Комментарии 163
Все равно все это выглядит красиво и приятно глазу, хоть уже практически и не используется. Такая своя красота логики, конструкций, когда читаешь такой код накатывает чувство ностальгии и сразу перед глазами старый монохромный монитор… эх…
P.S. Я не старый, мне 25 от роду, но все равно фанатею от старых языков.
P.S. Я не старый, мне 25 от роду, но все равно фанатею от старых языков.
15 лет писал в основном на С++, а тут вдруг понадобилось написать кое-что для линукса на чистом Си. Интересные впечатления… программирование С++ всегда вызывает беспокойство — потому что всегда не до конца понимаешь все эти шаблонные навороты, потому что С++ сочетает огромную мощь и некоторую «недоделанность», когда понимаешь что для вроде бы простой и очевидной вещи нужно подключать всякий Boost и писать кучу совершенно не относящегося к задаче кода.
Программирование же на чистом Си вызывает умиротворенность:) Все навороты С++ просто отсутствуют. Все что можно сделать — можно сделать единственным образом. Возможно, что это следствие того что для Си другие задачи, и если бы я применял Си для тех задач для которых я применяю обычно С++, то проблем было бы еще больше (на самом деле так оно и есть).
И еще. Удивительный по красоте и гармоничности язык Си сочетается в Линуксе с ужасными и взрывающими мозг языками шелл-скриптов и мейкфайлов. Глядя на них только и хочется сказать «дайте мне развидеть это». Странное противоречие, но как будто эти языки пришли из совершенно разных миров…
Программирование же на чистом Си вызывает умиротворенность:) Все навороты С++ просто отсутствуют. Все что можно сделать — можно сделать единственным образом. Возможно, что это следствие того что для Си другие задачи, и если бы я применял Си для тех задач для которых я применяю обычно С++, то проблем было бы еще больше (на самом деле так оно и есть).
И еще. Удивительный по красоте и гармоничности язык Си сочетается в Линуксе с ужасными и взрывающими мозг языками шелл-скриптов и мейкфайлов. Глядя на них только и хочется сказать «дайте мне развидеть это». Странное противоречие, но как будто эти языки пришли из совершенно разных миров…
НЛО прилетело и опубликовало эту надпись здесь
Шаблоны это магия и эту маги познать можно, и даже есть книги, которые позволяют это сделать. И когда этой магией будет пропитан весь мозг, вот тогда даже boost становится понятен.
Ладно еще все shell-языки неказисты в некоторой мере, но так обидеть Make — у Вас нет сердца! :)
shell и make тесно связаны, и я бы сказал что мне вся эта концепция активно не нравится.
Например qmake удивительно простой (поэтому там где возможно в линуксе использую только его). Но там иногда все равно вылезают хвосты от make.
Проекты Visual Studio к сожалению слишком неудобны для редактирования в текстовом виде, но концептуально тоже ничего.
qbs выглядит очень неплохо, очень похоже именно на то что надо, но к сожалению я этой системой еще не пользовался.
Например qmake удивительно простой (поэтому там где возможно в линуксе использую только его). Но там иногда все равно вылезают хвосты от make.
Проекты Visual Studio к сожалению слишком неудобны для редактирования в текстовом виде, но концептуально тоже ничего.
qbs выглядит очень неплохо, очень похоже именно на то что надо, но к сожалению я этой системой еще не пользовался.
Просто make — это низкоуровневое универсальное средство сборки проекта, а не средство его описания. Проекты Visual Studio действительно заморочены, и лазить руками в них лишний раз не стоит, когда для этого есть IDE.
Но лазить руками в них все равно приходится. Например, выносить общие для всех проектов настройки (пути, платформы, опции компилятора и режимы компиляции) в подключаемые шаблоны проектов, менять условия условий применения определённых настроек.
Но лазить руками в них все равно приходится. Например, выносить общие для всех проектов настройки (пути, платформы, опции компилятора и режимы компиляции) в подключаемые шаблоны проектов, менять условия условий применения определённых настроек.
Вообще говоря мне и бешеное изобилие опций командной строки того же gcc не нравится. Я бы предпочел, чтобы опции задавались в структурированном декларативном виде в файле проекта (идеально в json-подобном формате), который был бы единственным аргументом для gcc и заменой как опций gcc, так и make-файлов.
Это make — низкоуровневое?
В Makefile можно просто сказать, что эта цель зависит от этих файлов таким то образом. В современных системах что бы сделать такое часто приходится писать код, который сам проверяет и сравнивает времена модификаций файлов и дальше инициирует необходимые действия. И кто после этого низкоуровневый?
В Makefile можно просто сказать, что эта цель зависит от этих файлов таким то образом. В современных системах что бы сделать такое часто приходится писать код, который сам проверяет и сравнивает времена модификаций файлов и дальше инициирует необходимые действия. И кто после этого низкоуровневый?
Да, низкоуровенвое, иначе бы не существовало куча надстроек над make.
Во-первых, куча мантр: прописывание компилятора, его флагов, правил компиляции и т.д. А если я хочу поменять комилятор, при этом не хочу трогать Makefile?
Во-вторых, сложность с подключениями пакетов. Вот есть у меня проект — статическая библиотека, и я хочу его подключить и использовать. С помощью Makefile я не могу этого сделать с помощью инструкции типа «вот в той директории лежит проект, подключи его», мне нужно на низком уровне прописывать пути, опции компилятора, ещё и помнить, куда кладутся бинарники и т.д.
В-третьих, что у нас там с автоматическим скачиванием пакетов?
Во-первых, куча мантр: прописывание компилятора, его флагов, правил компиляции и т.д. А если я хочу поменять комилятор, при этом не хочу трогать Makefile?
Во-вторых, сложность с подключениями пакетов. Вот есть у меня проект — статическая библиотека, и я хочу его подключить и использовать. С помощью Makefile я не могу этого сделать с помощью инструкции типа «вот в той директории лежит проект, подключи его», мне нужно на низком уровне прописывать пути, опции компилятора, ещё и помнить, куда кладутся бинарники и т.д.
В-третьих, что у нас там с автоматическим скачиванием пакетов?
Make управляет абстрактным workflow (я на нем как-то сделал паралельное поднятие независимых сервисов в Linux :-)), а ключи компиляторов и управление пакетами — не него задача. Следуя «Unix way», он решает одну задачу, но хорошо, позволяя описывать зависимости декларативно и абстрактно. Но он вполне без проблем может интегрироваться с разными компиляторами и пакетными менеджерами.
Недостатки make — использование значимой табуляции и не очень хорошо подходящий для пакетной работы синтаксис sh. Но в своей области это высокоуровневый инструмент.
Недостатки make — использование значимой табуляции и не очень хорошо подходящий для пакетной работы синтаксис sh. Но в своей области это высокоуровневый инструмент.
Знаете, язык «С» — тоже высокоуровневый (по определению). Но есть ещё и всякие Java, Python. Так вот make — это как C, а я хочу уровень Python, ну или хотя бы Java.
Понятно же, что сложность программ многократно выросла за последние десятилетия, и инструмент make стал неудобным для огромных проектов.
Понятно же, что сложность программ многократно выросла за последние десятилетия, и инструмент make стал неудобным для огромных проектов.
НЛО прилетело и опубликовало эту надпись здесь
забавно, мои впечатления были наоборот, скорее негативными. В основном от того, что очистка выделенных ресурсов в плюсах всегда проще (scoped exit, unique_ptr)
C это свобода и ответственность.
Правда весь этот дзен в миг улетучивается, когда ты встречаешь нагромождение скобок и звездочек и начинаешь их «раскручивать»: «Так, тут у нас указатель на функцию, которая принимает в качестве аргумента указатель на функцию с двума параметрами возвращающую указатель на массив указателей на функции, которые ....»
Тогда Вам нужно обязательно попробовать C-- — не шучу! Недавно на Хабре была про него статья, язык C-- — реально существует.
Да я этот С-- смотрел когда еще Хабра не было:)
А к той статье вроде бы даже писал комментарии… странный язык. С одной стороны доступ к низкоуровневым вещам это приятно (хотя даже в Borland C++ был прямой доступ к регистрам через _AX, _BX и т.д.), но вот с другой — отсутствие приоритетов операций ставит на языке жирный крест.
А к той статье вроде бы даже писал комментарии… странный язык. С одной стороны доступ к низкоуровневым вещам это приятно (хотя даже в Borland C++ был прямой доступ к регистрам через _AX, _BX и т.д.), но вот с другой — отсутствие приоритетов операций ставит на языке жирный крест.
полностью согласен. чистый С — очень наглядный и понятный. библиотеки просты и ясны.
Я в своё время начинал изучать программирование переводя вручную в машинный код на ZX-Spectrum. Потом открыл для себя Zeus. А написать по памяти программу для копирования блока кода из одной области памяти в другую вообще без справочников мог :) Например, загрузить картинку в память, а потом вывести его быстро на экран.
по памяти ldir? ))
У меня был такой набор
— Ассемблер GENS4-51 (у когорого 51 символ в строке вместо дефолтных 32-х)
— Монитор/отладчик MONS4
Ну и, конечно же, The Complete Machine Code Tutor — обучающая программа по архитектуре и системе команд процессора Z80
Дизассемблировал заставки к играм и записывал карандашем в тетрадку код понравившихся эффектов.
Помимо спектрумовского асма в памяти жив легендарный Laser Basic — расширение для системного бейсика, вешающее свой хук на обработчик ошибок и расширяя таким образом синтаксис базового языка примитивами для работы с графикой (спрайты и т.п.)
— Ассемблер GENS4-51 (у когорого 51 символ в строке вместо дефолтных 32-х)
— Монитор/отладчик MONS4
Ну и, конечно же, The Complete Machine Code Tutor — обучающая программа по архитектуре и системе команд процессора Z80
Дизассемблировал заставки к играм и записывал карандашем в тетрадку код понравившихся эффектов.
Помимо спектрумовского асма в памяти жив легендарный Laser Basic — расширение для системного бейсика, вешающее свой хук на обработчик ошибок и расширяя таким образом синтаксис базового языка примитивами для работы с графикой (спрайты и т.п.)
Да что машинные коды — многие даже количество тактов почти каждой команды процессора наизусть помнили (ну это уже позже было, когда демо-сцена расцветала и стала появляться нормальная документация по процессорам и асму). А так — да, и на бумаге программы нередко писать приходилось, и графику на «миллиметровке» карандашом рисовать, а затем попиксельно переводить, и много других вещей.
Было такое. Изучал как на магнитной ленте данные хранятся. Разгадывал загрузчик Веременнеко, а также загрузчиков со шкалой. Каждый такт приходилось выверять. Потом сделал турбозагрузчик, когда каждый бит был заложен в положительный или отрицательный импульс. Не знал я тогда, что при скважности отличной от двух спектр импульса шире… Но тогда хватило, а потом учиться уехал.
На Apple ][ не было таймера, все задержки измерялись выполнением команд процессора, поэтому такты надо было помнить обязательно.
62 255 0 64 17 0 27 55 205 86 5 201 — запомнил навсегда.
Люблю Паскаль. За плечами кружок программирования в школьные годы. Привет в Рыбинск, Дмитрию Аргову.
Кстати, надо с отступами.
Кстати, надо с отступами.
program HelloWorld;
begin
WriteLn('Hello, World!');
end.
Полностью согласен!
Лучшего языка для начинающих пожалуй не придумали.
Вирт ГЕНИЙ!
Как учитель уже выпустивший не один десяток учеников которые пошли по данному профилю, могу сказать, Паскаль жив и еще много хорошего сделает.
Хотя сам начинал с маш кода.
Лучшего языка для начинающих пожалуй не придумали.
Вирт ГЕНИЙ!
Как учитель уже выпустивший не один десяток учеников которые пошли по данному профилю, могу сказать, Паскаль жив и еще много хорошего сделает.
Хотя сам начинал с маш кода.
Лучшего языка для начинающих пожалуй не придумали.
А как же Delphi, являющийся развитием Паскаля?
Вы можете меня побить ;) но Дельфи это не язык, а среда разработки на основе Паскаля.
Да, я знаю есть отличия, есть дополнение итак далее. Сам на нем создавал коммерческие приложения, но для начинающих лучше все классика-Паскаль :)
Да, я знаю есть отличия, есть дополнение итак далее. Сам на нем создавал коммерческие приложения, но для начинающих лучше все классика-Паскаль :)
Дельфи принципиально отличается тем, что у него парадигма Событийно-Ориентированного Программирования.
У вас устаревшее на лет 15 представление о мире. Delphi — это язык.
конечно — раз есть дельфийцы, то должен быть язык, на которм они общаются
Но я часто думаю, являются ли дельфийцы подвидом программистов
Но я часто думаю, являются ли дельфийцы подвидом программистов
Интересно, а кто?
Код писать можно на чём угодно, «Делфи — это визуальные формочки» — это явно от знакомства со школьными хэллоуворлдами. Примерно как ПХП — если порог вхождения позволяет школьникам ваять недосайты, то это не значит что на нём нельзя делать проекты. На сях тоже индусского кода более чем (весь код в h-файле, например). И таки-да, Delphi — это название языка уже много лет как (с 7 версии).
Код писать можно на чём угодно, «Делфи — это визуальные формочки» — это явно от знакомства со школьными хэллоуворлдами. Примерно как ПХП — если порог вхождения позволяет школьникам ваять недосайты, то это не значит что на нём нельзя делать проекты. На сях тоже индусского кода более чем (весь код в h-файле, например). И таки-да, Delphi — это название языка уже много лет как (с 7 версии).
кто является подвидом? не совсем понял
Просто для меня дельфийцы — это некоторая окукленная секта адептов — хуже нет на фрилансе встретить предложение поддержки и развития проекта на Дельфи
Например, у 1с-шников на форумах возникают мысли — а программист ли я — у дельфийцев таких мыслей не возникает,
А писать можно на чем угодно, даже на коленке
Просто для меня дельфийцы — это некоторая окукленная секта адептов — хуже нет на фрилансе встретить предложение поддержки и развития проекта на Дельфи
Например, у 1с-шников на форумах возникают мысли — а программист ли я — у дельфийцев таких мыслей не возникает,
А писать можно на чем угодно, даже на коленке
Предложения поддержки и развития проекта на Легендарном COBOL не встречаются?
>Например, у 1с-шников на форумах возникают мысли — а программист ли я
Мысль возникает поскольку многие программисты 1С занимаются программированием на 1С процентов 20 времени, остальное время это постановка учета, консультации, написание схем бизнес-процессов, ковыряние в проводках и куча других вещей из смежных областей
Мысль возникает поскольку многие программисты 1С занимаются программированием на 1С процентов 20 времени, остальное время это постановка учета, консультации, написание схем бизнес-процессов, ковыряние в проводках и куча других вещей из смежных областей
Скорее низкий порог вхождения позволяет за 3 копейки нанять эникея, который потом забросит продукт (или «продукт»), а заказчик захочет продолжения и ищет кого бы нанять. Обычно это фрилансеры, т.к. на пару формочек брать кого-то на полный рабочий дорого.
Другими словами нормальный язык должен иметь высокий порог вхождения — согласен — язык должен быть профессиональным, то есть применять его должен именно профессионал — а вот какие языки удовлетворяют этому требованию?
И будет им пользоваться полспециалиста на миллиард, ибо мало кто будет изучать на других проектах. Сложность освоения — порог вхождения велик, кадры безумно дороги и невосполнимы, библиотек нет, ибо нет сообщества. Нужен ли для реальных проектов такой профессионал? Лучше уж взять делфиста с хорошими навыками и опытом в нужной/разных сферах, чем такое непонятное чудо. Конкретный выбор зависит от проекта.
Delphi 7.0 — язык переименован из Object Pascal в Delphi. Шах и мат.
Развитием Паскаля является Oberon и Component Pascal. А Дельфи (Object Pascal) является модной в то время ООП-коммерциализацией языка.
А компонентный паскаль? Как он на практике и в обучении?
На практике не взлетел, в обучении чуть сложнее обычного паскаля — добавлены модули и методы. Синтаксис (32 страницы) гуглить component pascal language report. Аналогично для Oberon
А ещё была Modula — тоже как развитие Паскаля, и то же не взлетела. Оказалось, что наиболее полезные фишки Модулы легче добавить в Паскаль, чем переходить на Модулу.
Вообще слышал что компонентный паскаль — супер-пуперский, объектный, минималлистичный и надёжнейший язык — типа гибрида стилета с танком. Насколько это действительности соответствует?
И ещё — вроде бы языки движутся с десятилетиями в сторону доказательного программирования — компонентный паскаль пригоден для такого программирования?
Очень люблю Pascal и до сих пор на нём активно пишу (Lazarus/Delphi).
Но вот с дочкой в качестве первого языка всё-таки выбрали Python (Scratch не в счёт).
Но вот с дочкой в качестве первого языка всё-таки выбрали Python (Scratch не в счёт).
Нормально и правильно!
Тысячный раз повторю, Паскаль хорош как алгоритмический язык для первоначального обучения для детей примерно с 6-7 класса.
Если же алгоритмические структуры и основные понятия изучили раньше например на Scratch или Logo то разумней переходить на более взрослые языки Python, Java, C++.
Тысячный раз повторю, Паскаль хорош как алгоритмический язык для первоначального обучения для детей примерно с 6-7 класса.
Если же алгоритмические структуры и основные понятия изучили раньше например на Scratch или Logo то разумней переходить на более взрослые языки Python, Java, C++.
вот неуверен. например нет понимания структуры памяти.
я начинал на С. после него паскаль казался несколько примитивным.
я начинал на С. после него паскаль казался несколько примитивным.
Если кто-то считает, что есть «отстойные» языки, то он просто не постиг Дао программирования. То, что оказывается ненужным, просто отпадает само по себе. У любого языка есть свой «жизненный цикл», своя ниша. Я учился на Фортране, был Паскаль, Си, все они прекрасны. Нет «плохих» языков.
Сейчас я программирую на LabVIEW, и это выглядит вот так:
Формально этот код эквивалентен
Для меня это тоже язык программирования, хоть и графический, и ничуть не конфликтует с C#, который я изучаю в свободное время.
Сейчас я программирую на LabVIEW, и это выглядит вот так:
Формально этот код эквивалентен
int result = 0;
for (int i = 1; i < 1000; i++) {
if (((i % 3) == 0) || ((i % 5) == 0)) {
result += i;
}
}
Для меня это тоже язык программирования, хоть и графический, и ничуть не конфликтует с C#, который я изучаю в свободное время.
Для понимания графически изображённых алгоритмов нужны специальным образом повёрнутые мозги. Видимо, на них и ориентированы такие языки. Был период, когда визуальное программирование преподносилось как способ снижения порога вхождения в программирование — вот этого я на понимал.
Вот смотрю я на код — сразу всё понятно, на изображение — приходится должно въезжать. Аналогично приходится взрывать мозг, когда вижу UML. И это не привычка — со школы блок-схемы не воспринимаю. Хардварные реализации (радиоэлектроника), кстати, тоже не понимаю.
Вот смотрю я на код — сразу всё понятно, на изображение — приходится должно въезжать. Аналогично приходится взрывать мозг, когда вижу UML. И это не привычка — со школы блок-схемы не воспринимаю. Хардварные реализации (радиоэлектроника), кстати, тоже не понимаю.
У меня всё наоборот — текстовый код я воспринимаю значительно хуже (речь не идёт о коротких листингах, но если в проекте несколько десятков тысяч строк, то мне требуется заметно больше времени для понимания, чем в сравнимом по сложности LabVIEW проекте).
Вообще навык читать и создавать такие диаграммки приходит довольно быстро — через две недели оно уже не вызывает отторжения, через два месяца начинаешь свободно понимать чужой код, через два года перестаёшь понимать код текстовый.
Вообще каждый язык хорош по своему, но в той области, в которой я работаю (автоматизация производства и машинное зрение в области рентгеновского неразрушающего контроля) на LabVIEW разработка идёт значительно резвее — я с такой скорость даже на Дельфи не программировал (сравнимые по сложности продукты). Ну и по образованию я физик-электронщик, для меня диаграммки и схемы всегда были понятны.
Вообще навык читать и создавать такие диаграммки приходит довольно быстро — через две недели оно уже не вызывает отторжения, через два месяца начинаешь свободно понимать чужой код, через два года перестаёшь понимать код текстовый.
Вообще каждый язык хорош по своему, но в той области, в которой я работаю (автоматизация производства и машинное зрение в области рентгеновского неразрушающего контроля) на LabVIEW разработка идёт значительно резвее — я с такой скорость даже на Дельфи не программировал (сравнимые по сложности продукты). Ну и по образованию я физик-электронщик, для меня диаграммки и схемы всегда были понятны.
немного не так. У многих инженеров постарше хорошо развито системное мышление, но языки программирования они если и застали, то мельком. Поэтому им программировать квадратиками и кружочками проще
В основном вы правы, но, наблюдая за такими инженерами (хорошими, кстати) я вижу, что они довольно легко «входят» в эти кружочки и квадратики, но довольно быстро упираются в растущую сложность проектов, когда системное мышление уже не помогает, а требуются фундаментальные знания в разработке ПО, те же паттерны проектирования, хорошее понимание ООП, которых у них просто нет, ввиду того, что они застали классические языки «лишь мельком».
Я бы ни в коем случае не начинал изучение программирования с LabVIEW — тут простота кажущаяся и программист должен быть сформировавшийся, с окрепшей психикой.
Я бы ни в коем случае не начинал изучение программирования с LabVIEW — тут простота кажущаяся и программист должен быть сформировавшийся, с окрепшей психикой.
LabVIEW сравнивать с текстовыми языками — это как китайский с английским)))
А вообще + за упоминание. И если идти путем LabVIEW, который печатание текста превращает в рисование алгоритма, то следующая стадия в программировании это «компьютер, включи плиту, разбей на сковороду яйцо и жарь 5 мин». Лет так через 20 называться это будет «программирование рецепта завтрака».
А вообще + за упоминание. И если идти путем LabVIEW, который печатание текста превращает в рисование алгоритма, то следующая стадия в программировании это «компьютер, включи плиту, разбей на сковороду яйцо и жарь 5 мин». Лет так через 20 называться это будет «программирование рецепта завтрака».
Сравнение с китайским — прекрасно! 20 лет — это довольно оптимистичный прогноз, я полагаю и через 20 и через 50 лет текстовые языки будут использоваться в полный рост. Однако лет этак через 100-150 процесс разработки ПО будет выглядеть совсем иначе — тут я не сомневаюсь. Графическая парадигма имеет свои плюсы, но в данный момент несколько опережает время, системы контроля версий не заточены под эти файлы, нет стандартов, и т. д.
согласен — всегда мечтал писать программу как картину — лучше трехмерную
имо лучше если программы останутся в текстовом виде. Пусть лучше по тексту рисует графическое представление, если кому-то так нагляднее. Возможно, блок-схемы нагляднее текста для понимания кода. Но писать код куда быстрее, чем раскидывать кружочки
Блок-схемы очень красиво смотрятся на презентациях и прочих документов, а вот рисовать их — очень неудобно. Даже в Visio — намного медленнее и тормознее, чем писать код руками. Потому, когда мне в каком-нибудь документе нужно наглядное отображение алгоритма, то я использую структограммы Несси-Шнейдермана, благо их очень легко создавать в Word используя самые обыкновенные стандартные таблицы.
На стандартной клавиатуре, без хоткеев это конечно же ад!
Для таких «наглядных» языков необходимо подключать дополнительную клавиатуру с программируемыми клавишами забиндеными на нужные хоткеи.
Основная проблема визуального программирования — необходимость часто переключать режимы работы и выбирать необходимый инструмент — наглядная клавиатура решит эту проблему и останется только одной рукой елозить мышкой(не отрывая руки) по делу а не в меню.
Для таких «наглядных» языков необходимо подключать дополнительную клавиатуру с программируемыми клавишами забиндеными на нужные хоткеи.
Основная проблема визуального программирования — необходимость часто переключать режимы работы и выбирать необходимый инструмент — наглядная клавиатура решит эту проблему и останется только одной рукой елозить мышкой(не отрывая руки) по делу а не в меню.
Не все любители учить сотни биндов наизусть.
А насчёт специальной клавиатуре — это к APL. Потому что, например, в Delphi можно добавлять новые визуальные компоненты, а у обычной не виртуально клавиатуры — количество клавиш ограничено.
А насчёт специальной клавиатуре — это к APL. Потому что, например, в Delphi можно добавлять новые визуальные компоненты, а у обычной не виртуально клавиатуры — количество клавиш ограничено.
Так для этого и дополнительные клавиатуры. Как-то давно видел клавиатуру специальную для 3Dmax, AutoCAD и т.п. с аналоговыми крутилочками и доп. клавишами для удобной навигации в 3D.
А обычные кнопочные, как на кассовых аппаратах бывают и по 100 клавиш, свои изображения можно повставлять настроить и пользоваться — она распознается как стандартная USB-клавиатура.
Недавно статья по ним была на хабре.
Есть ещё клавиатуры-доски для драм-машин, они ко всему прочему могут подсвечиваться индивидуально любым из 16млн цветов, но эти совсем в цене…
Даже 100 кнопок это будет уже перебор — вы же не всегда пользуетесь 100+ объектов и режимов одновременно. Обычно же не больше 20 избранных часто используемых режимов и объектов.
А обычные кнопочные, как на кассовых аппаратах бывают и по 100 клавиш, свои изображения можно повставлять настроить и пользоваться — она распознается как стандартная USB-клавиатура.
Недавно статья по ним была на хабре.
Есть ещё клавиатуры-доски для драм-машин, они ко всему прочему могут подсвечиваться индивидуально любым из 16млн цветов, но эти совсем в цене…
Даже 100 кнопок это будет уже перебор — вы же не всегда пользуетесь 100+ объектов и режимов одновременно. Обычно же не больше 20 избранных часто используемых режимов и объектов.
Если говорить о LabVIEW, то постоянное переключение было необходимо лет этак десять назад. В настоящее время есть QuickDrop, есть настраиваемые хоткеи, а режимы уже переключаются автоматически.
Ну вот, к примеру, если требуется построить графики синуса и косинуса для сотни элементов, то процесс «рисования кода» с использованием QuickDrop как-то вот так выглядит:
QuickDrop я вызываю нажатием Ctrl+пробел, затем просто ввожу названия примитивов. В принципе довольно эргономично.
Ну вот, к примеру, если требуется построить графики синуса и косинуса для сотни элементов, то процесс «рисования кода» с использованием QuickDrop как-то вот так выглядит:
под спойлером анимированная гифка чуть больше мегабайта
QuickDrop я вызываю нажатием Ctrl+пробел, затем просто ввожу названия примитивов. В принципе довольно эргономично.
Идеально если код будет иметь двойное представление.
и в виде схемы и в виде читаемого кода текста.
в принципе к этому идет, иде сейчас уже рисуют диаграммы к коду по мере набора автоматически перерисовывают.
дебаг и контроль версий все таки работает с текстом пока.
а схема позволяет больше показать связей чем код. удобнее думать что не так в алгоритме.
я немного не так выразился, наверное. Я предположил утопию, в которой SDK будет на основе текста кода генерировать все эти блок-схемы, чтобы можно было мельком глянуть что где и как работает, а сам код править в виде текста.
Ну в идеале это должно в обе стороны работать — я могу разрабатывать что-то в графическом виде, при этом всегда иметь возможность переключиться в текстовый человекочитаемый текст, поправить что-то там, и это отобразилось бы в виде графическом и т. д. В настоящее время я могу только в графическом виде работать, оттого системы контроля версий, заточенные под текстовые файлы и не понимающие двоичный формат, в котором хранится моя диаграмма, не могут отобразить мне изменения.
Я не представляю, как должен выглядеть diff для LabVIEW файлов. Хотя если бы LabVIEW генерировал что‐то вроде «текстовый формат (тот же XML, хотя я его и не люблю) с секциями:
- список всех объектов на диаграмме,
- список всех логических связей между объектами (как вида «вход X элемента „больше или равно №50“ идёт на вход „бр“ элемента „создать кластер“», так и „элемент … находится на вкладке true диаграммы switch“),
- список всех отображений этих связей (т.е. „где пользователь видит провода“), а также принципиального внешнего вида, размеров (логических) и местонахождений объектов,
- список позиций и размеров индикаторов/… на контрольной панели, а также
- список входов и выходов VI»,
то diff вполне можно было бы понимать (при условии, что все списки сортированы, а элементы списков находятся каждый на своей строке). Не очень удобно, особенно, если изменение заключается в том, что вы добавили элемент X между элементами Y и Z и, соответственно, подвинули следующие за ними элементы Z1…Z50. Но, благодаря отделению отображения в отдельную секцию, можно понять, в чём принципиальные отличия.
Но это не позволит вам «разрабатывать в графике, переключиться в текст, потом опять в графику»: одна из главных проблем с редактированием в тексте — это «откуда брать позиции». Я как‐то скептически отношусь к возможности быстро программно сгенерировать одновременно читаемую и редактируемую диаграмму по данному тексту.
Кстати, научитесь переводить VI в такие XML’ки, можно будет научить VCS diff’ить их (по крайней мере, git и mercurial точно можно). Даже если при этом LabView не сможет их читать: хранить, в принципе, можно и старые VI.
С merge я так не уверен: mercurial точно можно (система расширений и не такое позволяет; а если и не позволяет, то авторы наверняка пойдут навстречу, как только вы объясните, зачем вам это нужно), git — не знаю. Да и задача более сложная.
Робот Фортран, чисть картошку! (с)
А почему бы и нет ;) только думаю не через 20, а уже лет через 5 :)
Если вспомнить что было 20 лет назад и сейчас, то думаю не все тогда поверили что такое возможно так скоро.
Если вспомнить что было 20 лет назад и сейчас, то думаю не все тогда поверили что такое возможно так скоро.
Мне приходится писать на LabView сейчас, и это ужасно. Дольше оформляется «красиво», при попытке что‐то абстрагировать в VI вылезают какие‐то баги (пытался разнести «код» инициализации/открытия FPGA, считывания из него значения и закрытия в три VI, так вторая со считыванием в упор не видит обновлений в VI FPGA), неясно где что вообще исполняется (три общих варианта: процессор MyRIO, его же FPGA и компьютер с labview, в первом случае ещё и подварианты (процессора (точнее, ядер) два, вроде есть потоки и процессы)), неясно, когда, как и на что выделяется память, неясна потокобезопасность различных конструкций (смотрел пример с погодным сервером на RT, не понимал, как такое вообще можно было придумать: очередь это VI с циклом, исполняющимся один раз; цикл нужен, чтобы хранить переменные в shift register — по моему мнению, они, вообще‐то, должны пересоздаваться при каждом обращении, а реально очередь можно использовать из обработчика http запроса, который неясно где вообще исполняется (но не думаю, чтобы в одном потоке с главным циклом, эту очередь использующим)). И ещё, diff вы не получите.
В общем рисовать в LabView долго — дольше, чем печатать после предварительного обучения. Узнать, что изменилось нельзя не только при помощи VCS, но даже и средствами LabView (как‐то посмотрел, чем объясняет LabView необходимость сохранения). Понять, как работает то, что вы нарисовали сложно. Единственный плюс — первые несколько прошивок для FPGA на каком‐нибудь VHDL я писал бы дольше, чем рисовал её же в LabView. Но только первые несколько.
графические языки очень малопроизводительны. Набрать приведенный экивалентный код намного быстрее, чем накидать все нужные элементы, установить связи и параметры.
В Delphi интерфейс и подключения к база данных — быстрее всего сделать графическим способом.
Пару лет назад на хабре при обсуждении спагетти-ориентированной разработки, коллега ttools задал вот такую задачку:
На что я ответил вот таким пятиминутным видео:
Вообще сравнивать LabVIEW с текстовыми языками — это всё равно что холиварить на тему Windows против Linux, или сравнивать китайский с английским. Я достаточно свободно владею и LabVIEW и С# — у каждого свои области применимости, свои паттерны, и так далее. Основная тема статьи — каждый язык хорош по своему, и с этим я абсолютно согласен. Вот только не нужно программировать на COBOL, если этого можно избежать.
Я бы хотел посмотреть, как бы вы красиво выполнили код такой несложной задачи, вполне практической: Имеется 30 датчиков одинакового типа, каждый датчик в реальном времени выдает 4 параметра, допустим float ток и напряжение и два boolean параметра: датчик исправен и датчик включен. Надо отобразить показания всех датчиков на одном экране, допустим 3 ряда по 10 слева направо, сверху вниз, в виде 2 танков (ток, напряжение) и 2х подписей (включен/отключен, исправен/ неисправен) на каждый датчик. Данные от датчиков можно эмулировать любыми функциями от времени и индекса датчика.
На Delphi, например, эту задачу я могу выполнить за полчаса, красивым кодом, с короткими методами. Сколько времени уйдет, чтобы сделать это на LabView и насколько это получится красиво и без лапши?
На что я ответил вот таким пятиминутным видео:
Вообще сравнивать LabVIEW с текстовыми языками — это всё равно что холиварить на тему Windows против Linux, или сравнивать китайский с английским. Я достаточно свободно владею и LabVIEW и С# — у каждого свои области применимости, свои паттерны, и так далее. Основная тема статьи — каждый язык хорош по своему, и с этим я абсолютно согласен. Вот только не нужно программировать на COBOL, если этого можно избежать.
Ну как же тут было Prolog не вспомнить?
НЛО прилетело и опубликовало эту надпись здесь
Классический Пролог поддерживает исключительно только Бинарную Логику. Для вещей посложнее лучше что-нибудь вроде Fuzzy Prolog с поддержкой Нечёткой Логики.
В принципе есть Mercury (хотя он не все умеет) и Curry, но они все еще маргинальны.
Меня удивляет, что в современных версиях Prolog почти не внедряют программирование в ограничениях. Появись такая поддержка, этот язык стал бы более востребован (пока его роль выполняют всякие солверы), да и программировать на нем стало бы легче (меньше неожиданных эффектов от изменения порядка предикатов).
Меня удивляет, что в современных версиях Prolog почти не внедряют программирование в ограничениях. Появись такая поддержка, этот язык стал бы более востребован (пока его роль выполняют всякие солверы), да и программировать на нем стало бы легче (меньше неожиданных эффектов от изменения порядка предикатов).
есть Mercury (хотя он не все умеет) и Curry
Не напишете про них ознакомительные статьи?
Заманчивая идея…
Я тут наткнулся на имплементацию языка LIFE. Разберусь с ним, смогу написать обзор о языках логического программирования.
Я тут наткнулся на имплементацию языка LIFE. Разберусь с ним, смогу написать обзор о языках логического программирования.
Я поставил минус, потому что не понял для чего эта статья, просто набор слабосвязных фактов. Какие выводы нужно было сделать после прочтения?
Понимаете, это как коллекция антиквариата с записками кто и зачем это сделал.
Каждый смотрит на эту коллекцию и видит своё: кто-то восхищается создателями, кто-то усмехается — «Как же таким можно было пользоваться», у кого-то прокатывается глубоко внутри ностальгия и вспоминается школьная любовь… эх…
Если бы мог плюсануть, наплюсовал бы! :)
Каждый смотрит на эту коллекцию и видит своё: кто-то восхищается создателями, кто-то усмехается — «Как же таким можно было пользоваться», у кого-то прокатывается глубоко внутри ностальгия и вспоминается школьная любовь… эх…
Если бы мог плюсануть, наплюсовал бы! :)
Эта статья для того, что-бы мы вспомнили каким тёплым и ламповым был ассемблер. Только гляньте на эти листочки (выше), становится сразу так тепло...
На отсканированных листочках «программирования в машинных кодах, без ассемблера» не видно, там обычный ассемблер.
Кроме того, Алгол-68 (на котором приведен пример) и Алгол-60 это совершенно разные языки.
Кроме того, Алгол-68 (на котором приведен пример) и Алгол-60 это совершенно разные языки.
На бумажке – условные переходы без меток, адреса переменных в числовой форме, и ниже – список адресов команд, составленный вручную. То есть автор сначала писал машинные команды в символической записи, а потом переводил их в машинный код вручную. Короче, представлен исходный материал для ручного ассемблирования.
В случае использования ассемблера там стояли бы символические адреса.
В случае использования ассемблера там стояли бы символические адреса.
В силу своего возраста мне довелось начать обучение (в вузе конечно) с машинных кодов, потом был алгол, потом фортран
Потом все остальные языки типа pascal, с/с++, разные варианты бейсика, java, c#, php, actionscript и др., которые использовались профессионально, то есть для реализации оплачиваемых проектов.
Некоторые языкм изучались для души типа Пролога или Лого, но профессионально не применялись.
Какой лучше или хуже — вопрос бессмысленный — лучший язык для программиста тот, на котором он лучше всего программирует
Не знаю как в Википедии, но вообще-то язык программирования — это средство записи алгоритма.
Если получается быстро и компактно записать нужный алгоритм решения поставленных задач в данной предметной области, то это и есть лучший для тебя язык
Хуже, когда приходишь на проект, созданном на чужом языке — это все равно, что попасть в центр Монголии, зная всего три монгольских слова — богатырь, деньги, тьма
Поэтому лучше не думать, что лучше, а учить, пока не станет лучше
Потом все остальные языки типа pascal, с/с++, разные варианты бейсика, java, c#, php, actionscript и др., которые использовались профессионально, то есть для реализации оплачиваемых проектов.
Некоторые языкм изучались для души типа Пролога или Лого, но профессионально не применялись.
Какой лучше или хуже — вопрос бессмысленный — лучший язык для программиста тот, на котором он лучше всего программирует
Не знаю как в Википедии, но вообще-то язык программирования — это средство записи алгоритма.
Если получается быстро и компактно записать нужный алгоритм решения поставленных задач в данной предметной области, то это и есть лучший для тебя язык
Хуже, когда приходишь на проект, созданном на чужом языке — это все равно, что попасть в центр Монголии, зная всего три монгольских слова — богатырь, деньги, тьма
Поэтому лучше не думать, что лучше, а учить, пока не станет лучше
вообще-то язык программирования — это средство записи алгоритма
Это Императивные языки, в Декларативных языках, включая (чистые) ФП, алгоритм не записывается.
Всё-таки не соглашусь с таким определением. Это не средство записи алгоритма. Тут скорей применима аналогия что язык — это алфавит и правила написания алгоритма.
Средство написания алгоритмов — это IDE и набор библиотек к конкретному компилятору языка программирования.
Средство написания алгоритмов — это IDE и набор библиотек к конкретному компилятору языка программирования.
несогласие — дело личное
Но любой алгоритм — это описание, для чего и нужен язык
Алгоритмы не требуют иде и прочего — но описать можно на только неком языке, что было изложено еще в труде аль Хорезми — Китаб мухтасаб аль-джабр и ва-ль-мукабала, где были описаны способы формализации описаний решения. Данное понятие алгоритма из этой книги попало в Европу (алгоритм и есть измененная фамилия автора)
Но любой алгоритм — это описание, для чего и нужен язык
Алгоритмы не требуют иде и прочего — но описать можно на только неком языке, что было изложено еще в труде аль Хорезми — Китаб мухтасаб аль-джабр и ва-ль-мукабала, где были описаны способы формализации описаний решения. Данное понятие алгоритма из этой книги попало в Европу (алгоритм и есть измененная фамилия автора)
Разве надежность — свойство языка? Вроде бы хелловорд на бейсике не менее надежен, чем на аде…
Чем паскаль то не устроил? Нормальный язык. Приучает сначала подумать (объявить переменную), а потом сделать. Вместо мусора в коде со 100500 переменными, которые объявлены черте где по месту и кучу раз перекрываются и в первый раз она указатель на объект, а во-второй раз там количество итераций цикла. И потом всю эту кашу кому-то разбирать)
В детстве читал книгу «А я был в компьютерном городе» и там приводили пример «программы» на машинном языке (в двоичном коде). Понял что это значит много лет спустя только в институте, когда, как встатье, писали программы на ассемблере, потом переводили их в двоичный код, затем в 16-ричный и наконец-то вводили в ячейки памяти учебного микропроцессорного комплекта (УМК) на базе КР580ИК80А. Здорово помогло для понимания процесса.
Пришлось в институте попрограммировать в машинных кодах на такой УМК-е
http://www.computer-museum.ru/histussr/umk_sorucom_2011.htm
http://www.computer-museum.ru/histussr/umk_sorucom_2011.htm
А у нас в универе был стенд на К1804 и лабу по разработке микропрограмм делал, которую с помошью кнопок в ОЗУ набирали.
Точно, она самая… и процессор там использовался отечественный, выполненный по технологии без диэлектрика на подложке — все транзисторы на кристалле отделялись обратно смещёнными pn-переходами, отчего процессор требовал 3-х различных напряжений питания и строгую последовательность их включения иначе срабатывал тиристорный эффект и выгорала часть кристалла протекающими токами КЗ.
Мдя, было время… Я в своё время для Орион-128 (который в моём исполнении превратился в Орион-512) написал дипломный проект (программа-проверялка исправности логических микросхем ТТЛ/КМОП, работавшая через железяку собственного изготовления, подключенную к параллельному порту), а так же программатор ПЗУ (железо опять же своё) с псевдографическим интерфейсом (вложенные менюшки, рамки, просмотр «прошиваемых» данных в шестнадцатеричном и графическом виде и прочее). Писалось всё даже не на ассемблере на бумаге, а прямо в машинных кодах в шестнадцатеричном редакторе. Я даже сейчас не понимаю, как мне удавалось создаваемый код в голове удерживать… Таблицу команд в кодах помнил ещё лет 15 наверное.
Я бы к этому списку ещё добавил Perl — любимый язык мастеров обфускации.
Программа на PL/I выдаёт очень поверхностное знание этого языка.
1. В конструкции DATA могут содержаться только имена переменных, поэтому такая программа вызовет ошибку при компиляции. Должно быть PUT SKIP LIST ('HELLO WORLD!');
2. Переменная FLAG, будучи описанной по умолчанию и обладая именем, начинающимся с буквы F, имеет вещественный тип, поэтому не очень осмысленно, хотя и возможно, сравнивать её с целым нулём и использовать в качестве флажка. Также не очень понятен бесконечный цикл, организованный таким образом.
3. Инструкции должны записываться не менее чем со второй позиции, коль скоро речь про IBM.
;)
1. В конструкции DATA могут содержаться только имена переменных, поэтому такая программа вызовет ошибку при компиляции. Должно быть PUT SKIP LIST ('HELLO WORLD!');
2. Переменная FLAG, будучи описанной по умолчанию и обладая именем, начинающимся с буквы F, имеет вещественный тип, поэтому не очень осмысленно, хотя и возможно, сравнивать её с целым нулём и использовать в качестве флажка. Также не очень понятен бесконечный цикл, организованный таким образом.
3. Инструкции должны записываться не менее чем со второй позиции, коль скоро речь про IBM.
;)
Мартовский файл
Снова ветреный март
Рассыпает капель,
В штабелях перфокарт
Похоронен PL.
Ничего, я привык,
Я до вас доберусь,
Благородный язык
Заучу наизусть!
Мы пойдём GO TO,
Раскопаем GET LIST,
Будут EDIT и DO,
Будет DEC FIXED,
ZERODIVIDE,
IF ENDFILE THEN REPEAT,
ON TRANSMIT VERIFY,
(X) DCL SYSPRINT.
Чтоб в метель, в холода
Сердцем правил апрель — Ты со мной навсегда,
Мой любимый PL!
1989 © S. Borodatoff
Снова ветреный март
Рассыпает капель,
В штабелях перфокарт
Похоронен PL.
Ничего, я привык,
Я до вас доберусь,
Благородный язык
Заучу наизусть!
Мы пойдём GO TO,
Раскопаем GET LIST,
Будут EDIT и DO,
Будет DEC FIXED,
ZERODIVIDE,
IF ENDFILE THEN REPEAT,
ON TRANSMIT VERIFY,
(X) DCL SYSPRINT.
Чтоб в метель, в холода
Сердцем правил апрель — Ты со мной навсегда,
Мой любимый PL!
1989 © S. Borodatoff
ABAP забыли :)
Жаль что не кто не вспомнил Форт ;)
В своё время был очень интересный язык. Скорость на уровне ассемблера, на нем получались очень любопытные вещи.
В своё время был очень интересный язык. Скорость на уровне ассемблера, на нем получались очень любопытные вещи.
На ХеллоВорлде не видно отличия языков. Вот если взять любую другую задачу для примера — квадратное уравнение, факториал, ряды…
И в список я бы добавил Redcode из Core War.
И в список я бы добавил Redcode из Core War.
извините не могу сдержаться, приведённый машинный код и программа на языка Assembler не соответствуют друг другу.
Первый выводит «Hello, World!» и использует для этого BIOS (см.
Вторая выводит «Hello, World\n» испльзуя порерывение
Первый выводит «Hello, World!» и использует для этого BIOS (см.
CD 10 = int 10h)Вторая выводит «Hello, World\n» испльзуя порерывение
21h MS DOS.
Из графических языков стоит вспомнить https://ru.wikipedia.org/wiki/Ladder_Diagram, а из сложных для понимания https://ru.wikipedia.org/wiki/FORTH
Форт — это такой иврит, читаемый справа налево (польская запись) и с тарабарщиной вместо букв.
А Ladder — как и большинство графических языков, компилируется плохо. Впрочем, декомпилируется н тоже не так легко.
Форт — это такой иврит, читаемый справа налево (польская запись) и с тарабарщиной вместо букв.
А Ladder — как и большинство графических языков, компилируется плохо. Впрочем, декомпилируется н тоже не так легко.
Запись польская, да только читается он слева направо.
2 2 +
Взять 2, взять ещё 2, сложить. И форт-машина выполняет программы тоже слева направо.
И сложен для понимания он тоже только с непривычки.: ) Сложность восприятия человеком вообще штука крайне субъективная. Мне вот лиспы самые простые для понимания, а все вокруг почему-то кроме ))))))))) ничего в них не видят.
2 2 +
Взять 2, взять ещё 2, сложить. И форт-машина выполняет программы тоже слева направо.
И сложен для понимания он тоже только с непривычки.: ) Сложность восприятия человеком вообще штука крайне субъективная. Мне вот лиспы самые простые для понимания, а все вокруг почему-то кроме ))))))))) ничего в них не видят.
я соавтор одной из форт-систем. Но думать на форте я привыкал полгода.
Что касается «справа налево» — сравни направление в операторах в обычном языке и в форте.
Обычный язык if (n != 0)
Форт: n ?DUP 0= IF
Что касается «справа налево» — сравни направление в операторах в обычном языке и в форте.
Обычный язык if (n != 0)
Форт: n ?DUP 0= IF
На счет сложности для понимания согласен, но кто начинал на программируемых калькуляторах (электроника бз-34 и прочих) труда не составляет :)
А еще можно из особенностей вспомнить Форт позволяет создавать свои операторы и делать из них словарь. Простейший пример :2+2= 5; и теперь при наборе 2+2= появляется 5 В свое время это был прогресс. :)
А еще можно из особенностей вспомнить Форт позволяет создавать свои операторы и делать из них словарь. Простейший пример :2+2= 5; и теперь при наборе 2+2= появляется 5 В свое время это был прогресс. :)
LAD элементарно компилируется и декомпилируется, так же как и FBD (в формулировке IEC 61131-3).
Вы писали компилятор и декомпилятор? Можно его проверить на сложных случаях? При декомпиляции проблема в многоадресных командах, иногда очень сложно нарисовать не то, что красиво, но даже и просто корректно. FBD проще отрисовывается. Да, под компиляцией я понимаю преобразование в IL (или в дерево вычислений), при декомпиляции — преобразование из IL. А IL включает команды конкретного контроллера.
Я писал на IL, LAD, FBD (и прочем). IL в стандарте — одноадресный, не привязан к конкретному контроллеру.
И не надо смешивать проблему декомпиляции и отрисовки.
И не надо смешивать проблему декомпиляции и отрисовки.
Я на них почти не писал. Я делал программу для OMRON CV-1000, которая в том числе по срабатыванию аварийного выхода и архиву переключений выясняет, какой источник был причиной аварии. При многотактной отработке аварии и сохранении в архиве далеко не всех входов и промежуточных переменных.
Компиляции в дерево шла из IL конкретного контроллера, включая сотню его специфических команд. Декомпиляция — в графическое представление в LD и FBD с подсветкой значений в конкретных соединениях. Можно было даже видео посмотреть — как меняются сигналы внутри LD или FBD.
> И не надо смешивать проблему декомпиляции и отрисовки.
Тогда что вы понимаете под декомпиляцией LD?
И что значит «элементарно компилируется»?
Компиляции в дерево шла из IL конкретного контроллера, включая сотню его специфических команд. Декомпиляция — в графическое представление в LD и FBD с подсветкой значений в конкретных соединениях. Можно было даже видео посмотреть — как меняются сигналы внутри LD или FBD.
> И не надо смешивать проблему декомпиляции и отрисовки.
Тогда что вы понимаете под декомпиляцией LD?
И что значит «элементарно компилируется»?
Я не понимаю, зачем переделывать руками типовые задачи — определения первопричины аварии и графической отладки LAD, встроенной во все современные средства программирования ПЛК. Ну да ладно, это оффтоп.
«Элементарно компилируется» — это значит, что более удобного для компиляции языка, чем связка логических операторов LAD, трудно себе представить. Это уровень ассемблерного транслятора, а не компилятора. Это синтаксический анализатор выражений, не более.
«Элементарно компилируется» — это значит, что более удобного для компиляции языка, чем связка логических операторов LAD, трудно себе представить. Это уровень ассемблерного транслятора, а не компилятора. Это синтаксический анализатор выражений, не более.
Типовые? Ну покажите, какой софт умеет определять причины аварии. Средненькие условия — на одном из сканов вход стал ON вместо OFF. Всего лишь на один скан. Далее — через 2 скана авария. Всего надо исследовать 3-4 LD-диаграммы с учетом порядка их выполнения в контроллере.
Вы попробуйте написать такой транслятор. С учетом того, что провода можно любой длины рисовать. А дальше будем говорить, легко или нет. Легко компилируется что-то типа паскаля или бейсика. Там работает типовая схема рекурсивного спуска, это обычная курсовая работа. А вот как вы будете компилировать laddder — это интересно.
Делаю реквест на статью — как сделать компилятор Ladder-диаграмм.
Вы попробуйте написать такой транслятор. С учетом того, что провода можно любой длины рисовать. А дальше будем говорить, легко или нет. Легко компилируется что-то типа паскаля или бейсика. Там работает типовая схема рекурсивного спуска, это обычная курсовая работа. А вот как вы будете компилировать laddder — это интересно.
Делаю реквест на статью — как сделать компилятор Ladder-диаграмм.
Анализ первопричины, как и реакция на аварию — шатдаун, делается в ПЛК.
Реакция на аварию — это не шатдаун. Стальная лента идет через печь. При остановке стана через минуту лента начинает прогорать. Если она прогорела, то время заправки её в стан от 12 часов до 3х суток. В день выпускается оцинкованной стали на 1.0-1.5 миллиона долларов.
Так что никакого шатдауна. При аварии останавливается непрерывное движение стальной ленты и загорается лампочка. И дальше забота оператора, на каком управлении протащить ленту — на дистанционном автоматическом однократном, на дистанционном ручном, в конце концов — на местом, прямо со шкафа управления.
ПЛК никакой анализ первопричины не делает. на это у него просто не хватает мощности. Дело ПЛК — по OR/AND собрать сигнал аварии. А уж как образовались отдельные сигналы — дело дежурной смены автоматчиков. Ну и нашего софта.
Разобрались — останов повесят на электриков, приводчиков, гидравликов… не разобрались — на автоматчиков. За 3 часа простоя в месяц по вине службы — премию лишают всю службу. А премия у них равна окладу.
>, зачем переделывать руками типовые задачи — определения первопричины аварии и и графической отладки LAD,
Я повторю вопрос: какой софт умеет определять первопричины аварии?
Ну и заодно — какой софт может проиграть из архива переключения LD по сканам? Не текущее состояние, а архивное, ну скажем 10 сканов перед аварией.
Так что никакого шатдауна. При аварии останавливается непрерывное движение стальной ленты и загорается лампочка. И дальше забота оператора, на каком управлении протащить ленту — на дистанционном автоматическом однократном, на дистанционном ручном, в конце концов — на местом, прямо со шкафа управления.
ПЛК никакой анализ первопричины не делает. на это у него просто не хватает мощности. Дело ПЛК — по OR/AND собрать сигнал аварии. А уж как образовались отдельные сигналы — дело дежурной смены автоматчиков. Ну и нашего софта.
Разобрались — останов повесят на электриков, приводчиков, гидравликов… не разобрались — на автоматчиков. За 3 часа простоя в месяц по вине службы — премию лишают всю службу. А премия у них равна окладу.
>, зачем переделывать руками типовые задачи — определения первопричины аварии и и графической отладки LAD,
Я повторю вопрос: какой софт умеет определять первопричины аварии?
Ну и заодно — какой софт может проиграть из архива переключения LD по сканам? Не текущее состояние, а архивное, ну скажем 10 сканов перед аварией.
Вы меня простите, но мне реально интересно, кто ещё умеет делать многотактовый анализ? И что именно у них сделано.
Да я вижу, любители придумывать себе проблемы, и героически с ними бороться.
1. Т.е у ПЛК хватает мощности проанализировать массив бит на аварийное состояние. Но при этом скопировать этот массив (а обычно достаточно скопировать 1 бит — ну или байт первопричины) при аварии мощности у него не хватает. Как?
Судя по документации, производительность вашего древнего SYSMAC CV-1000 0.15-0.45ms на операцию. Т.е вам на сохранение состояния при аварии нужно несколько миллисекунд.
2. У вас аварийный останов (шатдаун) стоит 1000000$. Ну так купите ПЛК поновее, дешевле будет.
Сохранять все состояния на каждый цикл и проигрывать их потом не нужно. Нужно правильно написать процедуру анализа аварий и первопричины.
1. Т.е у ПЛК хватает мощности проанализировать массив бит на аварийное состояние. Но при этом скопировать этот массив (а обычно достаточно скопировать 1 бит — ну или байт первопричины) при аварии мощности у него не хватает. Как?
Судя по документации, производительность вашего древнего SYSMAC CV-1000 0.15-0.45ms на операцию. Т.е вам на сохранение состояния при аварии нужно несколько миллисекунд.
2. У вас аварийный останов (шатдаун) стоит 1000000$. Ну так купите ПЛК поновее, дешевле будет.
Сохранять все состояния на каждый цикл и проигрывать их потом не нужно. Нужно правильно написать процедуру анализа аварий и первопричины.
> Но при этом скопировать этот массив (а обычно достаточно скопировать 1 бит — ну или байт первопричины) при аварии мощности у него не хватает. Как?
— Скажите, как мне доехать до рынка?
— Смотрите, где я выйду и выходите на 3 остановки раньше!
В момент загорания лампочки «авария» состояние нужных бит может уже совсем другим. Аварии бывают многотактные, вплоть до 4-5 сканов. 2-3 скана — это норма.
Ну вот смотрите.
Нетворк N1 принимает сигнал I1, P2 и выдает сигналы «Авария1» и P1 (по разным условиям)
Нетворк N2 принимает сигнал I2, P1, и выдает сигнал «Авария 2» и P2 (по разным условиям)
Первый цикл. Приходит сигнал I2, Нетворк N2 вырабатывает P2
Второй цикл — по P2 Нетворк N1 вырабатывает «Авария 1»
Видите, что здесь два скана? И на втором — I2 может уже не быть.
> Нужно правильно написать процедуру анализа аварий и первопричины.
Ну и КАК ваша процедура выдаст результат анализа? По сотне лампочек на каждую аварию?
В системе — 8 тысяч входных сигналов и 2 тысячи выходных. Дюжина контроллеров. Порядка сотни сигналов аварий. Добавить ещё 10 тысяч (по 100 причина на каждую из 100 аварий) лампочек? А если хотим анализировать не аварию?
> У вас аварийный останов (шатдаун) стоит 1000000$. Ну так купите ПЛК поновее, дешевле будет.
Чем это поможет? Авария — это, например, перегорела лампочка на фотоконтроле положения полосы. То есть ли полоса сошла с ролика, то ли лампочка сгорела. Вы думаете при более мощном контроллере лампочки начнут перегорать реже? :-)
Правы вы только в одно — на каждом скане контроллер пишет свое состояние (кроме часто изменяемых служебных переменных) в кольцевой буфер. Который и читает программа формирования архива. А уж из архива — делается анализ первопричин аварии. В том числе — с возможность БЫСТРО (секунды) посмотреть, когда были аналогичные аварии и схожие ли были причины.
— Скажите, как мне доехать до рынка?
— Смотрите, где я выйду и выходите на 3 остановки раньше!
В момент загорания лампочки «авария» состояние нужных бит может уже совсем другим. Аварии бывают многотактные, вплоть до 4-5 сканов. 2-3 скана — это норма.
Ну вот смотрите.
Нетворк N1 принимает сигнал I1, P2 и выдает сигналы «Авария1» и P1 (по разным условиям)
Нетворк N2 принимает сигнал I2, P1, и выдает сигнал «Авария 2» и P2 (по разным условиям)
Первый цикл. Приходит сигнал I2, Нетворк N2 вырабатывает P2
Второй цикл — по P2 Нетворк N1 вырабатывает «Авария 1»
Видите, что здесь два скана? И на втором — I2 может уже не быть.
> Нужно правильно написать процедуру анализа аварий и первопричины.
Ну и КАК ваша процедура выдаст результат анализа? По сотне лампочек на каждую аварию?
В системе — 8 тысяч входных сигналов и 2 тысячи выходных. Дюжина контроллеров. Порядка сотни сигналов аварий. Добавить ещё 10 тысяч (по 100 причина на каждую из 100 аварий) лампочек? А если хотим анализировать не аварию?
> У вас аварийный останов (шатдаун) стоит 1000000$. Ну так купите ПЛК поновее, дешевле будет.
Чем это поможет? Авария — это, например, перегорела лампочка на фотоконтроле положения полосы. То есть ли полоса сошла с ролика, то ли лампочка сгорела. Вы думаете при более мощном контроллере лампочки начнут перегорать реже? :-)
Правы вы только в одно — на каждом скане контроллер пишет свое состояние (кроме часто изменяемых служебных переменных) в кольцевой буфер. Который и читает программа формирования архива. А уж из архива — делается анализ первопричин аварии. В том числе — с возможность БЫСТРО (секунды) посмотреть, когда были аналогичные аварии и схожие ли были причины.
1. Так сделайте анализ каждой аварии в одном скане, а лучше нетворке.
2. Мир вокруг контроллера имеет время реакции. Минимум это 14мс устранение дребезга обычным модулем в/в. Все сканы, что происходят в этот период можно считать за один.Время обработки программы аварийной ситуации в конкретном ПЛК должно быть адекватным развитию аварийной ситуации, которая у вас минута =)
2. Первопричина аварии всего одна — одна авария <= одна первопричина. Один аварийный останов <= одна авария <= одна первопричина. Понятно, что первопричиной может быть набор определенных параметров процесса, но он все равно один.
В общем у вас какая то не АСУшная логика мышления. На сим откланиваюсь, надоело.
2. Мир вокруг контроллера имеет время реакции. Минимум это 14мс устранение дребезга обычным модулем в/в. Все сканы, что происходят в этот период можно считать за один.Время обработки программы аварийной ситуации в конкретном ПЛК должно быть адекватным развитию аварийной ситуации, которая у вас минута =)
2. Первопричина аварии всего одна — одна авария <= одна первопричина. Один аварийный останов <= одна авария <= одна первопричина. Понятно, что первопричиной может быть набор определенных параметров процесса, но он все равно один.
В общем у вас какая то не АСУшная логика мышления. На сим откланиваюсь, надоело.
Простите, сколько было входов-выходов в самой большой системе из запроектированных вами? Надеюсь на честный ответ.
>Так сделайте анализ каждой аварии в одном скане, а лучше нетворке.
Это делается только дублированием кода. На такую оптимизацию программы контроллеров проверяются.
> Все сканы, что происходят в этот период можно считать за один
Время скана 20-50мс. Развитие аварии — 1-5 сканов.
> Первопричина аварии всего одна — одна авария <= одна первопричина.
ДА. Повторю вопрос. КАК ваша процедура выдаст результат анализа? По сотне лампочек на каждую аварию?
Как довести информацию до электриков, гидравликов, приводчиков, химиков, технологов? Через какие механизмы? Ещё раз — у нас 100 аварий и 100 потенциальных причин на каждую. Вы предлагаете 10 тысяч сигнальных лампочек?
> В общем у вас какая то не АСУшная логика мышления.
Не выиграл, а проиграл, не в карты, а в домино…
1) АСУТП довольно сильно отличается от АСУ. АСУ — это «на таком-то стане избыток рулон оцинкованной стали, надо туда подать вагоны под погрузку.» АСУТП — это управление самим станов длиной 500 метров и высотой с пятиэтажку.
2) Программы контроллеры писали не мы, а сотрудники «Северстали». Наша работа — это программа диагностики и архивирования.
3) Логика в том, что лучше иметь универсальную систему анализа, работающую для любых программ контроллера, чем писать свою логику на каждую аварию и меть 10 тысяч сигнальных лампочек.
ЕЩЁ РАЗ. Мне реально интересно, кто ещё умеет делать многотактовый анализ? И что именно у них сделано.
>Так сделайте анализ каждой аварии в одном скане, а лучше нетворке.
Это делается только дублированием кода. На такую оптимизацию программы контроллеров проверяются.
> Все сканы, что происходят в этот период можно считать за один
Время скана 20-50мс. Развитие аварии — 1-5 сканов.
> Первопричина аварии всего одна — одна авария <= одна первопричина.
ДА. Повторю вопрос. КАК ваша процедура выдаст результат анализа? По сотне лампочек на каждую аварию?
Как довести информацию до электриков, гидравликов, приводчиков, химиков, технологов? Через какие механизмы? Ещё раз — у нас 100 аварий и 100 потенциальных причин на каждую. Вы предлагаете 10 тысяч сигнальных лампочек?
> В общем у вас какая то не АСУшная логика мышления.
Не выиграл, а проиграл, не в карты, а в домино…
1) АСУТП довольно сильно отличается от АСУ. АСУ — это «на таком-то стане избыток рулон оцинкованной стали, надо туда подать вагоны под погрузку.» АСУТП — это управление самим станов длиной 500 метров и высотой с пятиэтажку.
2) Программы контроллеры писали не мы, а сотрудники «Северстали». Наша работа — это программа диагностики и архивирования.
3) Логика в том, что лучше иметь универсальную систему анализа, работающую для любых программ контроллера, чем писать свою логику на каждую аварию и меть 10 тысяч сигнальных лампочек.
ЕЩЁ РАЗ. Мне реально интересно, кто ещё умеет делать многотактовый анализ? И что именно у них сделано.
Говоря про графические языки, не упомянули советский
ДРАКОН, для создания систем реального времени управления космическим кораблем «Буран».
ДРАКОН, для создания систем реального времени управления космическим кораблем «Буран».
Про Brainfuck/Befunge вспомнили, но забыли (=<;:^876Z43W10/.-,P*)('K%$H"!~}C{z@xwv<)]rJ%u4V2qC/nQPO*<(gJHGGb!m_BAi>Z=<WP(T
Непорядок :)
Непорядок :)
Забыли написать, что Pascal изначально был учебным языком, после изучения которого предполагалось перейти на ALGOL, но оказалось, что он может с успехом заменять ALGOL.
(а вот BASIC заменить FORTRAN не смог)
(а вот BASIC заменить FORTRAN не смог)
Logo — мой первый язык программирования, изучал его в детстве, даже написал на нем игру "морской бой" на конкурс юных программистов =)))
НЛО прилетело и опубликовало эту надпись здесь
> По мнению «Википедии», язык программирования — формальная знаковая система, предназначенная для записи компьютерных программ.
Поиск по странице фамилии «Тюринг» дает ноль вхождений. Здравствуй, 2016 год. Привет, определения языков программирования из «Википедии».
И да, bf был создан как демонстрация Тюринг-полного минимального языка. А вовсе не потехи ради.
Поиск по странице фамилии «Тюринг» дает ноль вхождений. Здравствуй, 2016 год. Привет, определения языков программирования из «Википедии».
И да, bf был создан как демонстрация Тюринг-полного минимального языка. А вовсе не потехи ради.
Вашу мысль, вынесенную в заголовок «Не все языки программирования одинаково полезны», некоторые формулируют иначе: «Все языки эквивалентны. Но некоторые из них эквивалентнее других».
Надо ли писать/читать столько страниц текста, чтобы обосновать достаточно банальное утверждение " Не все языки программирования одинаково полезны"?
какая от этого практическая/теоретическая польза?
какая от этого практическая/теоретическая польза?
Эх… В 90-х лежал в больнице и писал программы на салфетках, но правда на нормальном ассемблере x86. Сейчас я пожалуй на это не способен.
ADA… Расцвет использования этого языка пришелся на 80-е годы прошлого столетия
Вообще-то язык можно сказать, что жив:
- если C++ = C + объекты
- то PL/SQL = Ada + SQL
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не все языки программирования одинаково полезны