Re[7]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.08 01:44
Оценка: 21 (3) +1
Здравствуйте, alvas, Вы писали:

A>1. Нужен road map. Если он есть — можно ссылку?


Можно даже без ссылок, а прямо inline-ом.
Роад-мап очень простой. В ближайшее время будет выпущена версия 1.0. Произойдет это после того как я доведу работы по поддержке LINQ до финала и после того как мы вычистим основные ошибки в компиляторе и интеграции.
Я надеюсь, что эта работа будет завершена в Январе. В крайнем случае в первой половине 2009-года.
Новых фич при этом добавляться не будут. Только если библиотеки разработанные сторонними авторами. Так возможно мы увидим библиотеку поддержки XML а-ля LINQ to XML и (опять же возможно) реализацию макры аналогичной фиче dynamic из C# 4.0.

A>2. Команде Nemerle придется ВСЕГДА гнаться за Майкрософт. Огонь и движение

A>

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


A>Пример — необходимость реализации поддержки Linq в Nemerle.

A>На очереди dynamic, ...

Что-то в этом эссе есть. Но Джоиль человек не традиционной ориентации в прямо и переносном смысле этого слова.
Я не разделяю его вглядов. По крайней мере не все или не на 100%.

Так я считаю, что МС ведет этот огонь не со зла. Это проблемы большой организации и борьбы за лидерство в ней. Я тут скорее согласен с Роном Барком рассуждавшем о фатальном недостатке — его писали не они.

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

Посему считаю, что Linq должны поддерживать все уважающие себя гибридные языки реализующиеся на платформе дотнет (да и не только).
К тому же поддержка Линк не так сложна. Скорее сложно было довести систему разрешения перегрузок Немерле (действующую в очень жестких условиях отложенной типизации), чтобы быть совместимыми с библиотекой входящей в .NET Framework 3.5, нежели с самим Query Pattern. Само же преобразование кода в деревья выражений вообще было реализовано на базе макросов. Так что МС напряг не очень сильно своим Линком. Но он заставил довести систему разрешения перегрузки до очень высокого уровня.

A>Я так понял тут уж ничего не поделаешь.


Ну, почему же не поделаешь?
Вот погляди на ситуация которая складывается сегодня...
Все новые фичи C# 4.0 (до выхода которого еще 1.5 года) уже поддерживаются Nemerle. Разве что dynamic реализован не в полной мере и не через DLR, а через рефлексию. Но ведь, черт побери, реализован! И это было сделано 2 года назад! То есть мы опередили огромный Майкрософт ах на 4 года! Это ли не успех?
И так почти по всем новым фичам МС. Даже Линк — это проявление ФП которое было в Немрле с рождения.
Ко-/контр-вариантность интерфейсов и делегатов уже давно поддерживается в Немерле.
В общем, Немерле уже поддерживает все то что будет не только C# 4.0, но и в C# 5.0 (ведь компилятор изначально доступен как компонент, МП не просто реализовано, а реализовано как базовая фича языка).

Таким образом мы обогнали MS (который, на мой взгляд, движется в правильном направлении, но уж очень экстенсивными методами и с огромным количеством ошибок) на много лет. Эта фора которую нужно не прое... эээ... не утртить .
Все что нужно языку на сегодня — это отсутствие багов в языке и IDE.

Кроме того нужно:
1. Более качественное IDE. Желательно безупречная. Но это большая работа, особенно в условиях когда сама IDE основана на COM.
2. Вести работы над упрощением API компилятора используемого для целей мета-программирования.
3. Написать множество стандартных макросов которые можно будет использовать как строительные блоки.
4. Ускорить работу генерируемого им исполняемого кода. А это значит, что нам нужно научить его инлайнить хотя бы базовые ФП-функции вроде Map, Fold, Zip и Filter. А так же локальные функции и лямбды передаваемые в них. В идеале же нужно использовать технику супер-компиляции которая бы позволила максимально устранить, что называется, performance penalty от использования ФП.
5. Ускорить работу компилятора. Отчасти это сделает пункт 4, но кроме того компилятор нужно сделать многопточным. Чтобы он мог масштабироваться за счет увеличения процессоры ядер.
6. Возможно нужно снять ограничения на то где может применяться макрос и из каких лексем он может состоять. Тогда даже разбор самого описания макроса можно реализовать по средствам макроса, а ДСЛ-и можно будет объявлять на уровне типов.

Вот только все эти пункты мы будет реализовывать во второй версии языка и компилятора. Перед этим нам придется произвести основательный рефкторинг компилятора. Разбить его на модули абстрагируемые интерфейсами. Разложить все типы по отдельным файлам. Дать более внятные имена некоторым типам.

A>3. ECMA стандарт даст гарантию невозможности ламающих изменений языка в мажорных версиях. Даже у Майкрософт если

код считают устаревшим — помечают атрибутом [obsolete], но это ворнинги — код скомпилится без проблем. Обратная совместимость это наше все.

Гарантия отсуствия ломающих изменений, по крайней мере серьезных — это бутсртипинг компилятора, т.е. то что компилятор компилирует сам себя. Это приводит к эволюционному его развитию. Без ломающих изменений вряд ли получится улучшить язык. Но я уверен, что они не будут очень болезненными. Скажем переименование АПИ — это ломающее изменение. Но без него не обойтись. К тому же можно постараться сохранить и старые названия пометив их как obsolete.

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

A>4. Больше информировать комьюнити что происходит в Команде Nemerle.


Постараемся.

A>ЗЫ. Я так понял что не получилось у грандов выбить гранты — так разместите "Donate" на сайт и к вам потянутся люди.


Кто бы этим занялся. Просто невозможно сделать все сразу и в одиночку. Нас мало и приходится тратить время на основную задачу — доведение компилятора до ума. Финишь уже близко, но надо работать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 01:57
Оценка: 145 (6) +2
Здравствуйте, AndrewVK, Вы писали:

AVK>1) На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление.


Инженер, который не знает инструмента, с которым он работает, не может эффективно выполнять свои функции в принципе. С программистами, которые не хотят изучать новые технологии или даже противятся этому, рано или поздно начинаются проблемы из серии "тупой дизайн, кривой код". Причём чем выше статус такого человека в команде, тем разрушительнее последствия. Я не знаю как эти вещи связаны между собой, может это чистое совпадение, но в моей практике это совпадение сто процентное, что позволяет мне сделать вывод, что оно не случайно. Для меня это даже стало очень чётким индикатором, человек не интересуется, не может освоить новое — ничего хорошего от него не жди. Под таких людей нужно не подстраиваться, а пытаться их учить, а если не получается, то постараться от них избавится.

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


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

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

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

AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.


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

AVK>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.


Насколько мне известно, аббревиатура DSL в DSL Tools появилась по недоразумению. С DSL эти Tools имеет мало обощего.

AVK>3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.


Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.

AVK>4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.


Это опять лишь домыслы. Генерировать код на Немерле не сложнее, чем генерировать текст. Дело в том, что текст обычно генерируется последовательно, от начала до конца. Код в Немерле можно генерировать в произвольном порядке, что даёт определённую гибкость. А про правку сгенерированного кода и железной линейкой по пальцам тут уже сказали. И я с этим полностью согласен, т.к. встречался с таким баранизмом на практике.

AVK>5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.


Не знаю зачем ты добавил сюда этот пункт, но МП тут вообще ни при чём. Если у тебя задача не может использовать МП, или ООП, или ФП, то странно в этом обвинять МП, ООП, или ФП.

В общем, как-то всё не очень убедительно. Фактически я увидел две претенции:

1. Сложноть использования макросов.
2. Сложность написания макросов.

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

По второму пункту можно сказать, что да, написание макросов сложнее, чем, например, написание простого метода. Но ведь и эффект гораздо сильнее. Вообще написание библиотечного кода — это отдельный скил, который нужно тренировать. МП тоже скил, который тоже нужно тренировать. Во многом эти скилы пересекаются, так что не вижу в этом большой проблемы.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 02:03
Оценка: +1
AVK>Дисклеймер:

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

Круто, что foreach можно разъять на детали. Круто -- pattern matching. Круто полностью от начала до конца понимать, что такое монады (не гони пацан, это уже из "Что меня не устраивает в хаскелле").

Короче, вся эта крутизна пока не подтверждена убедительной success story. А без success story как ты промотивируешь команду сесть и вложить неделю времени в академические одиссеи?
Re[2]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 02:31
Оценка: +1
IT>В общем, сложность использования макросов надумана и не имеет ничего общего с реальной действительностью. Это не сложнее, чем использование метода из библиотеки общих компонент.

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

Например, многие мои знакомые англичане достаточно бегло говорят на английском языке и даже не спотыкаются на таких конструкциях как "will have been". Как ты думаешь, сложность использования времён в английском языке тоже надумана?


IT>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.


Понятное дело. Более того, если через полтора года что-то где в этом отлаженом механизме чем-то накроется -- нужно всего лишь найти того программиста, который это написал, кинуться ему в ноги, заплатить хороших денег -- и проблема решена. Куда проще чем попросить первого попавшегося и сунуть ему в зубы раздел MSDN по Custom Tools.



IT>можно сказать, что да, написание макросов сложнее, чем, например, написание простого метода. Но ведь и эффект гораздо сильнее. Вообще написание библиотечного кода — это отдельный скил, который нужно тренировать.


Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.

Знаешь, в одной конторе провели чемпионат по Солитёру и всех трёх финалистов назавтра выперли. Так вот Солитёр не единственный непроизводственный "скил".
Re[3]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 03:16
Оценка: +2
Здравствуйте, mihailik, Вы писали:

IT>>В общем, сложность использования макросов надумана и не имеет ничего общего с реальной действительностью. Это не сложнее, чем использование метода из библиотеки общих компонент.


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


M>Например, многие мои знакомые англичане достаточно бегло говорят на английском языке и даже не спотыкаются на таких конструкциях как "will have been". Как ты думаешь, сложность использования времён в английском языке тоже надумана?


К чему эта демагогия? Давай обойдёмся здесь без времён и англиских знакомых. Ты считаешь использование макросов сложным делом? Приведи пример, если сможешь, который демонстрирует эту сложность. Я со своей стороны попытаюсь приложить все усилия, чтобы понять в чём эта сложность состоит. АВК, кстати, привёл такой пример — yield return. Трудно видишь ли некоторым это понять. Согласен, трудно. А ленивость в Linq не трудно? Проблема ведь та же, но ни одного ключевого слова там нет. Одни сплошные функции. Так в конструкциях языка дело ли? Тоже самое и с макросами. Макросы — это форма, такая же как и классы, методы, языковые конструкции. Настоящая сложность не в них, а в концепциях, которые они реализуют. Если в твоих проектах используются библиотеки общих компонент, то сложность их использования и сложность использования макросов будет абсолютно одинаковой. Никакой разницы.

IT>>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.


M>Понятное дело. Более того, если через полтора года что-то где в этом отлаженом механизме чем-то накроется -- нужно всего лишь найти того программиста, который это написал, кинуться ему в ноги, заплатить хороших денег -- и проблема решена. Куда проще чем попросить первого попавшегося и сунуть ему в зубы раздел MSDN по Custom Tools.


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

IT>>можно сказать, что да, написание макросов сложнее, чем, например, написание простого метода. Но ведь и эффект гораздо сильнее. Вообще написание библиотечного кода — это отдельный скил, который нужно тренировать.


M>Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.


Директору может и всё равно, а начальнику IT департмента не всё равно. А если всё равно, то долго он начальником не будет.

M>Знаешь, в одной конторе провели чемпионат по Солитёру и всех трёх финалистов назавтра выперли. Так вот Солитёр не единственный непроизводственный "скил".


Что-то тебя сегодня на демагогию прорвало. Солитёры, чемпионаты Думаешь это делает твои умозаключения (кстати, какие?) более убедительными?
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 27.12.08 03:28
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


A>>1. Нужен road map. Если он есть — можно ссылку?


Большое спасибо Но я думаю что на Nemerle.org это бы прочитало значительно больше людей.

A>>2. Команде Nemerle придется ВСЕГДА гнаться за Майкрософт.


Я не считаю что это Майкрософт делает со зла. Но Nemerle Team все равно придется дублировать все фичи МС. Спасибо что убедил меня в том что это не большая проблема для Nemerle Team.

VD>Кроме того нужно:


Вот это все нужно в road map

A>>3. ECMA стандарт даст гарантию невозможности ламающих изменений языка в мажорных версиях. Даже у Майкрософт если

VD>код считают устаревшим — помечают атрибутом [obsolete], но это ворнинги — код скомпилится без проблем. Обратная совместимость это наше все.

VD>Без ломающих изменений вряд ли получится улучшить язык. Но я уверен, что они не будут очень болезненными. Скажем переименование АПИ — это ломающее изменение.


Представь момент когда Nemerle стал мейнстримом. И что тебе скажут менеджеры проектов, когда после закачки обновлений прогибается код, написанный до этого? И плюс еще на сайте висит гордая надпись. "Переходите на 2.0, потому что мы через месяц прекращаем поддержку 1.0?" В общем я ничего не имею против ломающих изменений в бета, CTP, RC. Но мажорные версии должны полностью поддерживать возможности минорных. Иначе просто никто не рискнет использовать Nemerle в промышленных проектах.

PS. АПИ — это API? Я правильно понял?
PPS. Писали мы как-то один проект на .Net 2.0 бета. Говорю товарищу — а не опасно? Он — зато будем впереди планеты всей. Пришло время релиза .Net 2.0. Качнули, поставили. Прога запустилась. Ура! А тут сразу как полетели эксепшины. И что делать будем? Перекомплили исходники. И все заработало.
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[8]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 27.12.08 03:42
Оценка:
Здравствуйте, VladD2, Вы писали:

Есть такой себе язык SCRIPT.NET. Он поддерживает Mutantic Objects. Что то типа анонимных типов. Такое нужно в хозяйстве?
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[9]: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 27.12.08 04:46
Оценка: +1 :)
Здравствуйте, AndrewVK, Вы писали:

Ясно, значит, какой реальный опыт. Но я отвлекся.
Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle". Выяснилось, что он не в состоянии вложить мозги в головы дураков и грамотно сделать проектирование вместо программиста. Действительно, фатальный недостаток системы МП
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 27.12.08 04:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Продемонстрируй, плиз, хотя бы один ДСЛ сужающий возможности исходного языка.


Например, возможность запретить использовать треды для низкоквалифицированных программистов. Или ограничение на unsafe-конструкции, как в C#. Или запрет обращаться к файловой системе и реестру напрямую в слое бизнес-логики. И т.д., и т.п.
Всё это имеет определенный смысл, хотя называть фатальным недостатком отсутствие такой возможности я бы не стал
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 05:00
Оценка: +2
Здравствуйте, Andrei F., Вы писали:

AF>Например, возможность запретить использовать треды для низкоквалифицированных программистов. Или ограничение на unsafe-конструкции, как в C#. Или запрет обращаться к файловой системе и реестру напрямую в слое бизнес-логики. И т.д., и т.п.


Это не DSL. Это больше смахивает на FxCop.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 27.12.08 05:06
Оценка:
Здравствуйте, IT, Вы писали:

IT>Это не DSL. Это больше смахивает на FxCop.


В рамках языка такая фича полезнее. Например, когда я работал на ABBYY, то познакомился с целым талмудом страниц на 100 — "как писать нельзя".
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 05:21
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

IT>>Это не DSL. Это больше смахивает на FxCop.


AF>В рамках языка такая фича полезнее. Например, когда я работал на ABBYY, то познакомился с целым талмудом страниц на 100 — "как писать нельзя".


Ну дык не проблема. Пиши макрос-атрибут уровня сборки и пусть он бегает по коду и анализирует чего-кому можно, а кому нельзя. Например, в компиляторе есть макрос, который запрещает объявлять неизменяемые поля типа Location.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Что меня не устраивает в МП в Nemerle
От: z00n  
Дата: 27.12.08 05:55
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


VD>> Например, если вам нужно что-то закладывать в стек перед обработкой, а потом — это что-то вынимать, то вам придется пользоваться жудко неудобной конструкцией try/finally и при этом еще еще и каждый раз явно описывать действия связанные с финализацией. Меж тем можно написать макрос который автоматом выполнет нужные действия. Тогда вместо награмождения кода можно будет написать push_with_auto_pop(mySteack, value) { ... }.


VE>Например в языках с развитой системой типов это делается обычной функцией. Зачем нужен макрос тут?

Так повелось со времен лиспа: UNWIND-PROTECT. Это один из способов избежать преждевременного вычисления аргументов. Другие способы: ленивый язык(a-la Haskell) или передача функций (thunks) как аргументов. Для последнего желательно иметь 'красивый' синтаксис лямбд, как в Smalltalk или Scala например.

// Scala: http://scala.sygneca.com/patterns/loan

def withResource[A](f : Resource => A) : A = {
    val r = getResource()  // Replace with the code to acquire the resource
    try {
        f(r)
    } finally {
        r.dispose()
    }
}

// clients code
withResource{ r =>
    // do stuff with r....
}
Re[10]: Что меня не устраивает в МП в Nemerle
От: FR  
Дата: 27.12.08 06:28
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

AF>Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle". Выяснилось, что он не в состоянии вложить мозги в головы дураков и грамотно сделать проектирование вместо программиста. Действительно, фатальный недостаток системы МП


Популярность Лиспа, Dylan'а и Форта показывают что недостаток может и не фатальный, но очень существенный.
Re[4]: Что меня не устраивает в МП в Nemerle
От: FR  
Дата: 27.12.08 06:40
Оценка:
Здравствуйте, z00n, Вы писали:

VE>>Например в языках с развитой системой типов это делается обычной функцией. Зачем нужен макрос тут?

Z>Так повелось со времен лиспа: UNWIND-PROTECT. Это один из способов избежать преждевременного вычисления аргументов. Другие способы: ленивый язык(a-la Haskell) или передача функций (thunks) как аргументов. Для последнего желательно иметь 'красивый' синтаксис лямбд, как в Smalltalk или Scala например.

Можно как в D http://www.digitalmars.com/d/2.0/lazy-evaluation.html обойтись только леневыми аргументами функций.
Re[2]: Что меня не устраивает в МП в Nemerle
От: hi_octane Беларусь  
Дата: 27.12.08 10:02
Оценка: 38 (1)
M>Проблема немерле в том, что изумительная красота макросов пока никак не конвертируется в деньги.

Каждый свою success story имхо сам должен делать. Неважно в целом по жизни или в применении каких-то фич каких-то языков в какой-то предметной области. У кого-то вон milliondollarhomepage выстрелил — и success story офигительная и бизнес модель явно проще чем самое короткое описание пути конвертации yield return в деньги

M>Короче, вся эта крутизна пока не подтверждена убедительной success story.


Я Nemerle success story
Автор: hi_octane
Дата: 14.02.08
почти год назад выкладывал, и даже на вопросы отвечал. Проект тот и сейчас развивается.

M>А без success story как ты промотивируешь команду сесть и вложить неделю времени в академические одиссеи?


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

Как переходила на Nemerle наша небольшая команда
Автор: hi_octane
Дата: 18.02.08
я тоже писал. Кстати, времени отведённого на обучение фактически не было. Люди просто сели и начали писать — медленно и с точки зрения нашего единственного на тот момент функциональщика — косяча и через одно место. Но у Nemerle есть одно охренительное преимущество — не знаешь как сделать красиво — делай как на C# А потом функциональщик делал ревью и обьяснял — что здесь через одно место и здесь, и т.п. Да какой-то протормоз на этом получился, но мы как те мышки, которые кололись и плакали, но знали что катус колется только пока иголки не сгрызёшь. Так и вышло — сейчас у всех кризис-кризис, а нас заказчик развитием этого проекта загрузил по-полной.
nemerle опыт применения success story
Re[4]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 10:03
Оценка: -1
IT> Трудно видишь ли некоторым это понять. Согласен, трудно.

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


IT> А ленивость в Linq не трудно? Проблема ведь та же, но ни одного ключевого слова там нет. Одни сплошные функции. Так в конструкциях языка дело ли? Тоже самое и с макросами. Макросы — это форма, такая же как и классы, методы, языковые конструкции. Настоящая сложность не в них, а в концепциях, которые они реализуют. Если в твоих проектах используются библиотеки общих компонент, то сложность их использования и сложность использования макросов будет абсолютно одинаковой. Никакой разницы.


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

НЕКОТОРЫЕ библиотеки сложны. Сложность использования НЕКОТОРЫХ библиотек сравнима с макросами немерле.


IT>Не вижу логической связи между этими двумя утверждениями. Получается, что если макросы, то кругом одни тупые кодеры, а если MSDN, первый попавшийся у нас гений, способный одной левой разобраться с таким редкосным гауном как Custom Tools.


Студент с улицы самостоятельно разберётся с Custom Tools в течении 3 дней (в среднем), какие бы ни были там омерзительные названия методов и ключей реестра.

60% студентов с улицы не осилят макросы немерле без посторонней помощи. Какие бы там ни были красоты внутреннего $.


M>>Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.


IT>Директору может и всё равно, а начальнику IT департмента не всё равно. А если всё равно, то долго он начальником не будет.


Производственные проблемы уборщицы не должны тормозить работу фирмы. Если фирме нужны литры-километры в срок, то всё остальное должно следовать строго в фарватере.
Re[3]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 10:23
Оценка:
M>>Короче, вся эта крутизна пока не подтверждена убедительной success story.

_>Я Nemerle success story
Автор: hi_octane
Дата: 14.02.08
почти год назад выкладывал, и даже на вопросы отвечал. Проект тот и сейчас развивается.


Success story это не просто факт из жизни. Success story должна продавать что-то.

Из твоего рассказа я не очень понял, почему именно немерле и какую он бизнес-выгоду для проекта принёс.
Re[2]: Что меня не устраивает в МП в Nemerle
От: IB Австрия http://rsdn.ru
Дата: 27.12.08 10:31
Оценка: 8 (1)
Здравствуйте, VladD2, Вы писали:

VD>Он просто возмущен тем, что кто-то может сомневаться в том что автор может не знать что-то.

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

VD>Ну, что же остается только задать вопрос: А почему же автор не упомянул о такой возможности? И почему он старательно пытается избежать ее обсуждения. Ведь, казалось бы, она снимает проблему изменения синтаксиса с которой боролся.

Не снимает. Проблема не в том, что можно так не делать, проблема в том, что так делать в принципе можно, об этом говорилось уже ни раз.

VD>Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.

Позволю себе напомнить, что тут не стояла цель что-то объяснить неопытному читателю. Андрей объяснял, опытным читателям, что именно его не устраивает в Nemerle, на именно его задачах. И именно этого вы от него и требовали.

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

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

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

С набором ограниченных возможностей.

[PR метапрограммирования поскипан...]

VD>Но ты почему-то проигнорировал наши просьбы дать расскзать о проблемах МП в Немерле. Вместо этого ты почему-то рассказал нам о своих предубеждениях (ни на чем не основанных).

Во-первых, никто не обещал рассказывать про проблемы МП в немерле, обещали рассказать чем не устраивает немерле именно AVK, и именно это и рассказали.
А во-вторых, рассказали на чем именно основаны "предубеждения".

VD>Почему-то уверен, что ответов по существу не будет. Вместо этого снова будет вцеплена одна из фраз, я буду обвинен в хамстве, а автор темы снова провозгласит себя правым и обиженным. А жаль.

А ты не хами и жалеть не придется.

VD>Ведь только в честных спорах рождается истина.

Возможно. Но только честно спорить ты не умеешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[5]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 27.12.08 10:32
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Студент с улицы самостоятельно разберётся с Custom Tools в течении 3 дней (в среднем), какие бы ни были там омерзительные названия методов и ключей реестра.


M>60% студентов с улицы не осилят макросы немерле без посторонней помощи. Какие бы там ни были красоты внутреннего $.


Это который string.Format, только продвинутый? Чтобы реально с ним начать работать думаю 3 дней много будет. Можно и за пару часов управиться.
http://alvas.net — Аудио-инструменты для .Net разработчиков
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.