Вышел новый релиз LispWorks 7.0

сможет ли хоть одна из этих реализаций сделать arm бинарник на x86_64 машине

Скорее такое возможно с ECL, имея кросскомпилятор.

В LispWorks для ARM, образ запускается и собирает код в QEMU на х86. Дальше готовый рантайм с приложением можно запускать на ARM железке, можно даже SLIME'ом туда зайти и компилировать уже на ARM.

хм. можно тогда будет попробовать с aboriginal linux поиграться.

Тут можно только посоветовать переехать в Россию.

А у него нормально с памятью? а то sbcl полтора гига отжирает только на хелловорлде.

SBCL отжирает около 30 МиБ в 32-бит сборке и почти в два раза больше в 64.

Да, у LispWorks с памятью намного лучше.

А как громко кукарекал! Думай в следующий раз наперед.

Да знаю я, что Common Lisp - это красивейший язык из всех, когда-либо созданных. У кого: мало серого вещества, безвкусица, фОнатизм curly brackets или прочие малоприятные синдромы, тот не поймёт. Никогда. И как говорил Эрик Наггум...

Линус Торвальдс написал ядро Linux, ныне самое популярное на серверах и мобильных устройствах. Не на LISP.
Ричард Столлман создал ОС GNU и первые версии компилятора GCC. Не на LISP.
Десятки, сотни тысяч программистов создали индустриальные СУБД, компиляторы, веб-серверы, серверы приложений, middleware, мегатонны научного и инженерного софта, игры, софт для создания музыки и кино. Не на LISP.

А что написал Eric Naggum?

Общелисп вообще сам по себе даёт преимущества в скорости и простоте разработки по сравнению с более слабыми языками.

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

Ах, да.

Ведь твой LISP-стартап лопнул.

А Эрик Наггум написал примерно следующее:

idiot-------------------------------common lisp programmer ^you

Это он тебя тоже имел в виду. И таких как ты.

А Эрик Наггум написал примерно следующее:

idiot-------------------------------common lisp programmer

----------^you

Это он тебя тоже имел в виду. И таких как ты.

А Ричард Столлман написал следующее:

The most powerful language is Lisp.

А Линус Торвальдс - фОнат Си. Но мне на него наплевать. Как и на тебя :-)

Скупая слеза пробежала по небритой щеке программиста: «ах, этот старый, добрый язык из смайликов! мы тебя уже похоронили, а ты вона как вылез!».

Также в угоду десяткам и сотням тысячам программистов были созданы такие выродки как XML, HTML, всякие нотации типа JSON. Всё это легко и в горадо более чистом виде представимо S-выражениями. Насчёт индустриальных СУБД, компиляторов, веб-серверов и проч. Что тут скажешь - молодцы программисты. Все пользуются их технологиями. Речь идёт о красоте языка. Ну ка, приведи пример более красивого и выразительного языка, чем Common Lisp?

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

perl

Мне жаль тебя.

пример более красивого и выразительного языка, чем Common Lisp

Если вопрос именно так, то ответ «Ruby».

Ruby проигрывает только по расширяемости синтаксиса и производительности.

А если вопрос ещё немного разбавить прагматизмом, то Руби проигрывает так, что писать на нём не хочется.

вот на нём и не пишут

то Руби проигрывает так, что писать на нём не хочется

Чем это? Реализация почти любого алгоритма на нём выглядит гораздо красивее и выразительнее, чем на Lisp.

Вот например

    class Server   
        
      def initialize(port=3333)   
        @server   = TCPServer.new('127.0.0.1',port)   
        @handlers = {}   
      end   
        
      def handle(pattern, &block)   
        @handlers[pattern] = block   
      end   
        
      def run   
        while session = @server.accept   
          msg = session.gets   
          match = nil   
          @handlers.each do |pattern,block|   
            if match = msg.match(pattern)   
              break session.puts(block.call(match))   
            end   
          end   
          unless match   
            session.puts "Server received unknown message: #{msg}"   
          end   
        end   
      end  
         
    end  

Использовать как

Server.run do   
  handle(/hello/i) { "Hello from server at #{Time.now}" }   
  handle(/goodbye/i) { "Goodbye from server at #{Time.now}" }   
  handle(/name is (\w+)/) { |m| "Nice to meet you #{m[1]}!" }   
end 

Попробуй переписать на Common Lisp, чтобы читалось не хуже.

вот на нём и не пишут

Ну-ну...

http://adambard.com/blog/top-github-languages-2014/

Или ты не про Ruby, а про Lisp?

Ты, наверное, не обратил внимание на упомянутый прагматизм, под которым я имел в виду упомянутую тобой производительность. Руби - тормоз, потому писать на нём для продакшена в wild-wild Internet я не буду. С помощью seaside вон тоже можно быстро и приятно кляпать. Только Smalltalk такой тормоз, что seaside я бы даже для intranet не взял бы. Правильнее сказать, Common Lisp - золотая середина - и красиво, и быстро, и человек становится умнее. (Он вынужден стать умнее.) И Lisp - это, прежде всего, идея, которая проста, элегантна и имеет прочный теоретический фундамент в основе которого теория Чёрча. В этом - главная изюминка его красоты. А на чём основан Руби? Это проект фОната ООП, созданный на вкус создателя. Где там математика? Там есть позаимствованные идеи Lisp и сахарочек от создателя. А ещё я не люблю я т.н. владельцев языка. Это когда (C)(tm)(R). Lisp - это концепция и лично мне это нравится. Но фОнатом его я не являюсь. ФОнаты мне вообще безразличны, а всякий фОнатизм я презираю.

Ну ка, приведи пример более красивого и выразительного языка, чем Common Lisp?

Я себе слабо представляю более уродливый язык, чтом общелисп. Scheme в сто раз лаконичнее и красивее, Go красивее, Си красивее, да даже сипипи красивее и уж точно выразительнее этого убожества.

Руби - тормоз, потому писать на нём для продакшена в wild-wild Internet я не буду

Гм. PHP, Perl и Python тормоза настолько же. Common Lisp тормоз на фоне C/C++. Тем не менее найти сайт на C++ — это очень надо постараться. Поэтому как раз для сайтов RoR скоростью не выделяется.

Где там математика?

Математика почти во всех (современных) языках одинакова. Отличия только синтаксические. Ну и плюс/минус типизация. Опять же, если брать математическое обоснование, то почему тебе нравится Lisp, а не ML или Haskell?

сахарочек от создателя

Вот этот сахарочек и позволяет писать красивые, лакончиные и понятные программы (тот самый критерий «красота и выразительность»). В Lisp'ах макросистема позволяет сделать аналогичный сахарочек, но его приходится делать к каждому случаю (что приводит к дроблению базы библиотек: hu.dwim.*, lisp-interace-library, ... — требуют при использовании придерживаться стиля библиотеки). В Ruby синтаксис достаточно хорош, чтобы его не переопределять по каждому поводу. Тот же Rails при очень хорошей читабельности придерживается изначального синтаксиса.

а мне CL))

Выдерать вопросы из контекста не красиво. Никого это не красит, даже вьетнамцев. Я про фундаментальные математичекие корни говорил. Трудно найти сайт на C++? - google.com Lisp мне нравится не только с т.з. математической теории, а ещё и по практическим соображениям. Там есть макры. Без макр мне Lisp даром не нужен. Мне синтаксис не нужен и не важен. Сахарочек не люблю, люблю шоколадки. И мне семантика важна.

А ты слабо представляешь, наверное потому, что фантазии маловато. go-go, когда танцуют, те ещё красивее. :-) Си++? Твои любимые Линус Торвальдс с Ричардом М. Столлманом не один раз его говнили. Си? Си - язык для оборудования, годный такой язык для написания рантаймов. Но он низкоуровневый, а потому его выразительность лишь на уровне его синтаксиса. Замысел разработчика этот язык передаёт плохо. Кстати, ты (или не ты) что-то упомянул про СУБД? А ты знаешь, что разработчики тоге же Postgres неоднократно поднимали вопрос о переходе с Си на Си++? Последний раз это было когда gcc перевели на Си++. Такие метания не от хорошей жизни. Scheme минимален, лаконичен и по-своему красив. Common Lisp интересен макрами. Язык без макросов, особенно если (c)(tm)(r) - это так, частный случай фОната или кОндидата в гегемоны.

Кстати, ты (или не ты) что-то упомянул про СУБД? А ты знаешь, что разработчики тоге же Postgres неоднократно поднимали вопрос о переходе с Си на Си++? Последний раз это было когда gcc перевели на Си++. Такие метания не от хорошей жизни.

А знаешь ли ты, что изначально Postgres был на лиспе? Такие метания не от хорошей жизни. (с)

Our feeling is that the use of LISP has been a terrible mistake for several reasons. First, current LISP environments are very large. To run a ‘‘nothing’’ program in LISP requires about 3 mbytes of address space. Hence, POSTGRES exceeds 4 mbytes in size, all but 1 mbyte is the LISP compiler, editor and assorted other non required (or even desired) functions. Hence, we suffer from a gigantic footprint. Second, a DBMS never wants to stop when garbage collection happens. Any response time sensitive pro- gram must therefore allocate and deallocate space manually, so that garbage collection never happens dur- ing normal processing. Consequently, we spent extra effort ensuring that LISP garbage collection is not used by POSTGRES. Hence, this aspect of LISP, which improves programmer productivity, was not avail- able to us. Third, LISP execution is slow.

Это было миллион лет назад. Посмотри на современные рантаймы CL, современное железо. У коммерческих реализаций есть кастомный риалтайм gc, если очень нужно.

У allegro CL также появился новый параллельный GC.

Это было миллион лет назад.

Как и высказывания Столлмана и Торвальдса. С тех пор Столлман вообще перестал что-либо писать, а Торвальдс вполне себе пишет на С++.

Посмотри на современные рантаймы CL, современное железо. У коммерческих реализаций есть кастомный риалтайм gc, если очень нужно.

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

вытрясая ненужный код.

Интересно вот а в sbcl такую фичу планируют делать?

медленнее С

Медленнее и жирнее, таки серьезные СУБД в несколько Мб давно уже не влазят.

Ты, небось, дальше первого предложения приведённого текста не читал. Соль текста в gigantic footprint, stop when garbage collection happens, LISP execution is slow. 20 лет спустя эти проблемы приобрели ярко выраженный относительный характер. Кстати, по все эти проблемы подпадает и Java. (Наверняка тебе нравится.)

Вот, пожалуйста, высказывание Столлмана в адрес C++ датировано Mon, 12 Jul 2010 08:36:48 -0400. «C++ is a badly designed and ugly language. It would be a shame to use it in Emacs.

The reason the GCC developers wanted to use it is for destructors and generics. These aren't much use in Emacs, which has GC and in which data types are handled at the Lisp level.»

О, да ты фОнат скорости. Поэтому то, что Common Lisp «медленнее» C - для тебя очень важный аргумент. Знаем, знаем таких скоростных товарищей :-)

И что же Торвальдс напЕсал на C++?

Ты, небось, дальше первого предложения приведённого текста не читал. Соль текста в gigantic footprint, stop when garbage collection happens, LISP execution is slow. 20 лет спустя эти проблемы приобрели ярко выраженный относительный характер.

20 лет спустя ровно ничего не изменилось, типичный код на лиспе всасывает С по скорости и потреблению памяти. Впрочем для СУБД уровня 20-летней давности, с теми же нагрузками, на современном железе он может уже и подойдет.

Кстати, по все эти проблемы подпадает и Java. (Наверняка тебе нравится.)

Отнюдь, не люблю GC, стою в очереди за rust.

Вот, пожалуйста, высказывание Столлмана

С таким же успехом можно привести высказывания «царя», хотя нет - тот хотя бы что-то реально пишет.

О, да ты фОнат скорости. Поэтому то, что Common Lisp «медленнее» C - для тебя очень важный аргумент. Знаем, знаем таких скоростных товарищей :-)

Есть задачи, для которых скорость очень важна, сложные СУБД - одна из них. Сколько ты их написал (поучаствовал), чтоб что-то тут высказывать?

такие выродки как XML, HTML, всякие нотации типа JSON.

Всё это легко и в горадо более чистом виде представимо S-выражениями

Ты имеешь в виду - для представления структурированной информации? Приведи, пожалуйста, пример S-выражения, заменяющего следующее:

<person>
    <firstname>John</firstname>
    <lastname>Smith</lastname>
    <age>42</age>
</person>

XML хорош, например, тем, что для него разработаны встроенные средства проверки, перекрёстных ссылок, преобразования в другие форматы...

(person (firstname «John») (lastname «Smith) (age 42))

XML убог.

Окей, спасибо.

А можно сделать, чтобы в одном файле лежало ЭТО, в другом правила проверки (аналог XML Schema), и всё это проверялось средствами самого языка?

А что там смотреть, как CL был медленнее С, так и остался.

Это из-за плохих (устаревших) компиляторов, а не из-за языка. Общелисп проектировался, в том числе, с фокусом на производительность, поэтому программы можно писать так, что у компилятора информация о типах будет. В SBCL компилятор по эффективности где-то в районе GCC 3-й ветки, но уже даже не вчерашних техник оптимизаций типа SSA в нём до сих пор нет.

Насчет «современное железо» - ну так и нагрузки выросли на порядки, как и сложность самих СУБД, что тоже требует повышенной производительности.

Нагрузки СУБД уходят в IO и проблемы, с ним связанные, а не в прямую нехватку вычислительной мощности.

Это раз. Два: программы промышленного масштаба пишут посредственные программисты, с посредственным результатом, естественно. У них и C++ тормозит.

Здрасте, приехали. Макрами можно сделать гораздо больше. Программируемый язык программирования способен на гораздо больше, чем эти твои задачи валидации.

Задачи есть всякие. И для каждой задачи уместно использовать свой язык. Common Lisp - золотая середина. На нём можно создавать не просто «картонный» прототип для показухи, а прототип с хорошими характеристиками производительности, который можно внедрять в эксплуатацию. Потом можно переписывать на какой-нибудь другой язык, если потребуется. А писать на Си с самого начала - это только для таких как ты, фОнатов скорости.

А писать на Си с самого начала - это только для таких как ты, фОнатов скорости.

Ок, добавим сюда еще то, что С до сих пор в каждой бочке затычка, а «золотая середина» Common Lisp так и остался уделом маргиналов, и закроем тему.

Поддержка multi-touch gestures.

Кто-нибудь пробовал? Zooming для output-pane есть?

А можно сделать, чтобы в одном файле лежало ЭТО, в другом правила проверки (аналог XML Schema)

http://okmij.org/ftp/Scheme/xml.html#SXML-spec

В частности http://okmij.org/ftp/Haskell/HSXML/Description.txt

Основной проблемой было найти работающий GTK3 под винду.

msys2 и pacman -Suy

[:person
    [:firstname "John"]
    [:lastname "Smith"]
    [:age "42"]]

Это на Кложуре будет. Точнее, на hiccup, крохотный dsl поверх кложуры.
Несильно лучше, но покомпактнее. Особенно всё хорошо при радужной подсветке скобок.

А что написал Eric Naggum?

кучу флейма же.

вот Eric Schulte написал много всякой годноты на емаксовом елиспе.

страшно подумать, чего бы он на CL мог бы написать :))

Ричард Столлман создал ОС GNU и первые версии компилятора GCC. Не на LISP.

ну он первый емакс писал таки и на CL тоже. уже потом на недоЕлиспе переписал. мне тут больше нравится кристиан, автор OpenLisp и Emact. его емакс как-то покомпактнее будет, хотя толком нифига не умеет — но выглядит обещающее.

Десятки, сотни тысяч программистов создали индустриальные СУБД, компиляторы, веб-серверы, серверы приложений, middleware, мегатонны научного и инженерного софта, игры, софт для создания музыки и кино.

не нужно.

не нужно писать это всё руками — нужно написать MetaCASE среду для метамоделирования, чтобы из метаметамоделей ограничений породить метамодели интерфейсов и модели реализации, и сами реализации, вот это вот оно всё. порождать модели моделями через метамодели. и целокупно — и в какую-то реализацию на выходе.

Не на LISP.

не нужно в квадрате.

что действительно нужно, так это практика=дисциплина+технологии, и минимально сложное, максимально гибкое нечто из технологий.

например, тот же org-mode babel + LP, RR остнастка из этой технологии. например, см. у того же eschulte проекты: emacs24-starter-kit, статья в JSS про LP,RR,org-mode babel, CiSE.

примерно в таком виде нужна операционная среда для поддержки «дисциплины» жизненного цикла разработки. она должна уметь выполнять первичную настройку (см. init.el) + вызов основных функций типа выкачки зависимостей через quicklisp, компиляции, сборки, тестирования, публикации релиза, документирования.

то есть: пишешь «концептуальный» .org по проекту, куда записываешь всякие TODO фичи. активно пользуешься фичей под названием column view, #+CATEGORY: , произвольные property на узлы аутлайна и блоков кода и данных, наследование пропертей в этом своём концептуальном .org с требованиями. пишешь в column view две матрицы прослеживаемости: трассировку требований по фичам и фич(или требований) по релизам.

затем пишешь «архитектурный» .org на API, на интерфейс + реализацию. аналогично тому как в org-mode TODO/DONE и clock-in/clock-out делаешь свои теги на ЖЦ: для сборки и тестирования. то есть, в TDD у тебя светофор красный-зелёный, по «тесты в разрезе кода», а тут будут «тесты в разрезе фич» и «тесты в разрезе интерфейсов спеки». в базовом org можно переключать без ограничений эти TODO/DONE, тут делаешь через светофор только если тесты написаны и проходят.

тесты пишешь на блоках кода, через метапеременные блоки кода связываешь с учётом матриц прослеживаемости(скриптом в блоке кода тестирования).

в том же архитектурном или в другом, но связанным с ним .org реализации API пишешь прозой «расказ резиновой уточке» как работает реализация интерфейсов. пишешь также по ходу кодом блоки кода, в духе Literate Programming. потом делаешь weave и получаешь нормальную доку (weave или экспорт org-а), делаешь tangle + запуск копиляции/тестов/сборки «по светофору» — и получаешь код (и собранный проект и бинарник).

магия LP, RR, и org-mode babel делает всё остальное.

если скрестить формат org-а с каким-нибудь GNU Skribilo (на guile) — или API для чтения и записи .org файлов на CL — то можно эти блоки кода кодогенерировать лиспом из лиспа на лиспе через елиспы (то есть, орг-моду или skribilo).

то есть, получаются модели и DSL, и если прикрутить свои reader,writer для skribilo — получаются свои метаязыки (реализованные через макросы в guile).

то есть, org-mode babel — это среда заодно и метамоделирования (позволяет заодно и отреверсить код в модель или модель в метамодель, если руками проставить нужные блоки кода в метамодели, и задать какие-то изоморфизмы исходной и отреверснутой). и всё что нужно — написать трансляцию из какого-то моделлера в эти свои метаязыки.

и какой-то язык модели ограничений для задания этих вот морфизмов.

а сам текст модели должен генерироваться автоматически: как запись макросов юзера, тыкающего в твоей апликухе в гуёвину.

Насчёт индустриальных СУБД, компиляторов, веб-серверов и проч. Что тут скажешь - молодцы программисты.

вот, кстати, про «индустриальные СУБД». MUMPS же :P

Все пользуются их технологиями. Речь идёт о красоте языка. Ну ка, приведи пример более красивого и выразительного языка, чем Common Lisp?

точно говорю — это MUMPS :)))

потому что MUMPS-глобалы изоморфны S-выражениям, и значит — S-выражения для символьных вычислений можно хранить напрямую в M-кубах.

то есть: можно снепшотить все трассы лисп-программы в лисп-на-мумпсе (хотя, и в picolisp есть что-то подобное: там все символы персистенты).

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