Привет, может кто-нибудь находил в инете инфу по метапрограммированию.
Интересуют принципы выделения и организации низкоуровневой структуры, и
методы конструирования мета-конструкций на основе предыдущего (нижнего) слоя понятий.
Нужно для создания древовидного конструктора программ.
— Основная идея — снизить порог вхождения в написание программ на любом языке,
используя принцип конструктора — каждая выбранная деталь определяет множество возможных
следующих деталей, что разгружает память от необходимости помнить синтаксис программы.
— Например, (Паскаль, консольный вариант) для создания программы достаточно заполнить два элемента —
название программы (строка) и список команд (дерево). Все другие секции (константы, типы,
переменные, процедуры), могут генерироваться для компилятора автоматически. Пользователь
будет их объявлять в первом месте использования. То есть редактирование в месте использования.
Динамически конструируемое дерево это легко позволяет.
— Уже несколько месяцев бьюсь над структурой конструирования мета-конструкций.
— Реализовать хотелось бы на javascript + sql (web kit html5), так как интересно сделать
конструктор на чистом браузере (для тачскринов).
по-большому счету, нет никаких специальных мета-конструкций.
есть лишь:
числа
логические величины
последовательности/множества/дерево/граф
операции над числами/логическими величинами/последовательностями и т.д.
исполнитель и операции над ним
мета же появляется только в виде того, что саму программу можно представить, например, в виде дерева. и применить к программе все те же самые операции, которые применяются к дереву.
типичным примером такого подхода являются макросы: когда программа рассматривается как текст (сишные макросы), или как дерево (nemerle)
слои же строятся на основе моделей/парадигм, например, поверх байтовой последовательности строятся сложные типы/структуры, поверх стеко-регистровой машинки строится ооп и т.д.
Здравствуйте, lseder, Вы писали:
L>Привет, может кто-нибудь находил в инете инфу по метапрограммированию. L>Интересуют принципы выделения и организации низкоуровневой структуры, и L>методы конструирования мета-конструкций на основе предыдущего (нижнего) слоя понятий.
... L>- Уже несколько месяцев бьюсь над структурой конструирования мета-конструкций.
Замах на рубль...
L>- Реализовать хотелось бы на javascript + sql (web kit html5), так как интересно сделать L>конструктор на чистом браузере (для тачскринов).
желания-то как раз все грамотные:
сейчас действительно не хватает простых средств разработки для веба,
и да, это действительно можно добиться через полуавтоматическую обработку мелочей,
и слоистую структуру программы
Здравствуйте, lseder, Вы писали:
L>Привет, может кто-нибудь находил в инете инфу по метапрограммированию. L>Интересуют принципы выделения и организации низкоуровневой структуры, и L>методы конструирования мета-конструкций на основе предыдущего (нижнего) слоя понятий.
Идея средства программирования, которое бы позволяло пользователю "складывать" программы из "кубиков" по аналогии с конктруктором LEGO витает очень давно. Однако все попытки сделать это провалились.
Вопрос — почему?
Здравствуйте, 0x7be, Вы писали:
0>Вопрос — почему?
1. В конечном счёте кубики уступают по выразительности нескольким строчкам кода.
2. Человек способен ошибаться, даже тасуя прямоугольники в графическом редакторе.
Здравствуйте, Sinix, Вы писали:
0>>Вопрос — почему? S>1. В конечном счёте кубики уступают по выразительности нескольким строчкам кода.
Когда надо написать "1+1", то да. А если я хочу, что-то более "масштабное", то надо быть Донцовой, чтобы быстро и "выразительно" получить желаемое.
S>2. Человек способен ошибаться, даже тасуя прямоугольники в графическом редакторе.
Это ты серьёзно сравниваешь количество ошибок при тусовании кубиков и при написании кода?
R3>Когда надо написать "1+1", то да. А если я хочу, что-то более "масштабное", то надо быть Донцовой, чтобы быстро и "выразительно" получить желаемое.
Наоборот что-то простое из кубиков получается быстро, красиво и выразительнее текста, чуть сложнее текст оказывается на порядок и проще и выразительнее.
Здравствуйте, Real 3L0, Вы писали:
R3>Вероятно потому, что всё это было не юзабельно. Кубики — они из названия подразумевают "лёгкость", но я ещё не встречал простого средства разработки.
Потому, что эти "кубики" не устраняли главной сложности в программировании, они решали не ту проблему.
Точно по той же причине провалились попытки сделать программирование простым, приблизив синтаксис языков к английскому.
Здравствуйте, 0x7be, Вы писали:
R3>>Вероятно потому, что всё это было не юзабельно. Кубики — они из названия подразумевают "лёгкость", но я ещё не встречал простого средства разработки. 0>Потому, что эти "кубики" не устраняли главной сложности в программировании, они решали не ту проблему.
А какую проблему они решали?
0>Точно по той же причине провалились попытки сделать программирование простым, приблизив синтаксис языков к английскому.
Здравствуйте, FR, Вы писали:
R3>>Когда надо написать "1+1", то да. А если я хочу, что-то более "масштабное", то надо быть Донцовой, чтобы быстро и "выразительно" получить желаемое. FR>Наоборот что-то простое из кубиков получается быстро, красиво и выразительнее текста, чуть сложнее текст оказывается на порядок и проще и выразительнее.
Мы живём в разных реальностях.
Пример 1.
Давай я тебе дам исходники, а ты не компилируя их, сможешь рассказать, что делает программа? Сколько времени у тебя на это уйдёт?
А теперь посмотрим на какой-нибудь бизнес-процесс, представленный в виде какой-нибудь модели (какой-нибудь нотации)? Сколь времени уйдёт на это? И заметь, я даже не уточнял — какую именно нотацию брать, что абсолютно невозможно опустить при просмотре исходников.
Пример 2.
Я уже как-то писал. Мне понадобилось в программу вставить проверку email-ящика. Просто — тупо открыть письмо и прочитать текст. ... Узнал много "офигенно полезной и нужной мне в данный момент" информации, типа MIME.
Или другой пример. Мне надо было подготовить данные, вставить их в контролы на форме, после чего показать форму пользователю. ... Узнал много "офигенно полезной и нужной мне в данный момент" информации, типа handle окна.
Здравствуйте, Real 3L0, Вы писали:
R3>Когда надо написать "1+1", то да. А если я хочу, что-то более "масштабное", то надо быть Донцовой, чтобы быстро и "выразительно" получить желаемое.
Да нет, просто в случае кода мы можем произвольно менять детализацию — вынося всё ненужное в методы и дописав мелкие костыли прям по месту. В случае с "кубиками" все костыли приходится изображать в виде кубиков же, что напрочь убивает юзабилити.
На самом деле, при наличии в команде хороших архитекторов и автоматизации контроля за качеством кода, результат по наглядности и удобству использования не сильно отстаёт от аналогичной блок-схемы.
S>>2. Человек способен ошибаться, даже тасуя прямоугольники в графическом редакторе. R3>Это ты серьёзно сравниваешь количество ошибок при тусовании кубиков и при написании кода?
Абсолютно. Как наглядный пример — попробуйте сделать что угодно неординарное в любом генераторе инсталляторов (например, в штатном от студии), и то же самое — кодом.
Пример из личной практики — на громадный пакет SSIS (workflow в чистом виде) ушло примерно 2 с половиной недели. В основном — на борьбу с дизайнером и дописывание своих action-ов. После чего всю эту радость выбросили нафиг и за день заменили самописным вариантом.
Здравствуйте, Sinix, Вы писали:
S>Да нет, просто в случае кода мы можем произвольно менять детализацию — вынося всё ненужное в методы и дописав мелкие костыли прям по месту. В случае с "кубиками" все костыли приходится изображать в виде кубиков же, что напрочь убивает юзабилити.
Как оно может убить то, чего нет? Повторюсь (и ты сам это знаешь) — на текущий момент нет юзабильной "платформы, управляющей кубиками". (*)
S>На самом деле, при наличии в команде хороших архитекторов и автоматизации контроля за качеством кода, результат по наглядности и удобству использования не сильно отстаёт от аналогичной блок-схемы.
+1. Только вот так и получается, чтобы написать "чтение почты из ящика", надо обладать знаниями архитектора. Не всем оно надо.
S>>>2. Человек способен ошибаться, даже тасуя прямоугольники в графическом редакторе. R3>>Это ты серьёзно сравниваешь количество ошибок при тусовании кубиков и при написании кода? S>Абсолютно. Как наглядный пример — попробуйте сделать что угодно неординарное в любом генераторе инсталляторов (например, в штатном от студии), и то же самое — кодом.
Не имел с этим дел. Но понимаю, ибо (*).
S>Пример из личной практики — на громадный пакет SSIS (workflow в чистом виде) ушло примерно 2 с половиной недели. В основном — на борьбу с дизайнером и дописывание своих action-ов. После чего всю эту радость выбросили нафиг и за день заменили самописным вариантом.
И опять (*).
Это всё равно, как развитие тачскрин-экранов: их придумали пару десяткок лет назад, но технология не стала популярной. Пока не появился сифон.
С кубиками пока такая же фигня: они придуманы давно, но нет удобного механизма их использования.
Если немного пофантазировать.
Кубики — это техника: определённу яму можно выкопать быстро и легко, но только определённым экскаватором. Чтобы выкопать яму другого размера, надо брать другой экскаватор. Маленькую ямку ("1+1") выкопать нельзя никаким экскаватором. Другой техникой — можно, но сразу много ямок. Чтобы проделать тунель для метро — нужна другая техника.
Но всё этом можно сделать обычной лопатой, причём включая маленькую ямку.
Так что, будем сильнее натачивать лопату или будем придумывать новую технику?
Вот например, есть ли хоть один "конструктор кубиков", который бы использовал онлайн-базу этих кубиков, что-то типа магазина-приложений? Я не встречал. О каком удобстве тогда стоит говорить, если нет основного механизма.
А если бы "нечто неординарное", что ты не смог сделать в генераторе инсталяторе, уже присутствовало бы в виде кубика в этом инсталяторе, ты бы тоже считал его "ацтоем"?
Конечно, через некоторое время тебе бы попался кубик, который выдаёт результат на 99% как надо, а 1% — не так. Если этот 1% для тебя очень важен, то сейчас переписывается весь кубик. Если же этот кубик состоял бы из других кубиков, то ты бы просто заменил ненужный кубик на правильный.
В общем, опять (*).
Здравствуйте, lseder, Вы писали:
L>Привет, может кто-нибудь находил в инете инфу по метапрограммированию. L>Интересуют принципы выделения и организации низкоуровневой структуры, и L>методы конструирования мета-конструкций на основе предыдущего (нижнего) слоя понятий.
Чего-то вменяемого для начинающих нет. Есть много разрозненной и очень специализированной информации, зачастую в научных работах.
Есть более менее продуманные и работающие решения: Lisp, Nemerle, MPS.
Есть куча решений застрявших на стадии прототипов.
L>Нужно для создания древовидного конструктора программ. L>- Основная идея — снизить порог вхождения в написание программ на любом языке, L>используя принцип конструктора — каждая выбранная деталь определяет множество возможных L>следующих деталей, что разгружает память от необходимости помнить синтаксис программы.
Какая-то не проработанная идея. Бессмысленная, я бы сказал.
Сокрытие деталей называется абстрагированием и инкапсуляцией. В программистском мире на сегодня имеется три проработанные концепции позволяющие добиться повышения абстракции:
1. Функции.
2. Объекты.
3. Языки предметной области — DSL.
Понизить порог вхождения они не могут, так как решают другую задачу — повышение уровня кода. Обычно чтобы понимать более высокоуровневый код нужно знать больше концепций, что никак не может понижать планку вхождения (если понимать под этим уровень знаний). Абстракция понижает сложность восприятия. Потратив время на понимание концепций потом можно быстрее понять программу целиком. Но это не тоже самое что понижение планки вхождения в язык.
L>- Например, (Паскаль, консольный вариант) для создания программы достаточно заполнить два элемента - L>название программы (строка) и список команд (дерево). Все другие секции (константы, типы, L>переменные, процедуры), могут генерироваться для компилятора автоматически. Пользователь L>будет их объявлять в первом месте использования.
Эту проблему просто не надо решать. Просто возьмите файл-заготовку где все секции уже будут и заполните только те секции что надо. Или еще проще — возьмите более современный язык в котором можно не писать всего этого оберточного кода (Руби, Питон, Немерл, Жабаскрипт, Лисп, ...).
L>То есть редактирование в месте использования. L>Динамически конструируемое дерево это легко позволяет.
А нужно ли это кому-либо? Мне кажется — нет.
Людям нужны более высокоуровневые конструкции.
Скажем в Яве отсутствуют такие концепции как лябды, итераторы, конструкции детерминированной финализации и т.п. По этому многие называют ее менее удобной и более низкоуровневой. Вот добавление таких конструкций в язык было бы оправдано.
Другой пример — встраивание в язык DSL-ей. Например, многие часто используют в своих программах SQL, XML и регексы. Встроить их в язык, так чтобы их было удобно использовать в этом языке даст ощутимую пользу. Во многие ЯП эти DSL-и хардкодятся. Это несомненно плохо. И возможность расширять базовый язык DSL-ями опять же полезна.
Но у вас какие-то сумбурные идеи. Они смело решаются текстовым препроцессором вроде препроцессора С.
Мне кажется вам нужно в первую очередь доработать свои идеи. А для этого имеет смысл познакомиться с теми идеями, что есть у других. И дело тут не в метапрограммирвоании.
L>- Уже несколько месяцев бьюсь над структурой конструирования мета-конструкций.
Я бьюсь над этой задачей последние 10 лет и пока что не доволен результатом на 100%.
L>- Реализовать хотелось бы на javascript + sql (web kit html5), так как интересно сделать L>конструктор на чистом браузере (для тачскринов).
sql то ту причем? Как он с броузерам может быть связан?
javascript, как многие скриптовые языки, обладает возможностями метапрограммирования за счет прототипного ООП и возможности динамически выполнять код. Средства эти не очень удобные, но приемлемые для использования.
ЗЫ
В общем, сначала постарайтесь сформулировать саму идею (задачу). А потом уже будет смысл думать о средствах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Real 3L0, Вы писали:
R3>Как оно может убить то, чего нет? Повторюсь (и ты сам это знаешь) — на текущий момент нет юзабильной "платформы, управляющей кубиками". (*)
Угу. Так предложите Проблема в том, что обычный код уже подошёл к пределу выразительности и даже уполз за него (если мы говорим о хардкорном ФП). Попробуйте выразить это
var customer = customers.Where(c => c.Age > 18 && c.NotBanned).Skip(123).FirstOrDefault();
в виде кубиков. А теперь — метод, в котором подобных строк — штук 5. А теперь — код, который оперирует парой сотен таких методов
R3>+1. Только вот так и получается, чтобы написать "чтение почты из ящика", надо обладать знаниями архитектора. Не всем оно надо.
Зависит от фреймворка. Если готовый компонент есть — какая разница между использованием его из кода или дизайнера? А вот если нет — с дизайнером всё, с кодом можно побарахтаться
R3>Это всё равно, как развитие тачскрин-экранов: их придумали пару десяткок лет назад, но технология не стала популярной. Пока не появился сифон. R3>С кубиками пока такая же фигня: они придуманы давно, но нет удобного механизма их использования.
Ну так тачскрин остаётся весьма узконишевой нишей. В качестве основного устройства управления он оччень неудобен, особенно — на больших экранах. Со всякими workflow-движками ситуация абшолютно аналогичная: не взлетят
R3>Так что, будем сильнее натачивать лопату или будем придумывать новую технику?
Увы, лучше затариться археологическими кисточками. Лопата — слишком грубый инструмент
R3>Вот например, есть ли хоть один "конструктор кубиков", который бы использовал онлайн-базу этих кубиков, что-то типа магазина-приложений? Я не встречал. О каком удобстве тогда стоит говорить, если нет основного механизма.
Ну будет онлайн магазин — что, появится контент? Неа, пара-тройка полезных вещей (о которых и так все кому надо знают) просто потонет под тонной багоподелок. И так — в любом магазине, спасает только поиск (если уже знаешь что искать).
R3>А если бы "нечто неординарное", что ты не смог сделать в генераторе инсталяторе, уже присутствовало бы в виде кубика в этом инсталяторе, ты бы тоже считал его "ацтоем"?
Неа. Потому что на все случаи жизни кубиков не напасёшься. Особенно для экзотики наподобие гусеничных ужоежей.
R3>Если же этот кубик состоял бы из других кубиков, то ты бы просто заменил ненужный кубик на правильный.
Угу. Тем самым взяв на себя обязанность сопровождать ещё и чужой кубик — следить за обновлениями, разруливать конфликты, править костыли... Ба, мы опять вернулись к тому, от чего убегали
Автор(ы): К. Чарнецки, У. Айзенекер
Кубики — они из названия подразумевают "лёгкость", но я ещё не встречал простого средства разработки.
