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

Question

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

C (++):

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

* LabVIEW 1015 *

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

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

Также:

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

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

---

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

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

---

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

Answer 1

До моего приезда наша группа (ученые PhD, с небольшим опытом программирования) пыталась включать и выключать приложение LabVIEW в течение почти года. Код был неопрятным, слишком сложным (передний и задний) и, самое главное, не работал. Я увлеченный программист, но никогда не использовал LabVIEW. С небольшой помощью гуру LabVIEW, который мог помочь мне перевести текстовые парадигмы программирования, которые я знал, в концепции LabVIEW, можно было кодировать приложение за неделю. Дело в том, что базовые концепции кодирования еще нужно выучить, язык, даже такой, как LabVIEW, это просто другой способ их выражения .

LabVIEW отлично подходит для того, для чего он изначально был разработан. то есть брать данные с карт DAQ и отображать их на экране, возможно, с небольшими манипуляциями между ними. Однако программирование алгоритмов не легче, и я бы даже предположил, что это сложнее. Например, в большинстве процедурных языков порядок выполнения обычно следует построчно, используя псевдоматематическую нотацию (т. Е. y = x*x + x + 1), тогда как LabVIEW реализует это с использованием ряда ВП, которые не обязательно следуют друг от друга (т. Е. Слева направо). правильно) на холсте.

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

Я полагаю, что некоторые аспекты графического программирования могут стать мейнстримом - использование sub-VI прекрасно воплощает принцип «черного ящика» программирования, а также используется в других языковых абстракциях, таких как Yahoo Pipes и Apple Automator - и, возможно, какой-то будущий графический язык произведет революцию в том, как мы программируем, но сам LabVIEW не является огромным изменением парадигмы в дизайне языка, у нас все еще есть while, for, if управление потоком, типизация, программирование на основе событий, даже объекты. Если будущее действительно будет написано в LabVIEW, программисту на C ++ не составит труда перейти на другую страницу.

В качестве постскриптума я бы сказал, что C / C ++ больше подходит для робототехники, поскольку студентам, несомненно, придется в какой-то момент иметь дело со встроенными системами и ПЛИС. Знания о низком уровне программирования (биты, регистры и т. Д.) Были бы неоценимы для такого рода вещей.

@ mendicant На самом деле LabVIEW широко используется в промышленности, особенно для систем управления. Предоставленный NASA вряд ли будет использовать его для бортовых спутниковых систем, но тогда разработка программного обеспечения для космических систем - это совершенно другая игра с мячом ...

Answer 2

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

И теперь я должен помешать себе написать 5-страничную речь, потому что для меня LabVIEW стал кошмаром. Позвольте мне вместо этого попытаться суммировать некоторые плюсы и минусы:

Отказ от ответственности Я не эксперт LabVIEW, я мог бы сказать, что предвзятые, устаревшие или просто неправильно:)

LabVIEW профи

• Да, легко выучить . Многие доктора наук в нашей группе, кажется, приобрели достаточно навыков, чтобы взломать их в течение нескольких недель или даже меньше.
• Библиотека . Это важный момент. Вам придется тщательно исследовать это в вашей собственной ситуации (я не знаю, что вам нужно, если для этого есть хорошие библиотеки LabVIEW или есть альтернативы на других языках). В моем случае найти, например, хорошую, быструю библиотеку диаграмм в Python, было серьезной проблемой, которая помешала мне переписать некоторые из наших программ на Python.
• Возможно, в вашей школе он уже установлен и работает.

LabVIEW минусы

• Возможно, слишком легко выучить. В любом случае, кажется, никто не утруждает себя изучением лучших практик, поэтому программы быстро превращаются в полный, непоправимый беспорядок. Конечно, это также должно произойти с текстовыми языками, если вы не будете осторожны, но IMO намного сложнее сделать все правильно в LabVIEW.
• В LabVIEW, как правило, возникают серьезных проблем с поиском под-VI (я думаю, даже до версии 8.2). LabVIEW имеет свой собственный способ узнать, где найти библиотеки и под-VI, что позволяет очень легко полностью сломать ваше программное обеспечение. Это делает большие проекты болью, если рядом нет человека, который знает, как с этим справиться.
• Трудно заставить LabVIEW работать с контролем версий . Конечно, это можно сделать, но в любом случае я бы воздержался от использования встроенного VC. Проверьте LVDiff для инструмента сравнения LabVIEW, но даже не думайте о слиянии.

(Последние два пункта затрудняют работу в команде над одним проектом. Это, вероятно, важно в вашем случае)

• Это личное, но я считаю, что многие алгоритмы просто не работают, когда программируются визуально. Это беспорядок .
  • Одним из примеров является материал, который является строго последовательным; это становится громоздким довольно быстро.
  • Трудно иметь общий обзор кода.
  • Если вы используете подпункты VI для небольших задач (точно так же, как хорошая практика - создавать функции, выполняющие небольшие задачи и помещающиеся на одном экране), вы не можете просто дать им имена, но вы должны нарисовать иконки для каждого из них. Это становится очень раздражающим и громоздким всего за несколько минут, так что вы очень искушаетесь , а не , чтобы поместить материал в суб-VI. Это слишком много хлопот. Кстати: создание действительно хорошей иконы может занять несколько часов. Попробуй сделать уникальный, сразу понятный, узнаваемый значок для каждого под-ВП, который ты пишешь:)
• Через неделю у вас будет запястный канал. Гарантированный.
• @ Брендан: слушай, слушай!

Заключительные замечания

Что касается вашего вопроса «я должен написать свои собственные модули»: я не уверен. Зависит от ваших временных ограничений. Не тратьте время на то, чтобы заново изобрести колесо, если не нужно. Слишком легко потратить дни на написание низкоуровневого кода, а затем понять, что у тебя не хватает времени. Если это означает, что вы выбрали LabVIEW, сделайте это.

Если бы были простые способы объединить LabVIEW и, например, C ++, я бы хотел услышать об этом: это может дать вам лучшее из обоих миров, но я сомневаюсь, что они есть.

Но убедитесь, что вы и ваша команда уделяете время изучению лучших практик. Глядя на код друг друга. Учимся друг у друга. Написание полезного, понятного кода. И веселиться!

И, пожалуйста, прости меня за то, что я звучу остро и, возможно, немного педантично. Просто LabVIEW стал для меня настоящим кошмаром:)

Answer 3

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

Это не значит, что программирование на LabVIEW, конечно, не является рыночным навыком; просто он не такой массовый, как C ++.

LabVIEW чрезвычайно облегчает параллельное управление различными вещами, которые вы вполне можете иметь в ситуации управления роботом. Условия гонки в коде, который должен быть последовательным, также не должны быть проблемой (то есть, если они есть, вы делаете это неправильно): существуют простые методы, чтобы убедиться, что все происходит в правильном порядке, где это необходимо - объединение в цепочку subVI с использованием проводник ошибок или другие данные, используя уведомители или очереди, строят структуру конечного автомата, даже используя структуру последовательности LabVIEW, если это необходимо. Опять же, это просто случай, когда вам нужно время, чтобы понять инструменты, доступные в LabVIEW, и то, как они работают. Я не думаю, что необходимость делать иконки subVI очень хорошо направлена; Вы можете очень быстро создать текст, содержащий несколько слов текста, возможно, с цветом фона, и это подойдет для большинства целей.

«Графические языки - путь будущего» - красная сельдь, основанная на ложной дихотомии. Некоторые вещи хорошо подходят для графических языков (например, параллельный код); другие вещи подходят текстовым языкам намного лучше. Я не ожидаю, что LabVIEW и графическое программирование либо исчезнут, либо захватят мир.

Кстати, я был бы очень удивлен, если бы НАСА не использовало LabVIEW в космической программе. Кто-то недавно описал в списке рассылки Info-LabVIEW, как он использовал LabVIEW для разработки и тестирования замкнутого контура управления полетными поверхностями, приводимыми в действие электродвигателями на Boeing 787, и создал впечатление, что LabVIEW широко использовался при разработке самолета. Он также используется для управления в реальном времени в Большом адронном коллайдере!

Наиболее активным местом для получения дополнительной информации и помощи с LabVIEW, помимо собственного сайта и форумов National Instruments, является LAVA .

Answer 4

Другая сила LabVIEW (кроме библиотек) - параллелизм . Это язык потока данных , что означает, что среда выполнения может обрабатывать параллелизм для вас. Поэтому, если вы делаете что-то одновременно и не хотите выполнять традиционную синхронизацию, LabVIEW может помочь вам в этом.

Будущее не принадлежит графическим языкам в их нынешнем виде. Он принадлежит тому, кто может представить представление потока данных (или другого типа программирования, ориентированного на параллелизм), которое так же просто, как графический подход, но также может быть проанализировано собственными инструментами программиста.

Answer 5

Это не дает прямого ответа на ваш вопрос, но вы можете рассмотреть третий вариант микширования на интерпретируемом языке. Например, Lua - это уже , используемое в области робототехники. Он быстрый, легкий и может быть настроен для работы с числами с фиксированной запятой вместо плавающей запятой, так как большинство микроконтроллеров не имеют FPU. Forth - другая альтернатива с аналогичным использованием.

Должно быть довольно просто написать тонкий интерфейсный слой на C, а затем позволить ученикам проигрывать интерпретированные сценарии. Вы даже можете настроить его так, чтобы код загружался динамически, без перекомпиляции и перепрошивки чипа. Это должно сократить цикл итераций и позволить учащимся лучше учиться, быстрее видя результаты.

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

Answer 6

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

Однако самое большое падение LabVIEW заключается в том, что вы теряете все инструменты, которые программисты пишут для себя.

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

Это отстой , когда у вас есть приложение на 5000 VI, которое требует универсальной настройки. Ваша опция only состоит в том, чтобы проходить каждый ВП вручную, и, боже, поможет вам, если вы пропустите изменение в одном ВП где-нибудь в углу.

И да, поскольку это двоичный файл, вы не можете делать diff / merge / patch, как вы можете с текстовыми языками. Это действительно делает работу с более чем одной версией кода ужасным кошмаром обслуживания.

В любом случае, используйте LabVIEW, если вы делаете что-то простое, или вам нужно создать прототип, или вы не планируете поддерживать свой код.

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

(О, и если вам нужны библиотеки DAQ, у NI также есть версии на C ++ и .Net.)

Answer 7

Мой первый пост здесь :) Будь нежнее ...

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

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

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

Answer 8

Я думаю, что графические языки всегда будут ограничены в выразительности по сравнению с текстовыми. Сравните попытки общения в визуальных символах (например, REBUS или язык жестов) с общением, используя слова.

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

Еще одна дискуссия, подразумеваемая в этом аргументе, это декларативное программирование против императива. Декларативное обычно лучше для всего, где вам действительно не нужен детальный контроль над тем, как что-то делается. Вы можете использовать C ++ декларативным способом, но вам потребуется больше усилий, чтобы сделать это, тогда как LABView разработан как декларативный язык.

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

Answer 9

Существует опубликованное исследование по теме, организованное National Instruments:

Исследование графического и текстового программирования для обучения DSP

В частности, он сравнивает LabVIEW с MATLAB (в отличие от C).

Answer 10

Боже мой, ответ так прост. Используйте LabView .

Я программировал встраиваемые системы в течение 10 лет, и я могу сказать, что без хотя бы пары месяцев инфраструктуры (очень осторожная инфраструктура!) Вы не будете так продуктивны, как в первый день работы с LabView .

Если вы разрабатываете робота для продажи и использования в военных целях, начните с C - это хороший вызов.

В противном случае, используйте систему, которая позволяет вам попробовать самые разнообразные в кратчайшие сроки. Это LabView .