Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Интересно, насколько нехватка времени была обусловлена сложностью задачи — а насколько уродством языка программирования?
Вот эта картинка:
в идеальном мире должна была бы выглядеть примерно вот так:
Вот эта картинка:
в идеальном мире должна была бы выглядеть примерно вот так:
Интересно, насколько нехватка времени была обусловлена сложностью задачи — а насколько уродством языка программирования?
ваше непонимание чего-либо не является основанием называть это уродством.
Сложность задачи не в вычислении расстояния между двух точек, а в поиске алгоритма поведения системы в заданных условиях.
Найденный алгоритм надо потом еще и закодировать (или нарисовать). Упрощает эту задачу такая IDE как LabView или усложняет?
Лично мне упрощает. Кому-то может усложнять. Это опять же не повод говорить, что раз они иные, то все тупые уроды.
А вот тем, кто писал олимпиаду — усложнила. Видно по скриншотам.
Вы не поверите, я и есть тот, кто писал этот код.
Хотел написать простыню текста с негодованием, но тут пришел AndreyDmitriev и успокоил меня.
Не, в идеальном мире этот код будет выглядеть как-то вот так:
На самом деле вы в какой-то мере правы — в некоторых случаях использование текстовых вставок, особенно в таких вот тривиальных вычислениях будет действительно проще, и LabVIEW это в общем-то не запрещает — это называется «Formula Node». Я б тоже не стал так делать, особенно использовать вложенные case структуры — они прячут часть кода, что в данном случае не есть хорошо. Наличие комментария из тектового кода рядом с графическим тоже наводит на мысль о необходимости небольшого рефакторинга.
А что касается вставок «традиционного кода», ну вот, к примеру из проекта, над которым я сейчас работаю и это у меня на экране:
Ну или пара примеров из учебника:
Результатом этого кода будет вот такой график:
Можно и более зубодробительный пример найти, вот, скажем быстрая сортировка сотни чисел:
Но дело в том, что LabVIEW программист и не будет с этим заморачиваться, он просто сделает вот так:
Вообще «чувство» где использовать тестовые вставки, а где — графические элементы — оно приходит с опытом. Моё мнение таково, что к LabVIEW нельзя подходить, не освоив как минимум один-два текстовых языка (скажем, Паскаль и Си — хорошие кандидаты для этого). Также владение как минимум одним объектно-ориентированным языком будет совсем не лишним (для понимая классов и полиморфизма). Но уродским я б этот язык не стал называть — там всё довольно неплохо продумано. Ну и сравнивать тестовые и графические языки тоже не всегда корректно, такое сравнение порой сродни сравнению апельсинов с помидорами.
На самом деле вы в какой-то мере правы — в некоторых случаях использование текстовых вставок, особенно в таких вот тривиальных вычислениях будет действительно проще, и LabVIEW это в общем-то не запрещает — это называется «Formula Node». Я б тоже не стал так делать, особенно использовать вложенные case структуры — они прячут часть кода, что в данном случае не есть хорошо. Наличие комментария из тектового кода рядом с графическим тоже наводит на мысль о необходимости небольшого рефакторинга.
А что касается вставок «традиционного кода», ну вот, к примеру из проекта, над которым я сейчас работаю и это у меня на экране:
Ну или пара примеров из учебника:
Результатом этого кода будет вот такой график:
Можно и более зубодробительный пример найти, вот, скажем быстрая сортировка сотни чисел:
Но дело в том, что LabVIEW программист и не будет с этим заморачиваться, он просто сделает вот так:
Вообще «чувство» где использовать тестовые вставки, а где — графические элементы — оно приходит с опытом. Моё мнение таково, что к LabVIEW нельзя подходить, не освоив как минимум один-два текстовых языка (скажем, Паскаль и Си — хорошие кандидаты для этого). Также владение как минимум одним объектно-ориентированным языком будет совсем не лишним (для понимая классов и полиморфизма). Но уродским я б этот язык не стал называть — там всё довольно неплохо продумано. Ну и сравнивать тестовые и графические языки тоже не всегда корректно, такое сравнение порой сродни сравнению апельсинов с помидорами.
У меня есть опыт работы с LabView на производстве (лет 5 назад). Программирование и отладка на нём почти не отличается от текстовых языков. Некоторые вещи трудновато делать (например делать хитрые циклы или рекурсии). Однако есть и свои преимущества (в основном интерфейсная SCADA часть). Вобщем — дело привычки и накопленных знаний.
Вообще вся эта тема с визуальным программированием очень болезненна. На обычном текстовом коде это все пишется намного быстрее. Визуальные темы — это хорошо когда например идет ETL (типа MapForce), и то, даже там порой это излищне… чтобы написать A+B нужно сделать блок (+) и подтащить к нему стрелочки… как-то стремно.
На обычном текстовом коде это все пишется намного быстрее.
доказательства такого утверждения можно увидеть?
И часто ли вы пишете программы, делающие только a+b?
Реальные системы, это не только простейшая арифметика над двумя слагаемыми, здесь нужен и интерфейс, и работа с железом, и много всего другого. LabVIEW не претендует на звание универсального суперязыка. на котором нужно писать всем. У этого языка своя ниша. где он занимает лидирующие позиции именно потому, что на нём в разы быстрее и проще создаются конкретные приложения.
Так а можно пример этих конкретных приложений? Потому что в статье как бы контр-пример.
По-моему, это я просил привести доказательства утверждения, почему этот вопрос был переадресован обратно?
В очередной раз предлагаю привести доказательства
БАК достаточно конкретен?
И просьба
В очередной раз предлагаю привести доказательства
БАК достаточно конкретен?
И просьба
По-моему, это я просил привести доказательства утверждения, почему этот вопрос был переадресован обратно?
В очередной раз предлагаю привести доказательства утверждения, на этот раз второго, например, указанием времени, которое будет потрачено на написание такого же приложения на «обычном» языке.
БАК достаточно конкретен? Он создан с использованием PXI (железо) и LabVIEW (софт).
Ещё раз повторяю, статья про решение конкретной задачи, частью которой было использование конкретно этого языка. Выбор задания лежит на авторах олимпиады, а не решавших её.
В очередной раз предлагаю привести доказательства утверждения, на этот раз второго, например, указанием времени, которое будет потрачено на написание такого же приложения на «обычном» языке.
БАК достаточно конкретен? Он создан с использованием PXI (железо) и LabVIEW (софт).
Ещё раз повторяю, статья про решение конкретной задачи, частью которой было использование конкретно этого языка. Выбор задания лежит на авторах олимпиады, а не решавших её.
Ну, из того, что навскидку приходит в голову — в своё время в одной из дискуссий на хабре пользователь ttools поставил вот такую задачку:
Я приведу тот коммент целиком:
Я бы хотел посмотреть, как бы вы красиво выполнили код такой несложной задачи, вполне практической: Имеется 30 датчиков одинакового типа, каждый датчик в реальном времени выдает 4 параметра, допустим float ток и напряжение и два boolean параметра: датчик исправен и датчик включен. Надо отобразить показания всех датчиков на одном экране, допустим 3 ряда по 10 слева направо, сверху вниз, в виде 2 танков (ток, напряжение) и 2х подписей (включен/отключен, исправен/ неисправен) на каждый датчик. Данные от датчиков можно эмулировать любыми функциями от времени и индекса датчика.
На Delphi, например, эту задачу я могу выполнить за полчаса, красивым кодом, с короткими методами. Сколько времени уйдет, чтобы сделать это на LabView и насколько это получится красиво и без лапши?"
Ну вот решение на LabVIEW с нуля за пять минут более-менее красиво и без лапши (при этом я старался не использовать Quick Drop, а проограммировать лишь одной мышкой, чтоб было понятнее что к чему):
Я приведу тот коммент целиком:
Я бы хотел посмотреть, как бы вы красиво выполнили код такой несложной задачи, вполне практической: Имеется 30 датчиков одинакового типа, каждый датчик в реальном времени выдает 4 параметра, допустим float ток и напряжение и два boolean параметра: датчик исправен и датчик включен. Надо отобразить показания всех датчиков на одном экране, допустим 3 ряда по 10 слева направо, сверху вниз, в виде 2 танков (ток, напряжение) и 2х подписей (включен/отключен, исправен/ неисправен) на каждый датчик. Данные от датчиков можно эмулировать любыми функциями от времени и индекса датчика.
На Delphi, например, эту задачу я могу выполнить за полчаса, красивым кодом, с короткими методами. Сколько времени уйдет, чтобы сделать это на LabView и насколько это получится красиво и без лапши?"
Ну вот решение на LabVIEW с нуля за пять минут более-менее красиво и без лапши (при этом я старался не использовать Quick Drop, а проограммировать лишь одной мышкой, чтоб было понятнее что к чему):
Глянул на LabView и платформу PXI. Ну, скажем так, все эти модули — весьма недешево. Но нравится модульность. И конечно пример БАКа впечатляет.
Да, продукты эти действительно недешёвые. Мы как-то сравнивали стоимость сравнимых систем на компонентах Сименс против NI и пришли к выводу, что на Сименс — заметно дешевле (по крайней мере в нашем сегменте промышленной автоматизации). Ну и с сервисом проще. А LabVIEW используем как СКАДА, ну и для обработки изображений.
По коллайдеру вот тут есть немного информации:
CERN Uses NI LabVIEW Software and PXI Hardware to Control World’s Largest Particle Accelerator
Ну и видео:
По коллайдеру вот тут есть немного информации:
CERN Uses NI LabVIEW Software and PXI Hardware to Control World’s Largest Particle Accelerator
Ну и видео:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Олимпиада по программированию в LabVIEW. Решение команды-победительницы