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

M>Да, так и есть. В дипломе делал такую штуку для школьной геометрии
M>(для задачек типа "даны длины сторон и углы какой-то штуки, найти параметры другой штуки"),
M>худо-бедно получалось синтезировать программки, решающие такие
M>задачки.

Давайте догадаюсь: вы решили эту задачу в общем виде, то есть формально описали связи между всеми возможными параметрами "какой-то штуки" (в виде дерева связей или как как-то). Каждая связь — алгоритм или формула, записанная в каком-то общем виде.
А дальше просто генерировали программки исходя из того что дано и что нужно найти: от того что найти рекурсивно доходили до того что дано (определяя заодно полноту входных данных) а затем обратно — к тому что найти, записывая программку в файлик.

Т.е. все равно задачу в общем виде нужно решать человеку, а компьютер лишь генерирует частное решение из общего.

Здравствуйте, 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).

Итоговое решение получалось перебором, управляемым эвристиками.

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

Мы ж не говорим, что типа, доказательство теоремы Ферма -- это фигня, ведь всё содержится в аксиомах и правилах вывода? Так и тут.

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

R>Пробуйте, сами увидите.

А есть с каким инструментарием пробовать?

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

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

M>>Автоматический синтез программы -- это когда текст программы
M>>создаётся по спецификации задачи (ну и знаниям предметной области).

EP>Тут скорее речь идёт об автоматическом решении задач описанных в некоторых декларативных терминах.

С одной поправкой: программа не решает задачу, а ищет план решения задачи. А вот созданная программа -- да, уже решает эту задачу.

EP>Генерация кода/текста программы по готовому формальному плану решения — это ортогональная примочка к такому решателю, реализация которой при наличии оного — всего лишь дело техники.

Ну так и есть, да. Если есть план решения в некотором абстрактном виде, то сгенерить прогу на том же C -- не проблема (но т.к. ЯВУ -- для людей, а нагенерённый код для сопровождения не нужен, то можно сразу в машинных кодах генерить).

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

M>>Можете написать, что сейчас в мире на эту тему происходит?
B>CMS, по-моему одни из немногих систем, которые в этом чего-то добились.

Спасибо за дельный ответ!

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

Вот, порылся на Google Scholar -- воз и ныне почти там же, только сдвинулся в Constraint Programming...

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

A>Компилятор?
A>DSL?
A>Ну и что тут может быть нового?

Вы видели компилятор для спецификаций задач в декларативном виде?
Я -- нет. (Компиляторы для функциональных и логических языков -- не то,
они слишком низкоуровневые).

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

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

R>>Пробуйте, сами увидите.

M>А есть с каким инструментарием пробовать?

В смысле генератор генераторов программ? Такое есть для компиляторов. Все зависит от того, что вам нужно. Если генерить программу по спецификации, то нужно в первую очередь определить язык на котором эта спецификация будет написана, что бы генератор кода мог с ней работать. Можно взять готовый язык, UML например.

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

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

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

R>>>Пробуйте, сами увидите.

M>>А есть с каким инструментарием пробовать?

R>В смысле генератор генераторов программ? Такое есть для компиляторов. Все зависит от того, что вам нужно. Если генерить программу по спецификации, то нужно в первую очередь определить язык на котором эта спецификация будет написана, что бы генератор кода мог с ней работать. Можно взять готовый язык, UML например.

Есть еще язык Gherkin — для описания входных тестовых случаев.

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

M>Спасибо за дельный ответ!
Вот, нашел предыдушую тему. Это одна из таких систем.
http://www.rsdn.ru/forum/java/5385555.flat

Автор: avpavlov
Дата: 06.12.13

Единственное что она все же ориентирована скорее на программиста и минимизацию его рутины, чем на отказ от программирования.

M>Ну, когда я в студенчестве этим занимался, уже тогда было ясно, что замену программистам запрограммировать
M>в ближайшие N лет не получится. Но может получится для хорошо специфицированных областей: некоторых
M>разделов математики, физики, химии. Я вот занимался "школьной геометрией" -- некое работающее средство
M>получилось. У нас на кафедре аспиранты делали генераторы решателей для некоторых разделов химии, тоже
M>что-то получалось (не знаю, насколько успешно).
Да. Это верно. Вспомнить хотя бы MathLab. То есть, под специфичную предметную область, вполне можно разработать инструмент, который сможет создавать некую работоспособную систему без программирования, но в терминах предметной области.

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

M>Вот и Тыугу предлагал те же три составляющих (только на декларативный лад):
M>1) библиотеки готовых решений типовых задач,
M>2) удобный язык спецификаций, позволяющий скрыть детали,
M>3) самая писечка: база знаний о том, как решаются задачи. Синтезатор программ
M>мог бы обращаться к ней, чтобы ускорить вывод синтезируемой программы.

В наши дни это называется domain-specific language, и им не занимается только ленивый.
Просто во времена Тыугу очень много внимания уделялось "подкапотному пространству".
Сейчас оптимизирующие компиляторы — это commodity. То, что компилятор C# "генерирует программу" на языке MSIL, которая потом ещё и обрабатывается другим компилятором — повседневность, а не высшее достижение инженерной мысли. Сейчас никто не пишет языки с компиляцией в таргет-код; порождается код на LLVM, JVM, CLR, или, на худой конец, я другом ЯВУ вроде джавы или шарпа.

Все "базы знаний" про решение задач сводятся к двум уровням: семантическая оптимизация (гугл., например, IQueryable Provider в плане примеров оптимизаций AST программы ещё до того, как она будет превращена в низкоуровневые конструкции) плюс оптимизация, встроенная в backend-компилятор.

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

M>Вы видели компилятор для спецификаций задач в декларативном виде?
Сколько угодно.
M>Я -- нет.
Вы просто не знаете, куда смотреть. Вот, например, любой JSP или ASP.NET позволяет вам в декларативном виде описать разметку страницы — уже 15 лет как. Затем компилятор проходит по этому описанию и выплёвывает код джава-сервлета или наследника System.Web.UI.Page, который является императивной реализацией вашей задачи, специфицированной в декларативном виде. Чего ещё?

Любой файл проекта в Идее или Visual Studio сейчас содержит декларативное описание задачи по компиляции проекта. Его не компилируют, а интерпретируют, но не потому, что это невозможно.

DSL сейчас используются повсеместно.

Здравствуйте, Blazkowicz, Вы писали:
B> — Нельзя построить сложный запрос к модели не понимая SQL.
Сам по себе SQL — уже DSL. Многие просто не в курсе, насколько сложна та программа (план запроса), которая "порождается компилятором" SQL по декларативному описанию запроса и знаниям предметной области (т.е. структуры таблиц и view). И насколько эта программа чувствительна к минимальным изменениям условий задачи.

Это всё настолько прозрачно для программиста, что ему уже SQL кажется чем-то инфернально сложным, хотя на практике даже написать аналог примитивного select b, c from a where d = @e order by c desc так, чтобы он гарантировал изоляцию на уровне read committed и имел линейную стоимость исполнения, этот программист не смог бы и под страхом пожизненного отлучения от интернета.

Составляю с клиентом спецификацию, заношу ее в нашу Jira — через несколько дней/недель там же в Jira появляется линк, по которому я скачиваю готовый софт. Полностью автоматически!

Здравствуйте, 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, а то я не сильно в курсе бд

Здравствуйте, Ikemefula, Вы писали:
I>Не понял, что ты хотел сказать. Поясни, пожалуйста, в чем сложность select b, c from a where d = @e order by c desc, а то я не сильно в курсе бд
Ну, для начала надо будет выбрать один из индексов, чтобы обеспечить приемлемую стоимость исполнения запроса. Вариантов может быть много, даже в таком примитивном случае.
Затем надо будет каким-то образом выбрать стратегию обеспечения изоляции — одновременно с этим select в ту же таблицу пишут множество update, insert, и delete. Причём эта стратегия должна, с одной стороны, не снижать concurrency без причины, а с другой стороны не тратить слишком много времени на синхронизацию саму по себе. И всё это для полярно разных случаев — от 0.0001 запроса на изменение в течение времени выполнения типичного запроса на чтение, то 10000 запросов на изменение в течение того же времени.
Если выбранная стратегия потенциально позволяет нарваться на дедлок, то должна быть и приемлемая методика предотвращения дедлоков — и опять с приемлемой стоимостью исполнения.

Здравствуйте, Аноним931, Вы писали:

Всё хорошо, только вы забыли указать фазу "заношу деньги на счёт программистов-исполнителей".

А>Составляю с клиентом спецификацию, заношу ее в нашу Jira — через несколько дней/недель там же в Jira появляется линк, по которому я скачиваю готовый софт. Полностью автоматически!

Нашёл неплохую презентацию о более-менее современном
положении дел:

http://www.myshared.ru/slide/400788/

смотрите, кому интересно.

Здравствуйте, 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, который кроме обычных языковых возможностей умеет визуально показывать формы (и перерисовывает их на лету при изменении в исходном коде).

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

Я могу предложить колонизировать Луну и добывать там гелий-3 и использовать его для получения дешевой энергии. Тоже звучит многообещающе? Ну не знаю, как реализовывать то не видно...

Так и Тыуга. Предложить, конечно, можно. Но практической реализации не видно (способа решения). Да, ним предложен некоторый язык УТОПИСТ, в котором многое держится на решении систем уравнений. Думаю, что на сегодняшний день пакет Maple предоставляет просто фантастические возможности для этого. И находит свое применение, но в сравнительно узкой нише. Потому что в повседневной жизни программиста это все надо примерно так же, как зайцу стоп-сигнал.

Библиотек готовых решений типовых задач сейчас тьма-тьмущая. ООП направлено на сокрытия деталей. При этом достаточно сложно отойти от стандартной парадигмы ЯВУ. Большинство попыток ухода от них не более чем заточки под специальные случаи. Например, SQL (не хотим писать и оптимизировать циклы обхода таблиц), или Prolog (не хотим писать перебор вариантов). Естественные языки содержат конструкции "если", "повторить", и они имеют аналоги в ЯВУ. А вот база знаний о том, как решаются задачи и есть нечто магическое. Как реализовать — непонятно. Ни одного внятного примера хотя-бы на уровне элементарной сортировки. Написать pre и post условия достаточно несложно на языке допускающем это, вроде Ada. Можно как-то попытаться доказать по готовому коду, что он из pre условия вытекает post условие. А вот сгенерировать тело процедуры... Плюс не очевидно, что спецификация на уровне pre и post условий менее трудоемка.

Прогресс идет по пути решения конкретных практических задач. Большой проблемы написать код, решающий задачу, для большинства профи нет. Зачем я хожу на stackoverflow? 99% это узнать причину ошибки. Что подразумевает взаимодействие с некоторой другой подсистемой, и знание деталей ее реализации. О базе знаний, которую можно будет использовать для написания кода, можно будет говорить только после анализа естественных языков.

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

Эх... Очередной пост на тему "автоматизация не нужна, давайте жить с тем, что есть"...

M> Потому что в повседневной жизни программиста это все надо примерно так же, как зайцу стоп-сигнал.

Далеко не вся наука занимается сиюминутными практическими задачами.

M>Библиотек готовых решений типовых задач сейчас тьма-тьмущая.

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

Ваши мысли про ООП и стандартные ЯВУ комментировать не буду,
и так всё ясно -- оглянитесь вокруг.

M> Ни одного внятного примера хотя-бы на уровне элементарной сортировки.

Посмотрите работы Дарлингтона.

M> Плюс не очевидно, что спецификация на уровне pre и post условий менее трудоемка.

Зато может (!) обладать дополнительными свойствами -- большая понятность для человека,
лучшая верифицируемость и пр.

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

Это как сказать -- вылечить любую болячку для врача профессионала -- раз плюнуть,
нафига тогда экспертные системы создавать?

M> Зачем я хожу на stackoverflow? 99% это узнать причину ошибки. Что подразумевает взаимодействие с некоторой другой подсистемой, и знание деталей ее реализации. О базе знаний, которую можно будет использовать для написания кода, можно будет говорить только после анализа естественных языков.

Снова см. "Экспертные системы". Хотя "анализ естественных языков" сделает в области ЭС революцию, но
и без них ЭС показывают неплохие результаты.