Версия 0.41 от 28.02.2017
1.Добавлен шаблон для генерации WEB приложения на PHP+MySQL для работы с таблицами.
2.Добавлен шаблон для генерации SQL-команд в синтаксисе SQLite и MySQL.
3.Добавлена возможность генерации в формат JSON.

Vladimir Baskakov,
спасибо!

В части развития направления генерации кода на PHP я подумывал о Yii 2.
Какого Вы мнения об этом фреймворке?

dma_caviar,
у Вас хорошая платформа.
Всегда мечтал нечто подобное сделать, но не сложилось.

Вы правы, гоняться за технологиями - неблагодарное занятие.
Особенной за фреймворками и библиотеками - на них еще быстрее мода проходит.

Именно по этотой причине хочется хоть в некоторой части обрести независимость
(или возможность перехода) не только от ОС, но и от языка/среды программирования.

Моя работа не носит коммерческий результат.
Мне интересно найти общее в подходах и технологиях пограммирования.
Этакое метапрограммирование.

Пример:
20 лет назад было 3 SQL-лидера: Sybase (потом MS SQL), Oracle, Informix.
И общее мнение было, что так и останется.
Сегодня, следуя моде, мне пришлось в WEB сервисе генерации
реализовать синтаксис SQL запросов для MySQL, PostgreSQL, SQLite.
Все, в общем, одинаково.
Но у каждого из них свои особенности в синтаксисе, иначе работать не будет или будет работать криво.
А ведь есть стандарты SQL92 и SQL2000.
Кто мог предположить такое развитие событий 20 лет назад?

А C-подобный синтакцис у C++, Java, JavaScript, того же PHP.
20 лет назад любой, кто хотел разработать свой язык программирования, был чудаком
и "изобретателем велосипеда". А сколько с тех пор появилось новых языков?

Еще можно спорить, что лучше: XML (для серьезных) или JSON (попса).

ИТОГ, к которому я пришел.
Очень хочется вынести "за скобку" программирования:
1.Особенности синтаксиса по-сути одинаковых языков программирования, библиотек и ИТ-технологий.
2.Общую модель (онтологию) данных. Чтобы в каждом проекте, например, не нужно было изобретать
таличку физических лиц (будь то клиент, работник или пациент) с одними и теми же полями.

Понимаю, что это не монетизируется, но это мой путь.
Буду продолжать идти, пока есть интерес и силы :)

kealon(Ruslan)Дмитрий Concept,

сегодня только наткнулся
ИИ научили писать код

Спасибо за ссылку, но смущает (привожу цитату из заметки) "В данный момент он может работать примерно с ПЯТЬЮ строками кодами. "

Вообще я не сторонник алгоритмов генерации произвольных программ.
Чтобы программа была полезна - ИИ нужно задать некий механизм целеполагания и критерии оценки полученного результата.
Обычно это можно сделать используя механизм спецификаций: т.е. не того как нужно программе работать, а что она должна делать или какой результат должен быть получен.
Это более реалистичный подход и он известен как генерация программ по входным спецификациям.
Я для того, чтобы не было комбинаторного взрыва - ограничивают такие генераторы программ предметной областью или классом решаемых задач.

Этот подход мне кажется более реалистичным, иначе такой ИИ (как в приведенной заметке) так и будет формировать абстрактные синтаксически правильные программы из 5-10 строк с неясной семантикой (для кого и чего такие программы будут нужны).

dma_caviarДмитрий Concept,

Вот вы бы взяли этот свой инструментарий и опубликовали через некое api. Чтобы те кому нужно смогли за вас реализовать провайдера требуемой кодргенерации под свою платформу.

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

Реально спасибо Вам за подсказанную идею. Не сразу, но Ваши слова до меня дошли.

По-сути внутри у меня именно такая архитектура (провайдер+api+классы генерации конструкций для различных ЯП) и используется.
Только нет четкого разделения на указанные компоненты. Т.е. где-то есть, а где-то еще все перемешано (каша).
У меня сейчас выделено три мета шаблона приложений:
1.Простая последовательность команд, включая циклические обработки (например цикл по полям сущности)
2.Приложение в архитектуре "десктоп" (основанное на создании и манипулировании классами компилируемых форм)
3.Приложение с архитектурой тонкого веб-клиента

В рамках одного мета шаблона настройка на конкретный ЯП вполне может быть вынесена в классы занимает около 10-20% от общего
объема команд шаблона.

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

Еще раз спасибо за идею и конструктив!

Vladimir Baskakovdma_caviar .... Чтобы те кому нужно , смогли за вас ....

Так в том и проблема, сделать что-то что хоть кому-то нужно. Это раз. Два - уже из коробки оно должно кодогенерить хотя бы под одну платформу. Три - разработка адаптеров и их использование на платформе Х должно быть проще, чем разработка того-же продукта на платформе Х с нуля, включая будущие расходы на развитие и поддержку.

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

Владимир, я с Вам согласен.
Но Вы обрисовали конечный продукт.
Я еще в начале пути к нему, думаю, где-то 20% только прошел.
И не могу гарантировать, что смогу дойти до конца (промышленной реализации).
Да и нужно ли?

Одно из применений сервиса - обучение ЯП. Особенно 2-му, 3-му и т.д. Например, я знал ASP. Сгенерировав параллельный код на PHP и сравнив его с аналогичным на ASP, не залезая в документацию, я сразу вижу принципиальные отличия.
<?php вместо <%
$sql = 'create ' . $id вместо sql='create '+id
echo '<tr>' вместо Response.Write('<tr>')

И т.д. Время существенно экономится. Обучение, так сказать, на примерах "параллельных текстов".

alex55555Дмитрий ConceptОчень хочется вынести "за скобку" программирования:
1.Особенности синтаксиса по-сути одинаковых языков программирования, библиотек и ИТ-технологий.
2.Общую модель (онтологию) данных. Чтобы в каждом проекте, например, не нужно было изобретать
таличку физических лиц (будь то клиент, работник или пациент) с одними и теми же полями.
А что мешает? Строим единую расширяемую модель и дорисовываем к ней "особенности синтаксиса языков" и "клиентов, работников и пациентов"..

Размерность задачи. ЯП много и предметных областей тоже. Онтология большая.

alex55555Дмитрий ConceptПонимаю, что это не монетизируется, но это мой путь.
Не смешно. Не монетезируется, это когда с открытым кодом (да и то не всегда). А так вы всегда оставляете себе ядро, а наружу только сервисы торчат (потенциально платные). Ну и идейки у народа за одно собираете, мол не для бабла, а чисто для души - помогите кто чем может, расскажите как вы там всё делаете (забесплатно, ведь для души!).

Хотя бывают и исключения.

Но конечный итог один - ещё лет 15 и будет вам ИИ, поувольняют не только кассиров да бухгалтеров, но и кодеров. Хотя опять же - ну какой дурак так далеко смотрит? Нам бы ипотеку выплатить, да унитаз подороже приобрести.

"Ну и идейки у народа за одно собираете, мол не для бабла, а чисто для души'.
Да и не скрываю, за идеи буду признателен. К тому же, это в обе стороны.
Кто-то посмотрит на WEB сервис генерации кода, подумает "а вон значит как можно" и сделает лучше, учтя мои ошибки.
Ну и хорошо.

kolobok0, спасибо!

kolobok01) можно искать подобных людей обладающих кучей бабла и тонной времени.
В это я не верю. У кого есть куча денег в такие проекты не вкладываются,
т.к. им нужна гарантия прибыли и желательно без рисков и за короткий срок.

kolobok0предложить некие правила объединяющих различные модули по генерации в единую платформу.

ЭТА ИДЕЯ НУ ОЧЕНЬ НРАВИТСЯ. Готов присоединиться к такому обсуждению, если кто-нибудь возьмет модерацию темы на себя.

kolobok02) (немного дёгтя наверное) с точки зрения рынка - это не удачный вектор. более удачный рядом - в пол шажке от Вас. На рынке требуются (как тут уже прозвучало) продукты для конечного потребителя. Ваш же подход - без раскрутки имени = имхо тупиковая ветка.

Понимаю. Но я стараюсь реально смотреть на вещи. Себя я давно знаю. Я технарь и вырос из системного программирования.
Маркетинг, продвижение, сегмент B2C - не умею я. Пробовал, но не умею.
Вот фреймворки, библиотеки, шаблоны - это мое. Но это сегмент B2B. А в нем в каждой софтверной компании свои программисты-технологи, технологии, внутренние стандарты и т.д.

kolobok03) выше Вы писали, что столкнулись с заточкой под те или иные БД. Это действительно так. Универсальность либо фичи. как более гибкий подход - создать адаптирующий слой под тот или иной движок. не все фичи вынуть сможете, но думаю для большинства задач подойдёт. Тут правда для адаптирующего слоя требуется опыт общения с различными БД и практическое применение наработок при той или иной модели классов обслуживающих БД.

С этим согласен. Общение с различными БД и практическое применение наработок необходимо.
Иначе не получить объективную оценку и обратную связь.

kolobok04) ваш сервис предлагает некий интерфейс общение с человеком в рамках ваших знаний и понимания, далее идёт готовое решение в рамках ваших знаний и понимания. Системе как воздух требуется гибкость. И в плане интерфейса и в плане генерации. Может имеет смысл рассмотреть промежуточный слой строения классов?

Здесь Вы абсолютно правы. Гибкость в плане интерфейса и в плане генерации необходимо.
Над этим работаю.
Не люблю загадывать и давать обещания, но, надеюсь, к концу марта продвинуть сервис в этом направлении.
Наработки есть, но они существуют для десктопной версии.
Сейчас переношу в WEB. Но процесс идет не быстро, т.к. я не являюсь глубоким специалистом в WEB технологиях и
приходится многому дообучаться в процессе.

На мой взгляд, сейчас ускорились (или просто четче стали проявляться) две тенденции:
1.Сроки и бюджеты на разработку программ сокращаются. Как следствие, уход заказчиков от постоянных затрат и длительных проектов в пользу привлечения подрядчиков под конкретные проекты с фиксированными сроками и бюджетами.
2.Бум Open Source технологий, которые снижают универсальность и мобильность команд разработки ПО. Вложившись своими наработками в один стек разработки ПО не факт, что эта мода долго продлиться или найдешь заказчиков, которые лояльны к этому стеку разработки ПО.

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

Вот если сделать CASE технологию, которая бы была:
1.Простой в изучении и использовании.
2.Дешевой.
3.Гибкой (настраивалась на выходные языки программирования и среды, Фреймворки, интерфейсы и т.д.)
4.Использовала на входе описание модели информационной системы/ПО в популярных нотациях (UML, ER, XML)
5.Поддерживала автоматическое документирование для всех этапов жизненного цикла ПО.

Собственно, это и есть цели разработки WEB сервиса генерации ПО.
Если удастся 50-70% программного кода на НАЧАЛЬНОМ ЭТАПЕ РАЗОРАБОТКИ ПО (или на этапе миграции на другую платформу/стек разработки ПО) сгенерировать автоматически, заложив прочный скелет приложения - это будет хороший результат,
который позволит вписаться в тенденции (указаны в начале данного сообщения) и позволит командам разработчиков
обеспечить необходимую мобильность, снизить зависимость от платформы, вписываться в сжатые сроки разработки и бюджеты.

Остальные 30%-50% программного кода - удел высокопрофессиональных разработчиков, допиливающих приложение под специфику задачи. От этого никогда и никуда не деться. Да и не нужно - это нормально.