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

AVK>> Серебрянных пуль, как ты знаешь, не бывает. За повышенную гибкость и мощность надо платить. Вопрос в том чем.

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

Если недостатков не найдем, значит мы их пропустили, следовательно высокие риски сохраняются. Или ты все таки считаешь что серебраные пули есть?

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

VD>Классная аргументация. То есть проблема в том, что в С++ не удалось изменить синтаксис как надо?

А как надо? Ты считаешь что каждый программист способен сделать грамотное изменение синтаксиса языка? ИМХО для этого нужна квалификация и объем работ, на голову больший, нежели разработка API.

VD>В общем, это смахивает на попытки найти проблемы любой ценой.

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

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

AVK>>А что, можно? Сам же тут расписывал про глюки кодогенератора.

VD>Где? Ты что-то путашь.

Где в коде с хеш-таблицей вылез никому не нужный Tuple.

AVK>>У меня практически нет таких задач, для которых его можно использовать. Поэтому для меня Nemerle в практическом плане пока не более чем концепция.

VD>Что-то не верится. Уверен, что в работе всегда появляются мелкие задачи которые нужно решить максимально быстро.

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

VD>>>Хм. Когда в 2001 ты взялся за C# и донет, то ты значит за паравозом не бежел?

AVK>>Нет, потому что дотнет львиную долю своих фич взял от джавы.

VD>А Нэмерл из C#, ML и Схемы. И что?

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

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

VD>Можно поднять твои посты 2001-2002 годов и убедиться, что скепсиса подбного проявляемому сейчас от тебя слышно не было.

Подними.

AVK>>Я имел ввиду разработчик конкретных расширений не ломает синтаксис языка.

VD>Синтаксис у CTR свой. Это отдельный и довольно убогий движек текстуальных шаблонов.

Но он один. Его достаточно один раз изучить. Я не увижу в других программах другого синтаксиса.

AVK>>Это пока я как ты, все свои проекты пишу один. А вот как не один, то уже все не так просто.

VD>Дык в чем проблема то?

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

AVK>>Вот только мне не нужен такой сложный и навороченный DSL.

VD>Какой сложный? И какой навороченный?

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

VD> Ты не забыл, что каждая команда вольна сама определять все что хочет?

В том то и дело что не забыл.

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

[демагогия поскипана]

AVK>>Только вот пока не стал. Следовательно никто в этом мире не способен предсказать проблемы языков с изменяемым синтаксисом на тяжелых и долгих приложениях.

VD>Стоп. Он не стал просто потму, что молод.

Доказательств у тебя нет.

VD>Зашибись. А чем же Nemerle тут от Шарпа то отличается? Точно так же привносит новое в уже готовую среду.

Количество нового несопоставимо.

AVK>>Знаешь чем мне нравится C# Team — они очень долго обсасывают каждое изменение в языке.

VD>Знашь чем не они не нравятся? Они очень долго обсасывают каждое изменение.

Я уже говорил — бег перед паравозом конечно завлекателен, но плохо совместим с коммерческой разработкой софта.

VD>Ага. Самое надежное решение тут будет ничего не делать. Вон в С++ так и поступают. Промежутон между стандартами более 10 лет...

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

AVK>>То есть ты сам пока не можешь с уверенностью сказать что это мегарулез без недостатков?

VD>Не могу. Как не мог сказать этого в 2001 про C#.

Ну а чего тогда ты от меня этого требуешь?

VD>Ну, вот в языке все пока что выглядит очень гладно. ОО 1:1 как в C#. И вообще многе из него взято. Функциональщина взята из ML, т.е. тоже проверенное решение. Макросы из Схемы. Рантайм — дотнет. В итоге получается композиция проверенных решений.

...

AVK>>Т.е. недостатков в языке ты не видишь?

VD>Так чтобы бросались в глаза пока не вижу.

Т.е. таки серебряная пуля?

[демагогия поскипана]

AVK>>Пока я задаю вопросы. Например — очевидно что язык, в котором ключевых слов много,

VD>Много? А откуда ты это взял? Ключевых слов не больше чем в Шарпе.

От того что их можно самостоятельно добавлять.

AVK>> да еще и их набор может изменяться (в том числе и неявно)

VD>Это как не явно?

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

AVK>>Читай внимательнее — информации о практической применимости. Много ты знаешь мало мальски долгоживущих проектов на Nemerle окромя его самого?

VD>А зачем же его самого то исключать? Прокт огромный и сложный.

Затем что его создатели не заинтересованы в демонстрации фундаментальных проблем в языке.

AVK>> С какими проблемами столнулись их (проектов) создатели? Что выгадали на практике, а не в теории?

VD>Можно спросить у того же Vermicious Knid. Он вроде бы уже что-то пописал на нем.

Что? Все что я слышал — какое то мелкое баловство.

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

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

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

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

VD>То-то и оно. Я бы сказал так "мысли в слух" sv. "научная разработка".
VD>Тебе там осталось сделать чуть-чуть изобретений. Изобрести квази-квотирование. Гигиеничность макросов. Рефлексию времени компиляции.
Вобщето я и это изобрел... только сейчас сообщение найти не могу.

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

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

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

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

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

Если в программе нет никаких неизвестных терминов, но они записаны неявно, "подразумеваются" под горами классов и методов — это по твоему проще, что ли?
Реальный код, который скрывается под неизвестными терминами, можно просто посмотреть рефлектором. Наверняка есть и более прямые способы. А вот восстановить исходные понятия из под гор кода (в особенности оптимизированного) — очень сложная и нетривиальная задача.

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

AVK>Где в коде с хеш-таблицей вылез никому не нужный Tuple.
Этот тупл устраняется элементарным анализом потока данных. Болие того ни к чему кроме незначительного замедления программы он не может привести в принципе. Так что назвать это серьезной проблемой я не могу.

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

AVK>Есть ненулевая вероятность, что они правы. В отличие от тебя я в повальный идиотизм всех тех, кто им занимается не верю.

Не идиотизм. Просто инертность, упрямство и косность мышления. Чем еще можно объяснить ситуацию с указателями на методы объектов, например?

AVK>Т.е. таки серебряная пуля?

когда Брукс писал про "серебряную пулю", он имел в виду совсем другое

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

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

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

VK>Если ты их используешь, то будь готов к проблемам и к их решению.

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

Все что я вижу в разговорах про Nemerle пока наводит на подобные аналогии с C++. И аргументы такие же: "Это крайне редко используется... Мне не приходилось... У меня проблем нет..."

E>>

E>>VLADD2_FOREACH_IN_HASH( k, h; hash ) { ... }

E>>EAO197_DECLARE_PERSISTENT_ATTR v : some_type;
E>>

VK>Извини, но это какой-то идиотизм и бред.

Извини, но идиотизм в том, чтобы цеплятся к конкретным примерам. Ну пришло мне в голову при написании только FOREACH, его и написал. Будь уверен, в реальной жизни возникнет соблазн сделать еще и не такое. А например, вот так бы я себе представил то, что мне интересно:

agent_class LoadBalancer
  message MsgAddNode { ... }
  message MsgRemoveNode { ... }
  message MsgTakeNodeStat { ... }
  message MsgPing { ... }
  event EvtAddNode( m : MsgAddNode ) { ... } autosubscribe MsgAddNode priority 0
  event EvtRemoveNode( m : MsgRemoveNode ) { ... } autosubscribe MsgRemoveNode priority 0
  event EvtTakeNodeStat( m : MsgTakeNodeStat ) { ... } autosubscribe MsgTakeNodeStat priority 0
  event EvtReconfigure( m : Configurator.MsgConfig ) { ... } autosubscribe MsgConfig form Configurator.AgentName() priority 1;

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

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

E>Извини, но идиотизм в том, чтобы цеплятся к конкретным примерам. Ну пришло мне в голову при написании только FOREACH, его и написал. Будь уверен, в реальной жизни возникнет соблазн сделать еще и не такое. А например, вот так бы я себе представил то, что мне интересно:
А в чем проблема то? Берешь и пишешь сборку с этими макросам. Потом в отдельном файле пишешь using MyCoolMacroNamespace; и описываешь. Если не написать using MyCoolMacroNamespace; то этих макросов не будет.

E>И есть у меня определенные сомнения, что задание подобных вещей через атрибуты будет удобнее переопределения синтаксиса. И если я смогу сделать такие вещи на атрибутах, то зачем вообще с Nemerle связываться, если есть C#? Но это уже риторический вопрос, даже больше эмоции.
Пожалуйста не путай атрибуты в C# и то что мфкрос можно использовать с темже синтаксисом что и атрибуты. Это разные вещи.

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

AVK>Только вот на C# их хватает, а на Nemerle пока нет.

1. "Они" под серьезным приложением явно понимаю некий Ворд от МС целиком написанный на дотнете. Януса им явно мало, а некие корпоративне продукты не так то просто показать.
2. Nemerle сейчас находится в стадии аналогичной C#-у в 2001. То есть, язык уже сформироан, но пока числится в бэтах. Что-то я не припоминаю засилия C#-программ, да еще и серьезных в 2001 году. Вот через 5 лет можно будет серьезно обсудить этот вопрос.

AVK>Это не значит что NEMERLE плохой, это значит что его использование влечет за собой очень высокий риск.

Конечно все новое влечет определенный риск. Но что-то в данном случае я особого риска не наблюдаю. Слишком хорошая подстраховка в виде дотнета есть. Да и язык сильно эмулирует C#. Так что приемственность очень высока.

Кстати, почитал их макросы поставляемые с компилятором... Оказывается C# содран только на уровне описания классов. Все statments и expressions в основном присуствуют в виде макросов. Я оифигел когда увидел, что даже операторы &&, ++, += и т.п., в общем, осная куча, реализованы в качестве макросов!

Макросами реализованы и буквально все операторы языка. Даже if/else и то макрос.

Это смешно, но во всем языке есть только пара операторов среди которых главных — это match. match-ем они эмулируют буквально все. И при этом, используя язык фиг подумашь, что все синтаксическое богатсвто — это всего лишь эмуляция! Блин, а ведь кто-то тут рассуждал о сложности языка! Да по сравнению с Нэмерлом Васик — это переусложненный язык.

В общем, я не перестаю фигеть с грамотности проектирования этого языка.

AVK>У меня и так полно дел. Статью, к примеру, писать нужно.

Это да. Я вот разрываюсь сейчас на 3 фронта. Нэмерлом в основном занимаюсь по ночам. Надо переходить на статьи о Нэмерле. Тогда глядишь и время разгрузится.

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

AVK>Так там ничего стороннего не используется, только набор собственных макросов.

Дык, я в том числе и о макросах. Они тоже чисты как слеза.

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

AVK>Если недостатков не найдем, значит мы их пропустили, следовательно высокие риски сохраняются.

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

В общем, даже не хочу обсуждать это.

AVK>Или ты все таки считаешь что серебраные пули есть?

Я вижу явное и существенное превосходство Нэмерла над C# и вижу ниличие в Нэмерле всего того что меня подкупало в C#.

Является ли Нэмерел панацеей? А является ли ею C#? Нет? Ну, вот и Нэмерел — нет. Что в прочем не мешает ему рвать C# и все остальные языки как тузик грелку.

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

WH>Вобщето я и это изобрел... только сейчас сообщение найти не могу.

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

VD>>В общем, ты обозначил требования, а в Нэмерле предложили реализацию. Причем работающую и очень неплохую.
WH>Ну реализацией надо заниматься...

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

Ну, и главое. А стоит ли теперь ломать копья?

Ты погляди на директорию nemerle-0.9.2.99.6088\macros. После изучения ее содержимого начинашь реально понимать всю мощь макросов и прозарливость авторов Нэмерла. Ведь даже операторы &&, +=, ++ и т.п. являются макросами! А о разных if-ах и говорить не приходится. В языке по сути есть только конструкция match. Остальное макросы. И ведь, при этом, хрен подкапашся к качеству и гибкости языка!

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

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

VD>>Классная аргументация. То есть проблема в том, что в С++ не удалось изменить синтаксис как надо?

AVK>А как надо?

Надо под делу. Без проецировния проблем одного языка на другой.

AVK> Ты считаешь что каждый программист способен сделать грамотное изменение синтаксиса языка?

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

AVK> ИМХО для этого нужна квалификация и объем работ, на голову больший, нежели разработка API.

Ну, API — это ты перебарщивашь. Погляди на макросы идущие в поставке Нэмерала. Все их API умещается в тех же файлах где объявлены макросы.

А вот опты конечно нужен. Ну, так новичет просто не поймет как получить доступ к макросам. А сами макросы получит.

К примеру, согласить круто вместо:

string.Formar("Имя: {0} Фамилия: {0}", name, lastname)

писать:

$"Имя: $name Фамилия: $lastname",

Причем ошибиться нигде нельзя! Если ты впишешь неверное имя переменной в текст, то тебя остановит компилятор! А в C# ты рискушь получить ошибку во время выполнения (неверный форма или еще что).

Так что грамотно написанный макрос способен сделать код даже надежнее. И уж точно он делает код более кратким.

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

VD>>В общем, это смахивает на попытки найти проблемы любой ценой.

AVK>Влад, если ты будешь опять переходить на наезды как только кто то посмеет высказать мнение, не совпадающее с твоим, я буду игнорировать твои топики.

Нет уж. Ты меня извини, но ты пыташся защитить свой ничем не обоснованный скепсис. Я с этим скепсисом в корне не согласен. Причем именно потому, что он ничем не обоснован. Это все из серии "как бы чего не вышло". И ведь не выйдет, если зачмарить хорошую вешь в зачатке.

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

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

AVK>Есть кардинальное отличие между кодогенерацией или там постобработкой сборок и правкой синтаксис а языка. Последнее затрагивает значительно более глубинные слои.

Сверху всё выглядит одинаково. Переопределяешь ли ты поведение в отнаследованном классе или добавляешь его в класс — какая разница? Оба подхода служат одной цели...

Кстати, использование Reflection.Emit приводит, например, к таким "приятным" мелочам, как создание инстанса только через фабрику. В Nemerle же можно переопределить поведение класса и создавать его с помощью new. Ещё одна приятная мелочь в копилку языка.

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

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

object bizObj = _f._c<_b>();

Что ж это получается — C# тоже вреден, раз позволяет так писать? Да нет — это скорее означает, что никто моей библиотекой не будет пользоваться — всего и делов. И культура, образовавшаяся вокруг C#, не пострадает от моего корявого кода.

Точно так же и с Nemerle — пусть в нём гораздо больше вкусностей, но писать на нём будут тоже люди, которым тоже не чуждо всё прекрасное

AVK>Собственно именно из-за этого имхо помер Форт.

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

Кстати, писать на Форте мне очень даже нравилось. Почему-то я его понял практически сразу, в отличие от Лиспа и Хаскеля (которых я так и не смог побороть — гения, видно, не хватило ).

AVK>Только мне почему то больше нравится решение, когда DSL узок, чисто декларативен и, желательно, в графическом или GUI представлении. Т.е. понимание и пользование его легко даже неспецу, контроль предельно жесткий. Создание DSL на базе большого и гибкого языка не кажется мне бесспорной идеей.

Ну... на DSL свет клином не сошёлся. Макросы Nemerle это имхо средство метапрограммирования вообще, а не средство написания DSL-ей. На Nemerle можно легко юзать AOP, писать всякие там O/R-Mapping tools, расширять функциональность классов... в общем, делать всё то, что сейчас в шарпе делается немножко через это самое.

Ну а возможность создать свой синтаксис имхо тоже может пригодиться. Опять же — для уменьшения объёма конечного кода. LINQ же тебя не пугает?

PS: Нет, конечно, всегда можно написать какую-то птичью бяку на любом языке (см. мой пример на C#), но Nemerle к этому не обязывает (как, например, язык регулярных выражений, Perl или Lisp). А раз не обязывает и раз у него есть нормальный синтаксис (так похожий на C#), то люди вряд ли будут делать из него что-то неудобочитаемое.

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

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

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

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

Вот на таких размышлениях и основываются мои слова.

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

AVK>Если недостатков не найдем, значит мы их пропустили, следовательно высокие риски сохраняются.

Если Nemerle (или его идеи — речь о них) и завоюет популярность, то этому будет предшествовать долгий процесс интеграции в среду разработчиков. За это время, я думаю, очень много чего всплывёт на поверхность. Индустрия что попало не примет, т.к. в ней денежка крутится.

AVK>Или ты все таки считаешь что серебраные пули есть?

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

Кстати, тут очень к месту эпиграф с сайта http://nemerle.org/ из Урсулы Ле Гуин

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

ВВ>А ничего если я спрошу? (без тени скепсиса )

Ничего, если отвечу и я? (освещённость скепсиса аналогична)

ВВ>Какие бенефеты ты лично видишь от использования Немерле при разработке бизнес-приложений?

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

Ещё бы я активно использовал вывод типов (писать что-то вроде Dictionary<int, MenuTreeNode> по много раз задалбывает). Больше с ходу ничего не придумывается.

Ну и очередная мечта — имхо на Nemerle получилось бы написать неплохую O/R-Mapping tool... Это я говорю как человек, измученный NHibernate Только вот где ж стока времени-то валяется...