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

Что я имею в виду по сложностью - сложность освоения, сложность выражения алгоритмов и т.д. Скажем так язык для мазохистов))

Но при этом этот ЯП был бы вполне востребованным или хотя бы позволял создавать приложения, не уступающие по функциональности приложениям, написанным скажем на C++ или Java. Про "нетормознутость" приложения я не говорю, ибо это в принципе неважно.

Если речь идет об используемом языке (а не придуманном "хохмы ради", вроде Brainfuck), то ответ уже назван - это C++. 

P.S. Это совершенно серьезно.

Фантом, а бесполезно!  


UniBomb, да, это C++. 

Добавлено @ 18:23

  Ну, тогда точно он!

Это сообщение отредактировал(а) kemiisto - 10.6.2009, 18:23

Я то думал будут говорить про какой-нибудь Ruby или Haskel :(

На самом деле субъективно С++ мне не кажется таким уж сложным. Может это потому, что я и С++ не так уж хорошо знаю, но в принципе в процессе использования его в том объёме, в котором мне позволяет моя подготовка, мне всё кажется простым и логичным. Трудности возникают в основном в алгоритмах, а не в реализации...

Ruby?  Неудачная шутка... A Haskell то тут причём?

Это кто писал?  



А может это потому, что ничего кроме С++ ты и не видел? Тока без обид. Всё познаётся в сравнении.  

Какие тут моуть быть обиды... Я действительно окромя С++ ничего практически не видел. Немного php, немного pascal, немного avr-asm. Поэтому и ляпнул про раби и хаскель (кстате непонял к чему претензии к хаскелю - он ведь тоже язык программирования, правда о его назначении я не знаю). Вот и хочу расширить свой кругозор и занятся ещё каким-нибудь ЯПом. Но я не хочу идти по пути "учи то-то и то-то, ибо больше пригодится".... Вот как то так.

мне ничего сложнее delphi не встречалось  
удивительно нелогичный и не интуитивный дизайн

Он пока не настолько востребован, чтобы обращать на него внимание. Кроме того, ФП - специфическая область. С позиции большинства императивных программистов = это сплошной мозохизм. 


Я бы посоветовал Component Pascal.

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



Вот этого я не знал.



Надо глянуть что это такое))

UniBomb, попробуй Visual Prolog, по сравнению с ним BrainFuck совсем не е...т мозги.

С чего? Два достаточно аккуратных языка, Haskell более компактный и логичный. Вы путаете сложность языка и непривычность принципов, которые в него заложены. 



Я бы сказал, что C++ в полном объеме знают очень немногие люди в мире (если таковые вообще имеются, в чем я совсем не уверен).   Из-за попыток затащить в язык сразу несколько парадигм в C++ появилось море языковых конструкций и особенностей их интерпретации, которые достаточно сложно связаны. 

Другое дело, что подавляющее большинство тех, кто использует C++, de facto пишет на некотором существенно упрощенном подмножестве языка (Вы наверняка не исключение), однако полностью проблему это не решает. Во-первых, у каждого человека подмножество свое, поэтому поддерживать чужой код или работать в группе достаточно неудобно, во-вторых, банальные синтаксические ошибки (с точки зрения "подмножества") могут оказаться корректными (но неправильными по смыслу) конструкциями для языка целиком.

ну это смотря что писать, если писать приложение для работы с БД, то да, просто, а если программировать, то полная *опа  
вот простой пример, у нас есть массив чисел типа double, нужно их отсортировать и вывести на экран
вариант на с++


ф-я print_data будет работать с любым контейнером и даже с обычным массивом или строкой
вариант на паскале пишите сами, мне страшно представить что у вас получится  

еще вариант, выбор из массива N разных, случайных элементов, вариант на с++

попробуйте сделать лучше на delphi  

Это сообщение отредактировал(а) Lazin - 10.6.2009, 21:51

  Для универсального вывода можно использовать тип Variant. Динамический массив есть свой родной.

даже для своего класса?


а как он мне поможет, если я написал свой контейнер, со своими итераторами, или массив тупо не подходит для той или иной задачи  

  Вектор тоже может не подойти для той или иной задачи, и что?


  Для типов есть стандартное преобразование в строку, для объектов можно переопределить ToString и юзать как альтернативу.

Вариант это и массив и объект и интерфейс и ком объект.

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

в этом и дело, я могу вместо 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