talas1234

Например, для контроля доступа к ресурсам, см. тут - bayguzin.ru/main/uroki/uroki-modx-revolution/resou...

Можно, я автор этой сборки. Собственно для начинающих и делал, хотя были и другие идеи. А по поводу того, что сильно заморочил, не парьтесь. Вам же надо посмотреть пример? Там примеров масса, pdoTools, Tickets, авторизация, условия.
Само-собой это не должно быть единственным источником для обучения.
А по поводу того, что там, что-то непрофессионально сделано, никаких аргументов из ответов я не увидел. Будут вопросы, стучите в скайп, помогу, если буду свободен.

1. Аналогию с самими языками проводить не стоит. Аналогию стоит провести для платформ.
Платформы вроде .net и java, которые разрабатывались для энтерпрайза, разумеется лучше для него подходят. И не важно даже, десктопное у вас приложение или веб-сервис. Важно, что в платформе есть поддержка нужных стандартов и технологий с гарантией качества от производителя.
С другой стороны, многие компоненты таких платформ это closed-source. Поэтому, если вы не банк, а стартап, то для веб-сервиса выбирайте
Ruby или Python.
Социальную сеть можно сделать много на чем, но я бы делал на рельсах или джанге. А вот функционал сбербанк-онлайн я бы делал на ASP.NET MVC (т.е. на C#) или на джаве (на спринге например). Однако, тот же близзовский battle.net написан на спринге (сервер когда-то случайно отдал мне stack-trace после ошибки).

Хотя, имхо, некоторые ключевые элементы дизайна языка все-таки влияют на возможность его применения в крупных проектах. Например, я считаю, что писать крупные проекты на языке со статической типизацией намного проще. Однако это вопрос очень холиварный.

2. Нет, не будет. Не должно быть, если точнее. Для пользователя язык общения с сервисом - HTTP. Если в современном веб-фреймворке нельзя нормально абстрагироваться от используемой технологии, это плохой фреймворк.

3. На PHP много чего нельзя сделать. Вернее, КАК БЫ можно все, но нормально можно только веб. Именно поэтому для меня он не язык, а какой-то шаблонизатор - слишком у него дурная история и связь с веб (что нехорошо для языка общего назначения). Конечно, современные веб-фреймворки его очень хорошо причесывают, что даже можно работать с ним, но мы же о языках говорим..

4. Для веб-проектов между Ruby, Python и PHP человек бы выбирал исходя из своих умений. У каждого языка своя экосистема (библиотеки, пакетные менеджеры, серверы приложений/плагины для веб-сервера) и довольно непросто знать все сразу. Именно поэтому все расходятся по своим лагерям и просто работают. Первичный выбор языка часто определяет его популярность. Лет 5 назад Руби всех рвал за счет Рельсов, сегодня Питон и PHP подтянулись в плане экосистемы, поэтому ситуация уже другая.
Если человек таки сумел познакомиться с разными языками, он выберет тот, в котором ему проще мыслить. Модель ООП, статическая/динамическая типизация - все это определяет ощущения КОНКРЕТНОГО человека от КОНКРЕТНОГО языка.

5. PHP учится быстрее всех, но если вы не знаете других нормальных языков, лучше его не учите - испортитесь как программист. Python и Ruby учатся примерно одинаково. Изучение C++ - совсем другая история, я бы не ставил его в один ряд с Питоном - этот язык несколько другого уровня и требует других (более глубоких) знаний о вычислительной технике (т.е. он 100% учится дольше, чем Python).

1) Можно задавать - что напишете в сниппете, то и сделает.
2) Есть разделение и достаточно просто в настройке.
3) Есть много готовых плагинов интернет-магазинов, но вообще MODX под это дело не приспособлен.
4) Есть плагин.
5) В MODX есть симлинки.
6) Мультиязычность - слабое место, реализуется костылями.

БЭМ - это такая методология вёрстки от Яндекса. Она подразумевает разбиение страниц на отдельные смысловые блоки (комментарий, пост, заголовок, футер, форма, инпут и т.п.). Каждый блок может состоять из других блоков. Основная идея - как можно больше повысить возможность повторного использования уже написанных блоков, для чего используются модификаторы. Плюс, БЭМ подразумевает отказ от каскадных стилей, потому что они препятствуют повторному использованию.
Например, на странице есть два разных заголовка (например, отдельно в статье, и отдельно во врезке). Как все привыкли делать это? есть код заголовка:
<h1 class="header">Заголовок</h1>
И мы ставим эти заголовки в текст статьи и во врезки:

<article class="article">
    <h1 class="header">Заголовок</h1>
    <p>Текст текст текст</p>
</article>
<aside class="incut">
    <h1 class="header">Заголовок</h1>
    <p>Текст текст текст</p>
</aside>

Тогда обычно мы используем каскад, чтобы стилизовать заголовок во врезке:

.header {font-size: 2em; padding-bottom: 1.5em;}
.incut .header {text-decoration: italic;}

Всё хорошо, но теперь мы не можем просто перенести эти стили заголовка во врезке в другое место, потому что эти стили привязаны именно ко врезке (классу incut). Плюс, что ещё хуже, если к элементу привязано несколько различных стилей, образующихся подобными каскадными правилами, то перенести такой внешний вид в другое место становится очень трудоёмко. А также, из-за большей специфичности каскадных стилей, их сложнее "перебить" новым стилем.
БЭМ предлагает отказаться от каскадных стилей и создавать отдельные стили-модификаторы:

<article class="b-article">
    <h1 class="b-article__header">Заголовок</h1>
    <p>Текст текст текст</p>
</article>
<aside class="b-article b-article__incut">
    <h1 class="b-article__header b-article__header_incut">Заголовок</h1>
    <p>Текст текст текст</p>
</aside>

.b-article__header {font-size: 2em; padding-bottom: 1.5em;}
.b-article__header_incut {text-decoration: italic;}

Чем больше проект, тем выгоднее использование подобной методологии. На маленьких и средних проектах БЭМ может быть избыточен. Хотя вот была статья habrahabr.ru/company/yandex/blog/234905 про использование в маленьких проектах.

БЭМ может использоваться самостоятельно, вручную создавая все элементы и блоки. Но существует обширный инструментарий для БЭМа, который помогает создавать библиотеку элементов и блоков.

Ну вот. Получилось не в двух словах, но менее подробно качественно описать БЭМ не получится, имхо.