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

Ну, а теперь в чём обсёр-то?, объясни. Ну спастил ты - и?

А ты кто такой чтобы я тратил на твое жалкое существование драгоценные секунды моего времени?

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

Если на один модуль бросается больше 10 человек, то что-то не так в консерватории.

Современный браузер с поддержкой HTML5 сделаешь силами 10 человек?

Или как разобьёшь на модули обработку HTML + CSS (JS ещё с горем пополам можно отделить)?

С модулями/плагинами даже без RPC особых проблем нет. Так как функционально ядро должно работать без модулей, то можно тестировать отдельно ядро, разработчик модуля тестирует ядро + его модуль. И интеграционный тест ядро + все модули, чтобы убедится, что нет взаимного влияния модулей.

А вот что делать, если ядро достаточно сложное? Таких задач много: СУБД, браузер, графический интерфейс (может поэтому нет ни одного полнофункционального графического пользовательского интерфейса, так как в одиночку сделать нереально, даже если делать FFI к GTK)/

Современный браузер с поддержкой HTML5 сделаешь силами 10 человек?

Если судить по Servo - да.

(JS ещё с горем пополам можно отделить)

Если судить по Webkit и тому же Servo, JS можно отделить без горя.

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

А уж как ты в теме про теплопроводность себя выставил тупым уебаном!

Короче, выблядок - без кода ты никто. Пустое место. Запиздевшийся шизофреник. И никак иначе тебя никто и нигде не воспринимает.

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

И опять же обосрался везде, но нигде конкретно. Ты конкретно пасти тему и конкретно объясняй в чем заключается «закатка». Ну и как всегда враньё. Я жду цитатки от меня, в которой написано - «фикспоинт якобы всегда и везде лучше плавучки».

А уж как ты в теме про теплопроводность себя выставил тупым уебаном!

Меня не интересует оценка меня каким-то нулём. Ты мне конкретно выкатывай, в чем выставил и почему.

Короче, выблядок - без кода ты никто. Пустое место. Запиздевшийся шизофреник. И никак иначе тебя никто и нигде не воспринимает.

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

И да, меня не интересует как там меня воспринимает нулёвая балаболка.

Кстати, почему про этого пациента нет до сих пор статьи на лурке? Давно уже пора.

силами 10 человек?

Если судить по Servo - да.

https://github.com/servo/servo: 292 contributors

И незакрытых ошибок ещё очень много

Если судить по Webkit и тому же Servo, JS можно отделить без горя.

Да? Ты сможешь собрать Webkit с JS-интерпретатором из Servo?

Если судить по Servo - да.

И даже у одного файла https://github.com/servo/servo/blob/master/components/script/dom/node.rs целых 46 разработчиков. В CL я бы не рискнул такой толпой разрабатывать один пакет.

И даже у одного файла https://github.com/servo/servo/blob/master/components/script/dom/node.rs целых 46 разработчиков

46 авторов. Сколько из них разработчиков - это надо смотреть.

Если судить по Webkit и тому же Servo, JS можно отделить без горя.

Да?

Да.

Ты сможешь собрать Webkit с JS-интерпретатором из Servo?

Что за дешевая демагогия.

CL я бы не рискнул такой толпой разрабатывать один пакет.

делишь задачу на множество атомарных минизадач. Реализация каждой минизадачи в субпакет. Эти субпакеты могут быть вложены на любую глубину. Наружу вытаскиваешь только интерфейс субпакета, внутри пакета — реализация --> все шито крыто. В принципе как на любом другом ЯП. man S.O.L.I.D.

делишь задачу на множество атомарных минизадач.

Это как раз понятно. Но многие проекты не делятся (по алгоритму) на атомарные минизадачи. Эти «минизадачи» взаимозависимы, причём на уровне реализации.

46 авторов. Сколько из них разработчиков - это надо смотреть.

Эти 46 человек меняли этот файл напрямую (не через pull request).

Ты сможешь собрать Webkit с JS-интерпретатором из Servo?

Что за дешевая демагогия.

Я лишь хотел намекнуть, что JS-интерпретаторы в Servo и Webkit достаточно тесно привязаны к реализации внутреннего состояния браузера.

JS-интерпретаторы в Servo и Webkit достаточно тесно привязаны к реализации внутреннего состояния браузера.

Например, https://github.com/servo/servo/commit/a3eaacccf60fc05f43f353e859ae2807cec12f59

Приходится одновременно согласованно менять модули compositing, layout, script.

46 авторов. Сколько из них разработчиков - это надо смотреть.

Эти 46 человек меняли этот файл напрямую (не через pull request).

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

Я лишь хотел намекнуть, что JS-интерпретаторы в Servo и Webkit достаточно тесно привязаны к реализации внутреннего состояния браузера.

Да. Тем не менее, движок JS от Firefox используется в Servo. Если у тебя есть данные о том, что движок пришлось для этого сильно модифицировать - поделись.

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

Если servo/components/script не считать частью JS движка, то можно считать, что движок независим.

А если считать, то можешь сам посчитать файлы и строки в этом модуле.

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

Я только в июле 13 разных комитящих человек насчитал. Речь про то, что в CL гораздо проще всё случайно сломать. А капля дёгтя легко портит бочку мёда. Для Java/C#/Rust при настроенном автоматическом тестировании можно давать доступ почти всем. В Common Lisp или Ruby — как было сказано выше только очень дисциплинированным.

Но многие проекты не делятся (по алгоритму) на атомарные минизадачи.

Назови хоть один.

Эти «минизадачи» взаимозависимы, причём на уровне реализации.

уровне реализации

Т.е., сначала на стали разбивать на «атомарные минизадачи», а потом оказалость, что взаимозависимость «на уровне реализации»

Назови хоть один.

Рендеринг HTML + CSS. Компоненты есть, но тесно связанные: Например, https://github.com/servo/servo/commit/a3eaacccf60fc05f43f353e859ae2807cec12f59

Приходится одновременно согласованно менять модули compositing, layout, script

Рендеринг HTML + CSS

"(по алгоритму)" прекрасно делится «на атомарные минизадачи»

«на уровне реализации» - вопрос к архитекторам программы (возможно из серии «имеют ли право на существование перловые однострочники?»)

Компоненты есть
модули compositing, layout, script

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

Это как раз понятно. Но многие проекты не делятся (по алгоритму) на атомарные минизадачи. Эти «минизадачи» взаимозависимы, причём на уровне реализации.

изобретаете аспекты и AspectL ?

«на уровне реализации» - вопрос к архитекторам программы

Так по факту все программы такие. Единственный вариант получить действительно независимое разделение на модули — спроектировать структуру модулей и все структуры данных в их API до начала написания программы. По этому пути пошёл GNU Hurd. Результат известен: DMA, IRQ и прочие «особенности реализации» просачиваются сквозь идеальную архитектуру и не имеют в рамках этой архитектуры красивого решения.

А во всех остальных случаях межмодульное API развивается итеративно: как только от некоего вида модулей (или некоему виду модулей) понадобилась дополнительная информация, приходится переписывать API, «stable API is nonsense» (c).

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

Так по факту ...

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

Поэтому приходится ... или лазить не только в свой модуль ...

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

Таким образом (c), опять имеем не алгоритмические ограничения, а плохое проектирование. То есть, опять не понятно (см. начало) чем лисп хуже (для проектированя и рефакторинга) крестов или жабы.

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

... и назвать его микроядро. Я же про Hurd и Linux (с stable API nonsense) потому и привёл в пример.

имеем не алгоритмические ограничения, а плохое проектирование

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

Спроектировал, например, что коллекция объектов — массив. А потом выясняется (в реализации одного из модулей), что необходим поиск по полю. Превращаем в объект с индексом или хэш. И меняем всюду aref на get-by-id.

Кстати, возвращаясь к CLOS.

Есть

(defclass node ...)

(defclass a ...)
(defmethod foo ((a a) (node node) ...) ...)

(defclass b (a) ...)
(defmethod foo ((b b) (node node) ...) ...)

Теперь я делаю наследника node и мне надо другое поведение. Что-то вроде

(defclass subnode (node) ...)

(defmethod foo (obj (subnode subnode) ...)
   ...)

Но для этого мне придётся скопипастить этот метод для каждого класса, для которого есть специализация по первому аргументу, не так ли?

(defun my-func (obj subnode ...) ...)

(defmethod foo ((obj a) (subnode subnode) ...)
   (my-func obj subnode))

(defmethod foo ((obj b) (subnode subnode) ...)
   (my-func obj subnode))

...

И при добавлении новых потомков класса a не забывать добавлять методы к subnode...

Или по не-первому аргументу переопределение не подразумевается?

А MOP в каждой конкретной ситуации не поможет?

Давай начнём с начала ;) А начало в твоём споре с Oxdeadbeef, где он утверждает, что проект можно разбить на модули, каждый из которых разрабатывает не более 10 человек (<offtop>я считаю, что 10 человек на модуль - слишком много</offtop>). Ты утверждал что «многие проекты не делятся (по алгоритму) на атомарные минизадачи». Я попросил привести пример хотя бы одной подобной задачи.

Меня на самом деле интересует пример проекта, который невозможно разделять на модули.

Кстати, возвращаясь к CLOS.

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

Меня на самом деле интересует пример проекта, который невозможно разделять на модули.

Теоретически — можно разбить любой. но для этого необходимо или готовое решение или архитектор-пророк. Практически — любой проект с большим числом внутренних связей: например, браузер. Или, например, компилятор C++.

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

Почему же тогда не пишут на CL?

... необходимо или готовое решение или архитектор-пророк...

Достаточно желания и дисциплины. Методы начал разрабатывать ещё Дейкстра.

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

Почему же тогда не пишут на CL?

<Здесь смайл с ОГРОМНЫМИ от удивления глазами>

1. Пишут. 2. ЦПП и жаба - многомиллиардный бизнес, ЦЛ - просто инструмент, хоть и очень мощный. 3. ЦЛ требует большей самодисциплины, чем мейстримные ЦПП и жаба, что и определяет выбор языка для программ требующих широкой поддержки и/или массового распространения.

ЦПП и жаба - многомиллиардный бизнес

Ну давай сравним с Python. Или даже Objective C или Haskell.

За 2012-2014 годы на github по ним всем рост в 2.5-3.5 раз.

По CL — всего в 1.5 раза.

ЦЛ требует большей самодисциплины

От ВСЕХ разработчиков, участвующих в проекте. Что сильно ограничивает количество возможных разработчиков.

Ну давай сравним с Python. Или даже Objective C или Haskell.

Python - один из самых низких входных уровней, наряду с ПХП.

Objective C - а на чём ещё можно прогать для тыблока?

Haskell - новомодная игрушка, плюс мейнстрам маргиналов.

Что сильно ограничивает количество возможных разработчиков.

Да и вообще, умных мало. :( Однако, это не доказательство _невозможности_ создания на лиспе больших проектов.

Решение о том, на каком языке разрабатывать _крупную_ систему никогда не принимают программисты. Принимают чиновники, финансисты, манагеры, да хоть кто, только не программисты. И главным критерием является не удобство разработки, и даже не удобство сопровождения, а кто будет отвечать в случае провала проекта. Любая не мейнстримная технология основной кандидат на обвинение в провале, остальные причины никто даже рассматривать не станет. Так как теоретически фейл имеет не нулевую вероятность (по независящим от языка причинам), а козлом отпущения никто стать не стремится, то и выбор технологий очень ограничен.

Однако, это не доказательство _невозможности_ создания на лиспе больших проектов.

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

То есть для 1-5 программистов при равной зарплате за равную квалификацию проект на CL будет в 3-4 раза дешевле, чем на Java (меньше бойлерплейта, проще отладка). Но для 100 программистов уже наоборот (все 100 программистов на CL должны иметь высокий уровень дисциплины, если новый человек в проекте оказался неподходящий, ошибки могут быть нелокальны). Кроме того в Java можно заменить 10 хороших программистов на 50 кодеров и всё равно получить правильно работающий результат. В CL — ложка дёгтя легко портит бочку мёда.

Haskell - новомодная игрушка, плюс мейнстрам маргиналов.

Ладно. Возьмём FORTRAN и Scheme. Тоже на http://githut.info/ в наличии трёхкратный рост.

А сравнимая с CL скорость роста только у Erlang и ActionScript.

Ладно. Возьмём FORTRAN и Scheme. Тоже на http://githut.info/ в наличии трёхкратный рост.

https://github.com/favadi/repository_with_highest_number_of_commits

Ладно. Возьмём FORTRAN и Scheme. Тоже на http://githut.info/ в наличии трёхкратный рост.

http://githut.info/

Ты говорил, что сложность разработки на CL и Ruby очень высока с ростом количества мака^Wразработчиков — Ruby занимает 6-е место среди мэйнстримовый язычков (по твоей ссылке), оставляя позади другие мэйнстримовые язычки. Что же из этого следует?

А сравнимая с CL скорость роста только у Erlang и ActionScript.

И да, всем срочно переходить на модный JavaScript!

Ruby занимает 6-е место среди мэйнстримовый язычков

А относительная скорость роста — с 76900 по 132800 репозитариев. Как у CL.

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

https://github.com/favadi/repository_with_highest_number_of_commits

Я не комиты, а репозитории считаю. Люди пишут новые программы на том, что считают удобным.

всем срочно переходить на модный JavaScript

Это да! Вон, anonimous (или как его) всё на ЛОРе рекламирует :-)

всем срочно переходить на модный JavaScript!

К слову, можно сравнить его с CL.

CLOS есть: http://lisperator.net/blog/multiple-inheritance-and-multiple-dispatch-in-java...

Макросы есть: http://sweetjs.org/

Даже генераторы есть: http://taskjs.org/

Что у нас ещё есть в CL? Разработка в образе? В JS также можно динамически подгружать новую версию функции на ходу. Разве что нет такой хорошей интеграции с Emacs

Вот я и говорю, все там будем. Срочно всем начинать не расты с хаскелами и гошками задрючивать, а на технологии будущего — JavaScript. Иначе без работы останетесь.

// seriously

но их присутствие, в большинстве случаев, больший fail.

Хм. Странно называть это fail-ом. Есть технологичная фича. Ей можно пользоваться, можно не пользоваться. В чем же заключается fail?

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

Легко. Диспетчеризация по двум аргументами, один из которых специализируется через EQL - вещь распространённая. Я вот пишу binding к Tcl/Tk. Свойства виджетов читаются и записываются средствами метода (option prop-keyword widget ...) и (setf (option prop-keyword widget ...)) соответственно. prop-keyword - EQL-специализатор. Такая организация работы со свойствами удобна: когда нужно установить сразу несколько свойств, не нужно создавать таблицу из методов, ну или перечислять методы.

Почему же тогда не пишут на CL?

На CL не пишут по причине скобок, а не по причине гибкости. Что поделать, людям подавая синтаксис.

(option prop-keyword widget ...) и (setf (option prop-keyword widget ...))

Fix. (option prop-keyword widget) и (setf (option prop-keyword widget) ...)

На CL не пишут по причине скобок

1+

хоть один пример, где специализация по двум аргументам была по делу

Свойства виджетов читаются и записываются средствами метода (option prop-keyword widget ...) и (setf (option prop-keyword widget ...))

Ты переопределяешь этот метод по каждому prop-keyword и по подклассам widget?

Чем это лучше, чем widget.options[prop-keyword]? Или в рамках методов: widget.get_option(prop-keyword) + widget.get_option(prop-keyword, value)? Или предполагается, что для каждого свойства метод доступа индивидуальный и могут добавляться новые свойства у уже определённых виджетов?

Ты переопределяешь этот метод по каждому prop-keyword и по подклассам widget?

Да. Там где это необходимо.

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

Именно.

На CL не пишут по причине скобок, а не по причине гибкости

Да ладно! Lisp (комментарий) — профессиональный лиспер не смог прочитать библиотеку, написанную другими профессиональными лисперами.

И такое сплошь и рядом: iterate не дружит с cl-containers, классы и методы Gtk не дружат с CLOS, для нормального наследования приходится выворачивать CLOS наизнанку и отказываться от проверки типов.

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

Да. Там где это необходимо.

Именно

Этот код где-нибудь можно посмотреть? Я всё равно никак не могу понять, почему недостаточно одного метода на все свойства.

Этот код где-нибудь можно посмотреть? Я всё равно никак не могу понять, почему недостаточно одного метода на все свойства.

Да, конечно будет можно. Но не прямо сейчас. Мне нужно ряд вещей довести до ума. Как открою код, отдельной темой дам знать обязательно.

Да ладно! Lisp (комментарий) — профессиональный лиспер не смог прочитать библиотеку, написанную другими профессиональными лисперами.

Такое во всех сообществах сплошь и рядом. CL сообщество особо ничего в этом смысле не отличается. Одним разработчикам не нравится код написанный другими разработчиками. Вот так новость.

iterate не дружит с cl-containers

Ну и не беда. Iterate и cl-containers писались разными людьми в разное время, естественно без учёта друг друга. Только вот мне не кажется, что подобная несовместимость какая-то особенность Common Lisp. В других сообществах всё тоже самое. Другое дело что качественных библиотек в CL действительно не хватает. Но сейчас ситуация потихоньку исправляется ввиду Quicklisp и усердного Xach-а. Мне кажется, с вашим опытом вы также многое смогли бы принести хорошего и качественного в сообщество. Но почему-то вдруг вам разонравился CL и вы начали выдумывать синтетические проблемы :) Ай-ай-ай.

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

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