Интересная статья, я нашу программу ПК simintech на линукс затащил и даже тут статью написал по этому поводу. Но у меня система на Delphi исходно и там код в принципе оказался хорошо совместим с Lazarus под Linux. Сейчас кодовую базу для windows и Linux единую сделали. Проблемы были там с исключениями в многопоточном режиме. Завязка на винапи то примерно одинаковая, но вот одно дело если из своего кода его напрямую дергать, другое если вызовы абстрагированы библиотекой.
Я согласен с тем, что ООП вообще скорее это абстрактный стиль написания программы и что его можно реализовывать и на языках не имеющих встроенной его поддержки. Описанную автором методику я применял при разработке некоторых модулей к своей системе, например ядра расчета электрических цепей, которое делалось на годом Си. Зачем так было сделано: чтобы обеспечить кросс языковую структурную совместимость, то есть чтобы без проблем вызывать сишный код из Delphi/fpc и из c/c++, но при этом чтобы код был объектно ориентированный по сути. В принципе это работает и можно делать код несколькими способами, подход даёт повышенную гибкость. Из минусов хочу отметить, что оптимизатор компилятора Си может сделать код при таком подходе менее оптимальным чем если например делать его именно как объекты на плюсах или. Delphi. Проблема только потом что объектная модель компиляторов различается и с совместимостью придется извращаться если в проекте их несколько разных. Если же везде только одни плюсы и один компилятор, всё решается наследованием от абстрактного класса, который описывается в общем интерфейсном заголовочном файле.
В мелких конторах она вообще не применима, потому как там ты можешь называться ведущим программистом или даже техническим директором, но будешь делать все сам.
Да может и так, вот так работаешь в фирме, занимаешься расчëтными программами, а потом она разоряется и ты на улице в 40 лет и по профилю работы уже никуда не берут, а менять специализацию уже поздно.
Да, это факт. После 40 уже даже резюме не читают. Если только по старым знакомствам устраиваться. Особенно если до этого занимался 20 лет узкоспециализированной темой на одном месте работы.
Можно и под qt сделать, но там надо прокладку между qt и Паскалем собирать под строго определенную версию qt и вот с этим как раз бывают проблемы. А Gtk2 есть штатно и в астра линукс и в альт и вроде как и работает нормально.
На Astra Linux я ставил и code typhon и компилировал программу, причём на версии smolensk у меня заводился код который я собирал на alt Linux 9. Также проверяли и на более новой версии Orel. Библиотека gui была использована штатная, то есть. Gtk2 с которой Лазарус работает по умолчанию. Все там завелось. Были проблемы с фортрановскими so, т.к. там требовалась определённая версия фортрана 77 для компиляции, чтобы ошибка не возникала.
Отчасти справедливо. Ну ещё многословность — на Java например, чтобы десктопное приложение с GUI написать кода получается сильно больше в ущерб качеству.
Интересная статья. Я занимался разработкой генератора кода для НПО Аврора и внедрением туда нашего программного комплекса ПК SimInTech в качестве системы проектирования алгоритмов управления и исполнительной системы реального времени.
Насколько я знаю в чистом виде автоматное программирование используют там не все отделы. По крайней мере алгоритмы систем управления энергоустановкой и общекорабельными системами формализуются в форме функционально-блочных диаграмм (+ в некоторых местах с условным выполнением).
Вообще на самом деле даже формально верифицированные алгоритмы управления желательно проверять на хотя бы упрощённой динамической модели объекта управления.
Во многом согласен, делать программу расчёта динамики с тесной интеграцией с Си и ФОРТРАНом и требованиями к скорости рендеринга видеокадров лучше на чём-то, что компилируется в нативный код. А так инструмент определяется задачей.
Вы можете поучаствовать например в добавлении поддержки процессорных архитектур в GCC или FPC, но скорее всего будете делать это за свой счёт. У нас выделяют деньги на разработку компиляторов для собственных процессоров, но это вещи нишевые и за это получают зарплату в профильных НИИ (НИИСИ РАН например). Из примеров успешной отечественной разработки в области языков программирования и сред разработки можно упомянуть наверное Kotlin + среда разработки IntelliJ IDEA, который был выкуплен Google-м и от которого они зарплату и получают собственно — наше государство им не платит ни копейки и живут они за счёт своего популярного и качественного продукта.
Та система (ПК SimInTech) которой мы занимается и особенности портирования которой были описаны в статье развивается давно, является платформообразующей в области расчётов динамики систем и активно используется организациями атомной отрасли и ВПК и деньги мы получаем от них за лицензии, доработки и техническую поддержку программного комплекса.
Было бы конечно просто замечательно если бы на разработки подобного рода выделялось прямое постоянное государственное финансирование, так как это позволило бы вести разработку с полностью открытым исходным кодом, но это во всём мире не так — над ядром Linux в основном работают сотрудники крупных корпораций, которые пишут доработки под свои нужды для своих изделий.
В общем короче: кто хочет делать — сначала делает и внедряет, а потом если это оказывается нужным, то это рано или поздно заметят и купят в той или иной форме.
Интересная статья, я нашу программу ПК simintech на линукс затащил и даже тут статью написал по этому поводу. Но у меня система на Delphi исходно и там код в принципе оказался хорошо совместим с Lazarus под Linux. Сейчас кодовую базу для windows и Linux единую сделали. Проблемы были там с исключениями в многопоточном режиме. Завязка на винапи то примерно одинаковая, но вот одно дело если из своего кода его напрямую дергать, другое если вызовы абстрагированы библиотекой.
Да приходится вообще иногда и такое делать. Могу пример скинуть реализации этого подхода на Delphi и C для конкретной расчетной библиотеки.
Я согласен с тем, что ООП вообще скорее это абстрактный стиль написания программы и что его можно реализовывать и на языках не имеющих встроенной его поддержки. Описанную автором методику я применял при разработке некоторых модулей к своей системе, например ядра расчета электрических цепей, которое делалось на годом Си. Зачем так было сделано: чтобы обеспечить кросс языковую структурную совместимость, то есть чтобы без проблем вызывать сишный код из Delphi/fpc и из c/c++, но при этом чтобы код был объектно ориентированный по сути. В принципе это работает и можно делать код несколькими способами, подход даёт повышенную гибкость. Из минусов хочу отметить, что оптимизатор компилятора Си может сделать код при таком подходе менее оптимальным чем если например делать его именно как объекты на плюсах или. Delphi. Проблема только потом что объектная модель компиляторов различается и с совместимостью придется извращаться если в проекте их несколько разных. Если же везде только одни плюсы и один компилятор, всё решается наследованием от абстрактного класса, который описывается в общем интерфейсном заголовочном файле.
Вы готовы поделиться с ними своей зарплатой?
Ну и хорошо. Зачем мне лично тут лишние конкуренты?
100%. Этих тут только не хватало.
В моем понимании мелкая контора это не больше 10 человек
В мелких конторах она вообще не применима, потому как там ты можешь называться ведущим программистом или даже техническим директором, но будешь делать все сам.
Да может и так, вот так работаешь в фирме, занимаешься расчëтными программами, а потом она разоряется и ты на улице в 40 лет и по профилю работы уже никуда не берут, а менять специализацию уже поздно.
Да, это факт. После 40 уже даже резюме не читают. Если только по старым знакомствам устраиваться. Особенно если до этого занимался 20 лет узкоспециализированной темой на одном месте работы.
Можно и под qt сделать, но там надо прокладку между qt и Паскалем собирать под строго определенную версию qt и вот с этим как раз бывают проблемы. А Gtk2 есть штатно и в астра линукс и в альт и вроде как и работает нормально.
На Astra Linux я ставил и code typhon и компилировал программу, причём на версии smolensk у меня заводился код который я собирал на alt Linux 9. Также проверяли и на более новой версии Orel. Библиотека gui была использована штатная, то есть. Gtk2 с которой Лазарус работает по умолчанию. Все там завелось. Были проблемы с фортрановскими so, т.к. там требовалась определённая версия фортрана 77 для компиляции, чтобы ошибка не возникала.
Да. Про гироскутеры это точно
Вопрос по делу: поработать с нами не хотите? Задача — написать для моделирующего комплекса модуль OPC-UA сервера.
Насколько я знаю в чистом виде автоматное программирование используют там не все отделы. По крайней мере алгоритмы систем управления энергоустановкой и общекорабельными системами формализуются в форме функционально-блочных диаграмм (+ в некоторых местах с условным выполнением).
Вообще на самом деле даже формально верифицированные алгоритмы управления желательно проверять на хотя бы упрощённой динамической модели объекта управления.
Та система (ПК SimInTech) которой мы занимается и особенности портирования которой были описаны в статье развивается давно, является платформообразующей в области расчётов динамики систем и активно используется организациями атомной отрасли и ВПК и деньги мы получаем от них за лицензии, доработки и техническую поддержку программного комплекса.
Было бы конечно просто замечательно если бы на разработки подобного рода выделялось прямое постоянное государственное финансирование, так как это позволило бы вести разработку с полностью открытым исходным кодом, но это во всём мире не так — над ядром Linux в основном работают сотрудники крупных корпораций, которые пишут доработки под свои нужды для своих изделий.
В общем короче: кто хочет делать — сначала делает и внедряет, а потом если это оказывается нужным, то это рано или поздно заметят и купят в той или иной форме.