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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Профили LabVIEW

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

LabVIEW cons

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

Единственное крупное падение LabVIEW - это то, что вы теряете все инструменты, которые программисты пишут сами.

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

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

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

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

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

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

Ответ 10

Я думаю, что графические языки могут быть языком будущего..... для всех тех разработчиков adhoc MS Access. Всегда будет место для чисто текстовых кодировщиков.

Лично я должен спросить, что представляет собой настоящее удовольствие от создания робота, если все это для вас сделано? Если вы просто оставите там модуль "найти красный шар" и посмотрите, как он идет? Какое чувство гордости вы получите за свое достижение? Лично у меня бы не было много. Кроме того, что он научит вас кодированию или (очень важно) аспекту программного/аппаратного интерфейса, который имеет решающее значение для робототехники?

Я не претендую на то, чтобы быть экспертом в этой области, но задаю себе одно: вы думаете, что NASA использовало LabVIEW для кодирования Mars Rovers? Считаете ли вы, что кто-то по-настоящему выдающийся в робототехнике использует LabView?

В самом деле, если вы спросите меня, единственное, что использует куки-резаки, такие как LabVIEW, чтобы построить это, будет готовить вас к тому, чтобы быть каким-то создателем роботов на заднем дворе и ничего больше. Если вы хотите что-то, что даст вам нечто большее, как опыт в отрасли, создайте собственную систему типа LabVIEW. Создайте свой собственный модуль поиска-шара или ваш собственный "последовательный" модуль. Это будет намного сложнее, но это также будет более здорово.: D

Ответ 11

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

C/С++ означает управление собственной памятью. Вы будете плавать в связях с памятью и беспокоиться о них. Пойдите с LabVIEW и убедитесь, что вы прочитали документацию, поставляемую с LabVIEW, и следите за условиями гонки.

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

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

Ответ 12

Отказ от ответственности: я не был свидетелем LabVIEW, но я использовал несколько других графических языков, включая WebMethods Flow и Modeller, языки динамического моделирования в университете и, er, MIT Scratch:).

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

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

Если ваш робот можно контролировать с помощью языка сценариев (Python, Ruby, Perl, что угодно), то я думаю, что это будет гораздо лучший выбор.

Тогда есть гибридные опции:

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

Если LabVIEW разрешает это, используйте свой графический язык, чтобы объединить модули, написанные на текстовом языке.

Ответ 13

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

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

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

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

Ответ 14

Ты в средней школе. Сколько времени вам нужно для работы над этой программой? Сколько людей в вашей группе? Знают ли они уже С++ или LabView?

Из вашего вопроса, я вижу, что вы знаете С++, а большая часть группы этого не делает. Я также подозреваю, что лидер группы достаточно проницателен, чтобы заметить, что некоторые члены команды могут быть запуганы текстовым языком программирования. Это приемлемо, вы в старшей школе, и эти люди нормы. Я чувствую, что обычные школьники смогут понять LabView более интуитивно, чем С++. Я предполагаю, что большинство учеников средней школы, как и население в целом, боятся командной строки. Для вас есть гораздо меньшая разница, но для них это день и ночь.

Вы правы, что те же концепции могут применяться к LabView как С++. У каждого свои сильные и слабые стороны. Ключ выбирает правильный инструмент для задания. LabView был разработан для такого рода приложений. С++ гораздо более общий и может применяться ко многим другим проблемам.

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

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

Насколько мы должны полагаться на предварительно написанные модули и сколько мы должны пытаться написать самостоятельно? Вы не должны тратить время на создание колеса. Если в Labview есть драйверы устройств, используйте их. Вы можете многому научиться, скопировав код, похожий по функциям, и поместив его в соответствии с вашими потребностями - вы узнаете, как другие люди решали подобные проблемы, и должны интерпретировать их решение, прежде чем сможете правильно применить его к своей проблеме. Если вы вслепую скопируете код, шансы получить его на работу незначительны. Вы должны быть хорошими, даже если вы скопируете код.

Удачи!

Ответ 15

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

Ответ 16

Есть одна огромная вещь, которую я нашел отрицательной при использовании LabVIEW для своих приложений: Организуйте сложность дизайна. Будучи физиологом, я считаю, что Labview отлично подходит для прототипирования, управления прибором и математического анализа. Нет языка, на котором вы получаете быстрее и лучше результат, чем в LabVIEW. Я использовал LabView с 1997 года. С 2005 года я полностью переключился на платформу .NET, так как ее легче проектировать и поддерживать.

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

Теперь я использую текстовые laguages, и я намного лучше поддерживаю все. Если бы вы сравнили С++ с LabVIEW, я бы использовал LabVIEW, но по сравнению с С# он не выигрывал

Ответ 17

Как всегда, это зависит.

Я использую LabVIEW с 20 лет и занимаюсь довольно большим количеством заданий - от простого DAQ до очень сложной визуализации - от устройств управления до тестирования секвенсоров. Если бы это было недостаточно, я бы наверняка переключился. Тем не менее, я начал кодировать Fortran с помощью punchcards и использовал множество языков программирования на 8-битных "машинах", начиная с Z80-based. Языки варьировались от Assembler до BASIC, от Turbo-Pascal до C.

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

Ответ 18

Я ничего не знаю о LabView (или о C/С++), но..

Считаете ли вы, что графические языки, такие как LabVEIW, являются будущим программирования?

Нет...

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

Легче учиться? Нет, но их легче объяснить и понять.

Чтобы объяснить язык программирования, вы должны объяснить, что такое переменная (что удивительно сложно). Это не проблема с инструментами flowgraph/nodal coding, такими как интерфейс программирования LEGO Mindstroms или Quartz Composer..

Например, в этом довольно сложная программа LEGO Mindstroms - это очень легко понять, что происходит... но что если вы хотите, чтобы робот выполнял блок INCREASEJITTER 5 раз, затем двигался вперед в течение 10 секунд, а затем снова повторял цикл INCREASEJITTER? Вещи начинают очень запутываться.

Quartz Composer - отличная иллюстрация этого, и почему я не думаю, что графические языки когда-либо будут "быть будущим"

Это очень легко отличает вещи (эффекты 3D-частиц, с камерой, управляемой средней яркостью пикселей с веб-камеры).. но невероятно сложно делать простые вещи, например, перебирать элементы из XML файла, или сохранить это среднее значение пикселя в файле.

Увидев, что мы в корне укоренены в том, чтобы помогать людям учиться, сколько мы должны полагаться на предварительно написанные модули и сколько мы должны пытаться писать самостоятельно? ( "Хорошие программисты пишут хороший код, отличные программисты копируют отличный код". Но не стоит ли быть хорошим программистом?)

Для обучения гораздо проще объяснить и понять графический язык.

Тем не менее, я бы рекомендовал специализированный текстовый язык на основе текста как прогрессию. Например, для графики что-то вроде Processing или NodeBox. Это "нормальные" языки (обработка Java, NodeBox - это Python) с очень специализированными, простыми в использовании (но абсурдно мощными) структурами, укорененными в них.

Важно, что они очень интерактивные языки, вам не нужно писать сотни строк, чтобы получить круг на экране. Вы просто набираете oval(100, 200, 10, 10) и нажимаете кнопку запуска, и она появляется! Это также позволяет им очень легко продемонстрировать и объяснить.

Больше связанных с робототехникой, даже что-то вроде LOGO было бы хорошим введением - вы набираете "FORWARD 1", а черепаха двигается вперед в одну коробку. Наберите "LEFT 90" и она повернется на 90 градусов. Это относится к реальности очень просто. Вы можете визуализировать, что будет делать каждая инструкция, затем попробовать и подтвердить, что это действительно работает.

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

Ответ 19

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

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

Ответ 20

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

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

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

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

Ответ 21

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

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

Ответ 22

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

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

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

Некоторые языки могут предоставить оба. Недавно я создал многопоточную библиотеку для Lua (Lanes), и ее можно использовать для программирования на основе требований в противном случае. Я знаю, что успешные роботы работают в основном в Lua (Crazy Ivan в Lua Oh Six).

Ответ 23

Вы посмотрели на Microsoft Robotics Studio? http://msdn.microsoft.com/en-us/robotics/default.aspx

Это позволяет визуальное программирование (VPL): http://msdn.microsoft.com/en-us/library/bb483047.aspx а также современные языки, такие как С#. Я призываю вас хотя бы взглянуть на учебники.

Ответ 24

Моя проблема с Labview (и Matlab в этом отношении) заключается в том, что если вы планируете внедрять код в чем-либо, кроме x86 (и Labview имеет инструменты для размещения LabView VI на ARM), тогда вам придется бросать столько же лошадиных сил на проблему как можно, потому что она неэффективна.

Labview - отличный инструмент для создания прототипов: множество библиотек, легко объединяемых блоков, может быть, немного сложно сделать передовые алгоритмы, но, вероятно, блок для того, что вы хотите сделать. Вы можете быстро получить функциональность. Но если вы думаете, что можете принять этот VI и просто надеть его на устройство, вы ошибаетесь. Например, если вы создаете блок сумматора в Labview, у вас есть два входа и один выход. Каково использование памяти для этого? Три значения переменных данных? Два? На C или С++ вы знаете, потому что вы можете написать z=x+y или x+=y, и вы точно знаете, что делает ваш код и какова ситуация с памятью. Использование памяти может быстро скапливаться, особенно потому, что (как указывали другие) Labview является очень параллельным. Поэтому будьте готовы бросить больше оперативной памяти, чем вы думали о проблеме. И больше вычислительной мощности.

Короче говоря, Labview отлично подходит для быстрого прототипирования, но вы теряете слишком много контроля в других ситуациях. Если вы работаете с большими объемами данных или ограниченной памятью/вычислительной мощностью, используйте текстовый язык программирования, чтобы вы могли контролировать, что происходит.

Ответ 25

Люди всегда сравнивают labview с С++ и днем ​​ "oh labview - это высокий уровень, и у него столько встроенных функций, что вы пытаетесь получить данные, выполняющие dfft, и отображаете данные, которые так легко в labview попробовать на С++".

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

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

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

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

"Будущее программирования графическое". (Думайте так?)

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

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

Трудно читать код Labview, потому что там вам нужно посмотреть столько области.

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

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