Текстовый по сравнению с графическими языками программирования
Вот что я использую, это быстро и охватывает все базы, которые я думаю; работает для всего, кроме IE & lt; 9.
(() => { function fn() {
// "On document ready" commands:
console.log(document.readyState);
};
if (document.readyState != 'loading') {fn()}
else {document.addEventListener('DOMContentLoaded', fn)}
})();
Кажется, что они улавливают все случаи:
- срабатывает немедленно, если DOM уже готов (если DOM не является " загрузка ", но либо" интерактивный ", либо" полный ")
- , если DOM по-прежнему загружается, он устанавливает прослушиватель событий, когда DOM доступен (интерактивный).
Событие DOMContentLoaded доступно в IE9 и во всем остальном, поэтому я лично считаю, что это нормально использовать. Перепишите объявление функции стрелки в обычную анонимную функцию, если вы не переставляете свой код с ES2015 на ES5.
Если вы хотите дождаться загрузки всех ресурсов, все изображения отображаются и т. Д., То используйте window.onload вместо этого.
24 ответа
Прежде чем я прибыл, наша группа (ученые доктора философии, с небольшим фоном программирования) пыталась реализовать приложение LabVIEW, периодичное в течение почти года. Код был неопрятен, слишком сложен (передняя сторона и бэкенд) и самое главное, не работал. Я - увлеченный программист, но никогда не использовал LabVIEW. С небольшой справкой от гуру LabVIEW, который мог помочь перевести текстовые progamming парадигмы, я знал в понятия LabVIEW, что было возможно кодировать приложение за неделю. Точка здесь - то, что понятия программирования в абсолютных адресах все еще должны быть изучены, язык, даже один как LabVIEW, является просто различным способом выразить их .
LabVIEW является большим использовать для того, для чего он был первоначально разработан. т.е. взять данные из карт DAQ и отобразить его на экране, возможно, с некоторым незначительным промежутком манипуляций. Однако алгоритмы программирования не легче, и я даже предположил бы, что это более трудно. Например, в большей части порядка выполнения процедурных языков обычно сопровождается линию за линией, с помощью псевдо математической нотации (т.е. y = x*x + x + 1), тогда как LabVIEW реализовал бы это использование серии VI's, которые не обязательно следуют друг из друга (т.е. слева направо) на холсте.
, Кроме того, программирование, поскольку карьера больше, чем знает технические особенности кодирования. Способность эффективно попросить ответы справки/поиска, запишите читаемый код и работайте с унаследованным кодом, все ключевые навыки, которые являются бесспорно более трудными на графическом языке, таком как LabVIEW.
я полагаю, что некоторые аспекты графического программирования могут стать господствующей тенденцией - использование под-Виса отлично воплощает принципал 'черного ящика' программирования и также используется в других абстракциях языка такой как Каналы Yahoo и Apple Automator - и возможно некоторый будущий графический язык коренным образом изменит способ, которым мы программируем, но сам LabVIEW не является крупной парадигмой, переключают дизайн языка на нижний регистр, мы все еще имеем while, for, if управление потоком, преобразование типа, событийно-управляемое программирование, даже возражает. Если будущее действительно будет записано в LabVIEW, программист на C++ не испытает много пересечения затруднений.
Как постскриптум я сказал бы, что C/C++ больше подходит для робототехники, так как студенты должны будут несомненно иметь дело со встроенными системами и FPGAs в какой-то момент. Знание низкоуровневого программирования (биты, регистры и т.д.) было бы неоценимо для такого рода вещи.
@mendicant На самом деле LabVIEW используется много в промышленности, специально для систем управления. Предоставленное НАСА вряд ли использует его для встроенных спутниковых систем, но тогда разработка программного обеспечения для систем пространства целая различная игра с мячом ...
Вы взглянули на Microsoft Robotics Studio? http://msdn.microsoft.com/en-us/robotics/default.aspx
Это допускает визуальное программирование (VPL): http://msdn.microsoft.com/en-us/library/bb483047.aspx , а также современные языки, такие как C#. Я поощряю Вас, по крайней мере, смотреть на учебные руководства.
капитан команды думает, что LabVIEW лучше для своей простоты изучения и обучения. Это верно?
я сомневаюсь, что это было бы верно для любого единственного языка или парадигмы. LabView мог, конечно, быть легче для людей с инженерным образованием электроники; создание программ в нем "просто" тянет провода. С другой стороны такие люди могли бы уже быть представлены программированию, также.
Одно существенное различие - кроме от диаграммы - то, что LV основан на спросе (поток) программирование. Вы запускаете с результата и говорите, что необходимо для получения до него. Традиционное программирование имеет тенденцию быть обязательным (движение наоборот).
Некоторые языки могут обеспечить оба. Я обработал библиотеку многопоточности для Lua недавно (Маршруты), и он может использоваться для основанного на спросе программирования в в других отношениях обязательной среде. Я знаю, что существуют успешные роботы, выполненные главным образом в Lua там ( Сумасшедший Ivan в Lua, О, Шесть).
Существуют определенно достоинства к обоим вариантам; однако, так как Ваш домен является образовательным опытом, я думаю, что решение для C/C++ больше всего принесло бы пользу студентам. Графическое программирование всегда будет опцией, но просто не обеспечивает функциональность изящным способом, который сделал бы более эффективным использовать, чем текстовое программирование для низкоуровневого программирования. Это не плохая вещь - смысл абстракции должен позволить новое понимание и представление проблемной области. Причина я верю многим, может быть разочарована графическим программированием, хотя то, что для какой-то конкретной программы возрастающее усиление в движении от программирования в C к графическому является совсем не тем же как идущий от блока до C.
Знание графического программирования принесло бы пользу любому будущему программисту наверняка. Вероятно, будут возможности в будущем, которые только требуют знания графического программирования, и возможно некоторые Ваши студенты могли извлечь выгоду из некоторого раннего опыта с ним. С другой стороны, прочная основа в фундаментальных концепциях программирования, предоставленных текстовым подходом, извлечет выгоду весь из Ваших студентов и конечно должна быть лучшим ответом.
Я запустил с LabVIEW приблизительно 2 года назад, и теперь используйте все это, время так может быть смещено, но найти его идеальным для приложений, где сбор данных и управление включены.
Мы используем LabVIEW главным образом для тестирования, где мы проводим непрерывные измерения и управляем газовыми клапанами и корпусами ATE. Это включает и цифровой и аналоговый вход и выводы со стандартными программами анализа сигнала и управлением процессом все выполнение от GUI. Путем разрушения каждой части в subVIs мы в состоянии реконфигурировать тесты с перетаскиванием мыши.
Не точно то же как C/C++, но подобная реализация измерения, управления и анализа с помощью Visual Basic кажется сложным и твердым поддержать по сравнению.
я думаю, что процесс программирования более важен, чем фактический язык программирования, и необходимо следовать инструкциям по стилю для графического языка программирования. Блок-схемы LabVIEW показывают поток данных ( программирование Потока данных), таким образом, должно быть легко видеть потенциальные условия состязания, хотя у меня никогда не было проблем. Если у Вас будет кодовая база C, тогда встраивающая его в dll, то позволит LabVIEW называть его непосредственно.
Кажется этим, при попытке подготовить нашу команду к будущему в программировании этого C (++) мама быть лучшим маршрутом. Обещание общих языков программирования, которые создаются с визуальными стандартными блоками, никогда казалось, не осуществилось, и я начинаю задаваться вопросом, будут ли они когда-нибудь. Кажется что, в то время как это может быть сделано для определенных проблемных областей, как только Вы входите в попытку решить много общих проблем, которые основанный на тексте язык программирования тверд разбить.
Когда-то у меня был вид вложившихся в идею исполняемого UML, но кажется что, как только Вы заканчиваете объектные отношения и некоторые технологические маршруты, UML был бы довольно скудным способом создать приложение. Предположите пытаться соединить все это проводом до GUI. Я не возражал бы доказываться неправым, но до сих пор кажется маловероятным, что мы будем точкой и щелчком, программирующим в ближайшее время.
Я ничего не делаю о LabView (или очень о C/C++), но..
Вы думаете, что графические языки, такие как LabVEIW являются будущим программирования?
№
графический язык легче выучить, чем текстовый язык? Я думаю, что они должны быть о равном бросании вызов для изучения.
Легче учиться? Нет, но они легче объяснить и понять.
Для объяснения языка программирования необходимо объяснить, что переменная (который является удивительно трудным). Это не проблема с инструментами кодирования потокового графа / узловыми инструментами кодирования, как LEGO Mindstroms интерфейс программирования или Кварцевый Компоновщик..
, Например, в этом довольно сложный LEGO Mindstroms программа - очень легко понять то, что входит..., но, что, если Вы хотите, чтобы робот работал INCREASEJITTER блок 5 раз, тогда управляйте вперед в течение 10 секунд, затем попробуйте цикл INCREASEJITTER снова? Вещи начинают становиться грязными очень быстро..
Кварцевый Компоновщик является большим экс-кленом этого, и почему я не думаю, что графические языки когда-либо "будут будущим",
Это делает его очень легким к действительно интересному материалу (3D эффекты частицы с камерой управляемый средней яркостью пикселей от веб-камеры).. но невероятно трудный сделать легкие вещи, как выполняют итерации по элементам от XML-файла или хранилищу что среднее пиксельное значение в файл.
Наблюдение, поскольку мы частично базированы в помощи людям учиться, насколько мы должны полагаться на предзаписанные модули, и сколько мы должны попытаться записать самостоятельно? ("Хорошие программисты пишут хороший код, великие программисты копируют большой код". Но разве не стоит хорошим программистом, сначала?)
Для изучения, настолько легче и объяснить и понять графический язык..
Однако я рекомендовал бы специализированный основанный на тексте язык языка как прогрессию. Например, для графики что-то как Обработка или NodeBox. Они - "нормальные" языки (Обработка является Java, NodeBox является Python) с очень специализированным, простым в использовании (но нелепо мощный) платформы, внушенные в них..
Значительно, они - очень интерактивные языки, Вы не должны писать сотни строк только для получения круга на экране.. Вы просто тип oval(100, 200, 10, 10) и нажатие кнопка запуска, и это появляется! Это также делает их очень легкими продемонстрировать и объяснить.
Более связанный с робототехникой, даже что-то как ЛОГОТИП было бы хорошим введением - Вы вводите "ВПЕРЕД 1", и диски черепахи передают одно поле.. Введите "ОСТАВЛЕННЫЙ 90", и это поворачивает 90 градусов.. Это касается действительности очень просто. Можно визуализировать то, что каждая инструкция сделает, затем испытает его и подтвердит, что это действительно прокладывает себе путь.
Показывают им солнечное выглядящие вещи, они будут погрузка полезный материал, который они узнали бы из C по пути, если они будут интересно или будут прогрессировать до точки, где им нужен "реальный" язык, они будут иметь все это знание, а не столкнутся с синтаксической ошибкой и кирпичной стеной компиляции..
Как всегда, это зависит.
я использую LabVIEW приблизительно с 20 лет теперь и сделал вполне большой вид заданий, от простого DAQ до очень сложной визуализации, от управления устройствами для тестирования секвенсеров. Если бы это не было достаточно хорошо, я наверняка переключился бы. Однако я начал кодировать Фортран с перфокартами и использовал много языков программирования на 8-разрядных 'машинах', начиная с основанных на Z80. Языки колебались от Ассемблера до ОСНОВНОГО от Turbo Pascal до C.
LabVIEW был основным улучшением из-за своих обширных библиотек для данных acqusition и анализа. Нужно, однако, изучить различный paradigma. И Вам определенно нужен шаровой манипулятор;-))
Существует одна огромная вещь, которую я нашел отрицательным в использовании LabVIEW для моих приложений: Организуйте сложность дизайна. Как физик я нахожу Labview большим для разработки прототипа, инструментального управления и математического анализа. Нет никакого языка, на котором Вы становитесь быстрее и лучше результат тогда в LabVIEW. Я использовал LabView с 1997. С 2005 я переключился полностью на платформу.NET, так как легче разработать и поддержать.
В LabVIEW простое, 'если' структура должна быть оттянута и использует много пространства на Вашем графическом дизайне. Я просто узнал, что многое из нашего коммерческого применения было трудно поддержать. Чем более сложным приложение стало, тем более трудно было читать.
я теперь использую текст laguages, и я намного лучше в поддержании всего. Если бы Вы сравнили бы C++ с LabVIEW, я использовал бы LabVIEW, но по сравнению с C# это не побеждает
Я предложил бы, чтобы Вы использовали LabVIEW, поскольку можно перейти к созданию робота, что Вы хотите сделать быстрее и легче. LabVIEW был разработан с этим умом. Конечно, C (++) большие языки, но LabVIEW делает то, что он, как предполагается, добивается большего успеха, чем что-либо еще. Люди могут записать действительно хорошее программное обеспечение в LabVIEW, поскольку это обеспечивает вполне достаточный объем и поддержку этого.
Вы находитесь в Средней школе. Сколько времени необходимо работать над этой программой? Сколько людей находится в Вашей группе? Они уже знают C++ или LabView?
От Вашего вопроса, я вижу, что Вы знаете C++, и большая часть группы не делает. Я также подозреваю, что лидер группы достаточно проницателен, чтобы заметить, что некоторые члены команды могут быть запуганы основанным на тексте языком программирования. Это приемлемо, Вы находитесь в средней школе, и эти люди normies. Я чувствую, как будто нормальные высокие школьники будут в состоянии понять LabView более интуитивно, чем C++. Я предполагаю, что большинство учеников средней школы, как население в целом, боится командной строки. Для Вас существует намного меньше различия, но для них, это - ночь и день.
Вы корректны, что к тем же понятиям можно относиться LabView как C++. У каждого есть его достоинства и недостатки. Ключ выбирает правильный инструмент для задания. LabView был разработан для этого вида приложения . C++ намного более универсален и может быть применен ко многим другим видам проблем.
я собираюсь рекомендовать LabView. Учитывая правильные аппаратные средства, можно быть в порядке почти out-of-the-box. Ваша команда может провести больше времени получение робота сделать то, что Вы хотите , который является, каков фокус этого действия должен быть.
Графические Языки не являются будущим программирования; они были одним из доступного выбора, созданного для решения определенных типов проблем, много лет. Будущее программирования является слоем на слой абстракции далеко от машинного кода. В будущем мы будем задаваться вопросом, почему мы потратили впустую все это время программирование "семантика" много раз.
, насколько мы должны полагаться на предзаписанные модули, и сколько мы должны попытаться записать самостоятельно? Вы не должны напрасно тратить время, перестраивая колесо. Если существуют драйверы устройств, доступные в Labview, используйте их. Можно изучить много путем копирования кода, который подобен в функции и адаптации его к потребностям - Вы добираетесь, чтобы видеть, как другие люди решили подобные проблемы и должны интерпретировать их решение, прежде чем можно будет правильно применить его к проблеме. При слепом копировании кода, возможностей получения, это для работы тонко. Необходимо быть хорошими даже при копировании кода.
Всего наилучшего
Я люблю LabVIEW. Я настоятельно рекомендовал бы его особенно, если другой помнит, использовали что-то подобное. Это требует времени для нормальных программистов для привыкания к нему, но результат намного лучше, если Вы уже знаете, как программировать.
C/C++ равняется, управляют Вашей собственной памятью. Вы будете плавать в ссылках памяти и волноваться о них. Пойдите с LabVIEW и удостоверьтесь, что Вы читаете документацию, которая идет с LabVIEW, и не упустите условия состязания.
Изучение языка легко. Изучение, как программировать, не. Это не изменяется, даже если это - графический язык. Преимущество Графических языков состоит в том, что легче к визуальному, что код будет делать, а не находиться там и дешифровать набор текста.
важной вещью не является язык, но концепции программирования. Не должно иметь значения, в каком языке Вы учитесь программировать, потому что с небольшим усилием необходимо быть в состоянии программировать хорошо на любом языке. Языки приходят и уходят.
Я думаю, что графические языки могли бы быть языком будущего..... для всех тех специальных разработчиков Доступа MS там. Всегда будет место для чисто текстовых кодеров.
Лично, я должен спросить, что реальной является забава создать робот, если она все сделана для Вас? Если Вы просто отбрасываете, 'находят красный шар' модулем там и часами, это идет? Какое чувство гордости Вы будете иметь для своего выполнения? Лично, у меня не было бы многого. Плюс, что это будет преподавать Вам кодирования, или (очень важного) аспекта программного обеспечения/аппаратного интерфейса, которое очень важно в робототехнике?
я не утверждаю, что был экспертом в поле, но спросил себя одна вещь: Вы думаете, что НАСА использовало LabVIEW для кодирования Роверов Марса? Вы думаете, что кто-либо действительно видный в робототехнике использует LabView?
Действительно, если Вы спрашиваете меня, единственное дело с помощью вещей резака cookie как LabVIEW для создания этого идет подготовиться, для необходимо быть некоторым разработчиком робота заднего двора и ничем больше. Если Вы хотите что-то, что даст Вам что-то больше как промышленный опыт, создать Вашу собственную ''-систему-типов LabVIEW. Создайте свой собственный модуль находить-шара или Ваш собственный модуль 'следовать-строки'. Это будет намного более трудно, но это также будет путь, более прохладный также.: D
О, мой Бог, ответ так прост. Используйте LabView.
я программировал встроенные системы в течение 10 лет, и я могу сказать это, по крайней мере, без пары месяцев инфраструктуры (очень осторожная инфраструктура!), Вы не будете так же продуктивны, как Вы находитесь в день 1 с LabView.
при разработке робота, который будет продаваться и использоваться для вооруженных сил, идите вперед и запуститесь с C - это - хороший вызов.
Иначе, используйте систему, которая позволяет Вам испытывать большую часть разнообразия за самое короткое количество времени. Это LabView.
LabVIEW позволяет Вам начать быстро, и (как другие уже сказали), имеет крупную библиотеку кода для того, чтобы сделать различный тест, измерение & связанные с управлением вещи.
единственное самое большое крушение LabVIEW, тем не менее, состоит в том, что Вы теряете все инструменты, которые программисты пишут для себя.
Ваш код хранится как ВИС. Это непрозрачные, двоичные файлы. Это означает, что Ваш код действительно не является Вашим, это - LabVIEW. Вы не можете записать свой собственный синтаксический анализатор, Вы не можете записать генератор кода, Вы не можете сделать автоматизированных изменений через макросы или сценарии.
Это сосет , когда Вы имеете 5000 VI приложений, для которых нужна некоторая незначительная тонкая настройка, примененная универсально. Ваш [только 119] опция состоит в том, чтобы пройти каждый VI вручную, и небеса помогают Вам при пропавших без вести изменения в одном VI прочь в углу где-нибудь.
И да, так как это является двоичным, Вы не можете сделать, разность/слияние/патч как Вы может с текстовыми языками. Это действительно делает работу больше чем с одной версией кода ужасающим кошмаром пригодности для обслуживания.
Любой ценой, используйте LabVIEW, если Вы делаете что-то простое, или должны моделировать или не планируете поддержать свой код.
, Если Вы хотите сделать реальное, удобное в сопровождении программирование, используйте текстовый язык. Вы могли бы медленнее начинать, но Вы будете быстрее в конечном счете.
(О, и если Вам нужны библиотеки DAQ, NI получила C++ и.Net версии тех, также.)
Я думаю что графические языки wil всегда быть ограниченным в expressivity по сравнению с текстовыми. Сравните попытку связаться в визуальных символах (например, РЕБУС или язык жестов) к передаче слов использования.
Для простых задач, с помощью графического языка обычно легче, но для большего количества сложной логики, я нахожу, что мешают графические языки.
Другие дебаты, подразумеваемые в этом аргументе, тем не менее, являются декларативным программированием по сравнению с императивом. Описание обычно лучше для чего-либо, где Вам действительно не нужно мелкомодульное управление тем, как что-то сделано. Вы можете C++ использования декларативным способом, но Вам было бы нужно больше работы впереди для создания его так, тогда как LABView разработан как декларативный язык.
изображение А стоит тысячу слов, но если изображение представляет тысячу слов, в которых Вы не нуждаетесь, и Вы не можете изменить это, тогда в этом случае изображение бесполезно. Принимая во внимание, что, можно создать тысячи изображений с помощью слов, определив каждую деталь и даже ведя фокус средства просмотра явно.
Существует опубликованное исследование темы, размещенной Национальными Инструментами:
Исследование А Графических по сравнению с Текстовым Программированием для Обучающего DSP
Это конкретно смотрит на LabVIEW по сравнению с MATLAB (в противоположность C).
Другая сила LabVIEW (помимо библиотек) параллелизм . Это язык потока данных , что означает, что время выполнения может обработать параллелизм для Вас. Таким образом, если Вы делаете что-то очень параллельное и не хотите должными быть делать традиционную синхронизацию, LabVIEW может помочь Вам там.
будущее не принадлежит графическим языкам, поскольку они стоят сегодня. Это принадлежит тому, кто бы ни может придумать представление потока данных (или другой благоприятный для параллелизма тип программирования), это так просто, как графический подход, но также parsable собственными инструментами программиста.
Это не отвечает Вам вопрос непосредственно, но можно хотеть рассмотреть третью опцию смешивания на интерпретируемом языке. Lua, например, уже , использовал в поле робототехники. Это быстро, легко и может быть настроено для выполнения с числами фиксированной точки вместо с плавающей точкой, так как большинство микроконтроллеров не имеет FPU. Forth является другой альтернативой с подобным использованием.
должно быть довольно легко записать тонкий интерфейсный слой в C и затем выпустить студентов с интерпретируемыми сценариями. Вы могли даже настроить его, чтобы позволить коду быть загруженным динамично, не перекомпилировав и высвечивая микросхему. Это должно уменьшить итеративный цикл и позволить студентам учиться лучше путем наблюдения результатов более быстро.
я смещаюсь против использующие визуальные инструменты как LabVIEW. Я всегда, кажется, поражаю что-то, что не делает или не будет работать вполне как, я хочу, чтобы он сделал. Так, я предпочитаю неограниченный контроль, который Вы получаете с текстовым кодом.
Я думаю выбор LabVIEW, или не сводится, хотите ли Вы учиться программировать на наиболее часто используемом языке как рыночный навык, или просто хотеть получить сделанный материал. LabVIEW позволяет Вам Получить Материал, Сделанный очень быстро и продуктивно. Как другие заметили, это волшебно не освобождает Вас от необходимости понять то, что Вы делаете, и довольно возможно создать безобразную путаницу, если Вы не делаете - хотя анекдотическим образом, худшие примеры плохого стиля кодирования в LabVIEW обычно совершаются людьми, которые испытаны на текстовом языке и отказываются адаптироваться к тому, как LabVIEW работает, потому что они 'уже знают, как программировать, черт возьми!'
Это не должно подразумевать, что программирование LabVIEW не является рыночным навыком, конечно; просто то, что это не как массовый рынок как C++.
LabVIEW делает чрезвычайно легким управлять разными вещами, продолжающимися параллельно, который Вы можете иметь в ситуации с управлением роботом. Условия состязания в коде, который должен быть последовательным, не должны быть проблемой ни один (т.е. если они, Вы делаете его неправильно): существуют простые методы для проверки, что материал происходит в правильном порядке в случае необходимости - объединение в цепочку использования subVI ошибочного провода или других данных, с помощью notifiers или очередей, создавая структуру конечного автомата, даже с помощью структуры последовательности LabVIEW при необходимости. Снова, это - просто случай занимания время для понимания инструментов, доступных в LabVIEW и как они работают. Я не думаю, что жалоба на необходимость сделать subVI значки очень хорошо направлена; можно очень быстро создать тот, содержащий несколько слов текста, возможно, с цветом фона, и это будет хорошо для большинства целей.
'Графические языки, способом будущего' является отвлекающий маневр на основе ложной дихотомии. Некоторые вещи хорошо подходят для графических языков (параллельный код, например); другие вещи удовлетворяют текстовым языкам намного лучше. Я не ожидаю, что LabVIEW и графическое программирование или уйдут, или примут мир.
Кстати, я был бы очень удивлен, не сделало ли НАСА использование LabVIEW в космонавтике. Кто-то недавно описал в Информационном-LabVIEW списке рассылки, как они использовали LabVIEW, чтобы разработать и протестировать управление замкнутым циклом поверхностей полета, приводимых в действие электродвигателями на Boeing 787, и произвели впечатление, что LabVIEW использовался экстенсивно в разработке плоскости. Это также используется для управления в режиме реального времени в Большой Коллайдер Адрона!
самое активное место в настоящее время для того, чтобы получить дополнительную информацию и справку с LabVIEW, кроме собственного сайта и форумов Национальных Инструментов, кажется, ЛАВА .
Я встретился с несколько аналогичной ситуацией в исследовательской группе, в которой я в настоящее время работаю. Это - группа биофизики, и мы используем LabVIEW повсеместно для управления нашими инструментами. Это абсолютно работает отлично: легко собрать UI, чтобы управлять всеми аспектами Ваших инструментов, просмотреть его состояние и сохранить Ваши данные.
И теперь я должен мешать мне писать напыщенную речь на 5 страниц, потому что для меня LabVIEW был кошмаром. Позвольте мне вместо этого попытаться суммировать некоторые за и против:
Правовая оговорка я не эксперт LabVIEW, я мог бы сказать вещи, которые смещаются, устаревшие или просто неправильно:)
профессионалы LabVIEW
- Да, легко учиться . Многие PhD в нашей группе, кажется, получили достаточно навыков для взламывания далеко в течение нескольких недель, или еще меньше.
- Библиотеки . Это - важный пункт. Необходимо было бы тщательно привлечь это по делу о собственной ситуации (я не знаю то, в чем Вы нуждаетесь, если существуют хорошие библиотеки LabVIEW для нее, или если существуют альтернативы на других языках). В моем случае, открытии, например, хорошая, быстрая библиотека построения диаграммы в Python была основной проблемой, которая препятствовала тому, чтобы я переписал некоторые наши программы в Python.
- Вашей школе можно было уже установить его и выполнение.
недостатки LabVIEW
- , возможно также легко учиться. В любом случае кажется, что никто действительно не потрудился изучать лучшие практики, таким образом, программы быстро становятся полной, непоправимой путаницей. Несомненно, это также обязано произойти с основанными на тексте языками, если Вы не осторожны, но IMO, намного более трудно сделать вещи правильно в LabVIEW.
- имеют тенденцию быть главные проблемы в LabVIEW с нахождением под-Виса (сгладьте к версии 8.2, я думаю). LabVIEW поступает по-своему знания, где найти библиотеки и под-Вис, который делает очень легким полностью повредить Ваше программное обеспечение. Это делает крупные проекты болью, если у Вас нет кого-то вокруг, кто знает, как обработать это.
- Получение LabVIEW работать с управлением версиями является болью . Несомненно, это может быть сделано, но в любом случае я воздержался бы от использования встроенного VC. Выезд LVDiff для инструмента разности LabVIEW, но даже не думают о слиянии.
(Последние две точки делают работу в команде на одном проекте трудной. Это, вероятно, важно в Вашем случае)
- , Это является персональным, но я нахожу, что много алгоритмов просто не работают, когда запрограммировано визуально. Это - путаница .
- Одним примером является материал, который строго последователен; это становится громоздким довольно быстро.
- трудно иметь обзор кода.
- при использовании Sub-VI для маленьких задач (точно так же, как это - хорошая практика для создания функций, которые выполняют маленькую задачу, и что соответствие на одном экране), Вы не можете только дать им имена, но необходимо потянуть значки для каждого из них. Это становится очень раздражающим и громоздким в течение только нескольких минут, таким образом, Вы становитесь очень соблазненными не для помещения материала в sub-VI. Это - просто слишком много стычки. Btw: создание действительно хорошего значка может занять профессиональные часы. Пойдите попытка сделать уникальный, сразу понятный, распознаваемый значок для каждого sub-VI, который Вы пишете:)
- у Вас будет кистевой туннель в течение недели. Гарантируемый.
- @Brendan: услышьте, услышьте!
Заключительные замечания
Что касается Ваш "должны я писать свои собственные модули" вопрос: я не уверен. Зависит от Ваших ограничений времени. Не проводите время при перестраивании колеса, если Вы не имеете к. Слишком легко провести дни на запись, что низкий уровень кодирует и затем понимает, что у Вас закончилось время. Если это означает выбор LabVIEW пойдите для него.
, Если были бы простые способы объединить LabVIEW и, например, C++, я хотел бы услышать об этом: это может дать Вам лучший из обоих миров, но я сомневаюсь, что существует.
, Но удостоверяются, что Вы и Ваша команда проводите время при изучении лучших практик. Рассмотрение кода друг друга. Изучение друг от друга. Запись применимого, понятного кода. И весело проведение время!
И простите мне за звучание острым и возможно несколько педантичным. Это просто, что LabVIEW был реален кошмар для меня:)
Правовая оговорка: я не засвидетельствовал LabVIEW, но я использовал несколько других графических языков включая Поток WebMethods и Средство моделирования, динамических языков моделирования в университете и, er, Царапина MIT:).
Мой опыт состоит в том, что графические языки могут сделать хорошее задание части 'инфраструктуры' программирования, но те, которых я использовал активно, мешают алгоритмированию. Если Ваши алгоритмы очень просты, который мог бы быть в порядке.
, С другой стороны, я не думаю, что C++ является большим для Вашей ситуации также. Вы проведете больше времени, разыскивая указатель и проблемы управления памятью, чем Вы делаете в полезной работе.
, Если Вашим роботом можно управлять с помощью языка сценариев (Python, Ruby, Perl, безотносительно), то я думаю, что это было бы намного лучшим выбором.
Тогда существуют гибридные опции:
, Если нет никакой опции сценариев для Вашего робота, и Вы имеете фаната C++ в своей команде, затем полагаете, что наличие что привязка записи фаната отображает Вашу библиотеку C++ на язык сценариев. Это позволило бы людям с другими специальностями программировать робот более легко. Привязка сделала бы хороший подарок сообществу.
, Если LabVIEW позволяет его, используйте его графический язык для инфраструктуры вместе модулей, записанных на текстовом языке.
Моя претензия к Labview (и Matlab в этом отношении) заключается в том, что если вы планируете встраивать код не в x86 (а у Labview есть инструменты для установки виртуальных приборов Labview на ARM), то вам Придется приложить максимум усилий для решения проблемы, потому что это неэффективно.
Labview - отличный инструмент для создания прототипов: множество библиотек, легко объединить блоки, может быть, немного сложно реализовать сложные алгоритмы, но, вероятно, есть блок для того, что вы хотите сделать. Вы можете быстро выполнить функциональность. Но если вы думаете, что можете взять этот ВП и просто поместить его на устройство, то ошибаетесь. Например, если вы создаете блок сумматора в Labview, у вас будет два входа и один выход. Какое использование памяти для этого? Ценность данных трех переменных? Два? Вы знаете, что в C или C ++ потому что вы можете написать z = x + y или x + = y , и вы точно знаете, что делает ваш код и какова ситуация с памятью. Использование памяти может быстро возрасти, особенно потому, что (как указывали другие) Labview очень параллельна. Так что будьте готовы выбросить на проблему больше оперативной памяти, чем вы думали. И больше вычислительной мощности.
Короче говоря, Labview отлично подходит для быстрого прототипирования, но вы теряете слишком много контроля в других ситуациях. Если вы работаете с большими объемами данных или с ограниченной памятью / вычислительной мощностью, используйте текстовый язык программирования, чтобы вы могли контролировать происходящее.
Так что будьте готовы выбросить на проблему больше оперативной памяти, чем вы думали. И больше вычислительной мощности.Короче говоря, Labview отлично подходит для быстрого прототипирования, но вы теряете слишком много контроля в других ситуациях. Если вы работаете с большими объемами данных или с ограниченной памятью / вычислительной мощностью, используйте текстовый язык программирования, чтобы вы могли контролировать происходящее.
Так что будьте готовы выбросить на проблему больше оперативной памяти, чем вы думали. И больше вычислительной мощности.Короче говоря, Labview отлично подходит для быстрого прототипирования, но вы теряете слишком много контроля в других ситуациях. Если вы работаете с большими объемами данных или с ограниченной памятью / вычислительной мощностью, используйте текстовый язык программирования, чтобы вы могли контролировать происходящее.
Мой первый пост :) Будьте осторожны ...
Я имею опыт работы в автомобильной промышленности, а теперь я работаю в оборонной промышленности. Я могу сказать вам по опыту, что C / C ++ и LabVIEW - действительно разные звери, преследующие разные цели. C / C ++ всегда использовался для встроенной работы с микроконтроллерами, потому что он был компактным, а компиляторы / инструменты были легко доступны. LabVIEW, с другой стороны, использовался для управления тестовой системой (вместе с тестовым стендом в качестве секвенсора). Большая часть используемого нами тестового оборудования была от NI, поэтому LabVIEW предоставил среду, в которой у нас были инструменты и драйверы, необходимые для работы, а также необходимая поддержка.
С точки зрения простоты обучения, существует множество ресурсов по C / C ++ и множество веб-сайтов, на которых излагаются соображения дизайна и примеры алгоритмов практически для всего, что вам нужно, в свободном доступе. Что касается LabVIEW, сообщество пользователей, вероятно, не так разнообразно, как C / C ++, и требуется немного больше усилий, чтобы проверить и сравнить пример кода (необходимо иметь правильную версию LabVIEW и т. Д.) ... Я обнаружил, что LabVIEW довольно легко выбрать вверх и учиться, но есть неприятности, о которых здесь упоминали некоторые, связанные с параллелизмом и различными другими вещами, которые требуют небольшого опыта, прежде чем вы узнаете о них.
Так какой вывод после всего этого? Я бы сказал, что изучать стоит ОБЕИХ языков, потому что они действительно представляют два разных стиля программирования, и, безусловно, стоит знать и владеть обоими.
и требуется немного больше усилий, чтобы проверить и сравнить пример кода (должна быть правильная версия LabVIEW и т. д.) ... Я обнаружил, что LabVIEW довольно легко подобрать и изучить, но есть неприятности, как некоторые упоминали здесь, чтобы сделать с параллелизмом и другими вещами, которые требуют некоторого опыта, прежде чем вы их осознаете.Итак, какой вывод после всего этого? Я бы сказал, что изучать стоит ОБЕИХ языков, потому что они действительно представляют два разных стиля программирования, и, безусловно, стоит знать и владеть обоими.
и требуется немного больше усилий, чтобы проверить и сравнить пример кода (должна быть правильная версия LabVIEW и т. д.) ... Я обнаружил, что LabVIEW довольно легко подобрать и изучить, но есть неприятности, о которых здесь упоминали некоторые с параллелизмом и другими вещами, которые требуют некоторого опыта, прежде чем вы их осознаете.Итак, какой вывод после всего этого? Я бы сказал, что изучать стоит ОБЕИХ языков, потому что они действительно представляют два разных стиля программирования, и, безусловно, стоит знать и владеть обоими.
но есть неудобства, о которых здесь упоминали некоторые, связанные с параллелизмом и различными другими вещами, которые требуют некоторого опыта, прежде чем вы их заметите.Итак, какой вывод после всего этого? Я бы сказал, что изучать стоит ОБЕИХ языков, потому что они действительно представляют два разных стиля программирования, и, безусловно, стоит знать и владеть обоими.
но есть неудобства, о которых здесь упоминали некоторые, связанные с параллелизмом и различными другими вещами, которые требуют некоторого опыта, прежде чем вы их заметите.Так какой вывод после всего этого? Я бы сказал, что изучать стоит ОБЕИХ языков, потому что они действительно представляют два разных стиля программирования, и, безусловно, стоит знать и владеть обоими.