CL быстрее прочих :)

> Лисперы, мне стало интересно, а на вашем языке реально написать операционную систему?

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

её гибель послужила во многом Герценом для Столмана.

> Посмотри код, который писал Питер Норвинг и сравни его с кодом postmodern, hunchentoot или iolib. Я не знаю как точно описать. Но возможно современный код более «технологичен» (что бы это не означало) и больше эксплуатирует идеи, которые являются общими для всех языков.

О да! хороший программист на (зачёркнуто фортране) «С/C++», на любом языке напишет код на «С/C++».

свободным короче не понять :)

брр... чтоб вот так, да за еду пришлось... брр...

> О да! хороший программист на (зачёркнуто фортране) «С/C++»,

на любом языке напишет код на «С/C++».

Я не понял, это Питер программист на "(зачёркнуто фортране) «С/C++»"?

А что такого криминального есть в коде из PAIP? Мне кажется много хороших вещей. Конечно многие выглядят эксцентрично, но это потому что там просто примеры - не целостные завершённые системы.

Про iolib - согласен. А вот hunchentoot - мне не нравится (не вообще подход к декомпозиции, а в деталях). И тоже - не знаю как точно описать :)

Значит, нужно читать iolib, postmodern, hunchentoot (ironclad, slime, cffi?)?

А какие выразительные средства CL из тех что есть в стандарте или из тех что могут быть введены (и во многом благодаря макро-системе) по твоему попадают под табу?

> чтоб вот так, да за еду пришлось... брр...

А что «брр»? Работа вполне5 может нравится. Сюрприз?

> Значит, нужно читать iolib, postmodern,

hunchentoot (ironclad, slime, cffi?)?

Всё, что сможешь прочитать. И не забывай про PHP ;) Я серьёзно.

А какие выразительные средства CL из тех что есть в стандарте или

из тех что могут быть введены (и во многом благодаря макро-системе)

по твоему попадают под табу?

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

К сожалению, лисп окружен всякими мифами. Наверно, самые главные:

1. Лисп НЕ является декларативным языком. Управление eval'ом не делает язык декларативным.

2. Лисп НЕ подходит для создания DSL. Потому что затрахаешься описывать семантику языка. Это также, как вручную писать парсеры методом рекурсивного спуска, их пишут, конечно, но очень редко.

Насколько я понимаю, «нью скулл» на понимании этих вещей и основан.

Зато на лиспе удобно работать с метаданными, зато на лиспе удобно обмениваться S-выражениями между частями программы или разными системами, зато на лиспе удобно взаимодействовать с разрабатываемой системой через REPL.

Лисп НЕ является декларативным языком. Управление eval'ом не делает язык декларативным.

Не буду говорить за всё семейство - но CL да, не является декларативным, не является функциональным и не имеет средств работы с Алг. ТД.

Лисп НЕ подходит для создания DSL. Потому что затрахаешься описывать семантику языка. Это также, как вручную писать парсеры методом рекурсивного спуска, их пишут, конечно, но очень редко.

Этого я не понял. Что сложного? Я про DSL на основе s-выражений, конечно - синтаксис не играет роли (тот что нужно разбирать нисходящими или восходящими методами разбора), так как в конце концов у нас будет AST, AST этот представляется в виде s-выражений. Я видел разные DSL - в asdf (archimag тут не согласен так как называет «языком» то «на чём можно вычислять», а я называю языком множеством цепочек над словарём), в макросах SBCL, определяющих виртуальные операторы, или инструкции ассемблера. Конечно это очень специального вида DSL - например некий кусок AST никак не помечается тэгом типа данного поддерева AST. В этом смысле, для построения DSL (опять - говорим за семантику, синтаксис по боку) над тэгированным AST нужны ADT и pattern-matching - в этом смысле Haskell подходит гораздо больше, говоря за себя - мне этих возможностей не хватает, но я знаю как их можно ввести, просто такой мотивации нет.

Да ты вообще любой макрос называешь DSL-ем

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

Тем не менее - видя некоторый код, например тот что написал swizard для блинчиков, ты считаешь что это «no way», получается табу, потому что он ведь вполне рациональнален - в блоге у него описывается подход к генерации кода в рантайме.

Или вот регулярные выражения (по Томпсону) - чем не общепризнаный аналог подхода swizard (или наоборот - swizard использует этот известный подход)? По строке (списку представляющего семантику строки, что бы ни говорил Macil) строится конечный автомат (со входом и выходом) - т.е. натурально генерация кода в рантайме, с последующей компиляцией.

Даже в cl-closure-templates было что-то подобное :) (компиляция шаблонов).

Да ты вообще любой макрос называешь DSL-ем

Не любой, а тот что имеет явный или неявный definition для семантики своих аргументов. Например aif - просто макрос, там просто делается код в который подставляются аргументы (без вычисления). А вот в asdf или в defpackage макрос имеет стадию семантического анализа своего аргумента (того в котором все эти :depends-on и т.д.). Технически это наличие анализирующего кода до back-quote или даже набора анализирующих функций (сотни строк кода, между прочим) рядом с макросом - то что в SBCL обзывают foo & friends.

> видя некоторый код, например тот что написал swizard для блинчиков,

ты считаешь что это «no way», получается табу, потому что он ведь

вполне рациональнален -

Он «no way» потому, что жутко не рационален. Он для того, что бы побить Java пишет кода больше, чем соответствующее решение на Java. Он жутко усложняет решение и заморачивается с типами. Вот если бы он написал столько строк, сколько было в решении на Python, а понять их было бы ещё проще, а при скорости это было бы быстрее, чем Java, вот тогда было бы круто. Да только сказок не бывает. А так.. я стараюсь матом не ругаться, поэтому промолчу.

Даже в cl-closure-templates было что-то подобное :)

(компиляция шаблонов).

Конечно, там ведь это самое простое решение. Гораздо проще генерировать код на CL (который и работать будет заметно быстрее), чем писать интерпретатор (медленный).

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

Некоторый паттерн-матчинг в CL все же есть - обобщенные функции и destructuring-bind
Ну и, можно написать. И даже нечто большее, чем паттерн-матчинг - cl-unification etc.

А ты попробуй. Только не простеньких hello word'ах, а на реальных задачах. Когда требования пересматриваются, когда приходится править написанное и при этом умудриться не порушить интерфейс взаимодействия, когда по прошествии времени DSL приходится расширять.

Когда пытаешься разобраться в хитросплетениях макросов, ловить ошибки когда что-то не так заквотил, ловить ошибки преобразования типов. Или когда что-то поменял, а ничего не работает и ты не понимаешь ЧТО ИМЕННО ТЫ ПОМЕНЯЛ. Дурацкое ощущение, на самом деле.

Опять же, повторюсь, на лиспе это можно сделать. И проверки статические. И анализ. И оптимизации. Но трудозатраты...

Для «нормального» DSL нужен язык, который может удобно и просто склеивать куски программы. Но не на уровне макроподстановок, а на уровне неявного управления потоком. И без системы статического анализа тут ну никак не обойтись. И без разницы что это за язык.

Хотя DSL DSL'у рознь, конечно. Мое мнение, DSLы предназначены для сборки и манипуляции объектами предметной области. Для кого-то это может и не так.

Ну это я сразу сказал - я обеими руками за то чтобы можно было в «обычных» программах писать прозрачный и очевидный код, без типов и без заморочек. Только вот он не будет быстрее (джавы, хацкеля и, возможно, плюсов), и дело тут не в сказках, а в том что быстрее он будет только если вбухивать огромное количество разного матана в компилятор. Т.е. два варианта - либо писать просто и прозрачно, не думать о производительности, либо изголяться в «обычных» программах, либо ждать когда разработчики компиляторов воспримут новые идеи. Но только воспримут ли они их - это вопрос, так как некоторые вещи могут законфликтовать с самим стандартом (предположительно, может и нет).

Что мешает писать на C? Быдет и быстрее и проще, чем у swizard. Я на CL пишу не для того, что бы с Java в скорости соревноваться.

нет, не Питер :)

лошадь вращающая жернов... знакомая история :(

Некоторый паттерн-матчинг в CL все же есть - обобщенные функции и destructuring-bind

Это паттерн-матчинг для АТД вида список, ещё кое-какой, более правильный, паттерн-матчинг есть в методах CLOS. Но вот их могут избегать из-за соображений производительности (хотя их оверхед - это не необходимость, просто это связано с остальной частью CLOS).

Настоящий паттен-матчинг неразрывно связан с АТД. Например:

(defdata (list a) nil (cons a (list a)))

Должен генерировать последовательность (в данном случае - две) объявлений defstruct, которые должны регистрировать конструкторы, придикаты, акессоры (что они и делают). И потом:

(defun last (nil) nil)
(defun last ((list x)) x) ;; или (defun last ((cons x nil)) x) 
(defun last ((cons x xs)) (last xs))
;; и сравнить с last из sbcl/src/code/list.lisp :)

И так для всевозможных видов defdata.

И ещё

(defun foo ((list list) (number a))
  ...)

(defun foo (1 'a)
  ...)

Тут прописаны типы, как в методах CLOS, но уже в смысле declare, и функции от атомов, как eql в CLOS. При наличии одной функции foo - это просто функция, при наличии большего числа - должна быть generic функция foo, которая содержит case/typecase и вызовы спецификаций foo, каждая из которых инлайнится. При определении ещё одной спецификации происходит переопределения всех других и дженерика.

Ну и, можно написать.

Это даже не очень сложно сделать, но это не станет тут же общепринятой практикой при написании программ.

Что мешает писать на C?

Ну мне приходилось - это больно и скучно :)

Быдет и быстрее и проще, чем у swizard.

Не факт ведь. Возьмём тот же шутаут - почему программы на C++ там иногда оказываются быстрее программ на C? Потому что шаблоны, то же самое с CL - если используется подход как у swizard-а в блинчиках - на C++ не получится построить такой шаблон, а на Си вообще ничего сделать нельзя. Выгрышь си только в том что программы типизированы, можно сказать, регистрами, разделяемой памятью и т.д.

>Только вот он не будет быстрее

О, это слово «быстрее». Дорога, ведущая в ад вымощена намерениями преждевременной оптимизации.

Да что там говорить, даже сложность алгоритма может оцениваться в «амортизированном» виде.

В реальном проекте «скорость», вообще понятие абстактное. Можно пожадничать 5% производительности, а потом получить кучу геморроя из-за хреновой расширяемости. Потому что требования меняются, потому что предметная область не стоит на месте.

Да, во всяких там числодробильнях все по-другому. Но мы же не числодробильни пишем!!! Мы пришем программы, с которыми НАМ В ТОМ ЧИСЛЕ должно быть приятно работать.

Например в asdf defsystem вызывает parse-component-form о ста сторках (вместе со вспомогательными функциями). parse-component-form занимается семантичесим разбором DSL мароса defsystem и, по Кнуту, семантическими атрибутами являются %define-component-inline-methods, %refresh-component-inline-methods и %remove-component-inline-methods.

> нет, не Питер :)

А кто? Еди и Стелиан? Люди, сделавшие для развития и популяризации CL гораздо больше?

Я опять ничего не понял. Нельзя как-нибудь проще выражаться?

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

вон простоял весь исторический материализм элеватор без гвоздей... только демократы спалить осилили :)

> Ну мне приходилось - это больно и скучно :)

Пиши на C++ - это здорово и весело.

Быдет и быстрее и проще, чем у swizard.

Не факт ведь

Факт, факт, не сомневайся. А С и С++ компилируют одним и тем же компилятором, на разработку которого брошены огромные силы, они и могу между собой соревноваться.

ну что за «включание дурака», веди себя прилично блин :(

конечно прикинуться «дохлым вонючим и не вкусным» тоже тактика... например опоссум так поступает :)

Мы пришем программы, с которыми НАМ В ТОМ ЧИСЛЕ должно быть приятно работать.

Всё верно, я уже сказал что тоже так считаю, если передо мной стоит задача, то прежде всего хочется написать простой и логичный (т.е. расширяемый) код. А когда я говорю слово «быстрее» я имею ввиду тех людей что пилят GCC, GHC или SBCL и о фанах с этим сопряжённых :) Они ведь явно не успокаиваются - вроде всё работает, но попытки оптимизировать и улучшить методы трансляции продолжаются. Ну а некоторые не ждут «серебрянной пули» и пытаются делать оптимизации в user-level (user - пользователь языка/реализации).

facepalm.jpg

Эди!
Полное имя - Эдмунд.

> тебе показали что можно при помощи топора и без гвоздей...

сразу стоны: как же мне без вагонки непривычно...

Мне показали, что решение на CL получается больше (в объёме) и гораздо сложней, чем на Java. Спасибо, я голосую за бетономешалку, подъёмный кран и Python.

вон простоял весь исторический материализм элеватор без

гвоздей... только демократы спалить осилили :)

Хм, ты вообще адекватен?

Пиши на C++ - это здорово и весело.

После знакомства с великим и могучим?) Я когда читал Шилдта себе небольшое хобби изобрёл, писал карандашём на бумажке - «это надо было сделать так...», «а это совсем нерационально сделано, так как...».

Факт, факт, не сомневайся.

Плох тот макрописатель что не мечтает сгенерировать код заруливающий gcc ;)

> Ну а некоторые не ждут «серебрянной пули» и пытаются делать

оптимизации в user-level (user - пользователь языка/реализации).

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

> Я когда читал Шилдта себе небольшое хобби изобрёл

Зачем макулатуру разную читаешь?

Плох тот макрописатель что не мечтает сгенерировать код

заруливающий gcc ;)

Удачи. А я лучше чем-нибудь полезным займусь.

Зачем макулатуру разную читаешь?

Ну не Страуструп конечно, да. Но то как всё устроено в C++ от этого не меняется.

Плох тот макрописатель что не мечтает сгенерировать код заруливающий gcc ;)

Удачи. А я лучше чем-нибудь полезным займусь.

Да я сам не очень-то этим заниматься хочу. Просто заметил что подход swizard-а при программировании (ну по крайней мере судя по хамелионам, блинчикам и пасьянсу) это *) dsl представление, *) генерация кода по dsl который должен именно что зарулить в плане производительности.

А некоторые просто покупают более мощное железо.

А мне постоянно кажется что emerge медленно работает (с чего бы это?). Какое железо мне прикупить ?)

Почитай Рэймонда «Искусство программирования под Unix», там отличная глава про DSL, и придумали это вовсе не для повышения производительности.

> Какое железо мне прикупить ?)

http://www.apple.com/macpro/

Доктор, же. Доктор Эдмунд Вейтзъ.

> А мне постоянно кажется что emerge медленно работает

(с чего бы это?).

Тогда переходи на Debian, там будет быстрее. Я использую Gentoo не ради производительности.

И всё равно оно будеть тормозить, потому что Python не умеет распоралеливать не параллельно написанные алгоритмы по ядрам.

Тогда переходи на Debian, там будет быстрее. Я использую Gentoo не ради производительности.

Мне нравится gentoo, но приходится терпеть питоньи тормоза, конечно не очень большие, это было к тому что «прикупить железо» не всегда решает проблему, например когда суествует оверхед на два порядка, и порой её решает именно какая-либо оптимизация (некоторые оптимизации это неявное преобразование плохих алгоритмов в хорошие - профит же, пишешь просто, оптимизатор делает из «просто» «быстро»).

У меня через день обновляется Chromium и это реальные тормоза. А emerge работает быстро, по крайней мере, на фоне компиляции нужных пакетов. Каких-либо претензий к emerge у меня нет.

А `emege --search ...` или `emerge -vp ...` даёт ответ мгновенно? Dот есть же paladis - зачем-то переписывают emerge на C++.

> А `emege --search ...` или `emerge -vp ...` даёт ответ мгновенно?

Мне мгновенно не надо.

Dот есть же paladis - зачем-то переписывают emerge на C++.

Делать людям нечего.

emerge тормозит не из-за питона, а из-за portage tree. Paludis, написаный на c++ тормозит так же (по субъективных ощущениях). Реальное ускорение даёт запихивание дерева в squashfs либо sqlite.

Реальное ускорение даёт запихивание дерева в squashfs либо sqlite.

А это реально сделать для обычного emerge, может есть какие-нибудь проекты?

>это реально сделать для обычного emerge

Да, поищи на gentoo-wiki или ещё где.

> Скучно же, целые сутки прошли, а всего 5 страниц.

плюсую, унылый какой-то лиспосрач.