LINUX.ORG.RU
Форум — Development  

Главная Проблема Лиспа


1

7

Надо признать, я солидарен с вот этим постингом в том, какая проблема у лиспа(и у Common Lisp в частности) на текущий момент является ключевой, и какая отталкивает от него разработчиков.

Проблема эта - библиотеки. Это одновременно и хорошо, и плохо. Хорошо потому, что другим проблем, в принципе, нет, а эта - решаема, а плохо потому, что все таки проблема стоит довольно остро, и решить ее довольно сложно, и более того, она порождает своеобразный замкнутый круг - на лиспе не пишут потому, что мало библиотек, а мало библиотек потому, что никто их особо не пишет.

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

Взять вот такую простенькую, даже тупую, программку - GUI-морда к БД. На C# написать ее не составило совершенно никакого труда, и заняло это пару часов от силы. Но если попытаться сделать то же самое на лиспе, окажется что сделать это не так уж и просто - будет очень не хватать WPF, очень не хватать Entity Framework, да и даже банального интерфейса к ОС(для того чтобы сделать программу синглтоном). И это не говоря уже про Visual Studio и прочие инструменты типа Expression Blend, которые очень сильно упрощают разработку GUI и подобного.

Так к чему этот постинг вообще? Пишите библиотеки для лиспа, вот к чему! Я вот твердо уверен, будь у CL столько же библиотек, как у .NET, или, тем более, Java, то последними бы никто почти не пользовался.

http://love5an.livejournal.com/366931.html

← [Common Lisp][интеграция] Аналог JMS для лиспа.
dialog(1) во время старта системы →
 ← 1 2 3 4

((Скобочки (что ли)?) (Пост не читал.))

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

(Как (такое (может)) (быть) (достоинством (?)))

«как можно жить в обществе без цветовой дифференциации штанов?» (с)

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

1. к этому быстро привыкаешь и перестаешь замечать

2. затраты на парсинг нулевые, поэтому лисп-образные dsl пишутся тривиально, особенно на самом лиспе

Reset ★★★★★
()

>Главная Проблема Лиспа

ГПЛ? При чём тут GPL?

// Дальше заголовка не читал.

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

> 1. к этому быстро привыкаешь и перестаешь замечать

Если вставить в жопу кактус, то к этому тоже быстро привыкаешь и перестаешь замечать.

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


А редакторы, отладчики, профилировщики для них пишутся сами собой, из астрала при помощи бабочек?

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

А редакторы, отладчики, профилировщики для них пишутся сами собой, из астрала при помощи бабочек?

конечно, это же лисп, а не какое-нибудь говно типа плюсов :)

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

Типа, нормальный человек видит всё как есть, а лиспер видит прекрасное?

Один довольно знаменитый политзэк писал в мемуарах:

До чего прекрасные скульптуры создаются в нужнике из мочи на морозе! Бесконечное разнообразие сосулек-сталактитов. Жёлтые — от тех, кто пьёт чифир; зелёные — от тех, кто страдает нефритом; красные — от тех, у кого отбиты почки...

Мораль: можно найти прекрасное даже в говне (в нашем случае — в моче). Если больше не в чем искать прекрасное, ага.

anonymous
()

Главная проблема лиспа - это лично ты!

Потому что печатаешь говно... [почти(c)]

Библиотек мало, да. Но не потому, что их некому написать, просто они не нужны. Хочешь ваять мордочку к базе - валяй, пиши на предназначенном для этого дотнетике. Лисп для другого, и везде он не нужен.

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

1 - это легко обрабатываемые данные(можно использовать макросы)

2 - чёткая структуризация (наглядная вложенность)

3 - простая схема - («что делаем» «с чем делаем»)

4 - можно сделать любой синтаксис, так что субъективное мнение «много скобок - лень привыкнуть» не катит (следует из 1)

pseudo-cat ★★★
()
Ответ на: комментарий от Reset

> затраты на парсинг нулевые, поэтому лисп-образные dsl пишутся тривиально, особенно на самом лиспе

А что, в DSL главные затраты - это парсинг? :D

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

не главные, но довольно ощутимые, особенно когда dsl затачивают не под задачу, а под пользователя

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

> Судя по картинке лисперу пора к офтальмологу :)

Судя по картинке, лисперу пора к психиатору. Скобочек он не видит, зато слова Beauty летают вокруг. Сенсорные галлюцинации — это серьёзно, между прочим.

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

Когда программист говорит, что в у языка неудобный синтаксис потому, что в нем много скобочек... ГСМ, что можно сказать...

kermzyxer ★
()

С липсом знаком только по манам и примерам, но ППКС.

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

В каких областях он удобнее C/C++/Java

Гибче процесс разработки из-за наличия REPL и возможности изменения в живом образе запущенной программы практически всего. К очевидному профиту CL классически относят сверхоблегчённый процесс кодогенерации прямо из лиспопрограммы.

.NET

Если имелся в виду C#, то см. выше.

Python

CL штатно компилируется, базовый язык мегастабилен (программа, написанная на ANSI CL 15 лет назад, работает и сегодня под любой ANSI CL-совместимой системой), имеется несколько очень серьёзных и высококачественных коммерческих имплементаций с поддержкой, больше всякоразных фич. Но уже ближе.

mv ★★★★★
()

Предлагаю удалять темы про скобочки в LISP, так как они затрагивают религиозные чувства верующих!

bioreactor ★★★★★
()

Возникает ощущение, что love5an кроме C# ничего не знает, и, соответственно, ему в любом языке будет очень не хватать WPF и Entity Framework.

static_lab ★★★★★
()
Ответ на: Главная проблема лиспа - это лично ты! от staseg

> Библиотек мало, да. Но не потому, что их некому написать,

просто они не нужны


Да не, библиотеки очень нужны, а вот писать их действительно некому ( И проблема не в малом количестве библиотек, а в том что их некому писать.

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

> На ЛОРе одни неграмотные тролли. Иногда, мне хочется самозабаниться =(

Не сдерживай себя. Одним неграмотным троллем станет меньше.

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

> А почему их некому писать?

Потому что язык привлекает мало вменяемых разработчиков. Ситуация меняется, но медленно.

archimag ★★★
()

У Лиспа две проблемы: первая — альтернативно адекватные Лисперы, вторая — Коммон Лисп головного мозга.

Поэтому, вероятность встретить адекватного лиспера без КЛГM стремится к нулю. И вообще, это скорее исключение.

Кстати говоря, сообщество Scheme и cообщество Clojure стремится всеми правдами и неправдами от КЛ и лиспа отстраниться, хотя все они — Лисперы. По той же самой причине.

Право слово, достало уже слушать про кодогенерацию, REPL и макросы.

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

> Коммон Лисп головного мозга.

Расскажите пожалуйста подробнее, что такое и чем опасно.

достало уже слушать про кодогенерацию, REPL и макросы.


А ещё про CLOS/MOP, conditions, динамические переменные и прочее. А про что вам было бы интересно послушать?

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

> достало уже слушать

Вот интересно, однако, скажем, когда подымается какая-то тема про Haskell, то я туда уже давно не лезу, ну просто не интересно. Вы же пишите во все темы про CL. Мышки плакали и кололись, но всё равно если кактус?

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

>то я туда уже давно не лезу, ну просто не интересно

Во-первых, «врага нужно знать в лицо».
Во-вторых, лиспосрачи — православны (кроме шуток, много чего полезного оттуда было вынесено).
В-третьих, пока еще интересно. Пройдет со времененм.

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

В схемах такой разброс и шатание, что КЛ и не снилось. Фактически, если писать на Схеме, то нужно прибиваться гвоздями к одной имплементации и самым жёстким образом использовать её непортабельные фичи.

Почему Кложура популярна - непонятно. Может быть, отсутствие вменяемого CL для jvm сыграл свою роль. И, ЕМНИП, для jvm несколько напряжно реализовать эффективный CL.

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

>А про что вам было бы интересно послушать?

Про параллельность/конкурентность. Про поддержку юникода. Про FFI. Про работу с типизированными структурами данных. Про паресеры. Про языковые средства, позволяющие разрабатывать большие проекты. Про пакетные менеджеры/системы автоматизированной сборки.

Да много про чего...

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

>если писать на Схеме, то нужно прибиваться гвоздями к одной имплементации

Ну на практике и в CL дела обстоят не лучшим образом. Тем более некоторые нужные фичи (типа юникода, параллельности/конкурентности и FFI) в изначальную спецификацию не входили... Кроме того, реализаций-то у CL... Раз, два, и нету.

Почему Кложура популярна - непонятно.

ИМХО из-за харизмы и предельной адекватности ее автора. А может быть из-за хорошего сайта. А может быть из-за доступности различных библиотек.

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

> Да много про чего...

Ну да что же не спрашиваете?

Про параллельность/конкурентность.


В стандарте не предусмотрена. Реализации предоставляет достаточно типовой набор средств. bordeaux-threads предоставляет унифицированный интерфейс к средствам реализаций. Ничего примечательного.

Про поддержку юникода.


Ну про это можно забыть. В том плане, что в ведущих реализациях ничего другого и нет. Unicode inside. Настоящий, а не кривой как в Java. Об это не надо даже думать, он просо работает.

Про FFI.


CFFI обеспечивает очень хороший интерфейс к FFI конкретных реализаций. Сам FFI обычно очень приятный. Скажем, я писал XSLT-расширения для libxml2 на CL прямо в REPL.

Про работу с типизированными структурами данных.


Динамическая типизация же, что именно интересно?

Про паресеры.


Про парсеры? esrap уделывает parsec, по любому.

Про языковые средства, позволяющие разрабатывать большие проекты.


Стандарт CL разрабатывался именно для больших проектов. Что именно интересно?

Про пакетные менеджеры/системы автоматизированной сборки.


А нужны? Впрочем, смотрите XCVB.

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

Ну на практике и в CL дела обстоят не лучшим образом.

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

Тем более некоторые нужные фичи (типа юникода, параллельности/конкурентности и FFI) в изначальную спецификацию не входили...

That's right. Но названные фичи стандартны по своей сути (треды кругом на pthreads, FFI для posix), поэтому особо отличающихся реализаций этих фич не сделаешь.

Кроме того, реализаций-то у CL... Раз, два, и нету.

Ну тоже неправда. Из бесплатных sbcl, clisp, ccl достаточно ровно в библиотеках поддерживаются. Есть all-in-one платные комбайны. На лисповой планете abcl'щики активно флудят, но я его лично не пробовал.

mv ★★★★★
()

>Я вот твердо уверен, будь у CL столько же библиотек, как у .NET, или, тем более, Java

clojure же

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

Если вставить в жопу кактус, то к этому тоже быстро привыкаешь и перестаешь замечать.

Вот почему Вы не залогинились ))).

dnoskov ★
()

love5an троллящий против CL - это нечто.

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

> Оффтоп Фамилия автора поста и ваш ник - совпадение?

:) да, забавное совпадение, никогда не обращал внимания. А вы что подумали?

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

> В схемах такой разброс и шатание, что КЛ и не снилось.

А R⁶RS на что?

Может быть, отсутствие вменяемого CL для jvm сыграл свою роль.


ABCL?

И, ЕМНИП, для jvm несколько напряжно реализовать эффективный CL.


Почему? начиная с 7-ки есть invokedynamic

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

Судя по картинке не-лисперу надо было прийти к офтальмологу лет пять назад.

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

А R⁶RS на что?

В R7RS всё встанет на свои места: базовый язык, который все поддерживают, и библиотеки, которые как попало поддерживают ;)

ABCL?

ABCL только в этом году стал более-менее живым.

Почему? начиная с 7-ки есть invokedynamic

Да там дело не в этом. Например, какой в jvm есть механизм для прозрачной передачи multiple values из функции? Или как КЛевские рестарты там сделать?

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

> В R7RS всё встанет на свои места: базовый язык, который все поддерживают, и библиотеки, которые как попало поддерживают ;)

Очень надеюсь дожить до той поры :) учитывая неторопливость Scheme Steering Committee...

Например, какой в jvm есть механизм для прозрачной передачи multiple values из функции?


Ну, функции-то они и в лиспе возвращают не multiple values, а cons-списки, так что как-нибудь да можно

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

Ну, функции-то они и в лиспе возвращают не multiple values, а cons-списки, так что как-нибудь да можно

Функции в CL возвращают values.

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4
← [Common Lisp][интеграция] Аналог JMS для лиспа.
Development
dialog(1) во время старта системы →