Здравствуйте, VladD2, Вы писали:
VD>Я бы еще понял, если бы кто-то что-то хотел сделать
Хочу сделать Немерле 1.5 — обычный, расширяемый компилятор единственного языка. Пусть код 1.0 придётся выкинуть — не жалко. Новый код будет на парсере от Нитры и свободным от ограничений Немерле 1.0;
Ну и чем это не проект?
Здравствуйте, Kolesiki, Вы писали:
K>Хочу сделать Немерле 1.5 — обычный, расширяемый компилятор единственного языка. Пусть код 1.0 придётся выкинуть — не жалко. Новый код будет на парсере от Нитры и свободным от ограничений Немерле 1.0; K>Ну и чем это не проект?
Нет. Это баловства. Шансов у тебя сделать что-то путное нет. Не то что бы мало, а просто нет.
Для того чтобы разработать язык такой сложности:
1. Нужен не хилоый опыт в разработке ЯП.
2. Нужно понимать какие проблемы были у Nemerle 1.x.
3. Нужны соответствующие средства разработки и базовые библиотеки/фреймворки или большой штат сотрудников работающих на фул-тайм и соответствющее руководство и планирование.
4. Наконец нужны те кто будет этим заниматься. Потому как при закате солнца вручную (при попытке написать с нуля) потребуется много человеколет. Поляки (авторы Nemerle) писали Nemerle около трех лет. Над проектом никогда не работало меньше двух человек. Они срезали все углы с целью как можно быстрее добежать до работающего прототипа, но все же не смоли сделать быстрее. И это при том, что опыт у них был.
Так что идея пытаться создать параллельный проект не просто глупа, а даже вредна. В таких проектах силы распылять нельзя.
Если у тебя есть задор и азарт, лучше приложи свою руку к основному проекту, а не трать его почем зря.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ionoy, Вы писали:
I>>Тут такое дело. Ты фактически говоришь: "Пацаны помогите мне коллайдер построить. Сначала сделаем ускоритель, потом ловушку, ну ещё кабинка для сторожа нужна." I>>А надо говорить так: "Пацаны, мне электрощиток надо установить в 7 комплексе, параметры такие-то." Глядишь кто-нибудь и отзовётся.
VD>Тут хоть мытьем, хоть катаньем, все ничего не делается.
VD>Я бы еще понял, если бы кто-то что-то хотел сделать, обратился ко мне и не смог. Но просто дальше трепа ни у кого ничего не идет. Один орел 3 подхода делал, но после получения примитивнейшего задания исчезал на неопределенное время не задавая ни одного вопроса.
Проблема, Влад, в том, что никому не интересно решать твои проблемы, сорри за каламбур. В случае Nitra всё ещё усугбляется сложностью задач, что отсекает всякую школоту. Как правило, люди которые участвуют в чужих Open Source проектах делают это не ради фана, а для решения каких-то своих задач.
Мне, например, Nitra кажется весьма перспективным продуктом, однако в текущем виде я его для решения своих задач использовать не могу даже теоретически. А в отрыве от практических задач мне эта тема не настолько интересна, чтобы глубоко погружаться в сложную предметную область и тратить на это свое личное время.
Что мне было бы интересно (и чем я мог бы потенциально заняться): порт на Java и интеграция с Eclipse, вместо VS. Другими словами, мне нужен XText, только на стероидах — прежде всего с поддержкой модульных грамматик.
Здравствуйте, #AVM, Вы писали:
AVM>Что мне было бы интересно (и чем я мог бы потенциально заняться): порт на Java и интеграция с Eclipse, вместо VS. Другими словами, мне нужен XText, только на стероидах — прежде всего с поддержкой модульных грамматик.
Тебе нужна нитра написанная на яве или нитра которая может интегрироваться в Eclipse и генерировать код на яве?
Второе намного проще.
Интеграция в Eclipse скорее всего просто механическая работа.
Генерация кода на яве в основном упирается в библиотеку, которая может читать и писать пакеты явы. Я не знаю есть ли такие под .НЕТ.
Как вариант можно генерировать текст на яве и компилировать его ява компилятором.
Для того чтобы саму нитру научить компилировать себя в яву придётся проделать весьма большой объём работы.
Нужно полностью забутстрапить нитру. Что само по себе не просто.
Только после этого можно начать думать о переводе нитры на другие платформы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, #AVM, Вы писали:
AVM>>Что мне было бы интересно (и чем я мог бы потенциально заняться): порт на Java и интеграция с Eclipse, вместо VS. Другими словами, мне нужен XText, только на стероидах — прежде всего с поддержкой модульных грамматик. WH>Тебе нужна нитра написанная на яве или нитра которая может интегрироваться в Eclipse и генерировать код на яве? WH>Второе намного проще. WH>Интеграция в Eclipse скорее всего просто механическая работа. WH>Генерация кода на яве в основном упирается в библиотеку, которая может читать и писать пакеты явы. Я не знаю есть ли такие под .НЕТ. WH>Как вариант можно генерировать текст на яве и компилировать его ява компилятором.
WH>Для того чтобы саму нитру научить компилировать себя в яву придётся проделать весьма большой объём работы. WH>Нужно полностью забутстрапить нитру. Что само по себе не просто. WH>Только после этого можно начать думать о переводе нитры на другие платформы.
Мне нужен полный тулчейн компилятора на Java, кроме бэкенда. Парсер, AST, типизация, генерация плагинов для Eclipse. Интеграция самой нитры с Eclipse тоже конечно не помешает, но это точно не первый приоритет.
Под портом на Java я скорее имел ввиду более-менее механическое переписывание с Nemerle на Java. Я понимаю, что бутстраппинг — это конечно более правильный путь, но с учетом того, с какой скоростью продвигаются работы по Nitra, ждать мне этого ещё долго. Впрочем, если ты готов время от времени консультировать — то я может и впрягся бы сам в это дело.
Только учитывай, что я в этой предметной области разбираюсь довольно поверхностно, так что вопросы могут быть несколько ламерские.
Генерацию я на первых порах делал бы в Java-исходники, так кажется проще, а производительность на этом этапе не так важна.
Здравствуйте, #AVM, Вы писали:
AVM>Мне нужен полный тулчейн компилятора на Java, кроме бэкенда. Парсер, AST, типизация, генерация плагинов для Eclipse.
Я так толком и не понял тебе нужен компилятор на яве или генерация кода на яве?
Ибо для того чтобы генерировать код на яве компилятор не обязан быть на яве.
Единственное чем за это придётся заплатить это поставить .НЕТ или моно на машине разработчика и билдсервере.
На машину клиента ни нитру ни компилятор сгенерированный нитрой ни .НЕТ или моно тащить не нужно.
Я конечно могу представить ситуацию, когда компилятор должен быть непременно на яве. Но скорей всего это не так.
AVM>Интеграция самой нитры с Eclipse тоже конечно не помешает, но это точно не первый приоритет.
Это одно и тоже.
Нитра уже частично написана на нитре. Так что если сделать одно то второе заработает сразу.
Для того чтобы встроить нитру и компиляторы которые генерирует нитра в Eclipse ни нитру ни компиляторы генерируемые нитрой на яву переводить не нужно.
Вся поддержка ИДЕ живёт в отдельном процессе. Для VS это тоже актуально, ибо она 32хбитная и в её адресное пространство загружается куча всякой хрени. Так что адресного пространства на всех не хватает.
Благодаря этому на яве нужно написать только очень тонкую прокладку, которая будет работать вот с этим протоколом. https://github.com/rsdn/nitra/blob/master/Nitra/ClientServer/Nitra.ClientServer.Messages/Messages.n
Для простоты и надёжности нужно модифицировать макросы немерела которые генерируют код на .НЕТ для работы с этим протоколом так чтобы они ещё и генерировали код на яве. https://github.com/rsdn/nitra/tree/master/Nitra/ClientServer/Nitra.ClientServer.Macros
Имея этот код реализация плагина к Eclipse должна быть тривиальной. Если конечно разработчики Eclipse не создали проблем на ровном месте. Но API плагинов Eclipse я не видел так что судить не берусь.
AVM>Под портом на Java я скорее имел ввиду более-менее механическое переписывание с Nemerle на Java.
Не реально. Совсем, совсем не реально. Даже не думай про это.
Для того чтобы это сделать нужно несколько человеко-лет.
И потом будет отдельная проблема с синхронизацией двух проектов.
AVM>Я понимаю, что бутстраппинг — это конечно более правильный путь, но с учетом того, с какой скоростью продвигаются работы по Nitra, ждать мне этого ещё долго. Впрочем, если ты готов время от времени консультировать — то я может и впрягся бы сам в это дело.
И я и Влад проконсультируем тебя в любой момент.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, #AVM, Вы писали:
AVM>>Мне нужен полный тулчейн компилятора на Java, кроме бэкенда. Парсер, AST, типизация, генерация плагинов для Eclipse. WH>Я так толком и не понял тебе нужен компилятор на яве или генерация кода на яве? WH>Ибо для того чтобы генерировать код на яве компилятор не обязан быть на яве. WH>Единственное чем за это придётся заплатить это поставить .НЕТ или моно на машине разработчика и билдсервере. WH>На машину клиента ни нитру ни компилятор сгенерированный нитрой ни .НЕТ или моно тащить не нужно. WH>Я конечно могу представить ситуацию, когда компилятор должен быть непременно на яве. Но скорей всего это не так.
Мне конечно нужен именно компилятор, написанный на Java. Извиняюсь, что недостаточно четко выразил свою мысль.
Влад, а вы не рассматриваете вариант снова поработать по найму? На тех же где-то условиях, как в JetBrains — выделенная команда, занимающаяся Nitra и, возможно, другими языковыми технологиями?
Здравствуйте, #AVM, Вы писали:
AVM>Влад, а вы не рассматриваете вариант снова поработать по найму? На тех же где-то условиях, как в JetBrains — выделенная команда, занимающаяся Nitra и, возможно, другими языковыми технологиями?
Рассматриваем. А кто платить будет?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, #AVM, Вы писали:
AVM>>Влад, а вы не рассматриваете вариант снова поработать по найму? На тех же где-то условиях, как в JetBrains — выделенная команда, занимающаяся Nitra и, возможно, другими языковыми технологиями? WH>Рассматриваем. А кто платить будет?
Детали предлагаю обсуждать в Skype: andrew.v.moiseev
Здравствуйте, #AVM, Вы писали:
AVM>Влад, а вы не рассматриваете вариант снова поработать по найму? На тех же где-то условиях, как в JetBrains — выделенная команда, занимающаяся Nitra и, возможно, другими языковыми технологиями?
Мысли такие есть. Я планировал кое что доделать (для более презентабельного вида) к зиме/осени и пройтись по софтовым фирмам.
Но без связей изнутри, конечно, будет не прос.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если сравнить nitra и xtext, что в nitra есть нового и полезного?
Еще не нашел тулкита для java, не дадите ссылку, если конечно таковой существует (то что должен существовать следует из того, что разрабатывалось оно в jetbrains).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Если сравнить nitra и xtext, что в nitra есть нового и полезного?
1. Модульность.
2. Расширяемость. В том числе в рантайме. Например, как Немерле, путем открытия пространства имен в некотором файле можно добавить поддержку расширения языка.
3. Безлексерность позволяет более гибко расширять языки. Меньше конфликтов. Нет проблем с тем, что в разных местах языка нужны разные лексерные контексты.
3. Нитра может поддерживать более сложные языки с меньшим объемом ручного кодирования.
4. Поддержка вывода типов.
xtext работает по верх генерированного АНТЛР 3 парсера. Отсюда и все проблемы с модульностью.
LP>Еще не нашел тулкита для java, не дадите ссылку, если конечно таковой существует (то что должен существовать следует из того, что разрабатывалось оно в jetbrains).
Реализации для Явы нет. Для этого нужно финасирвоание. Это довольно большой объем работ. Хотя мы все спроектировали так, чтобы это можно было сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
САД>>а зачем оно всё нужно, когда есть scala? САД>>я просто не совсем в курсе. С>
С>Покажите мне, пожалуйста, аналог linq2db для Scala. До сих пор ведь не написали. И не напишут, потому что язык жуткий, хуже C++.
С>Вот например, оператор <|*|> С>Угадайте-ка, что он означает. С>https://stackoverflow.com/questions/2545248/function-syntax-puzzler-in-scalaz\
в scala linq не нужен. там множество вещей делается значительно проще. без изобретений велосипедов.
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>в scala linq не нужен. там множество вещей делается значительно проще. без изобретений велосипедов.
Так, вы не поняли, о чём речь. linq2db — это типизированный SQL. Запросы к базе вы будете писать либо руками, либо как-то выводить из кода, с контролем компилятора, с оптимизациями, с безопасной параметризацией и т.п. И вот второго варианта — не-руками, в scala просто нет. Есть scala slick, и порождает он совершенно монстроидальные запросы, пользоваться им нельзя.
Вот так вот — язык вроде бы мощный, а чего надо — на нём не пишут.
САД>>в scala linq не нужен. там множество вещей делается значительно проще. без изобретений велосипедов. С>Так, вы не поняли, о чём речь. linq2db — это типизированный SQL. Запросы к базе вы будете писать либо руками, либо как-то выводить из кода, с контролем компилятора, с оптимизациями, с безопасной параметризацией и т.п. И вот второго варианта — не-руками, в scala просто нет. Есть scala slick, и порождает он совершенно монстроидальные запросы, пользоваться им нельзя.
типизированные запросы тоже не всегда нужны.
или не всегда возможны. как например с dapper.
linq2db всё равно не убережет тебя от ошибок в рантайме.
а получить типизированный результат позволяет и scala
С>Вот так вот — язык вроде бы мощный, а чего надо — на нём не пишут.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaPerouse, Вы писали:
VD>3. Безлексерность позволяет более гибко расширять языки. Меньше конфликтов. Нет проблем с тем, что в разных местах языка нужны разные лексерные контексты.
А бэктрекинга нет? Как в DCG Prolog-а. Наличие бэктрекинга позволит выйти за пределы контекстно-свободных грамматик.
VD>3. Нитра может поддерживать более сложные языки с меньшим объемом ручного кодирования. VD>4. Поддержка вывода типов.
LP>>Еще не нашел тулкита для java, не дадите ссылку, если конечно таковой существует (то что должен существовать следует из того, что разрабатывалось оно в jetbrains).
VD>Реализации для Явы нет. Для этого нужно финасирвоание. Это довольно большой объем работ. Хотя мы все спроектировали так, чтобы это можно было сделать.
Понятно. А не проще попробовать генерировать ява-код из уже сгенерированного .net кода?
Социализм — это власть трудящихся и централизованная плановая экономика.
