Сообщение об ошибочке и вопрос. - Nemerle

1. Ошибка.
Макра:

public macro Dot(inexpr) 
  syntax ("Dot", inexpr)
  {
      //Message.Hint("taddaam"+inexpr);
      match (inexpr)
      {
        | <[ $aVec with  $bVec ]> =>
        {
            Message.Hint("taddaam"+inexpr);
                     //    Vector3(
                     //(a.Y * b.Z) - (a.Z * b.Y),
                     //(a.Z * b.X) - (a.X * b.Z),
                     //(a.X * b.Y) - (a.Y * b.X));
        <[$aVec.X * $bVec.X + $aVec.Y * $bVec.Y + $aVec.Z * $bVec.Z]> ;
        }
      };
      <[()]>
  }

Понятно, что поломка в строке Message.Hint("taddaam"+inexpr);
Но при билде вместо простой ошибки вышибает окошко дебагера со следующим:

---------------------------
Ошибка утверждения: Прервать=Выход, Повторить=Отладка, Пропустить=Продолжить
---------------------------
Assertion: res
At: ncc\typing\TyVar.n failed.

failed to fixate Nemerle.Compiler.Parsetree.PExpr [] with Nemerle.Compiler.Parsetree.PExpr

at TypeVar._N__FT_Fixate_2541()

at TypeVar.Fix()

at TopLevelPattern.Build(list`1 pats)

at DecisionTreeBuilder.Build(list`1 patterns)

at DecisionTreeBuilder..ctor(list`1 cases)

at Typer.TypeMatch(Match mtch, TypeVar expected)

at Typer.DoType(PExpr expression, TypeVar expected, Boolean is_toplevel_in_seq)

at Typer.TypeExpr(PExpr expr, TypeVar expected, Boolean is_toplevel_in_seq)

at Typer.DoType(PExpr expression, TypeVar expected, Boolean is_toplevel_in_seq)

at Typer.TypeExpr(PExpr expr, TypeVar expected, Boolean is_toplevel_in_seq)

at Typer.TypeMatch(Match mtch, TypeVar expected)

at Typer.DoType(PExpr expression, TypeVar expected, Boolean is_toplevel_in_seq)

at Typer.TypeExpr(PExpr expr, TypeVar expected, Boolean is_toplevel_in_seq)

at Typer.TypeExpr(PExpr e, TypeVar expected......

<truncated>
---------------------------
Прервать Повтор Пропустить
---------------------------

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

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

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

R>Понятно, что поломка в строке Message.Hint("taddaam"+inexpr);
R>Но при билде вместо простой ошибки вышибает окошко дебагера со следующим:...

Кто-то в свое время вставил там ICE (внутренняя ошибка компилятора). Я поставилм там assert чтобы было ясно кода такая ситуация возникает. Похоже, что это вполне штатная ситуация, так что убрал оттуда все проверки.

R>Вопрос же в следующем, просто информированности ради, хотелось бы знать насколько юзабелен сейчас билд под Silverlight, если кто-то делал это.

С сервилатом главная проблема (как я понимаю) заключается в том, что он использует свой рантайм. А через SRE (System.Reflection.Emit), которым мы пользуемся, компилировать сборки можно только для текущего рантайма. И соответственно подключать другие сборки можно только если они совместимы с текущим рантаймом.

Так что пока мы не перешли на другую библиотеку генерации IL-а единственным способом запуска под другими рантаймами будет использование конфигов с явным указанием рантайма который нужно использовать. В случае сервилата можно компилировать приложения для работы WPF, а затем пробовать запустить его под сервилатом с помощью конфига.

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

R>Но при билде вместо простой ошибки вышибает окошко дебагера со следующим:...

Убрал этот assert к чертям.

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

VD>Здравствуйте, Rival, Вы писали:
R>>Но при билде вместо простой ошибки вышибает окошко дебагера со следующим:...
VD>Убрал этот assert к чертям.

Отлично. По поводу Сервелата — понятно. Спасибо за пояснение. Буду следить.

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

При всей замечательности твоих статей, Влад. И объяснении принципов работы компилятора на примере макросов. Порой не хватает простых примеров. Ну вот как обычная простая макра скалярного произведения, что в первом посте. Мне думается, что для большинства хомячков(ням-ням) было бы намного понятнее, для начала, примеры совсем простых макросов. Они бы делали простые вещи и генерировали несложный код. В нынешней ситуации есть пока огромный разрыв между Message.Hint и генерацией конструкции foreach.

Не хватает простой средней "питательной" прослойки, как то:
a). Как создать пользовательский тип(есть в первой статье, но хотелось бы большего внимания)
б). Как создать поле.
в). А вот в аргументах макроса можно использовать только в строенные типы, а как быть, когда нужно передать/вернуть пользовательский тип. Общие практики.
г). Общий How To.
д). Какой наилучший способ проверки и отладки макросов.

Как вариант, хорошо бы, чтобы имелось комментирование оригинальных макросов в исходниках или введение некого правила, что новые макры будут добавляться только с комментариями. Желательно к каждой строчке, чтобы как для Dummies. Таким образом исходники будут более полезной галереей-примером.

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

Вообщем, хорошо бы уделить просветительское внимание на вещи простой/средней сложности. Которые, может быть, в полной мере и не используют всю мощь макросистемы, но зато позволяют уменьшить порог вхождения для новичков и избавить или сильно уменьшить необходимость просмотра оригинальных макросов Nemerle и изучения их всырую. Лозунг "DSL в каждый дом" актуален не для каждого, хотя бы поначалу.

Вот, ещё добавлю. Или вот такие примеры, как в случае простым макросом в первом посте:

public macro Dot(inexpr) 
  syntax ("Dot", inexpr)
  {
      match (inexpr)
      {
        | <[ $aVec with $bVec ]> =>
         <[$aVec.X * $bVec.X + $aVec.Y * $bVec.Y + $aVec.Z * $bVec.Z]> ;
        | e => Message.FatalError($<#the syntax is ' "Dot" vectorA "with" vectorB ', got $e#>);
      };
      <[()]>
  }

Почему, например, и как работает конструкция <[ $aVec with $bVec ]>. Отчего если заменить слово "with" на "and" компилятор ругается на неверный токен. А если на "in" то нет. Вот в статье номер два http://www.rsdn.ru/article/nemerle/MacrosExtCoursePart2.xml#EZF в match используется такая конструкция, но о нюансах подстановки приходится догадываться.

И побочный вопросик. Планируется ли добавление для макросов XML документации в дотнетовском стиле?

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

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

P.P.S. Поставил Nemerle в Google Alerts иногда прикольные ссылки вываливаются.

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

R>Не хватает простой средней "питательной" прослойки, как то:
R>a). Как создать пользовательский тип(есть в первой статье,

В смысле, как из макроса добавить тип в компилируемый проект?

R>но хотелось бы большего внимания)

А что конкретно интересует?

R>б). Как создать поле.
R>в). А вот в аргументах макроса можно использовать только в строенные типы, а как быть, когда нужно передать/вернуть пользовательский тип. Общие практики.

Опять же очень абстрактный вопрос. Что понимается под "передать/вернуть" да и под "пользовательский"?

R>г). Общий How To.

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

Тут проще было бы если новичок (нашедший ответ на свой вопрос самостоятельно) задавал бы этот вопрос на форуме. Тогда интересные ответы можно было бы помещать в FAQ.

R>д). Какой наилучший способ проверки и отладки макросов.

ОК, про это можно написать. Хотя там все не хитро.

R>Как вариант, хорошо бы, чтобы имелось комментирование оригинальных макросов в исходниках или введение некого правила, что новые макры будут добавляться только с комментариями. Желательно к каждой строчке, чтобы как для Dummies. Таким образом исходники будут более полезной галереей-примером.

Комментарии в коде ведь будут на английском. Это ничего? Потом лично мне трудно писать на английском (медленно). Надо с кем-то договориться, чтобы переводил русские коменты, а я будут тогда писать по-русски.

R>При это, желательно, описать виды макросов и свести это в общую форму.

Это есть в расширенном курсе.

R>Вот, ещё добавлю. Или вот такие примеры, как в случае простым макросом в первом посте:
R>

R>public macro Dot(inexpr) 
R>  syntax ("Dot", inexpr)
R>  {
R>      match (inexpr)
R>      {
R>        | <[ $aVec with $bVec ]> =>
R>         <[$aVec.X * $bVec.X + $aVec.Y * $bVec.Y + $aVec.Z * $bVec.Z]> ;
R>        | e => Message.FatalError($<#the syntax is ' "Dot" vectorA "with" vectorB ', got $e#>);
R>      };
R>      <[()]>
R>  }
R>

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

R>Почему, например, и как работает конструкция <[ $aVec with $bVec ]>. Отчего если заменить слово "with" на "and" компилятор ругается на неверный токен. А если на "in" то нет. Вот в статье номер два http://www.rsdn.ru/article/nemerle/MacrosExtCoursePart2.xml#EZF в match используется такая конструкция, но о нюансах подстановки приходится догадываться.

Дык это вопрос скорее для форума. Ответ в общем-то очень прост. "with" и "in" уже являются ключевыми словами, а "and". Нужно или описать соответствующий оператор, или упомянуть этот "and" в описании синтаксического расширения. Для этого можно ввести фэйк-макрос. Если использовать ключевое слово в операторной форме, то имеет смысл дать ему описание приоритетов с помощью атрибута Nemerle.Internal.OperatorAttribute (как это сделано в . 
 
R>И побочный вопросик. Планируется ли добавление для макросов XML документации в дотнетовском стиле? 
 
А что означает дотнетовский стиль? В приципе макрос XML так прост, что его [url=http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.Xml/Test/Main.n]тест полностью демонстрирует его возможности.

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

Ещё раз напоминаю, что это информация лишь к сведению и является юзер фидбаком, а не критикой.

У меня иногда складывается впечатление, что меня боятся. На самом деле я добрый и пушистый, если конечно не пытаться намеренно хамить и пытаться унизить. Так что не надо бояться говорить даже жесткой критики. Только нужно стараться чтобы она была логически обоснованной (не хочу использовать заезженный штамп — "конструктивной"), чтобы от нее был толк.

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

Могу сказать только одно. Я видел уже не мало примеров когда люди сами въезжали, если не в тонкости, то в основные вопросы связные с языком и макросистемой. Как мне показалось с освоением языка (при наличии опыта программирвоания на Шарпе или Яуве) обычно проблем нет. С макросами чуть сложнее, но тоже ничего (оно так и должно быть, ведь макросы штука не простая сама по себе). Возможно это были люди несколько выше среднего. WolfHound, hardcase, Ziaw и многие другие вообще практически не задавали никаких вопросов. Ну разв что особо хитрые которые связаны с тонкостями устройства компиляторов. Ziaw без единого совета сделал целый фрэймворк (ох не люблю это слово), hardcase во всю правит баги в компиляторе и реализовал парсер C#-а, а WolfHound сделал тот самый макрос-генератор парсеров — PegGrammar. При этом мы с ним намного больше обсуждали вопросы проектирования алгоритмов макросов, нежели их использование. Другие тоже не исключения. Так что во многом все определяется желанием.

R>P.P.S. Поставил Nemerle в Google Alerts иногда прикольные ссылки вываливаются.

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

.

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

VD>В смысле, как из макроса добавить тип в компилируемый проект?

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

VD>А что конкретно интересует?

Хм... попробую придумать. Скажем, создание пользовательского типа Foo (добавление в сборку через макросы), макра один. Далее макра два которая вызывает метод/ы этого пользовательского типа.
Как видно такой пример довольно абстрактен, если смысл примера forindex или foreach понятен, то с Foo это скорее не объяснение почему и зачем нужны макросы, а объяснение "при повороте башни следи за углом ствола". Тот кто "прост и прямолинеен" не будет задаваться вопросом и будет следовать правилам, а тот кто любознателен и умён потом поймёт.

R>>б). Как создать поле.
R>>в). А вот в аргументах макроса можно использовать только в строенные типы, а как быть, когда нужно передать/вернуть пользовательский тип. Общие практики.

Под пользовательским типом, я имел в виду тот, который присутствует в сборке из которой вызывается макрос.
Под "передать/вернуть" мне понималось примеры макросов а-ля C++, которые просто раскрываются при компиляции и служат своеобразной заменой коротких методов.

R>>г). Общий How To.

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

Да, да. Именно об этом и речь. Я прекрасно вас понимаю. Мой пост как раз о том, что евангелизм это всегда объяснение зулусам с костью в носу, почему надо молится на белого человека на перекресте, на их языке и доступными методами. Еванелизм — быть понятным, а не ожидать чтобы тебя поняли. Заметь, как часто было слышно по поводу Немерле, что это очередная свистоперделковая блажь. "Такое уже было, оно никому не надо". При этом в массе своей такие люди даже не разбирались, они просто прошли по верхам, оценили всё с высокой башни, зевая посмотрели "исторический контекст" и за нежеланием дальнейших разбирательств составили мнение. Многие люди не тратят усилий. Ой, точнее, большинство.

Сделать меньше — получить больше. Мы же организмы, все организмы делают так. Делаем по-другому лишь тогда когда наблюдаем чей-то пример, видим результат и оцениваем успех. Обезьянка видит — обезьянка делает. Аппелировать к разуму бесполезно, а вот подача примера и понятность самое действенное средство. Поэтому, речь о том, что лучше чтобы примеры были разными. Да, цикл статей это правильный и верный подход, но стиль подхода может и должен быть разным. Более примитивный способ объяснения тоже полезен из-за того, что нужно потратить намного меньше усилий, для понимания. Одно дело почитать статью, другое дело беглым взглядом оценить примеры макросов. Ведь именно поэтому "Hello, world" самое частое и первое что показывают людям при изучении нового языка. Речь о галерябельности и показательности информации в стиле "нажал красную кнопку — получил банан". В этом нет ничего постыдного. Просто другой метод объяснения.

VD>Тут проще было бы если новичок (нашедший ответ на свой вопрос самостоятельно) задавал бы этот вопрос на форуме. Тогда интересные ответы можно было бы помещать в FAQ.

Вот-вот, осторожнее с интересным вопросом/ответом. Интересный вопрос для тебя и для новичка это слишком разные вопросы. Конечно Немерле пока не хватает базза и гудения но форумах, но с другой стороны, это пока избавляет от связанных с этим проблем.

VD>Комментарии в коде ведь будут на английском. Это ничего? Потом лично мне трудно писать на английском (медленно). Надо с кем-то договориться, чтобы переводил русские коменты, а я будут тогда писать по-русски.

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

Вот тут подумалось. Между прочим, стилистика вашего евангелизма крайне православна. "Человек сам должен придти к Nemerle", а не "Уверуй в святого Nemerle ибо путь истинный и единый он есть!" Да! Чуете?

Понятно, что не все обязаны знать английский, но для локализированной русской версии, в конце концов, можно создать отдельную страничку, ну или ветку. Вопрос не в методе, а в цели. Цель — галерея примеров. Смысл в том, чтобы наблюдать как и читать почему.

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

Да, понимаю. Это лишь пример. И вот от этого, хорошо бы создать набор примеров. Ну выше сказано об этом и явно моя мысль ясна.

R>>Почему, например, и как работает конструкция <[ $aVec with $bVec ]>. Отчего если заменить слово "with" на "and" компилятор ругается на неверный токен. А если на "in" то нет. Вот в статье номер два http://www.rsdn.ru/article/nemerle/MacrosExtCoursePart2.xml#EZF в match используется такая конструкция, но о нюансах подстановки приходится догадываться.

VD>Дык это вопрос скорее для форума. Ответ в общем-то очень прост. "with" и "in" уже являются ключевыми словами, а "and". Нужно или описать соответствующий оператор, или упомянуть этот "and" в описании синтаксического расширения. Для этого можно ввести фэйк-макрос. Если использовать ключевое слово в операторной форме, то имеет смысл дать ему описание приоритетов с помощью атрибута Nemerle.Internal.OperatorAttribute.

Ммм, интересно. Спасибо. Ну вот! Пожалуйста! Это как яркий образец того, что примеры с комментариями были бы полезны. Этот макрос может и полезен только для меня, но при его простоте позволяет объяснить интересные детали. Я ведь тоже как-то не часто "Hello, world!" на экран вывожу.

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

R>>И побочный вопросик. Планируется ли добавление для макросов XML документации в дотнетовском стиле?

VD>А что означает дотнетовский стиль? В приципе макрос XML так прост, что его тест полностью демонстрирует его возможности.

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

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

"Люди разные" и жёсткой критики у меня нет. Наоборот, вас хвалить надо по большинству критериев. Правда, чрезмерное количество похвальбы опасно, подставит подножку, а путь у вас долгий. И вообще, хотелось бы чтобы вы воспринимали это не как проект: "Мы это сделаем и станем ваще такими крутыми-крутыми", а как путь раскрытия собственной пассионарности, расширения знаний, ну и принесения заметной пользы. Как пролонгированный, сложный и приятный процесс. Кто-то решает кроссворды, кто-то пишет Теорию всего, а кому-то интересно делать отличный язык. Кстати, это к разговору о недавних смешках неких мусье на форуме, которым успех нужен сейчас, или через 5 лет, или через 10. И чтобы точно! Наверное, чтобы вот "добиться успеха" и сесть в кожаное кресло перед камином. И... И всё! И все сразу начнут любить и уважать тогда. Приглашать на чай с тортиком и почтительно закатывать глаза узнав о трудностях разработки Nemerle. Сам я крайне невысокого мнения о людях, которые орут о ненужности Nemerle, объясняя это сугубо локальными причинами. Думаю не стоит упоминать о возрасте и мировозрении подобных критиков, правда мне немного обидно, что это может сбить ваш благой порыв. Но ведь интернет такой, здесь овном назовут любого и не спросят.

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

Другие люди, другие цели. На примере с множественным наследованием интерфейсов генериков, ты хоть до конца и не понимал зачем это надо, но пошёл это делать. Я как-то не очень представляю себе злого человека, который идёт и делает то, что ему непонятно. Разве же это не доброта? Это явно показывает, что язык ты делаешь не только под себя и это не путь самоутверждения.

VD>Могу сказать только одно. Я видел уже не мало примеров когда люди сами въезжали, если не в тонкости, то в основные вопросы связные с языком и макросистемой. Как мне показалось с освоением языка (при наличии опыта программирвоания на Шарпе или Яуве) обычно проблем нет. С макросами чуть сложнее, но тоже ничего (оно так и должно быть, ведь макросы штука не простая сама по себе). Возможно это были люди несколько выше среднего. WolfHound, hardcase, Ziaw и многие другие вообще практически не задавали никаких вопросов. Ну разв что особо хитрые которые связаны с тонкостями устройства компиляторов. Ziaw без единого совета сделал целый фрэймворк (ох не люблю это слово), hardcase во всю правит баги в компиляторе и реализовал парсер C#-а, а WolfHound сделал тот самый макрос-генератор парсеров — PegGrammar. При этом мы с ним намного больше обсуждали вопросы проектирования алгоритмов макросов, нежели их использование. Другие тоже не исключения. Так что во многом все определяется желанием.

Безусловно. Но мы ведь говорим сейчас о понятности и доступности информации для большинства, а WolfHound, hardcase, Ziaw, при всём желании, никак нельзя отнести к среднему уровню. Конечно, главное желание, но это заметное упрощение ситуации. При всех прочих у этих людей было "понимание" уже заранее. Вот, скажем, 95% — это обезьянки, они берут палку только тогда, когда видят, что с помощью неё можно сбить банан. Банан — это вкусно, банан — это понятно. Я ем банан, от этого мне хорошо(упустим почему). Хочу банан, ой, я видел как, надо взять палку. Ей сбить. Палку же берут те, кто первым "понимает"(упустим почему). Так вот. Внимание, тут очень важная мысль. Не всегда те, кто не берёт палку первыми являются глупыми или менее конкуретными особями. Возможно, они заняты или отвлечены чем-то другим. В нашем случае, обычно люди говорят так: "ах, если бы было время" или "вот, если бы начальство позволило использовать в продакшене" или "ну если бы были доки, а так как-то". Видно, что особи прямо говорят, что есть некоторые факторы, которые для них являются определяющими. Ведь, помимо всего прочего, нас окружает масса событий и других вещей. Факторы у всех разные, реальность у всех чуть отличается. У многих особей есть свои собственные "пальмы с бананами" другого вида в другой области. Поэтому, неверно приводить им в пример и тыкать пальцем в пассионарных персон, объясняя что остальным 95% стоит прикладывать подобные же усилия как WolfHound, hardcase или Ziaw. Точнее тут как. Если тебе безразлично будут или нет использовать твой язык, тогда безусловно. Политика "Сами придут и сами всё к ногам бросят"("Мастер и Маргарита") имеет право на существование. Однако, по твоим статьям, да и по желанию объяснить людям преимущества макросистемы и вывода типов, я вижу, что тебе и вам хотелось бы, чтобы больше людей присоединялось к вашему делу. Вот, когда мы говорим о "больше людей", думаю, что кое кто может напугаться от опасности возникновения толп тупых чайников и предложит ждать элит. Ну тех у кого есть это особое "главное желание". У вас, в вашем случае, такой подход понятен и опеределён скорее не отсутствием желания, а отсутствием времени. Однако не забывайте, что даже в сотне дураков, может найтись тот, кто сделает довольно полезный вклад в развитие языка. Ведь правило 95% работает в обе стороны.) Поэтому, подходы к подаче могут быть разными и при всей позитивности статей не стоит недооценивать другие методы. Кстати, визуальный демонстратор это чудесно. Хорошо, пожалуй, закончу на этом мысль. Думаю, что мне удалось её донести.

От:	Rival	https://twitter.com/#!/red_rival
Дата:	07.12.10 17:37
Оценка:

От:	VladD2	www.nemerle.org
Дата:	07.12.10 18:34
Оценка:	15 (1)

От:	VladD2	www.nemerle.org
Дата:	07.12.10 18:38
Оценка:

От:	Rival	https://twitter.com/#!/red_rival
Дата:	08.12.10 02:39
Оценка:	46 (1)

От:	VladD2	www.nemerle.org
Дата:	08.12.10 15:15
Оценка: