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

GR>Я на этом форуме по больше части в режиме ReadOnly, но в этот раз не удержался.
GR>Сообщество Nemerle вполне дружелюбно к тем, кто ведет себя адекватно. Не припомню, чтобы человеку, которому нужен был совет или помощь в освоении языка было отказано или сказано что-то типа RTFM или ToGoogle, или оставлено не замеченным. В крайнем случае даются ссылки на статьи + небольшие пояснения, но в большинстве случаев дается вполне достаточный для понимания ответ с примерами кода. Конфликты возникают в основном с теми личностями, которые не пытались написать ни строчки кода и высказывают свое мнение о языке.

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

GR>ИМХО негатив идет извне, а не изнутри сообщества Nemerle, а в соответствии с третьим законом Ньютона возникает негатив равный по величине и противоположный по направлению.

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

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

_FR>>Если я хоть что-то понимаю в логике, то из того, что "Без mutable вообще не обойтись" и "количество mutable на квадратный милиметр кода как бы является показателем качества кода" говорит о том, что как не старайся, но качественного кода написать невозможно, ибо так как без изменяемых переменных нельзя и "редко", но они нужны
VD>Качественный код — это сферокнь вакумный. У понятия качество есть много составляющих. Одна из них скорость. Императивный код иногда может позволить поднять скорость. А стало быть и mutable вещь необходимая.
VD>Плюс иногда императивные решения бывают тоже хорошими. Но все же значительно реже.

Ну о качестве не я заговорил А "чистота" и "правильность" — ещё более сферические и более вакуумные понятия "Качество" по сравнению с ними более определено.

VD>В общем, большое количество mutable — это четки показатель не лучшего по качеству кода. Для начинающего это нормально. Но со временем объем mutable должен снижаться. Если это не так — это четко демонстрирует отсутствие прогресса в изучении языка.

С этим я нисколько и не возьмусь спорить. Я только пытаюсь высказать свою точку зрения на то, что для привлечения пользователей у Немерле есть только один выход — это сделаться C# с праттерн-матчингом и макросами. И только. Другие отличия, не призванные служить этому, будут мешать. Все остальные языки останутся игрушкой для любознательных. Если будет стабильным — то, возможно, и не игрушкой, но для любознательных. А для этого всякие "mutable", которые, тем более, что по-началу, будут использоваться часто, не должны отталкивать и мешать "в угоду обучения".

_FR>>>>Если этот факт не верный, то mutable надо убрать, а если верный, то не нужно искусственно усложнять.
VD>>>Тут можно провести аналогию с checked/unchecked. Нужны они крайне редко, но иногда нужны. Так что это не повод выкидывать их из языка.
_FR>>Аналогия мне кажется неуместна.
VD>Чем же это? Полная аналоги. Без фичи нельзя, но используется она не часто, частая ее использование почти наверняка указывает на низкое качество кода.

А, в этом плане уместная. Я под "неуместностью" понимал не наличие фичи, а ей, фичи, синтаксис: def/mutable vs checked/unchecked — пускай хоть и многословно, но зато сразу ясно о чём речь, а def/mutable, такое впечатление, что описывают совсем-совсем разные вещи.

_FR>>Я очень уважаю srp, ибо образ, созданный Борисовым в "за двумя зайцами" показателен более чем. Мне кажется, что для завоевания пользователей более полезным было бы сосредоточиться на желаниях программистов, даже в чём-то подыгрывая им.

VD>Дизайн языка — это тонкий процесс. Тут очень легко впасть в крайности. Идя на поводу у популизма очень легко сделать "грязный" язык которым никто не захочет пользоваться.

У "крайностей" две стороны и мне кажется, что Немерле впало во-вторую — идейную.

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

Не нужен диалект, посудите сами: спецам в немерле должно быть без разницы, что использовать: var или mutable, ибо они прекрасно понимают, с чем имею дело. А вот начинающим mutable категорически неудобен. Если вы хотите сделать язык для гиков — оставляйте mutable и думайте, что всё в порядке. Начинающим же это будет доставлять неудобство.ю Более того, намеренно вами сделанное. С точки зрения необходимости завоевания языком популярности — очень странное решение. Поверьте, огромное количество программистов не может писать код без изменяемых переменных.

_FR>>Более мудрым был бы шаг сначала завоевания большого числа пользователей, а потом уже [аккуратное!] привитие им кульных навыков.
VD>Это взаимно противоречивые требования. Если язык завоюет популярность в грязном виде, то появится груз обратной совместимости. Да и код в котором может быть и так, и так — это не очень хорошее решение. Это ведь точно так же будет отталкивать людей.

Если вы считаете, что "var" сделает язык "грязным" — то кто же впадает в крайности? В таких рамках посоветовать что либо я, например, не в силах, может кто другой справится и само обойдётся.

VD>Но вот использование val вместо def — это плохая идея. Все же между изменяемыми и неизменяемыми переменными должна быть явная синтаксическая разница.

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

VD>Кстати, одна из причин почему в C# редко используют неизменяемые поля — "длинный" синтаксис их объявления. В Немерле все с точностью до наоборот. По умолчанию (без дополнительных модификаторов) получается неизменяемое поле. И это очень здорово! Программист создает неизменяемые поля даже не задумываясь. И часто они таковыми и остаются. Ну, а если ему требуется изменяемость, то рано или поздно программист получает сообщение от компилятора и меняет объявление. Это заставляет его задумываться над тем нужна ли ему изменяемость.

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

_FR>>Такие умные и все из себя функциональные, как вы, могут использовать неудобное (для самого же себя) mutable, дабы не расслабляться. Да пожалуйста. А все остальные зачем должны страдать какое-то время (пока не постигнут Дао иммутабельности)?

VD>Дело в том, что неудобство mutable — это еще одна фобия. "mutable" комплитится с двух букв. Так что при написании это проблем не вызывает. Ну, а то что mutable лучше выделяется от этого только польза. Кто не хочет лучше видеть объявления переменных? Со временем приходит и понимание того, что mutable много быть не должно.

Это длиннее читать. Это сложнее выравнивать как, например, IT делает в исходниках. В первую очередб для меня это никак "не бьётся" c "def".

_FR>>Вы уверены, что люди считают, что им это нужно? Поэтому такие экстримистские, как бы я их назвал, подходы кажутся обречёнными на провал. Но это не страшно, благодаря ошибкам Немерле может появиться что-то популярное. Поэтому, для истории, может и ваша строгость окажется чем-то полезной

VD>Вот в Шарпе появилось ключевое слово override. Оно тоже "удлиняло" синтаксис. Кое кто по началу ворчал от этого. Но так как от этого на практике были только плюсы (люди перестали ошибаться в переопределении методов), то все быстро к этому привыкли.

"Кое-кто" — это не большая часть программистов.

VD>Думаю, что так как фарш уже невозможно провернуть назад (первая версия выпущена), то нужно просто постараться донести до программистов причины такого выбора. Разумные все пойму. Кто-то особо вредный может сделать для себя макрос. А совсем неадекватные пусть подрастают морально. Им пока этот язык не нужен. У нас, в конце концов, нет задача переманить на свою сторону всех манки-индо-девелоперов.

Ну вот авторы дотпика тоже думали что пять-то страниц документации никому не будет западло почитать Если вам кажется. что вы сумеете написать это так, что каждый прочитавший скажет "Ага!" и больше не будт испытывать с этим трудностей, то чот же всё ещё не написали? Проблема не том, сколько буков набирать — в том, что из-за того, что многие просто не привыкли, не имеют навыков писать неизменяемые типы, им придётся мачаться пока это прозрение на них не снизойдёт. И тут сколько не говори "сахар", слаще не будет. Поставлю вопрос по-другому — хотите ли вы, что бы языком стали пользоваться

_FR>>Мне кажется, что практика показывает, что в том виде, в котором Немерле есть, он очень мало кому нужен. Это неоспоримый факт. И стимуляция "визуальными отличиями" как бы ни к чему не приводит (ибо ещё не привела). Не нужно фантазировать, нужно отталкиваться от реалий. Или не ныть по поводу фобий у большого количества программистов.
VD>Откровенно говоря люди которые отказываются от языка из-за разницы в одном идентификаторе — это очень ограниченные люди и биться за них глупо. Лично я уверен, что mutable не является основной причиной неприятия.

Откровенно говоря, использовать работу людей, не способных к простейшему анализу, очень стрёмно: при чём тут "один идентификатор"? Дело не в нём, а в подходе, который пропагандируется в Немерле — "всё в чему вы привыкли идёт в лес, а мы лучше всех остальных знаем, как вам нужно писать, и вы, ёпрст, будете писать так, как вам нужно".

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

Дело ваше. остаётся только удачи пожелать. Только вот что смущает: почитайте, сколько за последние года вы лично на этом форуме в том или ином виде интересовались у общественности — "Что вам мешает перейти на Немерле?". Сейчас вот очередной раз. Люди старались, генерили много текста, сервер рсдн мужественно его хранит по сей день. Можно ли получить отчёт, что было предпринято по прошлым обращениям? Что было изменено в языке по итогам прежних "возопиёв"? Сколько новых Немерлистов встало в строй после этих изменений?

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

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

Прежде чем делать, задумались бы, как потом дальше жить с этим наследием и кому "супер-сет шарпа" в таком виде будет нужен?

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

_FR>Если вы считаете, что "var" сделает язык "грязным" — то кто же впадает в крайности? В таких рамках посоветовать что либо я, например, не в силах, может кто другой справится и само обойдётся.

VD>>Но вот использование val вместо def — это плохая идея. Все же между изменяемыми и неизменяемыми переменными должна быть явная синтаксическая разница.

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

Разница для языка позиционируемого как функциональный по моему существенная. Изменяемые переменные должны легко выделятся. Еще желательно поручить контроль этого компилятору как например атрибут pure в D, но такое не всегда и не везде возможно.

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

_FR>>Если вы считаете, что "var" сделает язык "грязным" — то кто же впадает в крайности? В таких рамках посоветовать что либо я, например, не в силах, может кто другой справится и само обойдётся.
VD>>>Но вот использование val вместо def — это плохая идея. Все же между изменяемыми и неизменяемыми переменными должна быть явная синтаксическая разница.
_FR>>Да без разницы на эти финтифлюшки тем, кто знает, о чём речь и у кого "глаз не замылился". Попробуйте пописать на Скале — если это будет идинственным "мешающим" фактором я например очень сильно удивлюсь. Это окажется вообще ничем незамеченной особенностью да и только.

FR>Разница для языка позиционируемого как функциональный по моему существенная. Изменяемые переменные должны легко выделятся. Еще желательно поручить контроль этого компилятору как например атрибут pure в D, но такое не всегда и не везде возможно.

В этом топике, мне казалось, язык обсуждается в разрезе завоёвывания им, языком, популярности. Так же напомню, что Скала, в которой используется val/var может считаться значительно более популярным языком нежели Немерле. Имеет ли кто-нибудь информацию о том, что в комьюнити Скалы по этому поводу есть дискуссии?

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

_FR>В этом топике, мне казалось, язык обсуждается в разрезе завоёвывания им, языком, популярности. Так же напомню, что Скала, в которой используется val/var может считаться значительно более популярным языком нежели Немерле. Имеет ли кто-нибудь информацию о том, что в комьюнити Скалы по этому поводу есть дискуссии?

Про Скалу не в курсе, но в не менее по моему уже популярном чем скала F# используется именно mutable (или ref как наследство OCaml) и присваивание таких переменных идет отдельным оператором (<-). Хотя по сравнению с OCaml есть послабления мутабельные переменные можно непосредственно использовать в выражениях, в OCaml же они ссылки которые необходимо разыменовывать.
Так что mutable для этого класса (строгие функционально гибридные) языков по моему — норма.

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

VD>В последнее время частенько стали возникать вопросы связанные с тем что (и почему) останавливает людей от перехода на новый язык (в нашем случае — Nemerle).

Не помешала бы еще дока в формате xmldoc => ndoc => .chm

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

DR>Т.е. надо делать язык для индусов не сумевших осилить C#. Зачем?

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

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

A>В первом случае поведение c# правильное, во втором случае c# штрафует не за то что он должен был бы штрафовать.
A>N предлагает наоборот — штрафовать за использование изменяемых переменных. Вот и все

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

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

A>Не помешала бы еще дока в формате xmldoc => ndoc => .chm

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

Ранее генерация с chm-а делалась, но видимо вручную.

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

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

A>>Не помешала бы еще дока в формате xmldoc => ndoc => .chm

VD>Ну, вот занялся бы. Народ тебе огромное спасибо сказал бы!

VD>Ранее генерация с chm-а делалась, но видимо вручную.

Как ни странно, но доку получилось сделать только для Nemerle.Macros.chm.zip
Теперь было бы не плохо если бы Nemerle Team начал писать xmldoc-коментарии

З.Ы. Это так задумано, что для Nemerle.Peg.Macros.dll нет xmldoc-файла в инсталяхе?

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

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

A>>Не помешала бы еще дока в формате xmldoc => ndoc => .chm

VD>Ну, вот занялся бы. Народ тебе огромное спасибо сказал бы!

VD>Ранее генерация с chm-а делалась, но видимо вручную.

Было бы неплохо если бы интеграция генерировала xmldoc болванки, как это делает c#

A>Как ни странно, но доку получилось сделать только для Nemerle.Macros.chm.zip
A>Теперь было бы не плохо если бы Nemerle Team начал писать xmldoc-коментарии

Ndoc ругается

Метод может быть вызван только для метода, для которого значение Type.IsGenericParameter является true.

Exception: NDoc.Core.DocumenterException
Метод может быть вызван только для метода, для которого значение Type.IsGenericParameter является true.

Exception: System.InvalidOperationException
Метод может быть вызван только для метода, для которого значение Type.IsGenericParameter является true.

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

A>Было бы неплохо если бы интеграция генерировала xmldoc болванки, как это делает c#

Интеграция этим не занимается, это делает мсбилд. Надо в файле проекта указать:

<DocumentationFile>$(OutputPath)\ProjectOutputName.xml</DocumentationFile>

Я как раз сейчас ковыряю сандкастл на этот счет. От NDoc отказался, он не поддерживается давно Есть ndoc3, но с 4м фреймворком с него тоже придется слезть. Сандкастл генерирует и вроде имеет нужные точки для расширения, но производит на меня впечатление какого-то кошмарного тула Собирает он ужасно долго, но зато имеет кучу выходных форматов и поддерживается майкрософтом. Засунуть его в репозитарий, как ndoc нельзя, весит 300+ Мб.

К нему нужен немерловый генератор кода (по аналогии с C#/VB/C++/F#). Нужен какой-то трансформатор для вариантов, хотя можно и так конечно.

Вдобавок нужно подхачить компилятор, чтобы он не генерировал в xml методы типа _N_GetVariantCode (впрочем есть вероятность подчистить их самим сендкастлом через XPath, я в нем не силен) и внедрял синтаксис синтаксических макров в коменты.

Также надо привести к образцу

<'a> и <T>

и задокументировать недокументированное.

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

Есть еще один интересный вариант, sandcastle умеет генерить хелп по своему маркапу (MAML). Если научиться делать нужный маркап, то все доки можно перевести в него и будет реально цельная документация, как с кодом, так и со статьями, тынц. Доку можно как выложить на сайт (умеет генерить html с нужными шаблонами, etc) так и в инсталятор (chm).

Если что вот собраный хелп Documentation.zip. Но это малополезная штука, имхо.

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

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

A>>Было бы неплохо если бы интеграция генерировала xmldoc болванки, как это делает c#

Z>Интеграция этим не занимается, это делает мсбилд. Надо в файле проекта указать:
Z>

Z><DocumentationFile>$(OutputPath)\ProjectOutputName.xml</DocumentationFile>
Z>

Я имел ввиду набираешь три слэша /// и тебе автоматом заготовка в cs файле.

        /// <summary>
        /// 
        /// </summary>
        /// <param name="outBuff"></param>
        /// <param name="wanted"></param>
        /// <returns></returns>
        public int GetSamples(short[] outBuff, int wanted)

Без этого никто xmldoc комментарии писать не будет. Что и подтверждают исходники N

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

Z>Если что вот собраный хелп Documentation.zip. Но это малополезная штука, имхо.

Спасибо
Это для Nemerle.dll, Nemerle.Compiler.dll и Nemerle.Macros.dll. Я правильно понял?

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

A>Я имел ввиду набираешь три слэша /// и тебе автоматом заготовка в cs файле.

A>Без этого никто xmldoc комментарии писать не будет. Что и подтверждают исходники N

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

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

Z>>Если что вот собраный хелп Documentation.zip. Но это малополезная штука, имхо.

A>Спасибо
A>Это для Nemerle.dll, Nemerle.Compiler.dll и Nemerle.Macros.dll. Я правильно понял?

Да. Билдятся они полчаса При отключенной привязке к MSDN, со включенной я так и не смог собрать, падает регулярно в разных местах.

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

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

A>>Я имел ввиду набираешь три слэша /// и тебе автоматом заготовка в cs файле.

A>>Без этого никто xmldoc комментарии писать не будет. Что и подтверждают исходники N

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

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

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

H>Да вы сами его провоцируете, высказываясь об умственных способностях непожелавших прикоснуться к вашему божественному языку

если человек не "прикоснулся к их божественному языку", то как он может о нем судить?
поэтому некоторые, у которых уже не осталось сил таким отвечать, от усталости агрессивничают

а вообще мы же с вами приличные люди, и вести должны себя соответственно.

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

FR>Про Скалу не в курсе, но в не менее по моему уже популярном чем скала F# используется именно mutable (или ref как наследство OCaml) и присваивание таких переменных идет отдельным оператором (<-). Хотя по сравнению с OCaml есть послабления мутабельные переменные можно непосредственно использовать в выражениях, в OCaml же они ссылки которые необходимо разыменовывать.
FR>Так что mutable для этого класса (строгие функционально гибридные) языков по моему — норма.

Кстати, было бы хорошо в Немерле для присваивания изменяемой переменной использовать как и в F# стрелочку -- стилистически архиприятная вещь, которая показывает разницу между присвоением нового значения (x <- new_value) и связывание неизменяемого символа с выражением (let x = expression)