Комментарии 14
НЛО прилетело и опубликовало эту надпись здесь
У меня есть вопрос о синтаксисе, и при этом не о скобках.
Что вы думаете об удобочитаемости записей, которые нужно смотреть справа налево? Например,
В объектно-ориентированных языках это можно было бы записать как
Это не относится непосредственно к LISP, в том же Haskell или C запись тоже «перевернутая». Привыкаете ли вы или со временем это продолжает вызывать дискомфорт, так как традиционно письменность в другую сторону.
.LISP'e на писать легко арабам Наверное
Что вы думаете об удобочитаемости записей, которые нужно смотреть справа налево? Например,
(to-customize (to-install Common-Lisp-IDE))
В объектно-ориентированных языках это можно было бы записать как
Common-Lisp-IDE.to-install.to-customize
Это не относится непосредственно к LISP, в том же Haskell или C запись тоже «перевернутая». Привыкаете ли вы или со временем это продолжает вызывать дискомфорт, так как традиционно письменность в другую сторону.
.LISP'e на писать легко арабам Наверное
Дело в том, что в функциональных языках функция является самодостаточным объектом. Ее можно передавать, возвращать и частично пприменять. Поэтому запись с точкой после ее первого аргумента — немного некорректна. Разве что язык должен быть мультипарадигменным.
Например в Скале пошли еще дальше — поубирали точки, и теперь можно писать
вместо
Но многие предпочитают такую запись не использовать.
Например в Скале пошли еще дальше — поубирали точки, и теперь можно писать
names mkString ","
вместо
names.mkString(",")
Но многие предпочитают такую запись не использовать.
Но ведь теоретически можно сделать, чтобы функция была и самодостаточна и читалась слева направо.
Здесь точно так же как в LISP'e, только последний аргумент, а не первый, считается функцией.
В Scala очень даже используют функции без точек
Anyways, вопрос в том, удобно ли читать справа налево.
(((Common-Lisp-IDE) to-install) to-customize)
Здесь точно так же как в LISP'e, только последний аргумент, а не первый, считается функцией.
В Scala очень даже используют функции без точек
names ++ otherNames
Anyways, вопрос в том, удобно ли читать справа налево.
Это скорее вопрос нотации.
Тоже выглядит не особо.
Есть достаточно общее решение композиции функций. В Clojure для этого есть специальная функция ->:
Будучи макросом, тоже самое можно сделать и в CL.
toCustomize( toInstall(CL_IDE) )
Тоже выглядит не особо.
Есть достаточно общее решение композиции функций. В Clojure для этого есть специальная функция ->:
(-> Common-lisp-IDE to-install to-customize)
Будучи макросом, тоже самое можно сделать и в CL.
Я не говорю, что проблема с скобках. Я сам согласился, что к C такой же вопрос.
Конечно, можно написать макрос. Но как говорят, «in Rome, do as Romans do», «со своим уставом в чужой монастырь не ходят». Это как в каком-то Ruby возвращать два значения, где второе — ошибка, как принято в Go.
Все пишут справа налево, так здесь принято. Но удобно ли читать такой код?
Конечно, можно написать макрос. Но как говорят, «in Rome, do as Romans do», «со своим уставом в чужой монастырь не ходят». Это как в каком-то Ruby возвращать два значения, где второе — ошибка, как принято в Go.
Все пишут справа налево, так здесь принято. Но удобно ли читать такой код?
По мне, так дело только в привычке…
Просто я перестроил моё «миропонимание» таким образом: функция — первый элемент списка, остальное — аргументы (привет от Капитана Очевидность:-).
Просто нужно привыкнуть…
Просто я перестроил моё «миропонимание» таким образом: функция — первый элемент списка, остальное — аргументы (привет от Капитана Очевидность:-).
Просто нужно привыкнуть…
Да я тоже не про скобки, я про то, что наличие функций как обьектов первого класса дает возможность строить элегантные конструкции, которые более идиоматичны для CL, чем цепочка вызовов. Хотя, усли вызовов двое, как в примере выше, то вприцнипе, ничего страшного нет и я сам регулярно так делаю. Но если действительно цепочка вызовов — то без композиции функций очень сложно понять кто что получает и кто что ожидает получить, особенно, если arity функций не всегда равен 1.
Вообще, тезис сильный. Я, например, стараюсь использовать композиции и частичное применение, привыкать к неудобному — не очень полезно.
Все пишут справа налево, так здесь принято.
Вообще, тезис сильный. Я, например, стараюсь использовать композиции и частичное применение, привыкать к неудобному — не очень полезно.
НЛО прилетело и опубликовало эту надпись здесь
> Нам нужна кроссплатформенная, свободная, автивно развивающаяся реализация
> Common Lisp. Я выбрал SBCL.
SBCL под Windows, официальный релиз имел некоторые баги и проблемы с потоками
habrahabr.ru/post/131418 сводящие впечатление от работы в с ним на нет.
Исправилось ли это? Хотели мерджить форк А.Ковелкенко с основной веткой.
С другой стороны версия/форк Антона Коваленко, последняя вышла в 2013-01, уже достаточно давно.
Какую версию SBCL выбрать?
2. Какой гайд по настройке выбрать? по ссылке выше более лаконично. хотелось бы программировать на CL а не заниматься длительными перенастройками Emacs-а
> Common Lisp. Я выбрал SBCL.
SBCL под Windows, официальный релиз имел некоторые баги и проблемы с потоками
habrahabr.ru/post/131418 сводящие впечатление от работы в с ним на нет.
Исправилось ли это? Хотели мерджить форк А.Ковелкенко с основной веткой.
С другой стороны версия/форк Антона Коваленко, последняя вышла в 2013-01, уже достаточно давно.
Какую версию SBCL выбрать?
2. Какой гайд по настройке выбрать? по ссылке выше более лаконично. хотелось бы программировать на CL а не заниматься длительными перенастройками Emacs-а
Спасибо за замечание относительно бага SBCL в Windows. Я про него знал.
Но зачем так котегорично?
Не стоит судить о вещах на основании чьих-то впечатлений…
Я, пока, сильных косяков с официальной реализацией под Windows не замечал.
Для успокоения приведу ссылку на замечательную CAS-систему Maxima: бинарники скомпилированы при помощи трех реализаций: SBCL, OpenMCL и CLisp. Все прекрасно работают. Я все пробовал. Сейчас установлена версия с SBCL (на работе Windows, дома — Linux). Вы же понимаете, что CAS-систему, состоящую на 72.2% из Common Lisp кода не станут собирать и компилировать на «плохой» реализации…
На машине с Windows использую последнюю версию SBCL(1.2.13). Полет — нормальный.
Решать Вам…
Отностительно настройки Emacs — если хотите, скачайте LispWorks и/или Allegro — отличные продукты, но, проприетарные. Но есть «бесплатные» Personal Edition (типа MS VS Express Edition...). Но, запомните, Slime + Emacs ничем не уступают коммерческим системам… Бесплатно, но долго привыкать и учиться. Такова жизнь… С Emacs и Slime Вы получите полностью настроенную (Вами) и контролируемую систему, которая работает. Она просто работает. Выбирайте…
Но зачем так котегорично?
… сводящие впечатление от работы в с ним на нет.
Не стоит судить о вещах на основании чьих-то впечатлений…
Я, пока, сильных косяков с официальной реализацией под Windows не замечал.
Для успокоения приведу ссылку на замечательную CAS-систему Maxima: бинарники скомпилированы при помощи трех реализаций: SBCL, OpenMCL и CLisp. Все прекрасно работают. Я все пробовал. Сейчас установлена версия с SBCL (на работе Windows, дома — Linux). Вы же понимаете, что CAS-систему, состоящую на 72.2% из Common Lisp кода не станут собирать и компилировать на «плохой» реализации…
На машине с Windows использую последнюю версию SBCL(1.2.13). Полет — нормальный.
Решать Вам…
Отностительно настройки Emacs — если хотите, скачайте LispWorks и/или Allegro — отличные продукты, но, проприетарные. Но есть «бесплатные» Personal Edition (типа MS VS Express Edition...). Но, запомните, Slime + Emacs ничем не уступают коммерческим системам… Бесплатно, но долго привыкать и учиться. Такова жизнь… С Emacs и Slime Вы получите полностью настроенную (Вами) и контролируемую систему, которая работает. Она просто работает. Выбирайте…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Common Lisp IDE