Здравствуйте, VladD2, Вы писали:

VD>Написал еще кучу текста в ответ, а потом поймал себя на слове, что трачу время впустую.

Поймал себя на МЫСЛИ. Потому что ты слишком умный, чтобы быть полезным. Буквально сегодня получил преинтереснейший список того, почему умники не преуспевают: https://vc.ru/30773-kak-intellekt-meshaet-dobitsya-uspeha — вот не поленись, прочти! (хотя бы ради эрудиции, а если повезёт — примерь на себя)

Понимаешь, от того, что ты вращаешься где-то в котелке своих идей, не делает тебя прозорливым мудрецом. Человек, 50 лет программирующий на Фортране, не становится гуру ИТ. "На жизнь надо смотреть ширше, а к людям — мяхше!". Нас — много и поверь, наш суммарный опыт больше твоего. Даже когда наш опыт конкретно в компиляторостроении меньше твоего, есть области (да и просто проф.чутьё), которыми ты не обладаешь. И даже не желаешь слушать.

Я понимаю твою главную идею — отвязаться от всего и вся, чтобы можно было легко интегрироваться и адаптироваться под любые запросы и платформы. Идея — здравая, но ты смотришь на неё чисто академически, наивно считая, что достаточно сделать какой-то абстрактный суперсервис, как "набигут домики" с программистами и все начнут юзать Нитру. ДАЛЕКО НЕ.
Посмотри на пример Ди — куда успешнее в плане реализации, там есть много чего — от самого компилятора "скачай и юзай", до IDE и библиотек на любой вкус. И те ЕДВА ДВИГАЮТСЯ, толкая в задницы всякое околоайтишное ***овно, которое выдумывает тысячи отмазок, лишь бы не брать и писать на этом бесспорно перспективном языке.
Это я к тому, что даже если кто-то потратит время для интеграции твоего детища в какой-нть говноVIM, успеха это не принесёт. Людям не нужны абстрактные языки — людям нужна конкретная платформа для конкретных приложений. Вот те же JVM+Kotlin — это конкретный язык, на котором можно писать под конкретную платформу. Никаких космический абстракций, портирования на мобилы или ещё каких несуразностей. И поверь, эта связка куда успешнее (в мире JVM, конечно), чем всеплатформенная Нитра. В твоём случае всё, что ты должен предоставить — это компилятор, IDE(VS) и .NET -- вот эта связка и имеет право называться "решением".
Не нравится VS — я давно говорил, выкинь её нафиг и напиши свою. Тем более, что 99% редактирования заключается в хайлайте и интеллисенсе — т.е. большая часть "суперфич" VS (со всеми их дебильными интерфейсами и неуклюжим API) просто нафик не нужна. И к слову, если ты выставляешь некий API компилятора, практически неважно, какой редактор над этим висит (если он под .NET, конечно — главная и единственная target твоего компилятора).

А касательно акторов... да чем ты их ни назови, это всё равно НЕНУЖНЫЙ транспорт между редактором и компилятором. Смоллток тоже в своё время хвалился суперабстракцией сообщений — ну так и остался сидеть как слива в ... академических кругах. Нет ничего быстрее, чем вызов и возврат значений. А быстрота тебе понадобится, т.к. .NET за долгие годы так и не научился делать оптимальный код, несмотря даже на урезанный набор инструкций VM.

Короче, моё видение успеха: самописная IDE + переписанный Nemerle (а не всемогутер Nitra) + .NET(Win). Это решение куда реалистичнее и ничуть не ограничивает любого дотнетчика (а остальные всё равно не смогут юзать Нитру без дотнета).

Здравствуйте, VladD2, Вы писали:

VD> Причем есть люди которым не нужен дотнет. А другие не хотят иметь дел с MS VS.

эээ... если им не нужен .NET, УЖЕ есть мульён альтернатив, к чему этим маргиналам Нитра??
А студия — да, я тоже с ней дела иметь не хочу Bloatware на устаревших технологиях. НО ДРУГИЕ — ЕЩЁ ХУЖЕ!! Думаю, ты согласишься, на фоне всяких Netbeans, Code::blocks и даже Rider, студия — лучшее из всего (внешне и в работе). Тем не менее, полноценная, гибкая и удобная IDE ещё никем не сделана, так что ниша свободна.

Здравствуйте, Pzz, Вы писали:

Pzz>А почему не наоборот? Я бы сделал имя именованного канала фиксированным, и пусть сервер его "слушает", а клиенты к нему коннектятся по мере надобности.

Потому что каждый экземпляр Студии должен общаться со своим экземпляром сервера. Плюс для поддержки разных языков могут разные серверы загружаться.

Pzz>Тогда если сервер отвалится, клиент может попробовать присоединиться еще один раз, и сделать несколько попыток с разумными интервалами, в течении разумного времени.

Если сервер отвалился, он сдох и его надо перезапускать. Как я уже сказал — это просто не сделано. Но надо будет сделать.

Pzz>Я бы сделал ответ всегда, пусть пустой, чтобы клиент как минимум знал, что его письмо достигло адресата.

Так и предполагалось. Но люди не безгрешны. Иногда делают ошибки. Полетело исключение и выход случился в незапланированном месте. Сейчас это исправлено, а количество псевдо-синхронных сообщений минимизировано.

Но факт остается фактом. Несоблюдение протокола может оказаться фатальным. На это надо рассчитывать.

Pzz>И сделал бы с серверной стороны некоторый общий уровень, который распаковывает и проверяет запрос, вызывает соответствующую функцию, запаковывает ответ, if any, и отправляет взад.

Я уже раза три сказал о том, что с распаковкой и запаковкой проблем нет. Этот код генерируется макросом. Но код обработки месаг может содержать ошибки.

Pzz>А парсеру от МС вообще безопасно подсовывать неизвестно откуда взявшийся ХМЛ?

Что значит неизвестно откуда взятый? Он известно откуда взятый. Сервер субъект доверительный. Просто парсер от МС своеобразно на ошибки реагирует, а на это никто не заложился. Ну, а ошибки получаются сами собой.

Pzz>Не получится так, что ты создаешь дыру в защите? Я б не очень доверял по умолчанию парсеру от МС, честно говоря.

Не от чего там защищаться. Студия это процесс который кому попало доверять не стоит. Любой экстеншен может содержать вредоносный код. Сервер запускается с теми же привилегиями. Так что сделать больше чем сама Студия он не может.

Здравствуйте, VladD2, Вы писали:

WH>>На HTTP нельзя. Там на каждый запрос нужен ответ. Причем сторого в той последовательности в которой были отправлены запросы.
VD>Ну, вот в VS Code как-то сделано. Многие интеграции через него работают.
Скорей всего они делают бесконечный пост, на который идёт бесконечный ответ.
Те от HTTP там ничего кроме заголовка в начале не остаётся.
И для того чтобы провернуть такой фокус нужно, как и в случае с консолью, научится пропускать все сообщения через один поток. Те большая часть работы общая.
Ну либо у них тупо RPC.

VD>Ты вот за генерацию кода парсера брался. Что-нибудь сделал?
Нет. Занимался другими делами.
Если хочешь у меня что-то спросить для этого есть скайп.
Что за дурацкая привычка на форуме личные вопросы задавать.

Здравствуйте, WolfHound, Вы писали:

WH>Скорей всего они делают бесконечный пост, на который идёт бесконечный ответ.
WH>Те от HTTP там ничего кроме заголовка в начале не остаётся.
WH>И для того чтобы провернуть такой фокус нужно, как и в случае с консолью, научится пропускать все сообщения через один поток. Те большая часть работы общая.
WH>Ну либо у них тупо RPC.

Ну, вот и надо разобраться, что там и как. Только на это время нужно. А его нет.

VD>>Ты вот за генерацию кода парсера брался. Что-нибудь сделал?
WH>Нет. Занимался другими делами.

Вот видишь, у тебя на первостепенные задачи времени нет, а ты предлагаешь заняться не пойми чем не ясно зачем. Сервер отлично работает и так. Других дел — море.

WH>Если хочешь у меня что-то спросить для этого есть скайп.
WH>Что за дурацкая привычка на форуме личные вопросы задавать.

Что за дурацкая привычка предлагать заняться какой-то херней? Хочешь — берись и делай. А у меня более важных дел на год вперед.

Мне помощь реальная нужна, а не абстрактные идеи. Вот задачи которые нужно делать в первую очерадь:
1. Генерация кода по новым символам.
2. Инкрементальный парсинг.
3. Реализация Nemerle 2 на новым движке (его сабсэта для бутстрапинга).

А все остальное меня пока вообще не интересует.

Здравствуйте, VladD2, Вы писали:

VD>Вот видишь, у тебя на первостепенные задачи времени нет, а ты предлагаешь заняться не пойми чем не ясно зачем. Сервер отлично работает и так. Других дел — море.
Где я предлагал что-то делать?
Я сказал можно сделать.
Я ни разу не сказал, что нужно.
И тем более нужно прямо сейчас.

Ты постоянно что-то себе фантазируешь и на это обижаешься.

Здравствуйте, WolfHound, Вы писали:

WH>Где я предлагал что-то делать?

А это

Автор: WolfHound
Дата: 20.12.17

ты начал, чтобы разговор поддержать?

WH>Я сказал можно сделать.

Количество того что можно сделать стремится к бесконечности. Если все обсуждать, то делом заниматься будет некогда. Я предполагаю, что если кто-то, что-то предлагает, то это предлагается сделать, а не просто потрепаться.

Здравствуйте, VladD2, Вы писали:

С>>Можно было ответить одной фразой "это Unix-way". Самое универсальное это именно взаимодействие процессов, поддерживаю такой выбор.

VD>Это не совсем UNIX-way. Все же наш сервер это многопоточное, асинхронное приложение. Каналы в нем используются для интерактивного общения через модель акторов.

ОК. Plan9 way.

Здравствуйте, WolfHound, Вы писали:

WH>На HTTP нельзя. Там на каждый запрос нужен ответ. Причем сторого в той последовательности в которой были отправлены запросы.

Говорят, в HTTP/2 это починили.

Сейчас все прогрессивные IDE на клиент-серверную модель переходят. Microsoft даже спеку сделала для протокола такого взаимодействия https://github.com/Microsoft/language-server-protocol
Интеграцию с той же Visual Studio Code можно сделать *только* таким образом (ну или написать свой движок разбора всего и вся целиком на жаваскрипте).

Здравствуйте, kekekeks, Вы писали:

K>Сейчас все прогрессивные IDE на клиент-серверную модель переходят. Microsoft даже спеку сделала для протокола такого взаимодействия https://github.com/Microsoft/language-server-protocol

Они не переходят, они изначально так сделаны. И не от хорошей жизни. Зачем в Нитре повторять то, что сделано из-за ограничений Electron'а?

K>Интеграцию с той же Visual Studio Code можно сделать *только* таким образом (ну или написать свой движок разбора всего и вся целиком на жаваскрипте).

Вот-вот. У Нитры внутри клиент-сервер со своим протоколом, для общения с Code'ом клиент-сервер со своим протоколом. И это считается нормальным

Здравствуйте, _Raz_, Вы писали:

_R_>Они не переходят, они изначально так сделаны. И не от хорошей жизни. Зачем в Нитре повторять то, что сделано из-за ограничений Electron'а?

Причин было описано овер дофига. Но кто-то уперся и не хочет мыслить здраво. Одна из причин — возможность поддержки любых IDE при относительно небольших трудозатратах.

_R_>Вот-вот. У Нитры внутри клиент-сервер со своим протоколом, для общения с Code'ом клиент-сервер со своим протоколом. И это считается нормальным

Реализовать протокол (что наш в Code, что Code-овский у нас) несоизмеримо проще нежели создать полную интеграцию. Причем в случае с Code других то путей особо и нет.

Как бы приговором была уже проблема с адресным пространством 32-битной студии (а другой нет). Все остальное — приятные дополнения. Уже одно то, что интеграция может падать от переполнения памяти на больших проектах вынуждает выбирать этот путь.

А главная не ясна ваша упертость. Вы с какой-то остервенелостью отстаиваете совершенно не конструктивную позицию. Что плохого то в клиент-серверной организации? Чем она может помешать то?

В общем, ребят извините, но вы реально не умеете стратегически мыслить.

Здравствуйте, VladD2, Вы писали:

VD>Причин было описано овер дофига. Но кто-то уперся и не хочет мыслить здраво. Одна из причин — возможность поддержки любых IDE при относительно небольших трудозатратах.

Ну вот ты реально только на первые части фраз внимание обращаешь? Как твой ответ про мою упертость и поддержку ИДЕ в Нитре, связана с "Зачем в Нитре повторять то, что сделано из-за ограничений Electron'а?"

VD>А главная не ясна ваша упертость. Вы с какой-то остервенелостью [...]
VD>В общем, ребят извините, но вы реально не умеете стратегически мыслить.

Спасибо за ответ.

Здравствуйте, _Raz_, Вы писали:

_R_>Ну вот ты реально только на первые части фраз внимание обращаешь? Как твой ответ про мою упертость и поддержку ИДЕ в Нитре, связана с "Зачем в Нитре повторять то, что сделано из-за ограничений Electron'а?"

Вот из чего сделан вывод, что сделано "как где-то" или "из-за ограничений Electron-а"?

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

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

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

Цели

1. Многоплатформность и переносимость. Одна из целей Nitra позволить в будущем создавать переносимые решения. На разных платформах имеются разные IDE API которых координально отличаются. Более того у этих IDE отличаются и программные платформы API. Это может быть .Net (для VS и SharpDevelop), Tipe Script/Java Script (для VS Code), Java (для IDEA, Eclipse, NetBeans и еще более 50-и) и нативные API для кучи других IDE.

Сейчас мы реализовывать движки для всех этих IDE не будем, но нам надо принять дизайнерское решение упрощающее эту задачу в будущем.

2. Поддержка VS с его 32-битностью. Приоритетной IDE для нас является VS (Microsoft Visual Studio) хотя бы потому, что мы сами ее используем и это основная IDE для .Net-разработки.

У VS есть особенность — она 32-битная. Это значит, что адресное пространство у нас ограничено. В это пространство грузятся интеграции ко всем языкам (включая огромный Разор для C#), а так же плагины вроде ReSharper, которые сами по себе могут отъедать всю память (все адресное пространство) в процессе.

3. Надежность. Nitra — это исходно расширяемая среда. Мы проектируем ее в расчета на то, что когда-нибудь она может быть перенесена на другие платформы. Среди платформ могут быть и небезопасные нативные платформы на основе LLVM или генерации С-кода. Пользовательские расширения могут содержать баги. Застраховаться от вылетов в режиме разработки мы не можем. Но нам нужно как-то защитить код от повреждений в случае некорректной работы пользовательских расширений.

4. Многопоточность. Мы хотим получать преимущества от наличия нескольких процессоров в одной системе. Их число постоянно растет и хотелось бы создать решение, которое будет хорошо масштабироваться. Стало быть мы хотим использовать в IDE-движке и компиляторах многопоточность. При этом наша задача добиться максимального контроля над многопоточной обработкой и при этом не очень пере усложнять код. Использование ручных блокировок, разных async/await-ов хотя и упрощает задачу, но не уберегает от ошибок. Нам же желательно иметь решение, которое было бы сравнимо с однопоточной разработкой по простате, но давало бы нам преимущества многопоточной обработки.

5. Чистота API. Мы хотим добиться максимальной чистоты API нашего движка IDE: четкого отделения движка (по сути являющегося контроллером) от представления, наличия четких мест общения движка с IDE, минимизации API, гарантии того, минимальной связанности движка и внешнего года.

6. Web-интерфейс. Для продвижения языков, да и самой Nitra, нам выгодно реализовать в будущем вариант работы через Web. В идеале мы должны предоставлять простенькую микро-IDE позволяющую человеку не устанавливая ничего на своей машине поиграться с Nitra или любым языком созданным на базе Nitra.

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

Далее мы начинаем искать решение удовлетворяющее всем этим условиям. При поиске мы обращаем внимание на решения имеющиеся у других разработчиков. Находим, что значительная часть этих решений мигрирует к клиент-серверному подхода. Пробуем понять почему это так и приходим к выводу о том, что клиент-срверное решение (в купе с реализацией многопоточности на базе системы акторов) позволяет (потенциально) достичь всех наших целей.

Реализуя многопоточность на основе передачи событий и обработки очередей в разных потоках мы избавляемся от необходимости явной синхронизации. Вместо этого мы вводим синхронизирующий монопольный поток, который осуществляет все операции, которые нужно делать синхронно. Он получает сообщения от рабочих потоков и передает сообщения им же. Передача эта осуществляется асинхронно и не требует явных блокировок. Все что нужно сделать, чтобы сообщения можно было передавать из других процессов — это создать систему сериализации сообщений. Учитывая требование кросплатформности и переносимости сериализация должна быть осуществлена или какими-то кросплатформными средствам (не дотнет-ными), или прямо нами. Я выбрал ручную бинарную сериализацию на основе макросов. Возможно я сделал не самый правильный выбор. Сейчас я склоняюсь к тому, что вместо бинарной сераилизации лучше было сделать сериализацию в JSON или XML. В прочем, это не сложно будет переделать в будущем, когда дойдут руки. Все что для этого нужно сделать — переписать макрос серилизации.

Теперь берем каждую из целей и задаемся вопросом реализуем ли она в виде внутри-процессной библиотеки? Уже на вопросе о 32-битном адресном пространстве мы получаем отрицательный ответ. Ряд других целей хотя теоретически и достижимы при реализации в виде внутри-процессной библиотеки, но могут потребовать написания кучи кода для обхода проблем.

Далее проверяем насколько легко достигаются эти цели при выборе клиент-серверной реализации. Оказывается, что все они не только достигаются, но и достигаются проще нежели при выборе внутри-процессного решения. Особенно хорошо на клиент-сервер ложатся пункты 2, 3 и 6. 32-битность не помеха.

Даже в 32-битной системе движок Нитры будут иметь собственное адресное пространство не конфликтующее с движками других языков.

Надежность у такого решения выше, так как даже фатальных сбоях вроде: порчи памяти, переполнения стэка или переполнения памяти можно будет тупо срубить весь процесс и запустить его вновь.

Работа через Веб сама по себе является клиент-серверным решением, что ложится на выбранный подход 1 в 1.

Остается проверить остальные пункты.

Многопоточность, будучи реализованная на базе модели акторов, прозрачным образом масштабируется с локальной на межпроцессную и даже на межкопьютерную. Единственная проблема данной модели — у межпроцессных и межмашинных интерфейсов высокая латентность. Стало быть нам нужно обеспечить общение между клиентом и сервером как можно более крупными блоками передающимися относительно редко. То есть не стоит делать 100500 вызовов для решения одной задачи, а надо передавать одно сообщение с данными и обрабатывать его на сервере возвращая относительно крупный результат. Кроме того реализация должна быть максимально асинхронной и кэшировать информацию на клиенте. Это будет сглаживать латентность.

Выбранное решение позволяет упростить достижение и пункта 5. Ведь модель акторов заставляет описать все взаимодействие между акторами в виде сериализуемых сообщений. А это гарантирует слабую связанность, четкое описание всего API и прочие плюшки чистого API. Таким образом сам выбор клиент-серверного подхода в купе с моделью акторов упрощает достижение этой цели и гарантирует чистоту.

ЗЫ

Мне кажется, что теперь я разжевал все до мелочей. Все кто способен понять и хочет это сделать, думаю, поняли. Прошу тех кому все еще хочется полезть в бутылку и поспорить просто зачислить меня в клинические идиоты и не посещать данный форум. Я по про прежнему готов отвечать на разумные вопросы. Но очень не хочу повторяться вновь. Это занимает много времени и несет мало пользы.

Здравствуйте, VladD2, Вы писали:

VD>Вот из чего сделан вывод, что сделано "как где-то" или "из-за ограничений Electron-а"?

Вот из чего сделан вывод, что это какой-то вывод? Это был конкретный ответ на конкретный пост kekekeks'а.

— Сейчас все прогрессивные IDE на клиент-серверную модель переходят...
— Они не переходят, они изначально так сделаны. И не от хорошей жизни. Зачем в Нитре повторять то, что сделано из-за ограничений Electron'а?

Ты увидел здесь вопрос про клиент-сервер в Нитре? Его здесь нет. Здесь речь про то, что не нужно приводить "прогрессивные IDE" в качестве аргумента, так как у них были другие причины выбора этой модели.

VD> [...]

Добавил бы скипнутое в стартовый пост, намного легче воспринимать, чем вопрос-ответ.

Здравствуйте, _Raz_, Вы писали:

VD>>Вот из чего сделан вывод, что сделано "как где-то" или "из-за ограничений Electron-а"?

_R_>Вот из чего сделан вывод, что это какой-то вывод?

Из твоего утверждения:

Зачем в Нитре повторять то, что сделано из-за ограничений Electron'а?

_R_>Это был конкретный ответ на конкретный пост kekekeks'а.

Ты, в следующий раз, когда будешь давать ответы не ставь в конце знак вопроса.

_R_>— Сейчас все прогрессивные IDE на клиент-серверную модель переходят...
_R_>— Они не переходят, они изначально так сделаны. И не от хорошей жизни. Зачем в Нитре повторять то, что сделано из-за ограничений Electron'а?

Вот, вот. Делаешь неверные предположения и утверждения, а потом начинаешь юлить.

По поводу:

Они не переходят, они изначально так сделаны.

Это тоже не верное утверждение. Ни одна IDE изначально клиент-серверной не являлась. VS появилась в 1997-м. Ей 20 лет в этом году исполнилось. Внешнепроцессные сервисы в ее языковые сервисы (language services) стали появляться только в последние годы.

VS Code не является клиент-серверным. Его языковые сервисы пишутся на Java Script/Type Script. Клиент-серверный вариант появился в процессе работы над некоторыми из них.

Rider — это надстройка над IDEA, которой 16 лет.

_R_>Ты увидел здесь вопрос про клиент-сервер в Нитре?

Я вижу здесь демагогию и попытки вывернуться. Оба твои предположения не верны. Причины выбора КС-подхода я описал. Вопрос, в общем-то, исчерпан. Но у тебя что-то подгорает.

_R_>Его здесь нет. Здесь речь про то, что не нужно приводить "прогрессивные IDE" в качестве аргумента, так как у них были другие причины выбора этой модели.

А тебе отвечают, что никто ради повторения ничего не делал. Был сделан дизайнерский выбор. Причины его я описал уже несколько раз. Но кто-то все это профильтровал и продолжает спорить на пустом месте.

_R_>Добавил бы скипнутое в стартовый пост, намного легче воспринимать, чем вопрос-ответ.

ОК

Здравствуйте, VladD2, Вы писали:

VD> [...]

Ты согласен с фразой "не нужно приводить "прогрессивные IDE" в качестве аргумента, так как у них были другие причины выбора этой модели."?

Здравствуйте, 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% новичков, а там уже и на Шекспира замахнёмся! Это реальный план и чётко ощутимые шаги.

С Новым Годом!

29 июня. Пол-года прошло, а Ленского всё нет!

Почему нет? Да потому нет — хотели полететь в космос, а фактически только спрыгнули с сарая. У нас есть хорошие планы, но мы делаем самолёт из лодки!! Причём лодки из ИКЕИ
Давайте перепишем Немерле-2 на Немерле-1, перепроектировав всё с нуля и безо всяких всемогутеров. Пусть будет как в Н-1 — макросы уровня выражений, уровня компилятора или чего там... короче, такое, которое не потребует космических ресурсов и будет доступно для понимания. Последнее очень важно — Н-2 не взлетит, если его надо будет объяснять так же, как Влад объясняет Нитру. (у Влада вообще с объяснениями не очень — сильно зарывается в детали, не видя главную линию)

Ну тык... когда будем пилить настоящий космолёт — с блэкджеком и композитами?