Clasp, одна из новых реализаций CL, всего лишь в четыре раза медленнее, чем C++

Т.е. у вас в идельном мире компилятор сам догадывается, что дебажные символы и некое safety генерировать именно для этой функции не нужно? И что тут тип должен быть именно unsigned?

Ага, это здоровый интерес. Забавно наблюдать за выживанием лисперов.

приличных языках есть стек

Это в C++ чтоле?

а не только ссылки на них

clhs declare (dynamic-extend)

Туда ещё нужо добавить «написано на C++». Как и тут: Ceramic — кросплатформенный GUI на Common Lisp

Верно

то что мертво умереть не может

А он не на SBCL ли основан? Там три года как собираются LLVM впилить.

И зачем это? Ты как ребенок радуешься, что лисп оказался всего-то в 4 раза медленнее. А это, между прочим, ой как дохера. Люди борются за процентное увеличение быстродействия, а тут 4 раза!

А си++ часто используется по делу?

Думаю, тут тяжело будет статистику подвести. Х его, как говорится, З.

Можете не отвечать, сходил по ссылке.

Да и тогда бы вывод типов от SBCL был, а его ещё пока нет.

Ты как ребенок радуешься, что лисп оказался всего-то в 4 раза медленнее.

Я радуюсь какому то ни было прогрессу.

И зачем это? Ты как ребенок радуешься, что лисп оказался всего-то в 4 раза медленнее.

Вы верите в объективность синтетических тестов? Тогда внимательно прочитаем таблицу ещё раз и возрадуемся, что лисп оказался быстрее на ЦЕЛЫХ ДВАДЦАТЬ ПРОЦЕНТОВ и срочно выкидываем сишечку в окно.

Кроме того, в энтерпрайзе сейчас почему-то используется куча языков, которые в десятки раз «slower than C».

Этот тест применим только для алгоритмов с простой целочисленой (fixnum) арфметикой использующих +,-,<,=,>,fboundp. Пока только эти операции будут достаточно быстрыми. Код который использует другие операции будет работать намного медленее, до тех пор пока я все не доделаю.
CCLASP прошел долгий путь став медленее C++ всего в 4 раза вместо сотен раньше.

Основной особенностью Clasp, ... использование LLVM.

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

Кроме того, в энтерпрайзе сейчас почему-то используется куча языков, которые в десятки раз «slower than C».

Потому, что там не нужен C. Очевидно же. Некоторым почему-то очень трудно понять, что разные языки используются для разных задач.

Кроме того, в энтерпрайзе сейчас почему-то используется куча языков, которые в десятки раз «slower than C».

Ну да, bash, например, тот же awk и т.п. И почему люди не пишут скрипты на C?

Кроме того, в энтерпрайзе сейчас почему-то используется куча языков, которые в десятки раз «slower than C».

Скорость разработки и надежность компонентов. Впрочем, лисп и тут отсасывает, так что хз даже, зачем оно.

Этот ботаник формалином надышался и теперь его штырит. На фига сюда этого утырка-то тащить, тут и своих недоумков хватает.

Clasp был приведен как возможность легко интерфейсится с плюсовыми либами и выступать в виде ядра бизнес логики.

чем тогда он отличается, к примеру, от Python, количеством скобок?

статическая типизация и ООП.

ооп в лиспе есть, а что - к нему нельзя приделать статическую типизацию? Что именно мешает? Вроде можно. Можно даже отказаться от вывода типов и заставить лисперов хинтами или еще как-то точно указывать даже промежуточные типы...

Первый раз слышу.

а что - к нему нельзя приделать статическую типизацию?

В CL нет статической типизации, она там не нужна. Но если компайлер умный, или с помощью хинтов, компилятор сможет оптимизировать код и/или выбросить ошибку в compile-time — это детали реализации. SBCL более близок/стремится к описанным фичам.

всего лишь в четыре раза медленнее, чем C++
всего лишь

Не нужно.

например, глянь вот статью лафсана: http://habrahabr.ru/post/230619

а по поводу статической типизации, ну её нет, но что мешает самому прикрутить? в смысле, подправить компилятор и IDE чтобы она начала существовать. Например, тупо первый параметр у всех функций начинает иметь специальное значние - это имя возвращаемого типа. И дефайнить что угодно ты можешь только с типом. И так далее.

а по поводу статической типизации, ну её нет, но что мешает самому прикрутить?

Так я её и имел в виду.

А нормального гуя в свободные реализации CL так и не завезли...

А нормального гуя в свободные реализации CL так и не завезли...

Emacs. Заплатившие 5к за коммерческую лицензию LW всё равно в Емаксе сидят.

Тащить это на ЛОР и не упоминуть что в данном тесте SBCL обогнал C++ ?!!

а вы бы в C++ еще чаще использовали визиторы и всякую околдинамическую фигню, он так скоро медленней питона станет =)

намякиваю на: Бьёрн Страуструп выбирает борщ: «С++ почти так же быстр как Haskell»

Нормальный гуй к емаксу лиспу, наверное, можно сделать на Jetbrains MPS с минимальными затратами... Но кто же этим будет заниматься? Вот ты будешь?

ого, рскудахтался. врпoчем, как обычно

Вот как раз на сложных и комплексных задачах ни один подобный язычок C++ никогда порвать не сможет. Просто потому, что не содержит адекватных средств борьбы со сложностью, коими являются статическая типизация и ООП.

Где нет ООП, в Common Lisp'е-то? Это его в C++ нет, если сравнивать с общелисповскими CLOS/MOP.

Средств борьбы со сложностью в CL опять-же больше. Я писал на обоих языках, в CL проще.

Не IDE, а гуя же.

Тоже что ли путаешь гуй с IDE? Ну и там по ссылке жаба. Для лиспа на жабе (ABCL) такая проблема не стоит — можно свинг, свт и жабафх напрямую дергать.

а, вот ты о каком гуе... Ну просто стучись к свингу через clojure или abcl. Там же в лиспе как эта.. гомо..фобия процветает? Должно быть удобно писать внешнее апи для гуя, и потом юзать его из другого лиспа, не?

Проблема в том, что самые хорошие реализации коммон лиспа — не на жабе

Да купи уже, чего ноешь? :) я купил себе и не ною, решаю задачи, все нравится.

https://news.ycombinator.com/item?id=9721801
Видео советую посмотреть, крутые штуки автор разрабатывает

Что именно мешает?

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

Где нет ООП, в Common Lisp'е-то?

Там все не очень хорошо с инкапсуляцией.

Это ботаник-то, накурившийся формалина?

Там все не очень хорошо с инкапсуляцией.

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

Что купил? LW или Allegro?

LW :)

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

Средств борьбы со сложностью в CL опять-же больше

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

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

Дженерики хорошо прячутся в пакеты (неймспейсы), если инкапсуляция нужна.

Что делать в ситуации:

(defpackage #:A
  (export #:A #:foo))
(in-package A)

(defclass A ...)
(defgeneric foo ...)

(defmethod foo ((A A) x ...)
....

у другого программиста

(defclass #:B (:use #:A) ...)

(in-package #:B)

(defmethod foo ((A A) (x fixnum)) ...)

;; использует особое поведение для целых чисел

у третьего программиста

(defclass #:C (:use #:A) ...)

(in-package #:C)
(foo (make-instance 'A:A) 3) ; результат зависит от того, загружен ли в текущий образ пакет B.

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

Ну так напиши и покажи что это вообще возможно. Я вот могу ткнуть в http://emias.info/ или http://zakupki.gov.ru/, или в похожие по сложности проекты на C++, которые в паблик не торчат, но вполне себе существуют и работают. Да тот же браузер, которым ты пользуешься, написан вовсе не на CL, хотя, казалось бы, что может быть лучше для работы с DOM?

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

Надо же, а мужики то и не знали. Только вот почему-то, в прошлом веке любое сколько-нибудь сложное приложение было написано либо на лиспе либо на смолтоке. Весь 21 век — это неуклюжие попытки переписать с помощью стада баранов тот сложный софт на другие, *более быстрые* *статически типизированные* ЯП. Разработка же сложных приложений непосредственно на этих ЯП — это вообще оксюморон.

Например тому анонимусу, которому я отвечал, да.

Скорость разработки и надежность компонентов. Впрочем, лисп и тут отсасывает

Нет.

Только вот почему-то, в прошлом веке любое сколько-нибудь сложное приложение было написано либо на лиспе либо на смолтоке.

O RLY?