Re[6]: [Nitra] Почему клинт-сервер?
От: Kolesiki  
Дата: 11.01.18 17:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Предпринимаю последнюю попытку объяснить предпосылки и показать как делается выбор.


Ну, раз прошлогодние попытки закончились, начнём с новогодних! Попробуем всем лесом объяснить медведю, что бить улей о дерево — не лучший способ добычи мёда.

VD>Нам нужно создать универсальное решение позволяющее с минимумом затрат создавать IDE-плагины для языков разрабатываемые на базе Nitra.


Вообще не о том. Влад, посмотри на Нитру извне капсулы "компилятор как хобби": ты делаешь даже не язык, а только конструктор языков — это настолько узкоспециализированная вещь, что даже на RSDN (старейший ресурс) у тебя не найдётся и 5 достаточно квалифицированных помощников, чтобы двигать проект. Ты уже убедился — перделки пилят сотни опенсорсников, Нитру — Влад, да его эго. Я к тому, что Немерля-2 не существует даже на бумаге, а ты уже решил, что кому-то в ИТ мире понадобится конопатиться — писать плагин!

Ещё мысль: вряд ли Немерля, будь она четырежды лучше Жабосипипей, вылезет за пределы дотнета. Ориентироваться на то, что какой-то больной маковод начнёт пилить плагин для ХэКоде — зря распалять абстракции. Прими программу-оптимум: переписать "начисто" Немерлю и самому написать плагин под Студию или любой другой дотнетный редактор/ИДЕ. С таким намного более реальным планом, ты куда раньше выйдешь на уровень "не стыдно показать" и куда быстрее найдёшь ребят, способных улучшать проект. Плагины — не самоцель. Даже если ты тупо возьмёшь FastColoredTextBox и прикрутишь к нему компилер, это уже будет что-то сносное для популяризации языка. А замахиваться на Шекспира — можно и портмоне порвать.


VD>Какие цели мы имеем?

VD>1. Многоплатформность и переносимость.

Никогда ею не была. Посмотри на этих калек — GTk, Qt, Xamarin, Delphi, vxWidgets — чем шире они пытались сесть на все платформы, тем ужаснее выглядели их попытки. На каждой платформе есть не просто Look, а Look'n'Feel — почувствуй вторую составляющую! Пока ты не напишешь нативного rich клиента, приложение будет чужеродным джамшутом в попытке мимикрировать под платформу.
Нет универсальных комбинезонов для Турции и Антарктиды — есть шубы и есть халаты. Или наоборот. Прими одну платформу как единственно правильную и используй все её преимущества. Например, если Немерля будет отдельно иметь парсер как DLL, практически любой проект может её тупо "зареференсить" и использовать в полный рост.

VD>2. Поддержка VS с его 32-битностью.


Никогда ею не была. Просто есть монстр на тухлых технологиях, который хорош только пока его вылизывают тысяча индусских чертей. Более того — 2017-ая версия уже показала полную деградацию процесса — с таким качеством я тем более буду сторониться этого поделия. Вторая дыра VS — это чрезмерные затраты между написанным кодом (те ещё простыни!) и результатом. Слишком абстрактные абстракции в этой ИДЕ, чтобы быть полезной.


VD>У VS есть особенность — она 32-битная. Это значит, что адресное пространство у нас ограничено.


Оно так "ограничено", что за 10 лет я не компилял ни одного проекта, которому нехватило бы памяти! А если такие проекты и есть, то как инженер, ты должен понимать — это помойка, а не "проект" и нуждается в декомпозиции.


VD>3. Надежность.


Аналогия: давайте, чтобы человек не "смялся" при аварии, он будет не в авто, а бежать рядом! Казалось бы, боремся за одно и то же, но почему таким смешным способом?? Просто повысь квалификацию, Люк! Используй решарпер, PVS Studio, исключения, что угодно — это ничего не стоит в плане производительности! Но это куда удобнее, чем уповать на рестарт зависшего парсера. Таких ошибок вообще не должно быть.


VD>4. Многопоточность.


То же, что и с "надёжность" — никакой связи с твоим решением. Нужны нити — бери и создавай, к чему отдельный процесс?


VD>5. Чистота API.


Тот же ответ, что про надёжность: повышай квалификацию. Если ты понимаешь взаимосвязи, если грамотно умеешь разделять модули, у тебя просто в принципе не будет никаких "хаков". Более того — "чистота" тебе нужна в единственном месте — в разрыве цепочки "AST->Code generation". После фазы AST ты можешь брать результат и подсвечивать его в любом редакторе и этот модуль (всё до фазы AST) должен быть отдельной библиотекой. Как только ты его напишешь, сам увидишь — дальше него никакие "кишки" не пролезут.


VD>6. Web-интерфейс.


Хипстота, забудь. Куда правильнее написать грамотный инсталлер, после которого не нужно лазить по ИДЕ и "конфигурить конфигурации"! *громадный такой ком г***на в разрабов IDEA* — вот уж где тупая посредственность ничего не понимает в "продвижении продукта".


VD>

Поиск решения


Да не... скорее "придумывание целей для оправдания решения". Явно же видно, что эти "цели" вообще фиолетовы основному проекту.


VD>Мне кажется, что теперь я разжевал все до мелочей.


Заблуждений повторение к истине не ведёт тебя! Шторы сними с разума своего, спокоен будь хайпа среди — тёмная сила движет Майкрософтом, очень тёмная — годами не мытая, но танцующая! кхе-кхе...

Влад, есть такая вещь — "техническое чутьё". Оттуда же "всё гениальное — просто" и "некрасивый самолёт не полетит". Так вот, твоё решение — "некрасивое", слишком амбициозное и абстрактное, сложное и вычурное. Оно "красиво" только в виде воздушных замков и квадратиков на бумаге, но практическое воплощение сразу зарывается по рога в землю — потому что непосильно писать всемогутеры одному, будь ты хоть трижды "академик компиляторов".

Напиши Немерле-2 на Немерле-1 (попутно устраняя серьёзные проблемы в "1"). Затем за неделю пишется тупейшая IDE с проектом и редакторами, чего за глаза хватит 99% новичков, а там уже и на Шекспира замахнёмся! Это реальный план и чётко ощутимые шаги.

С Новым Годом!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.