Новый номер журнала «Практика функционального программирования»

Clojure - совершенно отдельный язык. так можно заявить, что для С++ нет стандарта - приходится учить диалекты - Java и C#....

Эта крута! Качаю. Спасибо.

1. -С++ рулез! Лисп - говно! 2. -Вот те функция на лиспе, дай аналог на С++ 3. -Вот те вставка на ассемблере, дай аналог на лиспе.

facepalm.png

ps. Не раньше, чем будет приведен ответ на п.2...

> А вот скажите, люди добрые, чем вам JavaScript и C# (версии >=3.5) не функциональные языки? Lambda есть, closure есть. Вопщем, Haskell и Lisp фтопку сдать в музей.

В них безусловно есть элементы. присущие в первую очередь функциональным языкам. Но чистыми функциональными языками они не являются в виду своей мутабельности (в отличие от Haskell). И эти элементы у них by-design, а не суровая необходимость как например у Lisp.

> Функция хоть небольшая, но работу по кодингу уменьшает.

для незнающих лисп - в двух словах, что оно делает?

> Clojure - совершенно отдельный язык.

Это ложь. Clojure является «современным диалектом Lisp» (источники - сайт проекта, Википедия и так далее).

С++ ... диалекты - Java и C#

Это ложь. Java и C# не являются диалектами C++.

Не может не удручать то, что ключевой персонаж сабжевого журнала практикует столь наглые демагогические набросы. Или, что того хуже, настолько некомпетентен в столь базовых вещах как история и классификация языков прогарммирования.

> Это ложь. Clojure является «современным диалектом Lisp» (источники - сайт проекта, Википедия и так далее).

То есть по-вашему к примеру между CPython и Jython и IronPython нет никакой разницы? И вообще Python - диалект ABC?

Это ложь. Java и C# не являются диалектами C++.

А Visual C++ это отдельный язык или диалект?

Clojure - язык семейства Lisp, но имеет свои отличия, также как и схема отличается от common lisp

выдержка из википедии - «The language (Java) derives much of its syntax from C and C++» - значит диалект С++, если следовать логике lester...

Р.В.Душкин как всегда в своем неповторимом стиле, написал очередную статью с ярко выраженным душком академической затхлости. Статья вообще непонятно о чем, непонятно зачем, а самое главное - непонятно для кого.

> Clojure (pronounced like closure) is a modern dialect

The language (Java) derives much of its syntax from C and C++

совсем одно и тоже, да

> Clojure... у лисперов нет стандарта, учите еще одну модификацию

Впрочем, месье Лестеру тоже не помешает ознакомиться с предметом. Суть такова: разных лиспов существует хренова туча (Scheme, CL, Clojure и так далее), но каждый из них довольно хорошо стандартизован (взять тот же R6RS, к примеру).

Другое дело, что даже имплементации CL могут быть несовместимы друг с другом, потому что, когда речь заходит о задачах реального мира (а не об «экзистенциальных композициях» и прочем матане), имплементоры начинают городить собственные расширения, кто во что горазд.

Хороший пример - разбор аргументов командной строки. Этого нет в стандарте CL. В SBCL используется одно расширение, в CMUCL - другое. Результат - несовместимые программы.

> А Visual C++ это отдельный язык или диалект?

это IDE, ваш К.О.

> Суть такова: разных лиспов существует хренова туча

в принципе это я и имел ввиду, неудачно выразился

>> А Visual C++ это отдельный язык или диалект?

это IDE, ваш К.О.

Ошибся немного)) Как он там называется C++/CLI

поговорим о совместимости С++ при решении задач реального мира? как насчет networking, gui? boost конечно покрывает часть задач, но многие его не используют, изобретая свои несовместимые велосипеды...

> поговорим о совместимости С++ при решении задач реального мира? как насчет networking, gui?

qt, wxWidgets

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

Гламурненько! почитаем-с

говорилось про стандарты

Хороший пример - разбор аргументов командной строки.

Аргументы командной строки - это операционная система, а не язык. Язык может существовать там, где командной строки с аргументами нет.

> говорилось про стандарты

«boost конечно покрывает часть задач» - с каких пор буст стандарт?

Четвертый номер «практики», и как и три предыдущих, никакой практики не показывает. Какая-то околоакадемическая бодяга для очкариков.

Будьте проще, пожалуйста! Хотите чтобы вас за красноглазых очкариков не считали, рассказывайте о нужных и практических вещах. Или функциональщина для практики все же не пригодна?

> Это ложь. Clojure является «современным диалектом Lisp»

(источники - сайт проекта, Википедия и так далее).

Такого языка как Lisp просто нет, обычно к этому «семейству» относят языки, синтаксис которых основан на s-выражениях. Т.е. основная общность между ними - подход к синтаксису. С этой точки зрения Common Lisp имеет такое же отношение к Clojure как Java к С#.

P.S. И вообще причины включения статей по Clojure и, особенно, по SBCL в журнал про функциональное программирование совершенно не понятны. С таким же успехом можно было включить и статью про JavaScript.

Спасибо)

Clojure выполняет требования к функциональным языкам - иммутабельность данных, ФВП и т.д.

> Clojure выполняет требования к функциональным языкам - иммутабельность данных, ФВП и т.д.

Там нет setq ?

> Язык может существовать там, где командной строки с аргументами нет.

Однако же Си, который есть для любой кофемолки, предоставляет таки стандартный интерфейс для коммандной строки.

изменяемость данных производится только в определенных условиях - в статье есть раздел «работа с изменяемыми данными»

> изменяемость данных производится только в определенных условиях - в статье есть раздел «работа с изменяемыми данными»

Я собственно к чему. К тому что наличие мутабельности не делает язык нефункциональным. Чисто функциональные языки можно по пальцам пересчитать на самом деле. Просто есть языки изначально закладывающие концепции функциональности (тот же лисп), а есть языки, в которых это было потом прикручено для удобства (C#, например). Про Javascript точно не скажу.

Ну и в JavaScript тоже только «в определенных условиях». Почему тогда его в функциональные языки не записывают?

> поговорим о совместимости С++ при решении задач реального мира?

Аргумент из серии «да ты на себя посмотри»?

Вы снова передергиваете. Совместимость компиляторов-реализаций С++ и библиотек/тулкитов - ортогональные вещи. Вы хотите, чтобы Gtkmm и Qt были API- и ABI-совместимы?

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

Уж по крайней мере «Hello, world» на C, распечатывающий argv, будет компилироваться и работать везде одинаково. Имплементации CL (я не говорю о прочих лиспах) даже этим похвастать не могут.

Я уже не говорю о задачах, чуть более сложных, чем «Hello, world».

> Просто есть языки изначально закладывающие концепции

функциональности (тот же лисп)

В Common Lisp функциональности точно не больше, чем в JavaScript. Поэтому неверно говорить о функциональных свойствах всех «лиспов», только для конкретных диалектов.

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

почему бы не взять в качестве примера hash tables, числа с произвольной точностью и т.д.?

>Очередной толстый журнал для русской интеллигенции?

Для яйцеголовой русской интеллигенции. А просто русская интеллигенция, это же говно нации, вроде ИльичЬ еще про это сказал?

> В Common Lisp функциональности точно не больше, чем в JavaScript. Поэтому неверно говорить о функциональных свойствах всех «лиспов», только для конкретных диалектов.

Наверно вы все-таки правы.

P.S. вспоминаю институтский курс «функционального программирования», на котором изучался Лисп(не помню уже какой диалект), поскольку «это же функциональный язык». Первым делом нас научили присваивать переменные и делать циклы :)

> Это означает лишь то, что стандарт CL состоит из десятков тысяч

экзистенциально-эфемерных функций,

Каких например? Что еще за «экзистенциально-эфемерные» функции?

а до такой приземленной чепухи

как командная строка не считает нужным снисходить.

Потому что программы на CL почти никогда этим не занимаются, их используют по другому. Впрочем, различных библиотек на эту тему тоже хватает, например: http://github.com/astine/unix-options

Я уже не говорю о задачах, чуть более сложных, чем «Hello, world».

А зря, можете разовьёте мысль?

При всем моем уважении, в заголовках чувствуется легкий аромат бульварщины. Ну типа, как в журнале Кулл Герлз, для сексуально раскрепощенных девочек.

> вспоминаю институтский курс «функционального программирования», на

котором изучался Лисп(не помню уже какой диалект), поскольку «это же

функциональный язык». Первым делом нас научили присваивать

переменные и делать циклы :)

В том то и дело, что тот же Common Lisp распрощался с функциональность лет этак 25 назад, но «народная молва» упорно ассоциирует его с функциональным программированием. В результате, когда хаскелисты пишут свои очередные «не понятно какие» (не могу подобрать подходящего слова) статьи, плохим снова оказывается лисп. Ну что за народ...

Ну напиши свою статью, в пух и прах разносящую тухлый академизм г-на Душкина и осуждающую его за отрыв от народных масс в духе пошлого эксзистенциализма. Запости на ЛОР, а мы посмеемся от всей души.

>Не раньше, чем будет приведен ответ на п.2

А какое отношения я имею к п1 и почему должен ответить на п2 ? Я задал прямой вопрос. Вы же утверждаете что лисп всемогущий - даже гемоглобин и тестостерон повышает :)

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

А на некоторых лиспах, кстати, это легко. Например muLisp под DOS позволял ассемблерные вставки делать.

> Clojure выполняет требования к функциональным языкам - иммутабельность данных

ну иммутабельность можно легко сделать легко в обычных языках - в лиспе есть иммутабельный fset, для java есть google immutable collections, и тд.

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

Так ты напиши - тебе же легко :) Только меня не устроит ассемблерная встака в виде копипасты, ты это на лиспе напиши. Самое главное заставь это выполнится потому что при небольшом знании ты бы заметил что просто так этот код не выполнится.

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

Представляю себе мутабельное число :) правда ничего не выходит. Какое состояние может быть у единицы?

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

Литералы в большинстве языков тоже иммутабельны. Иммутабельные классы, я думаю, тоже можно сделать в любом языке. Единственная проблема, это сделать immutable symbols или переменные - вот это да, сложно.

Основные проблемы CL - в его малой популярности. Отсюда - высокая стоимость профессиональных фреймворков для работы. Имеется ввиду мультиплатформенное GUI и прочие библиотеки. Скажем, лицензия того же LispWorks для Solaris составляет порядка 4200 евро. Мало кто может позволить себе такие расходы.

> Представляю себе мутабельное число :) правда ничего не выходит. Какое состояние может быть у единицы?

спроси и r.

> спроси и r.

«Будьте добры помедленнее, я записываю». Абсолютно ничего не понял