Комментарии 17
Возможно немного глупый вопрос, но разве Simulink нельзя отнести к визуальному программированию?
Велосипед — это, конечно, хорошо, но иногда стоит попробовать поискать открытый бесплатный вариант.
www.proview.se — эта штука реально работает на промышленных объектах.
www.proview.se — эта штука реально работает на промышленных объектах.
Спасибо! Интересно будет сравнить по функциональности как например Proview on Raspberry PI и модули ввода-вывода.
Проблема визуального программирования (скажем, в Симулинке) — сложности с разделением и повторным использованием кода.
Ну т.е. достаточно легко нарисовать довольно крупное приложение из одной модели — а потом героически воевать с его сопровождением. При этом модель «идеологически» предполагается уникальной сущностью, в противоположность функции в программировании — и, плюс, поощряется использование глобальных переменных.
Ну и куча всяких нюансов — типа «что проще» — ползать по множеству вложенных менюшек, выискивая чекбоксы, настривающие хитрым образов каждый элемент — или тупо и просто написать «far uint» там, где вам это нужно.
Ну и, опять же — постоянные поиски того, «как же сделать хитрую фичу, которую я тексте я набью за пол-секунды» — тоже слегка напрягает.
(Пользуюсь симулинком регулярно.)
Ну т.е. достаточно легко нарисовать довольно крупное приложение из одной модели — а потом героически воевать с его сопровождением. При этом модель «идеологически» предполагается уникальной сущностью, в противоположность функции в программировании — и, плюс, поощряется использование глобальных переменных.
Ну и куча всяких нюансов — типа «что проще» — ползать по множеству вложенных менюшек, выискивая чекбоксы, настривающие хитрым образов каждый элемент — или тупо и просто написать «far uint» там, где вам это нужно.
Ну и, опять же — постоянные поиски того, «как же сделать хитрую фичу, которую я тексте я набью за пол-секунды» — тоже слегка напрягает.
(Пользуюсь симулинком регулярно.)
В bitreactive переиспользование решено за счет создания Building Block и размещения их в репозитарий. В том числе для диаграммы можно описать ее вводы-выводы и сохранить как Building Block.
По поводу удобства и культуры разработки с вами, наверное, сможет поспорить AndreyDmitriev.
Лично я предпочитаю текстовые языки разработки визуальным, но это мой хлеб.
По поводу удобства и культуры разработки с вами, наверное, сможет поспорить AndreyDmitriev.
Лично я предпочитаю текстовые языки разработки визуальным, но это мой хлеб.
Поспорить можно о чём угодно — но проблема в том, что великай «Тойота», кажется, имеет серьёзные проблемы в своём ПО — которое, как я слышал — разрабатывает именно в Симулинке.
Ну тут скорее не «Проблема визуального программирования», а просто уровень владения инструментом и область применимости самого инструмента к какой-то конкретной задаче.
Вообще «кривая изучения» визуального языка (если взять тот же LabVIEW как пример) на мой взгляд несколько отличается от «кривой изучения» языка текстового. В графическом языке довольно низкий «порог вхождения», но вот затем для уверенной разработки сложных систем потребуется положить куда как больше времени нежели в текстовом языке. Мне думается, это связано с тем, что текстовый язык несколько «беднее» графического в синтаксическом смысле — вначале нужно изучить конструкции и сравнительно небольшое количество ключевых слов, а затем разработка идёт на паттернах проектирования да библиотеках.
Это всё равно что разница между китайским и английским — в одном случае иероглифы, коих тысячи, а в другом — всего 26 букв. Вероятно уже на первом уроке мы сможем написать довольно длинную фразу всего несколькими иероглифами, но затем последует довольно утомительный период изучения.
У меня, кстати, обратная ситуация — я сейчас изучаю C#, и цель — довести владение до уровня профи, и вот там, где я в несколько щелчков могу набросать наглядный код на LabVIEW (где у меня шестнадцать лет опыта), в текстовом языке я пока что «программирую», порой не вылезая из гугля, stackoverflow и Албахари. Впрочем я ещё не прошёл ту точку, когда удобство обоих инструментов сравняется — для меня пока что LabVIEW заметно комфортнее.
Вообще «кривая изучения» визуального языка (если взять тот же LabVIEW как пример) на мой взгляд несколько отличается от «кривой изучения» языка текстового. В графическом языке довольно низкий «порог вхождения», но вот затем для уверенной разработки сложных систем потребуется положить куда как больше времени нежели в текстовом языке. Мне думается, это связано с тем, что текстовый язык несколько «беднее» графического в синтаксическом смысле — вначале нужно изучить конструкции и сравнительно небольшое количество ключевых слов, а затем разработка идёт на паттернах проектирования да библиотеках.
Это всё равно что разница между китайским и английским — в одном случае иероглифы, коих тысячи, а в другом — всего 26 букв. Вероятно уже на первом уроке мы сможем написать довольно длинную фразу всего несколькими иероглифами, но затем последует довольно утомительный период изучения.
У меня, кстати, обратная ситуация — я сейчас изучаю C#, и цель — довести владение до уровня профи, и вот там, где я в несколько щелчков могу набросать наглядный код на LabVIEW (где у меня шестнадцать лет опыта), в текстовом языке я пока что «программирую», порой не вылезая из гугля, stackoverflow и Албахари. Впрочем я ещё не прошёл ту точку, когда удобство обоих инструментов сравняется — для меня пока что LabVIEW заметно комфортнее.
«Кривая обучения» в визуально программировании действительно напоминает таковую, скажем, для Бейсика — начать легко, а потом…
Я, во всяком случае — могу точно сказать, что многие вещи, которые в «текстовых» языках решаются элементарно — например, экспорт переменных — в Симулинке решаются с заметными затратами (опишите каждую из десятка переменных).
Плюс «приделывание» ООП к оному — выглядит весьма непростой задачей.
А пордразумеваемая идеология «Один проект — одна модель» качеству кода отнюдь не способствует.
Так что мне ближе к душе C++, нежели чем «квадратики».
Вопрос, впрочем, может быть связан с областью определения — LabVIEW под свои задачи может быть и удобнее.
Я, во всяком случае — могу точно сказать, что многие вещи, которые в «текстовых» языках решаются элементарно — например, экспорт переменных — в Симулинке решаются с заметными затратами (опишите каждую из десятка переменных).
Плюс «приделывание» ООП к оному — выглядит весьма непростой задачей.
А пордразумеваемая идеология «Один проект — одна модель» качеству кода отнюдь не способствует.
Так что мне ближе к душе C++, нежели чем «квадратики».
Вопрос, впрочем, может быть связан с областью определения — LabVIEW под свои задачи может быть и удобнее.
а в чем преимущество данной системы например перед LabVIEW?
В готовых компонентах для IoT, интеграции с облачными сервисами и аппаратным обеспечением сторонних производителей
а где можно посмотреть это список компонентов и поддерживаемого оборудования?
Библиотеки доступны здесь. Из самой среды разработки в eclipse можно найти доступные блоки.
Документация доступна здесь. Там же ссылки на реализованные проекты и туториалы.
Из аппаратных все что поддерживает eclipse kura плюс то что поддерживается библиотеками. И кое что от партнеров по интеграции, например Bitreactive AS: NXP Partner
Libraries totally:
533
Available blocks:
2388
Users:
2525
Документация доступна здесь. Там же ссылки на реализованные проекты и туториалы.
Из аппаратных все что поддерживает eclipse kura плюс то что поддерживается библиотеками. И кое что от партнеров по интеграции, например Bitreactive AS: NXP Partner
Нашел пример еще пример поддерживаемого оборудования EDCK 4001 Everyware Device Cloud от Eurotech
Эта система несколько отличается от «чистого» LabVIEW в том смысле, что тут скорее строится машина состояний, причём на довольно высоком уровне, а LabVIEW — это по сути «классические» низкоуровневые конструкции типа циклов for, while, блоков switch, работы с массивами и т.д., обёрнутые в графическое представление и завязанные на data flow принцип. Идеологически ближе к этой системе NI LabVIEW Statechart Module — это такая надстройка над LabVIEW, но там нет такого количества «готовых» блоков.
Интересное замечание! Концепция потоков данных используется и в bitreactive. Это позволяет проще писать параллельный код в отличии от императивного подхода.
В building blocks тоже можно спускаться на такой уровень, но тогда теряется смысл, так как можно спуститься в java и написать там компактнее чем визуальное предствление.
В building blocks тоже можно спускаться на такой уровень, но тогда теряется смысл, так как можно спуститься в java и написать там компактнее чем визуальное предствление.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как разработать приложение для автоматизации почти не умея программировать. Придется выучить IDE…