Здравствуйте, IT, Вы писали:
IT>Кому она нужна без Немерле? Ну несколько интузиастов наклепали на ней что-то там. Это что-то уже перевернуло наше представление о разработке ПО? Ещё нет? А чё так
А кому сейчас нужен Nemerle? Ты всерьёз веришь, что он всё ещё способен что-то перевернуть? Я серьёзно, без подвоха спрашиваю. За те 5-7 лет с момента, когда делались последние допущения о востребованности и предназначении этого языка, весь остальной мир как бы на месте не стоял.
Вот, прямо сейчас, наблюдается неслабый хайп вокруг микросервисов, безсерверных и изоморфных приложений, блокчейна со смарт-контрактами и машинного обучения. Убогий (по меркам Nemerle) JavaScript уже сейчас пролез во всё это, кроме разве что ML и вполне успешно там используется. Что сейчас Nemerle сможет противопоставить этому языку, даже, если получит вменяемые бэкенды?
Здравствуйте, Qbit86, Вы писали:
KV>>Но тогда все здесь активно топили за .NET и написанную выше ересь, в лучшем случае, просто высмеяли бы. Q>Да и сейчас топят, и правильно делают.
Потеряв при этом для Nemerle куда большую пользовательскую массу, чем когда-либо была вокруг всей экосистемы .NET. Что в этом правильного?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Потеряв при этом для Nemerle куда большую пользовательскую массу, чем когда-либо была вокруг всей экосистемы .NET. Что в этом правильного?
Привязка к .NET это не только привязка к рантайму, но и доступ к стандартной библиотеке и уже написанным широко используемым компонентам. Если это всё заново изобретать, то ситуация была бы хуже.
Здравствуйте, Qbit86, Вы писали:
Q>Привязка к .NET это не только привязка к рантайму, но и доступ к стандартной библиотеке и уже написанным широко используемым компонентам. Если это всё заново изобретать, то ситуация была бы хуже.
Зачем переизобретать заново? "Отвязать" -- не значит, лишить язык поддержки этой платформы. Уже тогда была JVM с не меньшей библиотекой и компонентами. Чуть позже появилась LLVM. Моя мысль в том, что не стоило зацикливаться на .NET и тем более усиливать уже сущетвующую зависимость этого языка от конкретной платформы.
Здравствуйте, IT, Вы писали:
IT>Дык уже был инвестор. Всемирно известная компания JetBrains в течении трёх лет платила зарплату трём оболтусам. Рузультат — ноль. Думаешь дело в ковбойской шляпе?
Почему ноль? То что ты не хочешь смотреть на результат не значит, что его нет. Вопрос только в том, что 9 человеко-лет это мало для такого проекта. Плюс была еще одна проблема. Вольфхаунд был (вообще не ясно зачем) в Питере и я им фактически не мог управлять. Первое время он работал по полной, а потом все меньше и меньше. Так в реальности это было не 9 человеко-лет, а где-то 7. Если бы ДжетБрэйновцы не заставили нас разбить команду, то результат был бы лучше. А если не самоустранялись примерно через год, то еще лучше.
Последний год мы со Стасом (Храдкейсом) пахали так, что я после этого пол года отойти не мог и заработал себе повышенное давление. А ты вместо помощи, или хотя бы, поддержки — очередной раз глумишься. Сам то ты много сделал для проекта? Я ведь тебя не раз просил помочь. Вот ты тут о говорил о том что нужна компиляция под Кор и т.п. Вот помоги. Хотя бы разобраться, как отделить эмит из Розлина от самого Розлина-а. Тогда сделать нитровские языки кросплатформными будет совсем не сложно. Что-то мне подсказывает, что и CCI позволит под Core компилить. Но это надо пробовать, так как Майкрософтовский аналайзер портируемости, похоже, CCI использует.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Не стоит так, о коллегах Один из этих "оболтусов" после JetBrains устроился к нам и, за ~1.5 года работы, никаких нареканий к его продуктивности не возникло. Из этих полутора лет, месяцев ~8 я был его тимлидом, т.ч. знаю, о чём говорю. Это при том, что проект, над которым он всё это время работает, местами посложнее компилятора или языкового фреймворка будет.
Да, Стас программер от бога. Немножко, только, на запросы пользователей плюет (из серии "от меня пакет ушел") и, к сожалению, в последнее время мне совсем не помогает . Если бы над проектом работал бы хотя бы он, то мы уже его закончили.
KV>Получается, что вполне себе взрослый человек три года пинал балду, а потом внезапно взялся за ум, да так, что уже второй год отпустить не может? "Не верю!" (с)
Да у них постоянная идея, что они то на нашем месте все сделали бы не так, а в сто раз проще и лучше.
Это если погрузишься, ясны все сложности задач. А о чужой работе всегда легко рассуждать со стороны. Мы он и страной бы лучше управляли. И в футбол бы лучше играли (не смотря на пивные животы).
KV>Результат -- в репозитории Nitra и он определённо отличается от нулевого на несколько порядков.
Спасибо за поддержку.
KV>Если же речь про Nemerle, то он (насколько я помню) JetBrains интересовал лишь, как средство, но не сама цель. Целью же была разработка парнями тулкита, который мог бы, с одной стороны -- занять нишу модных нынче Haxe-подобных фреймворков, а с другой -- дать JetBrains возможность выстроить вокруг всего этого инфраструктуру на базе уже имеющихся продуктов.
Они их вообще не интересовал. Они один раз глянули на его демонстрацию. Я продемонстрировал, что все их предубеждения по поводу макросов беспочвенны, но интерес там не особо возник. Бреславу (автору Котлина) было интересно лишь сравнение со своими языковыми решениями. Он мне рассказал про планы сделать поддержку множественного наследования в Котлине. Я усомнился в простоте реализации этого дела. Он сказал, что сделают, но так и не сделали. А мы вот, со Стасом, сделали. В Нитре для АСТ поддерживается множественное наследование. Очень удобно получилось.
KV>Причин, по которым всё случилось так, как случилось -- множество и парни имеют отношение далеко не ко всем из них, IMO.
Именно так. Наверно мы не всегда выкладывались на 100. Но три года подряд выкладываться на 100% просто не реально. И наверно мы замахнулись на слишком большую задачу, недооценив ее сложность.
Но я могу детально доказать, что сделать правильный расширяемый язык по другому практически не возможно. Ну, разве что с намного большей командой и баблом МС.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я к тому, что разработка ими в первую очередь интеграции с VS (прибившей Nemerle гвоздями к экосистеме .NET) была ошибкой. Первое, что нужно было сделать -- это забить на польский proof-of-concept и отвязать язык от .NET (от слова совсем). И только после этого делать интеграцию с IDE и не факт, что VS был бы лучшим выбором. Результатом этого просчёта явилась потеря значительной массы потенциальных пользователей (часть из которых, вполне могла и примкнуть к проекту, со временем) и стагнация внутри одной платформы на десяток лет. Но тогда все здесь активно топили за .NET и написанную выше ересь, в лучшем случае, просто высмеяли бы.
Интеграция сейчас живет в серверном процессе. Клиентский код минимален. Перенести его на другую IDE, пусть даже основанную на Java или JavaScript уже совсем не сложно. Саму нитру (точнее языки основанные на ней) можно компилировать под Core, что обеспечить переносимость на все разумные платформы.
KV>Это не так. Концепцию Nitra (тогда ещё она называлась N2) начали прорабатывать задолго до начала истории с JetBrains. И парней изначально туда взяли на разработку именно языкового фреймворка, а не Nemerle. Пруф: https://blog.jetbrains.com/dotnet/2012/06/27/jetbrains-and-nemerle/
Именно так. И концепция Нитры была адаптирована так, чтобы как раз заинтересовать какую-нибудь контору, так как как раз Немерл никто поддерживать не хотел.
Лично я в этот проект впрягся именно для того, чтобы написать качественный расширяемый язык. Не важно Немерл ли это будет или ШарпаЭкс.
На сегодня мы можем вообще сразу несколько синтаксисов разбирать в единый АСТ с единой типизацией. Так что нет проблем сделать поддержку в одном языке и расширяемого Шарпа, и Немерла 2, и даже совсем нового языка, если это кому-то надо.
Фактически мы решили все технологические проблемы, что были у нас в Немерле. Единственное с чем может быть получилось не очень хорошо — это язык отображения. Он не очень интуитивный и явно излишний для мноигих задач. Но эту проблему можно было бы устранить пори реализации того самого расширяемого языка. Просто сделать немерлоподобный синаксис макросов, когда синтаксис задается вокруг АСТ-а, а не отображается на АСТ. К сожалению это не универсальное решение, но для 80% случаев его будет достаточно. Так что и эту проблему известно как решать.
С точки зрения переносимости надо делать два шага:
1. Переводить Немерл на Нитру в том объеме в котором Нитра использует Немерл.
2. Делать правильные бэкэнды. Первым делом имеет смысл попробовать использовать Roslyn-овский эмит для генерации кода. Это даст возможность генерации кода для .Net Core и переносимость. За счет сервера мы сможет окучить любую IDE в разумные сроки. Далее можно сделать бэкэнд для Явы и/или LLVM. Тогда будет вообще полная переносимость. Даже на загадочные платформы.
Но все это силы и время.
KV>Эта статья была опубликована сразу после того, как парни оказались под крылом JetBrains. Работу именно над Nemerle им там никто и никогда не оплачивал. От парней ждали несколько иного результата и упрекать их за то, что они стремились добиться именно его -- по меньшей мере странно
Все так. Просто IT хочет быть правым, ругать нас и при этом не помогать. Было бы честно просто сказать, что у него нет времени и желания на этот проект. Но зачем-то нужны оправдания. Вот и выдумываются какие-то мифические цели ДжетБрэйнс и нулевой результат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Qbit86, Вы писали:
KV>>Но тогда все здесь активно топили за .NET и написанную выше ересь, в лучшем случае, просто высмеяли бы.
Q>Да и сейчас топят, и правильно делают.
Я за последние годы не раз слышал о том, что .NET для нашего проекта — минус не дающий использовать его в чьей-то работе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Потеряв при этом для Nemerle куда большую пользовательскую массу, чем когда-либо была вокруг всей экосистемы .NET. Что в этом правильного?
Может это и правильно, но это не так просто. Это требует сил. А сделать это еще и технически правильно не сделав всего того, что сделали мы сейчас — еще сложнее. Велика вероятность получить в итоге костыльный продукт вроде Немерла 1.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А кому сейчас нужен Nemerle? Ты всерьёз веришь, что он всё ещё способен что-то перевернуть? Я серьёзно, без подвоха спрашиваю. За те 5-7 лет с момента, когда делались последние допущения о востребованности и предназначении этого языка, весь остальной мир как бы на месте не стоял.
Я уверен, что язык с расширяемым синтаксисом будет востребован все больше и больше. Сложность софта возрастает и чтобы просто держать ее в узде нужно ДСЛ-ить решения.
Минус именно Немерла в том, что он отличается от Шарпа и на его рскрутку нужно больше сил. Плюс огромный вопрос в качестве реализации.
KV>Вот, прямо сейчас, наблюдается неслабый хайп вокруг микросервисов, безсерверных и изоморфных приложений, блокчейна со смарт-контрактами и машинного обучения. Убогий (по меркам Nemerle) JavaScript уже сейчас пролез во всё это, кроме разве что ML и вполне успешно там используется. Что сейчас Nemerle сможет противопоставить этому языку, даже, если получит вменяемые бэкенды?
Да все тоже самое только удобнее и с возможностью решать конкретные задачи сделав ДСЛ-чик. Только в Немерле для этого прямых средств не было. В Нитре мы как раз продумали этот вопрос. Для ДСЛ-ей можно делать специализированный АСТ, который по своим возможностям не отличается от встроенного в Немерл 1.х. Точнее в Нитре это одно и то же. Средства описания АСТ Нитры позволяют описывать любые языковые конструкции и расширения. Языковую конструкцию можно описать как она есть и стипизировать получив первоклассную сущность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
KV>А кому сейчас нужен Nemerle?
Поясню свою позицию, которую пытаюсь донести до IT.
У Nemerle на текущий момент сложилась крайне хреновая "кредитная история" -- факт. Я не представляю себе, что возможно сделать для привлечения к нему интереса в текущем виде, даже если каким-то образом запилить там заменяемые бэкенды на текущей реализации, отполировать интеграцию со студией и т.п. Дело не в самом языке (он действительно хорош), а в его истории и упущенном времени. Кроме того, его область применения сейчас по сути ограничена библиотеками классов, консолью и частично вебом. И только в рамках .NET, и только с поддержкой VS. Этого недостаточно для того, чтобы им начали пользоваться прямо сейчас.
Nitra же позволит приемлемо быстро втащить Nemerle в чудесный мир JavaScript (проблем с библотеками там не будет, на худой конец -- https://bridge.net/ в руки и вперёд), дать сишарперам выбор между Nemerle и расширяемым C# и сделать то, чего не смогли сделать за все эти 10 лет: дать языку возможность жить за пределами одной платформы. "интернет-коммуникатор… iPod, телефон… понимаете? Это не три отдельных устройства. Это всего одно устройство!" (с).
Взять тот же Ethereum, ICO на котором растут сейчас, как на дрожжах. Виртуальная машина (EVM) там до безобразия простая. Solidity -- откровенно убог. Serpent -- ещё хуже. Вменяемого языка, который давал бы возможность разработки защищённых смарт-контрактов с верифицируемым workflow сейчас просто нет. Подмножество Nemerle, сдобренное контрактным сахаром и компилирующееся в байт-код EVM -- с руками оторвут, хоть сейчас (за это реально готовы платить и платить неплохо). Для текущего состояния Nemerle это -- неподъёмная задача. С Nitra же достаточно будет порезать стандартные библиотеки языка, добавить макросы, реализующие нужные примитивы контрактного программирования и реализовать бэкенд в EVM. Задача, которая вполне оценивается по всем типам ресурсов и, которая вполне достижима.
То же самое и с безсерверными приложениями. Будь у Nemerle возможность транспайлинга в JavaScript -- существенная доля проектов под амазоновский AWS стала бы его в достаточно короткие сроки. Возможно ли это сделать сейчас без Nitra, "наживую" в текущем компиляторе? Риторический вопрос. То же самое с SPA, то же самое с микросервисами, то же самое с мобилками. Нынешний мир уже давно не делится только на вебовский фронтенд и бэкенд (куда в чистом виде, ещё одному языку, только лучше, пробиться будет крайне тяжело). Вот на этом и можно сыграть, несмотря на потерянное время и текущую ситуацию. И вот для этого нужна Nitra.
Здравствуйте, VladD2, Вы писали:
VD>Я за последние годы не раз слышал о том, что .NET для нашего проекта — минус не дающий использовать его в чьей-то работе.
И не только за "последние". 10 лет назад я (и не только) тебе об этом тоже говорил.
Бог с ним с N1 — поляки сделали выбор за вас. Нитру-то почему надо были на этом говне мамонта делать? Уж скалка в тот момент точно была не хуже и давала вам кроссплатформу сходу.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>То же самое и с безсерверными приложениями. Будь у Nemerle возможность транспайлинга в JavaScript -- существенная доля проектов под амазоновский AWS стала бы его в достаточно короткие сроки. Возможно ли это сделать сейчас без Nitra, "наживую" в текущем компиляторе? Риторический вопрос. То же самое с SPA, то же самое с микросервисами, то же самое с мобилками. Нынешний мир уже давно не делится только на вебовский фронтенд и бэкенд (куда в чистом виде, ещё одному языку, только лучше, пробиться будет крайне тяжело). Вот на этом и можно сыграть, несмотря на потерянное время и текущую ситуацию. И вот для этого нужна Nitra.
Генерацию JavaScript сделать можно. Но опять таки время. ionoy и NN делали это для Немерла в https://github.com/NemerleWeb/NemerleWeb. Получилось не самое прямое решение, но оно работало. Вот только это никак не помогло популяризации Немерла. Более того сам Немерле веб не взлетел. Его тупо не поняли. Все искали там то визуальный редактор, то разделение модели и представления (тупо не понимая, что имеют дело с MVVM). Потом многие из не понявших все же освоили Ангуляр.
Собственно место того чтобы сужать нишу Нитры лучше попытаться привлечь тех кто сделает эти нишевые решения для себя.
Мы же можем предоставить общую базу для таких решений. Ну, и базовые языки: Шарп, Немерл, (возможно) ТайпСкрипт или что-то еще. Ну, и уже на базе их делать нишевые расширения и порты на другие платформы (в том числе и JavaScript или WebAssembly).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Знал бы прикуп, жил бы в Сочи Ровно 10 лет назад парни только-только взяли проект под своё крыло, вместо бросивших его поляков и определённо не имели достаточной информации, чтобы прогнозировать дальнейшее развитие проекта. По крайней мере, настолько, чтобы правильно расставить приоритеты стоявшим задачам.
Ровно 10 лет назад среди этих самых парней был и я и что тогда происходило мне известно в деталях. Я не силён в картах, но уже тогда было понятно что надо было делать и какие должны быть приоритеты. Самое печальное, что за эти 10 лет приоритеты никак и не поменялись.
Не хочу выглядеть слишком скромным, но равно десять лет назад я утверждал, что:
— компилятор представляет собой кусок говна.
— работу надо начинать с тотального переписывания всего кода.
— Немерле следует рассматривать как прототип, передизайнивать с нуля, отчуждать его от поляков, бросивших его к тому моменту (отдав все положенные почести авторам прототипа), переименовывать и полностью узурпировать.
— первостепенное значение имеет устранение привязки к Reflection.Emit и кодогенерация во все доступные .net фреймворки.
— энтузиасты не задерживаются на проекте долго по вышеперечисленным причинам.
Лично мне такому скромному почему-то это было понятно ещё 10 лет назад. Я часами убеждал Влада, что поступать нужно именно таким образом. Прошло 10 лет. 10, мля, ЛЕТ! А приоритеты всё теже
KV>Я к тому, что разработка ими в первую очередь интеграции с VS (прибившей Nemerle гвоздями к экосистеме .NET) была ошибкой. Первое, что нужно было сделать -- это забить на польский proof-of-concept и отвязать язык от .NET (от слова совсем).
От поляков нужно было отвязывать. От .NET? Зачем? В перспективе вполне можно было сделать кодогенерацию и на другие платформы. Мы с Владом это тоже обсуждали. Но изначально разработка на .NET и VS вполне была оправдана.
KV>>>Если же речь про Nemerle, то он (насколько я помню) JetBrains интересовал лишь, как средство, но не сама цель.
Я уже говорил, что это стало понятно не сразу. Сам факт того, что разработчиков языка берёт на работу JetBrains всеми был воспринят именно как перспективы прежде всего для языка. Но как-то быстро оказалось, что разработка "засекречена" и чем они там занимаются является копроративной тайной. Код не доступен, от разработчиков лишь загадочные намёки, перспективы туманны.
IT>>Это выяснилось далеко не сразу и скорее как оправдание того, что Немерле так никто и не стал заниматься. Изначально всё выглядело и заявлялось как JetBrains берёт под своё крыло язык и нанимает на работу его разработчиков. Ни о каких Нитрах вообще речи не было.
KV>Это не так. Концепцию Nitra (тогда ещё она называлась N2) начали прорабатывать задолго до начала истории с JetBrains. И парней изначально туда взяли на разработку именно языкового фреймворка, а не Nemerle. Пруф: https://blog.jetbrains.com/dotnet/2012/06/27/jetbrains-and-nemerle/
Вот именно:
We are extremely excited about this project and happy to bring Nemerle under the JetBrains umbrella and thus guaranteeing the viability of the N2 project.
Немерле под крыло, а что такое N2 толком никто не понимает. Орандж в Осло по секрету рассказал, что команду Немерле нанимает JetBrains. Вот этому чуваку — Philip Laureano, тогдашнему энтузиасту Немерле, он при мне в курилке грузил про все перспективы, которые теперь ожидают язык. Ни о каких Нитрах и прочем речи не было. Выглядело всё как язык берёт под крыло JetBrains. И это было реально крутой новостью и реально крутой перспективой для языка. Фактически тогдашняя мечта Влада сбылась — заниматься языком фултайм.
KV>Эта статья была опубликована сразу после того, как парни оказались под крылом JetBrains. Работу именно над Nemerle им там никто и никогда не оплачивал. От парней ждали несколько иного результата и упрекать их за то, что они стремились добиться именно его -- по меньшей мере странно
В этом смысле у меня к парням никих претензий нет. Парни отборолись по полной. Снимаю шляпу. Нитра — реально крутая... хрень. Думаю, опередившая своё время минимум на десятилетие. Есть только один вопрос — а Немерле где? По сути — это как был кусок говна, там им и остался.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
IT>>Кому она нужна без Немерле? Ну несколько интузиастов наклепали на ней что-то там. Это что-то уже перевернуло наше представление о разработке ПО? Ещё нет? А чё так
KV>А кому сейчас нужен Nemerle? Ты всерьёз веришь, что он всё ещё способен что-то перевернуть? Я серьёзно, без подвоха спрашиваю. За те 5-7 лет с момента, когда делались последние допущения о востребованности и предназначении этого языка, весь остальной мир как бы на месте не стоял.
И какие супер языки за это время появились?
Не думаю, что Немерле сегодня перевернёт мир. Не думаю, что у него есть шанс в будущем. Много времени упущено. Годы. Возможно даже и раньше, если бы всё было сделано правильно, то шансов было бы много. Но шансы были. У Немерле есть одна особенность, которая до сих пор не востребована и до сих пор скорее всего не осознанна — это макросистема. Не знаю как полякам удалось придумать такой удачный и сбалансированный язык. Видимо поляки действительно самая умная нация в Европе. Нужно это просто довести до ума. И Нитра здесь будет рулить нещадно. Но нужно качество, не тот кусок говнища, который из себя представляет компилятор сегодня, а качественный, продуманный и расширяемый код.
Лет пять назад я прикидывал варианты переноса своего некоторого кода на Немерле. Там реально сокращение кода на порядок. При этом в старом коде обнаруживались застарелые баги. ПМ + автоматизация кода могут творить чудеса. Не для всех типов приложений, но могут.
Кстати, обнаружилась весьма не эффективная генерация кода для ПМ. Но это вопрос технический.
KV>Вот, прямо сейчас, наблюдается неслабый хайп вокруг микросервисов, безсерверных и изоморфных приложений, блокчейна со смарт-контрактами и машинного обучения. Убогий (по меркам Nemerle) JavaScript уже сейчас пролез во всё это, кроме разве что ML и вполне успешно там используется. Что сейчас Nemerle сможет противопоставить этому языку, даже, если получит вменяемые бэкенды?
Хайпы на то они и хайпы. Сегодня одни хайпы, завтра будут другие. Тем более в вебе. Там чем примитивнее и хайповее, тем лучше. Это точно не ниша Немерле.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Но тогда все здесь активно топили за .NET и написанную выше ересь, в лучшем случае, просто высмеяли бы. Q>>Да и сейчас топят, и правильно делают. KV>Потеряв при этом для Nemerle куда большую пользовательскую массу, чем когда-либо была вокруг всей экосистемы .NET. Что в этом правильного?
Не надо пытаться перевести всех старушек через все дороги сразу. Хотя, если решать эту задачу последовательно, то Немерле мог бы оказаться лучшим решением.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Взять тот же Ethereum, ICO на котором растут сейчас, как на дрожжах. Виртуальная машина (EVM) там до безобразия простая. Solidity -- откровенно убог. Serpent -- ещё хуже. Вменяемого языка, который давал бы возможность разработки защищённых смарт-контрактов с верифицируемым workflow сейчас просто нет. Подмножество Nemerle, сдобренное контрактным сахаром и компилирующееся в байт-код EVM -- с руками оторвут, хоть сейчас (за это реально готовы платить и платить неплохо). Для текущего состояния Nemerle это -- неподъёмная задача. С Nitra же достаточно будет порезать стандартные библиотеки языка, добавить макросы, реализующие нужные примитивы контрактного программирования и реализовать бэкенд в EVM. Задача, которая вполне оценивается по всем типам ресурсов и, которая вполне достижима.
Scala? Maкро-система там собственно скопирована из N1 (идет работа на новой), но сам язык стабильный в отличие от. Я не в курсе Ethereum и ихних контрактов, но для задачи точно нужен внешний DSL, чтобы оправдать использовании Нитры?
Здравствуйте, IT, Вы писали:
IT>От поляков нужно было отвязывать. От .NET? Зачем?
Потому что .NET это 10%2% энтузиастов, которые нужны для поддержки, особенно на начальном этапе. "Нет кросс-платформы? Идите в жопу!".
IT>В перспективе вполне можно было сделать кодогенерацию и на другие платформы. Мы с Владом это тоже обсуждали.
Совсем не обязательно "другие". Можно одну, но она должна работать на 99% железа.
IT>Но изначально разработка на .NET и VS вполне была оправдана.
Необходимо было сразу переходить на JVM вместо VS-интеграции на которую Влад и компания потратили миллион задочасов. Правильным решение было бы просто затащить макро систему, если уж без нее не обойтись, в существующий современный язык, разрабатываемый людьми с настойчивостью и бюджетом (на тот момент Скала), а потом на нем разрабатывать Нитру, но это я конечно немного задним числом.
VD>... Я и так из последних сил иду по этому пути. Срезать углы нельзя. Будет такая же лажа как с Немерле 1.
Влад, и все парни принимавшие участие, реально крутые. сделать (сначала на энтузиазме) столько работы... я даже не могу себе такого представить.
наработки, реально интересные и местами не имеющие аналогов.
Но (как уже много раз было сказано), если общий объём работ тянет на сотни человеко-лет, то... одного энтузиазма нехватит.
Влад, ты не думал взять таймаут... собраться с духом... переключиться... и переключить внимание на поиск финансирования?
Может в универах есть какие-то гранты, или какие-то гос. программы по развитию? или в крупных корпорациях (типа 1с, касперский итп)?...
ведь как-то ведь финансируются исследовательские проекты.
Я думаю (если ещё дух крепок), надо решать задачу поиска союзника с деньгами..
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Нет, о профессионализме ты ничего не писал. Как, впрочем, и я. Я писал о продуктивности, т.е. о способности довести поставленную задачу до конца, в оговоренные сроки. Т.е. как раз о:
А вот парни которые пилили Elixir (с 2012) выпустили уже 1.5 версию, наплодили фреймворков и "интегрровались" с Elm, программисты на нём регулярно выступают на конференциях. Я понимаю, что разработка Влада больше похоже на полуакадемическую штку Haskell, но всё же я прекрасно понимаю IT и точку зрения.