Ну, может быть уже все в курсе, один я такой кретин

Unimperative Programming Language Library
public domain
by Christopher Diggins, 2005

Unimperative is a functional and procedural programming language
which is also Valid C++. Unimperative requires the Object Oriented Template
Library available freely from http://www.ootl.org

Примерно тут лежит

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Ну, может быть уже все в курсе, один я такой кретин

ЗХ>Примерно тут лежит
Недавно проскакивало похожее.

Вот вы не улыбайтесь тут, а лучше расскажите — может ли это быть как-то практически применено?
Или это так, приколы?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Вот вы не улыбайтесь тут, а лучше расскажите — может ли это быть как-то практически применено?
ЗХ>Или это так, приколы?

Вопрос философский, если учесть, что для большинства все не-мэйнстримовые языки — "это так, приколы".
Лучше задать его авторам:
http://www.intelib.org/faq.html

Why do I need it?
In almost every serious project there are little annoying subtasks which you could implement in minutes using another programming language, but you've got to waste hours, days or even weeks to implement them within the project's only language (typically C++). Suppose for example you've got an equotion and you need to differentiate it. The task is solved in at maximum two or three hours if you program in Lisp. It takes no less than a day if you're using pure C++.

With InteLib, you can do it in C++ just as if you were coding in Lisp. And you actually don't need any Lisp for it. It's all C++.

When do I need it?
InteLib will be useful for you if you work with C++ and you know Lisp. It is primarily intended for people who are able to see that something is better to be implemented in one of the alternative languages than in pure C++. And you only can do such a conclusion if you know what Lisp or Prolog or whatever is and what can it do.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Вот вы не улыбайтесь тут, а лучше расскажите — может ли это быть как-то практически применено?
ЗХ>Или это так, приколы?

Практически? Имхо, вряд ли. Скорее -- это нужно для доказательства закона Гринспуна о том, что влюбой сложной C++ программе есть пусть слабенькая, но реализация интерпритатора Лиспа.

Здравствуйте, Глеб Алексеев, Вы писали:

ЗХ>>Вот вы не улыбайтесь тут, а лучше расскажите — может ли это быть как-то практически применено?
ЗХ>>Или это так, приколы?

ГА>Вопрос философский, если учесть, что для большинства все не-мэйнстримовые языки — "это так, приколы".

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

ГА>

ГА>Why do I need it?
ГА>In almost every serious project there are little annoying subtasks which you could implement in minutes using another programming language, but you've got to waste hours, days or even weeks to implement them within the project's only language (typically C++). Suppose for example you've got an equotion and you need to differentiate it. The task is solved in at maximum two or three hours if you program in Lisp. It takes no less than a day if you're using pure C++.

Затем код с подобным лиспом попадает ко мне. Я не знаю Лиспа, но программу нужно сопровождать. Изучаю Лисп. Понимаю, что это не тот Лисп, который я изучил. Изучаю эту реализацию Лиспа в С++. Только после этого понимаю, что же здесь происходит. Затем надеюсь, что моих знаний в Лиспе и возможностей этой реализации Лиспа будет достаточно для внесения нужных модификаций. ПАВБЫВАВБЫ!

Мне больше нравятся два альтернативных сценария:
— переписать подобное издевательство на чистом C++;
— послать все подальше, отказаться от этого проекта и вообще уйти в более вменяемую контору.

Имхо, чем делать на C++ какой-то DSL, лучше воспользоваться языками, более для этого приспособленными. Например, вставлять в специальных комментариях код на каком-то скриптовом языке, затем проводить кодогенерацию и получать чистый C++ (см., например, Re: DSL внутрях C++.

Автор: eao197
Дата: 16.09.05

). Тогда тому, кто не знает DSL придется выучить только скриптовый язык, но не придется изучать, как этот скриптовый язык был выражен с помощью C++ конструкций.

Либо вообще встраивать в C++ интерпритатор скриптового языка, благо для Lua/Python/Ruby это без проблем делается.

Здравствуйте, eao197, Вы писали:

---------- SKIP-----------------

E>Либо вообще встраивать в C++ интерпритатор скриптового языка, благо для Lua/Python/Ruby это без проблем делается.

Sorry что вмешиваюсь, но и для самого С/C++ это встраивание без проблем
делается с помощью CINT, т.к. все вышеназванные языки С-подобные. IMHO.

Удачи !

Здравствуйте, eao197

Постараюсь на этот раз не впадать в философские дебри.

Сначала давайте поинтересуемся, кто авторы вышеназванных библиотек?
Christopher Diggins (автор Unimperative) — независимый консультант, пишет в C/C++ User's Journal и www.artima.com, изобретатель и пока единственный пользователь языка Heron.
Андрей Викт.(орович?) Столяров (автор InteLib) — сотрудник кафедры вычислительной математики и кибернетики МГУ им. Ломоносова, занимается исследованиями в области мультипарадигменного программирования.
Скептики могут увидеть в этом подтверждение своей правоты и доказательство игрушечности таких DSL-ей.

E>Затем код с подобным лиспом попадает ко мне. Я не знаю Лиспа, но программу нужно сопровождать. Изучаю Лисп. Понимаю, что это не тот Лисп, который я изучил. Изучаю эту реализацию Лиспа в С++. Только после этого понимаю, что же здесь происходит. Затем надеюсь, что моих знаний в Лиспе и возможностей этой реализации Лиспа будет достаточно для внесения нужных модификаций. ПАВБЫВАВБЫ!
Да не попадает он к тебе . Если при наборе в вашу контору в списке требований к кандидатам нет пункта о знании Лиспа, если у вас есть code review и код сопровождают не только его авторы, т.е. у вас нормальная контора, выпускающая промышленные продукты промышленным способом, то Андрей Столяров или Кристофер Диггинс у вас не работают, и если кому из сотрудников вдруг придет в голову написать код на Лиспе, то этого никто не пропустит.
Вопрос Зверька звучал "может ли это быть как-то практически применено?". Ключевое слово — "практически", если оно означает "в промышленном коде", который буду сопровождать поколения — то ответ нет. Если "практически" означает "с пользой", то да, причем необязательно в исследовательском проекте, это может быть вполне рабочее решение, но штучное, разработанное и сопровождаемое маленькой сплоченной командой, решающей очень специфические задачи (такие в наших университетах еще попадаются).
Насчет не того Лиспа в случае InteLib — неправда ваша (почти), с библиотекой идет даже транслятор с "нормального" Лиспа на С++-овый. Я подозреваю, что автор отлаживает лисповые вставки в интерпретаторе Лиспа, а потом транслирует в С++ и готово.

ЗХ>>>Вот вы не улыбайтесь тут, а лучше расскажите — может ли это быть как-то практически применено?
ЗХ>>>Или это так, приколы?
ГА>>Вопрос философский, если учесть, что для большинства все не-мэйнстримовые языки — "это так, приколы".
E>Воспрос интеграции языков совсем не филосовский, а сугубо практический. Ниже правильно сказано, что некоторые задачи гораздо проще решить на каком-то языке, а не на C++. Вопрос только в том, как это решение связать с С++.
Конечно, вопрос интеграции языков — сугубо практический. Вот только вопрос "полезна ли реализация подмножества языка X в виде плюсовой библиотеки" — вопрос философский, т.к. индустрия ставит под сомнение полезность самого языка X. Смотря для кого. Понятно, что как ни крути, С++-ные ДСЛи невозможно отлаживать, их синтаксис и семантика уступают оригиналу, и их типичный use-case — нечто миниатюрное, когда привлечение специализированных инструментов затруднено или не окупается. И не зря А. Столяров выделил: InteLib будет вам полезна, если вы знаете Лисп. А много сейчас на рынке знатоков Лиспа и какой на них спрос?

Если бы в моей любимой Визуальной Студии вместо непонятно кому нужных VB.NET и J# был какой-нибудь Lisp.NET, Haskell.NET, Lex.NET, Yacc.NET (спокойно, я знаю о существовании http://research.microsoft.com и http://www.dotnetpowered.com/languages.aspx, я только говорю о соответствующем уровне поддержки), то любителей издеваться над С++ еще поубавилось бы, ИМХО.

E>Мне больше нравятся два альтернативных сценария:
E>- переписать подобное издевательство на чистом C++;
Хотелось бы увидеть символьное дифференцирование на чистом С++.
E>- послать все подальше, отказаться от этого проекта и вообще уйти в более вменяемую контору.
С этим никаких проблем нет, вот найти невменяемую контору, которая применяет OCaml, например, значительно труднее. Эх, а жаль.

E>Имхо, чем делать на C++ какой-то DSL, лучше воспользоваться языками, более для этого приспособленными. Например, вставлять в специальных комментариях код на каком-то скриптовом языке, затем проводить кодогенерацию и получать чистый C++ (см., например, Re: DSL внутрях C++.

Автор: eao197
Дата: 16.09.05

). Тогда тому, кто не знает DSL придется выучить только скриптовый язык, но не придется изучать, как этот скриптовый язык был выражен с помощью C++ конструкций.
Скорее всего, так оно и есть (за некоторыми исключениями вроде Спирита, который живет и процветает, и никому его внутреннее устройство не мешает).

Здравствуйте, Глеб Алексеев, Вы писали:

ГА>Андрей Викт.(орович?) Столяров (автор InteLib) — сотрудник кафедры вычислительной математики и кибернетики МГУ им. Ломоносова,

А что, ВМиК уже до кафедры сократили? За что это их так?

Здравствуйте, rus blood, Вы писали:

RB>А что, ВМиК уже до кафедры сократили? За что это их так?
Это я так слово department перевел, сорри .

Здравствуйте, rus blood, Вы писали:

RB>А что, ВМиК уже до кафедры сократили? За что это их так?

Может за "ИзоБретательство" в виду отстуствия практичности ?

Здравствуйте, srggal, Вы писали:

S>Может за "ИзоБретательство" в виду отстуствия практичности ?
Когда за изобретательство в университетах начнут наказывать, это будет каюк.

Здравствуйте, Глеб Алексеев, Вы писали:

ГА>Сначала давайте поинтересуемся, кто авторы вышеназванных библиотек?

А зачем? От этого они сразу лучше станут? Увеличивается ли популярность и качество Оберон из-за того, что его автором является Вирт.
В общем, Сократ мне брат, но истина дороже

E>>Затем код с подобным лиспом попадает ко мне. Я не знаю Лиспа, но программу нужно сопровождать. Изучаю Лисп. Понимаю, что это не тот Лисп, который я изучил. Изучаю эту реализацию Лиспа в С++. Только после этого понимаю, что же здесь происходит. Затем надеюсь, что моих знаний в Лиспе и возможностей этой реализации Лиспа будет достаточно для внесения нужных модификаций. ПАВБЫВАВБЫ!
ГА>Да не попадает он к тебе . Если при наборе в вашу контору в списке требований к кандидатам нет пункта о знании Лиспа, если у вас есть code review и код сопровождают не только его авторы, т.е. у вас нормальная контора, выпускающая промышленные продукты промышленным способом, то Андрей Столяров или Кристофер Диггинс у вас не работают, и если кому из сотрудников вдруг придет в голову написать код на Лиспе, то этого никто не пропустит.

Промышленная контора, выпускающая промышленные продукты промышленным способом, выгнала бы такого велосипедиста, как я еще до окончания испытательного срока. Контора у нас, пока, небольшая, а проектов много. Часть из них явно безнадежные. Поэтому для их успешного выполнения мы и применяем всякие полезные штуки, вроде code review. И код у нас часто пишется одним, сопровождается другим, а переписыватеся третьим. Зато самостоятельность и изобретательность поощряется, а удачные велосипеды практически сразу идут в работу. Так что пока мы все еще иновационная компания. Поэтому меня и интересуют подобные фокусы с С++.

ГА>Насчет не того Лиспа в случае InteLib — неправда ваша (почти), с библиотекой идет даже транслятор с "нормального" Лиспа на С++-овый. Я подозреваю, что автор отлаживает лисповые вставки в интерпретаторе Лиспа, а потом транслирует в С++ и готово.

Вот это очень важное замечание. А то у меня уже был готов следующий вопрос -- как же этот код отлаживать. Но раз есть нормальный Лисп и кодогенератор с нормального Лиспа на C++, то почему бы не сделать вот так:

/*lisp*
    <нормальный код на Лиспе>
*/
/*lisp-generated:begin:md5:...*/
Def OutList = 
  (If, 
    (IsEmpty, _1), 
    nil, 
    (Proc, 
      (Out, (Head, _1)), 
      (Eval, self, (Tail, _1)),
    End)
  );

Def NthItem =
  (If,
    (Or,
      (EqZ, _1),
      (IsEmpty, _2)
    ),
    (Head, _2),
    (Eval, self, (Dec, _1), (Tail, _2))
  );
/*lisp-generated:end:md5:...*/

специальный препроцессор находит комментарий /*lisp*/, берет из него родной лисповый код, переводит в C++ и загоняет в исходник. Ведь, если в родном Лисповом коде обнаруживается ошибка, есть возможность зайти в emacs или какую-нибудь Лисповую среду и отладить его там. После чего препроцессор по исправленной версии сгенерит новый С++ код.

ГА>Столяров выделил: InteLib будет вам полезна, если вы знаете Лисп. А много сейчас на рынке знатоков Лиспа и какой на них спрос?

Вопрос не в этом. Вопрос в том, что если неправильно интегрировать Лисп в C++, то мало будет найти знатока Лиспа или самому Лисп выучить. Нужно будет еще приспособится к этому псевдо-Лиспу-псевдо-С++, а вот это уже куда геморройнее. Однако, если найти возможность встроить в C++ нормальный Лисп (какой-нибудь из распространненых диалектов), то для некоторых задач связка нормальный-Лисп+нормальный-С++ может действительно дать преимущества, даже при нехватке готовых Лисп-программистов.

E>>- переписать подобное издевательство на чистом C++;
ГА>Хотелось бы увидеть символьное дифференцирование на чистом С++.

Хотелось бы увидеть символьное дифференцирование на InteLib.

E>>- послать все подальше, отказаться от этого проекта и вообще уйти в более вменяемую контору.
ГА>С этим никаких проблем нет, вот найти невменяемую контору, которая применяет OCaml, например, значительно труднее. Эх, а жаль.

Вот в этих темах: Metaprogramming et al

Автор:
Дата: 09.07.05

, Lisp

Автор: fionbio
Дата: 12.07.05

затрагивались вопросы о том, как же включить тот же Лисп в реальную разработку. Рецепт прост -- берешь и доказываешь, что этот язык применять нужно. На конкретных практических примерах. Которые сначала делаешь сам, затем с примкнувшими к тебе единомышленниками. Сначала на каких-то мелких вспомогательных задачках. Потом все активнее и активнее. Пока этот язык не проникнет повсюду настолько, что от него уже нельзя будет избавиться. Если язык выбран правильно и применяется по назначению, то он свое достойное место займет. А если у тебя единомышленников так и не появится, то может выбор чего-то был не правильный? Либо конторы (если тебе хочется изобретательством заниматься), либо языка (может твои коллеги таки объективнее к этому языку относятся).

E>>Имхо, чем делать на C++ какой-то DSL, лучше воспользоваться языками, более для этого приспособленными. Например, вставлять в специальных комментариях код на каком-то скриптовом языке, затем проводить кодогенерацию и получать чистый C++ (см., например, Re: DSL внутрях C++.

Автор: eao197
Дата: 16.09.05

). Тогда тому, кто не знает DSL придется выучить только скриптовый язык, но не придется изучать, как этот скриптовый язык был выражен с помощью C++ конструкций.
ГА>Скорее всего, так оно и есть (за некоторыми исключениями вроде Спирита, который живет и процветает, и никому его внутреннее устройство не мешает).

Ну уж не знаю. На счет спирита флеймить не буду. Просто если потребуется парсингом чего-нибудь занятся, то я лучше возму bison или coco/r, или altlr, или даже Elkhound.

---

PS. Прошу прощения за философский уклон. Просто меня уже давно не интересуют вопрос "Как что-то сделать?". Уж как нибудь да работающее решение я сделаю. Сейчас меня больше интересует вопрос "Зачем это делать?". Поскольку, если достойного ответа на него не находится, то и вопрос "Как..." отпадает сам собой. Так вот необходимость Лиспа в C++-ном синтаксисе я пока не понял.

Здравствуйте, eao197, Вы писали:


E>PS. Прошу прощения за философский уклон. Просто меня уже давно не интересуют вопрос "Как что-то сделать?". Уж как нибудь да работающее решение я сделаю. Сейчас меня больше интересует вопрос "Зачем это делать?". Поскольку, если достойного ответа на него не находится, то и вопрос "Как..." отпадает сам собой. Так вот необходимость Лиспа в C++-ном синтаксисе я пока не понял.

Вот и я поставил тот же вопрос, замечу Только ты, кажется, подошел к нему со стороны "доказать, что этого делать не надо".
Все что ты говоришь — тяжело поддерживать и т.п. — это очевидно.
То, что проще использовать полноценный "внешний" DSL — мы уже обсудили (еще когда я предлагал "SQL на C++").
В рамках этого топика мне просто хотелось увидеть, в каких задачах решение на Лиспе будет настолько естественнее решения на С++, что оправдает издержки.

Здравствуйте, Зверёк Харьковский, Вы писали:

E>>Так вот необходимость Лиспа в C++-ном синтаксисе я пока не понял.

ЗХ>Вот и я поставил тот же вопрос, замечу Только ты, кажется, подошел к нему со стороны "доказать, что этого делать не надо".

Ага, именно так.

ЗХ>В рамках этого топика мне просто хотелось увидеть, в каких задачах решение на Лиспе будет настолько естественнее решения на С++, что оправдает издержки.

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

Факты, как говорится, упрямая вещь, но и мы, следователи, тоже не лыком шиты!

eao197 wrote:
>
> Затем код с подобным лиспом попадает ко мне. Я не знаю Лиспа, но
> программу нужно сопровождать. Изучаю Лисп. Понимаю, что это не тот Лисп,
> который я изучил. Изучаю эту реализацию Лиспа в С++. Только после этого
> понимаю, что же здесь происходит. Затем надеюсь, что моих знаний в Лиспе
> и возможностей этой реализации Лиспа будет достаточно для внесения
> нужных модификаций. *ПАВБЫВАВБЫ!*

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

В общем, однозначно хорошего ответа на этот вопрос не существует.

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