Когда-то в университете занимался subj'евой тематикой,
даже диплом по этой теме писал.
Автоматический синтез программы -- это когда текст программы
создаётся по спецификации задачи (ну и знаниям предметной области).
Потом эту тему забросил, а вот сейчас снова стало любопытно,
какие есть разработки.
Такое впечатление, что после древних работ Тыугу
"Концептуальное программирование" и Ильина
"Система порождения программ" больше ничего не
было.
И что, действительно, такое многообещающее направление
никому не интересно?? Есть тут кто-то, занимающийся подобным?
Можете написать, что сейчас в мире на эту тему происходит?
Здравствуйте, dimgel, Вы писали: M>>И что, действительно, такое многообещающее направление никому не интересно??
Ну, универсальный механизм создать не удалось — народ и несколько забросил. D>Выглядит заявкой на серебряную пулю. На входе — задача, на выходе — кнопка "сделать п----то". Сказки.
Нет.
Только не нужно писать УНИВЕРСАЛЬНЫЙ всемогутер.
Если ограничиться некоторой предметной областью — то вполне можно.
Вопрос в объеме задач предметной области.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, malphunction, Вы писали:
M>Когда-то в университете занимался subj'евой тематикой, M>даже диплом по этой теме писал.
это случайно не является частным (или общем) случаем метапрограммирования? метапрограммированием я интересуюсь давно и эта область активно развивается. метапрограммирование это когда результатом работы программы является программа, причем рекурсивно. и на верхнем уровне абстракции не только язык может быть предельно выразительным, нет! на вернем уровне абстракции могут быть данные, на основе которых автоматически генерируется программа для их обработки.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[3]: Автоматический синтез программ -- что нового?
Здравствуйте, LaptevVV, Вы писали:
LVV>Если ограничиться некоторой предметной областью — то вполне можно. LVV>Вопрос в объеме задач предметной области.
Да, так и есть. В дипломе делал такую штуку для школьной геометрии
(для задачек типа "даны длины сторон и углы какой-то штуки, найти параметры другой штуки"),
худо-бедно получалось синтезировать программки, решающие такие
задачки.
Re[2]: Автоматический синтез программ -- что нового?
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, malphunction, Вы писали:
M>>Когда-то в университете занимался subj'евой тематикой, M>>даже диплом по этой теме писал. М>это случайно не является частным (или общем) случаем метапрограммирования? метапрограммированием я интересуюсь давно и эта область активно развивается. метапрограммирование это когда результатом работы программы является программа, причем рекурсивно. и на верхнем уровне абстракции не только язык может быть предельно выразительным, нет! на вернем уровне абстракции могут быть данные, на основе которых автоматически генерируется программа для их обработки.
По вашему описанию, похоже на Турчинское метапрограммирование в языке Рефал.
Мой "автоматический синтез", в общем-то, рядом, но не совсем метапрограммирование.
Впрочем, интересно было бы почитать о современном уровне исследований по
метапрограммированию, можете накидать ссылок?
Здравствуйте, malphunction, Вы писали:
M>Когда-то в университете занимался subj'евой тематикой, M>даже диплом по этой теме писал.
M>Автоматический синтез программы -- это когда текст программы M>создаётся по спецификации задачи (ну и знаниям предметной области).
Формальное описание того, как должна работать программа имеет туже сложность, что и сама программа.
M>И что, действительно, такое многообещающее направление M>никому не интересно?? Есть тут кто-то, занимающийся подобным?
Это такое же программирование, только на языке предметной области.
Здравствуйте, malphunction, Вы писали:
M>Когда-то в университете занимался subj'евой тематикой, M>даже диплом по этой теме писал.
M>Автоматический синтез программы -- это когда текст программы M>создаётся по спецификации задачи (ну и знаниям предметной области).
Здравствуйте, malphunction, Вы писали:
M>Когда-то в университете занимался subj'евой тематикой, M>даже диплом по этой теме писал.
M>Автоматический синтез программы -- это когда текст программы M>создаётся по спецификации задачи (ну и знаниям предметной области).
M>Потом эту тему забросил, а вот сейчас снова стало любопытно, M>какие есть разработки.
M>Такое впечатление, что после древних работ Тыугу M>"Концептуальное программирование" и Ильина M>"Система порождения программ" больше ничего не M>было.
M>И что, действительно, такое многообещающее направление M>никому не интересно?? Есть тут кто-то, занимающийся подобным? M>Можете написать, что сейчас в мире на эту тему происходит?
Как-то читал книгу "Порождающее программирование". Впечатлило, что можно создать программу из кусочков на основе спецификации. Но сразу же было видно, что написать и отладить "порождающую программу было очень сложно. Посчитал, что писать "порождающую программу" нужно только если существует очень много вариантов "порожденных программ". Но тема тоже заинтересовала.
Думаю это направление сейчас вылилось:
а) кодогенераторы. Таковых существует много под различные задачи.
б) метапрограммирование. Тот же кодогенератор, но без явного промежуточного этапа в виде кода программы.
Сложности все те же — сложность написания и отладки.
Здравствуйте, Rinbe, Вы писали:
M>>Автоматический синтез программы -- это когда текст программы M>>создаётся по спецификации задачи (ну и знаниям предметной области).
R>Формальное описание того, как должна работать программа имеет туже сложность, что и сама программа.
Не совсем, формально задается не "как должна работать программа", а что она должна выдавать. В общем-то компиляторы функциональных языков или даже оптимизаторы реляционных запросов вполне попадают в эту категорию.
Автору: попробуй погуглить по словам generative programming.
no fate but what we make
Re[3]: Автоматический синтез программ -- что нового?
Здравствуйте, kl, Вы писали:
kl>Здравствуйте, Rinbe, Вы писали:
M>>>Автоматический синтез программы -- это когда текст программы M>>>создаётся по спецификации задачи (ну и знаниям предметной области).
R>>Формальное описание того, как должна работать программа имеет туже сложность, что и сама программа.
kl>Не совсем, формально задается не "как должна работать программа", а что она должна выдавать. В общем-то компиляторы функциональных языков или даже оптимизаторы реляционных запросов вполне попадают в эту категорию.
Здравствуйте, malphunction, Вы писали:
M>Автоматический синтез программы -- это когда текст программы M>создаётся по спецификации задачи (ну и знаниям предметной области).
А в чем added value? Все равно эти спецификации придется писать на некоем формальном языке, описывать в мельчайших деталях, искать противоречия и отличия от того, что имелось ввиду. Это будет задача, по сложности сравнимая с программированием, просто программировать придется на некоем специализированном языке описаний.
Re[2]: Автоматический синтез программ -- что нового?
Здравствуйте, dimgel, Вы писали:
D>Выглядит заявкой на серебряную пулю. На входе — задача, на выходе — кнопка "сделать п----то". Сказки.
Это имело бы смысл, если бы задача ставилась следующим образом: ты задаешь вход- выход, возможные блоки из которых строилось бы решение, и потом дописываешь тесты, которое решение должно было пройти, а вся комбинация блоков, их связи -- лежит на генераторе программ. Такое машинное обучение вместо программежа. Это можно сделать, но полученные решение будут скорее всего очень неоптимальными и придется обкладывать его очень изощренными тестами, чтобы оно хоть как то работало.
<Подпись удалена модератором>
Re[4]: Автоматический синтез программ -- что нового?
Здравствуйте, Rinbe, Вы писали:
R>>>Формальное описание того, как должна работать программа имеет туже сложность, что и сама программа.
kl>>Не совсем, формально задается не "как должна работать программа", а что она должна выдавать. В общем-то компиляторы функциональных языков или даже оптимизаторы реляционных запросов вполне попадают в эту категорию.
R>Ну это частный случай, я имел ввиду "вообще".
Причём эти частные случаи десятками-сотнями человеко-лет оптимизируют, и есть у меня подозрение, что ничего общего с автоматическим синтезом эта деятельность по оптимизации не имеет. А про "вообще" — повторюсь, сказки. Вообще сказки.
Здравствуйте, malphunction, Вы писали: M>Когда-то в университете занимался subj'евой тематикой, M>даже диплом по этой теме писал. M>Автоматический синтез программы -- это когда текст программы M>создаётся по спецификации задачи (ну и знаниям предметной области).
TDD чем-то перекликается с этой областью
как я понимаю, люди поняли, что спецификацию задавать удобно в виде тестов
а требование — минимальная программа, удовлетворяющая этим тестам.
это уже достаточно формализованная задача, которая отдается низкоквалифицированному народу или, однажды, может быть даже чат-бот из Одессы сможет с этим справиться
Re[2]: Автоматический синтез программ -- что нового?
Здравствуйте, Rinbe, Вы писали:
R>Формальное описание того, как должна работать программа имеет туже сложность, что и сама программа.
Отнюдь. Вы ж, когда программируете, не пишите весь софт с нуля, а используете
функциональность ОС и библиотек. Это раз. Далее, программируете вы не в машинных
кодах, а на ЯВУ, это упрощает программирование и понимание, хотя алгоритм внутри
остаётся, грубо говоря, тем же. Это два. Ну и три: находясь в тупике, вы пользуетесь
гуглом, StackOverflow, форумами, книжками, наконец.
Вот и Тыугу предлагал те же три составляющих (только на декларативный лад):
1) библиотеки готовых решений типовых задач,
2) удобный язык спецификаций, позволяющий скрыть детали,
3) самая писечка: база знаний о том, как решаются задачи. Синтезатор программ
мог бы обращаться к ней, чтобы ускорить вывод синтезируемой программы.
Таким образом, эта самая "формальная сложность" оказывается сниженой
за счёт использования этих трёх составляющих.
Представляется, что из-за этого написание спецификации будет проще,
чем программирование. Собственно, ради этого всё и затевается.
Другое дело, что Тыугу и Ильин скорее обозначили цели и наметили
способы решения, но не предложили готовых разработок.
M>>И что, действительно, такое многообещающее направление M>>никому не интересно?? Есть тут кто-то, занимающийся подобным?
R>Это такое же программирование, только на языке предметной области.
Ага, это как сказать, что SELECT * FROM tbl -- тот же cmp cx, cx; jne loop_start
и никакого прогресса последние лет сорок не было.
Re[2]: Автоматический синтез программ -- что нового?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, malphunction, Вы писали:
M>>Автоматический синтез программы -- это когда текст программы M>>создаётся по спецификации задачи (ну и знаниям предметной области).
Pzz>А в чем added value? Все равно эти спецификации придется писать на некоем формальном языке, описывать в мельчайших деталях, искать противоречия и отличия от того, что имелось ввиду. Это будет задача, по сложности сравнимая с программированием, просто программировать придется на некоем специализированном языке описаний.
Библиотеки методов решения задач, высокоуровневый язык спецификаций -- всё это
снижает сложность написания кода. Детали тоже иногда можно опустить (к примеру,
вы ж не занимаетесь управлением памятью в программах на современных ЯВУ,
это делается автоматически, освобождая вас от рутины).
Re[3]: Автоматический синтез программ -- что нового?
Здравствуйте, malphunction, Вы писали:
M>И что, действительно, такое многообещающее направление M>никому не интересно?? Есть тут кто-то, занимающийся подобным? M>Можете написать, что сейчас в мире на эту тему происходит?
CMS, по-моему одни из немногих систем, которые в этом чего-то добились. Всякие Wordpress, например. Можно сделать сайт без программиста и даже поддерживать его.
Было много попыток делать более сложные системы без программирования ещё лет 10 назад. Но, как-то ни одной не выстрелило. Я постоянно вижу анонсы и рекламу таких систем. А в одной такой даже участвовал.
Задумка достаточна простая. Система типа ERP это несколько составляющих.
— Модель предметной области
— Бизнес-процесс
— UI формы
— Отчеты
Все эти подсистемы можно нарисовать с помощью некого UI.
— Модель это сущности, свойства и ассоциации — вроде легко рисуется
— Процесс это блок-схема — аналогично можно изобразить
— UI формошлепается через WYSIWYG
— Отчеты тоже рисуются в WYSIWYG и Query Builder для модели данных, не такая уж и сложная фигня.
В теории всё кучеряво. Нарисовал, проставил связи и запускай себе.
На практике же оказывается, что программировать без программирования не так просто.
— Нельзя без определенных навыков нарисовать модель, чтобы она нормально ложилась на более менее нормализованую БД.
— Не может блок-схема лаконично уместить всё то что может язык программирования. Да, и нарисовать блок-схему, оказывается не так просто. Нужно что-то понимать в циклах, переменных, условиях и пр.
— Ну, вот формошлепство, по-моему не самый сложный момент. Хотя usability это тоже целая наука.
— Нельзя построить сложный запрос к модели не понимая SQL.
На самом деле подсистем может быть больше. Интеграции, например. Кто-то через SOAP их делает, а кто-то через DLL.
Сложные алгоритмы и интеграции в таких системых принципиально невозможны из-за слишком высокого уровня абстракции. Поэтому подобные решения позволяют внедрять на каком-то уровне код на популярном языке программирования. А это уже головная боль для программиста, которому помимо программирования на языке, приходится паралельно часть задачь решать в терминах этой системы.
Здравствуйте, malphunction, Вы писали:
M>Автоматический синтез программы -- это когда текст программы M>создаётся по спецификации задачи (ну и знаниям предметной области).
Тут скорее речь идёт об автоматическом решении задач описанных в некоторых декларативных терминах.
Генерация кода/текста программы по готовому формальному плану решения — это ортогональная примочка к такому решателю, реализация которой при наличии оного — всего лишь дело техники.
Re[4]: Автоматический синтез программ -- что нового?
Здравствуйте, malphunction, Вы писали:
M>Да, так и есть. В дипломе делал такую штуку для школьной геометрии M>(для задачек типа "даны длины сторон и углы какой-то штуки, найти параметры другой штуки"), M>худо-бедно получалось синтезировать программки, решающие такие M>задачки.
Давайте догадаюсь: вы решили эту задачу в общем виде, то есть формально описали связи между всеми возможными параметрами "какой-то штуки" (в виде дерева связей или как как-то). Каждая связь — алгоритм или формула, записанная в каком-то общем виде.
А дальше просто генерировали программки исходя из того что дано и что нужно найти: от того что найти рекурсивно доходили до того что дано (определяя заодно полноту входных данных) а затем обратно — к тому что найти, записывая программку в файлик.
Т.е. все равно задачу в общем виде нужно решать человеку, а компьютер лишь генерирует частное решение из общего.
Re[5]: Автоматический синтез программ -- что нового?
Здравствуйте, NeoCode, Вы писали:
NC>Здравствуйте, malphunction, Вы писали:
M>>Да, так и есть. В дипломе делал такую штуку для школьной геометрии M>>(для задачек типа "даны длины сторон и углы какой-то штуки, найти параметры другой штуки"), M>>худо-бедно получалось синтезировать программки, решающие такие M>>задачки.
NC>Давайте догадаюсь: вы решили эту задачу в общем виде, то есть формально описали связи между всеми возможными параметрами "какой-то штуки" (в виде дерева связей или как как-то). Каждая связь — алгоритм или формула, записанная в каком-то общем виде. NC>А дальше просто генерировали программки исходя из того что дано и что нужно найти: от того что найти рекурсивно доходили до того что дано (определяя заодно полноту входных данных) а затем обратно — к тому что найти, записывая программку в файлик.
NC>Т.е. все равно задачу в общем виде нужно решать человеку, а компьютер лишь генерирует частное решение из общего.
В составе моего "игрушечного" генератора решателей было:
1) база теорем (примерно такого вида: "треугольник(x) & прямоугольный(x) & гипотенуза(x, a) & катет(x, b) & катет(x, c) => a^2 = b^2 + c^2".).
2) способы преобразования (тоже вида "a^2 = x & x > 0 => a = sqrt(x)". С помощью преобразований можно из a^2 = b^2 + c^2 вывести, например, c = sqrt(a^2 — b^2)).
3) способы дополнительных построений (многие задачки решаются через доп.построения, там правила вида "если есть треугольник с опущенной высотой, то можно образовать два треугольника со стороной на этой высоте").
4) выводильщик плана программы (рекурсивный проход от "выходных данных" к "входным" с помощью перебора). План транслировался в ЯП C (ну тут всё очевидно).
5) эвристики, чтобы ограничить перебор у 2) и 3).
Итоговое решение получалось перебором, управляемым эвристиками.
Ну, я бы не сказал, что в общем случае задача решается человеком. Человек формирует базу знаний (теорем), спецификацию задачи, ну иногда эвристики.
А программа ищет путь от входных данных к выходным, тут ей человек не помогает.
Мы ж не говорим, что типа, доказательство теоремы Ферма -- это фигня, ведь всё содержится в аксиомах и правилах вывода? Так и тут.
Re[4]: Автоматический синтез программ -- что нового?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, malphunction, Вы писали:
M>>Автоматический синтез программы -- это когда текст программы M>>создаётся по спецификации задачи (ну и знаниям предметной области).
EP>Тут скорее речь идёт об автоматическом решении задач описанных в некоторых декларативных терминах.
С одной поправкой: программа не решает задачу, а ищет план решения задачи. А вот созданная программа -- да, уже решает эту задачу.
EP>Генерация кода/текста программы по готовому формальному плану решения — это ортогональная примочка к такому решателю, реализация которой при наличии оного — всего лишь дело техники.
Ну так и есть, да. Если есть план решения в некотором абстрактном виде, то сгенерить прогу на том же C -- не проблема (но т.к. ЯВУ -- для людей, а нагенерённый код для сопровождения не нужен, то можно сразу в машинных кодах генерить).
Re[2]: Автоматический синтез программ -- что нового?
Здравствуйте, Blazkowicz, Вы писали:
M>>Можете написать, что сейчас в мире на эту тему происходит? B>CMS, по-моему одни из немногих систем, которые в этом чего-то добились.
Спасибо за дельный ответ!
Ну, когда я в студенчестве этим занимался, уже тогда было ясно, что замену программистам запрограммировать
в ближайшие N лет не получится. Но может получится для хорошо специфицированных областей: некоторых
разделов математики, физики, химии. Я вот занимался "школьной геометрией" -- некое работающее средство
получилось. У нас на кафедре аспиранты делали генераторы решателей для некоторых разделов химии, тоже
что-то получалось (не знаю, насколько успешно).
Вот, порылся на Google Scholar -- воз и ныне почти там же, только сдвинулся в Constraint Programming...
Re[2]: Автоматический синтез программ -- что нового?
Здравствуйте, alpha21264, Вы писали:
A>Компилятор? A>DSL? A>Ну и что тут может быть нового?
Вы видели компилятор для спецификаций задач в декларативном виде?
Я -- нет. (Компиляторы для функциональных и логических языков -- не то,
они слишком низкоуровневые).
Re[5]: Автоматический синтез программ -- что нового?
Здравствуйте, malphunction, Вы писали:
M>Здравствуйте, Rinbe, Вы писали:
R>>Пробуйте, сами увидите.
M>А есть с каким инструментарием пробовать?
В смысле генератор генераторов программ? Такое есть для компиляторов. Все зависит от того, что вам нужно. Если генерить программу по спецификации, то нужно в первую очередь определить язык на котором эта спецификация будет написана, что бы генератор кода мог с ней работать. Можно взять готовый язык, UML например.
Re[6]: Автоматический синтез программ -- что нового?
Здравствуйте, Rinbe, Вы писали:
R>Здравствуйте, malphunction, Вы писали:
M>>Здравствуйте, Rinbe, Вы писали:
R>>>Пробуйте, сами увидите.
M>>А есть с каким инструментарием пробовать?
R>В смысле генератор генераторов программ? Такое есть для компиляторов. Все зависит от того, что вам нужно. Если генерить программу по спецификации, то нужно в первую очередь определить язык на котором эта спецификация будет написана, что бы генератор кода мог с ней работать. Можно взять готовый язык, UML например.
Есть еще язык Gherkin — для описания входных тестовых случаев.
Re[3]: Автоматический синтез программ -- что нового?
Единственное что она все же ориентирована скорее на программиста и минимизацию его рутины, чем на отказ от программирования.
M>Ну, когда я в студенчестве этим занимался, уже тогда было ясно, что замену программистам запрограммировать M>в ближайшие N лет не получится. Но может получится для хорошо специфицированных областей: некоторых M>разделов математики, физики, химии. Я вот занимался "школьной геометрией" -- некое работающее средство M>получилось. У нас на кафедре аспиранты делали генераторы решателей для некоторых разделов химии, тоже M>что-то получалось (не знаю, насколько успешно).
Да. Это верно. Вспомнить хотя бы MathLab. То есть, под специфичную предметную область, вполне можно разработать инструмент, который сможет создавать некую работоспособную систему без программирования, но в терминах предметной области.
Re[3]: Автоматический синтез программ -- что нового?
Здравствуйте, malphunction, Вы писали:
M>Вот и Тыугу предлагал те же три составляющих (только на декларативный лад): M>1) библиотеки готовых решений типовых задач, M>2) удобный язык спецификаций, позволяющий скрыть детали, M>3) самая писечка: база знаний о том, как решаются задачи. Синтезатор программ M>мог бы обращаться к ней, чтобы ускорить вывод синтезируемой программы.
В наши дни это называется domain-specific language, и им не занимается только ленивый.
Просто во времена Тыугу очень много внимания уделялось "подкапотному пространству".
Сейчас оптимизирующие компиляторы — это commodity. То, что компилятор C# "генерирует программу" на языке MSIL, которая потом ещё и обрабатывается другим компилятором — повседневность, а не высшее достижение инженерной мысли. Сейчас никто не пишет языки с компиляцией в таргет-код; порождается код на LLVM, JVM, CLR, или, на худой конец, я другом ЯВУ вроде джавы или шарпа.
Все "базы знаний" про решение задач сводятся к двум уровням: семантическая оптимизация (гугл., например, IQueryable Provider в плане примеров оптимизаций AST программы ещё до того, как она будет превращена в низкоуровневые конструкции) плюс оптимизация, встроенная в backend-компилятор.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Автоматический синтез программ -- что нового?
Здравствуйте, malphunction, Вы писали:
M>Вы видели компилятор для спецификаций задач в декларативном виде?
Сколько угодно. M>Я -- нет.
Вы просто не знаете, куда смотреть. Вот, например, любой JSP или ASP.NET позволяет вам в декларативном виде описать разметку страницы — уже 15 лет как. Затем компилятор проходит по этому описанию и выплёвывает код джава-сервлета или наследника System.Web.UI.Page, который является императивной реализацией вашей задачи, специфицированной в декларативном виде. Чего ещё?
Любой файл проекта в Идее или Visual Studio сейчас содержит декларативное описание задачи по компиляции проекта. Его не компилируют, а интерпретируют, но не потому, что это невозможно.
DSL сейчас используются повсеместно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Автоматический синтез программ -- что нового?
Здравствуйте, Blazkowicz, Вы писали: B> — Нельзя построить сложный запрос к модели не понимая SQL.
Сам по себе SQL — уже DSL. Многие просто не в курсе, насколько сложна та программа (план запроса), которая "порождается компилятором" SQL по декларативному описанию запроса и знаниям предметной области (т.е. структуры таблиц и view). И насколько эта программа чувствительна к минимальным изменениям условий задачи.
Это всё настолько прозрачно для программиста, что ему уже SQL кажется чем-то инфернально сложным, хотя на практике даже написать аналог примитивного select b, c from a where d = @e order by c desc так, чтобы он гарантировал изоляцию на уровне read committed и имел линейную стоимость исполнения, этот программист не смог бы и под страхом пожизненного отлучения от интернета.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Составляю с клиентом спецификацию, заношу ее в нашу Jira — через несколько дней/недель там же в Jira появляется линк, по которому я скачиваю готовый софт. Полностью автоматически!
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Re[3]: Автоматический синтез программ -- что нового?
Здравствуйте, Sinclair, Вы писали:
S>Это всё настолько прозрачно для программиста, что ему уже SQL кажется чем-то инфернально сложным, хотя на практике даже написать аналог примитивного select b, c from a where d = @e order by c desc так, чтобы он гарантировал изоляцию на уровне read committed и имел линейную стоимость исполнения, этот программист не смог бы и под страхом пожизненного отлучения от интернета.
Не понял, что ты хотел сказать. Поясни, пожалуйста, в чем сложность select b, c from a where d = @e order by c desc, а то я не сильно в курсе бд
Re[4]: Автоматический синтез программ -- что нового?
Здравствуйте, Ikemefula, Вы писали: I>Не понял, что ты хотел сказать. Поясни, пожалуйста, в чем сложность select b, c from a where d = @e order by c desc, а то я не сильно в курсе бд
Ну, для начала надо будет выбрать один из индексов, чтобы обеспечить приемлемую стоимость исполнения запроса. Вариантов может быть много, даже в таком примитивном случае.
Затем надо будет каким-то образом выбрать стратегию обеспечения изоляции — одновременно с этим select в ту же таблицу пишут множество update, insert, и delete. Причём эта стратегия должна, с одной стороны, не снижать concurrency без причины, а с другой стороны не тратить слишком много времени на синхронизацию саму по себе. И всё это для полярно разных случаев — от 0.0001 запроса на изменение в течение времени выполнения типичного запроса на чтение, то 10000 запросов на изменение в течение того же времени.
Если выбранная стратегия потенциально позволяет нарваться на дедлок, то должна быть и приемлемая методика предотвращения дедлоков — и опять с приемлемой стоимостью исполнения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Всё хорошо, только вы забыли указать фазу "заношу деньги на счёт программистов-исполнителей".
А>Составляю с клиентом спецификацию, заношу ее в нашу Jira — через несколько дней/недель там же в Jira появляется линк, по которому я скачиваю готовый софт. Полностью автоматически!
Здравствуйте, Blazkowicz, Вы писали:
B>Задумка достаточна простая. Система типа ERP это несколько составляющих. B> — Модель предметной области B> — Бизнес-процесс B> — UI формы B> — Отчеты
B>Все эти подсистемы можно нарисовать с помощью некого UI. B> — Модель это сущности, свойства и ассоциации — вроде легко рисуется B> — Процесс это блок-схема — аналогично можно изобразить B> — UI формошлепается через WYSIWYG B> — Отчеты тоже рисуются в WYSIWYG и Query Builder для модели данных, не такая уж и сложная фигня. B>В теории всё кучеряво. Нарисовал, проставил связи и запускай себе.
B>На практике же оказывается, что программировать без программирования не так просто.
Это да. У нас, например, в процессе развития платформы модель и процессы ушли в DSL. Изначально были какие-то мечты о визуальном задании логики, но в результате получилось, что кроме проблем это ничего не приносит. Сейчас наши бизнес-аналитики превратились в "полупрограммистов" и пишут (в основном декларативный) код. Более того, уровень UI тоже ушел в DSL, изначально был написан визуальный конфигуратор форм, но с течением времени его убрали, как тупиковую ветвь. Сейчас у нас есть плагин к Intellij, который кроме обычных языковых возможностей умеет визуально показывать формы (и перерисовывает их на лету при изменении в исходном коде).
Я могу предложить колонизировать Луну и добывать там гелий-3 и использовать его для получения дешевой энергии. Тоже звучит многообещающе? Ну не знаю, как реализовывать то не видно...
Так и Тыуга. Предложить, конечно, можно. Но практической реализации не видно (способа решения). Да, ним предложен некоторый язык УТОПИСТ, в котором многое держится на решении систем уравнений. Думаю, что на сегодняшний день пакет Maple предоставляет просто фантастические возможности для этого. И находит свое применение, но в сравнительно узкой нише. Потому что в повседневной жизни программиста это все надо примерно так же, как зайцу стоп-сигнал.
Библиотек готовых решений типовых задач сейчас тьма-тьмущая. ООП направлено на сокрытия деталей. При этом достаточно сложно отойти от стандартной парадигмы ЯВУ. Большинство попыток ухода от них не более чем заточки под специальные случаи. Например, SQL (не хотим писать и оптимизировать циклы обхода таблиц), или Prolog (не хотим писать перебор вариантов). Естественные языки содержат конструкции "если", "повторить", и они имеют аналоги в ЯВУ. А вот база знаний о том, как решаются задачи и есть нечто магическое. Как реализовать — непонятно. Ни одного внятного примера хотя-бы на уровне элементарной сортировки. Написать pre и post условия достаточно несложно на языке допускающем это, вроде Ada. Можно как-то попытаться доказать по готовому коду, что он из pre условия вытекает post условие. А вот сгенерировать тело процедуры... Плюс не очевидно, что спецификация на уровне pre и post условий менее трудоемка.
Прогресс идет по пути решения конкретных практических задач. Большой проблемы написать код, решающий задачу, для большинства профи нет. Зачем я хожу на stackoverflow? 99% это узнать причину ошибки. Что подразумевает взаимодействие с некоторой другой подсистемой, и знание деталей ее реализации. О базе знаний, которую можно будет использовать для написания кода, можно будет говорить только после анализа естественных языков.
Re[4]: Автоматический синтез программ -- что нового?
Эх... Очередной пост на тему "автоматизация не нужна, давайте жить с тем, что есть"...
M> Потому что в повседневной жизни программиста это все надо примерно так же, как зайцу стоп-сигнал.
Далеко не вся наука занимается сиюминутными практическими задачами.
M>Библиотек готовых решений типовых задач сейчас тьма-тьмущая.
Одно из направлений автоматического синтеза (и это даже пресловутый Тыугу предлагал) -- это синтез
программ из *готовых* библиотек решателей проблем. Потому что, хотя отдельных библиотек действительно
много, проблема создания целых программ до сих пор стоит весьма остро, недаром профессия программиста
всё ещё востребована и никакие индусы с аутсорсом в ближайшее время эту дыру не закроют.
Ваши мысли про ООП и стандартные ЯВУ комментировать не буду,
и так всё ясно -- оглянитесь вокруг.
M> Ни одного внятного примера хотя-бы на уровне элементарной сортировки.
Посмотрите работы Дарлингтона.
M> Плюс не очевидно, что спецификация на уровне pre и post условий менее трудоемка.
Зато может (!) обладать дополнительными свойствами -- большая понятность для человека,
лучшая верифицируемость и пр.
M> Большой проблемы написать код, решающий задачу, для большинства профи нет.
Это как сказать -- вылечить любую болячку для врача профессионала -- раз плюнуть,
нафига тогда экспертные системы создавать?
M> Зачем я хожу на stackoverflow? 99% это узнать причину ошибки. Что подразумевает взаимодействие с некоторой другой подсистемой, и знание деталей ее реализации. О базе знаний, которую можно будет использовать для написания кода, можно будет говорить только после анализа естественных языков.
Снова см. "Экспертные системы". Хотя "анализ естественных языков" сделает в области ЭС революцию, но
и без них ЭС показывают неплохие результаты.
Re[5]: Автоматический синтез программ -- что нового?
Здравствуйте, malphunction, Вы писали:
M>Эх... Очередной пост на тему "автоматизация не нужна, давайте жить с тем, что есть"... M>Далеко не вся наука занимается сиюминутными практическими задачами.
Нет, это как бы критика современного состояния и его перспективности. Мне кажется, что эта тема не созрела. Например, была бы перспективна тема космических полетов в X веке? Нет. Да, конечно, попытка достичь Луны могла бы развить дирижаблестроение. Но никак бы не приблизила высадку на Луну. А вот в XIX веке уже вполне себе перспективна. Моя чуйка, что автоматическое создание программ выстрелит только после успехов в области семантического анализа текста.
M>Одно из направлений автоматического синтеза (и это даже пресловутый Тыугу предлагал) -- это синтез M>программ из *готовых* библиотек решателей проблем. Потому что, хотя отдельных библиотек действительно M>много, проблема создания целых программ до сих пор стоит весьма остро, недаром профессия программиста M>всё ещё востребована и никакие индусы с аутсорсом в ближайшее время эту дыру не закроют.
А чем занимается современный программист? На 90% это вызов разных API. Плюс копание в документации к этим API. Плюс поиск багов, вызванных своим неправильным пониманием этих API. Плюс проблемы совместимости с предыдущим кодом. На изучение этих API/Framework-ов тратится в худшем случае несколько лет. Тыугу, как мне показалось, очень много вниманию уделял алгоритмам, но сейчас они прочно ушли на второй план. Поэтому я акцентирую такое внимании на семантическом анализе текста. Пока решатель не сможет выполнять операцию RTFM, до тех пор он будет бесполезен на текущем этапе развития IT. Другой вариант --- извлекать информацию непосредственно из исходников. Без всего этого даже если предположить, что мы обладаем неким Решателем, который преобразует некоторые абстрактные данные в некоторые другие абстрактные данные, нам надо будет писать код получения входных данных и надо писать код, который будет куда-то передавать эти данные.
M>Посмотрите работы Дарлингтона.
Можно ссылку?
M>Снова см. "Экспертные системы". Хотя "анализ естественных языков" сделает в области ЭС революцию, но M>и без них ЭС показывают неплохие результаты.
А можешь порекомендовать ЭС в области IT? Очень нуждаюсь в системе, которая бы помогала фиксить баги Но любая подойдет. А то я сталкивался с ЭС внутри Windows, которая помогала определять неполадки в компьютере. Но как-то ни разу и не помогла...
Re[6]: Автоматический синтез программ -- что нового?
Здравствуйте, Mystic, Вы писали:
M> Моя чуйка, что автоматическое создание программ выстрелит только после успехов в области семантического анализа текста.
Ваша позиция ясна.
M>>Одно из направлений автоматического синтеза (и это даже пресловутый Тыугу предлагал) -- это синтез M>>программ из *готовых* библиотек решателей проблем. Потому что, хотя отдельных библиотек действительно M>>много, проблема создания целых программ до сих пор стоит весьма остро, недаром профессия программиста M>>всё ещё востребована и никакие индусы с аутсорсом в ближайшее время эту дыру не закроют.
M>А чем занимается современный программист? На 90% это вызов разных API.
Вот поэтому и возникает идея заменить "современного программиста" генератором программ.
Эти 90% -- рутина, зачем же её терпеть? Её надо автоматизировать.
М> Пока решатель не сможет выполнять операцию RTFM, до тех пор он будет бесполезен на текущем этапе развития IT. Другой вариант --- извлекать информацию непосредственно из исходников.
Либо заранее снабжать библиотеки машинно-понимаемыми спецификациями.
Это и будет тем самым RTFM'ом.
M>>Посмотрите работы Дарлингтона. M>Можно ссылку?
http://link.springer.com/article/10.1007/BF00264597
M>>Снова см. "Экспертные системы". Хотя "анализ естественных языков" сделает в области ЭС революцию, но M>>и без них ЭС показывают неплохие результаты. M>А можешь порекомендовать ЭС в области IT? Очень нуждаюсь в системе, которая бы помогала фиксить баги Но любая подойдет. А то я сталкивался с ЭС внутри Windows, которая помогала определять неполадки в компьютере. Но как-то ни разу и не помогла...
Я не в курсе, есть ли ЭС в области IT, я этим не интересовался. Наверняка, что-то есть, поищите.
Но я знаю про медицинские ЭС. Хотя в медицине масса знаний представлена текстом (либо представлена
опытом самих врачей), тем не менее удавалось создать вполне пригодные ЭС без
"анализа текста" (см. Mycin). По аналогии можно сделать вывод, что создание решателя задач не обязательно
опирается на "анализ текстов".
