Dzavalishin: с байт-кодом все клево, но один момент остается непонятным. По сути, фантом напоминает объектную БД: я тоже работаю только с объектами, у меня есть «бесконечный» пул, и мне все равно, где объекты находятся. Похоже, что делается еще один шаг вперед — вся ОС становится БД, хранящей код и состояние объектов. Однако, БД и ОС — это все-таки разные вещи; когда я использую БД, накладные расходы представимы, а здесь непонятно. «Чистая» концепция ОС как объектной БД работает, если вся память — быстрая, а в ближайшее время разделение на «мало быстрой памяти, много медленной» все равно остается. И это нужно отражать, если мы хотим писать эффективный код. Традиционно, это и отражается наличием динамической памяти и файлов / БД. Если мне нужно обработать массив данных, существенно больший чем объем быстрой памяти, я не могу обращаться к ним просто «как есть», потому что тогда о перфомансе можно будет забыть. Как фантом будет гарантировать, что объект, к которому я обращаюсь — в быстрой памяти? Будет ли способ указать, что нужные объекты надо «поместить» в быструю память? И если да, то не вернемся ли мы к файлам, и сразу же? Попутно: 1. Зачем вам свой фантом-язык, который сильно хуже java или c#? Не лучше ли сразу ограничиться генерацией байт-кода, а фронт-эндом взять ту же жабу? 2. Почему вы отрицаете автоматические объекты и стэк? Все, что вы пишете в части Memory, было давно и неправда, а потом все равно всем пришлось делать unboxing 3. Как вы собираетесь давать API для отладчика без возможности кастить числа к объектам?
Дискуссии пользователя
Dzavalishin: с байт-кодом все клево, но один момент остается непонятным. По сути, фантом напоминает объектную БД: я тоже работаю только с объектами, у меня есть «бесконечный» пул, и мне все равно, где объекты находятся. Похоже, что делается еще один шаг вперед — вся ОС становится БД, хранящей код и состояние объектов. Однако, БД и ОС — это все-таки разные вещи; когда я использую БД, накладные расходы представимы, а здесь непонятно. «Чистая» концепция ОС как объектной БД работает, если вся память — быстрая, а в ближайшее время разделение на «мало быстрой памяти, много медленной» все равно остается. И это нужно отражать, если мы хотим писать эффективный код. Традиционно, это и отражается наличием динамической памяти и файлов / БД. Если мне нужно обработать массив данных, существенно больший чем объем быстрой памяти, я не могу обращаться к ним просто «как есть», потому что тогда о перфомансе можно будет забыть. Как фантом будет гарантировать, что объект, к которому я обращаюсь — в быстрой памяти? Будет ли способ указать, что нужные объекты надо «поместить» в быструю память? И если да, то не вернемся ли мы к файлам, и сразу же? Попутно: 1. Зачем вам свой фантом-язык, который сильно хуже java или c#? Не лучше ли сразу ограничиться генерацией байт-кода, а фронт-эндом взять ту же жабу? 2. Почему вы отрицаете автоматические объекты и стэк? Все, что вы пишете в части Memory, было давно и неправда, а потом все равно всем пришлось делать unboxing 3. Как вы собираетесь давать API для отладчика без возможности кастить числа к объектам?