Как стать автором
Обновить

А есть ли причины использовать статически типизированный функциональный язык программирования?

Время на прочтение10 мин
Количество просмотров6.6K
Всего голосов 56: ↑21 и ↓35-14
Комментарии28

Комментарии 28

PHP/Ruby — Два языка, которые завязаны на Веб-разработке…
Зачем… зачем так грубо с Ruby, сердце кровью обливается. Возможно из-за этого вы попадёте в ад.
>C# — Еще один клон С++

Вообще-то это такая майкрософтовская джава, а вовсе не клон C++. Да и сводить отличия от C++ к сахару? А сборщик мусора, а среда исполнения — это все сахар?

Но это так, придирка. У меня их к этой статье на порядок больше, просто лень перечислять :)
Если верить Рихтеру и Шилдту, то C# — это именно потомок С++, а не джавы (см. c-like object oriented language aka COOL aka C#)
C# — потомок С++, а вот CLR проектировалась на основе джававской машины. Причем так стремились к точному копированию, что тащили даже ошибки (по мнению Липперта) типа ковариции массивов.
Насчет ковариации массивов решарпер мне постоянно орет, а вот в чем заключается эта ошибка я так и не смог нагуглить.
По сути: Animal[] animals = new Giraffe[10]; — валидно по определению ковариации, но может привести к ошибке, когда в animals попробуем добавить, например, черепаху. По этой причине для дженериков решили избежать этой проблемы и поэтому ковариации для них нет, ну а для массивов не стали убирать из-за обратной совместимости.

У Липперта отличная серия статей на эту тему — начиная отсюда (не знаю, может где-то и переведенное на русский есть).
А что тут понимать? Массив мутабелен:

String[] stringArray = new String[1] { "str" };
Object[] objArray = stringArray;
objArray[0] = new Object();

String str = stringArray[0] // упс


В скале бы сказали, что типовой параметр стоит в контравариантной позиции и потому массив не может быть ковариантным по этому параметру.
В C# 4.5 страшных слов не используют, так что говорят проще: типовой параметр массива не может быть помечен «out», так как значение с этим параметром может быть записано.

вопрос 2 часа висел не отвеченным, как мы умудрились ответить синхронно?
Спасибо вам обоим, жаль репа в заднице, плюсовать не могу.
> А, если вы в своей практике встречались с задачами реализовать GUI на логическом языке (как Пролог) или Веб-разработку на Лиспе, то вы должны и сами представлять всю сложность «впихнуть невпихиваемое».

Как человек, давно и с удовольствием занимающийся веб-разработкой на Лиспе, хочу сообщить, что о «впихивании невпихуемого» там и речи не идет. Все делается логично, удобно и идиоматично. PHP по сравнению с Лиспом гораздо более неудобный язык для веб-разработки, но у него более пологая кривая обучения.
Говорят, что если сразу человека учить функциональному программированию, не забивая ему голову императивщиной, то он вполне учится. Хотя мне уже не испытать на себе этого, увы.
JS уже давно не просто для свистелок в браузере. У него есть очень большое количество библиотек для того чтобы иметь право на жизнь не только на стороне браузера, но и на довольно такие не плохом server side (NodeJS, Rhino and etc). Также сообщество commonjs развивает все новомодные плюшки, типа модульности, отложенных выполнений и прочее. И я считаю, что JS уже довольно таки сильный язык, чтобы посоревноваться с остальными… Одна из таких сторон это невероятный фреймворк AngularJS.
Более того, там вполне возможно программирование в функциональном стиле, и смотрится весьма органично.
livescript.net/ с prelude.ls так вообще няшка
В чем смысл поста? Цель первой статьи — элегантно намекнуть на некоторые плюшки, которые в общем и среднем дает ФП. Вы придумываете ситуации, в которых эти преимущества по разным причинам не играют роли или нивелируются. Никто и не сомневался, что они существуют.
Более того, в некоторых постах автор спорит с подразумеваемой версией: например в первом посте он спорит с шуточным утверждением «я не хочу следовать модным тенденциям», то есть спорит с утверждением, что им надо следовать. С другой стороны в посте №10 авторя явно намекает, что стоит учить математику. Так как в этом автор согласен с автором репоста, но не остается ничего, кроме как начать спорить с заведомо шуточным (а значит, отражающий противоположенность истине) пунктом.

То есть когда автору удобно — он громит подразумеваемый смысл, а когда он физически не может этого сделать (ввиду самоочевидной истинности какого-либо пункта), начинает спорить уже с шуткой…
Вот уж действительно иногда лучше жевать, чем говорить.
Mono? А вы уверены, что когда-либо будет достигнута задача запуска абсолютно любой программы, написанной на С#?
Реализация CLR полностью совместима, в BCL есть всё кроме WPF. Т. е. запускает любой код, который не использует WPF и не пытается стучаться через P/Invoke напрямую к Win32 API. Т. е. ограничения портируемости примерно такие же как и у C++. Вы же не ожидаете, что ваша программа на MFC запустится на Mac OS X? Или что проект, использующий JNI не придётся снабжать нативными версиями библиотек для каждой платформы?
Вывод: используйте D.
А вы читали «Комментарии автора к статье»?
Я думаю — это именно для вас.
Спасибо за статью. Было приятно прочесть ваши размышления, даже вне контекста ФП. Я полностью разделяю мнение, что программирование — это, в первую очередь, решение задачь. Тренды имеют значение, но они вторичны. А хорошего программиста, имхо, отличает вовсе не знание N->max модных технологий, а рациональное мышление, умение видеть абстракции, опыт, «крепкий фундамент» и здравый смысл.
Чем короче код, тем он непонятнее, и чем более явно всё прописано, тем понятнее.
Дигидрогена монооксид.

Вообще, я не очень понял, какое глобальное утверждение пытался оспорить автор этой статьей.
Хотел бы добавить:

> Причина 1. Я не хочу следовать последним тенденциям

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

> функции высшего порядка для коллекций (есть в C# и других языках, и будет в Java)

В Java уже есть Collections и Generic, как основа, и множество готовых библиотек типа Guava.

Императивные языки обзаводятся техниками функциональных и наоборот.
C# — Еще один клон С++, весь «сахар» появился уже позже, а распространенность основывается на привязке к Windows

Действительно, могли бы джаву использовать, она ведь на всех платформах
Могли бы, если бы не жадность Sun.
Был такой уродец, Microsoft JVM, но закончилось всё печально.
Давайте ещё J# вспомним.
Стоп, стоп, стоп. Мы говорим о том, что неплохо бы, если на всех платформах работала одна managed платформа, бинарно совместимая.
Микросовт вот подумал, что неплохо бы, начал работы, а ему жадины из SUN крылья подрезали, пришлось свой несовместимый клон делать.
Ну и хорошо, что подрезали. Совместимость всегда означает тащит старые костыли, а хотя бы в этой( habrahabr.ru/post/145932/ ) статье рассказывается, что они ввели и нормальные структуры, и настоящие дженерики, и пр…

(Бесит невозможность использовать теги форматирования...)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории