Tcl vs Clojure Vs CommonLisp vs Scheme

Если тебе нужен гуй, то на кой тебе функциональщина? Пиши на Tcl, он для гуйни идеален и лучше него ничего не придумали.

зря ты создал отдельную тему, ибо у каждого свой «функциональный стиль». Одним достаточно функций как FCO, другим подавай «типизацию Хиндли-Миллера» или ещё какого чёрта лысого

просто ужасная документация

Напиши лучше - будь мужиком! А вообще там отличная документация, но но местами не полная, что со временем исправляется.

Мне как раз не нужна жесткая типизация, как в Haskell, меня вполне устравивает динамическая типизация. Посему и рассмотрел вышеназванные языки. 1500 строк переписать я переживу, а вот когда хотя бы до 4000 доберусь...

Местами?! Она скорее местами полная.

типизацию Хиндли-Миллера
Миллера

http://en.wikipedia.org/wiki/Robin_Milner

Все познается в сравнении, давай образец «хорошей» документации!

Если тебе нужен гуй, то на кой тебе функциональщина?

Уменьшить количество строк, прокачать скилл.

Хотя бы документация по Qt, по Tk.

упс, виноват :(

запрашиваемые ТС в пред.треде фичи, реализуемые (либо реализованные) в Tcl:

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

наличие/возможность реализации нормальных лямбд - да,

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

наличие/возмоность реализации иммутабельных данных - если пояснит что имеет в виду, но последует ответ

наличие/возмоность реализации ленивость - да,

рекурсии/хвостовые рекурсии - да

паттерм матчинг - скорее нет, хотя в теории можно через «unknown» и «trace» реализовать

наличие/возмоность реализации иммутабельных данных - если пояснит что имеет в виду, но последует ответ

Тип данных, значение которого нельзя поменять.

Уменьшить количество строк, прокачать скилл.

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

Разве? А вот если выстроить тот же меню-бар их динамически-обновляемого списка. Тогда как без программирования?

Опиши правила преобразования списка в меню-бар. Декларативно. Программированию в гуйне не место.

наличие/возможность реализации нормальных лямбд - да

уже «в ядре»? Или всё так-же надо несколько строк написать (скопипастить с вики)?

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

если есть «нормальные лямбды», то разве это не автоматом даёт ФВП?

рекурсии/хвостовые рекурсии - да

«хвостовая рекурсия» стек ест? TCO нет, надо понимать?

Через ФП меньше строк получим, получится перейти к более высокому уровню абстракции -> сделает код программы более гибким

Скиллы качать? Coq, Agda, Epigram only. А то тебе сейчас насоветуют скалки, кложуры и прочую педерастию.

Выбор стоит между Tcl/Clojure/CommonLisp/Scheme и гуя для языка соответственно

Racket
просто ужасная документация

Too fat.

Документация у Qt и Tk действительно хорошая. Я так понимаю, у тебя претензии в основном к гую в Racket и к тому как он документирован? Есть такое - но гуй это маленький кусочек и он никак с функциональными фичами языка не связан, скорее это одна из самых императивных частей Racket. А что ты смотрел там, кроме гуя?

CL - CAPI, clojure - Swing или SWT.

P.S. Только что наткнулся на такую вещь. В CAPI (Common Lisp) надо самому реализовывать событие mouse-leave через таймер, но зато есть достаточно полная поддержка метафайлов - их можно создавать в памяти, читать с диска, писать на диск, класть и брать из clipboard. В SWT (Java) есть mouse-exit, но нихрена нет метафайлов, а нафиг тогда нужен, например, редактор диаграмм, если он не умеет создавать метафайлы в памяти и класть их в clipboard (или я мало смотрел, но просмотр исходников SWT ничего не дал)?

P.P.S. Справедливости ради надо заметить, что в Windows Forms (.NET) поддержка метафайлов тоже была сделана через одно место.

Тогда и не втирай за «функциональщину». Для гуя лучше WPF не найдешь.

Видите ли, у меня задача стоит именно написать программу с гуем в данном проект неотрывно. Причем нужен именно гуй-приложение, а не web-приложение. Посему...Если бы Вы посоветовали нормально документированный биндинг к Racket для Tk или Qt с хорошей документацией, вопрос бы отпал (тем более ракет немного ковырял, язык очень мощный)

для программы с гуем на tcl см. http://www.gnocl.org/

старательно выдержанная лёгкость и стиль tcl над gtk

А в Racket...даже сделать таблицу с реестром, который имеет множество параметров - уже само по себе не самая тривиальная задача. На у рисовать все, что можно через canvas...это как-то даже не знаю, через ж..у что ли.

Спасибо! Очень интересная ссылка! Буду смотреть. Но гуй в виде Тк в принципе меня тоже устраивает.

Для гуя, в таком широком понимании как Qt, Tk, на данный момент Racket очевидно не готов. Привязок к Qt нет точно. Про Tk не знаю, не видел.

А в Racket...даже сделать таблицу с реестром, который имеет множество параметров - уже само по себе не самая тривиальная задача. На у рисовать все, что можно через canvas...это как-то даже не знаю, через ж..у что ли.

Но это проблема не языка, а библиотек.

Согласен. Но ждать пока библиотеку допилят - я не могу.

Хочется узнать, насколько tcl поддерживает функциональную парадигму по сравнению с lisp-family

Так себе поддерживает. Замыканий из коробки нет, лямбд из коробки нет, FCO из коробки нет. Все велосипедится через костыли, типа upvar.

Разные перлы и питоны с рубями - и то могут больше.

Ок, на счет TCL понятно. Как с поддержкой гуйни в Clojure, CommonLisp и Scheme? И насколько у обозначенных языков хорошо обстоят дела с меттапрограммированием и поддержкой ФП?

(меттапрограммирование в сравнении с TCL соответственно)

Вспомнил. Есть еще такие варианты: (1) ABCL (Common Lisp) - Swing или SWT; (2) Кawa (которая не каша) - Swing или SWT. Но на мой взгляд это уже немейнстримная экзотика.

Как с поддержкой гуйни в Clojure, CommonLisp и Scheme?

В clojure замечательно, в CL хорошо только за денюжку, в scheme плохо.

дела с меттапрограммированием и поддержкой ФП?

С первым везде прекрасно, со вторым - в clojure заставляют использовать, в CL и scheme использовать удобно, но не обязательно.

Сами работали с Kawa? Почитал - выглядит «вкусно». В чем его профиты перед Clojure?

Я думал это «выберите лишнее слово» тред

Нет, я с kawa не работал, но работал со swing и swt. На счет kawa лучше спросить buddhist.

В CL есть привязки к Tk, google LTK

В чем его профиты перед Clojure?

[бред фанатика]В том, что это Scheme, R6RS. А Clojure — наколеночная поделка[/бред фанатика]

Уменьшить количество строк
Через ФП меньше строк получим
получится перейти к более высокому уровню абстракции
сделает код программы более гибким

Но ведь это всё мифы, насаждаемые адептами на ЛОРе и нульчане. На практике подтверждений этим мифам нет. Ведь если бы ФП/лисп/whatever действительно повышали продуктивность разработчика в разы, ими бы давно заинтересовались в индустрии.

Но это не так, и ФП, лисп и прочая маргинальщина заслуженно занимают своё место на обочине технологического прогресса.

Clojure

Рич Хикки - мерзкий говнюк. Само его существование является оскорблением наследия Лиспа, гения МакКарти и всех тех трудов, которые Лисперы вкладывали в дело за последние годы. Тот факт, что Clojure работает на JVM - это мелочь по сравнению с прочими смертными грехами, каковых настолько много (и которые так меня бесят), что я здесь даже половины не перечислю.

Ну что, начнем со сваливания в кучу функций и значений? В нормальном Лиспе головные формы распознаются моментально, потому что они, блядь, идут в начале списка. Когда с этим облажались в Scheme, было уже довольно хреново; еще хуже стало, когда на те же грабли наступил Пол «Поглядите-я-даже-не-знаю-что-такое-интерактивная-разработка» Грэм. И что, никто ничему не научился на их ошибках? Ах, ну да, в Scheme попытались это вылечить так называемыми «гигиеническими макросами», которые были хотя бы юзабельны, несмотря на убогость. В Clojure даже того нет - это просто смешно.

Но это еще не самое плохое. В Clojure слишком много синтаксиса! Похоже, что Хикки в качестве модели выбирал Haskell. Я не припомню другого языка, в котором было бы столько синтаксиса. В виде Кложуры мы получили самый синтаксически тяжеловесный лисп-подобный язык на сегодняшний день. («Лисп-подобный» - потому что, за исключением самых поверхностных моментов, на самом деле в Кложуре нет ничего от Лиспа.) Самые обычные вещи, которые тривиально реализуются в терминах головных форм, в Clojure превращаются в мешанину из скобок и разделителей, даже в элементарнейших случаях. [foo] вместо (list foo), {:foo bar} вместо (dict :foo bar)...

Лямбда. Это слово пишется как «lambda», а не «fn». Не так уж и сложно набрать, правда, мистер Хикки? Что, руку вывихнул, пока дрочил на собственное дутое ЧСВ? Надеюсь, руки у тебя отсохнут и отвалятся, а сам ты сдохнешь. Потому что ты угробил Лисп для огромного количества людей. Ты даже не можешь напечатать «lambda»? Серьезно? Не верю.

И да, к слову об ABCL. Он уже есть и прекрасно работает на JVM. Нет никаких причин плодить еще один диалект.

в CL хорошо только за денюжку

Есть GTK: https://github.com/Kalimehtar/gtk-cffi

Есть QT: https://gist.github.com/wedesoft/3993305

Есть Tk: http://www.peter-herth.de/ltk/index.html

Всё бесплатно

Спасибо за актуальные ссылки.

Что вам так эта гуйня сдалась? Что вы там такое делаете гуёвое да еще и на Common Lisp?

По-моему вы страдаете хернёй.

Буду краток: http://www.gtk-server.org/

Примеры: http://www.gtk-server.org/examples.html

Демо (со скриншотами): http://www.gtk-server.org/apps.html

А что-же всё такое старое?..

И да, к слову об ABCL. Он уже есть и прекрасно работает на JVM.

Он еще и активно сейчас развивается. Рассматриваю его для следующего проекта для интеграции с жабой.

Что вам так эта гуйня сдалась? Что вы там такое делаете гуёвое да еще и на Common Lisp?

По-моему вы страдаете хернёй.

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

Мне как раз не нужна жесткая типизация

Ну вот теперь ещё и жесткая и мягкая типизация появилась.