Увидеть в последний раз, возможно, в этот раз не получится: язык упорно не хочет умирать, вне академического программирования встречается как язык сценариев и расширений в некоторых приложениях, в том числе весьма распространенных (GIMP, например). Думаю, одна из причин выживаемости не только в простоте разбора, но и в относительно небольшом наборе примитивов, которые являются достаточно гибкими и выразительными + практически неограниченные возможности расширения.
«AST прямо в мозг» хорошо тогда, когда вам надо с ним работать. Собственно, это и обеспечивает удобство символьных вычислений в ЯП семейства Лисп. Читать код на них, особенно бегло, особенно если не практикуешься в этом регулярно — трудно. Пробовали реализовывать «сахар» в стиле Haskell, получалось наглядно (что-то вроде псевдокода в функциональном стиле). Но, конечно, с AST его все равно приходилось работать как со списком символов.
В Scheme подход к функциям несколько отличается от Common Lisp. Не являясь знатоком последнего, могу предположить, что такое определение соответствует определению функции (процедуры) в Scheme, записанному «без сахара»:
Да, макросистема в Scheme восхитительна! Справедливости ради надо отметить, что гигиенические макросы имеются в Rust, преемственность заметна. Но, конечно, там макросы гораздо сложнее — из за куда более богатого синтаксиса языка.
Динамическая типизация — не всегда зло. В скриптах, в сравнительно небольших проектах динамическая типизация бывает удобной и способствует краткости. Существует диалект Scheme со статической типизацией — Typed Racket. Кроме того, некоторые реализации Scheme поддерживающее статическую типизацию, например, Chicken Scheme.
Современный JS по-своему хорош, гибок и выразителен. Впрочем, есть и компиляторы Scheme в JS. Сам пробовал писать компилятор Scheme в JS на Scheme же, получается достаточно кратко и красиво: лексический и синтаксический анализ не требуется, все действия выполняются со списками и символами (symbol).
Наверное, Scheme (или его диалект) для Web-программирования был бы удобен. Тут важно согласовать функциональный подход языка и объектную моделью документа.
«AST прямо в мозг» хорошо тогда, когда вам надо с ним работать. Собственно, это и обеспечивает удобство символьных вычислений в ЯП семейства Лисп. Читать код на них, особенно бегло, особенно если не практикуешься в этом регулярно — трудно. Пробовали реализовывать «сахар» в стиле Haskell, получалось наглядно (что-то вроде псевдокода в функциональном стиле). Но, конечно, с AST его все равно приходилось работать как со списком символов.
В Scheme подход к функциям несколько отличается от Common Lisp. Не являясь знатоком последнего, могу предположить, что такое определение соответствует определению функции (процедуры) в Scheme, записанному «без сахара»:
Определение в REPL, затем несколько запусков подряд. Возможно, вы правы
Да, макросистема в Scheme восхитительна! Справедливости ради надо отметить, что гигиенические макросы имеются в Rust, преемственность заметна. Но, конечно, там макросы гораздо сложнее — из за куда более богатого синтаксиса языка.
Динамическая типизация — не всегда зло. В скриптах, в сравнительно небольших проектах динамическая типизация бывает удобной и способствует краткости. Существует диалект Scheme со статической типизацией — Typed Racket. Кроме того, некоторые реализации Scheme поддерживающее статическую типизацию, например, Chicken Scheme.
Современный JS по-своему хорош, гибок и выразителен. Впрочем, есть и компиляторы Scheme в JS. Сам пробовал писать компилятор Scheme в JS на Scheme же, получается достаточно кратко и красиво: лексический и синтаксический анализ не требуется, все действия выполняются со списками и символами (symbol).
Наверное, Scheme (или его диалект) для Web-программирования был бы удобен. Тут важно согласовать функциональный подход языка и объектную моделью документа.