Пару зёрен истинны у Колесика есть, но онт в зародыше. А пишем свою IDE вместо того что бы писать языковой сервис который встраивается в IDE — это явно упрощение и намерннное искажение ситуации.
И там по каждому пункту можно не то что смело не соглашаться, а даже комментировать не стоит.
Здравствуйте, Kolesiki, Вы писали:
K>Эй, мы тут опердни пишем, нам нет дела до гипермакросов!
Вот ключевое. Типичному опердень-программисту под .NET нет дела и до просто-макросов.
Есть конечно единицы которые и оценят, и применят, но в целом это промах с целевой аудиторией.
Нужно целится в C++ аудиторию, там народ выжимает из языка и препроцессора все возможные метапрограммные соки, используя любую возможную техническую зацепку и раскручивая её на полную катушку. И причём эти трюки становятся настолько популярны, что утилиты на их основе попадают в стандарт (например тот же enable_if).
В качестве бэкенда можно проделать тот же трюк что и Страуструп когда-то — то есть транслировать код из этого чудесного макро-немерле-языка в C++, тем самым бесплатно получив громадный охват платформ и лёгкость интеграции с уже готовым кодом, а самое главное — благодатную аудиторию
Здравствуйте, Mystic Artifact, Вы писали:
MA>Пару зёрен истинны у Колесика есть, но онт в зародыше. А пишем свою IDE вместо того что бы писать языковой сервис который встраивается в IDE — это явно упрощение и намерннное искажение ситуации. MA>И там по каждому пункту можно не то что смело не соглашаться, а даже комментировать не стоит.
На самом деле там всё как всегда эмоционально, но по делу.
1. Компилятор действительно представляет собой кучу говна. То, что его не начали переписывать ещё в 2008-м наверное самая большая ошибка.
2. По второму пункту тоже вроде так и есть на самом деле.
3. Нитра — это вторая большая толи ошибка, толи диверсия
4. Писать свою IDE — это бред, да.
5. Всё верно. Вхождение в проект должно быть простым и быстрым. А там сейчас без консультаций специалистов никак.
Ну и я бы добавил, что начинать нужно даже не с компилятора, а с переименования языка. Пусть Немерле останется языком, который придумали польские студенты. Они молодцы.
Если нам не помогут, то мы тоже никого не пощадим.
IT>Ну и я бы добавил, что начинать нужно даже не с компилятора, а с переименования языка. Пусть Немерле останется языком, который придумали польские студенты. Они молодцы.
А что не так с языком?
По мне там только один косяк — заморочки с массивами. и отсутствие коде-стайла.
нужен форматтер по аналогии с растом. сам язык вполне себе. ну и чтобы он было популярен, нужна поддержка "вс-код" как минимум с интелисенсом
и шаблоны проектов под кору(dotnet new). т.е. возможность кодить под линксом. для независимых проектов очень бы подошел язык.
Здравствуйте, IT, Вы писали:
IT>С языком нормально. Есть некоторые мелочи, типа привести синтаксис дженериков к стандартному виду.
Это с самого рождения была топ 1 не реализованная фича, имхо. Я не понимаю какого хрена её не сделали. Даже в C++ побороли проблемы с этим, если кто помнит времна когда нужно было добавлять пробелы перед >.
Игорь, спасибо за обстоятельный ответ. Я заранее извиняюсь, если местами буду отодвигаться от темы.
IT>1. Компилятор действительно представляет собой кучу говна. То, что его не начали переписывать ещё в 2008-м наверное самая большая ошибка.
И да и нет. Его никто не начал переписывать в 2008-м потому, потому, что сейчас, задним числом мы все умные. Для того что бы написать компилятор в 2008-м году — нужно в это было упороиться на 24/7. Я всё детство мечтал написать свой кошерный ассемблер и линкер, всё представлял как они работают. А потом подрос... и тупой однопроходник подружке написал за ночь (ессно далеко не идеальный), и по моему на C. Смог бы я это сделать, если бы не имел тугих дум о том, как оно устроено до этого? Конечно же — даже близко не смог бы. Но, так совпало, что на тот момент я хорошо знал и систему команд, и собственно говоря написать такую херотень не было проблемой. Смог бы я сейчас повторить такой подвиг? Да я сейяас даже за неделю не управлюсь, буду всё думать/подбирать "идеальные" решения. Ну в плане, сейчас, то смотришь на софт иначе — уже заранее знаешь узкие моменты и точки расширения, и как это должно быть, что бы это работало потом... А конечно, когда цель — сдать курсач — то требования иные.
Тем не менее — "переписать" готовый код — это означает его выбросить и написать что-то, что ведет себя похожым образом. Нужно ознакомиться алгоритмами в случае компилятора и т.п. Тем более комментариями код там не усеян, при чём комментариями — не xdoc, а нормальными комментариями, которыми *должен* сопровождаться любой код — которые объясняют "нахера эта херовина вообще нужна". Я много работаю с неизвестным кодом, в котором это есть, и это — приятно. И не приятно, когда там этого не описано. Например, в коде появляется какой-то свой тип строки (ага, C++) со своими характеристиками. Почему и зачем (мотивация) — если не описать — то ты никогда и не поймешь нахера оно было придумано, если не проведешь в коде достаточное число времени что бы извлечь эту информацию "естественным" образом. Я думаю, что с подобным — сталкивался каждый.
Безусловно, на сейчас — да, стоило его прям тогда переписывать.
Если есть чувство/понимание, что это тебе под силу — тогда бери и делай. Но я не думаю, что в реалиях у кого-то были такие силы в 2008-м, даже, если и думал, что они есть. Скорее наоборот, те кто ближе всех был вовлечен — понимали, что переписать запросто так не выйдет.
Это тоже самое как сказать, перепиши ты ка linq2db с ноля. Как считаешь сам, твой 10+ опыт в теме + контрибут (даже в виде фидбэка) — можно преодолеть лишь за счёт своей уникальности (ага, взял и переписал, я ж уникальный) и сделать (переписать) лучше?
А по нынешним меркам — я считаю вообще все языки кто не поддерживает ZST/VLT (Zero-Sized Types и Variable-Length Types) => ущербными. Кстати, привет, от Rust — ZST он умеет, про VLT не вкурсе. Отрадно видеть, что такие простые вещи реально воплощаются в жизнь, о которых я только думал в голове... 20 лет назад.
И вот тебе мой ответ — тратить силы на ущербный язык под дотнет в 2021 году — смысла вообще не имеет. В 2008-м году — это имело смысл. К сожалению, что бы кто бы не делал — было бы обречено на провал — МС бы выпустило свой "розлин" и все бы уткнулись в него всё равно. Ну, либо нужно было бы сделать язык который бы набрал популярность, организовать фонд, иметь реально плавные установки в любом случае, короче тянуть — все фичи которые только пользователи хотят (я имею ввиду по поводу установок). И то — это всё равно было бы обречено на провал, потому что в нашем мире ценят не только заслуги, но и имя. В данном случае — имени и не было, заслуги были польские, своих заслуг было прилично (исправление багов), но это всё. Нужна была аггрессивная популяризация, чем, сейчас пользуются абсолютно все, популизируя вещи которые вообще не стоят даже внимания... (я про новости, особенно от гугла, которые как бы даже таргетированы по интересам, и то в них — чушь!!!, а в избранных случаях — программисткая ересь!!! "why c++ is new python" ).
IT>2. По второму пункту тоже вроде так и есть на самом деле.
Синтаксис, как ниже уже сказали, особенно дженерики — конечно, однознчано да. Использование `<>` для шаблонов и/или дженериков — было уже фактически стандартом ещё тогда, в не таком уж и далеком 2008-м? году. Да и индексация в языках где нет параметров типов с `<>` — более чем часто всё таки через `[]`. Я не понимаю каким местом они вообще думали, что бы это было не так (я про поляков). Я в курсе, какую проблему они обошли, я в прошлом законтрибутил пару фиксов в компилятор (ничего существенного). Но, в месте с тем — да, меня это вымораживало. Единственное что спасало N — это то, что оно вроде прям не так уж часто надо было (хотя как сказать, объявляя совместимый с C# интерфейс — весьма наверное и часто), но всё равно — выглядит текст неправильно. Тут проддерживаю полностью.
IT>3. Нитра — это вторая большая толи ошибка, толи диверсия
Я не думаю что это ошибка вообще. Там проделана огромная работа, в том числе научная. Просто, я согласен, что Nitra — это не Nemerle 2. В добавок, генератор парсера (анализом не назову, т.к. они идут со своим уставом в чужой дом, при чём вееесьма опорометчиво) — это отлично конечно, но это как раз то, на что серьезный софт по факту не опирается. Не опирается оно всё по той простой причине, что модель предлагаемая в Nitra — совершенно правильная прям до одури правильная. А реальный мир работает в полу-иммутабельные объекты. Да просто невозможно осмысленно загрузить C++-модуль и не пропатчить что-нибудь... Увы и ах. Я уже не говорю о том, что всё что реально быстро работает — использует все биты, а не то как это устроено в дотнете (я про референсы, невозможность закодировать в ссылке — нессылочный "SMI", хотя младшие биты благодаря выравниванию позволяют). Почему-то clang умудряется кодировать модификатор const не тратя лишние байты. Почему-то V8 умудряется на x64 использовать 4-х байтовые ссылки на куче (с 9.1-9.2 версии, не помню точно), в которых опять же используется SMI. В Яве всегда был SMI. Это я к чему. Крутой инструмент — это хорошо. Но мне нужен компилятор, готовый компилировать код после "бутстрапа" OS, а не требовать сложный рантайм. Иначе говоря — нэйтив нужен. Было много инсинуаций про GC, но... как ни странно, в хроме вот есть GC, и сделан он на совершенно обычных C++ типах (имеется ввиду без поддержки компилятора). Тут речь не о соперничестве GC, — дотнетный тупо будет лучше. Тут речь о портабельности кода, и предсказуемости кода, особенно в нагрузке. Я не вижу смысла в генераторе неведомой хери, которая работает с неведомой херью (нитра-рантайм, F#-рантайм), и т.п. У вас или рабочий код с нормальный интерфейсом, или это можно выбрасывать. При чём, по полуярности проекта, видимо все решили около того как и я (выбросить и забыть нафиг, все мегамакросы заменяются генерацией кода и всё. Всё для чего годны были макросы — в C++ и так есть в виде старых макросов (ну не всё), а в C# их не было и нет — и хер с ними — жить можно).
Кстати, отдельный привет Source Generators — чудовищно неудобная хрень. Генерируйте пожалуйста код аккуратно в выходную (obj) директорию. На кой чёрт показывать исходники из temp? Сгенерированные исходники вдруг стали кем? Что, не частью билда? Идиоты. Я уже не говорю как это быстро у них шевелиться...
Именно поэтому абсолютно все *нормальные* проекты (на любых языках) — сначала тупо генерируют код, а потом его тупо компилируют. Явные зависимости... и он часть билда, и его можно проанализировать, и к нему переходят любые стандартные тулзы (IDE) и не только... Это тупо покрывает 99% потребностей. Не, если бы в C# сделали бы реврайтинг кода — тогда дааа... и то, весь реврайт стоило бы ожидать в obj. Но мир альтернативно одарённых людей — он именно такой и есть, каким мы его видим. А именно — ни системных кнопок, ни вкуса дизайна, ни настроек, всё перекособоченное, и миллион пустых папок в temp потому что их за собой та же студия не чистит.
Простите, отвлекся.
IT>4. Писать свою IDE — это бред, да.
Для разработчика языка и языкового серивса — однозначно да.
А если у Колёсиков цель — сделать нормальный редактор... (а он возмущался про VS и VSCode — и тут я должен с ним согласиться — это хрень господня... VS не умеет правильно из клипборда вставлять, вечно концы строк ломает) — то соглашусь. Если ставить вопрос сделать НОРМАЛЬНЫЙ редактор — можно смело писать свой. Есть масса хороших готовых, но хорошие ли они... оооо, это вопрос. Windows Terminal к примеру вполе себе позволял до недавнего времени аллоцировать кусочки строчек из VT-последовательностей. Ну и в целом весьма не быстр. Ведь парсинг это очень сложно. Рендеринг терминала — это "очень" сложно. Это сложно технически, но задача решенная раз так 50.
Более того — действительно, почти все языки имеют свою IDE. Легковесную. На основе чего-нибудь. Сейчас — можно на основе VSCode забабахать вполне что-то прикольное, конечно, если смириться с тем, что там всё альтернативно-одарённое. Ну... начиная с того, что иконка в верхнем-левом углу есть — но тыкать на неё безползено — системного меня почему-то там нет. Апи виртуальной файловой системы... построено на URI. Идиотам неведомо, что такое увидеть 200К ресурсов сразу. А не дайбог это файл реальной файловой системы — с этим ури что потом делать? Правильно — нормализовать к физическому. А что такое физичесйкий путь? Это то, что делает дотент, хочешь ты или нет — \\?\C:\... (вроде и длинные имена есть, вроде и не дурак, зато без просу тебе аллоцируют объекты просто так...). А проблему в VSCode с "открыть всё дерево" решили очень просто — этой функции — просто нет. Т.е. люди не изобретали там виртуальных списоков или ещё что. Просто, — это не нужно. Нафиг. Сказали что это просто не нужно. Вот типа это не нужно, потому что это не нужно. И поэтому этой функции нет. Но если у тебя в дереве 30 файлов всего, удобно всё открыть. А функции — нет. Опять же — ума сделать нормальное окно конфигурации общих опций — не хватило (например как в студии, или в ворде). Берите json и редактируйте... это же так хакеры делают, правда?! Спасибо, очень удобно.
Ну +/- все редакторы такие — но при этом, эта хрень нормально шевелится, как и другие в общем-то неплохо. Сейчас есть что выбрать за основу, не нужно делать прям с ноля, как поступали хардкорные среды вокруг того же шарпа. Но вместе с тем... положа руку на сердце, быстрее сделать гораздо лучше и самому, вместо того что бы копошиться в их говне.
Так что Колёсики тут прав, по части редактора.
IT>5. Всё верно. Вхождение в проект должно быть простым и быстрым. А там сейчас без консультаций специалистов никак.
Если речь про сборку — то, да, в среднем всё должно билдится 1-2 вызовами скриптов. Ну по крайней мере такой проект — точно это можно делать без диких приседаний. Ему точно не нужно из кармана доставать специальные тулзы для чекаута, что в некоторых проектах — используется — и обоснованно. В принципе для open-source проекта сейчас — либо солюшн должен билдится вызовом `dotnet build` — либо вызовом build.cmd/.sh. В целом, удивительно, но другие компиляторы умудряются в это вкладываться (CMake+build -> для clang более чем достаточно на любой платформе, конечно пререквизиты надо выполнить, но они как бы есть те или иные у всех).
IT>Ну и я бы добавил, что начинать нужно даже не с компилятора, а с переименования языка. Пусть Немерле останется языком, который придумали польские студенты. Они молодцы.
Поддерживаю. Они не только молодцы — но они поматросили и бросили. Не вижу причин записывать им плюс в карму за счёт чужого труда.
Здравствуйте, Mystic Artifact, Вы писали:
IT>>1. Компилятор действительно представляет собой кучу говна. То, что его не начали переписывать ещё в 2008-м наверное самая большая ошибка. MA> И да и нет. Его никто не начал переписывать в 2008-м потому, потому, что сейчас, задним числом мы все умные. Для того что бы написать компилятор в 2008-м году — нужно в это было упороиться на 24/7.
Влад и так занимался N практически 24/7. После того как мы не договорились я занялся поддержкой LINQ в bltoolkit, тоже практически 24/7. Речь шла о том, что на это уйдёт аж ЦЕЛЫЙ ГОД! Прошло 13 лет.
MA> Тем не менее — "переписать" готовый код — это означает его выбросить и написать что-то, что ведет себя похожым образом.
Когда я говорю переписать, то никогда не имею ввиду всё выкинуть и переписать заново. Любой код, даже самый фу, можно творчески переработать и переиспользовать. Любой код состоит из алгоритмов и их компоновки. Вот последнее в N было троечку с минусом, это нужно было полностью переписать. А алгоритмы можно было легко переисользовать.
MA> Если есть чувство/понимание, что это тебе под силу — тогда бери и делай. Но я не думаю, что в реалиях у кого-то были такие силы в 2008-м, даже, если и думал, что они есть. Скорее наоборот, те кто ближе всех был вовлечен — понимали, что переписать запросто так не выйдет.
Запросто и не надо. Там проблема была в другом. Влад считал, что вот ещё чуть-чуть, вот здесь переписать, тут подрехтовать и всё заработает, баги прекратятся. У меня было понимание того, что без тотальной переделки компилятора ничего не выйдет. Это бесконечный бег по кругу от одного бага к другому. Нужно остановиться и начать с переработки архитектуры компилятора, тем более, что понимание какой она должна быть к тому моменту уже присутствовало.
MA> Это тоже самое как сказать, перепиши ты ка linq2db с ноля. Как считаешь сам, твой 10+ опыт в теме + контрибут (даже в виде фидбэка) — можно преодолеть лишь за счёт своей уникальности (ага, взял и переписал, я ж уникальный) и сделать (переписать) лучше?
linq2db переписывался с нуля много раз. Может быть именно поэтому последние лет 8 он в этом не нуждается. Сначала это был примитивный маппер — RFD. Затем оно было переработано в bltoolkit по схеме, описанной выше — перерабатывается архитектура, переиспользуются алгоритмы. Потом туда был добавлен linq. Потом, всё что касается linq было вынесено в linq2db опять по вышеописанной схеме.
Т.е. как раз linq2db является отличным примером того, что переписывать "с нуля" можно и нужно.
MA> И вот тебе мой ответ — тратить силы на ущербный язык под дотнет в 2021 году — смысла вообще не имеет.
Я бы не был таким категоричным. Думаю, бесмысленность затеи не в том, что нет смысла писать язык, а в том, что это всё опять упрётся в персоналии и в то, что использовать — табы или пробелы.
IT>>3. Нитра — это вторая большая толи ошибка, толи диверсия MA> Я не думаю что это ошибка вообще.
Это — ошибка. Но не сама по себе Нитра. С этим я не спорю. Это хороший проект, особенно как исследовательский. Ошибка в том, что работа над ней поставила жирную точку в работе над компилятором. Вспомни что было в 2012 году.
— JB берёт под своё крыло N.
— Воплощаются мечты и чаяния народа. Какая радость, скоро у нас появится безглючный компилатор и интеграция со студией.
— Туманные сообщения о закрытии кода, какой-то секретный проект...
— Через пару лет выясняется, что работы ведутся не над компилятором, а над каким-то всемогутором.
Далее следует полное разочарование. Проект больше нафиг никому не нужен. Даже JB от него отказывается и открывает коды всемогутера. Лично у меня вообще возникло ощущение, что парнями попользовались и выкинули нахрен.
Результат затеи — развитие компилятора заканчивается раз и навсегда.
MA>Простите, отвлекся.
IT>>4. Писать свою IDE — это бред, да. MA> Для разработчика языка и языкового серивса — однозначно да.
Именно это я и имел ввиду. Разрабаывать что угодно в рамках отдельного проекта — это без проблем.
IT>>Ну и я бы добавил, что начинать нужно даже не с компилятора, а с переименования языка. Пусть Немерле останется языком, который придумали польские студенты. Они молодцы. MA> Поддерживаю. Они не только молодцы — но они поматросили и бросили. Не вижу причин записывать им плюс в карму за счёт чужого труда.
Именно. А трупик Немерле лучше закопать и оставить его в покое.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Именно. А трупик Немерле лучше закопать и оставить его в покое.
Ну зачем? Именно название замечательное. гуглится на ура.
вот например dlang пролетел. гугла автоматом корректирует на golang
И да, раз вспомнил про D, глянул и офигел:
у них уже и варианты завелись https://dlang.org/library/std/sumtype/sum_type.html
и аналог genericmethod из лиспа в виде внешнего модуля.
и vscode отличная поддержка. неплохой кандидат на замену.
Тот самый вожделенный нэйтив.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Kolesiki, Вы писали:
K>>На мой взгляд, ребята порвали ширинку, прыгая через несколько ступенек. Причём прыгая с весьма ветхой базы.
IT>После перехода под крыло JB там ещё наблюдался и явный разрыв с реальностью. Ребята полетели в далёкие дали, далеко впереди паровоза и не заметили как то ли они не туда свернули, то ли паровоз свернул и скрылся из вида. А они остались нафик никому не нужны. Все уехали на паровозе.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, DarthSidius, Вы писали:
DS>>Так и чо, куда делся Влад?
IT>В смысле? Вообще куда делся? Где-то тут в политике бродит...
Здравствуйте, IT, Вы писали:
IT>Это — ошибка. Но не сама по себе Нитра. С этим я не спорю. Это хороший проект, особенно как исследовательский. Ошибка в том, что работа над ней поставила жирную точку в работе над компилятором. Вспомни что было в 2012 году.
IMXO ошибка была в том, что для Нитры был использован N1, а не более менее индустриальный или даже полу-индустриальный язык. Сам N1 на тот момент уже не представлял ценности. Например на Скале уже были N1 макросы, a все остальное (баги, поддержка IDE, сообщество) было лучше на порядок. В результате N даже в JB было некуда воткнуть, кроме решарпера, а там овчинка просто не не стоила выделки.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, varenikAA, Вы писали:
AA>>Кстати, обнаружил вчера что irdis 2 реализован на Racket ЯП для разработки других ЯП. Комунити у них чуть больще чем у немерла/нитры.
N>В Julia тоже парсер написан на схеме(https://github.com/JeffBezanson/femtolisp).
Проблема сабжа в том что платформа донет очень сложна из-за своей закрытости,
взять тот же кложуре. легко взять jdk абсолютно любую, качнуть mvn и собрать clojure из исходников.
а вот дотнет сам по себе так сложен, что выход за пределы оф поддерживаемых ЯП(C#, F#) это уже занятие для мазохистов.
по-крайней мере нигде такой запутанной системы сборки не видел.
Здравствуйте, IT, Вы писали:
IT>Влад и так занимался N практически 24/7. После того как мы не договорились я занялся поддержкой LINQ в bltoolkit, тоже практически 24/7. Речь шла о том, что на это уйдёт аж ЦЕЛЫЙ ГОД! Прошло 13 лет.
Владу надоело заниматься всем одному и для себя. Вот в Касперском Немерл и Нитра применяются. К сожалению, там вечная гонка за елизами и трендами, так что на развитие оных времени почти не остается.
Тем не менее мы перевели компилятор немерла на dlLib, что позволило компилировать им под любую платформу. А вы тут так и занимаетесь сотрясением воздуха.
За это время я с Хадкейом сбацали на Нитре ДСЛ, который по сложности даст фору C#. Нитра уже средство для создания языков. Но нужны не трепачи, а соратники.
Проекты по созданию таких языков как Немерл и Нитра очень трудоемки. Взрослая система должна не просто работать, а позволять работать с проектами большого объема. На сегодня в одном только проекте KavKis 1500 файлов .tdl (DSL-я тестирования) общим объемом 10 мегабайт (а проектов в конторе не один). К сожалению, текущая реализация Нитры не хило так втыкает при его компиляции и особенно при редактировании. Нужна инкрементальность при редактировании. Да и оптимизации. Архитектурно вопрос решаемый. Решение в общем-то есть. Но написать его очень не просто. Нужно реализовать нечто вроде Хаскеле (ленивые вычисления для типизации). Парсер у нас мощный, но не очень быстрый. Опят таки понятно как это улучшить. Но нужны руки и время. А это деньги и не малые, так как класс программистов нужен очень высокий.
По факту нужна команда человек из 5-10 и несколько лет фултайм разработки.
Весь этот треп о том что надо делать ни к чему не приведет, так как банально никто ничего делать не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
).
