LINUX.ORG.RU

Tcl vs Clojure Vs CommonLisp vs Scheme


1

3

Собственно тема выросла из: Функциональное программирование на tcl

Хочется узнать, насколько tcl поддерживает функциональную парадигму по сравнению с lisp-family (Clojure, Scheme (пишите конкретную реализацию данного языка), CommonLisp)? Сейчас есть примерно 1500 строк написанных на tcl, которые могу безболезнено (пока, проект по самым минимальным прикидками будет занимать около 6-8 тысяч строк) перевести на любой другой язык из обозначенных. Проект домашний. Но мне нужна поддержка функционального стиля и вменяемый GUI с документацией (Racket не предлагать, у него очень мало виджетов (меньше, чем в Тк) и просто ужасная документация).

Заранее всех благодарю!

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

anonymous
()

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

yyk ★★★★★
()

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

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

qaqa ★★
()
Ответ на: комментарий от yyk

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

iMushroom
() автор топика

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

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

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

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

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

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

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

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

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

iMushroom
() автор топика
Ответ на: комментарий от iMushroom

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

iMushroom
() автор топика
Ответ на: комментарий от iMushroom

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

anonymous
()
Ответ на: комментарий от MKuznetsov

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

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

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

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

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

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

yyk ★★★★★
()
Ответ на: комментарий от anonymous

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

iMushroom
() автор топика
Ответ на: комментарий от iMushroom

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

anonymous
()

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

Too fat.

anonymous
()
Ответ на: комментарий от iMushroom

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

qaqa ★★
()

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) поддержка метафайлов тоже была сделана через одно место.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от iMushroom

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

anonymous
()
Ответ на: комментарий от qaqa

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

iMushroom
() автор топика
Ответ на: комментарий от qaqa

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

iMushroom
() автор топика
Ответ на: комментарий от MKuznetsov

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

iMushroom
() автор топика
Ответ на: комментарий от iMushroom

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

qaqa ★★
()
Ответ на: комментарий от iMushroom

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

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

qaqa ★★
()
Ответ на: комментарий от qaqa

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

iMushroom
() автор топика

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

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

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

no-such-file ★★★★★
()

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

iMushroom
() автор топика
Ответ на: комментарий от iMushroom

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

iMushroom
() автор топика

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

dave ★★★★★
()
Ответ на: комментарий от iMushroom

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

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

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

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

no-such-file ★★★★★
()

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

vertexua ★★★★★
()
Ответ на: комментарий от iMushroom

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

dave ★★★★★
()

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

anonymous
()
Ответ на: комментарий от iMushroom

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

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

buddhist ★★★★★
()
Ответ на: комментарий от iMushroom

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

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

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

anonymous
()

Clojure

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

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

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

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

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

anonymous
()
Ответ на: комментарий от feofan

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

dave ★★★★★
()
Ответ на: комментарий от iMushroom

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

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

metadeu5
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.