Как встраиваемый язык—отличная штука. Но года три назад с документацией было все очень плохо, из-за чего приходилось проводить кучу времени у них в исходниках.

ECL также может легко встраиваться в приложения написанные на других языках

Интересно как он в этом плане по сравнению с guile?

А если по-честному, у него есть пользователи? :-)

Если твой критерий выбора «количество пользователей», то выбирай похапе — не прогадаешь, гарантия 146%.

Жаль, что эти все крутые быстрые компилируемые и встраиваемые «настоящие» штуки больше никому не нужны, теперь у нас есть сраные электрон и жабаскрипт + необходимость продавать новые процессоры с миллиардами операций в секунду и гигабайтами памяти. Больше уже никто не будет писать быстрый, оптимизированный софт, одно дерьмо будет клепаться на «веб-технологиях».

Linux, FreeBSD, OpenBSD, NetBSD, OSX, Windows MSVC, Windows MinGW, Windows Cygwin, Android и Haiku

Сколько труда

Если твой критерий выбора «количество пользователей», то выбирай похапе — не прогадаешь, гарантия 146%.

Мой критерий выбора технологии - заинтересованность пользователей, для которых я работаю :-) Если я делаю data mining для кого-то, то зачем мне тормозной ECL? :-) Если я пишу приложение на цепепе для кого-то, то зачем клиенту встроенный ECL? :-) Вряд ли он обрадуется тому, что для расширения его программы (написания скриптов) ему нужно освоить Common Lisp :-)

В связи с этим вопрос «зачем нужен ECL» (не считая хобби и любовь к Лиспу) остаётся открытым :-)

Жаль, что эти все крутые быстрые компилируемые и встраиваемые «настоящие» штуки больше никому не нужны

Есть намного более крутая, быстрая, компилируемая и тоже встраиваемая штука под названием Racket :-) И что самое главное - современная и нужная :-)

Сколько труда

Ага, только для кого? :-) Лол :-)

заинтересованность пользователей, для которых я работаю

зачем нужен ECL

Так тяжело сложить 2 + 2? Ежу понятно, что тебе и твоим пользователям ненужно. Дальше что? Если не докажешь принципиальную ненужность ECL - ходишь как обосранный? Это какая-то патологическая зависимость...

Например, для меня.

Так тяжело сложить 2 + 2? Ежу понятно, что тебе и твоим пользователям ненужно. Дальше что?

Ты же за дискуссией следи :-) Вот вопрос:

Если твой критерий выбора «количество пользователей», то выбирай похапе — не прогадаешь, гарантия 146%.

А вот ответ:

Мой критерий выбора технологии - заинтересованность пользователей, для которых я работаю :-)

Если не докажешь принципиальную ненужность ECL - ходишь как обосранный? Это какая-то патологическая зависимость...

Ты сейчас доказываешь ненужность форумов? :-) У меня нет цели доказывать ненужность ECL :-) Есть желание порассуждать вслух :-) Или для чего форумы вообще? :-)

Например, для меня.

А что у тебя за потребность в ECL? :-) Не реально интересно :-) А то опять всё покрыто тайной, как и всегда вокруг Лиспа :-)

ECL также может легко встраиваться в приложения написанные на других языках

Интересно как он в этом плане по сравнению с guile?

Хреново. Guile самодостачный интерпретатор типа питона. Что удобно для скриптов. А ECL хочет С-шный компилятор в системе. Интерпретатор тоже есть но в основном для отладки скомпилированого же кода.

Он встраиваемый в том смысле что может подключаться к внутреностям сложновыебнутых C/C++ SDK. Вроде Android/IOS или Qt. Такой аналог плюсовых шаблонов с плюшками экосистемы лиспа.

Есть желание порассуждать вслух :-)

Не вижу желания порассуждать, вижу желание постебаться и повыёживаться.

Если я пишу приложение на цепепе для кого-то,
Вряд ли он обрадуется тому, что для расширения его программы (написания скриптов) ему нужно освоить Common Lisp :-)

Предметно-ориентированые языки! - скандировал узкий круг страшно далекий от скриптописателей.

Имхо. ECL нужен там где скрипты не катят или как минимум требуют уже С-шных вставок. И приходится браться за C. Вот ECL призван немножко облегчать этот процесс.

Не вижу желания порассуждать, вижу желание постебаться и повыёживаться.

Уважаемый Ярослав :-) Был задан вопрос:

А если по-честному, у него есть пользователи? :-)

Был получен ответ:

Если твой критерий выбора «количество пользователей», то выбирай похапе — не прогадаешь, гарантия 146%.

В каком из 2-х случаев ты видишь «желания порассуждать», а в каком - «желание постебаться и повыёживаться»? :-)

Если твой критерий выбора «количество пользователей», то выбирай похапе

Теперь уже, скорее, жабоскрипт. Похапе потихоньку уходит.

Имхо. ECL нужен там где скрипты не катят или как минимум требуют уже С-шных вставок. И приходится браться за C. Вот ECL призван немножко облегчать этот процесс.

Так он его не облегчает, а усложняет :-) Там, где не катят скрипты, где приходится браться за Си, там по-любому будет Си :-)

ECL позиционируется как реализация Common Lisp для расширения функционала сишной программы-ядра, функции которой можно дёргать из Лиспа, передавая в них колбэки уже на функции Лиспа :-) Таким образом, получается программа с ядром на Си и с функционалом на Лиспе - здравствуй Имакс :-)

Так он его не облегчает, а усложняет :-) Там, где не катят скрипты, где приходится браться за Си, там по-любому будет Си :-)

Ты никогда не писал генратор С-кода для прикладных нужд? Не буду тогда смущать:(

ECL позиционируется как реализация Common Lisp для расширения функционала сишной программы-ядра, функции которой можно дёргать из Лиспа

Нет. Ноборот на лиспе ядро которое дергает С-шную обвязку изнутри.

функции которой можно дёргать из Лиспа, передавая в них колбэки уже на функции Лиспа :-)

Это можно даже и в первую очередь в SBCL и далее везде.

Таким образом, получается программа с ядром на Си и с функционалом на Лиспе - здравствуй Имакс :-)

Нет как раз Emacs не получится. Но ты видимо не смогёшь понять почему так. Печаль:(

Ты никогда не писал генратор С-кода для прикладных нужд? Не буду тогда смущать:(

Не смущай меня :-) Генератор «C-кода для прикладных нужд» можно писать на любом языке :-) Причём тут ECL - мне действительно неведомо :-)

Нет. Ноборот на лиспе ядро которое дергает С-шную обвязку изнутри.

Что-то я не понял тогда, что куда встраивается? :-) ECL в программу на C, или программа на C в лисповое ядро на ECL? :-) Лол :-)

Это можно даже и в первую очередь в SBCL и далее везде.

Да, поэтому ECL не нужен :-) Единственный козырь ECL - возможность сборки там, где нельзя собрать какой-нибудь Racket :-)

Нет как раз Emacs не получится. Но ты видимо не смогёшь понять почему так. Печаль:(

Не могу понять, объясни :-)

Единственный козырь ECL - возможность сборки там, где нельзя собрать какой-нибудь Racket :-)

PS. Или когда нужно доставить приложение до клиента, но не нужно его бесить необходимостью устанавливать SBCL, попутно рассказывая про неимоверную крутость Лиспа :-) Клиент просто собрирает из программу исходников на C/C++ и запускает программу :-)

Генератор «C-кода для прикладных нужд» можно писать на любом языке :-) Причём тут ECL - мне действительно неведомо :-)

На любом. А лисперы написали инкрементный с реплом, отладчиком и возможностью смешивать автоматически-сгенерированый код с ручным. Это немножко интереснее «писать на любом языке»

Что-то я не понял тогда, что куда встраивается? :-) ECL в программу на C, или программа на C в лисповое ядро на ECL?

Лисповое ядро берет внешний С-шный компилятор и компилирует внутри себя код для привязки к С/C++ SDK. И опять же внутри себя ручной C-код используя автоматически сгенерированые из лиспа утилиты. Зря что ли у нас макросы и всякое прочее. Получаем в итоге класическую пару - исполняемый рантайм и и образ с прикладным кодом содержащий лисповые части и ручной С по необходимости и возможность дергать из SDK всякое интересное минуя FFI. Отдельная программа на С при этом нафиг не нужна. Но есть возможность подключать рантайм в качестве сишной библиотеке но по необходимости и это уже вторично наподобие Swank-а.

Не могу понять, объясни

А я там вверху писал про Guile который плоть от плоти emacs-овой применительно к ECL. Почитй - подумай:)

PS. Или когда нужно доставить приложение до клиента, но не нужно его бесить необходимостью устанавливать SBCL,

Зачем ставить SBCL клиенту? Ты совсем уж странный:( Просто выдаешь ему сохраненй образ под его ОС. И оно как-то само удивительным образом работает:)

На любом. А лисперы написали инкрементный с реплом, отладчиком и возможностью смешивать автоматически-сгенерированый код с ручным. Это немножко интереснее «писать на любом языке»

Если хочется «интереснее», то берёшь какой-нибудь SBCL и генерируешь :-)

Лисповое ядро берет внешний С-шный компилятор и компилирует внутри себя код для привязки к С/C++ SDK.

При этом, сначала надо написать FFI на C для ECL :-)

Получаем в итоге класическую пару - исполняемый рантайм и и образ с прикладным кодом содержащий лисповые части и ручной С по необходимости и возможность дергать из SDK всякое интересное минуя FFI.

Что значит «минуя FFI»? :-) Там есть статический, есть динамический FFI :-) Ты, видимо, про Static FFI, т.е. про вот такой подход:

(defun c-sin (x)
  (ffi:clines "#include <math.h>")
  (ffi:c-inline (x) (:double) :double "sin(#0)" :one-liner t))

Отдельная программа на С при этом нафиг не нужна.

Смотря что понимать под «программой на C» :-) А то любая библиотека - это и есть «программа на C» :-) Собственно, именно это я имел в виду, когда говорил про «программу-ядро» :-) И это действительно так :-) ECL реализует прикладную логику, дёргая разные функции ядра :-) Но твоя мысль про «отдельную программу на C» мне понятна :-)

А я там вверху писал про Guile который плоть от плоти emacs-овой применительно к ECL.

Если ты про вот это:

Guile самодостачный интерпретатор типа питона.

то ECL может работать как интерпретатор :-) При этом, будет такой же тормоз, как Elisp, но, правда, с поддержкой SMP :-)

Зачем ставить SBCL клиенту? Ты совсем уж странный:( Просто выдаешь ему сохраненй образ под его ОС. И оно как-то само удивительным образом работает:)

Странные нынче те клиенты, которые не хотят видеть исходники :-) Не, ну если у тебя есть клиенты, готовые на запуск 80-ти метрового бинаря, который мало ли что делает, то тебе повезло :-)

Есть намного более крутая, быстрая, компилируемая и тоже встраиваемая штука под названием Racket :-) И что самое главное - современная и нужная :-)

У которой до сих пор серьезные баги в компиляторе, и их никто не хочет и не может починить.

У которой до сих пор серьезные баги в компиляторе, и их никто не хочет и не может починить.

Какие такие «серьёзные баги»? :-)

Какие такие «серьёзные баги»? :-)

Ты уже подъзаебал со своими смайлами.

80-метровый бинарь в 2020 году это не так уж и много

80-метровый бинарь в 2020 году это не так уж и много

Собственно, дело не в размере :-) Есть пользователи, которые хотят собирать софт из исходников :-)

А есть, которым надо просто запустить, и чтобы усе работало. А с исходниками пускай «тыжпограммисты» занимаются. И таких пользователей 99+%.

А есть, которым надо просто запустить, и чтобы усе работало. А с исходниками пускай «тыжпограммисты» занимаются. И таких пользователей 99+%.

Ты прав, но, сам знаешь, какие это 99+% пользователей :-) Им нужен GUI, а с консолью пускай «тыжпрограммисты» работают :-) Отсюда, для таких пользователей походит LispWorks, но никак не SBCL :-) Кстати, я так и не решился покупать LispWorks :-) Лицензия показалась какой-то слишком строгой :-) Что скажешь? :-)

Лицензия показалась какой-то слишком строгой

Ты с AllegroCL не путаешь? Одна лицензия на LispWorks разрешает установку среды на один рабочий компьютер и один лаптоп. Конечный бинарь-продукт распространяется без ограничений.

PS: Кстати скоро буду сабмитить свою поделку в Apple AppStore.

С таким же успехом можно встроить ядро приложения на сабже, а гуйню клепать на Objective C в ХCode.

Кстати у Clojure CL есть родные биндинги к Cocoa, можно даже сишку с objective c не дергать. Пример есть в Apple AppStore: https://itunes.apple.com/us/app/clozure-cl/id489900618?mt=12

Ты с AllegroCL не путаешь?

Нет :-)

Одна лицензия на LispWorks разрешает установку среды на один рабочий компьютер и один лаптоп. Конечный бинарь-продукт распространяется без ограничений.

Это я знаю :-) Мне не нравятся пункты 12, 14 и особенно 21 :-)

PS: Кстати скоро буду сабмитить свою поделку в Apple AppStore.

Кстати, что ты будешь делать, если конечный пользователь нарушит соглашение (см. пункт 21 Лицензии)? :-)

Можешь привести линк к этим пунктам?

Можешь привести линк к этим пунктам?

Нет, у меня лицензия на локахосте - .sh файл :-) Посмотри сам у себя :-)

Посмотри сам у себя

Посмотрел. Все пункты соглашения адекватные. 21 п. — если не делать ничего криминального, то такого не случится. Мы ведь взрослые люди?

21 п. — если не делать ничего криминального, то такого не случится. Мы ведь взрослые люди?

Конечно, но тем не менее :-) Мне не нравятся такого рода условия :-)

или машинный код (если доступен компилятор С).

Эмм, не проще сразу писать на C?

Там рантайм настолько же жиробасный, как и у всех остальных лиспов, за исключением Picolisp?

Clojure CL

Закусывать надо.

clozure-cl
есть родные биндинги к Cocoa

У этих да.

Закусывать надо

Это сраный автокомплит в сафари

Кстати, что ты будешь делать, если конечный пользователь нарушит соглашение (см. пункт 21 Лицензии)? :-)

Конечный пользователь не нарушит, так как в его руках будет результат, а не licensed software. Читай внимательно. Отдал готовый бинарь и забудь.

запуск 80-ти метрового бинаря

Ловите ретрограда! Нынче массовый переход на контейнерную виртуализацию. Так что не мало клиентов, которых и десятки гигагабайт потратить не напрягает.

Нынче массовый переход на контейнерную виртуализацию. Так что не мало клиентов, которых и десятки гигагабайт потратить не напрягает.

Деградация :-)

Ну, если измерять прогресс экономией байтов, за последние лет 50 в IT произошла большая деградация.

Ну, если измерять прогресс экономией байтов, за последние лет 50 в IT произошла большая деградация.

IT превратился в бизнес облаков :-)

А чего не Chicken схема?

То же в Си