Здравствуйте, 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>Тем более, в таком болоте, как компания с многолетним легаси. То, что сначала изобрели телегу для лошади, а только потом — паровой двигатель, не делает "паровую телегу" королём дороги.

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

Здравствуйте, 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>Тем более, в таком болоте, как компания с многолетним легаси. То, что сначала изобрели телегу для лошади, а только потом — паровой двигатель, не делает "паровую телегу" королём дороги.

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