Comments 5
А зачем он нужен? Что нового он даёт, чего не может дать та же Clojure и куча других lisp-подобных языков?
Видимо, авторам нравится Clojure - "функциональный Java с макросами" и они захотели "функциональный Си с макросами".
Добрый вечер,
Давайте я приведу вам сравнение с "округлением в большую сторону" -- Janet это как компилируемый Clojure.
Публикаций по Janet на Хабре еще не было, я решил, что будет полезно чтобы они были.
С такой риторикой, получается, вообще языки не нужны. Максимум ассемблер, зачем что-то еще
Нет, я вовсе не в том смысле, что этот язык не нужен. Скорее про то, что прежде чем читать большую статью про мелкие детали, хотелось бы сначала получить некоторый общий обзор с видом сверху - что за язык, в чем его смысл, и какие плюсы и минусы по сравнению с языками-конкурентами.
Поэтому и спросил, что он может дать такого, чего не дают другие языки из большой семьи lisp.
Ну статья написана достаточно полно и подробно - хороший обзор языка с рассмотрением важных сторон. Но: фич меньше чем в лиспе:
numerical tower нет,
поддержки Unicode на уровне языка нет,
куски идеологии раста с изменяемыми и неизменяемыми переменными есть, при этом отражены в синтаксисе, и ради этого использован символ @
лишние виды скобок (наследие кложуры) нарушают гомоиконность, интересно как там макросы с этим нарушением справляются
кложуровские идиомы с кортежами, таблицами и векторами (двух видов) - прибиты к синтаксису (хотя в общем случае было бы достаточно списка, в в частном ради производительности можно было бы использовать стандартные идиомы доступа, которые еще и обобщаются. Т.е. можно было бы использовать общие функции для вектора и списка и делать конкретизацию только ради тюнинга производительности или даже автоматически, опираясь на тип.
вектор отождествлен с массивом, при этом многомерных массивов нет, так что налицо другое толкование термина "массив" (это не те дроиды, которых вы ищете)
nil отделен от пустого списка и от false (что приводит к более многословной обработке особых ситуаций), но имеет право на жизнь
символы есть (но автор ссылается на руби, а не на лисп, из которого руби их унаследовал, это забавно), при этом они интернируются, но отсутстует пакетная механика, затененение и явное управление символами и их видимостью в пакете.
вариадические аргументы функции есть, взято из питона, но нет куда более мощной концепции lambda-list, при этом у автора уже начинают заканчиваться спецсимволы, уже используется даже точка с запятой, могу себе представить сколько времени ушло на отладку парсера и насколько сложным он стал..
Есть файберы, прибиты к языку, хотя в лиспе они могут быть реализованы как библиотеки
Непонятно состояние и интеропом (есть FFI?)
Проверка на равенство изолирует нас от важных деталей
Видно что автор дал себе труд разобраться PLT и лиспах, думаю для него это хорошее упражнение по реализации языка. Думаю некоторые недостатки связаны с тем, что тяжелые в реализации вещи он постарался обойти, чтобы не делать скучную работу. Влияние "современных" языков к сожалению типично для подобных упражнений, т.к. из-за синдрома утенка мы можем часто видеть "кложуру с ароматом раст", но реже видим "лисп с ароматом эрланг" - до более нетривиальных идей тяжелее доходить, а поупражняться в создании языков хочется уже сразу
Язык Janet для смертных. Часть 1 — Значения и ссылки