[Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 09:51
Оценка:
Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".

Вот здесь
Автор: VladD2
Дата: 29.12.17
описаны цели, которые пытались достичь подобным дизайном.

Публикую один из чатов в Скайпе. Думаю, что в такой форме (вопрос, ответ) будет проще объяснить все "за" и "против".

Dmitry Golovko: Вариант с сервером какой то тяжеловесный на мой взгляд (он оправдан для работы с 32 битной версией VS) но для отдельного проекта с редактором это по моему перебор.
По идее для интелисенса должна быть отдельная библиотека с публичным апи.

Vlad: Наоборот. Это чистое и незамутненное разделение представления и модели.

Dmitry Golovko: А чем отдельная библиотека этому разделению препятствует?

Vlad: Вот сообщения и есть публичный АПИ.

Dmitry Golovko: Зачем затевать межпроцессорное взаимодействие если есть возможность выполнения в рамках одного процесса?

Vlad: Переверни свой вопрос и попробуй на него ответить.
Vlad: Тут вопрос лучше ставить по другому. Не "зачем", а что дает один и другой подход.

Dmitry Golovko: Дают по идее то же самое

Vlad: Ну, вот не совсем.
Vlad: И потому сейчас почти все движки ИДЕ по этому пути пошли. Райден, Розлин по карайней мере.
Dmitry Golovko: Ну там скорее всего упирается в ограничения по памяти в VS

Vlad: Это только одно "за".
Vlad: Еще — возможность реализации движка IDE для не дотнетной платформы. Месаги то просто плоские данные сериализуемые в поток.
Vlad: Реализуй их передачу на яве или С++ и получишь общение с сервером на дотнете даже не зная про это.

Dmitry Golovko: Это да.
Но для дот нета можно совместить оба подхода и в серверной части добавить открытое апи.

Vlad: Ну, и сама чистота связей. Когда у тебя все в одном процессе невольно хочется использовать какие-то внутренние структуры. А так ты обязан все сериализовать. А значит и сам не захочешь тащить кишки компилятора.
Изменены 12:24:08] Vlad: В итоге АПИ остается простым и легким.
Vlad: На скорость же это никак не влияет, так как все делается довольно крупными транзакциями.

Dmitry Golovko: Для тонких клиентов написанных на дот нете наличие серверной части усложняет интеграцию на мой взгляд

Vlad: Ну, про устойичивость к сбоям и говорить не приходится. Процесс слетит, и отряд не заметит потери бойца...

Dmitry Golovko: АПИ можно оставить один к одному как есть и при работе с библиотекой
Dmitry Golovko: Те де сообщения

Vlad: Ну, где усложняет то? Тебе и так и эдак надо реализовать некий АПИ.

Dmitry Golovko: + добавить запускалку серверной части
Dmitry Golovko: И отслеживать ее работоспособность

Vlad: Если ты пишешь на дотнете, то клиент уже есть. Просто создаешь его экземпляр и пользуешся.
Vlad: Ничем от классического АПИ не отличается.
Vlad: Разве что вместо вызова методов — передаешь сообщения. Но это и в обычном коде бывает. Слышал про модель акторов?

Dmitry Golovko: Да

Vlad: Тут еще один нюанс. Месаги выбраны не просто так. Все АПИ асинхронное. Это нужно чтобы не было тормозов.
Vlad: А с асинхронным, многопоточным кодом крайне неприятно работать теми средствами, что предоставляет тот же Шарп.
Vlad: Вот и была выбрана модель актров, чтобы все взаимодействие был понятным человеку.
Vlad: Пока что эта модель не подводила. Проблем с многопоточностью (тьфу-тьфу) нет.

Dmitry Golovko: Это все понятно — как серверный процесс будет запускаться лучше расскажи?

Vlad: Да молча. Стартует как ехе-шник. Это проблемы клиента.
Vlad: Он создает дочерний процесс и передает ему имена именованных каналов через параметры.
Vlad: Тебе как пользователю АПИ эти детали не важны. Ты просто соззаешь клиент и вызваешь всегда один метод — Send()

Dmitry Golovko: Ну как же не важны
Если я поставляю утилиту редактора то мне важно чтобы как можно проще можно было его установить и запустить без лишних зависимостей
Vlad: Вот отсутствие зависимостей — это еще одно преимущество данного подхода. Твой процесс зависит только от двух длл-ей Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll.
Dmitry Golovko: Т.е я их подключаю к проекту и дергаю у них метод Send?

Vlad: Все что может прийти с сервера и все что можно послать на сервер описано вообще в одном файле. https://github.com/rsdn/nitra/blob/master/Nitra/ClientServer/Nitra.ClientServer.Messages/Messages.n
Vlad: Т.е я их подключаю к проекту и дергаю у них метод Send?Да
Vlad: Так и работают плагин к Студии и Визуалайзер.

Dmitry Golovko: Ну супер.
Это то что я хотел
При это они создают отдельный процесс?

Vlad: Вот если захочешь на Яве ИДЕ замутить, то придется реализовать обе длл-ки. Но они не так уж сложны.
Vlad: При это они создают отдельный процесс?Да. Точнее создает Nitra.ClientServer.Client.dll

Dmitry Golovko: Ок
Главное что мне этим заниматься не надо

Vlad: Nitra.ClientServer.Messages.dll только содержит месаги и код их сериализации/десериализации (сгенерированный макросами).

Dmitry Golovko: Ок
Главное что мне этим заниматься не надо

Vlad: Ну, каждому главное свое. Кому-то может оказаться приятным, то что можно обращаться к серверу из Явы или С++.
Vlad: И он с радостью реализует эти две Длл-и. Благо они простенькие.

Dmitry Golovko: Это большой плюс

Vlad: Это куча огромных плюсов!

Dmitry Golovko: Согласен

Vlad: Потому и клиент-сервер. Жаль только каждому все это объяснять приходится.

Dmitry Golovko: Ну надо заметку создать



20.12.17 21:00: Перенесено из 'Nemerle'
20.12.17 21:00: Перенесено из 'Nemerle'
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 30.12.2017 8:43 VladD2 . Предыдущая версия . Еще …
Отредактировано 19.12.2017 9:54 VladD2 . Предыдущая версия .
Отредактировано 19.12.2017 9:54 VladD2 . Предыдущая версия .
Re: [Nitra] Почему клинт-сервер?
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.12.17 10:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".


А что, нормальный такой UNIX way. Я тоже так люблю

А клиент умеет выживать, если сервер упал и перезапустился?
Re: [Nitra] Почему клинт-сервер?
От: Kolesiki  
Дата: 19.12.17 11:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".


"Ичо?" Влад, ты всё равно ничего не объяснил, кроме как парируя гипотетическими преимуществами ( <- прочитать, вникнуть!) клиент-серверного подхода, оставляя за кадром саму нужность этого "многоплатформенного суперрешения". Ты идёшь от преимуществ к решению (а точнее, оправдываешь решение преимуществами), в то время как задача вообще нигде не формулирует нужность этой самой "всемногопуперности". Задача — предоставить клиенту удобный backend API, минимизируя любые затраты, ибо time critical.

Рассуди как маркетолог, после ЖетБрынзы ты теперь это можешь: кому нужна многоплатформенность? Ну да, есть пара гиков, которые пишут калькулятор для "Пингвохрень-Линукс 425.1.3". Ичо? Этот 0.000001% стóит тех затрат, что ты терпишь, учитывая все ньюансы решения "нечто независимое — связь — нечто независимое"? Очевидно, что нет. МакакОСь — та вообще удел конченых эпплерастов, не интересна ни разу.
Остаёмся мы и форточка. И космическая архитектура, позволяющая НЛО соединяться с Землёй и парсить там сорсы Немерли.

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

Так что нет, аргументированного ответа мы не получили. "Все так делают" — тоже не аргумент.
Re[2]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 11:05
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>А клиент умеет выживать, если сервер упал и перезапустился?


IDE остается жить. А вот сервер перезапускаться не умеет. Не научили пока. Оно и без того вроде пашет. Если что придется переоткрыть солюшен. Но, конечно, нужно сделать и это.

Как не странно самым противным багом оказалась передача неожидаемых клиентом данных (несоответствие протоколу). Вот тут ИДЕ не раз складывалась. Но это можно обложить трай-кэтчами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Почему клинт-сервер?
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.12.17 11:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>IDE остается жить. А вот сервер перезапускаться не умеет. Не научили пока. Оно и без того вроде пашет. Если что придется переоткрыть солюшен. Но, конечно, нужно сделать и это.


Ну если сервер руками перезапустить, клиент его подхватит?

VD>Как не странно самым противным багом оказалась передача неожидаемых клиентом данных (несоответствие протоколу). Вот тут ИДЕ не раз складывалась. Но это можно обложить трай-кэтчами.


А ты это сообщения не валидируешь, что ли, при приеме?
Re[4]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 11:57
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Ну если сервер руками перезапустить, клиент его подхватит?


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

Pzz>А ты это сообщения не валидируешь, что ли, при приеме?


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

Или другой пример. Сервер вырабатывает хинт. Но хинт частично формируется прикладным кодом. При этом в нем могут быть баги. В разультате может вернуться невалидный ХМЛ. Он тупо подсовывался парсеру от МС, которые ничего умнее не делал как кинуть исключение. Исключение не ловилось и все ИДЕ падала. Ну, понятно, что в итоге это дело отловилось и было перекрыто на разных уровных абстракции (вплоть до перехвата исключений парсера ХМЛ-я). Но какое-то время клиент наворачивался от некорректного выхлопа сервера. Теперь не только не падает, но еще и диагностику дает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.12.17 12:22
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>"Ичо?" Влад, ты всё равно ничего не объяснил, кроме как парируя гипотетическими преимуществами


Просто тебе так хочется считать не смотря на аргументы. Если просто здраво сопоставить все требования, то становится понятным, что выбор был единственно возможным.

Просто аргументы я несколько раз приводил. Последний раз в видео. Могу еще раз перечислить:
1. Преодоление 32-битного адресного пространства Студии.
2. Надежность.
3. Переносимость между платформами и поддержка разных ИДЕ в будущем.
4. Гарантированная изоляция представления от модели и как следствие удержание АМИ минималистическим, не тянушим лишних деталей.
5. Упрощение асинхронной, многозадачной реализации за счет использования модели акторов.
6. Возможность реализации клиента на основе браузера.

Уже одного пункта 1 за глаза хватает для выбора именно клиент-серверного решения. Но все остальные возможности тоже крайне желательны. Их отсутствие уменьшает конкурентоспособность Нитры.

K>Рассуди как маркетолог, после ЖетБрынзы ты теперь это можешь: кому нужна многоплатформенность?


Вот как раз "после" могу четко ответить на этот вопрос. Когда я пришел туда, основным продуктом был Решарпер, а сейчас основным продуктом стала Идея. Причем решарпер запихнули в такой же сервер и прикрутили к Идеее. Получившийся продукт назвали Райдер. Уж кто-то, а Джет коммерческая контора и просто так они ничего не разрабатывают. Тем более, что на разработку они тратят сильно больше одного человека.

K>Ну да, есть пара гиков, которые пишут калькулятор для "Пингвохрень-Линукс 425.1.3". Ичо? Этот 0.000001% стóит тех затрат, что ты терпишь, учитывая все ньюансы решения "нечто независимое — связь — нечто независимое"?


Очевидно, что ты пропустил маленькое событие. За эти годы разработка для Веба стала доминирующей, а десктоп отошел на второй план. Ранее МС выезжал на том, что которы писали разные бухгалтерии и склады под Винду. Но теперь они все прочухали, что лучше писать для Веба. Это снимает проблемы развертывания и администрирования клиентов. Делает решение клиент-серверным (т.е. более устойчивым к сбоям и более производительным).

Ну, еще в тренде мобилы. Но это опять не про МС, так как МС этот рынок слил.

И вот даже МС схватилась за голову и в спешке лепит .Net Core! На первый взгляд можно подумать, что это какой-то отдел нашел фатальный недостаток в дотнете и решил его исправить путем написания такого же дотнета, но другого. Но на самом деле они спасают шкуру компании, так как если не делать этого, то МС может и разориться.

Новая стратегия — захват облачного рынка. Но люди не очень хотят платить за Винду на сервере, ведь пхп-шки не плохо работают и на бесплатном Линухе. Вот МС и клепает в строчном порядке переносимый сабсэт дотнета. Основная задача .Net Core — хостить Asp.Net MVC. Именно по этому Джет начал клепать Райдер.

Так что нужда в кроссплатформенности не мнимая, а самая что ни на есть реальная.

K>Учитывая, что .NET и так "простихоспади" по производительности, да ещё и компиляция — весьма ресурсоёмкая задача, нужно крайне аккуратно разбрасываться "абстракциями", заранее предусматривая тотальную оптимизацию, кэши, reusing и т.п.


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

K>Так что нет, аргументированного ответа мы не получили. "Все так делают" — тоже не аргумент.


Это твои домыслы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: [Nitra] Почему клинт-сервер?
От: Слава  
Дата: 19.12.17 12:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".


Можно было ответить одной фразой "это Unix-way". Самое универсальное это именно взаимодействие процессов, поддерживаю такой выбор.
Re[5]: [Nitra] Почему клинт-сервер?
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.12.17 13:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Нет. Серверу передаются имена именованных каналов. Так что перезапускать его должен клиент. Это не сложно. Надо просто это сделать. Пока этого нет.


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

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

Pzz>>А ты это сообщения не валидируешь, что ли, при приеме?


VD>Да формат по определению не может быть не правильным. Он не сериализуется неверно. Но среди смесаг были такие, которые предполагают ответ, например. А в сервере может быть какой-то выход без ответа. И все идет наперекосяк.


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

VD>Или другой пример. Сервер вырабатывает хинт. Но хинт частично формируется прикладным кодом. При этом в нем могут быть баги. В разультате может вернуться невалидный ХМЛ. Он тупо подсовывался парсеру от МС, которые ничего умнее не делал как кинуть исключение. Исключение не ловилось и все ИДЕ падала. Ну, понятно, что в итоге это дело отловилось и было перекрыто на разных уровных абстракции (вплоть до перехвата исключений парсера ХМЛ-я). Но какое-то время клиент наворачивался от некорректного выхлопа сервера. Теперь не только не падает, но еще и диагностику дает.


А парсеру от МС вообще безопасно подсовывать неизвестно откуда взявшийся ХМЛ? Не получится так, что ты создаешь дыру в защите? Я б не очень доверял по умолчанию парсеру от МС, честно говоря.
Re: [Nitra] Почему клинт-сервер?
От: _Raz_  
Дата: 19.12.17 14:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>

VD>Dmitry Golovko: Зачем затевать межпроцессорное взаимодействие если есть возможность выполнения в рамках одного процесса?

VD>Vlad: Переверни свой вопрос и попробуй на него ответить.
VD>Vlad: Тут вопрос лучше ставить по другому. Не "зачем", а что дает один и другой подход.




VD>Уже не один человек задает вопрос "Почему для реализации IDE-движка выбрана именно клент-серверная реализация? И не является ли это перебором?".


Конечно задают — ты же уходишь от ответа. И будут задавать, пока ты игнорируешь часть "если есть возможность выполнения в рамках одного процесса".
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
Re[2]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 05:16
Оценка:
Здравствуйте, _Raz_, Вы писали:

_R_>Конечно задают — ты же уходишь от ответа. И будут задавать, пока ты игнорируешь часть "если есть возможность выполнения в рамках одного процесса".


Я ни от чего не ухожу. Просто у кого-то есть мнение, которое хрен оспоришь. С этим бороться невозможно.

Сама постановка вопроса "Зачем, если есть возможность выполнения в рамках одного процесса?" ущербная. Ее точно так же можно развернуть на 180 градусов: "Зачем, если есть возможность выполнения в рамках разных процессов?". Чем хуже?

В этом вопросе кроется ложная аксиома. Мол в одном процессе лучше. Вот, собственно, я в режиме диалога и объяснил чем лучше держать сервер в разных процессах. К слову, нет никаких проблем подправить код и сделать так, чтобы он работал в рамках одного процесса. Это можно сделать за день. Вот только в этом нет нужды.

Сервер изолированный в отдельном процессе дает кучу преимуществ и ни одного недостатка. Скорости передачи данных достаточно. Остальное мелочи. Пользователь может и не знать, что там что-то на процессы разнесено. В том же Розлине тоже отдельный процесс, но что-то никто не выступает против этого.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 05:34
Оценка:
Здравствуйте, Слава, Вы писали:

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


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

Да и не все понимают смысл этого UNIX-way.

Но, согласен — с UNIX-way много общего.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Почему клинт-сервер?
От: ifle  
Дата: 20.12.17 06:13
Оценка:
А к чему эти споры? непонятно . Абсолютно правильное решение, позволяющее безопасно не нагружая IDE делать свою работу, легко переносимое на любую IDE.
Примеров достаточно, тот-же VS, Code, Idea, Rider с решарпером как клиент-сервер.
Re[3]: [Nitra] Почему клинт-сервер?
От: WolfHound  
Дата: 20.12.17 06:38
Оценка:
Здравствуйте, VladD2, Вы писали:

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

На самом деле можно сделать совсем UNIX-way.
Пропустить всё общение через stdin и stdout процесса.
На производительности это не скажется.
За одно будет возможность работать с сервером по сети. Ибо API получится идентичным TCP/IP протоколу.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 07:00
Оценка:
Здравствуйте, ifle, Вы писали:

I>А к чему эти споры? непонятно . Абсолютно правильное решение, позволяющее безопасно не нагружая IDE делать свою работу, легко переносимое на любую IDE.

I>Примеров достаточно, тот-же VS, Code, Idea, Rider с решарпером как клиент-сервер.

Есть стойкое непонимание и неприятие у ряда людей. Месяц назад я IT тоже самое объяснял. Решил, чтобы не объяснять каждому в отдельности, выложить переписку с подобным объяснением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 07:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>На самом деле можно сделать совсем UNIX-way.

WH>Пропустить всё общение через stdin и stdout процесса.

Они текстовые. И не уверен, что не синхронные. У нас для возврата сообщений две очереди. Одна псевдо-синхронная (для операций, которые требуют продолжения) и одна асинхронная.

WH>На производительности это не скажется.


Возможно. Но это тоже надо проверять.

WH>За одно будет возможность работать с сервером по сети. Ибо API получится идентичным TCP/IP протоколу.


Именованные каналы и так по сети работают. Вопрос только в том зачем это сейчас нужно?

Вот что, возможно, и надо было бы сделать, так это перейти на HTTP и JSON вместо именованных каналов и бинарной сериализации. Та же VS Code именно этими форматами пользуется. Плюс, гоняя текст, упрощается отладка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Nitra] Почему клинт-сервер?
От: WolfHound  
Дата: 20.12.17 08:03
Оценка:
Здравствуйте, VladD2, Вы писали:

WH>>На самом деле можно сделать совсем UNIX-way.

WH>>Пропустить всё общение через stdin и stdout процесса.
VD>Они текстовые.
Это не правда.
Их обычно используют для текста. Но там нет ничего что бы делало их текстовыми.

VD>И не уверен, что не синхронные.

using System;
using System.Console;

module Program
{
  Main() : void
  {
    using (cout = Console.OpenStandardOutput())
    {
      def arr = array(256);
      for (mutable i = 0; i < 256; ++i)
        arr[i] = i :> byte;
      def t1 = cout.WriteAsync(arr, 0, 128);
      def t2 = cout.WriteAsync(arr, 128, 128);
      t2.Wait();
      t1.Wait();
    }
  }
}

Запусти и направь вывод в файл.
Потом шестнадцатеричным редактором посмотри содержимое.
Там будут все байты в нужной последовательности.

VD>У нас для возврата сообщений две очереди. Одна псевдо-синхронная (для операций, которые требуют продолжения) и одна асинхронная.

Да хоть десять. Если в клиенте будет сидеть поток, который постоянно читает поток и распихивает сообщения по очередям всё будет прекрасно работать.

WH>>На производительности это не скажется.

VD>Возможно. Но это тоже надо проверять.
Нужно. Но там те же пайпы. Так что разницы быть не должно.

VD>Вот что, возможно, и надо было бы сделать, так это перейти на HTTP и JSON вместо именованных каналов и бинарной сериализации. Та же VS Code именно этими форматами пользуется. Плюс, гоняя текст, упрощается отладка.

На HTTP нельзя. Там на каждый запрос нужен ответ. Причем сторого в той последовательности в которой были отправлены запросы.
Что касается JSON то в VS Code не какой попало JSON, а вполне конкретный. И я не уверен, что наши сообщения могут быть 1 в 1 представлены в формате VS Code. Возможно там понадобятся некие пляски для того чтобы сгенерировать JSON в формате VS Code.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 08:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


Ну, вот в VS Code как-то сделано. Многие интеграции через него работают.

WH>Что касается JSON то в VS Code не какой попало JSON, а вполне конкретный. И я не уверен, что наши сообщения могут быть 1 в 1 представлены в формате VS Code. Возможно там понадобятся некие пляски для того чтобы сгенерировать JSON в формате VS Code.


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

Ты вот за генерацию кода парсера брался. Что-нибудь сделал?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Почему клинт-сервер?
От: Kolesiki  
Дата: 20.12.17 10:48
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Просто тебе так хочется считать не смотря на аргументы.


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

VD>1. Преодоление 32-битного адресного пространства Студии.


Мимо. Студия спокойно компилирует проекты любой мыслимой величины. То, что сама студия — отстоище на COM технологии — отдельная песня.

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


Надёжность... эээ... по каким параметрам?? Вместо "программа-библиотека" ты ввёл "программа-RPC-библиотека", тем самым ухудшив надёжность лишним звеном.
А если ты про "упал парсер, но не упал редактор", то извини — это не метод разработки софта, ВСЁ должно быть подконтрольно и обёрнуто в try/catch. В любом случае, упавший парсер — это ПРОБЛЕМА, которую надо решать, а не дистанцироваться за клиент-сервером. От того, что редактор не упал, мне не легче — код всё равно нельзя редактировать!


VD>3. Переносимость между платформами и поддержка разных ИДЕ в будущем.


Уже обсуждали, не аргумент. Все эти "многоплатформенности" — миф, распыление сил на гетерогенные системы, где профита — ноль.


VD>4. Гарантированная изоляция представления от модели и как следствие удержание АМИ минималистическим, не тянушим лишних деталей.


Да мне пофиг эти изоляции — ты сейчас говоришь тупо про КАЧЕСТВО API, никакого отношения к "клиент-серверу" оно не имеет. Кроме того, RPC — лишь транспорт, любое API предоставляет только те методы, которые выставляет. К чему тут какие-то "изоляции"?


VD>5. Упрощение асинхронной, многозадачной реализации за счет использования модели акторов.


Асинхронность — вообще рядом стояла, причём тут опять "клиент-сервер"? Хочешь — можешь и с "программа-библиотека" написать такой же асинхронный код, кто мешает-то? Многонитевость — туда же. Да и "упрощения" я что-то не вижу — на обеих сторонах придётся аккуратно программировать потоки.


VD>6. Возможность реализации клиента на основе браузера.


О! Эт да... нам же тормозов мало — браузер закосячим! Потом портируем на Newton и МК-61. Браузер? Для разработки?? Знаешь, у меня хоть и мощный комп, но ни под каким видом я не хочу это убожество "отображатель гипертекста" превращать в элегантные шорты. Чистое баловство на фоне общего хайпа.


VD> Их отсутствие уменьшает конкурентоспособность Нитры.


Нитра — у неё, строго говоря, вообще нет конкурентов! Прикинь, сюрприз! Ты воюешь на танке против мельниц. Но надо понимать, что чем выше ты улетаешь в абстракции, тем дальше ты от задачи помола зерна. Нитра ценна сама по себе, своей сутью. А ты пытаешься сделать из неё попсовый гироскутер. Лучше сначала полностью реализовать самое ядро Нитры, а потом уже думать, принесут ли ей бенефиты остальные свистоперделки — браузеры, облака, линупсы и прочая местечковая буря в стакане.


K>>Рассуди как маркетолог, после ЖетБрынзы ты теперь это можешь: кому нужна многоплатформенность?


VD> Причем решарпер запихнули в такой же сервер и прикрутили к Идеее. ... Уж кто-то, а Джет коммерческая контора...


Влад, я уже это писал: "а вон те так делают" — не технический аргумент. Тем более, в таком болоте, как компания с многолетним легаси. То, что сначала изобрели телегу для лошади, а только потом — паровой двигатель, не делает "паровую телегу" королём дороги. Я не считаю их решение оптимальным, скорее — агония из-за неправильно выбранной стратегии.
(от себя лично: десяток раз ставил Решарпер и сносил к чертям — бессмысленная монстро-перделка с парой полезных фич, душащая мою IDE. Решарпер — это инструмент студоты, в проф. сегменте, да при всех возможностях VS, ему делать нечего.)


VD>Очевидно, что ты пропустил маленькое событие. За эти годы разработка для Веба стала доминирующей, а десктоп отошел на второй план.


Влад, ты штанины не подворачиваешь, случаем? Какой Веб, какие "доминанты"?? Виндуза как были, так и остались диктатором на десктопах. ВЕСЬ мой рабочий софт — чистые, незамутнённые Win API. Веб кажется "большим" в силу единственной причины — это параллельная вселенная, которой раньше не было, а теперь она разрослась. Её смысл — примитивные интерфейсы к большим системам, чтобы каждый задрот со смартом мог тыкнуть единственную кнопку на экране и возрадоваться курсу Биткойна. Веб никогда не был rich UI, это всегда позорные компромиссы и ограничения.
Но ладно, с чего-то вдруг ты сделаешь этот WebUI. Для кого? Что это за странный контингент одарённых шимпанзе, который не может поставить студию, но может писать макросы?? Да нас, "немерлистов", даже в ДотНЕТе — единицы, и те не все могут наладить безпроблемную среду (а я тебе говорил!). Веб никого не спасёт, всё равно полноценные проекты даже для библиотеки+GUI потребуют настоящей, нативной среды.


VD> Это снимает проблемы развертывания и администрирования клиентов.


А кого тебе понадобилось развёртывать?? Это компилятор, а не калькулятор! Специфическая вещь даже не для каждого программиста! Сделаешь качественный сетап — будут и пользователи. А прятать одни проблемы за другими — не поможет.


VD>Ну, еще в тренде мобилы. Но это опять не про МС, так как МС этот рынок слил.


Мобилы? Для компиляции Nitra?!


VD>И вот даже МС схватилась за голову и в спешке лепит .Net Core! На первый взгляд можно подумать, что это какой-то отдел нашел фатальный недостаток в дотнете и решил его исправить путем написания такого же дотнета, но другого. Но на самом деле они спасают шкуру компании, так как если не делать этого, то МС может и разориться.


Ты прав, Core — это агония. С одной поправкой — Core тоже не спасёт MS, новые вёсла не спасут тонущую лодку. Там проблема в людях, а не технологиях.


VD>Новая стратегия — захват облачного рынка.


С одним маленьким ньюансом: ни один чел на Земле не любит, когда его откровенно доят. Ни один сервер, даже за сущие копейки и при "неубиваемом, быстром Интернете" (несбыточная мечта), не сравнится с локальной копией, которая просто работает.


VD>Так что нужда в кроссплатформенности не мнимая, а самая что ни на есть реальная.


Только если ты нырнул в глубины этого глупого хайпа. Вернись на десяток лет назад — ВСЁ работало безо всяких облаков. Веб — чисто утилитарные клиенты для всё тех же серверов, к которым уже были нативные GUI-клиенты. Линукс — как был маргинальной дырой для траты времени — так и остался. Причём дыры, даже самые тупые, вылазят и по сей день. GUI и Линукс — вообще оксюморон. Apple — там делать нечего, анально огороженная секта. Ну и... какая кроссплатформенность, Влад? Винда даже в своих самых чистейших попытках быть "ещё и мобильной" провалила всё — "десятка" вошла в историю эпик фэйлом.


VD>Это никак не противоречит клиент-серверной архитектуре. Наоборот, серверу удобнее кэшировать все что надо. Обмен с сервером идет довольно редкими и крупными сообщениями. Так что на производительности это не сказывается.


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

Ещё раз: для каждого решения должно быть веское обоснование. "Нельзя просто так взять и вывернуть всё наизнанку!". Сначала — чёткое, доказанное обоснование потребности и только потом — её решение. А судя по аргументам, ты просто увидел где-то решение, словил пару "бенефитов" и на этом успокоился, даже не пытаясь скептически оценить, насколько это новое решение обоснованно в твоей задаче. Ну, тут я просто развожу руками! Ты — босс, тебе и отвечать за недальновидную растрату сил.
Кстати, ровно тем же занимается MS — вместо того, чтобы в поте лица развивать мобильную венду (на рынке которой уже МИЛЛИАРДЫ профита), они гоняют лысого и переписывают собственные ошибки. Только вот "работа над экзаменационными ошибками" уже не нужна, когда сам экзамен прошёл. хех....
Re[4]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 13:47
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Влад, мне не нужно "хотеть", мне достаточно увидеть хотя бы один весомый, технический аргумент (при отсутствии серьёзных недостатков), чтобы принять твою идею как здравую. Мы оба видим один и тот же предмет, но ты упорно считаешь слона удавом, держа его за хобот.


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

VD>>1. Преодоление 32-битного адресного пространства Студии.


K>Мимо. Студия спокойно компилирует проекты любой мыслимой величины. То, что сама студия — отстоище на COM технологии — отдельная песня.


Причем тут "компилирует"? Компилирует не студия, а компиляторы. Почти все компиляторы запускаются (сюрприз!) в отдельном процессе. По этому 32-битность Студии для них не проблема. А вот код обеспечивающий интеллисенс для языков работает внутри процесса. Причем так как Студия — это компонетный контейнер, кода такого загружается довольно много. Если одновременно встречается какой-нибудь РеШарпер и движок Розлина, а проекты имеют большой объем, то памяти начинает не хватать даже без сторонних компонентов. По сему движок Розлина и часть Решарпера реализованы как внешние процессы. Только ты об этом не знаешь.

K>Надёжность... эээ... по каким параметрам??


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

K>А если ты про "упал парсер, но не упал редактор", то извини — это не метод разработки софта, ВСЁ должно быть подконтрольно и обёрнуто в try/catch.


Попробуй на досуге в catch поймать переполнение стека.

K>Уже обсуждали, не аргумент.


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

K>Все эти "многоплатформенности" — миф, распыление сил на гетерогенные системы, где профита — ноль.


Вот тебе простой пример — JetBrains Rider. Работает под Windows, macOS и Linux. Реализована в клиент-серверной технологии. Движок РеШарпера живет в серверном процессе, а "мордой" выступает IDEA.

Новый движок интеллисенса для C# от Майкрософт тоже реализован в отдельном процессе-сервере из тех же соображений.

Так что это не миф, а твое незнание.

K>Да мне пофиг эти изоляции


А мне не по фиг. И вообще, что либо объяснять тем, кому все по фиг нет даже желания. Кому надо поймет. А если тебе по фиг — проходи мимо.

K> — ты сейчас говоришь тупо про КАЧЕСТВО API, никакого отношения к "клиент-серверу" оно не имеет.


Имеет наимпрямейшее. АПИ предназначенный для клиент-сервера можно без проблем использовать локально. А вот наоборот — нет.

K>К чему тут какие-то "изоляции"?


К тому, что ошибиться не можешь. Нельзя случайно протащить лишнее. Даизайн получается сам собой. Границу разделения можно просто увидеть в одном файле. Уже никто не сможет "прикастить" какой-нибудь интерфейс к типу или вызвать что-то через рефлексию.

K>Асинхронность — вообще рядом стояла, причём тут опять "клиент-сервер"?


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

K>Хочешь — можешь и с "программа-библиотека" написать такой же асинхронный код, кто мешает-то? Многонитевость — туда же. Да и "упрощения" я что-то не вижу — на обеих сторонах придётся аккуратно программировать потоки.


Разберись с тем, что такое модель акторов. Тогда и упрощение увидишь. Она как раз и придумана, чтобы не надо было "аккуратно программировать потоки".

K>О! Эт да... нам же тормозов мало — браузер закосячим! Потом портируем на Newton и МК-61. Браузер? Для разработки?? Знаешь, у меня хоть и мощный комп, но ни под каким видом я не хочу это убожество "отображатель гипертекста" превращать в элегантные шорты. Чистое баловство на фоне общего хайпа.


Я понимаю, для тебя многое в новинку. Привыкай.

K>Нитра — у неё, строго говоря, вообще нет конкурентов! Прикинь, сюрприз!


Ты и тут блеснул компетенцией. Ну, знакомься c конкурентами. Там правда, всего два приведены. А их где-то с десяток.

K>Но надо понимать, что чем выше ты улетаешь в абстракции, тем дальше ты от задачи помола зерна. Нитра ценна сама по себе, своей сутью. А ты пытаешься сделать из неё попсовый гироскутер. Лучше сначала полностью реализовать самое ядро Нитры, а потом уже думать, принесут ли ей бенефиты остальные свистоперделки — браузеры, облака, линупсы и прочая местечковая буря в стакане.


Ядро давно работает. Вот только людям интересно интегрированное решение. Причем есть люди которым не нужен дотнет. А другие не хотят иметь дел с MS VS. Я делаю продукт, который если не сейчас, то по крайней мере в перспективе, можно будет перенацелить на другую IDE и перенести на другие платформы. Делать реализации для всех IDE я сейчас не собираюсь. Но возможность для этого я заложил. Каши она не просит. И кроме перенацеливания на другие платформы дает еще кучу возможностей. При этом недостатки у данного подхода несущественны.

K>Влад, я уже это писал: "а вон те так делают" — не технический аргумент.


Ты утверждал, что никому не надо. Я тебе привел примеры, что надо. Предлагаю больше не упомянуть ошибочные аргументы.

K>Тем более, в таком болоте, как компания с многолетним легаси. То, что сначала изобрели телегу для лошади, а только потом — паровой двигатель, не делает "паровую телегу" королём дороги.


Написал еще кучу текста в ответ, а потом поймал себя на слове, что трачу время впустую. Я привел достаточно аргументов, чтобы те хотел понять — поняли. У тебя явно недостаточно знаний, чтобы их понять, а часть ты просто забалтываешь неся не пойми что. Оставайся со своими заблуждениями дальше. Мне от этого ни горячо, ни холодно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 20.12.2017 14:26 VladD2 . Предыдущая версия .
Re[5]: [Nitra] Почему клинт-сервер?
От: Kolesiki  
Дата: 20.12.17 17:41
Оценка:
Здравствуйте, 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). Это решение куда реалистичнее и ничуть не ограничивает любого дотнетчика (а остальные всё равно не смогут юзать Нитру без дотнета).
Re[5]: [Nitra] Почему клинт-сервер?
От: Kolesiki  
Дата: 20.12.17 17:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


эээ... если им не нужен .NET, УЖЕ есть мульён альтернатив, к чему этим маргиналам Нитра??
А студия — да, я тоже с ней дела иметь не хочу Bloatware на устаревших технологиях. НО ДРУГИЕ — ЕЩЁ ХУЖЕ!! Думаю, ты согласишься, на фоне всяких Netbeans, Code::blocks и даже Rider, студия — лучшее из всего (внешне и в работе). Тем не менее, полноценная, гибкая и удобная IDE ещё никем не сделана, так что ниша свободна.
Re[6]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.12.17 18:28
Оценка:
Здравствуйте, Pzz, Вы писали:

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


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

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


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

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


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

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

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


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

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


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

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


Не от чего там защищаться. Студия это процесс который кому попало доверять не стоит. Любой экстеншен может содержать вредоносный код. Сервер запускается с теми же привилегиями. Так что сделать больше чем сама Студия он не может.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [Nitra] Почему клинт-сервер?
От: WolfHound  
Дата: 21.12.17 06:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

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

Нет. Занимался другими делами.
Если хочешь у меня что-то спросить для этого есть скайп.
Что за дурацкая привычка на форуме личные вопросы задавать.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.17 11:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Скорей всего они делают бесконечный пост, на который идёт бесконечный ответ.

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

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

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

WH>Нет. Занимался другими делами.

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

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

WH>Что за дурацкая привычка на форуме личные вопросы задавать.

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

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

А все остальное меня пока вообще не интересует.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [Nitra] Почему клинт-сервер?
От: WolfHound  
Дата: 21.12.17 11:58
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Где я предлагал что-то делать?
Я сказал можно сделать.
Я ни разу не сказал, что нужно.
И тем более нужно прямо сейчас.

Ты постоянно что-то себе фантазируешь и на это обижаешься.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.12.17 12:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


А это
Автор: WolfHound
Дата: 20.12.17
ты начал, чтобы разговор поддержать?

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


Количество того что можно сделать стремится к бесконечности. Если все обсуждать, то делом заниматься будет некогда. Я предполагаю, что если кто-то, что-то предлагает, то это предлагается сделать, а не просто потрепаться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Почему клинт-сервер?
От: Pzz Россия https://github.com/alexpevzner
Дата: 21.12.17 12:47
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


ОК. Plan9 way.
Re[6]: [Nitra] Почему клинт-сервер?
От: Pzz Россия https://github.com/alexpevzner
Дата: 21.12.17 12:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


Говорят, в HTTP/2 это починили.
Re: [Nitra] Почему клинт-сервер?
От: kekekeks  
Дата: 28.12.17 21:26
Оценка: +1
Сейчас все прогрессивные IDE на клиент-серверную модель переходят. Microsoft даже спеку сделала для протокола такого взаимодействия https://github.com/Microsoft/language-server-protocol
Интеграцию с той же Visual Studio Code можно сделать *только* таким образом (ну или написать свой движок разбора всего и вся целиком на жаваскрипте).
Re[2]: [Nitra] Почему клинт-сервер?
От: _Raz_  
Дата: 28.12.17 21:55
Оценка: -1
Здравствуйте, kekekeks, Вы писали:

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


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

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


Вот-вот. У Нитры внутри клиент-сервер со своим протоколом, для общения с Code'ом клиент-сервер со своим протоколом. И это считается нормальным
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
Re[3]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.17 23:03
Оценка: +2
Здравствуйте, _Raz_, Вы писали:

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


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

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


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

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

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

В общем, ребят извините, но вы реально не умеете стратегически мыслить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 29.12.2017 9:14 VladD2 . Предыдущая версия .
Re[4]: [Nitra] Почему клинт-сервер?
От: _Raz_  
Дата: 28.12.17 23:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

VD>А главная не ясна ваша упертость. Вы с какой-то остервенелостью [...]

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

Спасибо за ответ.
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
Re[5]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.12.17 10:42
Оценка:
Здравствуйте, _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. Таким образом сам выбор клиент-серверного подхода в купе с моделью акторов упрощает достижение этой цели и гарантирует чистоту.

ЗЫ

Мне кажется, что теперь я разжевал все до мелочей. Все кто способен понять и хочет это сделать, думаю, поняли. Прошу тех кому все еще хочется полезть в бутылку и поспорить просто зачислить меня в клинические идиоты и не посещать данный форум. Я по про прежнему готов отвечать на разумные вопросы. Но очень не хочу повторяться вновь. Это занимает много времени и несет мало пользы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 30.12.2017 8:38 VladD2 . Предыдущая версия .
Re[6]: [Nitra] Почему клинт-сервер?
От: _Raz_  
Дата: 29.12.17 15:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


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

VD> [...]


Добавил бы скипнутое в стартовый пост, намного легче воспринимать, чем вопрос-ответ.
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
Re[7]: [Nitra] Почему клинт-сервер?
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.12.17 08:37
Оценка:
Здравствуйте, _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_>Добавил бы скипнутое в стартовый пост, намного легче воспринимать, чем вопрос-ответ.


ОК
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [Nitra] Почему клинт-сервер?
От: _Raz_  
Дата: 30.12.17 14:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD> [...]


Ты согласен с фразой "не нужно приводить "прогрессивные IDE" в качестве аргумента, так как у них были другие причины выбора этой модели."?
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
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% новичков, а там уже и на Шекспира замахнёмся! Это реальный план и чётко ощутимые шаги.

С Новым Годом!
Re[7]: [Nitra] Почему клинт-сервер?
От: Kolesiki  
Дата: 28.06.18 18:58
Оценка:
29 июня. Пол-года прошло, а Ленского всё нет!

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

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