Цитировать не буду. Тезисно.
По поводу вопросов сугубо по языку, коли таковые возникнут: Согласен. Я просто говорил, что знание только языка - это очень мало. Более того, как показывает практика, вопросы именно по языку чаще всего возникают в одной и следующих ситуаций:
- на этапе изучения языка или подготовке к какому-нибудь экзамену на сертификат;
- при "копании" в чужом коде иногда встречаются конструкции, которые ты просто редко используешь;
- когда тебе нужны какие-нибудь инструменты языка, которые редко используешь или вовсе не сталкивался с ними.
В большинстве же случаев, как правило, возникают вопросы не по языку, а по библиотекам или технологиям программирования.
По поводу Паскаля и первокурсников: Так уж получилось, что первым языком программирования, который изучает нынешний среднестатистический школьник или студент, оказывается именно Паскаль (что забавно - до сих пор в виде DOS-овского TurboPascal'я). Для многих из "моего" и чуть более старшего поколения первым языком был Бейсик УК-НЦ, для еще более старшего поколения - Фортран. Естественно, пишешь на том языке, которым лучше владеешь.
По поводу размера исполняемого бинарного файла: На ассемблере можно написать все что угодно. Причем при хорошем подходе к оптимизации кода такие программы будут самыми маленькими и наиболее эффективными. Но увы, трудоемкость программирования на ассемблере даже довольно простых вещей слишком высока. Большая часть кода современных операционных систем написаны на С/C++. Что уж говорить о пользовательских приложениях. Ассемблер и сейчас, конечно, используется. Но в очень специфических местах. Горячие же споры на тему "Ассемблер vs языки высокого уровня" затихли еще в 1970-х годах... При нынешней производительности компьютеров и размерах памяти они тем более неактуальны. Вот другое дело споры "компилируемый код на C/C++ vs интерпретируемый на Java" - по сути тот же спор, но уже на новом витке.
По поводу портируемости - кстати, есть вполне успешные решения написания портируемого кода и на компилируемом языке. Характерный пример - библиотека Qt. Кроме того, рекомендации придерживаться стандарта С++ тоже никто не отменял (если бы еще разработчики компиляторов к этим рекомендациям прислушивались бы - но это уж совсем тонкости пошли
По поводу "сборки мусора": Тут все зависит от того, к какому стилю программирования привык человек. Я привык полностью сам контролировать все ресурсы, которыми располагаю - захватывать их и освобождать. Поэтому когда это делают за меня, мне как-то неуютно и я как-то инстинктивно внутренне не доверяю этой сборке мусора. Однако же те, кто привык работать на более высоком уровне, часто даже не умеют следить за используемыми ресурсами и тем паче не думают об их освобождении. Упаси Эру, если такому программисту приходится переходить язык более низкого уровня. Без слез смотреть невозможно. И на самом деле очень жалко человека.
По поводу шаблонов с С++ и STL: Шаблоны - штука специфичная, но часто полезная. Хотя не могу сказать, что часто ими пользуюсь (в смысле - пишу свои шаблоны). Действительно по болшому счету сталкиваюсь с ними в основном когда пользуюсь STL-ем А вот STL на шаблонах построена. И в этом ее великая идея. Пример со строкой не очень корректен. Свою строку действительно не так уж сложно реализовать на char*. Однако же не строками едиными STL заканчивается. А вот другие STL-ные контейнеры гораздо более сложные. Особенно если вспомнить, что в качестве элементов того же вектора могут быть объекты абсолютно любого типа - от обычных int или char до сложных классов или других контейнеров. И со всеми ними можно управляться абсолютно единообразным образом. Вот тут и есть вся прелесть. Кроме того - STL, это не только контейнеры. Это еще и алгоритмы! Причем алгоритмы тоже могут быть применены к элементам любого типа. И это достигается опять же за счет шаблонов.
И еще в сторону интерпретируемых языков: Мне в таких языках очень не хватает указателей, возможности работы напрямую с памятью и прочих низкоуровневых штук. В свое время это мне создавало значительные трудности в проектах на Python'е.
Никакая она, по сути, не кроссплатформенная - VJM всё равно пишется на нативных функциях. 
Никакая она, по сути, не кроссплатформенная - VJM всё равно пишется на нативных функциях. 
