Информация об изменениях

Сообщение Re[16]: понимание ООП Алана Кея от 30.03.2023 22:31

Изменено 30.03.2023 22:33 vdimas

Re[16]: понимание ООП Алана Кея
Здравствуйте, Ночной Смотрящий, Вы писали:

V>>В интерпретаторе спектрумовского Бейсика всё аналогично.

НС>Нет, совсем нет. Там именно исходная программа, просто в закодированном виде. Если по современному, то просто поток токенов.

Как я и думал, собсно.
Для некоторых команд проца IBM/360 аргументы тоже представляют себя эдакие токены.


НС>>>Непонятно. Что значит отделения и зачем он в этом топике?

V>>Это значит, что в практике IT редко встречается так, что язык диктует способ своей реализации.
НС>Но тот бейсик как раз демонстрирует обратное.

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


V>>Конечно, возможно.

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

Вообще-то получило.
Интроспекция дерева выражений Boost.Proto может происходить не только в рантайм, но и в момент компиляции через диспетчеризацию на шаблонах, т.к. любое выражение полностью статически типизировано и представляет из себя "плоский" граф, построенный на value-type в терминах дотнета.

Например, выражение expr:
auto x= _1;
auto y = _2;
auto expr = sin(x*10 + y*20);

порождает (на пальцах если) примерно такую структуру:
sin_(plus_(mul_(arg_<0>, const_<10>()), mul_(arg_<1>, const_<20>)))

Структура имеет нулевой размер (если служит базовым классом) или один байт в кач-ве самостоятельного значения (фиктивный байт, т.к. размер структуры не может быть меньше одного байта).
А эффективность её интерпретирования на порядок выше интерпретирования Expression<T> (до компиляции).

Соответственно, основное применение Boost.Proto — это compile-time генерация кода из некоего DSL (Boost.Proto, в отличие от Expression<T> позволяет переопределять дефолтную грамматику, доступные операторы, терминалы/нетерминалы, "ключевые слова" и т.д.).
В т.ч. можно в compile-time производить трансформацию AST, т.е. "компиллировать" свой DSL.

И напротив, связка linq/expression/queryable с подключаемыми провайдерами — чисто динамическая вещь.

Можно ли аналогичное сделать в С++, т.е., породить такое AST, которое возможно будет итерировать в рантайм не шаблонным кодом, а через систему интерфейсов (с целью динамической трансформации AST подключаемыми в рантайм провайдерами)? — можно.

Почему не было сделано?
Предположу, что по той причине, что работа с БД давно уехала с клиента на сервер и даже на веб-сервер, где плюсы не в топе популярности.

Когда плюсы теряли популярность в вебе, средний пинг по планете был 50-100 ms, т.е. экономия единиц ms ничего не давала.
К тому же, основные задержки по-прежнему в БД.


V>>Я вижу, что ты пытаешься утверждать, что байт-код таковым является только для виртуальных машин очень низкого уровня. ))

НС>Не я, это общепринятое определение. И, думаю, Синклер именно его имел в виду.

Как выяснилось, Синклер имел ввиду и вовсе AST-выражений, т.е. ближе к коду Бейсика, а не к низкоуровневому байт-коду.


НС>Если тебе хочется придумать собственную трактовку — ради бога


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


НС>но тогда все твои возражения теряют релевантность. И образуется именно та логическая каша, про которую я написал.


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

Был у нас коллективный курсовик для всей группы на 3-м курсе, в рамках которого была разработана учебная ОС.
В состав ОС входило ядро с пакетным планировщиком, одно устройство ввода, одно вывода, загрузчик и компилятор учебного советского языка (нц/кц, если помнишь) в байт-код стековой машинки.

Угадай с одного раза, зачем мы компиляли в байт-код?
Потому что мы были не способны за трудоёмкость курсовика (плюс небольшой свой опыт) компилять это всё в машинный код x86 со всеми его бесконечными спецификациями.
Это нетривиальная задача — порождать "ассемблерный код" реального нехилого проца.

Зато на языке высокого уровня (Си) написать интерпретатор своего упрощённого байт-кода — как два пальца об асфальт выделенной группе из 3-х студентов.
В итоге, ни на одном из этапов разработки мы не выходили на низкий уровень, кроме собственного уютного примитивного байт-кода.

Разумеется, в исходниках эта разработка была более-менее переносима на другие платформы, а значит байт-код получался автоматически переносимым.

Но это мы, студенты-третьекурсники.
А когда мне показывают, что похожий по технике Паскаль был разработан взрослыми инженерами... Реакция была как на кислый лимон.
Те тоже не стали пачкать ручки оптимизацией и низким уровнем, бгг.
Вы, ребят, даже не сообразили, на что даёте ссылки. ))
Re[16]: понимание ООП Алана Кея
Здравствуйте, Ночной Смотрящий, Вы писали:

V>>В интерпретаторе спектрумовского Бейсика всё аналогично.

НС>Нет, совсем нет. Там именно исходная программа, просто в закодированном виде. Если по современному, то просто поток токенов.

Как я и думал, собсно.
Для некоторых команд проца IBM/360 аргументы тоже представляют себя эдакие токены.


НС>>>Непонятно. Что значит отделения и зачем он в этом топике?

V>>Это значит, что в практике IT редко встречается так, что язык диктует способ своей реализации.
НС>Но тот бейсик как раз демонстрирует обратное.

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


V>>Конечно, возможно.

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

Вообще-то получило.
Интроспекция дерева выражений Boost.Proto может происходить не только в рантайм, но и в момент компиляции через диспетчеризацию на шаблонах, т.к. любое выражение полностью статически типизировано и представляет из себя "плоский" граф, построенный на value-type в терминах дотнета.

Например, выражение expr:
auto x= _1;
auto y = _2;
auto expr = sin(x*10 + y*20);

порождает (на пальцах если) примерно такую структуру:
sin_(plus_(mul_(arg_<0>, const_<10>()), mul_(arg_<1>, const_<20>)))

Структура имеет нулевой размер (если служит базовым классом) или один байт в кач-ве самостоятельного значения (фиктивный байт, т.к. размер структуры не может быть меньше одного байта).
А эффективность её интерпретирования на порядок выше эффективности интерпретирования Expression<T> (до компиляции).

Соответственно, основное применение Boost.Proto — это compile-time генерация кода из некоего DSL (Boost.Proto, в отличие от Expression<T> позволяет переопределять дефолтную грамматику, доступные операторы, терминалы/нетерминалы, "ключевые слова" и т.д.).
В т.ч. можно в compile-time производить трансформацию AST, т.е. "компиллировать" свой DSL.

И напротив, связка linq/expression/queryable с подключаемыми провайдерами — чисто динамическая вещь.

Можно ли аналогичное сделать в С++, т.е., породить такое AST, которое возможно будет итерировать в рантайм не шаблонным кодом, а через систему интерфейсов (с целью динамической трансформации AST подключаемыми в рантайм провайдерами)? — можно.

Почему не было сделано?
Предположу, что по той причине, что работа с БД давно уехала с клиента на сервер и даже на веб-сервер, где плюсы не в топе популярности.

Когда плюсы теряли популярность в вебе, средний пинг по планете был 50-100 ms, т.е. экономия единиц ms ничего не давала.
К тому же, основные задержки по-прежнему в БД.


V>>Я вижу, что ты пытаешься утверждать, что байт-код таковым является только для виртуальных машин очень низкого уровня. ))

НС>Не я, это общепринятое определение. И, думаю, Синклер именно его имел в виду.

Как выяснилось, Синклер имел ввиду и вовсе AST-выражений, т.е. ближе к коду Бейсика, а не к низкоуровневому байт-коду.


НС>Если тебе хочется придумать собственную трактовку — ради бога


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


НС>но тогда все твои возражения теряют релевантность. И образуется именно та логическая каша, про которую я написал.


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

Был у нас коллективный курсовик для всей группы на 3-м курсе, в рамках которого была разработана учебная ОС.
В состав ОС входило ядро с пакетным планировщиком, одно устройство ввода, одно вывода, загрузчик и компилятор учебного советского языка (нц/кц, если помнишь) в байт-код стековой машинки.

Угадай с одного раза, зачем мы компиляли в байт-код?
Потому что мы были не способны за трудоёмкость курсовика (плюс небольшой свой опыт) компилять это всё в машинный код x86 со всеми его бесконечными спецификациями.
Это нетривиальная задача — порождать "ассемблерный код" реального нехилого проца.

Зато на языке высокого уровня (Си) написать интерпретатор своего упрощённого байт-кода — как два пальца об асфальт выделенной группе из 3-х студентов.
В итоге, ни на одном из этапов разработки мы не выходили на низкий уровень, кроме собственного уютного примитивного байт-кода.

Разумеется, в исходниках эта разработка была более-менее переносима на другие платформы, а значит байт-код получался автоматически переносимым.

Но это мы, студенты-третьекурсники.
А когда мне показывают, что похожий по технике Паскаль был разработан взрослыми инженерами... Реакция была как на кислый лимон.
Те тоже не стали пачкать ручки оптимизацией и низким уровнем, бгг.
Вы, ребят, даже не сообразили, на что даёте ссылки. ))