Нет, нет. Мы сразу абсолютно однозначно (и я это подчёркивал) обсуждаем алголопожобные языки. То есть императивные. Поэтому не надо нам ни (никому ненужной  ) функциАнальщины, ни монструозных гибридов. Вот и сравни Java и какой-нибудь другой императивный язык под JVM. Разница тут будет чисто синтасическая. Синтаксис в данном случае как раз будет вторичен.

Конечно, если включить в рассмотрении какой-нибудь функциАнальный язык, то синтаксис уже вторичен не будет. При таком сравнении уже нужно понимать, что синтаксис будет определять уже сам способ мышления программиста. Поэтому, повторюсь, мы ограничимся императивными языками, когда синтаксис (до какой-то степени) будет вторичен. Благо, мы можем наложить такое ограничение на дискуссию с чистой совестью и почти без последствий, ибо о(б)суждаемые ЯП (C, C++, Pascal, Oberon, Java) императивны.


Безусловно. Но мы говорим только за Java. Это один язык. То, что впоследствии (благодаря популярности Java) появилось множество языков под JVM не меняет дело. Изначально JVM писалась чисто и только под Java. И, кстати, многие идеосинкрозии JVM отсюда и растут. Поэтому, кстати  , при разработке своей JVM с пасьянсом и куртизанками MS так сильно концентрировалась на том, чтобы платформа была максимально независима от (пускай и основного) языка, что отразилось даже в названии CLR.

Но, повторюсь, с JVM была совсем иная история.
 

Опять же, не думаю, что это имеет какое-то отношение к нашему разговору. Интерепретатор он на то и интерпретатор, что там не нужно ни промежуточное представление кода, ни виртуальная машина для его исполнения.


Дык о том и речь, что не имеет. Это же ключевое различие, а Вы его сразу отметаете. И как Вы собираетесь сравнивать Java в отрыве от платформы? Это бессмысленно. Там останется только синтаксис. А он мало того, что вторичен, он банально (почти) одинаков. И сравнивать то особо нечего.


Нет, нет, нет и ещё раз нет. С точностью до наоборот. Java существенно ближе к Оберону, чем к С++ с точки зрения идеалогия, чтобы Вы под ней не понимали.

Вот, смотрите. Первой будет идти характеристика общая для Java и Oberon, затем характеристика C++.

• Промежуточное представление кода и исполняющая его виртуальная машина против компиляции в машинный код на каждой платформе.
• Раздельная компиляция (separate compilation) против независимой компиляции (independent compilation). Разница существенная, между прочим. Вот тут можете посмотреть, о чём речь. Впрочем, я именно Вам уже это пытался объяснить, как мне кажется.
• Динамическое связывание против статического связывания.
• Только процедурное и ОО программирование против всего, что пожелаете. Да, в Java есть процедурное программирование. Из-за того, что класс выполняет функции модуля оно просто скрыто. Каждый раз, когда Вы пишете статическую функции и, не зная куда её деть, создаёте какой-то недокласс - это и есть процедурное программирование на Java.  
• Только полностью автоматическое управление памятью (сборка мусора) против ручного и (всё-таки) полуавтоматического (умные указатели).

Хватит для начала?

ну собственно все расхождение в этом.

я когда-то пытался (безуспешно) приобрести книгу по C#, где был бы описан в первую очередь язык, а CRL во вторую (или вообще не описан).
я понимаю, почему не нашел. понимаю, насколько сильна связь подобных языков с платформой. понимаю исторические причины вида java (как и C++).
но когда я пишу на языке, неважно каким образом исполняемым, я думаю на этом языке. а встроенные структуры/алгоритмы воспринимаю как прилагаемые библиотеки (что вполне естественно, т.к. часть структур и алгоритмов мы таки пишем сами).

что касается раздельной/независимой компиляции, я все безусловно понимаю. это, пожалуй, действительно серьезный аргумент, и я его пропустил. но опять же, на определенном уровне по большому счету неважно, что писать - import, #include или uses, точнее, что при этом думать.

Добавлено через 2 минуты и 54 секунды
  

далеко не всегда предсказуемым, и уж не настолько определенным. боль-менее точно определены цели, а уж результат....   

солидарен, платформы надо сравнивать вне сравнений языков ))

так его выразителеность и есть суть языка, все остальное возможности/особенности среды выполнения..

потому яву как язык надо сравнивать с другими языками ява-машины.. шарп с с++ сравнивается только в cli-шном исполнении.. 
в противном случае паскаль с с++ одно и то же , ибо отличаются только синтаксисом 

при всем этом выразительность одного языка может быть неприемлимой/неудобной как для другой платформы, так и области программированния... потому это тоже должно быть уточнено перед спором.. 

У всякого тьюринг-полного языка (а все обсуждаемые к этой категории относятся) выразительность максимально возможная. Так что критерием это служить не может.

Фантом, может и служит )

Не уверен, но вроде как наличие миксинов в языке никак не влияет на полноту по Тьюрингу (ну если только в compile-time), однако в некоторых ситуациях позволяет элегантно решить задачу. Т.е. позволяет программисту выразить свою мысль просто и доступно, ближе к терминам прикладной задачи, а не языка. Т.к. программы пишутся для людей в первую очередь, это позволяет код сделать читабельным, а значит легким для сопровождения, а значит более эффективным. Ассемблер-то тоже тьюринг полный. Чем больше язык позволяет оперировать ближе к терминам прикладной задачи, тем он эффективнее - вот в этом я уверен на 100%. А тут тьюринг-полноты не достаточно.

Да и функциональщина имеет хорошие перспективы на мой взгляд. Это же замечательно, если компилятор будет знать, что данные функции чистые с функциональной точки зрения - он сможет оптимизировать порядок их вызова, возможно даже где-то закэшировать вызов (ну вот такой умный компилятор попался  ) - чем не шаг к декларативному программированию? Держать под контролем все аспекты выполнения кода становится все труднее и дороже. На первый план выходит способность кода к сопровождению - в принципе, по этой же причине появились всевозможные убийцы плюсов. А наличие в языке возможностей к совместному невзаимоисключающему смешению различных парадигм - и императивщины, и функциональщины, например - дает возможность программисту использовать именно то, что наиболее оптимально для конкретной задачи. В части межпоточного взаимодействия функциональщина даст фору императивному подходу, имхо.

Это совершенно правильно. Но это не "выразительность" в терминологии  mes, она определяется совсем не тем, описываются операторные скобки как begin..end или {..}.   

  позвольте уточнить, "выразительность" в терминологии mes, это описание операторных скобок через {...} ?  а то я русский подзабыл..

Как я понял, Вы считаете за выразительность способность языка каким-либо образом (не важно, каким - лишь бы был) выразить все возможные варианты - поэтому Вы и опираетесь на тьюринг-полноту. А мне показалось, что mes имел в виду, что выразительность языка это его способность кратко, емко и по существу выразить то, что нужно программисту (например, я именно так представляю выразительность).
Я правильно вас обоих понял?

И чтобы не писать второй пост - у меня сложилось впечатление, что именно из-за выразительности в понимании Фантом хвалят С++ его сторонники, когда говорят, что это мощный язык (и это так). И именно из-за не очень высокой выразительности в понимании Mes (в силу излишней сложности синтаксиса - тут,  я думаю, никто не будет спорить) ругают С++ его противники.

С точностью до наоборот. 

кажется все тут выразительность понимают по разному. если выразительность синоним возможности реализовать вычислимую функцию, то и brainfuck выразителен.
однако традиционно под выразительностью ЯП понимают его синтаксические возможности, т.е. удобство для человека.

В том и проблема, что удобство для человека может быть разным. Можно сделать так, чтобы удобно было писать код, а можно так, чтобы его удобно было читать и поддерживать.

можно пример, когда удобно писать, но неудобно читать и наоборот?

По-моему это одно и то же. Как можно удобно писать код, который неудобно читать и поддерживать?

   одно предположение - тупо фигачить наугад по клавиатуре десятью пальцами - писать удобно, но сопровождать...   

Два классических примера: Perl и Ada.