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

Хорошая статья о том, что нас больше всего волновало-бы, если бы первой закончилась
та часть закона Мура, которая о количестве транзисторов.
То есть его формулировали — каждые два года кол-во (читай — плотность) транзисторов
удваивается, а каждые полтора года удваивается скорость (частота).
Первой перестала действовать экспонента по увеличению частоты, экспонента по
увеличению плотности всё ещё действует (лет 5-10 ещё будет действовать).
Из-за увеличения числа транзисторов — сейчас индустрия озабочена больше
переходом на многоядерные CPU. А проблему разницы скорости процессора и
памяти решают увеличением кэша, сложными предвыборками и пр. Хотя и тут
некоторые приложения могут выиграть в скорости работы в разы (при правильной
организации данных в памяти), всё-же эта проблема пока отступает перед
проблемой — что делать со всеми этими транзисторами. В ядро уже влепили
несколько блоков ALU, FP, добавили блоки для векторной арифметики,
удвоили это всё большим количеством регистров (для каждой стадии конвеера),
оптимистичным исполнением и т.п. и т.д. Добавили гигантские кэши
(увеличение которых уже почти не даёт ускорения). А транзисторов всё прибывает,
и как их эффективно использовать — непонятно. Разве только переходом на
многоядерность, интегрированием разнородных ядер и пр. Отсюда и основное
движение в софтостроении — распарраллелить, приготовится к приходу 8-16-32
ядерных процессоров...

А если бы первой закончилась та часть закона Мура, которая о кол-ве транзисторов,
а частота продолжала-бы расти экспоненциально? Вот тогда-бы все говорили
только об этом — как быстрее добраться до памяти. Потому как проходило-бы не
200, а 2000 тактов при доступе к памяти, транзисторов для безмерного кэша просто
не было-бы, и так далее. Архитектура процессоров бы менялась именно в этом направлении.

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

Весёлое будет время.

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

M>Весёлое будет время.
И тут придет твоя сумаде и всех спасет?
Угадал?


Вот только ты так и не сказал как.

Давай без речей типа ньюВасюки.
Все хотят видить техническое обоснование.

Отказ от текста обоснованием не является.

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

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

M>>Весёлое будет время.
WH>И тут придет твоя сумаде и всех спасет?
WH>Угадал?
WH>

Не знаю. Зависит от того, что ты понимаешь под спасением.
Если некую панацею — нет, SymADE не панацея.
Просто эта технология позволяет перейти на новый уровень сложности программ
(за счёт повышения уровня адаптивности, в том числе и адаптивности к
новым аппаратным архитектурам), как раньше OOP позволил перейти на новый уровень
сложности программ.

WH>Вот только ты так и не сказал как.

Сказал, но ты не там искал

WH>Давай без речей типа ньюВасюки.
WH>Все хотят видить техническое обоснование.

WH>Отказ от текста обоснованием не является.

Речь идёт от отказе от того уровня стандартизации языков программирования,
которые мы сейчас имеем. Отказ от текстового представления является
необходимым условием для этого (альтернативно прийдётся использовать
примитивный синтаксис а-ля Lisp/Forth).

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

M>Отказ от текстового представления является
M>необходимым условием для этого (альтернативно прийдётся использовать
M>примитивный синтаксис а-ля Lisp/Forth).

А это почему? И в пользу чего? Текст — это, наверное, одно из самых компактных представлений информации, в том смысле, что на единицу площади, например листа, можно уложить больше всего, и при этом (самое главное) — такое представление будет понятно человеку.

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

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

M>Если некую панацею — нет, SymADE не панацея.
Если верить твоим речам то таки панацея.

M>Просто эта технология позволяет перейти на новый уровень сложности программ
За счет чего?

M>(за счёт повышения уровня адаптивности, в том числе и адаптивности к новым аппаратным архитектурам),
На сколько новым?
Вернее насколько разнам?
Если в приделах вариаций на тему фон Неймоновской архитектуры то это не интересно.
В этих приделах может адаптироваться практически все.

WH>>Вот только ты так и не сказал как.
M>Сказал, но ты не там искал
Я искал базис на котором все будет работать.
Но что-то не вижу.

M>Речь идёт от отказе от того уровня стандартизации языков программирования, которые мы сейчас имеем.
Предлагаешь жить без стандартов?
Или как?

M>Отказ от текстового представления является необходимым условием для этого
Ну этого ты пока не показал.
Пока что вся аргументация сводилась к чемуто типа: "Бедные индусы не поймут что написано на языке высокого уровня."
Проблема в том что реализацию распределенных транзакций они не поймут по любому.

M>(альтернативно прийдётся использовать примитивный синтаксис а-ля Lisp/Forth).
Те ты изобрел что-то типа лиспа или форта?
Замечательно.
Значит у этого чегото должна быть очень простая вычислительная модель которую можно подробно описать за пару часов максимум.
И это вложение окупится ибо такие как я смогут понять что к чему.

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

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

M>>Отказ от текстового представления является
M>>необходимым условием для этого (альтернативно прийдётся использовать
M>>примитивный синтаксис а-ля Lisp/Forth).

С>А это почему? И в пользу чего? Текст — это, наверное, одно из самых компактных представлений информации, в том смысле, что на единицу площади, например листа, можно уложить больше всего, и при этом (самое главное) — такое представление будет понятно человеку.

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

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

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

M>Так вот, имея программу в виде дерева, можно отображать в любой
M>удобной форме — например, показывая типы (в декларациях) или не показывая их. Но это самый мизер
M>из предоставляющихся возможностей гибкого отображения (и редактирования) кода программ.

Ну, гибкость в отображении — это хорошо, а вот поможет ли это в редактировании, пока не очеидно.
Вот, например, при представлении кода в виде простого текстового файла я могу сохранить его даже, если в нем есть ошибки (хоть лексические, хоть грамматические). А вот в случае баз данных так не получится, так как данные должны быть согласованны, и промежуточные результаты хоть на салфетке записывай...
Так вот, что представляет собой описание программы в виде дерева, в свете этих двух альтернатив? Как учитывается временная несогласованность частей? И каков формат хранения данных — бинарный или текстовый?

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

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

M>>Так вот, имея программу в виде дерева, можно отображать в любой
M>>удобной форме — например, показывая типы (в декларациях) или не показывая их. Но это самый мизер
M>>из предоставляющихся возможностей гибкого отображения (и редактирования) кода программ.

С>Ну, гибкость в отображении — это хорошо, а вот поможет ли это в редактировании, пока не очеидно.
С>Вот, например, при представлении кода в виде простого текстового файла я могу сохранить его даже, если в нем есть ошибки (хоть лексические, хоть грамматические). А вот в случае баз данных так не получится, так как данные должны быть согласованны, и промежуточные результаты хоть на салфетке записывай...
С>Так вот, что представляет собой описание программы в виде дерева, в свете этих двух альтернатив? Как учитывается временная несогласованность частей? И каков формат хранения данных — бинарный или текстовый?

Лексических и грамматических ошибок в дереве быть не может, по определению. Там лексики нет, и парсера нет.
Все ошибки в них могут быть только семантические. Конечно, ты можешь сохранить файл с ошибками. Пофиг что сохранять — просто дерево дампится в файл.
В текстовом или бинароном виде — тоже пофиг. Сейчас я дамплю в xml-е. Конечно, можно написать имя класса "this$is_a`тип", а вот правильное оно или нет — определится только когда ты выберешь конкретный backend — в некоторых $_` можно использовать в именах, а в других нет. В некоторых имена типов должны начинаться с большой буквы. А в других можно использовать только ascii, уникод нельзя.

Каждый узел дерева — это просто:
а) имя узла (в смысле — тип, то есть "Var" или "PrefixExpression")
б) набор примитивных аттрибутов (int, string, и т.п.)
в) набор под-узлов
г) символьные ссылки на другие узлы (само имя + uuid)
В отличие от, скажем, Lisp-а — у узла есть тип (имя типа), и слоты под аттрибуты/под-узлы именованные (а не по индексу в списке).
Конечно, можно использовать примитивный синтаксис, вроде
(PrefixExpression operator="!" expr=(BoolConst value="true"))
но это будет ещё менее удобно, чем лисп, а смысла практически никакого. Если уж так надо сохранить текст, можно использовать разработку языка вроде XL.

Конечно, этого слишком мало для нормальной работы. Просто это минимум, после определения которого узел будет опознаваться в системе.
А потом на него навешивается дополнительная информация — как отображать/редактировать, как проверять семантическую правильность, как трансформировать в конкретный backend или делать "нормализацию"%, навесить control-flow информацию (если будет использоваться в языке с выводом типов), навесить проверку типов, навесить резолвинг имён и т.п. и т.д. Всего этого в Lisp-е за задать.

Отличие от современных средств разработки в том, что эта информация задаётся централизованно, единожды заданная она используется всеми средствами.
Скажем, если я задал правила резолвинга имён — это используется и в компиляторе, и в редакторе для авто-комплита.
Дерево версионное, можно открывать транзакции, в которые будут автоматом записываться все изменения — и версионность используется и редактором
для undo, и компилятором для отката ненужных трансформаций и т.п.

Конечно, синтаксис никуда не делся. Просто это не текстовый синтаксис, это описание формата узла (имени, имён и типов аттрибутов) и формата дополнительной информации.

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

M>>Отказ от текстового представления является необходимым условием для этого
WH>Ну этого ты пока не показал.
Сам смотри, если есть чем.
WH>Пока что вся аргументация сводилась к чемуто типа: "Бедные индусы не поймут что написано на языке высокого уровня."
Этой аргументации ты от меня услышать не мог, потому как не было её.
WH>Проблема в том что реализацию распределенных транзакций они не поймут по любому.
Проблема в языке, на котром эти транзакции излагаются.

M>>(альтернативно прийдётся использовать примитивный синтаксис а-ля Lisp/Forth).
WH>Те ты изобрел что-то типа лиспа или форта?
WH>Замечательно.
WH>Значит у этого чегото должна быть очень простая вычислительная модель которую можно подробно описать за пару часов максимум.
WH>И это вложение окупится ибо такие как я смогут понять что к чему.

Ты умеешь просто фантастически неправильно понять. Выдёргиваешь знакомое слово, и у тебя несётся туева хуча ассоциаций,
никак к делу не относящихся.
SymADE — это не язык программирования и не процессор. Это среда разработки. У неё нет вычислительной модели.

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

M>Здравствуйте, Стэн, Вы писали:

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

M>>>Так вот, имея программу в виде дерева, можно ...

M>Конечно, этого слишком мало для нормальной работы. Просто это минимум, после определения которого узел будет опознаваться в системе.
M>А потом на него навешивается дополнительная информация — как отображать/редактировать, как проверять семантическую правильность, как трансформировать в конкретный backend или делать "нормализацию"%, навесить control-flow информацию (если будет использоваться в языке с выводом типов), навесить проверку типов, навесить резолвинг имён и т.п. и т.д. ...

Забавно, но именно под таким соусом мне подают сейчас лисп
Вопрос — сколько имеющихся backends имеют понятие о cache-conscious data structures ? Или это по принципу "это все оставлено как упражнение для читателя".

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

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

M>>Здравствуйте, Стэн, Вы писали:

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

M>>>>Так вот, имея программу в виде дерева, можно ...

M>>Конечно, этого слишком мало для нормальной работы. Просто это минимум, после определения которого узел будет опознаваться в системе.
M>>А потом на него навешивается дополнительная информация — как отображать/редактировать, как проверять семантическую правильность, как трансформировать в конкретный backend или делать "нормализацию"%, навесить control-flow информацию (если будет использоваться в языке с выводом типов), навесить проверку типов, навесить резолвинг имён и т.п. и т.д. ...

SD>Забавно, но именно под таким соусом мне подают сейчас лисп

Да? Про отображение/редактирование попродробней, плиз. Кто, где, что делает.

SD>Вопрос — сколько имеющихся backends имеют понятие о cache-conscious data structures ? Или это по принципу "это все оставлено как упражнение для читателя".

Это оставлено как упражнение для производителей железа и компиляторов. А SymADE решает задачу возможности расширения языков соответствующими
семантическими понятиями. А равно и семантическими понятиями для всех остальных целей. И начинал этот разговор я с того, что
проблемы латентности памяти или многотредовости — это достаточно мелкие проблемы, по сравнению с теми, что ожидают нас в недалёком
будущем. И вот SymADE — это технология, парадигма решения этих проблем. А не само решение. Так же, как, скажем, OOP или FP — это
парадигма, технология решения определённых проблем, а не конкретные программы и не конкретные языки программирования для
конкретных backend-ов.

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

M>>>>>Так вот, имея программу в виде дерева, можно ...
SD>>Забавно, но именно под таким соусом мне подают сейчас лисп
M>Да? Про отображение/редактирование попродробней, плиз. Кто, где, что делает.

Отображением и редактированием занимается текстовый редактор

SD>>Вопрос — сколько имеющихся backends имеют понятие о cache-conscious data structures ? Или это по принципу "это все оставлено как упражнение для читателя".

M>Это оставлено как упражнение для производителей железа и компиляторов. А SymADE решает задачу возможности расширения языков соответствующими
M>семантическими понятиями. А равно и семантическими понятиями для всех остальных целей. И начинал этот разговор я с того, что
M>проблемы латентности памяти или многотредовости — это достаточно мелкие проблемы, по сравнению с теми, что ожидают нас в недалёком
M>будущем. И вот SymADE — это технология, парадигма решения этих проблем. А не само решение. Так же, как, скажем, OOP или FP — это
M>парадигма, технология решения определённых проблем, а не конкретные программы и не конкретные языки программирования для
M>конкретных backend-ов.

Пока вы не решили 1 конкретную задачу, то парадигма — пустой звук. Вот например cache-conscious. Это проблема тк любое высокоуровневое описание этому делу в лучшем случае не помогает. предлагаемая идея в стиле "давайте все засунем в xml/lisp/ast" это не решение ни одной из задач. это в лучшем случае декларация намерений ее решить. Потому как эта форма описания не работает, а та которая работает — не высокоуровневая. И по сравнению с обычным boilterplate нужно иметь проблему например с деталями xml и инструментами отладки.
То есть утверждение что "эта задача не такая важная" это не конструктивно.
Меня кстати очень интересует набор инструментов, который бы позволял такие вещи как cache-conscious манипуляции с си в качестве target platform. Можете продемонстрировать пример ?

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

WH>>Ну этого ты пока не показал.
M>Сам смотри, если есть чем.
Есть чем. Но не на что.

WH>>Проблема в том что реализацию распределенных транзакций они не поймут по любому.
M>Проблема в языке, на котром эти транзакции излагаются.
Нет. Проблема в алгоритмах.
Ты сам то пробовал делать распределенные транзакции?
Или хотябы локальные?

M>Ты умеешь просто фантастически неправильно понять. Выдёргиваешь знакомое слово, и у тебя несётся туева хуча ассоциаций, никак к делу не относящихся.
Где уж нам уж.

M>SymADE — это не язык программирования и не процессор. Это среда разработки. У неё нет вычислительной модели.
Ты же пишешь в этой среде программы. Так?
Далие эта среда переводит эти программы в некий другой вид (например байткод JVM).
Следовательно просто обязан быть нейкий базис относительно которого будут происходить трансформации.
Его просто не может не быть физически.

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

M>>SymADE — это не язык программирования и не процессор. Это среда разработки. У неё нет вычислительной модели.
WH>Ты же пишешь в этой среде программы. Так?
WH>Далие эта среда переводит эти программы в некий другой вид (например байткод JVM).
WH>Следовательно просто обязан быть нейкий базис относительно которого будут происходить трансформации.
WH>Его просто не может не быть физически.

Ну нету его. Какая вычислительная модель у Eclipse? Никакой. Есть плагины к Eclipse, в которых
и реализуется компиляция кода, отдельный плагин для Java, отдельный для C++ и так далее.
Eclipse предоставляет платформу — редакторы, средства сохранения настроек, GUI и т.п.
Так же и SymADE — это платформа для компиляторов.
Отличия SymADE от Eclipse в том, что Eclipse вообще никак не стандартизирует внутреннее представление
програм на разных языках, а в SymADE это внутренее представление стандартизировано. В SymADE есть
набор "заготовок" общих для разных языков программирования, но он не требует, чтоб эти "заготовки"
использовались конкретным компилятором (плагином). Заготовки — это типа "Var", "Class", "Method",
"BinaryExpr" и т.д. Скажем, единственный реализованный у меня сейчас компилятор (в java bytecode)
берёт эти заготовки и трансформирует дерево в соответствии со своим представлением. Например, берёт
"заготовку" AccessExpr, у которого есть два аттрибута (под-узла) — accessor и lvalue-decl.
Если accessor — ThisExpr или просто другое выражение, то он заменяет этот узел на явовский
узел InstanceFieldAccessExpr. А если это TypeReference, то заменяет на StaticFieldAccessExpr.
И так далее. В конце трансформации получается набор из семантических узлов непосредственно
соответствующих понятиям JVM. У меня два backend-а, один дампит это дерево как явовский source
code, а другой дампит это-же дерево в java bytecode.
Практически все расширения к яве у меня реализованы как эти плагины, трансформирующие дерево.
Собственно, и сами добавления к яве в версиях больше 1.0 тоже реализованы как плагины. Плагин
и семантические узлы для enum-ов, плагин и семантические узлы для assert-ов и т.д.
Скажем, моё расширение для generic types позволяет в рантайме получать тип аргументов у контейнера.
Для этого он вставляет во все NewExpr и во все аргументы Constructor-ов этих контейнеров
специально генерируемые данные, потом модифицирует InstanceOfExpr, CastExpr, NewExpr, NewArrayExpr
и другие явовские узлы так, что они используют эти сгенерированные данные в рантайме. А для
.NET подобное не нужно генерировать, он это сам поддерживает, такой трансформер дерева
можно не использовать.

Но сам SymADE ничего не вычисляет. Точнее, если у узла заданы сведения о том, как резолвить в нём
имена, как получить его тип, какой у него data/control flow — они вычисляются. А трансформации
производятся плагинами и backend-ами (которые, собственно говоря, тоже плагины).

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

M>Отличия SymADE от Eclipse в том, что Eclipse вообще никак не стандартизирует внутреннее представление програм на разных языках, а в SymADE это внутренее представление стандартизировано.
Очень интересно.
Каким образом?

M>В SymADE есть набор "заготовок" общих для разных языков программирования, но он не требует, чтоб эти "заготовки" использовались конкретным компилятором (плагином).
Что будет если в дереве есть некие узлы которые не понимает бекенд?
Например комуто захочется использовать континюэйшены. Как ты код с континюэйшенами превратишь в жабовский байткод?

M>Заготовки — это типа "Var", "Class", "Method", "BinaryExpr" и т.д.
Те все языки ограничиваются жабой и C#ом?

M>Скажем, единственный реализованный у меня сейчас компилятор (в java bytecode) берёт эти заготовки и трансформирует дерево в соответствии со своим представлением. Например, берёт "заготовку" AccessExpr, у которого есть два аттрибута (под-узла) — accessor и lvalue-decl.
M>Если accessor — ThisExpr или просто другое выражение, то он заменяет этот узел на явовский узел InstanceFieldAccessExpr. А если это TypeReference, то заменяет на StaticFieldAccessExpr.
А что делать с хаскелем?

M>И так далее. В конце трансформации получается набор из семантических узлов непосредственно соответствующих понятиям JVM. У меня два backend-а, один дампит это дерево как явовский source code, а другой дампит это-же дерево в java bytecode.
Короче из того что я вижу тебе нужно срочно менять позиционирование своей сумаде как мегатул для жабы.
Но не для решения вобще всех проблем человечества.

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

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

M>>Отличия SymADE от Eclipse в том, что Eclipse вообще никак не стандартизирует внутреннее представление програм на разных языках, а в SymADE это внутренее представление стандартизировано.
WH>Очень интересно.
WH>Каким образом?

Метаданными, данными и операциями которые можно производить над узлами дерева/графа.
Чуть выше я об этом писал (не тебе).

M>>В SymADE есть набор "заготовок" общих для разных языков программирования, но он не требует, чтоб эти "заготовки" использовались конкретным компилятором (плагином).
WH>Что будет если в дереве есть некие узлы которые не понимает бекенд?

В этот бэкэнд скомпилировать код использующий эти узлы — будет нельзя.

WH>Например комуто захочется использовать континюэйшены. Как ты код с континюэйшенами превратишь в жабовский байткод?

В ПРЫНЦЫПЕ это можно сделать. Только это будет настолько неэффективно, что никто даже заморачиваться не будет.
Но если кому-то нужно — то можно сделать. Не continuation в полном виде, а некий урезанный вариант, который
покроет его нужды. Что-то подобное я и сделал для своего логического движка — мне нужен был backtracking,
yield, и я их сделал — для конкретного типа методов.

M>>Заготовки — это типа "Var", "Class", "Method", "BinaryExpr" и т.д.
WH>Те все языки ограничиваются жабой и C#ом?

Языков в твоём понимании там вообще нет. Есть семантические понятия, можно создавать (чисто для удобства) онтологии
оных, которые будут являтся аналогом языка программирования. Но в коде программы можно легко смешивать любые
семантические узлы. Если backend тебя не поймёт — это не проблемы SymADEа. Это проблемы того кто писал код
и кто писал backend. Кому надо Var в хаскеле (неком гипотетическом хаскелевском backend-е) — тот и через
IO сделает генерацию кода для них.

M>>Скажем, единственный реализованный у меня сейчас компилятор (в java bytecode) берёт эти заготовки и трансформирует дерево в соответствии со своим представлением. Например, берёт "заготовку" AccessExpr, у которого есть два аттрибута (под-узла) — accessor и lvalue-decl.
M>>Если accessor — ThisExpr или просто другое выражение, то он заменяет этот узел на явовский узел InstanceFieldAccessExpr. А если это TypeReference, то заменяет на StaticFieldAccessExpr.
WH>А что делать с хаскелем?

Подумай.

M>>И так далее. В конце трансформации получается набор из семантических узлов непосредственно соответствующих понятиям JVM. У меня два backend-а, один дампит это дерево как явовский source code, а другой дампит это-же дерево в java bytecode.
WH>Короче из того что я вижу тебе нужно срочно менять позиционирование своей сумаде как мегатул для жабы.

Спасибо, я пешком постою.

WH>Но не для решения вобще всех проблем человечества.

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

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

M>Метаданными, данными и операциями которые можно производить над узлами дерева/графа.
Ясно. Святым духом.

M>В этот бэкэнд скомпилировать код использующий эти узлы — будет нельзя.
Ясно.
Будет весьма ограниченное колличество узлов которые будут отображатся в весьма ограниченное колличество очень похожих бекендов.
Видимо только шарп и жаба.
Ну может что-то еще сильно похожее на первые 2.

M>В ПРЫНЦЫПЕ это можно сделать.
Ну очень в принципе ибо жаба полна по Тьюрингу.
Проблема в том что придется натгивать на жабу другую вычислительную модель.

M>Только это будет настолько неэффективно, что никто даже заморачиваться не будет.
Во-во.

M>Но если кому-то нужно — то можно сделать. Не continuation в полном виде, а некий урезанный вариант, который покроет его нужды.
Любители континьейшенов очень любят call/cc. Так что захотят именно его.
Еще они любят shift/reset тоже не подарок.

M>Языков в твоём понимании там вообще нет.
А тебе что извесно мое понимаение языков?
Не думаю.
Ибо твое семантическое дерево в моем понимании это тоже язык.

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

M>Есть семантические понятия, можно создавать (чисто для удобства) онтологии оных, которые будут являтся аналогом языка программирования. Но в коде программы можно легко смешивать любые семантические узлы.
Не любые, а только те что понимает бекенд.

Также нужно понимать что некоторые узлы просто физически не совместимы друг с другом.
Например call/cc и конструкторы/деструкторы из С++.
Ты просто не сможешь написать бекенд который превратит дерево с этими узлами во что-то осмысленное.

M>Если backend тебя не поймёт — это не проблемы SymADEа.
M>Это проблемы того кто писал код и кто писал backend.
Нет это проблемы сумаде.
Ибо код написанный под один бекенд не будет работать на другом бекенде.
Те вся переносимость идет в топку.

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

M>>Есть семантические понятия, можно создавать (чисто для удобства) онтологии оных, которые будут являтся аналогом языка программирования. Но в коде программы можно легко смешивать любые семантические узлы.
WH>Не любые, а только те что понимает бекенд.

WH>Также нужно понимать что некоторые узлы просто физически не совместимы друг с другом.
WH>Например call/cc и конструкторы/деструкторы из С++.
WH>Ты просто не сможешь написать бекенд который превратит дерево с этими узлами во что-то осмысленное.

M>>Если backend тебя не поймёт — это не проблемы SymADEа.
M>>Это проблемы того кто писал код и кто писал backend.
WH>Нет это проблемы сумаде.
WH>Ибо код написанный под один бекенд не будет работать на другом бекенде.
WH>Те вся переносимость идет в топку.

Ты так уверенно писал, что тебе всё ясно, что я просто в растерянности от последовавших неверных выводов.
Чего же ты проигнорировал реализацию Var в хаскеле через IO? Наверное, она мешала стройности твоего
понимания. Потому как этот пример чётко показывает, что вставлять можно любые узлы, и эти узлы могут
быть трансформированны так, чтоб их понял backend.
Кроме того, где ты видел обещание переносимости? Я такого не обещал.
Переносимо писать в SymADE можно, но для этого надо выполнить некоторые условия.
Главное — надо писать семантику, а не реализацию. То есть, надо писать log INFO "Cannot do this",
где log — это семантическое понятие, имеющий атрибут для severity и атрибут для текста сообщения.
А не getLogger().logInfo("Cannot do this"), потому как этот код использует конкретную библиотеку
и конкретный язык. На платформе, где нет backend-а для этого языка или нет реализации этой библиотеки —
программа и не скопилится. А некий абстрактный log можно скомилировать практически во что угодно,
на какой угодно платформе и используя кучу разных средств. А можно вообще выкинуть, если копилируется
с настройками не выводить логгинга. Вот поэтому и назвал Чарльз Симони похожую технологию — intentional
programming. Потому как она предполагает кодировать намерения программиста, а не конкретный код
под конкретную платформу. А компьютер по возможности автоматизирует компиляцию в конкретный код под
конкретную платформу.

Ты всё ищешь в SymADE панацею. Хоть я тебе уже не раз говорил — это не она. Но это хороший
инструмент для автоматизации работы программиста, чтоб компьютер думал вместо него. А если
ты будешь этот инструмент использовать как просто среду для набивания кода в старом языке
программирования — много ты с него не получишь. Точно так-же, как используя компилятор C++
для компиляции C-шных исходников — никакого эффекта от ООП компилера ты не заметишь. ООП
виноват будет?

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

M>Ты так уверенно писал, что тебе всё ясно, что я просто в растерянности от последовавших неверных выводов.
Не верных или не укладывающихся в твою картинку мира?

M>Чего же ты проигнорировал реализацию Var в хаскеле через IO?
А что на него реагировать?

Меня другое интересует: Почему ты проигнорировал невозможность укатать в одно дерево call/cc и деструкторы С++?

Наверное, она мешала стройности твоего понимания.

(С)Ты
Ы?

M>Потому как этот пример чётко показывает, что вставлять можно любые узлы, и эти узлы могут быть трансформированны так, чтоб их понял backend.
IO в хаскеле показывает что можно выкрутится в одном частном случае.
Причем данный частный случай не содержит противоречий внутри дерева.
А может и не повести... см про call/cc и деструкторы.

M>Кроме того, где ты видел обещание переносимости?
А в чем смысл без переносимости?

M>Переносимо писать в SymADE можно, но для этого надо выполнить некоторые условия.
M>Главное — надо писать семантику, а не реализацию. То есть, надо писать log INFO "Cannot do this", где log — это семантическое понятие, имеющий атрибут для severity и атрибут для текста сообщения. А не getLogger().logInfo("Cannot do this"), потому как этот код использует конкретную библиотеку и конкретный язык.
Да пойми ты наконец что это твое семантическое дерево и есть язык и log INFO "Cannot do this" часть программы на этом языке.

M>На платформе, где нет backend-а для этого языка или нет реализации этой библиотеки — программа и не скопилится.
Те будет еще хуже чем с С++.
Чтобы программа компилировалась на разных платформах придется жить с очень не большим колличеством узлов которые понимют наиболие распространенные бекенды.

M>А некий абстрактный log можно скомилировать практически во что угодно, на какой угодно платформе и используя кучу разных средств.
M>А можно вообще выкинуть, если копилируется с настройками не выводить логгинга.
Ты просто не предстваляешь в какой геморой при деплойменте выльются такие выкрутасы.

M>Ты всё ищешь в SymADE панацею. Хоть я тебе уже не раз говорил — это не она.
Это несколько расходится с твоими речами про то что всем кто не будет использовать сумаде будет ой как плохо.

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

M>А если ты будешь этот инструмент использовать как просто среду для набивания кода в старом языке программирования — много ты с него не получишь.
И я о томже... ибо от языков ты никуда не ушол.
Семантическое дерево это язык.

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

M>>Но если кому-то нужно — то можно сделать. Не continuation в полном виде, а некий урезанный вариант, который покроет его нужды.
WH>Любители континьейшенов очень любят call/cc. Так что захотят именно его.
WH>Еще они любят shift/reset тоже не подарок.

Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках).