LINUX.ORG.RU

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


1

0

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

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

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

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

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

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

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

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

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

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



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

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 ★★★★
()
Ответ на: комментарий от archimag

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

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

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

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

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

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

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

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

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

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

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

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