Если функциональные языки действительно лаконичны, почему они не имеют лучшего ранга в игре стрельбы по языкам?
Я сравнил языки в языковой игре-стрелялке только по размеру их кода . Вот краткое изложение того, что я получил (сначала самое короткое, сгруппированы по сходным показателям).
- Python, Ruby, JavaScript, Perl, Lua, PHP, Mozart / OZ
- OCaml, Erlang, Racket, Go, Scala, F # Smalltalk
- Паскаль, Чистота, Хаскелл, Common Lisp, C #, Java, C
- C ++, Ada, ATS
Интересно, почему. Победители кажутся простыми старыми динамическими языками. Эрланг, Ракет (урожденная схема PLT) и F # все в порядке. Haskell и Common Lisp не выглядят более лаконичными, чем заявленная для многословия Java.
ОБНОВЛЕНИЕ:
Я нашел проницательный пост на эту тему с диаграммами. Я также нашел аналогичное сравнение языков для более крупной программы (простой трассировщик лучей). В целом, я бы не сказал, что получил «ответ», но у меня есть пища для размышлений.
5 ответов
- Ни один язык не всегда превосходит другой (ну, есть несколько исключений... ;)), поэтому то же самое относится к группе широко категоризированных языков. Тесты охватывают широкий спектр тем, и X может быть менее подходящим для одного, чем Y.
- Исходный код gzipped, мы действительно не знаем, сколько строк какой длины были программы (да, это показатель)
- Значительное количество функциональных языков по-прежнему намного лучше, чем широко распространенный императив, статические языки - дело не в том, что функциональные языки программирования не лаконичны, но динамические языки позволяют использовать еще более лаконичные программы
- По крайней мере, в Haskell большой потенциал для краткости исходит от абстракций, которые вы можете построить сами, но вы должны создать их сами и включить их в свое решение. Умный хакер Haskell может реализовать монаду в 20 строк, что позволяет решить небольшую задачу в 20 строк вместо 30 - абстракция не окупается для маленькой программы, но может сохранить много строк в более крупной (например, 200 строк вместо 300) программе. Полагаю, то же самое относится и к Lisps (только макро вместо монады)
- Не воспринимайте фанатов слишком серьезно. FP удивителен и заслуживает внимания, но он не лечит рак и волшебным образом не сокращает код на 25%
- Они все еще могут превзойти динамические языки для некоторых областей: например, древовидные структуры данных и их обработка выражены чрезвычайно естественно во многих функциональных языках, благодаря алгебраическим типам данных и сопоставлению шаблонов.
Должно быть, это как-то связано с обширными ООП-библиотеками, доступными для большинства языков вашего уровня 1, и простыми старыми хаками, такими как обратные кавычки для вызовов оболочки и синтаксис регулярных выражений perl. Отказ от python
pw = file("/etc/passwd")
for l in pw:
print l.split(':')[0]
Вывод всех имен пользователей в системе потребовал бы намного больше кода, если бы не абстракции, которыми изобилуют объектно-ориентированные языки. Я не говорю, что это невозможно сделать в других парадигмах, но тенденция такова, что каждый тип имеет множество функций-членов, которые упрощают утомительные задачи. Лично я считаю чисто функциональные языки полезными только для академических целей (но опять же, что я знаю).
Программы в игре Alioth на самом деле не являются репрезентативными для программ на этих языках в целом. Во-первых, реализации там сильно оптимизированы для конкретной инфраструктуры Shootout, что может привести к менее идиоматичному и более раздутому коду на функциональном языке. Это похоже на то, как некоторые библиотеки Ruby пишут код, критичный к производительности, на C — если посмотреть на этот код C и объявить Ruby раздутым и низкоуровневым, это действительно не даст языку должной встряски.
Во-вторых, большая часть того, почему функциональные языки рекламируются как лаконичные, заключается в том, что они хороши в создании абстракций. Это, как правило, помогает больше в больших программах, чем в чудесах с одной функцией, поэтому языки, специально разработанные для легкой краткости, выигрывают там. Python, Perl и Ruby специально разработаны для того, чтобы делать короткие программы короткими, в то время как у большинства функциональных языков другие цели (хотя это не значит, что они просто игнорируют размер кода).
Вы должны учитывать тот факт, что ваши языки группы 1 (скрипты) в 30-100 раз медленнее, чем C/C++, для функциональных языков то же самое от 2 до 7 раз. Программы в списке оптимизированы по скорости, и измерение чего-либо еще является второстепенной проблемой, которая на самом деле не является хорошим показателем реального состояния языка.
Более интересно взглянуть на таблицу, где размер кода и время выполнения имеют вес 1. Таким образом, вы получаете сравнение соотношения скорость/ремонтопригодность, которое кажется лучшей метрикой, чем просто размер кода.
Это похоже на возможность вырваться:
Существуют ли статистические исследования, которые показывают, что Python «более продуктивен»?
Дело в том, что первоначальный вопрос заключается в попытке использовать некоторые (мизерные, неуместные) данные, чтобы сделать обобщение о сравнениях между языками программирования. Но на самом деле практически невозможно использовать какие-либо данные для каких-либо разумных общих количественных сравнений языков программирования.
Тем не менее, вот некоторая пища для размышлений:
- При прочих равных условиях языки с динамической типизацией, вероятно, будут более лаконичными, поскольку им не нужно тратить время на описание типов данных
- При прочих равных условиях , среди статически типизированных языков языки с выводом типов, вероятно, кажутся мне более лаконичными, поскольку им не нужно объявлять типы повсюду
- . более кратки, так как языки без них требуют повторяющегося кода или приведения типов и косвенности
- . При прочих равных, языки с кратким лямбда-синтаксисом, вероятно, будут более краткими, поскольку лямбда, возможно, является самой важной абстракцией в программировании для избегая повторения и шаблонного
Тем не менее, все вещи не равны, не далеко.