История изменений

Clojure и Racket - это байткод, не люблю. Или я что-то упустил? Racket только собирается перейти на Chez и пермиссивную лицензию, вот тогда и будет предмет для разговора (Монк меня давно на него сманивает). Хотя на мой взгляд, Racket монструознее чем даже CL. Фич очень много, я, например, не осилил их цикл. Мне кажется, он перефичастый по сравнению даже с loop/iterate, притом мне его дизайн странен.

что хорошо в Racket - это syntax-objects, но я в своём Яре уже их аналог давно запилил. Отсутствие syntax-objects в CL и чтение кода непосредственно в дерево весьма затрудняет отслеживание преобразований исходного текста, а без этого опять же, сложно поддерживать макросы. Т.е. если читается 42 (С), то мы не знаем, где оно прочитано - информация об этом теряется в момент чтения из файла и потом её тяжело «тянуть». Поэтому, чтобы улучшить пошаговый отладчик для SBCL, я начал патчить компилятор таким образом, который завеодомо исключает возможное затягивание последующих версий SBCL. А поскольку SBCL состоит почти полностью из багов, то без этой возможности тяжко. Так разработка пошагового отладчика зашла в тупичок. Один человек в команде SBCL признался, что они тоже хотят отладчик «как в Visual Basic». Но в том же письме написал, что примитивы для отладчика там ненадёжны и что исправлять их займёт несколько месяцев. Короче, опять всё внутри кривое. Ну что же, посмотрим, каков в этом плане CCL. Хорошо то, что CCL замер и не развивается, поэтому будет легче поддерживать форк, если понадобится.

Chez интересен, да. Но на самом деле мне не нравятся сами скобочки. Вот примерно в 2010 году я опубликовал свою proga https://bitbucket.org/budden/budden-tools/commits/6746446ddd93ec632adce44ec93... и пытался её продвигать. Меня, конечно, смешали с говном. Не прошло и 7 лет, как подобный макрос под именем nest вошёл в состав uiop и он вовсю используется в коде asdf. Жаль, что моё имя не упомянуто. Я не смог отследить, откуда взялся этот nest и понять, придумали ли его раньше меня. Хотя вообще это нормально, что нормальные идеи воплощаются через 100 лет и заслуги приписываются не исходному автору, которого смешивают с говном. Мне главное это не забывать, а то можно и приуныть.

Т.е. то, что каждый let, flet, labels порождает отдельный уровень вложенности - это просто чудовищная потеря читабельности. Я думаю, это одна из причин, по которой лиспы хронически не стреляют: нечитабельное месиво из скобок настолько затрудняет поддержку, что мы видим слабость библиотек на CL, невзирая на мощь макросов и инкрементной разработки. Я пишу свой код примерно так:

(perga
  (:lett a (+ 2 2) integer)
  (flet f (x) (* x 4))
  (:@ mlvl-bind (foo bar) (find-symbol 'foo))
  и т.п.
  )

Это читается несравнимо легче.

И кроме того, Chez был открыт спустя год после начала моего проекта. Теперь несколько поздно. Если у меня появятся дальнейшие ресурсы, то я подробно рассмотрю возможность перехода на Chez. В принципе ещё интересен Oberon. Я скачал BlackBox - он гораздо более развит, чем SLIME. Есть врождённый гуй, к примеру, а в CL его нет по сей день. Но там замена может быть только на уровне модулей. Сообщество Oberon гораздо более живое, чем CL, думаю, я мог бы найти соратников. Кроме того, он чертовски компактен.

Clojure и Racket - это байткод, не люблю. Или я что-то упустил? Racket только собирается перейти на Chez и пермиссивную лицензию, вот тогда и будет предмет для разговора (Монк меня давно на него сманивает). Хотя на мой взгляд, Racket монструознее чем даже CL. Фич очень много, я, например, не осилил их цикл. Мне кажется, он перефичастый по сравнению даже с loop/iterate, притом мне его дизайн странен.

что хорошо в Racket - это syntax-objects, но я в своём Яре уже их аналог давно запилил. Отсутствие syntax-objects в CL и чтение кода непосредственно в дерево весьма затрудняет отслеживание преобразований исходного текста, а без этого опять же, сложно поддерживать макросы. Т.е. если читается 42 (С), то мы не знаем, где оно прочитано - информация об этом теряется в момент чтения из файла и потом её тяжело «тянуть». Поэтому, чтобы улучшить пошаговый отладчик для SBCL, я начал патчить компилятор таким образом, который завеодомо исключает возможное затягивание последующих версий SBCL. А поскольку SBCL состоит почти полностью из багов, то без этой возможности тяжко. Так разработка пошагового отладчика зашла в тупичок. Один человек в команде SBCL признался, что они тоже хотят отладчик «как в Visual Basic». Но в том же письме написал, что примитивы для отладчика там ненадёжны и что исправлять их займёт несколько месяцев. Короче, опять всё внутри кривое. Ну что же, посмотрим, каков в этом плане CCL. Думаю, команда там не лучше, но хорошо хотя бы то, что CCL замер и не развивается, поэтому будет легче поддерживать форк, если понадобится.

Chez интересен, да. Но на самом деле мне не нравятся сами скобочки. Вот примерно в 2010 году я опубликовал свою proga https://bitbucket.org/budden/budden-tools/commits/6746446ddd93ec632adce44ec93... и пытался её продвигать. Меня, конечно, смешали с говном. Не прошло и 7 лет, как подобный макрос под именем nest вошёл в состав uiop и он вовсю используется в коде asdf. Жаль, что моё имя не упомянуто. Я не смог отследить, откуда взялся этот nest и понять, придумали ли его раньше меня. Хотя вообще это нормально, что нормальные идеи воплощаются через 100 лет и заслуги приписываются не исходному автору, которого смешивают с говном. Мне главное это не забывать, а то можно и приуныть.

Т.е. то, что каждый let, flet, labels порождает отдельный уровень вложенности - это просто чудовищная потеря читабельности. Я думаю, это одна из причин, по которой лиспы хронически не стреляют: нечитабельное месиво из скобок настолько затрудняет поддержку, что мы видим слабость библиотек на CL, невзирая на мощь макросов и инкрементной разработки. Я пишу свой код примерно так:

(perga
  (:lett a (+ 2 2) integer)
  (flet f (x) (* x 4))
  (:@ mlvl-bind (foo bar) (find-symbol 'foo))
  и т.п.
  )

Это читается несравнимо легче.

И кроме того, Chez был открыт спустя год после начала моего проекта. Теперь несколько поздно. Если у меня появятся дальнейшие ресурсы, то я подробно рассмотрю возможность перехода на Chez. В принципе ещё интересен Oberon. Я скачал BlackBox - он гораздо более развит, чем SLIME. Есть врождённый гуй, к примеру, а в CL его нет по сей день. Но там замена может быть только на уровне модулей. Сообщество Oberon гораздо более живое, чем CL, думаю, я мог бы найти соратников. Кроме того, он чертовски компактен.

Clojure и Racket - это байткод, не люблю. Или я что-то упустил? Racket только собирается перейти на Chez и пермиссивную лицензию, вот тогда и будет предмет для разговора (Монк меня давно на него сманивает). Хотя на мой взгляд, Racket монструознее чем даже CL. Фич очень много, я, например, не осилил их цикл. Мне кажется, он перефичастый по сравнению даже с loop/iterate, притом мне его дизайн странен.

что хорошо в Racket - это syntax-objects, но я в своём Яре уже их аналог давно запилил. Отсутствие syntax-objects в CL и чтение кода непосредственно в дерево весьма затрудняет отслеживание преобразований исходного текста, а без этого опять же, сложно поддерживать макросы. Т.е. если читается 42 (С), то мы не знаем, где оно прочитано - информация об этом теряется в момент чтения из файла и потом её тяжело «тянуть». Поэтому, чтобы улучшить пошаговый отладчик для SBCL, я начал патчить компилятор таким образом, который завеодомо исключает возможное затягивание последующих версий SBCL. А поскольку SBCL состоит почти полностью из багов, то без этой возможности тяжко. Так разработка пошагового отладчика зашла в тупичок. Не стоит и говорить, что команда в SBCL элитная и ей, конечно, пошаговый отладчик не нужен. Ну что же, я проголосовал против SBCL ногами, как и многие другие люди до меня. Посмотрим, каков в этом плане CCL. Думаю, команда там не лучше, но хорошо хотя бы то, что CCL замер и не развивается, поэтому будет легче поддерживать форк, если понадобится.

Chez интересен, да. Но на самом деле мне не нравятся сами скобочки. Вот примерно в 2010 году я опубликовал свою proga https://bitbucket.org/budden/budden-tools/commits/6746446ddd93ec632adce44ec93... и пытался её продвигать. Меня, конечно, смешали с говном. Не прошло и 7 лет, как подобный макрос под именем nest вошёл в состав uiop и он вовсю используется в коде asdf. Жаль, что моё имя не упомянуто. Я не смог отследить, откуда взялся этот nest и понять, придумали ли его раньше меня. Хотя вообще это нормально, что нормальные идеи воплощаются через 100 лет и заслуги приписываются не исходному автору, которого смешивают с говном. Мне главное это не забывать, а то можно и приуныть.

Т.е. то, что каждый let, flet, labels порождает отдельный уровень вложенности - это просто чудовищная потеря читабельности. Я думаю, это одна из причин, по которой лиспы хронически не стреляют: нечитабельное месиво из скобок настолько затрудняет поддержку, что мы видим слабость библиотек на CL, невзирая на мощь макросов и инкрементной разработки. Я пишу свой код примерно так:

(perga
  (:lett a (+ 2 2) integer)
  (flet f (x) (* x 4))
  (:@ mlvl-bind (foo bar) (find-symbol 'foo))
  и т.п.
  )

Это читается несравнимо легче.

И кроме того, Chez был открыт спустя год после начала моего проекта. Теперь несколько поздно. Если у меня появятся дальнейшие ресурсы, то я подробно рассмотрю возможность перехода на Chez. В принципе ещё интересен Oberon. Я скачал BlackBox - он гораздо более развит, чем SLIME. Есть врождённый гуй, к примеру, а в CL его нет по сей день. Но там замена может быть только на уровне модулей. Сообщество Oberon гораздо более живое, чем CL, думаю, я мог бы найти соратников. Кроме того, он чертовски компактен.