Re[5]: Nemerle через 10 лет
От: Mystic Artifact  
Дата: 16.07.21 23:23
Оценка: 9 (1)
Здравствуйте, IT, Вы писали:

Игорь, спасибо за обстоятельный ответ. Я заранее извиняюсь, если местами буду отодвигаться от темы.

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>Ну и я бы добавил, что начинать нужно даже не с компилятора, а с переименования языка. Пусть Немерле останется языком, который придумали польские студенты. Они молодцы.

Поддерживаю. Они не только молодцы — но они поматросили и бросили. Не вижу причин записывать им плюс в карму за счёт чужого труда.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.