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

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

Опиши фичу

CL-USER> (= (+ 0.1 0.2) 0.3)
T

и внятное описание контекста её применения.

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

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

Сложить два числа без потери точности.

А когда я пацану выкатываю сишный эквивалент

Можешь начинать :)

...а умный осиливать не станет

А совсем умный даже разговаривать со скобканутыми не станет. Зачем время тратишь?

~450 человек на #lisp.

А на C++ пишет несколько миллионов. По самой консервативной оценке:

http://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/

А на C++ пишет
пишет
#lisp.

А совсем умный даже разговаривать со скобканутыми не станет. Зачем время тратишь?

Зачем же ты сюда, глупыш, зашел?

А на C++ пишет несколько миллионов.

Производя миллионы тонн тормозного и глючного говнокода...

Они хоть что-то производят, кроме метана. Я видел только две более-менее крупные программы на скобках: emacs (кривой, тормозной и существенно однопоточный) и maxima (на данный момент отсасывает даже у шестого Maple, написанного на сишке и собственном паскалеподобном языке).

Думаю, что эти две причины являются основными минусами для разработки на CL большой командой.

Если принципиально подойти к сути, то эта проблема всех динамических языков, таких, например, как Python или Ruby. Тем не менее множество вещей написано на них явно не одиночками. В то же время, в сравнении с этими языками, у CL есть ряд преимуществ.

А во-вторых порядок загрузки никто не отменял.

Кстати, да. Механизмов у ASDF позволяющих указывать порядок загрузки пакетов множество.

Был вменяемый Flavors.

Хм.

CLOS offers the following features not found in Flavors:

Multimethods
Methods specialized on individual objects (via EQL).
Methods specialized on Common Lisp types (symbol, integer, ...).
Methods specialized on defstruct types.
Class slots.

Отстутствие мультиметодов и EQL-специализаторов - это fail.

А я вот на хаскеле не видел и не использовал ни одной программы вообще. Что это доказывает? А вот лиспом я пользуюсь каждый день: emacs, stumpwm, lispworks. И у нас он в продакшене пашет 24/7. Ты этого не увидишь к сожалению, но когда будешь использовать какой-нибудь сервис по телефону, возможно лисп будет обрабатывать твой звонок, но ты об этом все равно не узнаешь.

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

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

Хорошо. Ты считаешь, что написание качественного продукта нa скобках принципиально нe возможно?

maxima (на данный момент отсасывает даже у шестого Maple, написанного на сишке и собственном паскалеподобном языке)

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

Но почему мифическая «сила лиспа» не устранила этот разрыв? Даже опенсорсный sympy сейчас умеет примерно столько же, сколько maxima.

А где именно максима хуже чем maple?

Взять хоть символьное решение ODE.

Символьное решение ode в максиме вроде есть.

Она вроде для уравнений выше второго порядка тупо интеграл Лапласа выбрасывала.

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

Точно. И чем больше коллектив, тем сложнее добиваться высокого уровня дисциплины от ВСЕХ.

думаю, коммерческие вендоры бы осилили, просто это никому не нужно, и хватает CLOS

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

А крупные проекты на CL почти всегда изначально пишутся не как крупные, а как прототип командой не более 8 человек. Потом потихоньку растут. Но, когда они дорастают до размера, где недостатки CL видны, объём переписывания на что-то ещё уже слишком велик.

эта проблема всех динамических языков, таких, например, как Python или Ruby

В Python нет возможности в модуле Bar испортить класс из модуля Foo.

В Ruby — да. Единственный крупный проект на нём — Ruby on rails ыл изначально написан одним человеком. Сейчас команда разработчиков — всего полтора десятка. Думаю для проекта с хотя бы сотней программистов он уже непригоден как и CL.

Отстутствие мультиметодов и EQL-специализаторов - это fail

Я понимаю, тебя ник обязыает так считать, но их присутствие, в большинстве случаев, больший fail.

Потому что нарушает принцип наименьшей неожиданности и очень редко нужен (можешь привести хоть один пример, где специализация по двум аргументам была по делу, а не просто замена declare type?)

А неожиданности:

(defmethod foo (a (b integer))
  (+ b 1))
(assert (= (foo 1 3) 4))

может работать при первой загрузке системы и не работать при перезагруке, так как кто-то, использующий данный файл определил (defmethod foo ((a integer) b) (+ a 1))

Вообще модульные тесты (юнит-тесты) в условиях CLOS почти невозможны. И приходится либо заниматься оборонительным программированием и не доверять даже тем методам, которые сам пишешь, либо надеяться на всеобщую дисциплину.

Думаю для проекта с хотя бы сотней программистов он уже непригоден как и CL.

Смотря как разрабатывать. Можно на каждый сабмодуль-приложение бросить по 10 человек, и пусть потом эти модули общаются через RPC.

Если на один модуль бросается больше 10 человек, то что-то не так в консерватории. Поэтому и получается, что в интерпрайзе бросают 100500 мартышек на один проект за миску риса — на выходе получается неподдерживаемый тормозячий говнокод. 10 человек — максимум. Потом нужно делить на модули и следовать протоколам RPC.

но когда будешь использовать какой-нибудь сервис по телефону, возможно лисп будет обрабатывать твой звонок, но ты об этом все равно не узнаешь.

*Вспоминая лапшу из erlang, bash и tcl*

В мобильных сетях и не такое «24/7» вертится ^___~

интересно, есть сравнение с ecl? вроде бы Clasp это форк ecl, вот вопрос, насколько оптимизировали производительность благодаря LLVM. за счёт чего разница?

алсо, был какой-то форк sbcl на LLVM, интересно сравнение с ним.

don’t want to start an argument about the speed of SBCL vs C++ here, my point is that CClasp has come a long way from being hundreds of times slower than C++ to within a factor of 4.

и всё же странно: где тормозит, надо построчно дизасемблировать и сравнить два варианта. кто-то в топике уже это сделал? </тред не читал>

Ура! Два самых прекрасных языка в мире теперь могут взаимодействовать друг с другом!

гораздо интереснее другой проект того же автора (ЕМНИП, часть исходников есть внутри Clasp на гитхабе) : Clang AST matcher на базе Clasp (см. видео по последней ссылке с ютуба по ссылке отсюда, с анонса)

то есть: колбасить C++ кодогенератором, который написать можно на коленке на лисповых макросах.

то есть: реализовать нормальные аспекты на C++, например.

Код. Хоть что-нибудь, чтобы подтвердить твои претензии на царство.

Меня не интересует выкат знамений для всяких ламерков. Меня не интересует ни твоё, ни какого-либо иного ламерка отношение ко мне.

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

Ты ж пиздобол, жалкая балаболка, которая сама не умеет вообще ни хуя.

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

Так по какому праву ты ебло разеваешь и производишь пиздежь, если ты сам полный ноль?

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

Это бенчмарк хелловолда же. На более комплексных и сложных приложениях Clasp вполне может порвать C++ по продуктивности разработки и результату выполнения.

я б скорее хотел бы взглянуть на Qt+Ecl примеры, портированные с Ecl на Clasp. и их бенчмарк. и вообще сравнение Clasp via LLVM vs. Ecl via C++, эффективности компиляции.

например, автоматическая кодогенерация обёрток к Qt тому же. или каких биндингов к ещё какому коду на C++ (через Clang AST matcher).

например: пишем плагин к Clang, компиляем => автоматические врапперы к FFI и обёртки на CL => автоматически сгенерированная заготовка на Clasp.

и в идеале, автоматическая миграция кода CL/C++ туда и сюда.

которая обычно на 20% медленнее плюсов
20%
обычно

Посмеялся, спасибо.

Все так, в точности

Очередная куллстори. Пруфцаны будут?

Какие реализации CL являются высокопроизводительными?

sbcl, lispworks, scieneer

Пока что я победил абсолютно во всех спорах, а ты ссышься даже из-под регистранта написать.

И все-таки царь выполняет очень полезную функцию. Вот уже не первый раз заходил с Гугла на ЛОР по какой-то теме, а там царя умные люди по дерьму катают и всякую полезную инфу в процессе оставляют.

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

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

ну например: calling conventions. читаем про C, видим cdecl, fastcall в регистрах, pascal и cdecl модифицированный (C++ vtable).

читаем описания рантаймов лиспа, и видим, на уровне lisp callconv:

1. количество параметров неизвестно заранее, и их типов — тоже (то есть, можно передавать списки, которые должны деструктурироваться либо параметры-ключевые слова)

2. выделение примитивных типов — элементарно, в стеке; выделение более сложных — в хипе, через conscell-ы.

3. время жизни параметров, продолжения, замыкания.

то есть: в общем случае, lisp callconv *ЛЮБОЙ ФУНКЦИИ* привёдёт к GC, выделяется каждый раз разное количество памяти; время жизни тоже всё усложняет.

поэтому в среднем вызов lisp-функции будет всегда дольше, чем просто в C cdecl + alloca локальные переменные в стеке + автоматическое прибивание при чистке стека при возврате.

другое дело, что можно не пытаться придумывать один-единственный универсальный lisp callconv на все случаи жизни (и усложнять рантайм), а наоброт, придумать несколько РАЗНЫХ lisp callconv (и усложнять генерацию таких вот эффективных моделей, во время компиляции; в пределе, макросами лиспа или чем-то вроде Clang AST matcher).

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

но для получения сравнимого результата надо писать не на идеоматическом CL, а на неподдерживаемом C-со-скобочками, с кучей (declare) и императивщеной.

но да, это будет уже не совсем лисп. а какое-то минималистичное эффективно компилируемое на уровне ABI/callconv подмножество.

Вообще у CL какой-то identity crisis - вроде динамический язык, а зачем-то пытается с С++ по скорости соревноваться.

скорее, есть два языка со своими недостатками: C++ и СL, и надежда на то, что недостатки одного компенсируются достоинствами другого:

имея один фломастер, можно закрасить почти всё, кроме него самого. имея два фломастера, можно закрасить вообще всё ;-)

например, был такой проект STELLA статья PDF

там похожая идея: берётся подмножество CL, похожее на С++. пишется какой-то метаязык STELLA на лиспе с макросами. затем из лиспа кодогенерируется код на C++/Java/whatever.

а тут похоже, только хотят LLVM обойтись.

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

ну sbcl,lispworks и ещё какой-то CL умеют промотить переменные в выделяемые на стеке.

оптимизаторопроблемы.

можна зделоть

можна, можна.

ну например, в COS есть бенчмарки, сравнивающие производительность объектных моделей COS/C++/Objective C.

COS вполне на уровне C++, при этом обладает гибкостью CLOS, а не Vtable и Fragile Base Class problem.

такшта: можнозделоть более эффективную ООП систему, чем С++, и при этом более гибкую, чем в С++.

один микробенчмарк.

ещё по оптимизациям, рантайму и тому же lto, например. ещё один.

ещё можнозделоть шаблоны, концепты и аспекты лучче, чем в с++.

когда таких микромелочей накопится достаточно большое количество, то то, что можнозделоть на CL + Clang AST matcher + «достаточно умный компилятор» зделоед этот ваш С++ по всем параметрам.

Python lisp, InterLib

ну например:

после Норвига только ленивый не писал свой недолисп на питоне. а вот если взять Nim (бывший Nimrod), то можнозделоть лучче, конпелируемей. и с AST макросами в Nim «из коробки».

А. Столяров, который недавно бабло на книжку собирал — написал в своё время диссер на тему InteLib — лисп, который макросами С++ разворачивается в С++. «метод непосредственной интеграции», вот.

если взять вместо C++ язык D, то можнозделоть человеческий CTFE, и нормальный язык с метапрограммированием, рефлексией и тайпинфо, а не С++ с костылями.

либо, если взять минималистичный недолисп на C++ и переписать его на Rust например (а не на D), реализовав плагин компилятора Rust.

то можнозделость трансляцию в LLVM «из коробки», через ржавчину.

много таких «можнозделоть», на самом деле.

можнозделоть.

протистую. где в этом вот можнозделоть язык D, например?

негодую.

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

нет, не на SBCL. в SBCL хоть оптимизации есть ;-)

интересно сравнить бенчмарки этого форка SBCL/LLVM, который три года как «можнозделоть» с Clasp/LLVM/ClangASTmatcher etc.

тут почитай оптимизаций что и нету — и надо же, всего в 4 раза тормоза, а не в 100, вот сюрприз-то какой :-)))

Столяров, редиска, куда-то исходники задевал. лучше бы он новую книжку в духе Literate Programming, используя только Emacs org-mode по реализации своего InteLib напейсал. наподобие того проекта mal, мультиязычнаго.

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

обмазаться списком литературы

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

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

лучше спроси, чем он от DaoLang отличается

Вот уже не первый раз заходил с Гугла на ЛОР по какой-то теме, а там царя умные люди по дерьму катают и всякую полезную инфу в процессе оставляют.

Вот уже 2-й раз ты пытаешься за сутки эту херню нести, но как и в первый раз ты обосрался - обосрёшься и сейчас.

Выкатывай мне темы в которых царя катают, с описанием в чем собственно катание заключается. Раз не первый раз - минимум две. Я жду.

интересно, есть сравнение с ecl? вроде бы Clasp это форк ecl

Подход у них разный. Еcl трнслирует лисп в С и скармливает С-шному же компиялтору. Таскать такую штуку для пользовательских скриптов очень накладно по сравнению с каким-нибудь питоном. А интерпретатор у Ecl очень слабый в большой степени для отладки. CLasp по идее мог бы обходтся минимальным LLVM без Clang.

Любая тема по ISA. Тему про HDL вообще можно на анекдоты разбирать.

Любая тема по ISA. Тему про HDL вообще можно на анекдоты разбирать.

Конкретней. Тему, цитатки - в чем обосрался.

Бери любую, ты везде обосрался.

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

На что ты рассчитываешь, убогий?

Языковый базис (комментарий)

> На Verilog можно писать исполняемый код, ламер ты дранный.
Вякнул про HDL - говори про хдл и не сливайся.

И не такая уж в русском языке и нестрогая семантика.

Лол.