Здравствуйте, Evgeny.Panasyuk, Вы писали:
VD>>Шаблоны можно навернуть как расширение к языкам базирующимся дотнетной системе типов
EP>А статическую типизацию можно добавить к динамически типизированному языку. А уж если смотреть с точки зрения полноты по Тьюрингу — то и море по колено
Зачем говорить ерунду? С прекручиванием шаблонов к донтентной системе типов никаких теоретических проблем нет. Они даже самому дотнету будут по фиг (опять же напоминаю, что дотнетная система типов и сам дотнет — это разные вещи). Они во время компиляции раскрываются.
EP>Насколько я вижу: со стороны системы типов нет гарантии что варианты состоящие из одинакового списка типов будут иметь один и тот же тип, нет гарантии закрытости.
В Нитре систему типов делаешь/изменяешь ты сам. Что сделаешь, то и будет. Конечно, если сгенерировать дотнетную сборку и заюзать типы из не нитровского языка, то они будут видны как обычные классы. Но в нитровском языке ты будешь иметь дело с тем типом, что опишешь. Так что если тебе нужно сделать чтобы иерархию нельзя было расширить — не проблема, сделай.
Кроме того варианты с возможностью расширения так же востребованы на практике. Например, мы в Нитре были вынуждены делать открытые иерархии, так как Нитра подразумевает расширяемость в любом месте.
EP>Какое-то есть, да, поэтому я и написал "практически".
Ну, да. В русском языке "практически — да" означает "теоретически, но на практике нет" или "не совсем возможна".
EP>Этот паттерн рождён из необходимости scope-based управления ресурсами при летающих исключениях. Что характерно, присутствует во всех mainstream языках, пусть и в обрезанной форме.
Мы говорим о С++-ном термине? Если — да, то в С++ речь идет о наличии конструкторов и деструкторов у объектов вызываемых при выходе из области видимости. И в С++ это дело используется для автоматизации управления памятью. Результат — море багов связанное с этим дело и ряд проблем иделогического порядка (например, проблемы с исключениями в деструкторах/конструкторах).
Ладно. Это вопрос филосовфский. К делу не относится. С++-ый вариант сделать намного проще. Но если бы я был пользователем языка, я бы пожелал наличие хоть какой-то автоматизации управления память. Хотя бы автоматический подсчет ссылок.
EP>О том и речь, и макросами в ней можно закрыть далеко не все дыры, по-крайней мере малой кровью.
Ну, то что в С++ делается с помощью метапрограммирования на шаблонах почти на 100 можно заменить макрами. В 90% случаев они удобнее, быстрее и понятнее будут.
Что касается свойств шаблонов, то да. Такие их свойства как:
1. Раскрытие во время компиляции.
2. Переменное число аргументов.
3. Утиная типизации (вытекает из п. 1).
Делаю их более мощными, хотя и порождают некоторые недостатки.
Вообще, то что шаблоны раскрываются во время компиляции роднит их с макросами. По сути и то, и то является средствами метапрограммирования времени компиляции. Но шаблоны идут от системы типов, а макросы от языка.
EP>При прочих сферических равных, чем более всё автоматизированно, тем естественно лучше — само по себе ручное управление достоинством не является. Вот только нет этих сферических равных.
+1
EP>И речь же не про ручное/автоматическое, а конкретно про GC vs scoped-based. Да и "ручным" управлением называть scope-based неверно.
Верно. Ручное оно не от того, что "scope-based", а от того, что нужно проделывать ряд приседаний для его работы и при этом можно легко ошибиться.
Но проблема подхода принятого в С++ не только в том, что оно там ручное. Проблема еще и в том, что есть куча возможностей языка позволяющих легко нарушить инварианты этих, реализованных в ручную, правил управления памятью. Например, можно выделить память в стеке и передать ее куда-то где указатель на нее положат в поле другого объекта. И это никак не проконтролируешь. Вот в Расте попытались эту проблему решить, но при этом сам язык превратили в далекий от менэстрима.
EP>Да, есть выбор из ряда вариантов, в том числе даже и GC. Но если наличие выбора называть ручным управлением, тогда и в .NET оно ручное — так как например имеется выбор между struct/class.
Выбор между struct/class — это выбор стратегии. Сама стратегия реализуется автоматически. Естественно — это и ограничение. Манипулировать памятью становит я сложнее, что снижает потенциал оптимизаций.
ЗЫ
Мы ушли не в ту степь. Мы начали дискутировать о принципах управления памятью и о системах типов.
Данная тема вообще посвящена конкретным языкам. В них эти вопросы определены.
Если ты хочешь создать другой язык, то Нитра позволяет это сделать относительно быстро, просто и получить автоматом поддержку IDE.
Если хочешь обсудить этот другой язык, то лучше создай отдельную тему. Можно даже не тут, а в Философии программирования. Там к нему присоединиться много народа. Мне есть что высказать по этому вопросу, но эта тема немного о другом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>ЗЫ VD>Мы ушли не в ту степь. Мы начали дискутировать о принципах управления памятью и о системах типов. VD>Данная тема вообще посвящена конкретным языкам. В них эти вопросы определены. VD>Если ты хочешь создать другой язык, то Нитра позволяет это сделать относительно быстро, просто и получить автоматом поддержку IDE.
Не только IDE, но и как я понял можно автоматом получить лёгкую расширяемость и макросы.
VD>Если хочешь обсудить этот другой язык, то лучше создай отдельную тему. Можно даже не тут, а в Философии программирования. Там к нему присоединиться много народа. Мне есть что высказать по этому вопросу, но эта тема немного о другом.
Я же не просто про какой-то левый язык на базе Nitra спросил, а конкретно про возможность разделения части кодовой базы этого языка с Nemerle 2.0. Думаю возможность такого разделения-переиспользования должна быть как-то заранее учтена при разработке Nemerle 2.0 — и этот момент полностью относится к этой данной теме, IMO.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не только IDE, но и как я понял можно автоматом получить лёгкую расширяемость и макросы.
Само собой.
EP>Я же не просто про какой-то левый язык на базе Nitra спросил, а конкретно про возможность разделения части кодовой базы этого языка с Nemerle 2.0. Думаю возможность такого разделения-переиспользования должна быть как-то заранее учтена при разработке Nemerle 2.0 — и этот момент полностью относится к этой данной теме, IMO.
Разделять несомненно можно. Вопрос в том, что разделяемые части будут иметь одинаковую семантику. Если тебя устроит некоторый супер-сет Немерла, или даже не полной подмножество, то можно брать "дотнетный" АСТ за основу и добавлять/менять в нем все что угодно.
Но если ты хочешь нативное исполнение и фишки вроде шаблонов, то тебе придется сделать собственный бэкэнд. Нитра сильно упростит эту задачу, так как она тебе предоставит "из коробки" сериализацию и десериализацию всех метаданных. Если в твоем языке будет модульность на уровне сборок (длл-ей), а это логично для языка базирующегося на Немерле, то метаднные из одной длл-и можно будет подключать к другой не особо напрягаясь.
В любом случае тут есть что обсудить с народом. Например, что брать из С++? Очевидно, что С-шный препроцессор — это зло и его брать не следует. А вот нужно ли брать из С++ шаблоны со всеми сложностями и проблемами — это большой вопрос. Мне кажется, что полные по тюрингу шаблоны в языке с макросами не нужны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если кто-то хочет поучаствовать в этих проектах, пишите в ответ на это сообщение.
Поучаствовать хочется, но есть сомнения реально ли это потянуть, так как нет знаний
1. предметной области (компиляторостроение)
2. самой nitra
Кроме того, C# — это очень сложный комплексный язык, где одна только спецификация пятой версии занимает более 500 страниц.
Я сомневаюсь, что сейчас можно зайти со стороны, то есть не будучи автором nitra, и начать приносить реальную пользу.
Может, стоит перед тем, как звать людей делать C# и тем более Nemerle 2, нарисовать что-то попроще, чтобы было ясно, по пунктам, как делаются языки с применением nitra? Может, потенциальным участникам стоит сделать с вашей помощью что-то подобное? Это не должно занять много времени, но перспективы участия в разработке C# должны сильно проясниться, я полагаю.
Потом хочется какого-то понимания, как будет устроен процесс работы.
Как будут ставится задачи, кто все это запроектирует, как будет тестироваться, когда и в каком формате будет проходить общение. Опыт этого раздела, например, показывает, что общение выходит достаточно рваным, так как какие-то вполне конкретные предментные вопросы могут оставаться без внимания долгое время.
VD>Со своей стороны мы будем помогать и обучать.
Этого явно недостаточно, я считаю. Если говорить за себя, то не знаю досконально спецификацию C#, читаю IL-код не без проблем и ориентируюсь там в основном по комментариям из-чего он был сгенерирован. То есть даже часть генерации IL, которая не является чем-то nitra-специфичным, выглядит для меня сложно.
Я могу представить сценарий, когда некто, разбирающийся в данной области сделает каркас, а потом нарежет большой объем сравнительно простой механической работы на маленькие куски и пояснит, как их реализовывать. Тогда можно вложить в это свое время и понемногу раскурить предметку. Вариант, что все соберутся и начнут что-то осмысленное делать, периодически обращаясь к вам за вопросами, я как утопичный даже не рассматриваю.
И, наконец, в gitter-конференции (где по какой-то причине нет никого из ведущих разработчиков языка) обсуждался вопрос целесообразности воспроизведения Nemerle на nitra в его текущем виде. Вот только несколько тем:
— option как значимый тип и его поддержка в компиляторе
— non-nullable types
— методы расширения в стиле F# (обсуждалась поддержка свойств и расширения для статических классов)
— захардкоженные конвенции (невозможно называть типы с маленькой буквы, например)
И далее в таком духе. Это как дискуссия про nemerle base-level, только вместо фатального неприятия C#-программистами when вместо if, обсуждались чуть другие вещи.
Я понимаю, что перспективы Nemerle 2 еще более туманны, чем воспроизведенного на nitra C#, но есть ощущение, что именно это и привлекает внимание людей. У C# сейчас всё хорошо — есть кроссплатформенный roslyn, core clr, ahead of time компиляция в нативный код и тд. И лично меня не сильно интересует воспроизведение C# со всеми его недостатками, которые тянуться со времен первой версии. Полагаю, что я не один такой.
Это вопрос мотивации, потому как люди понимают, что сейчас какие-то вещи сделаны в C# или F# более оптимально чем в Nemerle. А есть еще и опыт других языков. И нужно, во-первых, понимание, какие задачи стоят в разработке Nemerle 2 (nitra в качестве подсистемы макросов здорово, но либо хочется еще профитов, либо нет понимания, к чему это ведет), во-вторых, открытая дискуссия по этим задачам. Было предложение создавать issue с proposal'ами в репозитории текущего Nemerle, но, имхо, это писать в никуда.
Резюмирую:
— надо потренироваться на кошках, перед тем как браться за C#
— надо определить архитектор(а/ов) / ведущещ(его/их) разработчик(а/ов)
— надо напилить маленьких понятных задач
— надо обсуждать перспективы языка, которому посвящен раздел
Это не требования, но без этого что-то поднять будет сложно, на мой взгляд. Потому как я, использующий в Nemerle в продакшене разработчик, на текущий момент более заинтересован в улучшении качества инфраструктуры и компилятора текущего Nemerle, чем в трате времени создание кальки на C# или тот же самый текущий Nemerle. Никто ведь не объяснил внятно, зачем и кому нужен расширяемый C# на nitra и переписанный Nemerle.
Здравствуйте, STDray, Вы писали:
STD>Поучаствовать хочется, но есть сомнения реально ли это потянуть, так как нет знаний STD>1. предметной области (компиляторостроение)
На то мы и делали Нитру, чтобы компиляторы могли делать люди не имеющие огромного опыта в компиляторостроении.
STD>2. самой nitra
Вот ее придется освоить. Но это не так сложно как кажется.
STD>Кроме того, C# — это очень сложный комплексный язык, где одна только спецификация пятой версии занимает более 500 страниц. STD>Я сомневаюсь, что сейчас можно зайти со стороны, то есть не будучи автором nitra, и начать приносить реальную пользу.
Собственно именно потому что работа объемная и нужна помощь.
При этом никто не предалагает новичкам реализовывать C# с нуля. Нитра тем и хороша, что позволяет вести разработку отдельных частей языка независимо от других. Скажем берешь простенький "if" и делаешь его типизацию.
STD>Может, стоит перед тем, как звать людей делать C# и тем более Nemerle 2, нарисовать что-то попроще, чтобы было ясно, по пунктам, как делаются языки с применением nitra?
Ну, для тренировки — можно. Но я тебя уверяю, что работать над шарпом будет не сильно труднее. Даже может и проще, так как нужно реализовывать отдельные мелкие части языка, а не язык с нуля.
STD>Может, потенциальным участникам стоит сделать с вашей помощью что-то подобное? Это не должно занять много времени, но перспективы участия в разработке C# должны сильно проясниться, я полагаю.
Я не против. Лучше делать хоть, что-то. Если потом участники этого проекта смогут сделать статейку с описанием процесса, будет вообще замечательно.
Единственное что мне хотелось бы — это чтобы этот проект делал не я. Я могу консультировать, править баги (если они вылезут) и помогать решать проблемы.
STD>Потом хочется какого-то понимания, как будет устроен процесс работы.
Тут главное начать. Процесс наладится сам собой. Нужно создать репозиторий, создать проект и наладить его сборку. Так как Найтра еще не имеет "коробочного" качества, это тоже будет проблемой.
Далее все очень просто. Шаги банальны и стандартны:
1. Пишется и тестируется в Visualizer-е грамматика в формате .nitra.
2. Описывается AST и mapping правил на него.
3. Пишется и тестируется (там же) типизация.
STD>Как будут ставится задачи, кто все это запроектирует, как будет тестироваться, когда и в каком формате будет проходить общение.
Собственно задача поставлена по ссылке. Нужно просто ее реализовать на Найтра.
STD>Опыт этого раздела, например, показывает, что общение выходит достаточно рваным, так как какие-то вполне конкретные предментные вопросы могут оставаться без внимания долгое время.
Про рваный опыт не понял.
VD>>Со своей стороны мы будем помогать и обучать.
STD>Этого явно недостаточно, я считаю. Если говорить за себя, то не знаю досконально спецификацию C#, читаю IL-код не без проблем и ориентируюсь там в основном по комментариям из-чего он был сгенерирован. То есть даже часть генерации IL, которая не является чем-то nitra-специфичным, выглядит для меня сложно.
ОК, я буду участвовать в разработке нитра-шарпа и ставить задачи для других.
STD>Я могу представить сценарий, когда некто, разбирающийся в данной области сделает каркас, а потом нарежет большой объем сравнительно простой механической работы на маленькие куски и пояснит, как их реализовывать.
Ну, вот каркас для шарпа уже готов. Можно брать и развивать его.
Что касается этого микро-языка, то делать каракас для него мне категорически не хочется. Если уж браться за такой проект, то нужно чтобы он на 100% был создан людьми не имеющими отношения к разработке Найтры. Я буду курировать проект, объяснять что нужно делать и решать возникающие проблемы. Но делать все должны вы. Иначе это будет еще один проект в котором целиком разбираюсь только я.
STD>Тогда можно вложить в это свое время и понемногу раскурить предметку. Вариант, что все соберутся и начнут что-то осмысленное делать, периодически обращаясь к вам за вопросами, я как утопичный даже не рассматриваю.
Я готов организовать взаимодействие. Но мне важно, чтобы проект развивал не я. Я его и так за пару дней сделаю.
STD>И, наконец, в gitter-конференции (где по какой-то причине нет никого из ведущих разработчиков языка) обсуждался вопрос целесообразности воспроизведения Nemerle на nitra в его текущем виде.
Сори. Я уже даже забыл (или не знал) что такое gitter-конференция. Почему бы было не обсуждать это здесь?
STD>Вот только несколько тем: STD>- option как значимый тип и его поддержка в компиляторе STD>- non-nullable types STD>- методы расширения в стиле F# (обсуждалась поддержка свойств и расширения для статических классов) STD>- захардкоженные конвенции (невозможно называть типы с маленькой буквы, например) STD>И далее в таком духе. Это как дискуссия про nemerle base-level, только вместо фатального неприятия C#-программистами when вместо if, обсуждались чуть другие вещи.
Это все какие-то мелкие технические детали. Для начала нужно организовать совместную работу над проектом. Для начала надо воспроизвести C#. А далее каждый сможет эксперементировать с ним. Ну, а на следующем этапе забацаем немерл и решим все поднятые вопросы.
STD>Я понимаю, что перспективы Nemerle 2 еще более туманны, чем воспроизведенного на nitra C#, но есть ощущение, что именно это и привлекает внимание людей. У C# сейчас всё хорошо — есть кроссплатформенный roslyn, core clr, ahead of time компиляция в нативный код и тд. И лично меня не сильно интересует воспроизведение C# со всеми его недостатками, которые тянуться со времен первой версии. Полагаю, что я не один такой.
Воспроизведение C# нужно для того чтобы его можно было начать изменять и расширять. Это как с конструктором. Имея гору блоков Лего не так то просто создать модель красной площади. А вот имея модель красной площади уже не так трудно подправить отдельные ее недостатки.
STD>Это вопрос мотивации, потому как люди понимают, что сейчас какие-то вещи сделаны в C# или F# более оптимально чем в Nemerle. А есть еще и опыт других языков. И нужно, во-первых, понимание, какие задачи стоят в разработке Nemerle 2 (nitra в качестве подсистемы макросов здорово, но либо хочется еще профитов, либо нет понимания, к чему это ведет), во-вторых, открытая дискуссия по этим задачам. Было предложение создавать issue с proposal'ами в репозитории текущего Nemerle, но, имхо, это писать в никуда.
Дискуссия по шкуре не убитого медведя всегда будет крайне не продуктивной. Говорить сейчас о мелких деталях бессмысленно.
Мы имеем шанс показать индустрии как нужно создавать и развивать языки программирования.
Вся прелесть Найтры заключается в том, что с ее помощью моно изменять языки в нужном направлении. Причем делать это несоизмеримо проще чем это было возможно ранее. Каждый кто имеет какие-то идеи в области языкостроения сможет опробовать их на практике. И далее люди и время решат стоящие это идеи или нет.
Немерл нас научил главному. Язык может расширяться библиотеками. Натйра позволяет расширять библиотеками любые языки. Можно взять Шарп и переделать его в другой язык. А можно сделать свой удобный ДСЛ для своих нужд.
Но чтобы все это можно был делать надо реализовать каркас языка (языков). C# — отличный кондидат для тренировки. Работа уже начата и сделано довольно много.
STD>Резюмирую: STD>- надо потренироваться на кошках, перед тем как браться за C#
ОК. Если есть такое желание, то можно реализовать этот мини язык. Давайте соберем команду и наладим общение.
STD>- надо определить архитектор(а/ов) / ведущещ(его/их) разработчик(а/ов)
Я могу быть координатором и консультантом. Ведущим разработчиком я не хочу быть по описанным выше причинам.
Мне кажется, что ведущий разработчик может определиться и сам в процессе работы. Возможно он и не особо буде нужен. Проект очень простенький. Мы на налаживание сборки больше времени убьем.
STD>- надо напилить маленьких понятных задач
Да как бы все задачи шаблонны. Выше я описал процесс. Этот миркро-язык нужен только чтобы изучить концепции Нитры. Затачи в нем настолько примитивны, что их проще определять по ходу действий.
STD>- надо обсуждать перспективы языка, которому посвящен раздел
Перспективы чего? Микро-языка? Это язык-игрушка. Единственная его перспектива попасть в качестве примера в обучающую статью по Нитре.
Или речь о расширяемом C# и Nemerle 2?
С ними даже не надо загадывать что в них будет в дальнейшем. Время самое покажет что в них надо добавить. Для начала нужно просто воспроизвести Шарпа, а далее начинать параллельно его расширять. Это будет точно так же как написание макросов Немрла. Каждый сможет сделать расширение и предложить его на суд зрителей. Только теперь расширения смогут быть куда серьезнее и качественнее.
STD>Это не требования, но без этого что-то поднять будет сложно, на мой взгляд. Потому как я, использующий в Nemerle в продакшене разработчик, на текущий момент более заинтересован в улучшении качества инфраструктуры и компилятора текущего Nemerle, чем в трате времени создание кальки на C# или тот же самый текущий Nemerle. Никто ведь не объяснил внятно, зачем и кому нужен расширяемый C# на nitra и переписанный Nemerle.
Nemerle реализован так, что его улучшение мало чем отличается от переписывания его заново. При этом разработка Nemerle вручную — это много человеколет и много багов, которые потом придется править.
Нитра задумывалась и разрабатывалась для того, чтобы можно было написать Nemerle правильно и без компромисов. Для того чтобы развивать его было не так тяжело и болезненно как сейчас. Мы учли в Нитре все проблемы имевшиеся в Nemerle.
Создать Nemerle на Нитре во много раз проще.
Я ответил на вопрос по Nemerle?
Теперь по C#. Нитра-C# нужен из следующих соображений:
1. C# имеет довольно внятную и полную спецификацию и огромную кодовую базу. Это позволит качественно верефицировать результат.
2. C# очень близок к Nemerle и 90% работы по нему можно будет (с небольшими изменениями) перенести на Nemerle 2.0.
3. Многие не приняли Nemerle из-за того, что он слишком далеко отошел от C#. Сделав Нитра-C# мы сможем предложить плюшки Nemerle (да еще и реализованные на новом уровне) огромному числу C#-программистов. Тем самым есть надежда создать достаточное комьюнити для развития Нитра-C#-а. А уже далее оно может повлиять и на развитие Нитры, и на развитие Nemerle-а.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Теперь по C#. Нитра-C# нужен из следующих соображений: VD>1. C# имеет довольно внятную и полную спецификацию и огромную кодовую базу. Это позволит качественно верефицировать результат. VD>2. C# очень близок к Nemerle и 90% работы по нему можно будет (с небольшими изменениями) перенести на Nemerle 2.0. VD>3. Многие не приняли Nemerle из-за того, что он слишком далеко отошел от C#. Сделав Нитра-C# мы сможем предложить плюшки Nemerle (да еще и реализованные на новом уровне) огромному числу C#-программистов. Тем самым есть надежда создать достаточное комьюнити для развития Нитра-C#-а. А уже далее оно может повлиять и на развитие Нитры, и на развитие Nemerle-а.
Лично мне C# совсем неинтересен, даже с макросами, даже в качестве песочницы. Я на нем не пишу и опробовать его мне просто негде. В отличии от F#.
Какие я вижу проблемы в реализации расширяемого F#:
Significant whitespace синтаксис (хотя Nemerle тоже его поддерживает и, возможно, здесь проблем не будет).
Глобальный вывод типов.
Однопроходный компилятор, поэтому последовательность объявлений типов/функций и порядок файлов важен.
Type Providers — генерят типы лениво и поддерживают так называемые erased types, которые стираются при компиляции.
Здравствуйте, vaskir, Вы писали:
V>Какие я вижу проблемы в реализации расширяемого F#:
V>* Significant whitespace синтаксис (хотя Nemerle тоже его поддерживает и, возможно, здесь проблем не будет). V>* Глобальный вывод типов. V>* Однопроходный компилятор, поэтому последовательность объявлений типов/функций и порядок файлов важен. V>* Type Providers — генерят типы лениво и поддерживают так называемые erased types, которые стираются при компиляции.
F#, по описанным тобой причинам, плохо IDE-зируемый язык. Тайп провайдеры не проблема, а вот однопроходная схема и глобальный вывод типов — это приговор. При этом по возможностям от от Немерла мало чем отличается.
Что касается отступного парсер, то ясно как это дело реализовать, но это надо делать, а приоритет у этого дела не высокий.
C# же можно использовать как базу для Nemerle 2.0.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Уверен, что в Nitra придется многое усовершенствовать, так что мы (разработчики ядра Nitra) видимо будем вынуждены уделять много времени именно Nitra. По сему нужны добровольцы которые будут писать код для Nemerle 2.0 и расширяемого C#.
Здравствуйте, VladD2, Вы писали:
VD>По Nemerle 2.0 задача по сложнее, так как нужно еще написать парсер Nemerle на Nitra
Влад, я не совсем понял принципиальный момент: раз мы пишем Немерле-2, используя Нитру, в конечном итоге мы должны получить некий "лаконичный язык" в виде экзешника. Но ведь Немерле-2 будет таким же расширяемым "сам собой", как и Немерле-1! Получается, расширения к Н-2 будут писаться на самом же Н-2! Но ведь "расширяемые правила" у нас существуют только в Нитре! Какбыть?
Здравствуйте, Kolesiki, Вы писали:
K>Влад, я не совсем понял принципиальный момент: раз мы пишем Немерле-2, используя Нитру, в конечном итоге мы должны получить некий "лаконичный язык" в виде экзешника. Но ведь Немерле-2 будет таким же расширяемым "сам собой", как и Немерле-1! Получается, расширения к Н-2 будут писаться на самом же Н-2! Но ведь "расширяемые правила" у нас существуют только в Нитре! Какбыть?
Тут противоречий нет. Nitra написана на Nitra и одновременно на Nemerle. Nemerle может быть написан на Nemerle и одновременно на Nitra. Просто какая-то часть Nitra станет составной частью Немерла.
В Nemerle 1 ест подсистема парсинга, АСТ, типизированный АСТ, подсистема макросов и т.п. В Nemerle 1 их место займет Nitra. Естественно Нитру придется интегрировать в Nemerle 2, чтобы швов не было видно. Но это не сложно.
В итоге Nemerle и Nitra должны переплестись и стать одним целым. Код в Nitra пишется на Nemerle, сам Nemerle будет реализован на Nitra.
Разница только в том, что Nitra можно будет использовать не только для создания Nemerle, но и для любых других языков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Не, но на нас они их тратить нетхотят. Они их на Котлин, например, тратят.
Получается что проект мертворожденный и не нужный.
Зачем тогда кому-то тратить время бесплатно пилить ваше поделие? Какая-то мотивация кроме саморазвития присутствует?
Для саморазвития разрабу можно найти проекты с куда большим visibility для своего резюме.
Здравствуйте, woah, Вы писали:
VD>>Не, но на нас они их тратить нетхотят. Они их на Котлин, например, тратят.
W>Получается что проект мертворожденный и не нужный.
Это какая-то извращенная логика. То что кто-то считает один проект перспективнее другого, не означает, что второй проект не перспективный. Время рассудит.
W>Зачем тогда кому-то тратить время бесплатно пилить ваше поделие? Какая-то мотивация кроме саморазвития присутствует? W>Для саморазвития разрабу можно найти проекты с куда большим visibility для своего резюме.
Да хоть в крестики нолики играй для саморазвития и резюме. Нам резюмисты/карьеристы не нужны. Нам нужны люди способные делать сложные вещи и способные самостоятельно оценивать перспективность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.