LINUX.ORG.RU

Lisp, Haskell, Smalltalk, Forth... что дальше?


1

0

Навеяно предыдущей темой.

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

Факел был когда-то зажжен незабвенным Проффессором Луговскером, и достался он лиспу. Прошло несколько лет, и теперь даже самый распоследний нубас на ЛОРе расскажет вам про REPL, метапрограммирование, квазиквотацию, eval, Slime и про жаба-monkey-кодеров. Лисп стал популярен на ЛОРе, и утратил позиции «элитного» языка, дискутировать о котором могли единицы.

Ниша долго не пустовала. Некоторое время факел находился у Haskell, а последние месяцы его гордо несет Smalltalk (я сужу исключительно по количеству новостей и дискуссий о нем). Но теперь завзятые маргинальщики начинают интересоваться Forth'ом, из чего я делаю вывод о том, что факел Smalltalk'а начал коптить, в силу его популяризации на ЛОРе.

Предлагаю коллективно поразмыслить над тем, какой язык мог бы принять эстафету у Форта. Из маргинальных неэзотерических языков осталось не так уж и много. Clean? Pure? Factor?

★★

Ответ на: комментарий от Laz

> Неужто стандартизованный CL по-разному работает на разных реализациях?

Естественно, ведь CLISP это интерпретатор, а значит не может быть быстрым.

Или, может, стандарта не хватает для работы, приходится использовать

несовместимые фичи разных реализаций?



Интересно, а для работы с каким языком достаточно одного стандарта?

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

Неужто стандартизованный CL по-разному работает на разных реализациях?
Или, может, стандарта не хватает для работы, приходится использовать несовместимые фичи разных реализаций?

«Стандартизированный», конечно, работает везде одинаково, а вот не стандартизированный (фактически - весь real world, т.е. детали вроде интерпретация/компиляция, много-поточность, поддержка разных ОС и т.д.) - по-разному.

Грэхем при написании ViaWeb ориентировался на решение в духе «интерпретируемый-быстрый» чуть ли не «скриптовый» CL, а это и был CLisp. Однако, как оказалось, это было неверное направление - в дальнейшем бОльшее развитие получили компиляторы. CCL используется в коммерческих организациях, CMUCL форкнулся в самый «народный» SBCL и, коммерческий опять же, Sciener (или как его там). Ну и ещё есть коммерческие реализации AllegroCL и LispWorks. Это всё компиляторы.

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

> Цитировать нужно правильно. «Одинаково плохо подходящий для решения

абсолютно всех задач»


Вы отдаете себе отчёт в том, что утверждаете это сразу об очень многих языках, например, о C++, Java, Python и т.д.?

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

Выбор CLISP скорей всего был обусловлен тем, что приложение работало в режиме cgi.

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

>> Или, может, стандарта не хватает для работы, приходится использовать несовместимые фичи разных реализаций?

Интересно, а для работы с каким языком достаточно одного стандарта?

Я говорил не о недостаточности одного стандарта, а о том, что приходится использовать особенности конкретных реализаций. У C стандарта явно не хватит для всего и вся, но тем не менее даже тут, на лоре, многие рассказывают, что собирают всё исключительно с -pedantic-errors. А когда и программа, и все используемые ей библиотеки укладываются в рамки стандарта, они переносимы между компиляторами, его реализующими. А что не позволяет перенести программу с медленного clisp на sbcl (ну или какая в то время была более быстрая реализация)?

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

> А что не позволяет перенести программу с медленного clisp на sbcl

SBCL долго стартует, а его стартовый образ занимает довольно много памяти - он не может использоваться для cgi, только в роли сервера приложений. Конечно, при желании, можно как и в С использовать нестандартные расширения, но это, как и в С, остаётся на совести разработчика.

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

>> А что не позволяет перенести программу с медленного clisp на sbcl

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


SBCL я только для примера упомянул. Я придираюсь к утверждению, что использование clisp в качестве реализации программы Грэма было минусом. И спрашиваю, почему нельзя было её перенести на более быструю (подходящую под условия задачи) реализацию? Потому что других реализаций не было? Или потому что не были соблюдены стандарты?

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

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

ecl не? gcl как его предок местами мертв кроме матпрограм. Но на тот момент вроде уже или еще был.

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

> Естественно, ведь CLISP это интерпретатор, а значит не может быть быстрым.

Ну во-первых, не интепретатор, а компилятор в байт-код. Есть все же некоторая разница. Во-вторых CLISP согласно документации умеет компилировать и в С-код тоже. Я не сторонник CLISP, но правды ради.

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

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

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

> Грэхем при написании ViaWeb ориентировался на решение в духе «интерпретируемый-быстрый» чуть ли не «скриптовый» CL, а это и был CLisp.

Если не изменяет память, то по словам самого Грэхема, он ориентировался на скорость ввода-вывода. И на тот момент лучшим был именно CLISP, прибитый гвоздями к С.

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

В общем, это было криво, поэтому и переписал. Впрочем, кривизна вполне понятна, учитывая время разработки - в том время ещё было очень мало опыта разработки веб-приложений.

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

Вдогонку.

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


это плохо или банальная зависть?


Это не хорошо и не плохо, просто успешная коммерциализация абсолютно не коррелирует с качествами языка. И поэтому посылка «Franz зашибает бабло ⇒ лисп крут» неверна.

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

Если не изменяет память, то по словам самого Грэхема, он ориентировался на скорость ввода-вывода.

И на тот момент лучшим был именно CLISP, прибитый гвоздями к С.

Об этом трудно судить без сорсов, т.е. только со слов самого Грэхэма. Если там были foreign сишные дескрипторы и alien функций для обеспечения IO с ними, то возможно, да и то - на CMUCL те же foreign/aliens можно было сделать точно также. Ну а если там были «стандартные» gray-streams, то IO для них осуществляется с помощью диспечерезируемых методов CLOS - тут интерпретатор ну никак не может обогнать компилятор, тем более CMUCL с его effective dispatching.

Кстати Грэхем говорил что они «вдвоём с приятелем ... только и умели что писать на Лисп ... поэтому решили делать систему на ...» - кто этот второй человек?))

Ну что, ViaWeb как бы то ни было - пример удачного применения СL в качестве CGI технологии.

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

> которые не должны попасть в чужую секту...

я так и знал :)

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

(удачного) или нашумевшего, Грэхэм, всё-таки, отличный публицист :)

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

> Ну извините, вы тут жонглируйте терминами. «общего назначения» и «хорошо подходящий для решения абсолютно всех задач» - разные вещи

Расскажите это лучше самим лисперам.

Вы, право, словно первый день на ЛОРе. Да загляните в любой лиспосрач! Там у лисперов спрашивают: «где ОС / СУБД / КИС / десктопный софт / игры и т.п., написанные на лиспе?» Ответ неизменен: «это все есть, и гораздо лучше сишных/жабьих», а далее в двух вариантах: "...но вам, быдлу, никто этого не покажет", либо "...но это все маркетоиды, масоны, бендерцы да петлюрцы, злые люберы да негры, узурпировали рынок потребительского сОфта".

А, еще бывает такой ответ: «А зачем это все? Это не нужно, поэтому на лиспе и не пишут». Точно как БЗДуны, когда их спросят, почему BSD до сих пор не поддерживает журналирования.

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

> чего же маргинального в изучении(и возможно использовании) коммон лиспа, хаскеля, форта или смолтолка?

матлаб ... гораздо большая маргинальщина


Как было отмечено выше, маргинальщина - она не в языке, а в головах.

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

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

> Об этом трудно судить без сорсов, т.е. только со слов самого Грэхэма. Если там были foreign сишные дескрипторы и alien функций для обеспечения IO с ними, то возможно, да и то - на CMUCL те же foreign/aliens можно было сделать точно также. Ну а если там были «стандартные» gray-streams, то IO для них осуществляется с помощью диспечерезируемых методов CLOS - тут интерпретатор ну никак не может обогнать компилятор, тем более CMUCL с его effective dispatching.

Я конечно зануда, но повторю. Не интерпретатор, умеет компилировать в С-код. И были ли gray-streams в те седые времена?

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

> Неужто стандартизованный CL по-разному работает на разных реализациях?

Вы смеетесь? Пощадите бедных лисперов :)

У них даже такая примитивная вещь как разбор аргументов командной строки реализована по-разному во всех имплементациях CL (поэтому приходится городить костыли наподобие [url=http://cl-cookbook.sourceforge.net/os.html]такого[/url]).

Впрочем, сейчас они вам ответят, что «вы не понимаете, командная строка не нужна, лисп вообще работает другим образом». Но фактов это не изменит: если несовместимость есть в таких мелочах, то чего уж говорить о вещах более серьезных?

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

> SBCL долго стартует, а его стартовый образ занимает довольно много памяти - он не может использоваться для cgi, только в роли сервера приложений.

В этом весь лисп.

«Он работает по-другому», поэтому ему сначала нужны свой сервер приложений, потом окажется, реляционные СУБД тоже работают не так, как надо - потребуется свое решение для обработки данных, потом выяснится, что и ОС неподходящая - нужна LISP OS, которая заработает, естественно, только на LISP Machine.

И после этого лисп - язык общего назначения?

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

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

Если вы еще не поняли - я против любого cектантства. Я - за адекватноcть, трезвомыcлие и неконъюнктурность при выборе, изучении и использовании языков программирования.

И исли вы видите в этом признак cектантства, то разрешаю вам персонально называть меня Одептом Cекты Адеквaтов :)

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

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

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

> В общем, это было криво, поэтому и переписал. Впрочем, кривизна вполне понятна, учитывая время разработки - в том время ещё было очень мало опыта разработки веб-приложений.

Единственное rrrеволюционное (на ту пору), что присутствовало в Viaweb - использование динамического языка для быстрого и грязного прототипирования веб-приложения. Молодцы ребята - набросали вдвоем прототип, да и загнали его крупной конторе, пускай дальше переписывает в нормальных технологиях.

Сейчас таким образом поступает 99% так называемых «Web 2.0 стартапов», только в качестве языков прототипирования - Python и особенно Ruby. А Грэхем с ребятками просто впервые додумались до этого, за что их нельзя не уважать.

Впрочем, если мне не изменяет память, уже тогда был нетскейповский Phobos (server-side JavaScript), но JavaScript тогда был еще в зародышевом состоянии как язык.

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

>форт

маниакально пытаются засунуть в каждую дырку

Ну это откровенная неправда. Фортисты сами говорят, что форт подходит не везде. Да и за смоллтолкерами я подобной маниакальности не замечал.

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

> У каждого человека свое здравомыслие, и если он подрывается на ваши лозунги, то значит здравомыслия у него нет...

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

Если хотите, в некотором приближении тому же самому учат в университетах.

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

> Фортисты сами говорят, что форт подходит не везде.

man Love5an

> Да и за смоллтолкерами я подобной маниакальности не замечал.

man yoghurt

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

> Я говорил не о недостаточности одного стандарта, а о том, что приходится использовать особенности конкретных реализаций. У C стандарта явно не хватит для всего и вся, но тем не менее даже тут, на лоре, многие рассказывают, что собирают всё исключительно с -pedantic-errors. А когда и программа, и все используемые ей библиотеки укладываются в рамки стандарта, они переносимы между компиляторами, его реализующими. А что не позволяет перенести программу с медленного clisp на sbcl (ну или какая в то время была более быстрая реализация)?

Даже в С потоки и сеть не стандартизированы (насколько я знаю). Стандарт CL покрывает только сам язык без средств взаимодействия с ОС. FFI, сеть, нити, mop унифицируются внешними библиотеками. Но они начали развиваться в 2004-2006 гг. Вместе с приходом серьезных открытых реализаций, SBCL (имхо) прежде всего. Практически с этих лет идет вторая волна Лиспа, основанная на прежнем стандарте, но с новыми компиляторами и библиотеками. Посути второе рождение и новый язык. В таком разрезе лисп очень молодой язык и еще многое успеет. Ну а стортапы при покупке по-моему часто переписывают, плбс еще смена архитектруры накладывется.

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

> У них даже такая примитивная вещь как разбор аргументов командной строки реализована по-разному во всех имплементациях CL (поэтому приходится городить костыли наподобие [url=http://cl-cookbook.sourceforge.net/os.html]такого[/url]).

Особенно забавно, что ты (ну или вы :))) за годы троллизма-антилиспа смог найти только этот аргумент.

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

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

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

С каких пор Love5an стал фортистом?

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

anonymous
()

Просто недавно на code project ссылку давали про Форт на Лиспе, вот все и возбудились по новой.

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

> за годы троллизма-антилиспа смог найти только этот аргумент.

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

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

> на лиспе можно взять любой алгоритм из Кнута и дословно переписать в эффективный код.

... который не поймет и сам Кнут.

где же тут маргинальшина?

Все write-only языки маргинальны. Кроме Перла, по каким-то извращенным причинам.

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

> да это дебил-недотролль какой-то

Переход на личности несомненно означает, что мои стрелы достигли цели, а у вас, наоборот, стрел не осталось.

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

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

> Лисп - язык с изменяемым синтаксисом;

Лисп - язык с изменяемой семантикой;

Не осилишь ли объяснить, почему это мифы?

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

> смог найти только этот аргумент.

Несовместимость реализаций Common Lisp - недостаточный аргумент?

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

> не достигают своей цели (имхо). И вы, как обычно, выглядите троллем

Что ж, Франческо «Джордано» Бруно тоже плохо кончил. Человечество не меняется.

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

> Вот скажите, каким способом проще строить DSL - вышеописанным, как в лиспе? Или же все-таки скормить EBNF ANTLR'у?

В Лиспе проще. Что ты с AST от antlr потом делать будешь?

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

> Не осилишь ли объяснить, почему это мифы?

Выше была важная поправка: это мифы в том смысле, что это уникальные фичи лиспа. Сейчас углубляться не собираюсь, по причинам, опять-таки описанным выше (ждите отдельных публикаций на эту тему).

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

> В Лиспе проще. Что ты с AST от antlr потом делать будешь?

Обходить при помощи как DOM-like, так и event-driven API.

А в лиспе?

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

Ну пока еще не стал.

Скажу по секрету - и не станет :)

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

Повторю, забавно то что ты смог найти только несовместимость в редко используемых ключах ком. строки. Для тех кто не в курсе, поясню что компиляция и загрузка идет другими способами (обычно единообразно через ASDF) а загрузка самого лиспа в стиле *CL |имя образа|. Поэтому эти самые параметры последняя по необходимости вещь. И тоже кстати нифицируется, если это критично.

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

ждите отдельных публикаций на эту тему

откроете свою редакцию по сабжу?

//

Про несовместимость реализаций - бред. Если что - могу развернуть.

\\

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

Ты думаешь, это единственная несовместимость? Тут где-то не так давно было обсуждение несовместимости, касающейся стандартных в/в-потоков. Или потоки тоже не нужны?

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

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