Снова о Nemerle или профанация не пройдет :) - Философия программирования

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

E>В C++ для подобных экспериментов изобрели Boost. В .NET-е, похоже, Nemerle с макросами.

E>Впечатление почему-то от исходников того и другого одинаковое

Шаблоны С++, а стло бытьи Буст по этому поводу нервно курит в сторонке.

Если сможешь с помощью С++-шаблонов сгенерировать код конструктора и эксесор-методы для полей, то я сниму перед тобой шляпу.

Что до внешенго вида, то мы просто наткнулись на проблему которую хорошо было бы решить. А код подобного макроса мог бы выглядеь так:

def propInfos = Impl.GetMemberDefs(body);
def ctx = ImplicitCTX();
def builder = ctx.Env.Define(<[ decl: public class $(className.ToString() : usesite) { } ]>);

MacroLib.DefineCtor(builder, propInfos);
MacroLib.DefineProps(builder, propInfos);

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

Как ты понимашь, функции GetMemberDefs, DefineCtor и DefineProps можно написать один раз универсально и использовать потом где нужно (в том числе и в макросах типа Accessor и Record).

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

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

Это просто мега-фича. Она способна сделать язык офигительно выразительным.

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

ЗЫ

Эх. Как бы заставить обратить внимание МС на этот проект?! Ведь сейчас проекту нехватает гарммотного коммерческого подхода. Сейчас нужно было бы произвести ревизию фич, заморозить проект и довести, что назвается, его до релиза! Ведь щастье так близко, но все может погубить отсуствие коммерческой жилки у проекта.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Форум публичный, никто никого силой читать его не заставляет. И принимать на веру или во внимание чьи-то слова так же. Поэтому ты можешь игнорировать мои сообщения так же спокойно, как я некоторые твои.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Влад, у тебя есть, что сказать или как обычно?

Как обычно. Сказать есть что, но тебе это не нравится.
Могу перефразировать свои слова.

Приведенный "вариант" кода искажает смысл примера и стало быть является банальным банальным подлогом.

ANS>Или может ты таким хитрым способом хочеш сказать, что тоже думаеш, что сопоставлением с образцом в Nemerle нужно сравнивать именно с if/switch в C#?

Я хочу сказать, что человек продемонстрировал мощь паттерн-матчинга.

Что до сравнение с if/switch, то могу высказаться.

match заменяет и if, и switch и даже операторы вроде && и ||. Доказательством служит то, что в Нэмерел операторы if реализован на базе match, а switch вообще отсуствует, так как проигрывает match-у в выразительности.

Но это сказать это, все равно что ничего не сказать.
match — это в разы большее мошьная конструкция.
Конечно, все что можно сделать с помощь match можно сэмулировать сочетанием груды if-ов cо switch-ами, плюс прийдется пользоваться хэш-таблицами и писать кучу кода.

Но основная проблема заключается в том, что при этой эмуляции сильно страдает выразительность.
Собственно именно это и пытался продемонстрировать Vermicious Knid в обсуждаемом сообщении.

Не приймите, это за наезд или оскорбление, но вам похоже нужно просто по серьезнее изучить match и его возможности. Тогда вам будет очевидно, что match — это намного более универсальная и выразительная вещь чем switch. Ну, а if является более врыазительным в некоторых случаях, но не обеспечивает всего функционала. Куча же if-фов является явно менее выразительной.

VD>> и делашь далеко идущие выводы.

ANS>Вывод был только один — сравнение не корректно, соответсвенно выводов из него делать нельзя. Вот такой я вывел "далекоидущий" вывод.

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

ANS>Если ты так пишеш на C# то мне жаль г-на Хелсберга.

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Но все равно код уж сильно на Perl-овку смахивает. Это и не нравится.

Попробуй написать то же самое на Перли и тогда сравним.

К тому же код банально не здорово написан. В нем не произведена декомпозиция. Но на любом языке можно свалить все в кучу и получить птичий язык. Это не проблема зяыка.

E>C++ шаблоны для меня так же не являются верхом изящества. Поэтому от трехэтажных шаблонов в C++ меня начинает отворачивать уже даже по эстетическим соображениям.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Я придерживаюсь мнения, что результаты генерации вообще в VCS попадать не должны. Там должны быть только исходники, из которых производится генерация. Например, для yacc-а под контроль версий нужно укладывать .y-файлы, но вот полученные из них .c-файлы помещать под контроль версий смысла нет.

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

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

Если же есть генерируемые исходники, то можно просто поправить их.

Работая над R#-ом я пару раз наталкивался на такую проблему. Это очень неприятно, скажу я вам.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

WP> Во время компиляции? За что так?

За медленность и сложность. Метапрограммирование над метапрограммированием — это то что может сорват самую зоровую крышу.

WP> Да и не интерпретация это в большинстве современных Лиспов, а компиляция всё равно. Нет там вообще интерпретаторов.

Хм. Динамически компилировать генерируемый код только для того, чтобы один раз его выполнить? А будет ли это быстрее интерпретации?

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

WP> Это не всегда нужно.

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

WP>Например, параметром макры таки может быть строка (допустим, регулярное выражение). А разворачивается макра в код распознавателя для этого регвыра.

Может. Но тоже желательно проверить, что это строка или выражение которое может быть во время компиляции приведено к строке.

WP> Когда это нужно — есть тот же самый Хиндли-Милнер, который работает и для Лиспа. Есть несколько реализаций, да и своя пишется на коленке за пол часа.

Ну, вот мы и пришли тому с чего начли. Nemerle — это как раз тот самый один из клонов Лиспа с подержкой вывода типов а-ля Хиндли-Милнер, наличием синтаксиса (похожего на смесь C# и ML) и основанном на мошьном рантайме предоставляющем отличную среду выполнению и огромную тучу библиотек.

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

WP> Возможно всё. Из Лиспа сделать Nemerle тривиально. Из Nemerle сделать Лисп тривиально.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

WP> Если не в AST программировать, то многоуровневые макры становятся кошмаром.

Казалось бы. Но Окамл и Нэмелр вроде как отлично опровергли это утрверждение. Решением оказалось тривиально и от того гениально.

Просто нужно ввести средство преобразующее куски кода в АСТ и обратно. Квази-цитирование из Схемы оказалось ключем к решению проблемы.

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

WP> Затем что язык, где прикручено много всякого разного — нишевой, узкоспециализированный язык.

Хм? Что нишевого в Нэмерле?

WP> А метаязык, к которому можно приделать всё, из которого можно сделать любой другой язык — это универсальный язык.

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

Если уж я прекрасно решаю 90% задач на C# в котором метапрограммирования нет (точнее доступно только по средствам рантайм-кодогенерации или создания отдельных кодогенераторов), то в Нэмерле я вообще проблем знать не буду. На крайняк в нем есть возможность получить доступ к токенам и сделать все что хочешь. Но надеюсь прибегать к такому низкому уровню, кстати, в общем-то к Лисп-уровную, я лично очень не хочу. Мне банально жалго свое время.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

WP> Что же тут непонятного? Это — макры. Строго. И на ваши разницы тут наплевать конкретно.

Плюсй. Только что с вопросами тогда лезть?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>>при выборе платформы для реального большого проекта популярность имеет довольно большое значение. а серый обыватель или не серый и его слой общества никакого значения не имеет.

WP> Имеет. Дворник лихо пользуется метлой, но для большого проекта разработки межконтинентальной баллистической ракеты надо набрать много разных крутых специалистов, а не сто тысяч дворников с популярной и такой простой и интуитивно понятной метлой.
WP> А то, что дворника найти проще и что он дешевле — так это в вас, батенька, жадность играет. Ищете не там, где потеряли, а там, где светлее. Что никак нельзя назвать разумным поведением.
При чем тут дворник?
аналогия неверная. мы про инструмент говорим.
аналогия должна быть примерно такая: если мне нужно убирать мусор, то что надо выбрать — метлу, которая производится легко и дешева в освоении и производстве или супер-пупер пылесос сложный в освоении, дорогой, и с неизвестно какой надежностью?

WP> Как, продолжим аналогии, или попробуем совместно рассчитать расходы и риски на примере какого либо типичного индустриального софтового проекта?
вот это уже интереснее. давайте попробуем.
возьмем типичный индустриальный софтовый проект.
состоящий из трех частей — база данных, сложный гуи, обработка большого количества данных (то есть с какими-то требованиями по производительности)
подойдет такой?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

WP>> Как, продолжим аналогии, или попробуем совместно рассчитать расходы и риски на примере какого либо типичного индустриального софтового проекта?
G>вот это уже интереснее. давайте попробуем.
G>возьмем типичный индустриальный софтовый проект.
G>состоящий из трех частей — база данных, сложный гуи, обработка большого количества данных (то есть с какими-то требованиями по производительности)
G>подойдет такой?
О! может для примера RSDN@Home взять? благо про его разработку известно довольно много.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

VD>[Record] съедается компилятором, но вот конструктора у класса не создается (смотрел Рефлектором).

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

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

WP>> Вы меня пугаете. Какое такое всё? Это за пару семестров вдалбливается тривиально. А если человек уже отучился, мозги натренировал, то за пару месяцев.
S>Парадигму на пустом месте не впихнешь. Человек — не машина, ему надо за что-то зацепиться. Заучить конспекты лекций за два семестра — можно.

Зачем заучить? Учить там вообще всего ничего. Понимать надо больше, чем учить.

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

Понять — не проблема на самом деле. Достаточно небольшого математического фундамента. Чуть-чуть дискретной математики. Теория множеств, мат. логика, теория графов. Вот и всё! Остальное — приложится. И я уже говорил — людям без минимальнй математической базы делать в программировании нечего, так что тех, кто этой базы не имеет (и получить её не желает) — просто сразу отметаем.

S>Понять программирование можно исключительно при помощи практики. Иначе мы получим бодхисатву, "которому не надо программировать для воплощения своих идей".

Вот на практику эти два семестра либо два месяца и нужны. На теорию хватит двух дней.

WP>> Время надо было раньше тратить. Когда оно было.
S>А когда оно было? Нет, теперь мне конечно кажется, что во время учебы я неприлично много отдыхал... Тем не менее, вряд ли можно было существенно увеличить эффективность проведения того времени без значительных потерь для других аспектов моей личности. К примеру, теперь я читаю около десятка художественных книг в год. В студенчестве — около 100.

Ну так что ж вы в программисты пошли, если ваша личность не вмещала в себя науку программирования даже во время обучения? Кстати, я когда учился, всё свободное время бухал и читал художественную литературу, по томику за день. Всю классику сожрал и даже современной пиф-паф-фантастикой не подавился. А computer science выучил уже потом, в процессе работы. В сумме как раз пара месяцев и накопилась. В ВУЗе я и слов то таких не слышал, как "ита-редукция" или "LALR(1)-грамматика"...

WP>> Как уже тут обсуждалось, работающий студент — пропавший для общества студент. Отработанный материал. Социальный труп...
S>Ну, студенту рано или поздно все-таки придется начать работать. Ибо иначе мы опять получаем много-много эффективно усвоенных знаний на входе и полный нуль на выходе.

Только когда работа — часть учебного процесса. Как в системе Физтеха, например.

WP>> Перевернут. Всё это вместе убьёт индусов. Кодирование станет настолько простым и автоматизируемым делом, что недоучки из программирования вылетят, улицы подметать пойдут или бигмаками торговать. И это будет радость великая!
S>Забавно. Я лично в это не верю, т.к. исторический опыт показывает обратный эффект.

Да нет, история показывает орды вышвырнутых на улицу ненужных леммингов. Как например эти толпы веб-кодеров, оставшиеся не при делах после дотком-бума. Will code HTML for food, и всё такое.

S> Упрощение программирования впустит на этот рынок тех, кто до сих пор не может освоить даже настройку радиоприемника.

Зачем? Нет программирования ради программирования. Времена Синклера и Атари прошли. Есть программирование конкретных приложений. Которые формулируются заказчиком. Вот заказчиком они и реализуются сразу же, без посредников в виде орд безграмотных индусов. И останется узкая каста настоящих программистов — тех, кто решает нетривиальные задачи, такие, которые не по силам индусу независимо от простоты и удобства средств разработки — просто в силу высокой сложности и наукоёмкости самой предметной области.

S> Тот миллион индусов, которые сейчас пишут код для нашего с вами развлечения, станут мега-архитекторами в командах их умственно отсталых, и будут по вечерам рассказывать страшные истории, как в 2005 они писали исходные тексты на неподъемно страшно сложном VB.NET!
S>Если народ уже теперь жалуется на то, что дотнет, дельфи и ВБ недостаточно сложны для отсечения недоумков, то что же начнется, когда программирование станет еще более простым и автоматизируемым делом?

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

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

S>>Если народ уже теперь жалуется на то, что дотнет, дельфи и ВБ недостаточно сложны для отсечения недоумков, то что же начнется, когда программирование станет еще более простым и автоматизируемым делом?

Д>Я бы сказал — более автоматизируемым, но и намного более сложным.

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

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

G>О! может для примера RSDN@Home взять? благо про его разработку известно довольно много.

И кроссплатформенную реализацию, чтобы все разговоры про RSDN@Home for Linux разом закрыть.

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

WP>> Во время компиляции? За что так?

VD>За медленность и сложность. Метапрограммирование над метапрограммированием — это то что может сорват самую зоровую крышу.

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

WP>> Да и не интерпретация это в большинстве современных Лиспов, а компиляция всё равно. Нет там вообще интерпретаторов.

VD>Хм. Динамически компилировать генерируемый код только для того, чтобы один раз его выполнить? А будет ли это быстрее интерпретации?

Для выполнить один раз — вообще без разницы, если этот один раз выполняется во время компиляции. Ведь не плачет народ над тем, насколько тормозной и до памяти жадный интерпретатор языка темплейтов в компиляторах C++.

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

Я уже рассказывал, как этих проблем избежать. Независимо от языка — что в Лиспе, что в Template Haskell, что в Nemerle, что в даже Форте.

VD>Напомню, что такие мощьные возможности применяются для решения проблем основного языка. То есть их можно просто не решать.

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

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

Проблемы начинаются в тот момент, когда семантика DSL оказывается чрезмерно далёкой от семантики базового языка. Тогда хочется, чтобы базовый язык был более тупым и низкоуровневым (и соответственно более гибким).

Я, конечно же, для большинства задач тоже выберу Nemerle или скорее Template Haskell, но и для Common Lisp у меня примений очень немало.

От:	VladD2	www.nemerle.org
Дата:	22.02.06 14:47
Оценка:

От:	VladD2	www.nemerle.org
Дата:	22.02.06 14:47
Оценка:

От:	VladD2	www.nemerle.org
Дата:	22.02.06 14:47
Оценка:

От:	VladD2	www.nemerle.org
Дата:	22.02.06 14:47
Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	22.02.06 14:47
Оценка:

	От:	Vermicious Knid
	Дата:	22.02.06 15:00
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	22.02.06 15:05
Оценка: