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

ВВ>Я предложил внешний ДСЛ.

А делать его ты будешь топром и киянкой?

Пойми макры — это ведь просто технология. Их ведь и для внешних ДСЛ-ей можно приспособить. Вопрос только в том насколько технология позволяет упростить разработку ДСЛ-я и его интеграцию с компилятором и IDE. Так вот то что называется в немерле макрами позволяет очень существнно упростить эту задачу. Причем это далеко не предел. Можно упростить ее еще больше. А вот в ДСЛТулз почти ничего нет для этого. Это почти сто-процентный закат солнца вручну.

ВВ>Макросы позволяют сделать внутренний ДСЛ.

И внешний тоже. Мы тут недавно приколькный такой ДСЛ-чик написали — C#.
Сделано все на макросах.

ВВ>А кардинальной разницы нет, да.

С чем? Я же говорю. Разница в простоте реализации. Миллионы долларов против тысяч. Это ли не выгода?

ВВ>ASPX вот — тоже такой внешний ДСЛ.

Ага. МС вот делает движок рендеренга новый к нему. Делает уже более года. Тоже на макрах делается где-то за месяц одним человеком. И это не преувеличение или понты.

ВВ> Просто очень убогий. И вместо парсера там регексы. Почему — я не знаю.

В последнем видимо это не так. Но ответ очень простой. У них просто нет подходящих стредств. А у нас есть.

ВВ> Но мне слабо верится в то, что он убогий, потому что в C# нет макросов, и у МС не хватило денег и времени на разработку чего-то более вменяемого.

Но это так. Через десят лет после выпуска убогой версии выкупают и менее убогую.

ВВ> Скорее были приоритеты другие на момент его создания + совместимость с ASP Classic.

А чем тут совместимость то мешает?

Пойми все очень просто. МС даже в своих компиляторах все вручуню да еще и на С++ фигачит. Цена такой разработки очень высока. А отдавать на разные АСП (денег на прямую не приносящих) жаба душит. По сему прогресс у них такой медленный. И это при их то ресурсах. А были бы они как мы — без копейки в кармане, то вообще ничего бы не сделали.

ВВ>Интереснее тут другое. Я в общем не очень понимаю, почему на вопрос "а насколько этим удобно пользоваться?" я получаю ответ "но зато это написано на макросах".

Ты извини, но тему не ты создал. И вопрос в ней был другой. А ты просто его подменить другим пытаешься. Ответ на твой вопрос очевиден. Даже созданный самыми экстенсивными и не эффективными методами продукт может удовлетворять потребителя. MS или IBM так и поступают. Но вот даже при их ресурсах МС пока что не продемонстрировал действительно удобного решения для разработки веб-сайтов. А энтузиасты-рубисты продемонстрировали. Вот и на немерле продемонстрировали недавно. Разве это не наталкивает на мысли?

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

G>Хороший язык, на котором никто не пишет и не хочет писать — плохой язык. Наоборот кстати тоже.

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

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

Получается какой-то порочный круг.

Что до сравнения PHP с F#... Если тебе оно не нравится, то можешь сравнить F# с C# или с VB. Они то из одной экосистемы. Но на их фоне F# не видно даже в микроскоп.

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

Z>Если никто — то конечно да. А плохой у немерле не язык, а PR, стабильность и доки.

Про стабильность я бы не согласился.

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

FR>Я согласен с тем что F# и OCaml уже достаточно далеко разошлись, но совместимость при этом осталась, например далеко нетривиальная библиотека http://www.coherentpdf.com/ocaml-libraries.html компилируется и OCaml и F#.

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

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

G>>То есть макры — не тул для программистов, а тул для разработчиков компилятора.
S>Фактически — да. У меня по-прежнему нет личного опыта, но всё выглядит именно так.

А кстати, что так? Может пришла пора попробовать? Или боишься подсесть на эту "траву"?

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

Кэр>>Любую фичу можно использовать как во благо, так и во вред. Мне вот такое свободное изменение синтаксиса дает такую картину перекрестного опыления различными библиотеками результирующего кода, что жить не хочется.
S>Ну, это старый аргумент. Я наблюдаю этот спор тут чуть ли не со времён R#. Ответы на него мне тоже известны.
S>Как оно окажется на практике — пока что непонятно. Пока что мы имеем не очень много макросных библиотек для немерле, так что трудно сказать, насколько твой страх оправдан.

Тем кто использовал макры на практике (не баловался, я делал что-то полезное) — понятно. Я не сказал бы, что все уж так прекрасно, но проблем с конфликтами нет. Есть проблемы с тем, что иногда хочется, чтобы один макрос обрабатывал результаты работы другого, но по причине их не синхронизированности этого достичь не удается. Пример этого я видел только один раз. Это конечно недоработка макрос-системы, но опять же это не системная проблема, как тут пытаются это интерпретировать, а проблема реализации. В двушке, я думаю, мы и ее устраним.

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

DG>вопрос еще более старый (ему лет 50) — спор идет со времен lisp, макро-ассемблера и т.д.

У макро-ассемблера нет ничего общего, кроме названия, с макросами лиспа.

DG>и видно, что в mainstream-е выбор всегда делался в пользу "жестких" инструментов.
DG>на текущий момент, не видно почему этот выбор должен измениться.

Мэйнстрим тупо не осилил Лисп. А некоторые вообще хавают только то что дают ему корпорации. Они вообще не будут даже смотреть на что-то где нет клейма "Мэйд бай Майкрософт".

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

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

Вот это вряд ли. Тут логика обратная.

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

DG>но в том же .net-е (c#) — это является не просто соглашением "давайте писать хороший код", но и предоставляются способы по защите от плохого кода.
DG>есть namespace, есть алиасы и т.д. — которые позволяют при необходимости один плохой код скрестить с другим плохим кодом, и все это использовать из хорошего кода.

Дык они и тут работают. Любой макрос можно вызвать в виде фунции (без использования синтаксиса). А синтаксис импортируется using-ами.

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

Z>В чем суть примера?

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

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

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

VD>Самое забавное, что те кто язык освоили они или его используют, или хотя бы уже не говорят, что он плохой.
Самое забавно что я уже освоил nemerle на уровне написания кода, но:
1)По сравнению с C# не хватает тулинга
2)По сравнению с F# не слишком лаконичный, и сильно не хватает карринга
Поэтому не могу в моей работе найти места nemerle. Может для задач, которые потребуют DSL и прочего разберусь с макросами, но пока это довольно сложно ибо недокументировано, и не хватает для обучения материалов.

VD>Получается какой-то порочный круг.
Именно порочный круг, чтобы выйти из него — надо заниматься популяризацией, на приемр того же липперта, сайма, SPJ, мейера и других деятелей.
Заметь — они все довольно частые гости на различных конференциях, пишут в блогах, снимают видео итп. Такой hype даже в отсутствии нормальных доков сможет привлечь волну ковырятелей исходников, которые сами со всем разберутся.

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

DG>я использую МП, активно использую.

Покажите код!

DG>настолько активно — что у меня есть две больших работающие системы построенные с помощью того или иного применения МП.

Вертишься в своей песочницы и на основании этого делаешь далеко идущие выводы о других подходах.

DG>есть множество иследовательских проектов по МП — по тому или иному его аспекту применения и работы.

Опять же, код в студи, тогда и обсудим.

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

Ну, вот тебе опыт работы минимум трех десятков человек над одним проектом — компилятором немерла. Как видишь, проект жив и развивается.

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

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

Готов принять участие в этом смелом научном эксперементе и оказать посильную помощь.

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

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

Особенно понравилось вот это:


DG>не передергивай. я утверждаю лишь, что бесконтрольное применение МП — лажает...
DG>...само по себе МП — конечно благо и необходимая в хозяйстве вещь...
DG>...но это понятное контролируемое применение МП, которое не вызывает таких побочных эффектов — как те же макросы.

Простой логический рад. МП — благо, лажает бесконтрольное МП, макросы это контролируемое применение МП. Выводы: Макросы не лажают — Макросы это благо.

Что и требовалось доказать!

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

S>В общем случае я не вижу способа сделать компиляцию Nemerle-кода в JS. По крайней мере, в эффективный JS.

Это еще почему? Даже для ОКамла и F# подобное сделали. Чем немерл то хуже?

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

ВВ>>Тут, мне кажется, другая проблема — как транслировать код, активно использующий FCL? По-моему, вообще никак. Получается, что придется вводить очень жесткие ограничение на дотнетовское АПИ, которое разрешено в таких транслируемых в джаваскрипт функциях. А это уже не очень круто.
S>Я об этом и говорю — вопрос в окружении. На сервере ты взял, к примеру, прицепился к CryptoAPI, и побежал. Или там на диск сбегал. Вокруг тебя — ось.
S>На клиенте вокруг тебя — DOM и CSS.

Это-то как раз не проблема. ur/web, на который Вульфхаунд тут уже раз надцать приводил ссылку, как раз производит такое прозрачное транслирование себя в ДжаваСкрипт по принципу — если метод должен выполняться на сервере (ему нужны ресурсы на сервере), то он останется серверным, если нет — то будет транслирован в ДжаваСкрипт.

S>С точки зрения системы типов, никакого преимущества у статики тут нет — всё равно всё, с чем работаешь, это хеш таблицы. Как будет выглядеть код на C#, манипулирующий DOM-ом?

C# не знаю. Я предпочел бы функциональный язык, пусть даже и динамически типизированный. И с ДОМ-ом тоже надо как-то в другом стиле работать — например, формировать его через литералы. А так, да, если взять C# as is, то смысла вообще мало очень.

S>Поэтому, на мой взгляд, польза сводится к трансляции изолированных функций типа IsValidEma
ВВ>>И самое забавное, что как раз одна из основных проблема джаваскрипта, которую в идеальном мире хотелось бы решить — это бедность доступных на нем библиотек.
S>Возможно. Лично я в джаваскрипте не особо силён. Мне казалось, что основная проблема там — отсутствие автокомплита и интеллисенса.

Для начала должно быть то, что можно было бы автокомплитить и интеллисенсить

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

FR>Тут http://ocsigen.org/ вроде это все уже сделано http://ocsigen.org/docu/1.3.0/XHTML.M.html, но я слишком далек от веба
FR>чтобы оценить насколько хорошо. DSL'ы у них по моему весьма неплохие.

Ага. У ребят есть чему поучиться.

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

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

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

Естественно, подразумевается, что автокомплит будет работать не всегда, лишь для ряда случаев. Я думаю, что этим "рядом случаев" может покрываться изрядная часть кода. Там будет автокомплит, интеллисенс и проч. Часть кода покрываться не будет. Компилировать, кстати, тоже можно по такой же модели — смогли вывести типы хорошо, не смогли — тоже ладно.

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

S> Мне казалось, что основная проблема там — отсутствие автокомплита и интеллисенса.

Кое какой интеллисенс там был еще лет 10 назад.

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

ВВ>>Нет, не бред. Я просто понимаю, что типы будут выводиться не всегда и интеллисенс не будет работать в ряде случаев.
VD>А кому нужен то потухающий, то погасающий интеллисенс?

Не вижу тут проблемы
В Шарпе переключаешься на динамики — интеллисенса нет, никто ж не умер. Здесь так же.

Опять же — потухать он будет не полностью. Т.е. к примеру, мы можем вывести что foo — это функция типа a->b->c, но что такое эти a, b, c — не можем. Все равно это уже какая-то информация, которую можно использовать при автокомплите, давать ворнинг, если ты пытаешься делать с foo то, что нельзя делать с функциями и пр.

ВВ>>Но большинство сценариев он будет покрывать. В С# 4 вон тоже можно написать код, для которого интеллисенс "официально" не работает.
VD>А может пойти дальше и сделать как в Boo? Ну, чтобы динамика была только там где компилятор не в силах типы вычислить.

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

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

G>Самое забавно что я уже освоил nemerle на уровне написания кода, но:

Ой не зарекайся. Я и через 3 года активного программирования открывал для себя много нового.

G>1)По сравнению с C# не хватает тулинга

Туллинг — это круто! А по русски?

G>2)По сравнению с F# не слишком лаконичный, и сильно не хватает карринга

В иднет-режиме 1 в 1. Так что разница только в скобках.

А вот если еще макросы использовать...

G>Поэтому не могу в моей работе найти места nemerle. Может для задач, которые потребуют DSL и прочего разберусь с макросами, но пока это довольно сложно ибо недокументировано, и не хватает для обучения материалов.

Ну, все новое по началу сложно. Я тоже не сразу все освоил.

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

VD>>Получается какой-то порочный круг.
G>Именно порочный круг, чтобы выйти из него — надо заниматься популяризацией,

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

G>на приемр того же липперта, сайма, SPJ, мейера и других деятелей.

Мы ведь не можем привлечь к популяризации ПиАр-машину МС? У перечисленных лиц есть свои игрушки. Липерт по уши в компиляторе шарп. Дон Сайм в своем компиляторе. Меер в хаскеле. А как было бы здорово прокатить ДонБокса (который не мало хорошего о макрах лиспа говаривал) по миру с рассказом о крутости микросистемы. Забить пол МСДН-а примерами и статьями? Вот только это нереальные мечты.

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

G>Заметь — они все довольно частые гости на различных конференциях, пишут в блогах, снимают видео итп. Такой hype даже в отсутствии нормальных доков сможет привлечь волну ковырятелей исходников, которые сами со всем разберутся.

Да, 2 лимона баксов дать на пиар и разработку было бы проще и дешевле .