Текстовые и графические языки программирования

Question

Я являюсь частью команды роботов средней школы, и есть некоторые споры о том, какой язык использовать для программирования нашего робота. Мы выбираем между C (или, возможно, C ++) и LabVIEW. Есть плюсы для каждого языка.

C (++):

• Широко используется
• Хорошая подготовка к будущему (большинство позиций программирования требуют текстовых программистов.)
• Мы можем расширить нашу кодовую базу C с прошлого года
• Позволяет нам лучше понять, что делает наш робот.

* LabVIEW 1015 *

• Проще визуализировать ход программы (блоки и провода, а не строки кода)
• Проще учить (предположительно ...)
• «Будущее программирования - графическое». (Так думаете?)
• Ближе к истории Robolab, которую могут иметь некоторые новые участники.
• Не нужно глубоко знать, что происходит. Просто скажите модулю найти красный шар, не нужно знать, как.

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

Также:

• Считаете ли вы, что графические языки, такие как LabVEIW, - это будущее программирования?
• Легче ли изучать графический язык, чем текстовый? Я думаю, что они должны быть примерно такими же сложными в изучении.
• Видя, что мы неравнодушны к тому, чтобы помогать людям учиться, сколько мы должны полагаться на заранее написанные модули и сколько мы должны пытаться писать самостоятельно? ("Хорошие программисты пишут хороший код, отлично программисты копируют отличный код. «Но разве не стоит быть хорошим программистом, во-первых?)

Спасибо за совет!

---

Edit: Я хотел бы подчеркнуть этот вопрос больше: Капитан команды считает, что LabVIEW лучше для простоты обучения и преподавания. Это правда? Я думаю, что С можно научить так же легко, и задачи начального уровня все еще будут рядом с С. Мне бы очень хотелось услышать ваше мнение. Есть ли какая-то причина, по которой набирать while {} должно быть сложнее, чем создавать "while box"? Разве не так интуитивно понятно, что программа работает построчно, модифицируется только ifs и Циклы, поскольку интуитивно понятно, что программа проходит через провод, изменяемый только с помощью ifs и циклов!?

Еще раз спасибо!

---

Edit: Я только что понял, что это подпадает под тему «языковых дебатов». Я надеюсь, что все в порядке, потому что речь идет о том, что лучше для конкретной отрасли программирования с определенными целями. Если нет ... прости ...

Answer 1

Кажется, что если вы пытаетесь подготовить нашу команду к будущему программированию, то C (++) может стать лучшим путем. Похоже, что обещание общих языков программирования, построенных с использованием визуальных строительных блоков, никогда не осуществилось, и я начинаю задумываться, будут ли они когда-нибудь. Кажется, что, хотя это может быть сделано для конкретных проблемных областей, как только вы попытаетесь решить много общих проблем, текстовый язык программирования будет трудно победить.

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

Answer 2

Я начал работать с LabVIEW около 2 лет назад, и теперь все время использую его, поэтому могу быть предвзятым, но нахожу его идеальным для приложений, где требуется сбор данных и контроль.

Мы используем LabVIEW в основном для тестирования, где мы проводим непрерывные измерения и контролируем газовые клапаны и корпуса ATE. Это включает в себя как цифровые, так и аналоговые входы и выходы с процедурами анализа сигналов и управления процессом, которые выполняются из графического интерфейса. Разбивая каждую часть на подвиды, мы можем перенастроить тесты одним щелчком мыши.

Не совсем то же самое, что C / C ++, но аналогичная реализация измерения, контроля и анализа с использованием Visual BASIC кажется сложной и трудной для поддержки при сравнении.

Я думаю, что процесс программирования важнее, чем реальный язык кодирования, и вы должны следовать рекомендациям по стилю для графического языка программирования. Блок-схемы LabVIEW показывают поток данных ( Программирование потока данных ), поэтому должно быть легко увидеть потенциальные условия гонки, хотя у меня никогда не было проблем. Если у вас есть кодовая база C, то ее встраивание в dll позволит LabVIEW вызывать ее напрямую.

Answer 3

Капитан команды считает, что LabVIEW лучше для простоты обучения и учение. Это правда?

Я сомневаюсь, что это было бы верно для любого отдельного языка или парадигмы. LabView, безусловно, может быть проще для людей с опытом работы в области электроники; Создание программ в нем - это «просто» рисование проводов. С другой стороны, такие люди уже могут быть знакомы с программированием.

Одно существенное отличие, помимо графического, заключается в том, что LV - это программирование, основанное на потребностях (потоке). Вы начинаете с итогов и рассказываете, что нужно для этого. Традиционное программирование имеет тенденцию быть обязательным (наоборот).

Некоторые языки могут предоставить оба варианта. Недавно я создал многопоточную библиотеку для Lua (Lanes), и ее можно использовать для программирования по требованию в остальной императивной среде. Я знаю, что успешные роботы в основном работают в Луа ( Сумасшедший Иван в Луа О Шесть).

Answer 4

Люди всегда сравнивают labview с C ++, и день "о, labview - это высокий уровень, и в нем так много встроенной функциональности, попробуйте получить данные, выполнив загрузку и отобразив данные, их так легко в labview попробовать в C ++".

Миф 1: С C ++ трудно что-либо сделать, потому что на его низком уровне и в labview уже реализовано много вещей. Проблема в том, что если вы разрабатываете роботизированную систему на C ++, вы ДОЛЖНЫ использовать библиотеки, такие как opencv, pcl ... ect, и вы будете еще умнее, если будете использовать программную среду, предназначенную для создания роботизированных систем, таких как ROS (операционная система робота). Поэтому вам нужно использовать полный набор инструментов. На самом деле, когда вы используете ROS + python / c ++ с такими библиотеками, как opencv и pcl, доступны более высокоуровневые инструменты. Я использовал робототехнику labview, и, честно говоря, широко распространенных алгоритмов, таких как ICP, там нет, и теперь вы не можете легко использовать другие библиотеки.

Миф2: легче ли понимать языки графического программирования

Это зависит от ситуации. Когда вы кодируете сложный алгоритм, графические элементы займут ценное место на экране, и вам будет сложно понять метод. Чтобы понять код labview, вы должны прочитать область, сложность которой составляет O (n ^ 2), в коде, который вы только что прочитали сверху вниз.

Что делать, если у вас есть параллельные системы. ROS реализует архитектуру на основе графов, основанную на сообщениях подписчика / издателя, реализованных с использованием обратного вызова, и довольно легко запускать и обмениваться данными несколькими программами. Разделение отдельных параллельных компонентов облегчает отладку. Например, переход по параллельному коду labview - это кошмар, потому что скачки потока управления образуют одно место в другое. В ROS вы явно не «вытягиваете свою архитектуру, как в labview, однако вы все равно можете увидеть ее, выполнив команду ros run rqt_graph (которая покажет все подключенные узлы)

«Будущее программирования - графическое». (Так думаете?)

Надеюсь, что нет, текущая реализация labview не позволяет кодировать текстовые и графические методы. (есть математика, но это невероятно медленно)

Его сложно отладить, потому что вы не можете легко скрыть параллелизм.

Трудно читать код labview, потому что там вам приходится просматривать большую область.

Labview отлично подходит для обработки данных и обработки сигналов, но не для экспериментальной робототехники, поскольку большинство высокоуровневых компонентов, таких как SLAM (одновременная локализация и отображение), регистрация облака точек и т. Д. Отсутствуют. Даже если они добавляют эти компоненты и их легко интегрировать, как в ROS, потому что labview является проприетарным и дорогим, они никогда не поспевают за сообществом открытого исходного кода.

В итоге, если labview - это будущее для мехатроники, я изменяю свой карьерный путь на инвестиционный банкинг ... Если я не могу наслаждаться своей работой, я могу также заработать немного денег и рано уйти на пенсию ...

Answer 5

Определенно есть достоинства для обоих вариантов; тем не менее, поскольку ваш домен является образовательным опытом, я думаю, что решение C / C ++ принесет наибольшую пользу студентам. Графическое программирование всегда будет опцией, но просто не предоставляет функциональности элегантным способом, который сделает его более эффективным, чем текстовое программирование для низкоуровневого программирования. Это неплохая вещь - весь смысл абстракции состоит в том, чтобы дать новое понимание и взгляд на проблемную область. Причина, по которой я полагаю, что многие могут быть разочарованы графическим программированием, заключается в том, что для любой конкретной программы прирост перехода от программирования на C к графическому отличается от перехода от ассемблера к C.

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