Comments 42
Почему в качестве выходного языка генерации используется Си, а не Си++?
За несколько десятилетий практики разработки систем как-то обходились без объектного программирования (список систем см. по ссылке в первом абзаце).
Хотя сейчас пришлось задействовать и Си++ в генерируемом коде, т.к. приняли решение использовать Qt, но с чувством глубокого неприятия.
Хотя сейчас пришлось задействовать и Си++ в генерируемом коде, т.к. приняли решение использовать Qt, но с чувством глубокого неприятия.
расскажите пожалуйста о своём многодесятилетнем неприятие С++
С утра до вечера денно и нощно не принимал язык. Шутка.
Если серьезно, то по моему мнению языки делятся на две категории: с ручным управлением памятью и со сборщиком мусора. К первым безусловно относится C. Ко вторым — Java. Язык C++ — это тянитолкай, в котором пытались совместить ручное управление памятью и работу с объектами. Хотели в языке объединить преимущества двух подходов, но в результате, как обычно бывает, объединили недостатки.
Ну и в отношении масс к языкам зачастую определяет на свойства самого языка, а наличие доступных в нем библиотек, ну и, разумеется, реклама.
А зачем еще один подобный рассказ? Не хватает своей собственной ненависти к этим языкам программирования, хотите больше ненависти?
Лучше пост «любви и обожания» к языку, который вам нравится. А еще лучше что-то полезное с практической точки зрения. А этих бессмысленных срачей уже и без того полон интернет.
Лучше пост «любви и обожания» к языку, который вам нравится. А еще лучше что-то полезное с практической точки зрения. А этих бессмысленных срачей уже и без того полон интернет.
Возможно я невнимательно читал. А на каком языке исходные модели? И на каком языке описаны преобразования моделей в код? Мы тоже занимаемся разработкой подобных генераторов. Причем, это даже не внутренняя разработка, а коммерческие проекты :) Исходные модели — UML или Ecore, а преобразования — на языке QVTo. На выходе разные языки — Java, XSLT, XPath.
Язык самодельный. Сами придумали, сами реализовали. На нем и пишем. И сам генератор неписан на этом же языке.
А готовые инструменты смотрите или планируете использовать? Типа Xtext или того же QVTo? У OMG целый ряд стандартов, посвященных модельно-ориентированной разработке. И есть целый ряд уже готовых инструментов, реализующих эти стандарты. На мой взгляд тут лидер Eclipse с его EMF и пр. Я пишу цикл статей на эту тему, но пока пришлось забросить.
Преимущество готовых инструментов в том, что тратишь время только непосредственно на разработку самого языка или транслятора. Всякие инфраструктурные вещи уже готовы и даже стандартизованы.
Конечно, было бы интересно хотя бы примерно узнать где вы все это используете. У нас, например, в одном из проектов аналитики описывают правила ФЛК в платформо-независимом виде в модели. А генератор генерит реализацию этих правил под нужные платформы на нужных ЯП. В результате экономится просто огромное количество времени работы разработчиков.
Преимущество готовых инструментов в том, что тратишь время только непосредственно на разработку самого языка или транслятора. Всякие инфраструктурные вещи уже готовы и даже стандартизованы.
Конечно, было бы интересно хотя бы примерно узнать где вы все это используете. У нас, например, в одном из проектов аналитики описывают правила ФЛК в платформо-независимом виде в модели. А генератор генерит реализацию этих правил под нужные платформы на нужных ЯП. В результате экономится просто огромное количество времени работы разработчиков.
Все, что у вас перечислено не используем. И еще очень много других систем тоже.
Приходи в голову анекдот:
Вы знаете, что в Испании самое распространенное имя — Хосе? А наименее распространенное — Василий Тимофеевич.
А если серьезно, то недостаток готовых инструментов в том, что на их освоение уходит очень много времени, а потом оказывается, что он не подходит.
Приходи в голову анекдот:
Вы знаете, что в Испании самое распространенное имя — Хосе? А наименее распространенное — Василий Тимофеевич.
А если серьезно, то недостаток готовых инструментов в том, что на их освоение уходит очень много времени, а потом оказывается, что он не подходит.
Ну, вы же ОС готовую используете или Си готовый ) Консорциум OMG — это основная, если не единственная организация, которая занимается стандартизацией в области модельно-ориентированной разработки. Это как W3C для веба или как ISO.
В вебе есть HTML, CSS и т.п. В модельно-ориентированной разработке есть MOF, UML, OCL, QVT, XMI и т.п. Их разрабатывали компании, которые занимаются этой темой уже 20-30 лет. На освоение нужно не очень много времени.
Я ничего не навязываю, просто, может быть это будет для кого-то полезным. Если кому-то интересно, то я как-раз пытался описать некоторые OMGшные стандарты с простыми примерами и сжато.
В вебе есть HTML, CSS и т.п. В модельно-ориентированной разработке есть MOF, UML, OCL, QVT, XMI и т.п. Их разрабатывали компании, которые занимаются этой темой уже 20-30 лет. На освоение нужно не очень много времени.
Я ничего не навязываю, просто, может быть это будет для кого-то полезным. Если кому-то интересно, то я как-раз пытался описать некоторые OMGшные стандарты с простыми примерами и сжато.
Бессмыслица какая-то. Количество открытых портов, строк кода, утилит внутри проекта, и ни слова о том, что он делает.
В статье и не ставилась цель рассказать об упомянутом проекте.
Зачем-то рассказываете про премущество трансляции из языков высокого уровня в язык Си в 2017 году, когда это для всех уже самоочевидно.
Если это самоочевидно, то об этом нельзя говорить?
GTK под win32 работает
На приложения gtk под win32 без слез смотреть невозможно.
И, похоже, команда gtk решила самоубиться, если судить по тому, как там развивается ситуация.
а не взять сразу Qt?
Qt взяли недавно преодолев брезгливость от C++.
Большие вопросы в состоятельности экспорта из вашего языка в JS и Java, и html со смесью вашего яыка, он либо очень примитивен, либо… а без вариантов — уж больно разные системы вы целитесь поддерживать.
Реализуется экспорт подмножества языка. А насчет примитивен — не надо думать, что если вы что-то считаете невозможным, то это невозможно для всех остальных.
Все это есть очень много где, или абстракция для этого пишется очень быстро. Особо мощного DSL в вашем базовом языке нет, это фактически очень тонкая обертка над Си, которая по выразительности явно проигрывает любому современному языку высокого уровня. У С++ конечно много проблем, но даже беря его двольно безобидное подмножество уровень возможностей будет выше, чем в вашем языке.
Не слишком ли категорично? Вы судите об сложной системе по короткой статье, написанной на одном дыхании, чтобы посмотреть реакцию общественности.
Мое личное мнение — вы со своим проектом застряли где-то на уровне начала нулевых, когда велосипедостроение не было чем-то зазорным, а любой подход к построению коммерческих систем считался рабочим покуда за него платят деньги, какая бы дичь не была под капотом. Судя по примеру кода на базовом языке, который вы привели, в поддержке таких программ приятного мало.
Не нравится — вот и чудненько. Пишите на фреймворках и бог вам в помощь.
Я думаю, что таких комментариев будет еще много, потому и ответил достаточно развернуто, чтобы потом не повторяться.
Портфолио не выглядит внушительным… Забавно.
Кстати что не так с Gtk в плане команды, вроде же только третий гном вышел провальным, а сам тулкит развивается?
Это, кстати, тоже неочевидно (провальность GNOME 3.xx). Несмотря на всю мою неприязнь к тому, что они сделали, назвать третий гном провальным я не могу: это DE по умолчанию во многих популярных дистрибутивах (fedora, ubuntu с 18.xx, opensuse).
Но судя по скриншоту одного из ваших продуктов, вы и так не тратите время на красивости.
Со скриншотом пример не очень удачный, поскольку данный проект лабораторный. В нем разработчик отлаживал внутреннюю математику построения и использования иерархического каталога вычисляемых синтетических показателей. Для этих целей интерфейс был достаточно красив, ибо не требовал специальных усилий. А вообще, пользовательский интерфейс — дело тонкое, и наши разработчики здесь ориентируются на детальные спецификации и пожелания заказчика.
«Я осмотрел ваши проекты по ссылке https://www.ustech.ru/ostcgi/ostagn?section=products&product=all, и насколько я понял сегодня такие вещи в основном пишутся на Java, C#, PHP»
Такие вещи отлично пишутся на платформе 1С, т.к. у этой платформы (фреймворка) есть все необходимые объекты для этого.
Плюс над ее развитием работает много людей, плюс очень много готовых наработок которые можно посмотреть/взять в типовых решениях которые работают по всей стране.
Такие вещи отлично пишутся на платформе 1С, т.к. у этой платформы (фреймворка) есть все необходимые объекты для этого.
Плюс над ее развитием работает много людей, плюс очень много готовых наработок которые можно посмотреть/взять в типовых решениях которые работают по всей стране.
Скажите пожалуйста, получается-ля у вас реализовывать многопоточные приложения при помощи генератора? Как реализована синхронизация потоков?
Лет десять назад была попытка задействовать потоки в сервере. Поразмыслив, отказались. Если нужна параллельность вычислений, то лучше в разных процессах. Сейчас пытаемся в новой модели приложений сделать два потока, один — графика, другой — сеть, протокол.
ИМХО, чтобы выйти на современный уровень, нужна работа с потоками. Удобнее всего, как мне кажется, работать в виде сигналов — слотов в стиле qt.
Напишите еще, пожалуйста, чем вам так не нравится с++, но устраивает с?
Напишите еще, пожалуйста, чем вам так не нравится с++, но устраивает с?
Я вот сейчас не поленился, привстал со стула, повернулся к книжной полке и измерил линейкой толщину книги Страуструпа (3-е издание 1999 года) по C++. Результат 42 мм. При этом значительного эффекта по-сравнению с C не дает.
C — это всего лишь возомнивший о себе ассемблер. И тем хорош, что реализуется сразу на любой платформе. И не навязывает лишнего.
C — это всего лишь возомнивший о себе ассемблер. И тем хорош, что реализуется сразу на любой платформе. И не навязывает лишнего.
Как мне кажется, в любом языке, как минимум, достаточно базовой синхронизации на уровне объектов ядра — мьютексы, семафоры. Такие механизмы доступны в любых языках.
Более глубокая интеграция в модельные механизмы безусловно упрощает жизнь разработчику.
Более глубокая интеграция в модельные механизмы безусловно упрощает жизнь разработчику.
Базовый язык — это часть генераторного языка описания проекта, реализующая универсальный язык программирования. Разработчик с помощью генератора проектов имеет возможность писать обычные программы на этом языке
Это упростило сам генератор, так как отпала необходимость следить за тонкостями адресации в Си для реализации модельных сущностей
Вы придумали свой PHP.
Основная идея заключалась в том, что клиентская программа получает информацию от сервера не в виде нескольких кортежей и таблиц, а в виде произвольного документа зафиксированной для данного запроса структуры. И, симметрично, клиент, выполняя запрос, тоже присылает в общем виде документ.
A это web-API.
В более сложном случае программа на базовом языке может состоять из нескольких пакетов.
Описание проекта — это файл описания проекта с заголовком и упорядоченным перечнем пакетов.
А это composer.
это аналогично описанию базы данных с двумя таблицами и заданными колонками в них.
возникла идея генерировать по модели не сразу Си-код, а код на базовом языке
Похоже на Doctrine, да и вообще на любой маппер записей БД в сущности.
Генерация моделей по таблице в БД или по заданному описанию есть в любом крупном PHP фреймворке.
Итого.
Ваш язык конечно имеет преимущества по сравнению с низкоуровневым C. Хорошо, что он вам приносит пользу. Но ничего нового тут нет, и для всего более удобные или более распространенные инструменты. Единственный плюс это генерация нативных клиентов, что требуется не так часто. Ну еще производительность вычислений, но и она требуется не так часто, тем более в описанных в статье клиент-серверных проектах с формами ввода данных.
PHP и JavaScript — языыки без контроля типов ил с очень слабым. Были придуманы для написания небольших программ. Математически вполне остроумны и изящны, но не для программирования больших систем. А когда все перечисленное сваливается в одну кучу, с этим работать весьма затруднительно. Именно поэтому мы и развиваем свой инструмент. В статье написано, что преимущество нашего подхода проявляется только на очень больших программах.
Могу написать вам то же самое про Python, Java или C#. Да и в PHP давно есть проверка типов. И да, на всех них пишут большие программы.
Кстати про объемы. Не могли бы вы рассказать про количество серверов и портов — что они делают, что по ним передается, сколько таблиц в базе, сколько в них данных и т.д. Хотя бы в общих словах.
Большие программы пишут на всем, что есть. Это меня всегда забавляло. Вот и в цирке некоторые уникумы ходя по канату. Но это не означает, что по канату надо ходить всем.
Идеалист – это тот, кто, обнаружив, что у розы запах лучше, чем у
капусты, сделает вывод, что и бульон из розы получится лучше.
Идеалист – это тот, кто, обнаружив, что у розы запах лучше, чем у
капусты, сделает вывод, что и бульон из розы получится лучше.
По-вашему, надо писать большие программы на том, чего нет? Если бы писать большие программы на некотором языке было проблематично, они бы на этом языке не появлялись.
И да, аналогия у вас какая-то некорректная. Ходить не по канату а по ровному полу гораздо удобнее. Вот все и ходят. А по канату да, ходят единицы и с определенной целью. И вот преимуществ вашего подхода по сравнению с другими в статье нет, отсюда и вопросы.
Идеализм здесь ни при чем, это практический расчет. Выбирается то, что удобнее использовать с точки зрения поддерживаемости/надежности/ресурсов.
С моей точки зрения писать большие программы на языке без строгой типизации — это хождение по канату. В статье об этом ясно написано. Если вы меняете спецификацию процедуры (состав и типы параметров), которая вызывается по всему коду пару сотен раз, то в языке типа PHP или JavaScript это катастрофа. А у нас вы просто запускаете генерацию и получаете курсор в месте очередной ошибки несоответствия параметров. И пока не исправите, дальше не продвинетесь.
Кто тут ходит по ровному полу я вообще не понял.
Кто тут ходит по ровному полу я вообще не понял.
Python, Java, C# — это языки без строгой типизации?
В языке типа PHP:
— Если вы меняете типы параметров (int <-> string, int <-> float), по всему коду их менять как раз не надо. Внутри функции типы сконвертируются. Если вы вместо базового типа решили передавать объект, будет ошибка при использовании его в выражениях, если наоборот, будет ошибка доступа к свойству/методу.
— Если вы добавили параметр, но не добавили в месте вызова, будет сообщение об отсутствующем аргументе. Если убрали, ну да, будет молча передаваться.
— Ассоциативные массивы хорошая замена большому числу параметров.
Конечно это все в рантайме, но это проверяется тестами, которые в таких системах должны быть независимо от типизации языка. Это конечно неприятности, но явно не катастрофа.
С моей точки зрения писать большие программы, в которых много сущностей с поведением, на процедурном языке это и есть хождение по канату. Возможно, поэтому у вас процедуры и вызываются по всему коду сотни раз. А "по ровному полу" ходит большинство, которое пишет программы на современных объектных языках. Повторю, я не говорю, что ваш подход плохой, но его преимущества неочевидны. Даже не очень понятно, на каких типах проектов они проявляются, формулировка "на больших" слишком размытая.
Да, забыл про проект с серверами. Вот ссылка на краткое описание:
https://www.ustech.ru/ostcgi/ostagn?section=products&product=yenisei
https://www.ustech.ru/ostcgi/ostagn?section=products&product=yenisei
Мне тоже приходили в голову мысли о том, что многое, что приходится кодить можно на самом деле генерировать. В итоге написал скрипт, который по структуре БД генерирет вспомогательный код на разных языках, чтобы потом было комфортно писать бизнес-логику в разных IDE. В моем случае это:
— классы на PHP и JavaScript с описанием структуры, аннотациями, сеттерами, геттерами и другими операциями, чтобы в PHPStorm заработали автоподсказки и автодополнения,
— фрагменты на HTML и JavaScript в соответствии с типом полей
— серилиализаторы
— SQL-функции, процедуры и макросы для различных манипуляций с записями, с тем чтобы избегать перечислений полей.
Свой язык придумывать не стал (за исключением макро расширения для MySQL), так как 1) их уже и так полно 2) хотелось бы писать в IDE, c автоподсказками и нормальным дебагом.
Вообще интересно, кто и что использует для такой вот автоматизации.
— классы на PHP и JavaScript с описанием структуры, аннотациями, сеттерами, геттерами и другими операциями, чтобы в PHPStorm заработали автоподсказки и автодополнения,
— фрагменты на HTML и JavaScript в соответствии с типом полей
— серилиализаторы
— SQL-функции, процедуры и макросы для различных манипуляций с записями, с тем чтобы избегать перечислений полей.
Свой язык придумывать не стал (за исключением макро расширения для MySQL), так как 1) их уже и так полно 2) хотелось бы писать в IDE, c автоподсказками и нормальным дебагом.
Вообще интересно, кто и что использует для такой вот автоматизации.
Как я понимаю из описания, сабж в большей степени предназначен для предоставления гибкости при написании бэкэнда, в то время как большинство CMS его достаточно сильно контролируют. Автоматизация разработки фронтальных компонент похоже не очень сильно развита в сравнении с другими популярными продуктами.
Такая диспропорция может быть востребована, наверное, в большей степени для корпоративных систем, где внутренний фронт не самая главная фишка.
Такая диспропорция может быть востребована, наверное, в большей степени для корпоративных систем, где внутренний фронт не самая главная фишка.
Не могли бы вы привести пример масштабного внедрения системы, написанной на Генераторе проектов?
Для интересующихся конкретными системами, которые были разработаны на Генераторе.
Полный список можно посмотреть здесь: https://www.ustech.ru/ostcgi/ostagn?section=projects&project=all&comp=all/
Чуть подробнее опишу систему MassPay, чтобы был понятен масштаб. Система работает в Сбербанке уже более десяти лет, обеспечивает прием различных платежей на банкоматах. Многие, наверное, пользовались.
Схемотехнически выглядит это примерно так: десятки серверов MassPay круглосуточно функционируют в подразделениях Сбербанка по всей стране, к ним подключены в on-line десятки тысяч банкоматов с одной стороны, и сотни тысяч автоматизированных систем получателей платежей (on-line и off-line) с другой. Миллионы платежных транзакций в сутки обрабатываются в реальном времени. Преимущества Генератора были особенно ощутимы при выпуске очередных версий ПО MassPay с последующим их тотальным тиражированием.
Полный список можно посмотреть здесь: https://www.ustech.ru/ostcgi/ostagn?section=projects&project=all&comp=all/
Чуть подробнее опишу систему MassPay, чтобы был понятен масштаб. Система работает в Сбербанке уже более десяти лет, обеспечивает прием различных платежей на банкоматах. Многие, наверное, пользовались.
Схемотехнически выглядит это примерно так: десятки серверов MassPay круглосуточно функционируют в подразделениях Сбербанка по всей стране, к ним подключены в on-line десятки тысяч банкоматов с одной стороны, и сотни тысяч автоматизированных систем получателей платежей (on-line и off-line) с другой. Миллионы платежных транзакций в сутки обрабатываются в реальном времени. Преимущества Генератора были особенно ощутимы при выпуске очередных версий ПО MassPay с последующим их тотальным тиражированием.
что используется в качестве хранилища данных SQL или NOSQL?
В качестве СУБД мы используем то, что пожелает заказчик. Если не пожелает, то предлагаем свои варианты — обычно из open-source что-нибудь (чаще всего — PostgreSQL 9.x).
В проекте MassPay первоначально использовался MS SQL Server 2000, а потом с лавинообразным ростом нагрузки перешли на Oracle 10g.
Из поддерживаемых сейчас СУБД: Sqlite, PostgreSQL, Oracle, MySQL, MS SQL Server.
Но при необходимости может быть добавлена поддержка новых СУБД через специальный абстрактный уровень взаимодействия с базами.
Ваше отношение к Tarantool?
Использование NoSQL в наших проектах пока не было востребовано. Хотя такой подход хранения данных мы сейчас с интересом рассматриваем для перспективных проектов.
Конкретно Tarantool пока не использовали для этих целей. Но база данных очень интересная — вся в памяти, шибко шустрая.
А, вообще, Генератор постоянно развивается и подстраивается под текущие проекты.
На Генераторе можно сгенерировать операционную систему?
Что касается написания ОС на Генераторе, то здесь вопрос — что такое ОС?
Если речь идет только про ядро, то тоже вопрос — микроядро и много процессов, как в QNX, или монолитное ядро со всеми подсистемами и драйверами, как в Linux?
Если же не только ядро, а весь прикладной базовый софт в придачу, то это третий вариант.
Но теме не менее отвечу так — можно. Для этого придется использовать много полурукописных пакетов на Си — spackage (полурукописный пакет, спецификация на генераторе, часть кода на Си), в которых можно реализовать все критически важные механизмы, а остальную логику можно на штатном языке Генератора написать.
Можно посмотреть язык описания для генерации?
Скоро будет запущен тематический сайт по Генератору проектов с примерами проектов (tutorial), будут выложены полные исходники нескольких старых больших проектов. Там же будет и описание языка.
Я бы хотел отдельно обозначить мотивацию нашего взаимодействия с сообществом.
Мы не ставим перед собой задачу обсуждать достоинства и недостатки традиционных технологий программной разработки, а также их нюансов — языков, библиотек, фреймворков и т.п. Нам интересно обсудить инструментальный подход к программированию сложных программных комплексов — когда-то это называлось «автоматизация программирования». Но предметно говорить на эту тему, скорее всего, мотивированы разработчики больших прикладных систем, поскольку сами проблемы им очевидны.
Ядро ОС — это наверное большой проект, но если в нём мало типового, «рутинного» кода, то вряд ли будет большой эффект от генерации кода.
С другой стороны, есть много «маленьких» проектов, в которых используется генерация кода и других артефактов. Та же генерация документации по комментариям в коде. Или популярный сейчас Swagger может генерить скелеты приложений для разных языков.
Тут наверное основной критерий — это количество рутины в проекте или проектах. Если её много, то есть смысл тратить время на разработку метамоделей, DSL, генераторов и т.п.
Мне интересна ваша штука, потому что мы сами делаем подобные. Но без деталей сложно понять, что это.
С другой стороны, есть много «маленьких» проектов, в которых используется генерация кода и других артефактов. Та же генерация документации по комментариям в коде. Или популярный сейчас Swagger может генерить скелеты приложений для разных языков.
Тут наверное основной критерий — это количество рутины в проекте или проектах. Если её много, то есть смысл тратить время на разработку метамоделей, DSL, генераторов и т.п.
Мне интересна ваша штука, потому что мы сами делаем подобные. Но без деталей сложно понять, что это.
Очень приятно встретить единомышленника, спасибо за проявленный интерес. Как я уже писал, мы готовим в поддержку этой дискуссии большой материал в виде сайта, посвященного Генератору. Там будет много деталей. Но пока это не произошло, милости прошу, задавайте вопросы, я буду отвечать. Может, это и еще кого заинтересует.
Что касается генерации скелетов приложений, то самая важная фишка Генератора в том, что у нас не просто скелет генерится, а поддерживается полноценный жизненный цикл разработки проекта. Т.е. Генератор позволяет многократно вносить изменения в действующий проект с полным контролем соответствия всех внутренних взаимодействий на этапе генерации.
Что касается генерации скелетов приложений, то самая важная фишка Генератора в том, что у нас не просто скелет генерится, а поддерживается полноценный жизненный цикл разработки проекта. Т.е. Генератор позволяет многократно вносить изменения в действующий проект с полным контролем соответствия всех внутренних взаимодействий на этапе генерации.
Sign up to leave a comment.
Генератор проектов