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

IT>Да прекращай ты народ и самого себя запугивать. Ничего никому не выгодно. Всё течёт и развивается своим естественным путём. Посмотри хоть на проект Nemerle. У этого проекта есть только три варианта развития:

IT>1. Nemerle станет достаточно популярен и отберёт у C# существенную, а со временем возможно и всю нишу. MS будет курить в сторонке.
IT>2. MS прекратит баловаться всякими детскими штучками типа LINQ и начнёт развивать C# по взрослому. Тогда будет два конкурента, что есть гуд.
IT>3. MS купит команду Nemerle и конкуренция будут происходить в самой MS

Есть еще один вариант развития: Nemerle станет популярен, но в достаточно узком кругу, и чтобы этого не произошло необходимо наличие "change agents", т.е. людей которые готовы внедрять, применять и популяризировать Nemerle на практике, в рамках "change projects". И очень хочеться верить, что этими "change agents" станут люди, ныне обсуждающие/увлекающиеся Nemerle на RSDN.

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

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

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

E>Это всегда так, к сожалению
E>Все равно, желаю удачи

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


E>Все таки как-то грусно смотреть на такие вещи... Такая сильная привязанность к VS...

Просто потому, что это удобно. Я лучше поработаю над плагином, чем буду снова писать код в плоском текстовом редакторе и собирать проект make-файлом

Здравствуйте, eao197, Вы писали:
E>Блин, ну вот опять... Да со стандартными расширениями я свой DSL подружить всегда смогу.
E>Но я не смогу органичивать пользователей своего DSL от совместного использования моего DSL с чужими DSL. В одном файле, в одном контексте.
E>А когда у пользователей из-за моего DSL возникают проблемы в их коде -- они сделают то, что ты раньше и предлагал -- выбросят мою библиотеку. А вот это уже не допустимый сценарий.
Ну, я бы на самом деле не стал по этому поводу сильно плакать. Синтаксические расширения — это, фактически, введение своего диалекта.
Дотнет сам по себе специально заточен для межъязыковой интеграции. Считай, что у тебя появится возможность писать проекты на чуть большем количестве языков. В самом хреновом случае — когда у тебя есть легаси проект на диалекте, которого ты не знаешь и не хочешь знать, всегда есть возможность изолировать это чудо в отдельный проект и линковаться с ним на уровне сборки.
Более того, как я понимаю, немерле позволяет абстрагироваться на уровне отдельного исходника. Отлично — хочется тебе применить сразу два расширения к одному классу — так вперед, partial class и дело в шляпе. Ситуация, когда тебе захочется иметь два противоречивых расширения в пределах одного метода, по моему мнению возникнуть не может. Она сродни желанию придать одновременно два смысла оператору +. Так что на первый взгляд есть полный набор средств защиты от нежелательного секса. Все, как в жизни:
— можно просто не спать с незнакомыми
— если припрет, то можно спать, но в разных комнатах
— если совсем припрет, можно спать хоть в одной кровати, но с LifeStyles наготове

Здравствуйте, AndrewVK, Вы писали:
AVK>Вот только чтобы кто то другой прочел это нужно, чтобы все термины этот другой понимал. А вот если программа состоит наполовину из неизвестных терминов, то понять это чужому будет крайне сложно.
Ты совершенно прав. Но мне кажется, что эта проблема не намного тяжелее, чем применение сторонних библиотек в банальном сишарпе. Никогда не сталкивался с изобилием реализации DropDownList и TabStrip в асп.нете? А результат получается примерно такой же. Да, язык — один и тот же, но словарный запас шибко различен.
Или еще можно пользоваться несовместимой системой именования объектов, вместе с экзотическим выравниванием. Сразу получаем "французский акцент".
Насколько мне известно, как раз в студии начали вводить возможности для архитекторского произвола — типа фиксировать некоторые настройки, и до свидания. Никаких неодобренных библиотек, никаких табов размером в пять с половиной символов. Аналогичное решение можно бы поприменять и для немерле — чтобы в проекте было состряпано конечное количество DSL с четко специфицированными областями применения. А не так, что половина кода пользуется макросами, половина наколбашена вручную, а кто-то все то же из XML кастом тулом генерит.

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

Д>Просто потому, что это удобно. Я лучше поработаю над плагином, чем буду снова писать код в плоском текстовом редакторе и собирать проект make-файлом

[offtopic]
Проские текстовые редакторы, имхо, сейчас еще поискать нужно. Называть emacs, vim, jedit, и пр. обычными редакторами как-то язык не поворачивается.
Да и make сейчас уже вчерашний день. Наверное, только упертые unix-оиды ими пользуются. И то, те, кому кроссплатформенность не нужна. Остальные же переходят на Scons, Boost.Build, Ant, CMake, MPC и пр.
[/offtopic]

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

Д>наводит на такие мысли )

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

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

S>Андрей, пользуясь случаем: я в свое время имел дело с кастом тулом для XSLT процессинга.

Я кастом тул не очень люблю, у него много ограничений. Проще запускать утилитку перед компиляцией.

S>Так вот я так и не нашел способа генерить нормальные директивы #line, т.к. в XSLT процессоре нету доступа к номеру строки входного XML. Ты не знаешь, эта задача имеет решение?

Не знаю. Мне как то не нужно было. Читстых решений однозначно быть не может, потому что источником для преобразования служит XPathNavigator, а у него совсем не обязательно вобще есть такое понятие как номер строчки. Грязноватое и трудоемкое решение — создание своего DOM, содержащего номера строк для каждого узла и XPathNavigator для него. Совсем грязное, но не такое трудоемкое — написать свой загрузчик XmlDocument из XmlTextReader, который параллельно построению документа строит таблицу соответствий между каждым узлом и позицией в тексте.

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

Д>>>Если в программе нет никаких неизвестных терминов,

AVK>>А если есть?

Д>А если сначала прочитать сообщение не "по диагонали", а целиком?

Взаимно. Ситуации, когда незнакомых терминов нет меня в контексте данногог вопроса не интересуют.

AVK>>Вот вот — чтобы разобраться в исходниках нужно изучать рефлектором код макросов.

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

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

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

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

AVK>Взаимно. Ситуации, когда незнакомых терминов нет меня в контексте данногог вопроса не интересуют.

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

AVK>Это останется. Добавится незнакомый синтаксис. Неужели для тебя нет разницы между кодом на незнакомом языке и кодом с использованием незнакомой библиотеки?

Есть разница. В том, что в первом случае враг сразу виден в лицо. И у программиста не создается ложного впечатления, что он понимает, как всё работает.

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

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

AVK>>Я не понимаю чем тут восторгаться. Ты Форт выдел? Там то же самое, даже еще круче. И это его и убило.

O>Нет, в Форте не то же самое. Форт — язык интерпретируемый, без строгой типизации. И без синтаксиса — там просто есть слова, работающие с двумя стеками — и всё. А определение нового слова — всего лишь добавление строки в словарик.


Ну форт не совсем интерпретатор, и в этом он тоже особняком.


O>В Nemerle совсем не так всё сделано — тут тебе и строгая типизация, и проверка корректности макросов на этапе компиляции, и вменяемые диагностические сообщения... И никакой чехарды со стеком.

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

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

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

Ты недооцениваешь возможности Nemerle. Они позволяют, к примеру, эмулировать синтаксис Питона.

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

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

VD>>Они и есть отарытый вроде.

AVK>Я в списке Open projects его не обнаружил. Из относящегося к нему я заметил только комплит.
Open projects — это которые еще не занятые.

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

AVK>Не знаю. Мне как то не нужно было.
А жаль. Вот такие мелочи меня неприятно удивляют. Казалось бы, в чем проблема — живи и пользуйся. Увы. В самых простых случаях — сгенерился, к примеру, duplicate identifier. Это однозначный косяк Xml, в котором надо поправить результат неосторожного copy-paste. Увы, позиционироваться на него способа нет; вместо этого приходится вкусывать текст из .cs и выполнять контекстный поиск...
AVK>Читстых решений однозначно быть не может, потому что источником для преобразования служит XPathNavigator, а у него совсем не обязательно вобще есть такое понятие как номер строчки.
Это понятно.
AVK>Грязноватое и трудоемкое решение — создание своего DOM, содержащего номера строк для каждого узла и XPathNavigator для него. Совсем грязное, но не такое трудоемкое — написать свой загрузчик XmlDocument из XmlTextReader, который параллельно построению документа строит таблицу соответствий между каждым узлом и позицией в тексте.
Ясно. А может, есть способ доработать напильником загрузчик XmlTextReader, который будет добавлять в каждый элемент документа что-то вроде атрибута? Чтобы это можно было относительно легко пользовать внутри xslt.

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

AVK>Ты недооцениваешь возможности Nemerle. Они позволяют, к примеру, эмулировать синтаксис Питона.

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

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

AVK>Ты недооцениваешь возможности Nemerle. Они позволяют, к примеру, эмулировать синтаксис Питона.
Замечательно. А чем это отличается от применения Python.NET в рамках solution? Выбор языков остается на совести архитектора. Если ты считаешь, что оно оправдано — применяешь. Если не считаешь — не применяешь. Случайно попитонить вряд ли получится; девелоперам до пятого дана писать синтаксические макры нужно запретить под страхом перевода в ночной суппорт.

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

S>А жаль. Вот такие мелочи меня неприятно удивляют. Казалось бы, в чем проблема — живи и пользуйся. Увы. В самых простых случаях — сгенерился, к примеру, duplicate identifier. Это однозначный косяк Xml, в котором надо поправить результат неосторожного copy-paste. Увы, позиционироваться на него способа нет; вместо этого приходится вкусывать текст из .cs и выполнять контекстный поиск...

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

S>Ясно. А может, есть способ доработать напильником загрузчик XmlTextReader, который будет добавлять в каждый элемент документа что-то вроде атрибута?

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

S> Чтобы это можно было относительно легко пользовать внутри xslt.

Для пользования внутри XSLT все равно придется extension object писать.

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

FR>Это не важно, важно то что и форт и лисп и немерли очень гибкие, и эта гибкость очень легко может привести к тому что язык расползется, превратится в кучу трудно совместимых и непонятных непосвященым диалектов.

Да нет уж. Я уже тут где-то писал, что у Nemerle есть синтаксис и он позволяет не писать на "птичьем" языке, в то время как Форт с Лиспом буквально требуют этого — вот отличие. И вот почему Nemerle не станет кучкой диалектов — потому что у него уже есть основной диалект, который будет только расширяться.

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

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

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

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

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

Значит, по существу вопроса замечаний нет?

Кстати, твои выводы просто таки блещут логичностью

E>Насколько я помню, Vermicious Knid (кто реально щупал Nemerle) прогнозов как раз не делает.

Ну и? Другие люди пусть не делают прогнозы, а я их делать не боюсь.

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

O>Значит, по существу вопроса замечаний нет?

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

O>Кстати, твои выводы просто таки блещут логичностью

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