Неосилятор ищет язык.

Про DSL надо читать только двух товарищей - Walid Taha и Martin Fawler. Все прочие глубоко вторичны.

> Именно по этому в 0,99 случаях он не нужен. Нужен не инструмент для создания решений, а одно частное решение.

Ага, молодец. Пиши build-скрипты на bash, на кой нужны всякие там инструменты типа make, scons, ant?

Из еще более недавнего: http://david.darais.com/assets/racket-macros.pdf

> Про DSL надо читать только двух товарищей - Walid Taha и Martin

Fawler. Все прочие глубоко вторичны.

Хм, Рэймонд тоже вторичен?

> Пиши build-скрипты на bash, на кой нужны всякие там инструменты типа make, scons, ant?

ну он же не сказал, что они вообще не нужны - 1%, где-то так оно и есть

Реймонд - это такой Фрезер, излагает доходчиво народное творчество. Собиратель сказок. А вышеозначенные товарищи создают новое знание.

> Про DSL надо читать только двух товарищей - Walid Taha и Martin Fawler. Все прочие глубоко вторичны.

Бгг. А ничего, что yacc, troff и прочие как бы не старше самого Фаулера? Или yacc и troff - не DSL?

В моей практике все наоборот - 1% того, что стоит делать на языках общего назначения, и 99% того, что лучше ложится на DSLы всех мастей (и кстати, perl это тоже такой DSL. И sed, и awk, и M4).

Люди тысячелетиями говорили прозой. Но пока не появились лингвисты, они этого не осознавали.

> В моей практике все наоборот - 1% того, что стоит делать на языках общего назначения, и 99% того, что лучше ложится на DSLы всех мастей (и кстати, perl это тоже такой DSL. И sed, и awk, и M4).

может я неправильно понял, но вроде он имел ввиду не кол-во кода на DSL, а написание новых

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

Мне и новые делать приходится регулярно, для каждой новой задачи как минимум один, чаще два-три. Они все примитивные, строятся как надстройка над одним или несколькими существующими, но по формальным признаком полноценные DSL (eDSL не увлекаюсь).

> Люди тысячелетиями говорили прозой. Но пока не появились лингвисты, они этого не осознавали.

После «Фаулер создает новое знание» я уже не стану спорить %)

> Но уж на порядок лучше чем все то дерьмо, которое остальное.

Я назвал примеры «того говна», которое обгоняет твой любимый sbcl. Заговор?

Для CL возможности оптимизации продолжаются там, где для говноязыков типа C# и C++ они заканчиваются.

И чо? В чём пассаж-то? Коммитить в шутаут можно кому угодно. Докажи свои слова, не будь говном.

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

Твои попытки завербовать взятием «на слабо» смешны.

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

Тесты всегда синтетические. На то они и тесты, елки. // Ваш К.О.

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

Ага, я вижу. То-то у тебя virgil'ов 20 штук, написанных на разных языках. И взятый с потолка вечный понос в сторону плюсов и сишарпа.

> Осилить мою библиотеку virgil, правда

привет love5an! все-также, как и положено лисперам, пишешь обертки к сишным библиотека?

Утверждаешь, что Фаулер вторичен? Ну, показывай, где все то же изложено более ранним автором. Он обобщил и систематизировал принятые в народе практики, а обобщение это и есть новое знание. Других путей получения нового знания человечество пока что не придумало.

> все-также, как и положено лисперам, пишешь обертки к сишным библиотека?

Не стоит обобщать.

> Не стоит обобщать.

извините, хотел поддеть тролля, и сам толсто потроллил

Ты потроллил не толсто, а просто глупо. Нет ничего плохого в написании оберток к библиотекам. Скриптовые языки на то и нужны, чтобы обертки делать, а Лисп очень неплохо подходит на роль скриптового клея. Почти так же неплохо как Python.

> Нет ничего плохого в написании оберток к библиотекам.

да, просто некоторые только этим и занимаются

Ну и что ж в этом такого? Зачем изобретать новое, когда можно собрать по быстрому из готовых кубиков?

> Зачем изобретать новое, когда можно собрать по быстрому из готовых кубиков?

так и надо делать, речь в том, что лицемерно ругать С и С++ на каждом шагу, хвалить CL, а при этом только и делать, что использовать код из сторонних библиотек на этих языках

>Я назвал примеры «того говна», которое обгоняет твой любимый sbcl. Заговор?

Оно не обгоняет SBCL. Одни реализации на Си обгоняют другие на SBCL.
Потому как на Си они вылизанные и используют ручное закатывание солнца. Такое можно и на SBCL написать, не вопрос. Можно даже лучше(и swizard писал). Только кому это надо? Те кто в оптимизации CL разбирается, как правило не дрочат на синтетические тесты.

А вот когда напишешь что-то подобное http://github.com/Lovesan/virgil которое бы имело сравнимую производительность, тогда и будешь пиздеть о тормозах.

И чо? В чём пассаж-то? Коммитить в шутаут можно кому угодно. Докажи свои слова, не будь говном.

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

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

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

Так уж повелось, что современные ОС предоставляют сишный интерфейс в своих API.

Называть это «сишными библиотеками», я бы, правда, не стал.

То, к чему я сейчас пишу биндинги, это не библиотеки, это системные API.

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

«Скриптовым» я бы его называть не стал.
Более того, для скриптов CL подходит плохо.

и еще раз - биндинг к системным api это не клей между библиотеками.

> Утверждаешь, что Фаулер вторичен?

Утверждаю, что никакого нового знания он не создал.

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

Давай ты покажешь, какое новое знание создал Фаулер.

Он обобщил и систематизировал принятые в народе практики, а обобщение это и есть новое знание.

Он назвал принятые практики эффектными терминами. Это маркетинг, а не новое знание.

Зачем так долго и длинно писать фразу «Сперва Добейся»?

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

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

Лисперы ругают C/C++ не за вообще, а за то, что их пытаются применить там, где надо применять «скриптовый клей» или просто язык более высокого уровня. Всему свое место. Системные библиотеки на Си, прикладуха - на ЯВУ.

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

> Системные библиотеки на Си, прикладуха - на ЯВУ.

GTK, cairo, Qt, Webkit и т.д. - системные библиотеки?

Естественно. GUI toolkit - это вообще очень низкий уровень, и чем на более низком уровне оно реализовано, тем лучше.

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

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

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

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

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

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

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

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

Альтернатива? Какая альтернатива-то?

разбираюсь в CL и имею представление о производительности кода, сгенерированного ведущими реализациями

И при этом считаешь, что легко можешь его сравнивать со «всем остальным говном»? :) Скажу по секрету, что недостаточно в одном sbcl разбираться, чтобы его сравнивать с clean или luajit, например.

P.S. Ну хоть говна поменьше уже лить стал, уже разговаривать с тобой можно.

>https://github.com/Lovesan/virgil

Сколько пользователей у твоего Виргила?

>И при этом считаешь, что легко можешь его сравнивать со «всем остальным говном»? :) Скажу по секрету, что недостаточно в одном sbcl разбираться, чтобы его сравнивать с clean или luajit, например.

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

Так, например, даже не особо разбираясь в Python и CL, но узнав, что
1) в python уебищный GC на подсчете ссылок, говно за которым подчищается mark-n-sweep сборщиком, а в большинстве реализаций CL - копирующие отслеживающие сборщики мусора
2) в python дебильная утиная типизация повсюду, а в CL есть опциональные декларации типов, которые помогают компилятору оптимизировать
3) python создавался, и продолжает развиваться «на коленке», а CL вышел из лабораторий ведущих американских институтов, кругов военных и крупного бизнеса
4) на оптимизацию компиляторов CL потрачено более 30 лет, а на оптимизацию Python - совсем практически нихуя

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

P.S. Ну хоть говна поменьше уже лить стал, уже разговаривать с тобой можно.

А с тобой все меньше - все большую хуйню несешь.

Откуда я знаю? Там как минимум 5 человек следит за его развитием.

А я его использую в LDX и Doors.

Рекомендую, кстати, попробовать самому.
Надо, правда, документацию таки написать.

> Надо, правда, документацию таки написать.

Йепик фейл!

как и наследование интерфейсов

кстати, интересно послушать как ты будешь решать такую задачу: функция, которая должна принимать объекты, реализующие как интерфейс A, так и интерфейс B (семантически разные) в C++

через наследование интерфейсов? смешивая два интерфейса в один? через шаблоны и static check'и? как?

> как ты будешь решать такую задачу:

функция, которая должна принимать объекты, реализующие как интерфейс A, так и интерфейс B (семантически разные) в C++

через наследование интерфейсов? смешивая два интерфейса в один? через шаблоны и static check'и? как?

через две разные функции с разным типом параметра

> через две разные функции с разным типом параметра

П.С. С++ такое позволяет, если вдруг и это не знаешь

> python создавался, и продолжает развиваться «на коленке», а CL вышел из лабораторий ведущих американских институтов, кругов военных и крупного бизнеса

на оптимизацию компиляторов CL потрачено более 30 лет, а на оптимизацию Python - совсем практически нихуя

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

через две разные функции с разным типом параметра

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

П.С. С++ такое позволяет, если вдруг и это не знаешь

хватит паясничать

Кретины(вроде тебя) как раз верят шутауту.

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

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

напиши пример, который подходит под твою задачу

struct ISerializable
{
  virtual void serialize() = 0;
};

struct IRunnable
{
  virtual void run() = 0;
};

struct IFetchable
{
  virtual void fetch() = 0;
  virtual void release() = 0;
};

...

struct ClassA : ISerializable, IRunnable, IFetchable
{
};

struct ClassB : ISerializable, IRunnable, IFetchable
{
};

struct Class C: IRunnable, IFetchable
{
};

...

bool invoke(SomeI * obj)
{
  bool res = obj->fetch();

  if(res)
  {
    res = obj->run();

    if(res)
    {
      obj->release;

      return true;
    }
    else
    {
      obj->serialize();
      History::getInstance->set(obj);

      return false;
    }
  }

  return false;
}

например, как-то так. объекты ClassA и ClassB могут быть обработаны в invoke, объект ClassC - нет

> объекты ClassA и ClassB могут быть обработаны в invoke,

Не могут.