в этом и дело, я могу вместо vector<double> написать vector<long> или list<complex>, все будет работать одинаково, первая ф-я ожидает на вход пару forward итераторов, в качестве forward итератора может выступать все что угодно, начиная от указателя и заканчивая файловым итератором. 
Вторая ф-я принимает vector<T>, но можно ее переписать так, что она будет принимать пару random access итераторов.


а можно тупо добавить каждому объекту метод WriteMe и все, че париться  


а если я написал класс complex, который не имеет таблицы вирт. функций, это просто пара чисел, не массив, не интерфейс и не ком объект, и выводить их нужно не просто так, а перед мнимой частью еще вывести "j". Писать убер-функцию которая будет выводить все что угодно?


вот мы наконец и вернулись к сабжу, почему я считаю что delhpi - сложный язык программирования
- код на delphi жутко не гибкий, написать простую ф-ю - просто, но сложную, как например ф-ю вывода на экран содержимого любого контейнера, "правильно" реализовать очень сложно, так как все решения принимаются в рантайме, эта ф-я должна быть невероятно могучей и знать о всех типах, которые ей могут быть переданы. Проблемы с отладкой и сопровождением такого кода будут обязательно. Плюсовый вариант, который я привел, просто сгенерирует множество реализаций ф-ии print_data, для всех типов аргументов, причем у нас есть полный контроль за тем, как это будет происходить. Можно специализировать шаблон для определенных аргументов.

- язык имеет статическую типизацию, но, при этом он в основном ориентирован на "ран тайм фичи", что приводит к раздуванию кода. К примеру ф-я print_data на динамическом ЯП будет выглядеть по настоящему просто:

в принципе эту ф-ю можно и не писать, настолько она простая, вот что значит "ран тайм фичи"  
а в delphi, для того, что-бы работали ран  тайм фичи, нужно прелюбодействовать с технологией COM и интерфейсами, а это даже не intermediate, это сложно в реализации и в сопровождении, в этом очень сложно искать ошибки
вот почему я считаю delphi сложным языком программирования, несмотря на поверхностную простоту 

Добавлено через 8 минут и 5 секунд
еще одна сложность, возможно надуманная - освобождение памяти
в delphi нет GC, поэтому все нужно удалять вручную, но не всегда, часть объектов управляют временем жизни объектов, которые им передают, к примеру так поступает большинство VCL классов, но некоторые этого не делают, и перед тем как удалить, скажем TList, нужно сначала удалить его содержимое, это неудобно и не интуитивно. А из-за того, что delphi не поддерживает deterministic destruction как с++, то и написать smart pointer, который будет следить за памятью - невозможно, ну а реализовать сборщик мусора на delphi думаю вообще не реально...

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

Почти всегда «интуитивный» в отношении ЯП означает «похожий на то, что я видел ранее».

Если считать мерой сложности количество ad hoc решений в языке, не выводимых из неких базовых принципов, то C++ здесь вне конкуренции, пожалуй 

сложный ли такой код? (вроде бы ничего сложного)

gcc, читать сложно. 

Добавлено через 2 минуты и 8 секунд
А, так это Perl! Read-only language!  

  Разница есть. ToString есть у общего предка TObject притом виртуальная.


  Если бы это было самой большой проблемой программирования, то я бы согласился. Чтобы вывести массив чисел и функции не нужно, можно просто так написать  . 


  А вот с этим как раз проблем нет, в VCL есть универсальная система потоков пронизанная через весь VCL. Есть унифицированный интерфейс для чтения и записи в файл, память, ресурс, строку и т.д. Есть также объекты умеющие писать в поток стандартные вещи. Короче на все есть свое альтернативное решение. Просто ты мыслишь в терминах С++, от того не находишь аналога.

Добавлено через 1 минуту и 13 секунд
  И главное, синтаксис в десятки раз проще.

в паскале все объекты являются наледниками TObject? видимо нет, тоесть ради приведения к строковому типу, я должен наследовать свой класс от TObject? А если мне нужно создать несколько миллионов экземпляров моего класса, не будет-ли дорогим удовольствием наличие дополнительных данных и таблицы вирт. функций в моем классе?


ну это частный случай общей проблеммы, это может быть не вывод на экран, а к примеру сериализация в xml


Кажется мы разговариваем на разных языках, поток данных != итератор на элемент из набора данных.
Существует ли в delphi поток для записи в двухсвязный список, или в бинарное дерево поиска? Вероятно - нет.

Може он и проще, но зато он многословней, и простота синтаксиса != простота программирования  

  Все объекты его наследники.


  А вот это уже новости  . С++ намного более многословный, особенно при работе с шаблонами.
  Сравни dynamic_cast<TObject>(SomeObj) == NULL и SomeObj is TObject .


  С сериализацией как раз мощнее и удобнее на порядок ввиду того что RTTI на голову выше.



  Если подумать, то использование итератора это ни что иное как вызов виртуального метода. Работают же с деревьями, например с тем же TreeView или TXMLDocument. Вся проблема сводиться к тому что вместо It++/It-- нужно записать ChNode := RNode.Next; или ChNode := RNode.Prev;
  Скажу честно, мне не приходилось в Delphi работать с деревьями, но наверняка, те работал имеют свои наработки. Нельзя ждать, что в поставке будет все все, на все случаи жизни. Есть много сторонних классов.

  На счет 4х байтов адреса VMT, а ты знаешь какие накладные расходы на однократное выделение  
памяти? По меньшей 10-30 байт, только на служебную информацию, потом выравнивание на границу 4х байт, потом выравнивание структур на границу 8ми или даже 16ти байт. Сейчас 4 байта ничего не значат, это не вопрос оптимизации. Это крошечная плата за ту полноту фич, которые можно использовать. Например в С++ нельзя по указателю достоверно узнать какой это на самом деле класс, потому что нет ни какой гарантии что у этого класса есть VMT. А тут такая гарантия есть и на это можно всегда рассчитывать, будь то свой или чужой класс. Точно также работа с памятью. Возникают куча проблем с тем чтобы сначала выделить память и потом вернуть в ней результат, потому что объект может быть статическим, стековым или в куче. Нельзя быть уверенным что его можно уничтожить из вне или создать во вне и вернуть ссылку, так чтобы получатель мог его сам удалить при необходимости. А тут запросто, передавай куда хош, возвращай из функции, создавай и уничтожай где хош, потому что все объекты динамические. Это очень просто, других объектов быть не может. Собственный метод free() удалит его, каким бы способом он не создавался, кроме того если объект создавался во вне, а получен был лишь его интерфейс, то объект автоматически будет уничтожен как только переменная интерфейса выйдет из области видимости.
  Чего ни говори, но работа в динамике на порядок удобнее.

Традиции Винграда: любую тему о ЯП здесь превращают в холивар Delphi vs C++. Добро пожаловать в 2009 год, что ли...

Write-only  

ужас какой, а еще у вас нет стековых объектов

ну знаешь, в с++ этой конструкцией почти не приходится пользоваться, так как есть шаблоны, а в Delphi нужно постоянно использовать downcast-ы, так-как все контейнеры и все классы VCL, хранят указатели на TObject, там, где нужно хранить произвольные пользовательские данные.

но на голову ниже чем в C#  
Вообще, в с++ это то-же возможно, есть фреймверки для сериализации, которые сильно это упрощают.   

неа, возьмем к примеру std::vector<int>, после инстанциировния и оптимизации компилятором, итератор на элемень вектора сведется к указателю на int, а все операции над итератором - к операциям над указателем, никаких вирт. ф-ий, все максимально эффективно  



ну знаешь, выравниванием можно управлять, и очень часто, приходится работать с объектами, размер которых сопостовим с размером указателя на VMT, так-что это не аргумент. К примеру, мне нужно проводить вычисления над кватернионами, в С++ можно написать класс, который будет иметь семантику значений, полиморфизм такому объекту не нужен, но в delphi это сделать нельзя. Придется размещать объекты этого класса в куче, а это во первых медленней, так как повышается уровень косвенности при обращении, к тому-же, рано или поздно это приведет к фрагментации памяти.


Вообще-то можно, это называется RTTI. Но это как правило не нужно и обычно вызвано ошибками проектирования. Как правило, нам нужно наоборот, не знать с объектм какого класса работает программа, обращаясь к нему через указатель(ссылку) на базовый класс.

Ну, эти проблемы возникают обычно у нубов и это не проблемы вовсе. Такие ошибки достаточно легко обнаруживаются, так-как вызывают падение программы. К тому-же, моно сделать так, что с объектами некоторго класса будет можно работать только через указатель(нельзя будет создать на стеке), или только через смарт поинтер определенного типе. Можно сделать наоборот, так, что-бы объект можно было создать только на стеке и нельзя - в динамической памяти. В конце концов, можно написать сборщик мусора, а еще лучше - использовать готовую библиотеку  

Намана. Хорошо холиварят, даже читать приятно.  Берите пиво и попкорн!
Правда увлеклись vcl, а вопрос был про язык, а не библиотеки. А то знаете ли можно и MFC вспомнить или GTK 1.

Синтаксически С++ самый тяжёлый. А читабельность исходников сильно зависит от того насколько хороший профессионал их писал, в отличии от скажем python'а. 

Можете мне помочь решить эту проблему путем публикации своего мнения в этой гуглоформе. Со своей стороны готов поделиться результатами по окончанию опроса 

(пардон за некропостинг)


--- 

UPD
Итог
* визуализация ответов http://goo.gl/xzyV1x
* итоговая оценка сложности http://goo.gl/F3hk4k

Спасибо всем ответившим!

Это сообщение отредактировал(а) Stolzen - 24.12.2013, 15:27