Closure в 2024 достаточно эзотеричен, чтобы на него почти полностью отсутствовали вакансии. C 2007 года его много где могли попробовать, но в отличии от PHP и JavaScript, не нашлось ни одной области, где он бы обеспечил хоть какое-то преимущество над более простыми решениями.
nim и Nemerle тоже где-то пробовали. А на Lotus до сих пор что-то в каких-то компаниях работает.
В уже указанной книге написанию такого интерпретатора на Go посвящены главы Evalution и Evaluting the Interpreter. Сам автор указывает, что его реализация обхода аналогична интерпретатору из 5-ой части SICP.
Набор s-выражений здесь выстроен в AST (Abstract Syntax Tree). В принципе, никаких принципиальных отличий от Scheme нет - просто yacc позволяет сгенерировать лексер и парсер, а в лиспоподобных языках лексер и парсер - белковые (то есть это дерево строит сам программист).
Собственно, именно в этом главная проблема чисто функциональных языков программирования.
Они запрещают состояния. Но компьютер (и любая другая машина Тьюринга) и есть машина состояний. Пишем мы на жёсткий диск, выводим на экран, получаем запрос по сети, посылаем ответ - всё это состояния.
В принципе, задача решена в книге Writing an Interpreter in Go (только для Go). Там пишут JS-подобный язык (даже с макросами) и спокойно обходят эти S-выражения.
И как новый стандарт SRFI повлиял на популярность языка? Fortran тоже в 2018 году обновился.
Сравнивать в JavaScript сложнее, чем в Scheme, потому что в JavaScript не все типы сводимы к деревьям. А так-то готовые методы есть в underscore и lodash.
Вообще, JavaScript наглядно доказывает, что языки программированяи бывают двух видов: на одни все жалуются, а другими никто не пользуется. Lisp-оподобные языки были популярны как скриптовые языки в больших системах (с тех времён уцелели Emacs, Mathematica, Gimp) в те времена, когда документации было мало и разработчику приходилось работать лексером и парсером. Но почему-то как только появились Perl, а потом Python, Ruby, JavaScript и Lua, именно их, при всех недостатках, стали понимать интерпретаторы.
За 10 лет функционального ренессанса так и не случилось. А всё, что действительно было нужно, давно перенесли в мейнстримовые языки.
Возможно, в следующей статье нам расскажут про язык макросов в C.
А так, конечно, после волны скриптовых языков начала 90х всё это уже не актуально. В JavaScript уже в 2000 году были и деревья, и функции как значения и даже eval.
Ну, наоборот - нужно как раз учиться в этой области. Если ты поступаешь в университет - у тебя ещё около 6 лет до начала работы. К тому времени всё будет вообще по-другому.
Это проблема как раз для тех, кто начал слушал курсы и решил, что его и так на работу возьмут.
Могу понять даже людей, которые пишут на кроссплатформенном и Тьюринг-полном языке Brainfuck.
У меня https://clojurejobboard.com/ открылся как пустая страница.
Замечательная демонстрация продвинутости технологии и профессионализма тех, кто её использует.
ZED (из недавно вышедших) написан на Rust.
Что в нём нового по сравнению с Sublime - не очень ясно.
Там архитектура более сложная: https://chrismennie.ca/EMACS-Conceptual-Architecture.pdf
Но в том же vim макросы уже процедурные, а не LISP-поподобные.
emacs на C написан. LISP там - аналогично Python в Sublime или JavaScript в Atom, язык скриптов и дополнений.
Closure в 2024 достаточно эзотеричен, чтобы на него почти полностью отсутствовали вакансии. C 2007 года его много где могли попробовать, но в отличии от PHP и JavaScript, не нашлось ни одной области, где он бы обеспечил хоть какое-то преимущество над более простыми решениями.
nim и Nemerle тоже где-то пробовали. А на Lotus до сих пор что-то в каких-то компаниях работает.
Говоря проще, LISP - это JSON с макросами.
В уже указанной книге написанию такого интерпретатора на Go посвящены главы Evalution и Evaluting the Interpreter. Сам автор указывает, что его реализация обхода аналогична интерпретатору из 5-ой части SICP.
Набор s-выражений здесь выстроен в AST (Abstract Syntax Tree). В принципе, никаких принципиальных отличий от Scheme нет - просто yacc позволяет сгенерировать лексер и парсер, а в лиспоподобных языках лексер и парсер - белковые (то есть это дерево строит сам программист).
Можно попросить интерпретатор, чтобы он дёргал предустановленные функции из C-библиотеки. Подключить их можно, например, так: https://dev.to/metal3d/understand-how-to-use-c-libraries-in-go-with-cgo-3dbn
Собственно, именно в этом главная проблема чисто функциональных языков программирования.
Они запрещают состояния. Но компьютер (и любая другая машина Тьюринга) и есть машина состояний. Пишем мы на жёсткий диск, выводим на экран, получаем запрос по сети, посылаем ответ - всё это состояния.
В принципе, задача решена в книге Writing an Interpreter in Go (только для Go). Там пишут JS-подобный язык (даже с макросами) и спокойно обходят эти S-выражения.
Аналогично есть уже нативные:
LUA - https://crates.io/crates/mlua
JS - https://github.com/Bromeon/js-sandbox
Ну вот видите. Язык прошёл проверку временем. В отличии от Scheme.
Судя по той же таблице популярности, Scheme - это эзотерический язык где-то между Closure и Brainfuck
И как новый стандарт SRFI повлиял на популярность языка? Fortran тоже в 2018 году обновился.
Сравнивать в JavaScript сложнее, чем в Scheme, потому что в JavaScript не все типы сводимы к деревьям. А так-то готовые методы есть в underscore и lodash.
Вообще, JavaScript наглядно доказывает, что языки программированяи бывают двух видов: на одни все жалуются, а другими никто не пользуется. Lisp-оподобные языки были популярны как скриптовые языки в больших системах (с тех времён уцелели Emacs, Mathematica, Gimp) в те времена, когда документации было мало и разработчику приходилось работать лексером и парсером. Но почему-то как только появились Perl, а потом Python, Ruby, JavaScript и Lua, именно их, при всех недостатках, стали понимать интерпретаторы.
За 10 лет функционального ренессанса так и не случилось. А всё, что действительно было нужно, давно перенесли в мейнстримовые языки.
Ну, за 10 лет прошедшие с написания той заметки я несколько вырос - а Scheme неизменен с 1985 года.
Реклама такая реклама.
Названия этих многих теорем в статье стыдливо опущены
Скажем так - этот язык появился раньше Perl и с тех пор особо не развился. Никаких преимуществ перед JavaScript не обнаружено.
Эта книга может вам пригодиться только если вы станете попаданием в год эдак 1986. Тогда описанные там знания станут для вас очень актуальны.
Невероятные технологии из 1985 года.
Возможно, в следующей статье нам расскажут про язык макросов в C.
А так, конечно, после волны скриптовых языков начала 90х всё это уже не актуально. В JavaScript уже в 2000 году были и деревья, и функции как значения и даже eval.
Вам, видимо, очень повезло, раз вам поручают писать на языках, которые вы знаете плохо.
Помню, аналогичные крики когда вышел ReSharper. А ведь по сути он делал то же самое - подсказывал разработчику, что есть код и лучше.
Вот теперь о1 аналогично пихают.
Ну, наоборот - нужно как раз учиться в этой области. Если ты поступаешь в университет - у тебя ещё около 6 лет до начала работы. К тому времени всё будет вообще по-другому.
Это проблема как раз для тех, кто начал слушал курсы и решил, что его и так на работу возьмут.