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

Question

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

C (++):

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

* LabVIEW 1015 *

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

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

Также:

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

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

---

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

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

---

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

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

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

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

Удачи!

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

Нет ...

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

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

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

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

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

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

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

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

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

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

Было бы лучше познакомить вас с роботами, даже чем-то вроде LOGO - вы вводите «ВПЕРЕД 1», и черепаха двигается вперед на одну коробку. Набирайте «ВЛЕВО 90», и она поворачивается на 90 градусов. просто. Вы можете визуализировать, что будет делать каждая инструкция, затем опробовать ее и подтвердить, что она действительно работает таким образом.

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

Answer 8

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

Я использую LabVIEW уже около 20 лет и выполнял довольно большие виды работ, от простого DAQ до очень сложной визуализации, от элементов управления устройством до тестовых секвенсоров. Если бы это было недостаточно хорошо, я бы наверняка перешел. Тем не менее, я начал кодировать Fortran с помощью перфокарт и использовал множество языков программирования на 8-битных «машинах», начиная с Z80. Языки варьировались от Ассемблера до Бейсика, от Турбо-Паскаля до С.

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

Answer 9

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

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

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

Answer 10

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

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