Python-сообщество

Доброго времени суток ! Существует такая корпорация Autodesk, она выполняет ПО в различных областях. Когда то давно выкупили такую программу как Revit для инженеров и архитекторов. К пожеланиям пользователей не прислушиваются. ПРодукт уже морально устарел. Но компания занимается скупкой непонятных стартапов и выпускает довески к Revit с уклоном в менеджмент(достаточно посмотреть линейку продукции Autodesk). Но появилась интересная группа людей которая решила связать API Revit со своей платформой граффического программирования , вот их ресурс http://dynamobim.com/. ПРограмируют на designskript и IronPython с уклоном в последний. Возможности программы и ноды есть на сайте. ПРограмма позиционируется как способ програмировать людям без знания языка програмирования или как введение в програмирования и при этом еще решение любых инженерных задач. В моем понимании (и по опыту) инженерные задачи эточисленные методы , комбинаторика и тд и тп и проще и лучше решать вопросы непосредственным программированием нежели игрой с граффическими объектами. Хотелось бы услышать ваше мнение по этому поводу !

Не знаю как сейчас, а во времена моей юности были популярны радиоконструкторы: наборы готовых радиокомпонентов, которые можно было легко соединять между собой и получать простые функционирующие цепи. Для школьников старших классов весьма занятная штука, для человека профессионально занимающегося радиоэлектроникой - просто игрушка, несмотря на то, что теоретически на элементах радиоконструктора можно собрать сколь угодно сложную схему. Это как бы аналогия. А если ближе к теме, то задумайтесь вот над каким вопросом: ну ладно, хорошо, нарисовали мы в каком-то специальном редакторе нашу программу - набор связанных какими-то отношениями блоков, что дальше то?
А дальше эту схему во-первых надо как-то сохранить на диск, а во-вторых как-то выполнить. В любом случае вы придете к какому-то формальному языку, который графически представляется этой схемой. То есть фактически вы получите своеобразную IDE. То есть можно взять любой язык программирования и сделать для него ИДЕ, которая будет транслировать блок-схемы в слова и операторы этого языка. Задача вообще-то не сложная, это гораздо проще, чем разобрать программу в синтаксическое дерево. Возвращаясь к нашей аналогии, внутри кубиков конструктора таки настоящие транзисторы и конденсаторы, и, разумеется, специалисту кубики как посредник не нужны.
Резюме: полезность сего околонулевая.

Отредактировано FishHook (Янв. 20, 2016 19:01:12)

miko2009
ПРограмма позиционируется как способ програмировать людям без знания языка програмирования

Будучи радиолюбителем - могу присоединиться к метафоре и добавить от себя
Полезность - не нулевая! Она отрицательная.

Да можно открыть програмку и натыкать мышкой по картинкам…
Натыкал а оно не заработало - как? Почему? Как найти причину? По цвету кубиков или названию?

Чему научится человек играя с кубиками?
Давайте абстрагируемся от сложной аналогии и перейдем к азам - сначала ребенка учат алфавиту и правилам работы с буквами по непревзойденному мануалу “Букварь”.
Почле чего дабы развивать процесс игровым стилем дают придурковатые кубики из которых ребенок строит домик по форме а не по буквам…
Тут точно также

Подобные темы неоднократно обсудались на форуме радиолюбителей по программированию микроконтроллеров. Я сам даже создал видеокурс по программированию АВР для чайников… так вот приходили люди которые писали в студии где уже были кубики… через две недели кидали ето УГ - садились за обычную IDE и через 2 недели достигали уровня осознания того что кубики х//ня

FishHook я вас понимаю на все 100% и аналогию понял так как занимался в 5 классе радиоконструированием (подслушивающие устройства , сигнализация детской , электрошокер и тд) и понимаю это, вот только в инженерной среде програмка Dynamo позиционируется как некая революция но по факту решают детские задачки оторванные от реальности ….. Само Dynamo написанно толи на C# толи на C++ (насколько я понимаю что бы оптимизировать программку а не отдать это на автоматику как в Python) но граффические блоки нодов поддерживают IronPython. Я пытался решить одну из задач которая остро стоит перед инженерами конструкторами. Описать работу одного класса в котором содержится порядка 40 типов и у каждого типа есть сотни и тысячи экземпляров. Так вот наппример у программы Revit нету объекта API который бы унаследовал тип класса , тип каждого элемента приходится искать путем написания различных алгоритмов , а так как API еще желает лучшего то таких алгоритмов я уже написал около 3 десятков для одной этой задачи. В итоге я бросил с граффическим програмированием еще в начале пути и начал просто изучать синтаксис Python и решать “классическим” способом по учебнику. ВОт у меня и закрался вопрос , а может я чего то не допонял в граффическом программировании. Оно еще позиционируется что можно собирать коды бестрее чем классически текстом. Переубедить сообщество очень сложно вот я и решил спросить где правда и услышать компетентное мнение.

Отредактировано miko2009 (Янв. 20, 2016 19:45:57)

ZerG
Подобные темы неоднократно обсудались на форуме радиолюбителей по программированию микроконтроллеров. Я сам даже создал видеокурс по программированию АВР для чайников… так вот приходили люди которые писали в студии где уже были кубики… через две недели кидали ето УГ - садились за обычную IDE и через 2 недели достигали уровня осознания того что кубики х//ня

Я не архитектор и по этому не могу оценивать Revit. Но если кого-то интересует моё мнение по поводу графического программирования, то безусловно за ним будущее.

1 Как правильно заметили граф язык тоже язык. Т.Е. язык нужен в любом случае. Кто говорит что его нет просто шарлатан.
2. Граф язык декларируют как более простой по сравнению с классическими. Это так, но за счет снижения его возможностей. Если в обычных ЯП оставить только арифметические действия его тоже будет просто изучить.

Важна адекватность языка и предметной области. Возьмите Симулинк, или систему моделирования электрических схем. Перерисовать схему с листочка проще чем написать программу. Тыкать виртуальным осциллографом также как реальным проще чем сделать в питоне import pylab as plt;plt.plot(x,y,“+-” );plt.show(). Если надо сравнить пару цифр, то тогда есть смысл делать это в граф оболочке.
Однако у меня не выжила ни одна графическая модель. После отрисовки надо подобрать рабочую точку, проверить устойчивость, оптимизировать режимы, из субд элементов подобрать наиболее дешевые, но позволяющие решить задачу и т.п. Граф язык в виде блок схем либо не позволяет выразить такие абстракции либо это намного сложнее чем на питоне или другом ЯП. Однако это другая задача, для нее возьмите Wolfram Mathematica. Эти задачи там решаются легко. Причем интерфейс практически тоже графический - можно “рисовать” красивые дифференциальные уравнения, работать с формулами, НО он адекватен другой предметной области.

По факту сейчас студенты мучаются. В симулинке рисуют модель управляемого объекта (6-8 дифуров). Дальше цепляют транслятор, который из этого делает код для заливки в stm32. Цепляют к регулятору, проверяют качество регулирования (в железе). Работают полтора месяца. Тот-же код на гольном C был бы 10 строчек для модели и 30 строчек для регулятора, максимум пару часов работы. Но ответ прост, мы на C не умеем писать :) Про оптимизацию вообще говорить не приходится.

Т.е. знать граф языки полезно, но знать ЯП общего назначения еще полезнее. Будущее не за граф языками, а за языками приспособленными для предметной области. Сомневаюсь что граф языки смогут заметно потеснить классические языки в ближайшие 10 лет. Нужно и то и то.

Отредактировано doza_and (Янв. 20, 2016 22:45:46)

Да?
Ну вот доучатся эти студенты! Сдадут лабораторные работы - пойдут на работу….. менеджерами по продажам… потому что по профилю работать не смогут…


Форум программистов же:
Неужели вы думаете что эти инженеры сложат из кубиков с буквами
Слово “ВЕЧНОСТЬ” ? (а это кстати основная работа программиста)

ZerG
Да?
Ну вот доучатся эти студенты! Сдадут лабораторные работы - пойдут на работу….. менеджерами по продажам… потому что по профилю работать не смогут…