Каждый язык программирования хорош по-своему. Однако с этим утверждением согласятся не все. После прочтения следующего материала ряды несогласных могут пополниться. Более того, есть мнение, что некоторые «конструкции» вообще нельзя считать языками программирования.
По мнению «Википедии», язык программирования — формальная знаковая система, предназначенная для записи компьютерных программ. Язык программирования определяет набор лексических, синтаксических и семантических правил, определяющих внешний вид программы и действия, которые выполнит исполнитель под её управлением.
Какие-то знаковые системы проще для освоения, какие-то сложнее. Однако среди них есть и весьма причудливые. А есть настолько сложные, что осваивают их только самые хардкорные разработчики.
brainfuck
Название данного языка программирования примерно соответствует русскому «вынос мозга». Это язык реально существует. Он был придуман Урбаном Мюллером в 1993 году. С одной стороны, это сделано потехи ради. С другой стороны, brainfuck был создан, чтобы затем разработать для него компилятор размером менее 200 байт — один из самых маленьких компиляторов в мире.
Однако brainfuck также называют и самым непрактичным из когда-либо созданных языков. Сам язык состоит из восьми команд, а программа представляет собой сочетание этих команд. Команды эти исполняются в большинстве своем последовательно.
Если же в программе появлялись символы, не являющиеся командой, они воспринимались как комментарии. А пресловутый «Hello World!» на brainfuck выглядит так:
++++++++++[>+++++++>++++++++++>
+++>+<<<<-]>++.>+.+++++++..+++.
>++.<<+++++++++++++++.>.+++.——.
——--.>+.>.
Чтобы понять, насколько brainfuck оправдывает свое название, можно начать с разбора приведенной выше программы.
Первый шаг – подготовка в памяти (с ячейки 1) массива значений, близких к ASCII-кодам символов, которые необходимо вывести (70, 100, 30, 10). Для этого необходимо произвести 10-кратное повторение приращения содержимого ячеек на 7, 10, 3 и 1, соответственно.
Затем выполняется вывод букв и символов.
...
Befunge
До недавнего времени программы, написанные на Befunge, практически невозможно было скомпилировать. Поэтому можно сказать, что этот язык – злейший враг компиляторов.
Первая версия языка Befunge была создана Крисом Пресси в 1993 году. Как утверждал автор, его целью было разработать язык, максимально сложный для компиляции. Все лексемы языка представляют собой одиночные символы. В Befunge версии 97-го года практически каждый символ является командой.
Befunge отличается от прочих языков программирования, поскольку программа представляет собой двухмерную таблицу, в которой программист может размещать элементы управления, перемещая их с помощью стрелок влево, вправо, вверх или вниз. А эти операции, в свою очередь, сводятся к манипуляции со стеком.
Для примера достаточно взглянуть на код программы «Hello World»:
> v
@,,,,,,,,,,,,"Hello World!"<Однако в программе для генерации случайных чисел разобраться намного сложнее:
Такие программы на Befunge являются отличным упражнением для мозгов. Было бы странно, если бы этот язык вышел на рынок коммерческой разработки. Да и сам создатель Befunge на это не рассчитывал. Ведь разрабатывал он его для других целей. Некоторые могли бы сказать, что это чистое искусство – сложность ради сложности.
Нарочно не придумаешь
Настоящим героям предлагается вспомнить способ программирования в машинных кодах, без ассемблера. Более того, для полного счастья код нужно писать на обычной бумаге. Таким героем был автор следующих (не побоюсь этого слова) строк:
Недавно в сети появились фотографии рукописных исходников кода, которые были написаны в начале 1980-х. Их опубликовал сайт The Codeless Code. Разработчик писал этот код для программы, которую нужно было запустить на персональном компьютере Apple II, также известном как Apple ][.
Недоверчивые читатели могут подумать, что это просто «извращение». Однако в некоторых ситуациях реальные задачи, которые приходилось решать без использования ассемблера, решались в то время именно так. Исходный код писался на бумаге и затем, по мере ввода, переводился в шестнадцатиричную систему.
Поэтому если вы вдруг заподозрите себя в излишней требовательности к работе какого-то IDE, то в качестве «прививки» попробуйте решить следующую задачу, вооружившись карандашом и бумагой.Задача приведённого в примере кода — рисование текста с заглавными и строчными буквами на экране высокого разрешения. «Шрифты» создавались программистом на графической бумаге и затем вручную переводились в байты, которые хранились в области данных.
Правда, запросы к библиотеке шрифтов создавались не на бумаге, а на Applesoft BASIC (диалекте MS BASIC) при помощи специальной последовательности символов в текстовой строке. Например:
100 PRINT "&F2&B&H3&W2Hello, world!"Такая команда позволяла выбрать шрифт #2, жирный, с тройной высотой, двойной шириной, и напечатать «Hello, world!» в месте нахождения курсора. Похожие команды позволяли менять цвет текста, и даже назначать разные цвета соседним столбикам символов, таким образом создавая иллюзию использования несуществующих в Apple ][ цветов — например, бирюзового.
Для начинающих
Если же быть немного скромнее, чем «художник», упомянутый выше, и не ловить звезд с неба, то машинный код для «Hello World» будет выглядеть так:
BB 11 01 B9 0D 00 B4 0E 8A 07 43 CD 10 E2 F9 CD 20 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21В более читабельном виде то же самое можно записать, используя мнемонические команды языка Assembler:
CODE SEGMENT
ASSUME CS:CODE, DS:CODE
ORG 100h
START:
mov ah,9
mov dx,OFFSET Msg
int 21h
int 20h
Msg DB 'Hello World',13,10,'$'
CODE ENDS
END START
К слову, Assembler по-прежнему востребован, хотя и не является модным языком программирования высокого уровня. А вот многие более современные языки канули в лету. Некоторые забылись окончательно, а у некоторых еще есть шанс оказаться полезными в современных реалиях.
Чтобы помнили
В Bloomberg решили вспомнить некогда великие, а теперь полузабытые языки программирования. Все они появились еще в 50-х годах прошлого столетия. К каждому из них, как своеобразную дань уважения, подобрали лингвистический эквивалент из числа естественных языков человеческого общения. Правда, критерии, по которым сопоставлялись языки, остаются загадкой.
1. ALGOL
Создан в 1958 году. Название происходит от сокращения словосочетания «алгоритмический язык» — Algorithmic Language. Над ним трудилась группа европейских и американских компьютерных экспертов. Годы его расцвета — 1958–1968.
Использовался для научных вычислений. Это был фактически первый эксперимент по созданию языка, который можно применять на различных платформах. Оказалось, что он больше подходит для лабораторных вычислений, чем для коммерческих приложений, поскольку в исходной форме язык не поддерживал никаких протоколов ввода-вывода.
BEGIN
FILE F (KIND=REMOTE);
EBCDIC ARRAY E [0:11];
REPLACE E BY "HELLO WORLD!";
WHILE TRUE DO
BEGIN
WRITE (F, *, E);
END;
END.
Лингвистический эквивалент: классический древнегреческий.
2. COBOL
Создан в 1959 году. Название является аббревиатурой для Common Business-Oriented Language. Над ним работала крупная группа, в которую входила и пионер компьютерных наук Грейс Хоппер, известная в том числе и как создательница термина «баг». Период расцвета COBOL — 60-80 годы. Тогда он использовался для крупных корпоративных систем (страховка, банки и т.д.).
Сегодня его до сих пор учат в некоторых школах. А в 2000 году финансовые учреждения должны были вызывать знатоков COBOL из отдыха на пенсии, чтобы пофиксить «проблему 2000 года».
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO-WORLD.
* simple hello world program
PROCEDURE DIVISION.
DISPLAY 'Hello world!'.
STOP RUN.Сравним с церковной латынью.
3. PL/I
Создан в 1964 («релиз» состоялся в 1969 году). Название расшифровывается как Programming Language One. Над ним работала группа экспертов IBM. Пик славы — ранние 1970-е.
Использовали для мейнфреймов IBM System/360, которые в свою очередь служили в очень разных областях — от бухгалтерии до астрофизики. Был создан, чтобы потеснить COBOL, FORTRAN и другие языки того времени. Намного шире использовался в СССР, чем на Западе. Утратил популярность в 1970-х, поскольку был признан слишком ресурсоемким и сложным. Но учитывая доминирование IBM в те времена, достаточно много всего, написанного на PL/I, существует до сих пор.
HELLO: PROCEDURE OPTIONS (MAIN);
/* A PROGRAM TO OUTPUT HELLO WORLD */
FLAG = 0;
LOOP: DO WHILE (FLAG = 0);
PUT SKIP DATA('HELLO WORLD!');
END LOOP;
END HELLO;Сравним с церковно-славянским.
4. PASCAL
Создан в 1968 году швейцарским ученым Никлаусом Виртом, назван в честь математика Блеза Паскаля. Годы расцвета — 1980-е. Самый популярный наследник ALGOL, использовался в том числе для программирования под ранние версии компьютеров Apple.
Популярная версия от 1983 года называлась Turbo Pascal. Сейчас используется для преподавания, но намного реже, чем лет 30 назад.
program HelloWorld;
begin
WriteLn('Hello, World!');
end.Лингвистический эквивалент: эсперанто.
5. LISP
Создан в 1958 году Джоном МакКарти, название — сокращение от List Processing. Расцвет его пришелся на 60-е годы прошлого столетия. Чаще всего использовался для разработки систем искусственного интеллекта, в системах ПВО, причем в AI-разработках используется и поныне.
(PRINT '«HELLO, WORLD!»)
Можно сравнить с санскритом.
6. APL
Созданный в 1962 году, назван сокращением от скромного «A Programming Language». Его создатель — Кен Айверсон, которому за эту разработку дали премию Тьюринга. APL был очень популярен в 60-х. Чаще всего использовался в прикладной математике. Известен предельной простотой и ясностью синтаксиса. Минусы: требует наличия греческого алфавита и других специальных символов. Читается при этом справа налево (как иврит, например).
Сегодня нечасто, но все же используется, в очень узкоспециальных нишах — к примеру, в расшифровке ДНК, и как ни странно, в теории бухучета.
@ This program is very simple in APL!
'Hello World!'
@ In APL, anything that is printed in quotes is printed to the terminal. (@ in APL signifies a comment)
@ If the "Hello World statement needed to be stored, then you could use the following :
h<-'Hello World'
h
@Typing h causes h's value to be printed to be printed.Можно сравнить с языком Навахо.
7. FORTRAN
Разработан в год полета первого искусственного спутника Земли, называется сокращением от Formula Translator. Его создал для IBM Джон Бэкус. Пик популярности — 60-70 годы.
Использовался, да и продолжает использоваться поныне для научных вычислений.
program hello
print *, "Hello World!"
end program helloМожно сравнить его с английским языком версии Джейн Остин.
8. LOGO
Название — от древнегреческого «логос», то есть «слово» или «мысль». Создан в 1967 году Сеймуром Пейпертом и группой под его началом в лаборатории искусственного интеллекта при MIT. Изначально использовался, чтобы обучать программированию детей, и до сих пор используется в этих целях. Одна из версий работает с платами Arduino.
PRINT [Hello world]Сравним с системой знаков в аэропортах.
9. ADA
Назван в честь математика Ады Лавлейс, написавшей первую в мире программу. Расцвет использования этого языка пришелся на 80-е годы прошлого столетия, в основном он был полезен военным и в системах контроля воздушного сообщения. В обозримом будущем Ada будет оставаться в этих системах благодаря своей исключительной надежности.
with Text_To; use Text_To
procedure hello is
begin
put("Hello World");
end hello Сравним с американским английским, с легким налетом аппалачского.
Комментарии (154)
FSA
07.09.2016 19:35Я в своё время начинал изучать программирование переводя вручную в машинный код на ZX-Spectrum. Потом открыл для себя Zeus. А написать по памяти программу для копирования блока кода из одной области памяти в другую вообще без справочников мог :) Например, загрузить картинку в память, а потом вывести его быстро на экран.
mkarev
07.09.2016 20:33У меня был такой набор
— Ассемблер GENS4-51 (у когорого 51 символ в строке вместо дефолтных 32-х)
— Монитор/отладчик MONS4
Ну и, конечно же, The Complete Machine Code Tutor — обучающая программа по архитектуре и системе команд процессора Z80
Дизассемблировал заставки к играм и записывал карандашем в тетрадку код понравившихся эффектов.
Помимо спектрумовского асма в памяти жив легендарный Laser Basic — расширение для системного бейсика, вешающее свой хук на обработчик ошибок и расширяя таким образом синтаксис базового языка примитивами для работы с графикой (спрайты и т.п.)
DmitryMry
07.09.2016 22:15+1Да что машинные коды — многие даже количество тактов почти каждой команды процессора наизусть помнили (ну это уже позже было, когда демо-сцена расцветала и стала появляться нормальная документация по процессорам и асму). А так — да, и на бумаге программы нередко писать приходилось, и графику на «миллиметровке» карандашом рисовать, а затем попиксельно переводить, и много других вещей.
FSA
12.09.2016 18:47Было такое. Изучал как на магнитной ленте данные хранятся. Разгадывал загрузчик Веременнеко, а также загрузчиков со шкалой. Каждый такт приходилось выверять. Потом сделал турбозагрузчик, когда каждый бит был заложен в положительный или отрицательный импульс. Не знал я тогда, что при скважности отличной от двух спектр импульса шире… Но тогда хватило, а потом учиться уехал.
vadimr
12.09.2016 21:51На Apple ][ не было таймера, все задержки измерялись выполнением команд процессора, поэтому такты надо было помнить обязательно.
UA3MQJ
07.09.2016 20:13+1Люблю Паскаль. За плечами кружок программирования в школьные годы. Привет в Рыбинск, Дмитрию Аргову.
Кстати, надо с отступами.
program HelloWorld; begin WriteLn('Hello, World!'); end.
ru_vlad
08.09.2016 00:27-1Полностью согласен!
Лучшего языка для начинающих пожалуй не придумали.
Вирт ГЕНИЙ!
Как учитель уже выпустивший не один десяток учеников которые пошли по данному профилю, могу сказать, Паскаль жив и еще много хорошего сделает.
Хотя сам начинал с маш кода.Idot
08.09.2016 06:23-2Лучшего языка для начинающих пожалуй не придумали.
А как же Delphi, являющийся развитием Паскаля?ru_vlad
08.09.2016 08:09Вы можете меня побить ;) но Дельфи это не язык, а среда разработки на основе Паскаля.
Да, я знаю есть отличия, есть дополнение итак далее. Сам на нем создавал коммерческие приложения, но для начинающих лучше все классика-Паскаль :)Idot
08.09.2016 08:14Дельфи принципиально отличается тем, что у него парадигма Событийно-Ориентированного Программирования.
zagayevskiy
08.09.2016 09:45У вас устаревшее на лет 15 представление о мире. Delphi — это язык.
sbnur
08.09.2016 11:15-1конечно — раз есть дельфийцы, то должен быть язык, на которм они общаются
Но я часто думаю, являются ли дельфийцы подвидом программистовPakos
08.09.2016 12:57Интересно, а кто?
Код писать можно на чём угодно, «Делфи — это визуальные формочки» — это явно от знакомства со школьными хэллоуворлдами. Примерно как ПХП — если порог вхождения позволяет школьникам ваять недосайты, то это не значит что на нём нельзя делать проекты. На сях тоже индусского кода более чем (весь код в h-файле, например). И таки-да, Delphi — это название языка уже много лет как (с 7 версии).sbnur
08.09.2016 13:09-1кто является подвидом? не совсем понял
Просто для меня дельфийцы — это некоторая окукленная секта адептов — хуже нет на фрилансе встретить предложение поддержки и развития проекта на Дельфи
Например, у 1с-шников на форумах возникают мысли — а программист ли я — у дельфийцев таких мыслей не возникает,
А писать можно на чем угодно, даже на коленкеmihailfilatov
09.09.2016 11:34>Например, у 1с-шников на форумах возникают мысли — а программист ли я
Мысль возникает поскольку многие программисты 1С занимаются программированием на 1С процентов 20 времени, остальное время это постановка учета, консультации, написание схем бизнес-процессов, ковыряние в проводках и куча других вещей из смежных областейsbnur
09.09.2016 11:47e 1c-шников отличительное свойство (отличная черта, к слову) — прямое сращивание с предметной областью.
fishca
09.09.2016 15:36каким бы ты ни был гениальным разработчиком, без знания нюансов предметной области ничего не выйдет
правда можно завелосипедить гениальный велосипедsbnur
09.09.2016 16:13а в этом и есть спиральность развития — гениалить гениальный велосипед
To developers — update, update and update
Pakos
09.09.2016 16:21Скорее низкий порог вхождения позволяет за 3 копейки нанять эникея, который потом забросит продукт (или «продукт»), а заказчик захочет продолжения и ищет кого бы нанять. Обычно это фрилансеры, т.к. на пару формочек брать кого-то на полный рабочий дорого.
sbnur
09.09.2016 16:28Другими словами нормальный язык должен иметь высокий порог вхождения — согласен — язык должен быть профессиональным, то есть применять его должен именно профессионал — а вот какие языки удовлетворяют этому требованию?
Pakos
09.09.2016 16:42И будет им пользоваться полспециалиста на миллиард, ибо мало кто будет изучать на других проектах. Сложность освоения — порог вхождения велик, кадры безумно дороги и невосполнимы, библиотек нет, ибо нет сообщества. Нужен ли для реальных проектов такой профессионал? Лучше уж взять делфиста с хорошими навыками и опытом в нужной/разных сферах, чем такое непонятное чудо. Конкретный выбор зависит от проекта.
sbnur
09.09.2016 16:52а почему именно дельфийца, а не яванца, шарпея, сипласа, питона идругих славных предстамителей проектной разработки
Siemargl
08.09.2016 10:17+1Развитием Паскаля является Oberon и Component Pascal. А Дельфи (Object Pascal) является модной в то время ООП-коммерциализацией языка.
Idot
08.09.2016 20:25-1Я бы сказал, что:
— Оберон — разработка теоретиков, оказавшаяся оторванной от реальной жизни и потому не взлетевшая;
— Дельфи — очень удобный прикладной язык.
Vjatcheslav3345
08.09.2016 12:35А компонентный паскаль? Как он на практике и в обучении?
Siemargl
08.09.2016 13:00На практике не взлетел, в обучении чуть сложнее обычного паскаля — добавлены модули и методы. Синтаксис (32 страницы) гуглить component pascal language report. Аналогично для Oberon
Idot
08.09.2016 13:04А ещё была Modula — тоже как развитие Паскаля, и то же не взлетела. Оказалось, что наиболее полезные фишки Модулы легче добавить в Паскаль, чем переходить на Модулу.
Vjatcheslav3345
08.09.2016 15:19Вообще слышал что компонентный паскаль — супер-пуперский, объектный, минималлистичный и надёжнейший язык — типа гибрида стилета с танком. Насколько это действительности соответствует?
И ещё — вроде бы языки движутся с десятилетиями в сторону доказательного программирования — компонентный паскаль пригоден для такого программирования?
woodhead
08.09.2016 12:53+1Очень люблю Pascal и до сих пор на нём активно пишу (Lazarus/Delphi).
Но вот с дочкой в качестве первого языка всё-таки выбрали Python (Scratch не в счёт).ru_vlad
08.09.2016 13:17Нормально и правильно!
Тысячный раз повторю, Паскаль хорош как алгоритмический язык для первоначального обучения для детей примерно с 6-7 класса.
Если же алгоритмические структуры и основные понятия изучили раньше например на Scratch или Logo то разумней переходить на более взрослые языки Python, Java, C++.
AndreyDmitriev
07.09.2016 20:24+1Если кто-то считает, что есть «отстойные» языки, то он просто не постиг Дао программирования. То, что оказывается ненужным, просто отпадает само по себе. У любого языка есть свой «жизненный цикл», своя ниша. Я учился на Фортране, был Паскаль, Си, все они прекрасны. Нет «плохих» языков.
Сейчас я программирую на LabVIEW, и это выглядит вот так:
Формально этот код эквивалентен
int result = 0; for (int i = 1; i < 1000; i++) { if (((i % 3) == 0) || ((i % 5) == 0)) { result += i; } }
Для меня это тоже язык программирования, хоть и графический, и ничуть не конфликтует с C#, который я изучаю в свободное время.DistortNeo
08.09.2016 00:53-1Для понимания графически изображённых алгоритмов нужны специальным образом повёрнутые мозги. Видимо, на них и ориентированы такие языки. Был период, когда визуальное программирование преподносилось как способ снижения порога вхождения в программирование — вот этого я на понимал.
Вот смотрю я на код — сразу всё понятно, на изображение — приходится должно въезжать. Аналогично приходится взрывать мозг, когда вижу UML. И это не привычка — со школы блок-схемы не воспринимаю. Хардварные реализации (радиоэлектроника), кстати, тоже не понимаю.AndreyDmitriev
08.09.2016 09:43У меня всё наоборот — текстовый код я воспринимаю значительно хуже (речь не идёт о коротких листингах, но если в проекте несколько десятков тысяч строк, то мне требуется заметно больше времени для понимания, чем в сравнимом по сложности LabVIEW проекте).
Вообще навык читать и создавать такие диаграммки приходит довольно быстро — через две недели оно уже не вызывает отторжения, через два месяца начинаешь свободно понимать чужой код, через два года перестаёшь понимать код текстовый.
Вообще каждый язык хорош по своему, но в той области, в которой я работаю (автоматизация производства и машинное зрение в области рентгеновского неразрушающего контроля) на LabVIEW разработка идёт значительно резвее — я с такой скорость даже на Дельфи не программировал (сравнимые по сложности продукты). Ну и по образованию я физик-электронщик, для меня диаграммки и схемы всегда были понятны.
Antervis
08.09.2016 11:31немного не так. У многих инженеров постарше хорошо развито системное мышление, но языки программирования они если и застали, то мельком. Поэтому им программировать квадратиками и кружочками проще
AndreyDmitriev
08.09.2016 14:06В основном вы правы, но, наблюдая за такими инженерами (хорошими, кстати) я вижу, что они довольно легко «входят» в эти кружочки и квадратики, но довольно быстро упираются в растущую сложность проектов, когда системное мышление уже не помогает, а требуются фундаментальные знания в разработке ПО, те же паттерны проектирования, хорошее понимание ООП, которых у них просто нет, ввиду того, что они застали классические языки «лишь мельком».
Я бы ни в коем случае не начинал изучение программирования с LabVIEW — тут простота кажущаяся и программист должен быть сформировавшийся, с окрепшей психикой.Antervis
08.09.2016 14:14+1я думаю, изначально идея была дать таким инженерам возможность делать что-то самостоятельно, без программиста-посредника или курсов программирования
ogoNEKto
08.09.2016 01:37+1LabVIEW сравнивать с текстовыми языками — это как китайский с английским)))
А вообще + за упоминание. И если идти путем LabVIEW, который печатание текста превращает в рисование алгоритма, то следующая стадия в программировании это «компьютер, включи плиту, разбей на сковороду яйцо и жарь 5 мин». Лет так через 20 называться это будет «программирование рецепта завтрака».AndreyDmitriev
08.09.2016 11:39+1Сравнение с китайским — прекрасно! 20 лет — это довольно оптимистичный прогноз, я полагаю и через 20 и через 50 лет текстовые языки будут использоваться в полный рост. Однако лет этак через 100-150 процесс разработки ПО будет выглядеть совсем иначе — тут я не сомневаюсь. Графическая парадигма имеет свои плюсы, но в данный момент несколько опережает время, системы контроля версий не заточены под эти файлы, нет стандартов, и т. д.
Antervis
08.09.2016 14:16имо лучше если программы останутся в текстовом виде. Пусть лучше по тексту рисует графическое представление, если кому-то так нагляднее. Возможно, блок-схемы нагляднее текста для понимания кода. Но писать код куда быстрее, чем раскидывать кружочки
Idot
08.09.2016 14:32Блок-схемы очень красиво смотрятся на презентациях и прочих документов, а вот рисовать их — очень неудобно. Даже в Visio — намного медленнее и тормознее, чем писать код руками. Потому, когда мне в каком-нибудь документе нужно наглядное отображение алгоритма, то я использую структограммы Несси-Шнейдермана, благо их очень легко создавать в Word используя самые обыкновенные стандартные таблицы.
Alexeyslav
08.09.2016 17:09На стандартной клавиатуре, без хоткеев это конечно же ад!
Для таких «наглядных» языков необходимо подключать дополнительную клавиатуру с программируемыми клавишами забиндеными на нужные хоткеи.
Основная проблема визуального программирования — необходимость часто переключать режимы работы и выбирать необходимый инструмент — наглядная клавиатура решит эту проблему и останется только одной рукой елозить мышкой(не отрывая руки) по делу а не в меню.Idot
08.09.2016 19:54Не все любители учить сотни биндов наизусть.
А насчёт специальной клавиатуре — это к APL. Потому что, например, в Delphi можно добавлять новые визуальные компоненты, а у обычной не виртуально клавиатуры — количество клавиш ограничено.Alexeyslav
08.09.2016 21:16Так для этого и дополнительные клавиатуры. Как-то давно видел клавиатуру специальную для 3Dmax, AutoCAD и т.п. с аналоговыми крутилочками и доп. клавишами для удобной навигации в 3D.
А обычные кнопочные, как на кассовых аппаратах бывают и по 100 клавиш, свои изображения можно повставлять настроить и пользоваться — она распознается как стандартная USB-клавиатура.
Недавно статья по ним была на хабре.
Есть ещё клавиатуры-доски для драм-машин, они ко всему прочему могут подсвечиваться индивидуально любым из 16млн цветов, но эти совсем в цене…
Даже 100 кнопок это будет уже перебор — вы же не всегда пользуетесь 100+ объектов и режимов одновременно. Обычно же не больше 20 избранных часто используемых режимов и объектов.
AndreyDmitriev
09.09.2016 09:09Если говорить о LabVIEW, то постоянное переключение было необходимо лет этак десять назад. В настоящее время есть QuickDrop, есть настраиваемые хоткеи, а режимы уже переключаются автоматически.
Ну вот, к примеру, если требуется построить графики синуса и косинуса для сотни элементов, то процесс «рисования кода» с использованием QuickDrop как-то вот так выглядит:
под спойлером анимированная гифка чуть больше мегабайта
Antervis
09.09.2016 09:02я немного не так выразился, наверное. Я предположил утопию, в которой SDK будет на основе текста кода генерировать все эти блок-схемы, чтобы можно было мельком глянуть что где и как работает, а сам код править в виде текста.
AndreyDmitriev
09.09.2016 12:44Ну в идеале это должно в обе стороны работать — я могу разрабатывать что-то в графическом виде, при этом всегда иметь возможность переключиться в текстовый человекочитаемый текст, поправить что-то там, и это отобразилось бы в виде графическом и т. д. В настоящее время я могу только в графическом виде работать, оттого системы контроля версий, заточенные под текстовые файлы и не понимающие двоичный формат, в котором хранится моя диаграмма, не могут отобразить мне изменения.
ZyXI
09.09.2016 23:02Я не представляю, как должен выглядеть 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 — не знаю. Да и задача более сложная.
ru_vlad
08.09.2016 13:22А почему бы и нет ;) только думаю не через 20, а уже лет через 5 :)
Если вспомнить что было 20 лет назад и сейчас, то думаю не все тогда поверили что такое возможно так скоро.
ZyXI
08.09.2016 08:36+1Мне приходится писать на LabView сейчас, и это ужасно. Дольше оформляется «красиво», при попытке что?то абстрагировать в VI вылезают какие?то баги (пытался разнести «код» инициализации/открытия FPGA, считывания из него значения и закрытия в три VI, так вторая со считыванием в упор не видит обновлений в VI FPGA), неясно где что вообще исполняется (три общих варианта: процессор MyRIO, его же FPGA и компьютер с labview, в первом случае ещё и подварианты (процессора (точнее, ядер) два, вроде есть потоки и процессы)), неясно, когда, как и на что выделяется память, неясна потокобезопасность различных конструкций (смотрел пример с погодным сервером на RT, не понимал, как такое вообще можно было придумать: очередь это VI с циклом, исполняющимся один раз; цикл нужен, чтобы хранить переменные в shift register — по моему мнению, они, вообще?то, должны пересоздаваться при каждом обращении, а реально очередь можно использовать из обработчика http запроса, который неясно где вообще исполняется (но не думаю, чтобы в одном потоке с главным циклом, эту очередь использующим)). И ещё, diff вы не получите.
В общем рисовать в LabView долго — дольше, чем печатать после предварительного обучения. Узнать, что изменилось нельзя не только при помощи VCS, но даже и средствами LabView (как?то посмотрел, чем объясняет LabView необходимость сохранения). Понять, как работает то, что вы нарисовали сложно. Единственный плюс — первые несколько прошивок для FPGA на каком?нибудь VHDL я писал бы дольше, чем рисовал её же в LabView. Но только первые несколько.
Antervis
08.09.2016 11:28+1графические языки очень малопроизводительны. Набрать приведенный экивалентный код намного быстрее, чем накидать все нужные элементы, установить связи и параметры.
Idot
08.09.2016 11:50В Delphi интерфейс и подключения к база данных — быстрее всего сделать графическим способом.
Antervis
08.09.2016 14:12Работать с данными то потом всё равно из кода
Idot
08.09.2016 20:20И такой подход разумен: делать визуально — то что быстрее и удобнее делать визуально, и кодить — то, что быстрее и удобнее кодить.
AndreyDmitriev
09.09.2016 09:13Да, согласен. В принципе и в LabVIEW никто это не запрещает делать — можно комбинировать графический и текстовый код, тогда пример выше будет выглядеть как-то вот так:
AndreyDmitriev
08.09.2016 14:25+2Пару лет назад на хабре при обсуждении спагетти-ориентированной разработки, коллега ttools задал вот такую задачку:
Я бы хотел посмотреть, как бы вы красиво выполнили код такой несложной задачи, вполне практической: Имеется 30 датчиков одинакового типа, каждый датчик в реальном времени выдает 4 параметра, допустим float ток и напряжение и два boolean параметра: датчик исправен и датчик включен. Надо отобразить показания всех датчиков на одном экране, допустим 3 ряда по 10 слева направо, сверху вниз, в виде 2 танков (ток, напряжение) и 2х подписей (включен/отключен, исправен/ неисправен) на каждый датчик. Данные от датчиков можно эмулировать любыми функциями от времени и индекса датчика.
На Delphi, например, эту задачу я могу выполнить за полчаса, красивым кодом, с короткими методами. Сколько времени уйдет, чтобы сделать это на LabView и насколько это получится красиво и без лапши?
На что я ответил вот таким пятиминутным видео:
potan
07.09.2016 20:48+4Ну как же тут было Prolog не вспомнить?
Escalibur
08.09.2016 09:18+1Prolog, кстати, до сих пор уникален.
Просто тупо нет нормальных систем программирования логического вывода. Это или библиотеки или какая-то неадекватная система запросов в OWL.
Prolog был и остается идеальным языком для программирования сложной логики, правил и прочего такого. Сейчас все чатботы должны на нем писаться.
Разумеется, не нужно маяться фигней и делать на Prologе интерфейсы или работу с БД. Он для этого просто не предназначен. Его нужно использовать для подсистемы логического вывода, для чего он и создан.Idot
08.09.2016 10:22Классический Пролог поддерживает исключительно только Бинарную Логику. Для вещей посложнее лучше что-нибудь вроде Fuzzy Prolog с поддержкой Нечёткой Логики.
potan
08.09.2016 10:32+1В принципе есть Mercury (хотя он не все умеет) и Curry, но они все еще маргинальны.
Меня удивляет, что в современных версиях Prolog почти не внедряют программирование в ограничениях. Появись такая поддержка, этот язык стал бы более востребован (пока его роль выполняют всякие солверы), да и программировать на нем стало бы легче (меньше неожиданных эффектов от изменения порядка предикатов).Idot
08.09.2016 12:15есть Mercury (хотя он не все умеет) и Curry
Не напишете про них ознакомительные статьи?potan
08.09.2016 19:14+1Заманчивая идея…
Я тут наткнулся на имплементацию языка LIFE. Разберусь с ним, смогу написать обзор о языках логического программирования.Idot
08.09.2016 19:20Буду рад почитать!
Escalibur
10.09.2016 11:14Да, было бы интересно!
Пролог уже давно, как я понимаю, не классический. Он довольно серьезно развился с тех времен, но его тупо не изучают и, соответственно, не применяют. При этом, этот язык стоит учить хотя бы для развития мышления. Он вроде тех же функциональных языков программирования — они более трудно усваиваются, но зато затем позволяют реализовывать сложные алгоритмы весьма изящно и коротко.
Популярность процедурных языков, я считаю, обусловлена их низким порогом вхождения, но зато потом люди платят за это многими часами напрасного труда.
Вообще, да, я считаю, что для каждого домена должен быть свой DSL. И системы должны писаться из небольших кусочков, обменивающихся сообщениями. А сами кусочки уже должны быть реализованы на наиболее подходящем DSL.
mkot
07.09.2016 21:39+10Я поставил минус, потому что не понял для чего эта статья, просто набор слабосвязных фактов. Какие выводы нужно было сделать после прочтения?
IvanCher
07.09.2016 22:41+2Понимаете, это как коллекция антиквариата с записками кто и зачем это сделал.
Каждый смотрит на эту коллекцию и видит своё: кто-то восхищается создателями, кто-то усмехается — «Как же таким можно было пользоваться», у кого-то прокатывается глубоко внутри ностальгия и вспоминается школьная любовь… эх…
Если бы мог плюсануть, наплюсовал бы! :)
unixwz
08.09.2016 12:52Эта статья для того, что-бы мы вспомнили каким тёплым и ламповым был ассемблер. Только гляньте на эти листочки (выше), становится сразу так тепло...
nikitadanilov
07.09.2016 22:20+1На отсканированных листочках «программирования в машинных кодах, без ассемблера» не видно, там обычный ассемблер.
Кроме того, Алгол-68 (на котором приведен пример) и Алгол-60 это совершенно разные языки.vadimr
08.09.2016 00:00+1На бумажке – условные переходы без меток, адреса переменных в числовой форме, и ниже – список адресов команд, составленный вручную. То есть автор сначала писал машинные команды в символической записи, а потом переводил их в машинный код вручную. Короче, представлен исходный материал для ручного ассемблирования.
В случае использования ассемблера там стояли бы символические адреса.
sbnur
07.09.2016 22:39В силу своего возраста мне довелось начать обучение (в вузе конечно) с машинных кодов, потом был алгол, потом фортран
Потом все остальные языки типа pascal, с/с++, разные варианты бейсика, java, c#, php, actionscript и др., которые использовались профессионально, то есть для реализации оплачиваемых проектов.
Некоторые языкм изучались для души типа Пролога или Лого, но профессионально не применялись.
Какой лучше или хуже — вопрос бессмысленный — лучший язык для программиста тот, на котором он лучше всего программирует
Не знаю как в Википедии, но вообще-то язык программирования — это средство записи алгоритма.
Если получается быстро и компактно записать нужный алгоритм решения поставленных задач в данной предметной области, то это и есть лучший для тебя язык
Хуже, когда приходишь на проект, созданном на чужом языке — это все равно, что попасть в центр Монголии, зная всего три монгольских слова — богатырь, деньги, тьма
Поэтому лучше не думать, что лучше, а учить, пока не станет лучше
Idot
08.09.2016 06:57вообще-то язык программирования — это средство записи алгоритма
Это Императивные языки, в Декларативных языках, включая (чистые) ФП, алгоритм не записывается.sbnur
08.09.2016 07:03и что же декларируется в декларативных языках — именно они (декларативные языки) алгоритмичны по своей сути)
Alexeyslav
08.09.2016 10:51Всё-таки не соглашусь с таким определением. Это не средство записи алгоритма. Тут скорей применима аналогия что язык — это алфавит и правила написания алгоритма.
Средство написания алгоритмов — это IDE и набор библиотек к конкретному компилятору языка программирования.sbnur
08.09.2016 11:13несогласие — дело личное
Но любой алгоритм — это описание, для чего и нужен язык
Алгоритмы не требуют иде и прочего — но описать можно на только неком языке, что было изложено еще в труде аль Хорезми — Китаб мухтасаб аль-джабр и ва-ль-мукабала, где были описаны способы формализации описаний решения. Данное понятие алгоритма из этой книги попало в Европу (алгоритм и есть измененная фамилия автора)
Survtur
07.09.2016 22:40+1Разве надежность — свойство языка? Вроде бы хелловорд на бейсике не менее надежен, чем на аде…
dizjis
07.09.2016 22:41Чем паскаль то не устроил? Нормальный язык. Приучает сначала подумать (объявить переменную), а потом сделать. Вместо мусора в коде со 100500 переменными, которые объявлены черте где по месту и кучу раз перекрываются и в первый раз она указатель на объект, а во-второй раз там количество итераций цикла. И потом всю эту кашу кому-то разбирать)
goral
07.09.2016 22:41В детстве читал книгу «А я был в компьютерном городе» и там приводили пример «программы» на машинном языке (в двоичном коде). Понял что это значит много лет спустя только в институте, когда, как встатье, писали программы на ассемблере, потом переводили их в двоичный код, затем в 16-ричный и наконец-то вводили в ячейки памяти учебного микропроцессорного комплекта (УМК) на базе КР580ИК80А. Здорово помогло для понимания процесса.
fishca
07.09.2016 22:41+2Пришлось в институте попрограммировать в машинных кодах на такой УМК-е
http://www.computer-museum.ru/histussr/umk_sorucom_2011.htm
igor_suhorukov
07.09.2016 23:15А у нас в универе был стенд на К1804 и лабу по разработке микропрограмм делал, которую с помошью кнопок в ОЗУ набирали.
Alexeyslav
08.09.2016 10:56Точно, она самая… и процессор там использовался отечественный, выполненный по технологии без диэлектрика на подложке — все транзисторы на кристалле отделялись обратно смещёнными pn-переходами, отчего процессор требовал 3-х различных напряжений питания и строгую последовательность их включения иначе срабатывал тиристорный эффект и выгорала часть кристалла протекающими токами КЗ.
VadimPanov
07.09.2016 22:41Мдя, было время… Я в своё время для Орион-128 (который в моём исполнении превратился в Орион-512) написал дипломный проект (программа-проверялка исправности логических микросхем ТТЛ/КМОП, работавшая через железяку собственного изготовления, подключенную к параллельному порту), а так же программатор ПЗУ (железо опять же своё) с псевдографическим интерфейсом (вложенные менюшки, рамки, просмотр «прошиваемых» данных в шестнадцатеричном и графическом виде и прочее). Писалось всё даже не на ассемблере на бумаге, а прямо в машинных кодах в шестнадцатеричном редакторе. Я даже сейчас не понимаю, как мне удавалось создаваемый код в голове удерживать… Таблицу команд в кодах помнил ещё лет 15 наверное.
DistortNeo
07.09.2016 23:32+2Я бы к этому списку ещё добавил Perl — любимый язык мастеров обфускации.
vadimr
08.09.2016 00:17+2Программа на PL/I выдаёт очень поверхностное знание этого языка.
1. В конструкции DATA могут содержаться только имена переменных, поэтому такая программа вызовет ошибку при компиляции. Должно быть PUT SKIP LIST ('HELLO WORLD!');
2. Переменная FLAG, будучи описанной по умолчанию и обладая именем, начинающимся с буквы F, имеет вещественный тип, поэтому не очень осмысленно, хотя и возможно, сравнивать её с целым нулём и использовать в качестве флажка. Также не очень понятен бесконечный цикл, организованный таким образом.
3. Инструкции должны записываться не менее чем со второй позиции, коль скоро речь про IBM.
;)VitalyAstro
08.09.2016 01:37+3Мартовский файл
Снова ветреный март
Рассыпает капель,
В штабелях перфокарт
Похоронен PL.
Ничего, я привык,
Я до вас доберусь,
Благородный язык
Заучу наизусть!
Мы пойдём GO TO,
Раскопаем GET LIST,
Будут EDIT и DO,
Будет DEC FIXED,
ZERODIVIDE,
IF ENDFILE THEN REPEAT,
ON TRANSMIT VERIFY,
(X) DCL SYSPRINT.
Чтоб в метель, в холода
Сердцем правил апрель — Ты со мной навсегда,
Мой любимый PL!
1989 © S. Borodatoff
kanikeev
08.09.2016 00:20ABAP забыли :)
Alexeyslav
08.09.2016 10:59Тогда ненароком про 1С вспомнят. Нет уж, не надо!
ru_vlad
08.09.2016 00:33+1Жаль что не кто не вспомнил Форт ;)
В своё время был очень интересный язык. Скорость на уровне ассемблера, на нем получались очень любопытные вещи.
Siemargl
08.09.2016 01:37На ХеллоВорлде не видно отличия языков. Вот если взять любую другую задачу для примера — квадратное уравнение, факториал, ряды…
И в список я бы добавил Redcode из Core War.
smile616
08.09.2016 01:37+6извините не могу сдержаться, приведённый машинный код и программа на языка Assembler не соответствуют друг другу.
Первый выводит «Hello, World!» и использует для этого BIOS (см.CD 10=int 10h)
Вторая выводит «Hello, World\n» испльзуя порерывение21hMS DOS.
Jef239
08.09.2016 02:48Из графических языков стоит вспомнить https://ru.wikipedia.org/wiki/Ladder_Diagram, а из сложных для понимания https://ru.wikipedia.org/wiki/FORTH
Форт — это такой иврит, читаемый справа налево (польская запись) и с тарабарщиной вместо букв.
А Ladder — как и большинство графических языков, компилируется плохо. Впрочем, декомпилируется н тоже не так легко.naryl
08.09.2016 03:05+1Запись польская, да только читается он слева направо.
2 2 +
Взять 2, взять ещё 2, сложить. И форт-машина выполняет программы тоже слева направо.
И сложен для понимания он тоже только с непривычки.: ) Сложность восприятия человеком вообще штука крайне субъективная. Мне вот лиспы самые простые для понимания, а все вокруг почему-то кроме ))))))))) ничего в них не видят.Jef239
08.09.2016 03:30я соавтор одной из форт-систем. Но думать на форте я привыкал полгода.
Что касается «справа налево» — сравни направление в операторах в обычном языке и в форте.
Обычный язык if (n != 0)
Форт: n ?DUP 0= IFFortop
08.09.2016 06:08Вы классные, наверное, оба.
Да только польская нотация и обратная польская нотация отличаются именно порядком:
(операция) (аргументы) для польской нотации + 2 2
(аргументы) (операция) для обратной польской нотации 2 2 +Jef239
08.09.2016 07:15я долго думал, писать ли «обратная». :-) Все-таки с фортом я 30 лет назад возился.
ru_vlad
08.09.2016 07:48На счет сложности для понимания согласен, но кто начинал на программируемых калькуляторах (электроника бз-34 и прочих) труда не составляет :)
А еще можно из особенностей вспомнить Форт позволяет создавать свои операторы и делать из них словарь. Простейший пример :2+2= 5; и теперь при наборе 2+2= появляется 5 В свое время это был прогресс. :)
Siemargl
08.09.2016 10:22LAD элементарно компилируется и декомпилируется, так же как и FBD (в формулировке IEC 61131-3).
Jef239
08.09.2016 11:41Вы писали компилятор и декомпилятор? Можно его проверить на сложных случаях? При декомпиляции проблема в многоадресных командах, иногда очень сложно нарисовать не то, что красиво, но даже и просто корректно. FBD проще отрисовывается. Да, под компиляцией я понимаю преобразование в IL (или в дерево вычислений), при декомпиляции — преобразование из IL. А IL включает команды конкретного контроллера.
Siemargl
08.09.2016 13:12Я писал на IL, LAD, FBD (и прочем). IL в стандарте — одноадресный, не привязан к конкретному контроллеру.
И не надо смешивать проблему декомпиляции и отрисовки.Jef239
08.09.2016 14:05Я на них почти не писал. Я делал программу для OMRON CV-1000, которая в том числе по срабатыванию аварийного выхода и архиву переключений выясняет, какой источник был причиной аварии. При многотактной отработке аварии и сохранении в архиве далеко не всех входов и промежуточных переменных.
Компиляции в дерево шла из IL конкретного контроллера, включая сотню его специфических команд. Декомпиляция — в графическое представление в LD и FBD с подсветкой значений в конкретных соединениях. Можно было даже видео посмотреть — как меняются сигналы внутри LD или FBD.
> И не надо смешивать проблему декомпиляции и отрисовки.
Тогда что вы понимаете под декомпиляцией LD?
И что значит «элементарно компилируется»?Siemargl
08.09.2016 14:59Я не понимаю, зачем переделывать руками типовые задачи — определения первопричины аварии и графической отладки LAD, встроенной во все современные средства программирования ПЛК. Ну да ладно, это оффтоп.
«Элементарно компилируется» — это значит, что более удобного для компиляции языка, чем связка логических операторов LAD, трудно себе представить. Это уровень ассемблерного транслятора, а не компилятора. Это синтаксический анализатор выражений, не более.Jef239
08.09.2016 21:26Типовые? Ну покажите, какой софт умеет определять причины аварии. Средненькие условия — на одном из сканов вход стал ON вместо OFF. Всего лишь на один скан. Далее — через 2 скана авария. Всего надо исследовать 3-4 LD-диаграммы с учетом порядка их выполнения в контроллере.
Вы попробуйте написать такой транслятор. С учетом того, что провода можно любой длины рисовать. А дальше будем говорить, легко или нет. Легко компилируется что-то типа паскаля или бейсика. Там работает типовая схема рекурсивного спуска, это обычная курсовая работа. А вот как вы будете компилировать laddder — это интересно.
Делаю реквест на статью — как сделать компилятор Ladder-диаграмм.Siemargl
08.09.2016 21:38Анализ первопричины, как и реакция на аварию — шатдаун, делается в ПЛК.
Jef239
09.09.2016 00:40Реакция на аварию — это не шатдаун. Стальная лента идет через печь. При остановке стана через минуту лента начинает прогорать. Если она прогорела, то время заправки её в стан от 12 часов до 3х суток. В день выпускается оцинкованной стали на 1.0-1.5 миллиона долларов.
Так что никакого шатдауна. При аварии останавливается непрерывное движение стальной ленты и загорается лампочка. И дальше забота оператора, на каком управлении протащить ленту — на дистанционном автоматическом однократном, на дистанционном ручном, в конце концов — на местом, прямо со шкафа управления.
ПЛК никакой анализ первопричины не делает. на это у него просто не хватает мощности. Дело ПЛК — по OR/AND собрать сигнал аварии. А уж как образовались отдельные сигналы — дело дежурной смены автоматчиков. Ну и нашего софта.
Разобрались — останов повесят на электриков, приводчиков, гидравликов… не разобрались — на автоматчиков. За 3 часа простоя в месяц по вине службы — премию лишают всю службу. А премия у них равна окладу.
>, зачем переделывать руками типовые задачи — определения первопричины аварии и и графической отладки LAD,
Я повторю вопрос: какой софт умеет определять первопричины аварии?
Ну и заодно — какой софт может проиграть из архива переключения LD по сканам? Не текущее состояние, а архивное, ну скажем 10 сканов перед аварией.
Jef239
09.09.2016 01:06Вы меня простите, но мне реально интересно, кто ещё умеет делать многотактовый анализ? И что именно у них сделано.
Siemargl
09.09.2016 03:27-1Да я вижу, любители придумывать себе проблемы, и героически с ними бороться.
1. Т.е у ПЛК хватает мощности проанализировать массив бит на аварийное состояние. Но при этом скопировать этот массив (а обычно достаточно скопировать 1 бит — ну или байт первопричины) при аварии мощности у него не хватает. Как?
Судя по документации, производительность вашего древнего SYSMAC CV-1000 0.15-0.45ms на операцию. Т.е вам на сохранение состояния при аварии нужно несколько миллисекунд.
2. У вас аварийный останов (шатдаун) стоит 1000000$. Ну так купите ПЛК поновее, дешевле будет.
Сохранять все состояния на каждый цикл и проигрывать их потом не нужно. Нужно правильно написать процедуру анализа аварий и первопричины.Jef239
09.09.2016 05:14+1> Но при этом скопировать этот массив (а обычно достаточно скопировать 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$. Ну так купите ПЛК поновее, дешевле будет.
Чем это поможет? Авария — это, например, перегорела лампочка на фотоконтроле положения полосы. То есть ли полоса сошла с ролика, то ли лампочка сгорела. Вы думаете при более мощном контроллере лампочки начнут перегорать реже? :-)
Правы вы только в одно — на каждом скане контроллер пишет свое состояние (кроме часто изменяемых служебных переменных) в кольцевой буфер. Который и читает программа формирования архива. А уж из архива — делается анализ первопричин аварии. В том числе — с возможность БЫСТРО (секунды) посмотреть, когда были аналогичные аварии и схожие ли были причины.Siemargl
09.09.2016 13:42-11. Так сделайте анализ каждой аварии в одном скане, а лучше нетворке.
2. Мир вокруг контроллера имеет время реакции. Минимум это 14мс устранение дребезга обычным модулем в/в. Все сканы, что происходят в этот период можно считать за один.Время обработки программы аварийной ситуации в конкретном ПЛК должно быть адекватным развитию аварийной ситуации, которая у вас минута =)
2. Первопричина аварии всего одна — одна авария <= одна первопричина. Один аварийный останов <= одна авария <= одна первопричина. Понятно, что первопричиной может быть набор определенных параметров процесса, но он все равно один.
В общем у вас какая то не АСУшная логика мышления. На сим откланиваюсь, надоело.Jef239
09.09.2016 20:07Простите, сколько было входов-выходов в самой большой системе из запроектированных вами? Надеюсь на честный ответ.
>Так сделайте анализ каждой аварии в одном скане, а лучше нетворке.
Это делается только дублированием кода. На такую оптимизацию программы контроллеров проверяются.
> Все сканы, что происходят в этот период можно считать за один
Время скана 20-50мс. Развитие аварии — 1-5 сканов.
> Первопричина аварии всего одна — одна авария <= одна первопричина.
ДА. Повторю вопрос. КАК ваша процедура выдаст результат анализа? По сотне лампочек на каждую аварию?
Как довести информацию до электриков, гидравликов, приводчиков, химиков, технологов? Через какие механизмы? Ещё раз — у нас 100 аварий и 100 потенциальных причин на каждую. Вы предлагаете 10 тысяч сигнальных лампочек?
> В общем у вас какая то не АСУшная логика мышления.
Не выиграл, а проиграл, не в карты, а в домино…
1) АСУТП довольно сильно отличается от АСУ. АСУ — это «на таком-то стане избыток рулон оцинкованной стали, надо туда подать вагоны под погрузку.» АСУТП — это управление самим станов длиной 500 метров и высотой с пятиэтажку.
2) Программы контроллеры писали не мы, а сотрудники «Северстали». Наша работа — это программа диагностики и архивирования.
3) Логика в том, что лучше иметь универсальную систему анализа, работающую для любых программ контроллера, чем писать свою логику на каждую аварию и меть 10 тысяч сигнальных лампочек.
ЕЩЁ РАЗ. Мне реально интересно, кто ещё умеет делать многотактовый анализ? И что именно у них сделано.
igor_suhorukov
08.09.2016 16:31Говоря про графические языки, не упомянули советский
ДРАКОН, для создания систем реального времени управления космическим кораблем «Буран».
kenrube
08.09.2016 05:37Про Brainfuck/Befunge вспомнили, но забыли (=<;:^876Z43W10/.-,P*)('K%$H"!~}C{z@xwv<)]rJ%u4V2qC/nQPO*<(gJHGGb!m_BAi>Z=<WP(T
Непорядок :)Idot
08.09.2016 15:05А это что за язык?
iqiaqqivik
08.09.2016 15:42>> (=<;:^876Z43W10/.-,P*)('K%$H"!~}C{z@xwv<)]rJ%u4V2qC/nQPO*<(gJHGGb!m_BAi>Z=<WP(T
> А это что за язык?
Это и есть название языка.
pestilent
14.09.2016 11:57Ну тогда уж можно было бы вспомнить и то, с чего всё это безобразие начиналось,— INTERCAL.
Idot
08.09.2016 06:12Забыли написать, что Pascal изначально был учебным языком, после изучения которого предполагалось перейти на ALGOL, но оказалось, что он может с успехом заменять ALGOL.
(а вот BASIC заменить FORTRAN не смог)
i360u
08.09.2016 06:54Logo — мой первый язык программирования, изучал его в детстве, даже написал на нем игру "морской бой" на конкурс юных программистов =)))
Escalibur
08.09.2016 09:21-4Ассемблер был и остается идеальным способом для обучения пониманию, как устроена вычислительная система.
Я считаю, что если программисту в период обучения не выдавали аналог Robotron-1715 и он для него не написал ОС, транслятор с языка программирования, линкер, шелл и набор системных утилит, то его жизнь прошла зря и он нихрена не понимает в вычтехнике, как это сделал, к примеру, Линус.
В качестве обоснования своих слов могу сослаться на эпическую книжку Чарльза Уэзерелла «Этюды для программистов» 1972 года выпуска. Рекомендую ознакомиться с разделом системного программирования и оценить какие курсачи по мнению Чарльза должны были делать студенты за 1 семестр в 72-ом году.
iqiaqqivik
08.09.2016 11:46> По мнению «Википедии», язык программирования — формальная знаковая система, предназначенная для записи компьютерных программ.
Поиск по странице фамилии «Тюринг» дает ноль вхождений. Здравствуй, 2016 год. Привет, определения языков программирования из «Википедии».
И да, bf был создан как демонстрация Тюринг-полного минимального языка. А вовсе не потехи ради.kenrube
08.09.2016 12:57Поиск дал бы больше результатов, если б вы учли, что его фамилию исторически переводят как Тьюринг
iqiaqqivik
08.09.2016 13:45Ну ок, поиск бы дал результат «за эту разработку дали премию Тьюринга». Это сильно изменит высказанный тезис?
kenrube
08.09.2016 13:58Не сильно. Только непонятны ваши ожидания увидеть в развлекательной статье углубление в теорию ЯП
yomayo
08.09.2016 11:54Вашу мысль, вынесенную в заголовок «Не все языки программирования одинаково полезны», некоторые формулируют иначе: «Все языки эквивалентны. Но некоторые из них эквивалентнее других».
Vlad_fox
08.09.2016 12:26+1Надо ли писать/читать столько страниц текста, чтобы обосновать достаточно банальное утверждение " Не все языки программирования одинаково полезны"?
какая от этого практическая/теоретическая польза?
Viacheslav01
08.09.2016 17:35Эх… В 90-х лежал в больнице и писал программы на салфетках, но правда на нормальном ассемблере x86. Сейчас я пожалуй на это не способен.
SicYar
Все равно все это выглядит красиво и приятно глазу, хоть уже практически и не используется. Такая своя красота логики, конструкций, когда читаешь такой код накатывает чувство ностальгии и сразу перед глазами старый монохромный монитор… эх…
P.S. Я не старый, мне 25 от роду, но все равно фанатею от старых языков.
NeoCode
15 лет писал в основном на С++, а тут вдруг понадобилось написать кое-что для линукса на чистом Си. Интересные впечатления… программирование С++ всегда вызывает беспокойство — потому что всегда не до конца понимаешь все эти шаблонные навороты, потому что С++ сочетает огромную мощь и некоторую «недоделанность», когда понимаешь что для вроде бы простой и очевидной вещи нужно подключать всякий Boost и писать кучу совершенно не относящегося к задаче кода.
Программирование же на чистом Си вызывает умиротворенность:) Все навороты С++ просто отсутствуют. Все что можно сделать — можно сделать единственным образом. Возможно, что это следствие того что для Си другие задачи, и если бы я применял Си для тех задач для которых я применяю обычно С++, то проблем было бы еще больше (на самом деле так оно и есть).
И еще. Удивительный по красоте и гармоничности язык Си сочетается в Линуксе с ужасными и взрывающими мозг языками шелл-скриптов и мейкфайлов. Глядя на них только и хочется сказать «дайте мне развидеть это». Странное противоречие, но как будто эти языки пришли из совершенно разных миров…
Sirikid
Это дзен
AxisPod
Шаблоны это магия и эту маги познать можно, и даже есть книги, которые позволяют это сделать. И когда этой магией будет пропитан весь мозг, вот тогда даже boost становится понятен.
gorodnev
Ладно еще все shell-языки неказисты в некоторой мере, но так обидеть Make — у Вас нет сердца! :)
NeoCode
shell и make тесно связаны, и я бы сказал что мне вся эта концепция активно не нравится.
Например qmake удивительно простой (поэтому там где возможно в линуксе использую только его). Но там иногда все равно вылезают хвосты от make.
Проекты Visual Studio к сожалению слишком неудобны для редактирования в текстовом виде, но концептуально тоже ничего.
qbs выглядит очень неплохо, очень похоже именно на то что надо, но к сожалению я этой системой еще не пользовался.
DistortNeo
Просто make — это низкоуровневое универсальное средство сборки проекта, а не средство его описания. Проекты Visual Studio действительно заморочены, и лазить руками в них лишний раз не стоит, когда для этого есть IDE.
Но лазить руками в них все равно приходится. Например, выносить общие для всех проектов настройки (пути, платформы, опции компилятора и режимы компиляции) в подключаемые шаблоны проектов, менять условия условий применения определённых настроек.
NeoCode
Вообще говоря мне и бешеное изобилие опций командной строки того же gcc не нравится. Я бы предпочел, чтобы опции задавались в структурированном декларативном виде в файле проекта (идеально в json-подобном формате), который был бы единственным аргументом для gcc и заменой как опций gcc, так и make-файлов.
0xd34df00d
На хаскеле самое оно после почти любого другого языка. Как будто с умным математиком говоришь, а не тупым исполнителем.
Antervis
забавно, мои впечатления были наоборот, скорее негативными. В основном от того, что очистка выделенных ресурсов в плюсах всегда проще (scoped exit, unique_ptr)
RomanArzumanyan
C это свобода и ответственность.
DeadKnight
Правда весь этот дзен в миг улетучивается, когда ты встречаешь нагромождение скобок и звездочек и начинаешь их «раскручивать»: «Так, тут у нас указатель на функцию, которая принимает в качестве аргумента указатель на функцию с двума параметрами возвращающую указатель на массив указателей на функции, которые ....»
Siemargl
Вот не надо панику подымать на ровном месте. Это все решается typedef'ами и нормальным проектированием структур.
Хороший С-код отлично читаем. Что, впрочем можно сказать, про почти любой более-менее традиционный язык (не брейнфак).
Sirikid
Не обязательно писать всю программу в одну строчку и без пробелов, тогда и bf получше читается.
Idot
Тогда Вам нужно обязательно попробовать C-- — не шучу! Недавно на Хабре была про него статья, язык C-- — реально существует.
NeoCode
Да я этот С-- смотрел когда еще Хабра не было:)
А к той статье вроде бы даже писал комментарии… странный язык. С одной стороны доступ к низкоуровневым вещам это приятно (хотя даже в Borland C++ был прямой доступ к регистрам через _AX, _BX и т.д.), но вот с другой — отсутствие приоритетов операций ставит на языке жирный крест.