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

E>А в чем состояло существо вопроса?

Вот в чём:

... у Nemerle есть синтаксис и он позволяет не писать на "птичьем" языке, в то время как Форт с Лиспом буквально требуют этого — вот отличие. ...

E>Это какие?

Цитирую тебя:

... (видимо, это способ самовнушения о правильности собственного выбора). ...

E>В одной части обсуждения я предполагал, что Nemerle не станет популярным языком, скорее нишевым или аналогом Lisp-а. И в этом мнении я был не одинок, как помнится.
E>Во второй части обсуждения я выяснил у Vermicious Knid что будет происходить при расширении синтаксиса. И принял для себя решение. По вопросу, который меня интересовал. Никому ничего не навязывая и не высказывая в адрес Nemerle никаких обвинений. Разве я кого-то призывал не программировать на Nemerle или бросить это занятие?
E>Так о каких именно выводах ты говоришь?

Речь о других "выводах" которые меня задели. См. выше.

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

O>

O>... у Nemerle есть синтаксис и он позволяет не писать на "птичьем" языке, в то время как Форт с Лиспом буквально требуют этого — вот отличие. ...

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

O>

O>... (видимо, это способ самовнушения о правильности собственного выбора). ...

Но ведь складывается такое впечатление

O>Речь о других "выводах" которые меня задели. См. выше.

Вообще по поводу выводов: имхо, следует взять тайм-аут на годик и вернуться к рассмотрению Nemerle через это время.
И еще одно впечатление, не только по поводу Nemerle. Для раскрутки языка нужен killer app. Вот еще год назад про Ruby особо и не слышно было. Да, есть что-то типа Perl или Python, не более того. Даже RSS-фиды по Ruby были относительно вяленькие. Но после шумихи вокруг RubyOnRails какое-то помещательство началось (либо это мне, как Rubyist-у так кажется). В основном по поводу RoR, но и Ruby внимания перепадает. Я это к тому, что если бы на Nemerle вышло какое-то killer app, которое бы привлекло внимание к Nemerle (мол, это оказалось возможным только благодаря фишкам Nemerle), это бы более точно выявило реальные достоинства Nemerle и его потенциальную стартовую область применения.

Есть ли такой killer app для Nemerle?

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

AVK>Я, опять же, поступаю проще. Я рисую для входного XML схему и предварительно ее проверяю. Тем самым отлавливаю большое количество ошибок в схеме.
Погоди, а как схема поможет от дублирующихся значений атрибутов?
У меня сейчас нет исходников того проекта, в котором я встревал, но вот примерная иллюстрация идеи:

<businessEntities namespace="Project.BO">
  <businessEntity className="Person">
      <property type="string" name="Name" />
      <property type="int" name="Age" readonly="true"/>
    </businessEntity>
  <businessEntity className="Person">
    </businessEntity>
</businessEntitties>

Скажи мне, какой схемой я смогу проверить уникальность className в пределах неймспейса? Если бы у меня в генеренном коде стояли корректные #line, то студия автоматом ткнула бы меня носом в обе строчки, даже если они в разных xml файлах.
AVK>И атрибутов никаких в ноду добавить нельзя, и сам загрузчик конфигурированию не поддается. Можно попытаться подписаться на событие NodeInserted, но скорее всего при загрузке оно не вызывается. Хотя чем черт не шутит.
Именно это останавливает меня от интенсивного применения кодогенерации из Xml Отладка этого барахла в моей жизни занимает довольно много времени. Особенно это сказывается тогда, когда ошибку обнаруживает не тот, кто ее сделал. Порой бывает довольно сложно найти тот файл, из-за которого все сломалось.
AVK>Для пользования внутри XSLT все равно придется extension object писать.
Ясно. Спасибо.

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

E>Да, против этого возражений нет. Хотя что получится из Nemerle, когда народ начнет макросы ваять в огромных количествах (именно макросы, не только расширения синтаксиса), интересно будет посмотреть.

Посмотрим. Я верю в лучшее

O>>

O>>... (видимо, это способ самовнушения о правильности собственного выбора). ...

E>Но ведь складывается такое впечатление

Хм. Я вообще никакого выбора не делал Так что впечатление неверное. Да и аутотренингом не занимаюсь — некогда

E>Вообще по поводу выводов: имхо, следует взять тайм-аут на годик и вернуться к рассмотрению Nemerle через это время.

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

E>И еще одно впечатление, не только по поводу Nemerle. Для раскрутки языка нужен killer app. Вот еще год назад про Ruby особо и не слышно было. Да, есть что-то типа Perl или Python, не более того. Даже RSS-фиды по Ruby были относительно вяленькие. Но после шумихи вокруг RubyOnRails какое-то помещательство началось (либо это мне, как Rubyist-у так кажется). В основном по поводу RoR, но и Ruby внимания перепадает. Я это к тому, что если бы на Nemerle вышло какое-то killer app, которое бы привлекло внимание к Nemerle (мол, это оказалось возможным только благодаря фишкам Nemerle), это бы более точно выявило реальные достоинства Nemerle и его потенциальную стартовую область применения.

E>Есть ли такой killer app для Nemerle?

Был ли такой killer app для C++? А для C?

А вообще я уже писал, что мне лично хотелось бы увидеть написанным на Nemerle... А именно — O/R-Mapping tool.

В общем, ты прав — надо начинать что-то писать для себя Сегодня и начну.

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

E>>Вообще по поводу выводов: имхо, следует взять тайм-аут на годик и вернуться к рассмотрению Nemerle через это время.

O>Тогда уже не так интересно будет обсуждать Сейчас надо пытаться понять, что же в будущем будет с языком, прогнозировать, искать достоинства/недостатки... напрягать извилины, в общем. А через несколько лет естественный отбор уже сделает своё гнусное дело

Ну так это же самое главное
Как мне кажется, многие здесь прицеливаются на Nemerle не для того, чтобы проектики "для себя" на нем писать. А чтобы production-системы со временем на нем делать. Лично я с этой точки зрения на Nemerle смотрел. А что может быть лучше, чем когда за тебя грязную работу (по раскрутке или, наоборот, закрутке) Nemerle за тебя другие сделают

E>>Есть ли такой killer app для Nemerle?

O>Был ли такой killer app для C++? А для C?

За C++ не скажу сразу, зато для C был -- Unix.

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

E>Ну так это же самое главное
E>Как мне кажется, многие здесь прицеливаются на Nemerle не для того, чтобы проектики "для себя" на нем писать. А чтобы production-системы со временем на нем делать. Лично я с этой точки зрения на Nemerle смотрел. А что может быть лучше, чем когда за тебя грязную работу (по раскрутке или, наоборот, закрутке) Nemerle за тебя другие сделают

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

E>За C++ не скажу сразу, зато для C был -- Unix.

А с Си и Unix разве не была история "язык ради продукта"? Потому что с Ruby история другая, насколько я понимаю: "сначала было слово", а потом уже — RoR.

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

E>>За C++ не скажу сразу, зато для C был -- Unix.

O>А с Си и Unix разве не была история "язык ради продукта"? Потому что с Ruby история другая, насколько я понимаю: "сначала было слово", а потом уже — RoR.

Имхо, не важно, что из-за чего явилось. Важно, что C доказал свою привлекательность, когда оказалось, что на нем можно написать Unix и что после этого Unix стало легче портировать на другие архитектуры.

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

E>Никому ничего не навязывая и не высказывая в адрес Nemerle никаких обвинений.

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

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

S>У меня сейчас нет исходников того проекта, в котором я встревал, но вот примерная иллюстрация идеи:
S>

S><businessEntities namespace="Project.BO">
S>  <businessEntity className="Person">
S>      <property type="string" name="Name" />
S>      <property type="int" name="Age" readonly="true"/>
S>    </businessEntity>
S>  <businessEntity className="Person">
S>    </businessEntity>
S></businessEntitties>
S>

S>Скажи мне, какой схемой я смогу проверить уникальность className в пределах неймспейса?

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

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

Ну это мелочь. Если бы мне сильно нужно было — давно бы сделал.

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

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

Да я о другом немножко. Вот представь ты объясняешь топ-менеджменту зачем нужен Немерле. Макросы там синтаксические и прочее. При этом большая часть штата, которая на настоящий момент пишет на си-шарпе, делает круглые глаза, услышав всякие страшные слова типа "перегрузка операторов".
Tо, что можно написать "def" вместо "const int" — это конечно мощное преимущество, но представь себе — бедным людям придется еще запоминать что есть такой загадочный "def". Так что есть подозрение что это не окажет решающей роли. А решающую роль как обычно может сыграть бОльшая простота языка с сохранением хороших возможностей, более высокая дуракоустойчивость... — в общем все то, благодаря чему си-шарп "лучше" С++. А вот как у Немерле с этим?

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

ВВ>Да я о другом немножко. Вот представь ты объясняешь топ-менеджменту зачем нужен Немерле. Макросы там синтаксические и прочее. При этом большая часть штата, которая на настоящий момент пишет на си-шарпе, делает круглые глаза, услышав всякие страшные слова типа "перегрузка операторов".

Ты сам когда-нибудь пересаживал народ с одной технологии на другую и представляешь себе как это реально делается?

ВВ>Tо, что можно написать "def" вместо "const int" — это конечно мощное преимущество, но представь себе — бедным людям придется еще запоминать что есть такой загадочный "def". Так что есть подозрение что это не окажет решающей роли. А решающую роль как обычно может сыграть бОльшая простота языка с сохранением хороших возможностей, более высокая дуракоустойчивость... — в общем все то, благодаря чему си-шарп "лучше" С++. А вот как у Немерле с этим?

Чушь. Уж привыкнуть к def — дело пары минут. Гораздо болезненнее будет проходить ломка сознания при переходе от императивного подхода к функциональному. Но вот что забавно, этого не требуется в обязательном порядке. К тому же ты наверняка знаешь, что .NET позволяет легко совмещать языки. В одном солюшине могут быть проекты на VB для более простой работы с COM, на C++/CLI для работы с WinAPI, на Nemerle для замены того, что сейчас генерируется в precompile- и run-time, на C# для всего остального. Для начала Nemerle может прочно занять нишу о которой я говорю, а уже переходить на него или нет полностью покажет время.

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

IT>Ты сам когда-нибудь пересаживал народ с одной технологии на другую и представляешь себе как это реально делается?

Кое-какой опыт был

IT>Чушь. Уж привыкнуть к def — дело пары минут.

Да в общем коммент про def это было в порядке шутки, а ты уж сразу в штыки

IT>Гораздо болезненнее будет проходить ломка сознания при переходе от императивного подхода к функциональному. Но вот что забавно, этого не требуется в обязательном порядке. К тому же ты наверняка знаешь, что .NET позволяет легко совмещать языки. В одном солюшине могут быть проекты на VB для более простой работы с COM, на C++/CLI для работы с WinAPI, на Nemerle для замены того, что сейчас генерируется в precompile- и run-time, на C# для всего остального. Для начала Nemerle может прочно занять нишу о которой я говорю, а уже переходить на него или нет полностью покажет время.

Да, но есть хороший вопрос — а зачем? И вопрос далеко не риторический. Я не думаю — согласно своему опыту, который может быть и не самый показательный — что получение дополнительных наворотов вроде синтаксических макросов является серьезной причиной для перехода. Народ и существующими фичками-то не пользуется. Какие бенефиты даст немерле? Повысится надежность кода? Понизится entry level? А таковы ИМХО на сегодняший день критерии массового распространения.

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

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

VD>>Да она сама в Лиспе под большим вопросом. Язык то по сути динамически типизированный. Ну, как ты сможешь определить что некий парамерт это получает INT если в него передано сложное выражение?

Y>(declare (type integer arg)) ?

У макроса тип параметра не может быть integer. У него тип параметра должен быть "векта АСТ". Для Лиспа это будет означать S-выражение.

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

Насколько мне извесно — это невозможно.

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

ВВ>Да я о другом немножко. Вот представь ты объясняешь топ-менеджменту зачем нужен Немерле. Макросы там синтаксические и прочее. При этом большая часть штата, которая на настоящий момент пишет на си-шарпе, делает круглые глаза, услышав всякие страшные слова типа "перегрузка операторов".

А ты разве мэнеджер? Ты вроде как программист справшивал.
Ответ на этот вопрос для менеджера очень прос. Его программисты смогут делать меньше ошибок и делать работу быстрее чем раньше. А вот детали того почему это так требуют вдумчивого изучения возможностей языка.

ВВ>Tо, что можно написать "def" вместо "const int" — это конечно мощное преимущество, но представь себе — бедным людям придется еще запоминать что есть такой загадочный "def".

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

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

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

Даже приведенный тобой пример с "def" и "const int" является показательным. Ведь "const int" в C# позволяет только лишь определить константу. В отличии от С++ эта константа сама должна основываться только на константакх. В то же время def, как минимум, позволяет задать неизменяемую переменную на основе выражения. Причем как в виде члена класса, так и в виде локальной переменной. Это уже нет в C#. Это конечно есть в С++, но в С++ нет много что есть в C# и в добавок есть море собственных проблем.

Но "def" не ограничивается введением переменных доступных только для чтения! "def" позволяет описывать локальные функции (которых тоже, кстати, нет в C#). Кроме того "def" позволяет описывать так называемое частичное применение. Это для большинства императивщиктов вообще не понять. Например, это:

def add5 = _ + 5;

Приводит к тому, что мы получаем функцию добавляющую 5 к своему аргументу.

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

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

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

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

IT>Это — не плохой аргумент. Это — жизнь. В середине проекта, в котором участвует только девелоперов с полсотни, менять VCS из-за проблем с кодогенерацией в одной из шести команд — это безумие. Никто на это не пойдёт. Да и худо бедно до этого работали, пока не начали умничать.

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

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

ВВ>Да, но есть хороший вопрос — а зачем? И вопрос далеко не риторический. Я не думаю — согласно своему опыту, который может быть и не самый показательный — что получение дополнительных наворотов вроде синтаксических макросов является серьезной причиной для перехода. Народ и существующими фичками-то не пользуется. Какие бенефиты даст немерле? Повысится надежность кода? Понизится entry level? А таковы ИМХО на сегодняший день критерии массового распространения.

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

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

IT>>Это — не плохой аргумент. Это — жизнь. В середине проекта, в котором участвует только девелоперов с полсотни, менять VCS из-за проблем с кодогенерацией в одной из шести команд — это безумие. Никто на это не пойдёт. Да и худо бедно до этого работали, пока не начали умничать.

VD>Не выдумывай. Во-первых, в середине проекта никто не станет прибегать к кодогенерации. Это архитектурное решение.

Кодогенерацию начали делать с самого начала. Проблемы вылезли в середине. Что тут непонятного?

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

А ты попробуй это с VSS, потом расскажешь.

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

VD>А ты разве мэнеджер? Ты вроде как программист справшивал.

А ты вспомни свои аргументы против С++. И как кто ты их приводил? Проблемы у С++ начинаются не когда один гуру пишет некий проект, а когда таких гуру несколько. Можно хорошо писать на любом языке, но точно также можно и плохо.
Если подходить к вопросу только с позиции "как программист" то мне тогда непонятно чем в свое время С-макросы не угодили и почему их нет в си-шарпе. Ведь я-то знаю, что лично я всегда бы использовал макросы только "хорошо" и они не усложнили бы мой код, а только сделали бы его короче и читабельнее.

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

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

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

IT>Например, вот для чего. Первые два класса абстрактные и полностью генерируются в run-time. У большинства методов датааксессоров код типовой и может легко свестись к декларации. Compile- и run-time генерация может сделать эту декларацию расширяемой, т.е. где можно мы оставляем декларацию, где хотим добавляем код по вкусу. Подобного типового кода, который нельзя затолкать в обычные процедуры, но в котором просматриваются чёткие паттерны, обычно навалом в любом проекте, нужно только захотеть поискать. Сейчас это отчасти решается средствами run-time генерации. С этим жить, конечно, можно, но не так прикольно.

Игорь, ты прочитай мой исходный вопрос. Что, RFD — это типичный пример бизнес-приложения? Я лично десять раз готов подписаться под тем, что синтаксические макросы это круто, но вопроса это не меняет.