Comments 163
P.S. Я не старый, мне 25 от роду, но все равно фанатею от старых языков.
Программирование же на чистом Си вызывает умиротворенность:) Все навороты С++ просто отсутствуют. Все что можно сделать — можно сделать единственным образом. Возможно, что это следствие того что для Си другие задачи, и если бы я применял Си для тех задач для которых я применяю обычно С++, то проблем было бы еще больше (на самом деле так оно и есть).
И еще. Удивительный по красоте и гармоничности язык Си сочетается в Линуксе с ужасными и взрывающими мозг языками шелл-скриптов и мейкфайлов. Глядя на них только и хочется сказать «дайте мне развидеть это». Странное противоречие, но как будто эти языки пришли из совершенно разных миров…
Например qmake удивительно простой (поэтому там где возможно в линуксе использую только его). Но там иногда все равно вылезают хвосты от make.
Проекты Visual Studio к сожалению слишком неудобны для редактирования в текстовом виде, но концептуально тоже ничего.
qbs выглядит очень неплохо, очень похоже именно на то что надо, но к сожалению я этой системой еще не пользовался.
Но лазить руками в них все равно приходится. Например, выносить общие для всех проектов настройки (пути, платформы, опции компилятора и режимы компиляции) в подключаемые шаблоны проектов, менять условия условий применения определённых настроек.
В Makefile можно просто сказать, что эта цель зависит от этих файлов таким то образом. В современных системах что бы сделать такое часто приходится писать код, который сам проверяет и сравнивает времена модификаций файлов и дальше инициирует необходимые действия. И кто после этого низкоуровневый?
Во-первых, куча мантр: прописывание компилятора, его флагов, правил компиляции и т.д. А если я хочу поменять комилятор, при этом не хочу трогать Makefile?
Во-вторых, сложность с подключениями пакетов. Вот есть у меня проект — статическая библиотека, и я хочу его подключить и использовать. С помощью Makefile я не могу этого сделать с помощью инструкции типа «вот в той директории лежит проект, подключи его», мне нужно на низком уровне прописывать пути, опции компилятора, ещё и помнить, куда кладутся бинарники и т.д.
В-третьих, что у нас там с автоматическим скачиванием пакетов?
Недостатки make — использование значимой табуляции и не очень хорошо подходящий для пакетной работы синтаксис sh. Но в своей области это высокоуровневый инструмент.
Понятно же, что сложность программ многократно выросла за последние десятилетия, и инструмент make стал неудобным для огромных проектов.
А к той статье вроде бы даже писал комментарии… странный язык. С одной стороны доступ к низкоуровневым вещам это приятно (хотя даже в Borland C++ был прямой доступ к регистрам через _AX, _BX и т.д.), но вот с другой — отсутствие приоритетов операций ставит на языке жирный крест.
— Ассемблер GENS4-51 (у когорого 51 символ в строке вместо дефолтных 32-х)
— Монитор/отладчик MONS4
Ну и, конечно же, The Complete Machine Code Tutor — обучающая программа по архитектуре и системе команд процессора Z80
Дизассемблировал заставки к играм и записывал карандашем в тетрадку код понравившихся эффектов.
Помимо спектрумовского асма в памяти жив легендарный Laser Basic — расширение для системного бейсика, вешающее свой хук на обработчик ошибок и расширяя таким образом синтаксис базового языка примитивами для работы с графикой (спрайты и т.п.)
Кстати, надо с отступами.
program HelloWorld;
begin
WriteLn('Hello, World!');
end.
Лучшего языка для начинающих пожалуй не придумали.
Вирт ГЕНИЙ!
Как учитель уже выпустивший не один десяток учеников которые пошли по данному профилю, могу сказать, Паскаль жив и еще много хорошего сделает.
Хотя сам начинал с маш кода.
Лучшего языка для начинающих пожалуй не придумали.
А как же Delphi, являющийся развитием Паскаля?
Да, я знаю есть отличия, есть дополнение итак далее. Сам на нем создавал коммерческие приложения, но для начинающих лучше все классика-Паскаль :)
Но я часто думаю, являются ли дельфийцы подвидом программистов
Код писать можно на чём угодно, «Делфи — это визуальные формочки» — это явно от знакомства со школьными хэллоуворлдами. Примерно как ПХП — если порог вхождения позволяет школьникам ваять недосайты, то это не значит что на нём нельзя делать проекты. На сях тоже индусского кода более чем (весь код в h-файле, например). И таки-да, Delphi — это название языка уже много лет как (с 7 версии).
Просто для меня дельфийцы — это некоторая окукленная секта адептов — хуже нет на фрилансе встретить предложение поддержки и развития проекта на Дельфи
Например, у 1с-шников на форумах возникают мысли — а программист ли я — у дельфийцев таких мыслей не возникает,
А писать можно на чем угодно, даже на коленке
Мысль возникает поскольку многие программисты 1С занимаются программированием на 1С процентов 20 времени, остальное время это постановка учета, консультации, написание схем бизнес-процессов, ковыряние в проводках и куча других вещей из смежных областей
А компонентный паскаль? Как он на практике и в обучении?
Вообще слышал что компонентный паскаль — супер-пуперский, объектный, минималлистичный и надёжнейший язык — типа гибрида стилета с танком. Насколько это действительности соответствует?
И ещё — вроде бы языки движутся с десятилетиями в сторону доказательного программирования — компонентный паскаль пригоден для такого программирования?
Но вот с дочкой в качестве первого языка всё-таки выбрали Python (Scratch не в счёт).
Тысячный раз повторю, Паскаль хорош как алгоритмический язык для первоначального обучения для детей примерно с 6-7 класса.
Если же алгоритмические структуры и основные понятия изучили раньше например на Scratch или Logo то разумней переходить на более взрослые языки Python, Java, C++.
я начинал на С. после него паскаль казался несколько примитивным.
Сейчас я программирую на LabVIEW, и это выглядит вот так:
Формально этот код эквивалентен
int result = 0;
for (int i = 1; i < 1000; i++) {
if (((i % 3) == 0) || ((i % 5) == 0)) {
result += i;
}
}
Для меня это тоже язык программирования, хоть и графический, и ничуть не конфликтует с C#, который я изучаю в свободное время.
Вот смотрю я на код — сразу всё понятно, на изображение — приходится должно въезжать. Аналогично приходится взрывать мозг, когда вижу UML. И это не привычка — со школы блок-схемы не воспринимаю. Хардварные реализации (радиоэлектроника), кстати, тоже не понимаю.
Вообще навык читать и создавать такие диаграммки приходит довольно быстро — через две недели оно уже не вызывает отторжения, через два месяца начинаешь свободно понимать чужой код, через два года перестаёшь понимать код текстовый.
Вообще каждый язык хорош по своему, но в той области, в которой я работаю (автоматизация производства и машинное зрение в области рентгеновского неразрушающего контроля) на LabVIEW разработка идёт значительно резвее — я с такой скорость даже на Дельфи не программировал (сравнимые по сложности продукты). Ну и по образованию я физик-электронщик, для меня диаграммки и схемы всегда были понятны.
Я бы ни в коем случае не начинал изучение программирования с LabVIEW — тут простота кажущаяся и программист должен быть сформировавшийся, с окрепшей психикой.
А вообще + за упоминание. И если идти путем LabVIEW, который печатание текста превращает в рисование алгоритма, то следующая стадия в программировании это «компьютер, включи плиту, разбей на сковороду яйцо и жарь 5 мин». Лет так через 20 называться это будет «программирование рецепта завтрака».
Для таких «наглядных» языков необходимо подключать дополнительную клавиатуру с программируемыми клавишами забиндеными на нужные хоткеи.
Основная проблема визуального программирования — необходимость часто переключать режимы работы и выбирать необходимый инструмент — наглядная клавиатура решит эту проблему и останется только одной рукой елозить мышкой(не отрывая руки) по делу а не в меню.
А насчёт специальной клавиатуре — это к APL. Потому что, например, в Delphi можно добавлять новые визуальные компоненты, а у обычной не виртуально клавиатуры — количество клавиш ограничено.
А обычные кнопочные, как на кассовых аппаратах бывают и по 100 клавиш, свои изображения можно повставлять настроить и пользоваться — она распознается как стандартная USB-клавиатура.
Недавно статья по ним была на хабре.
Есть ещё клавиатуры-доски для драм-машин, они ко всему прочему могут подсвечиваться индивидуально любым из 16млн цветов, но эти совсем в цене…
Даже 100 кнопок это будет уже перебор — вы же не всегда пользуетесь 100+ объектов и режимов одновременно. Обычно же не больше 20 избранных часто используемых режимов и объектов.
Ну вот, к примеру, если требуется построить графики синуса и косинуса для сотни элементов, то процесс «рисования кода» с использованием QuickDrop как-то вот так выглядит:
QuickDrop я вызываю нажатием Ctrl+пробел, затем просто ввожу названия примитивов. В принципе довольно эргономично.
Идеально если код будет иметь двойное представление.
и в виде схемы и в виде читаемого кода текста.
в принципе к этому идет, иде сейчас уже рисуют диаграммы к коду по мере набора автоматически перерисовывают.
дебаг и контроль версий все таки работает с текстом пока.
а схема позволяет больше показать связей чем код. удобнее думать что не так в алгоритме.
Я не представляю, как должен выглядеть 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 лет назад и сейчас, то думаю не все тогда поверили что такое возможно так скоро.
Мне приходится писать на LabView сейчас, и это ужасно. Дольше оформляется «красиво», при попытке что‐то абстрагировать в VI вылезают какие‐то баги (пытался разнести «код» инициализации/открытия FPGA, считывания из него значения и закрытия в три VI, так вторая со считыванием в упор не видит обновлений в VI FPGA), неясно где что вообще исполняется (три общих варианта: процессор MyRIO, его же FPGA и компьютер с labview, в первом случае ещё и подварианты (процессора (точнее, ядер) два, вроде есть потоки и процессы)), неясно, когда, как и на что выделяется память, неясна потокобезопасность различных конструкций (смотрел пример с погодным сервером на RT, не понимал, как такое вообще можно было придумать: очередь это VI с циклом, исполняющимся один раз; цикл нужен, чтобы хранить переменные в shift register — по моему мнению, они, вообще‐то, должны пересоздаваться при каждом обращении, а реально очередь можно использовать из обработчика http запроса, который неясно где вообще исполняется (но не думаю, чтобы в одном потоке с главным циклом, эту очередь использующим)). И ещё, diff вы не получите.
В общем рисовать в LabView долго — дольше, чем печатать после предварительного обучения. Узнать, что изменилось нельзя не только при помощи VCS, но даже и средствами LabView (как‐то посмотрел, чем объясняет LabView необходимость сохранения). Понять, как работает то, что вы нарисовали сложно. Единственный плюс — первые несколько прошивок для FPGA на каком‐нибудь VHDL я писал бы дольше, чем рисовал её же в LabView. Но только первые несколько.
Я бы хотел посмотреть, как бы вы красиво выполнили код такой несложной задачи, вполне практической: Имеется 30 датчиков одинакового типа, каждый датчик в реальном времени выдает 4 параметра, допустим float ток и напряжение и два boolean параметра: датчик исправен и датчик включен. Надо отобразить показания всех датчиков на одном экране, допустим 3 ряда по 10 слева направо, сверху вниз, в виде 2 танков (ток, напряжение) и 2х подписей (включен/отключен, исправен/ неисправен) на каждый датчик. Данные от датчиков можно эмулировать любыми функциями от времени и индекса датчика.
На Delphi, например, эту задачу я могу выполнить за полчаса, красивым кодом, с короткими методами. Сколько времени уйдет, чтобы сделать это на LabView и насколько это получится красиво и без лапши?
На что я ответил вот таким пятиминутным видео:
Вообще сравнивать LabVIEW с текстовыми языками — это всё равно что холиварить на тему Windows против Linux, или сравнивать китайский с английским. Я достаточно свободно владею и LabVIEW и С# — у каждого свои области применимости, свои паттерны, и так далее. Основная тема статьи — каждый язык хорош по своему, и с этим я абсолютно согласен. Вот только не нужно программировать на COBOL, если этого можно избежать.
Меня удивляет, что в современных версиях Prolog почти не внедряют программирование в ограничениях. Появись такая поддержка, этот язык стал бы более востребован (пока его роль выполняют всякие солверы), да и программировать на нем стало бы легче (меньше неожиданных эффектов от изменения порядка предикатов).
есть Mercury (хотя он не все умеет) и Curry
Не напишете про них ознакомительные статьи?
Я тут наткнулся на имплементацию языка LIFE. Разберусь с ним, смогу написать обзор о языках логического программирования.
Каждый смотрит на эту коллекцию и видит своё: кто-то восхищается создателями, кто-то усмехается — «Как же таким можно было пользоваться», у кого-то прокатывается глубоко внутри ностальгия и вспоминается школьная любовь… эх…
Если бы мог плюсануть, наплюсовал бы! :)
Эта статья для того, что-бы мы вспомнили каким тёплым и ламповым был ассемблер. Только гляньте на эти листочки (выше), становится сразу так тепло...
Кроме того, Алгол-68 (на котором приведен пример) и Алгол-60 это совершенно разные языки.
В случае использования ассемблера там стояли бы символические адреса.
Потом все остальные языки типа pascal, с/с++, разные варианты бейсика, java, c#, php, actionscript и др., которые использовались профессионально, то есть для реализации оплачиваемых проектов.
Некоторые языкм изучались для души типа Пролога или Лого, но профессионально не применялись.
Какой лучше или хуже — вопрос бессмысленный — лучший язык для программиста тот, на котором он лучше всего программирует
Не знаю как в Википедии, но вообще-то язык программирования — это средство записи алгоритма.
Если получается быстро и компактно записать нужный алгоритм решения поставленных задач в данной предметной области, то это и есть лучший для тебя язык
Хуже, когда приходишь на проект, созданном на чужом языке — это все равно, что попасть в центр Монголии, зная всего три монгольских слова — богатырь, деньги, тьма
Поэтому лучше не думать, что лучше, а учить, пока не станет лучше
вообще-то язык программирования — это средство записи алгоритма
Это Императивные языки, в Декларативных языках, включая (чистые) ФП, алгоритм не записывается.
Средство написания алгоритмов — это IDE и набор библиотек к конкретному компилятору языка программирования.
Но любой алгоритм — это описание, для чего и нужен язык
Алгоритмы не требуют иде и прочего — но описать можно на только неком языке, что было изложено еще в труде аль Хорезми — Китаб мухтасаб аль-джабр и ва-ль-мукабала, где были описаны способы формализации описаний решения. Данное понятие алгоритма из этой книги попало в Европу (алгоритм и есть измененная фамилия автора)
http://www.computer-museum.ru/histussr/umk_sorucom_2011.htm
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
В своё время был очень интересный язык. Скорость на уровне ассемблера, на нем получались очень любопытные вещи.
И в список я бы добавил Redcode из Core War.
Первый выводит «Hello, World!» и использует для этого BIOS (см.
CD 10
= int 10h
)Вторая выводит «Hello, World\n» испльзуя порерывение
21h
MS DOS.Форт — это такой иврит, читаемый справа налево (польская запись) и с тарабарщиной вместо букв.
А Ladder — как и большинство графических языков, компилируется плохо. Впрочем, декомпилируется н тоже не так легко.
2 2 +
Взять 2, взять ещё 2, сложить. И форт-машина выполняет программы тоже слева направо.
И сложен для понимания он тоже только с непривычки.: ) Сложность восприятия человеком вообще штука крайне субъективная. Мне вот лиспы самые простые для понимания, а все вокруг почему-то кроме ))))))))) ничего в них не видят.
Что касается «справа налево» — сравни направление в операторах в обычном языке и в форте.
Обычный язык if (n != 0)
Форт: n ?DUP 0= IF
Да только польская нотация и обратная польская нотация отличаются именно порядком:
(операция) (аргументы) для польской нотации + 2 2
(аргументы) (операция) для обратной польской нотации 2 2 +
А еще можно из особенностей вспомнить Форт позволяет создавать свои операторы и делать из них словарь. Простейший пример :2+2= 5; и теперь при наборе 2+2= появляется 5 В свое время это был прогресс. :)
И не надо смешивать проблему декомпиляции и отрисовки.
Компиляции в дерево шла из IL конкретного контроллера, включая сотню его специфических команд. Декомпиляция — в графическое представление в LD и FBD с подсветкой значений в конкретных соединениях. Можно было даже видео посмотреть — как меняются сигналы внутри LD или FBD.
> И не надо смешивать проблему декомпиляции и отрисовки.
Тогда что вы понимаете под декомпиляцией LD?
И что значит «элементарно компилируется»?
«Элементарно компилируется» — это значит, что более удобного для компиляции языка, чем связка логических операторов LAD, трудно себе представить. Это уровень ассемблерного транслятора, а не компилятора. Это синтаксический анализатор выражений, не более.
Вы попробуйте написать такой транслятор. С учетом того, что провода можно любой длины рисовать. А дальше будем говорить, легко или нет. Легко компилируется что-то типа паскаля или бейсика. Там работает типовая схема рекурсивного спуска, это обычная курсовая работа. А вот как вы будете компилировать laddder — это интересно.
Делаю реквест на статью — как сделать компилятор Ladder-диаграмм.
Так что никакого шатдауна. При аварии останавливается непрерывное движение стальной ленты и загорается лампочка. И дальше забота оператора, на каком управлении протащить ленту — на дистанционном автоматическом однократном, на дистанционном ручном, в конце концов — на местом, прямо со шкафа управления.
ПЛК никакой анализ первопричины не делает. на это у него просто не хватает мощности. Дело ПЛК — по OR/AND собрать сигнал аварии. А уж как образовались отдельные сигналы — дело дежурной смены автоматчиков. Ну и нашего софта.
Разобрались — останов повесят на электриков, приводчиков, гидравликов… не разобрались — на автоматчиков. За 3 часа простоя в месяц по вине службы — премию лишают всю службу. А премия у них равна окладу.
>, зачем переделывать руками типовые задачи — определения первопричины аварии и и графической отладки LAD,
Я повторю вопрос: какой софт умеет определять первопричины аварии?
Ну и заодно — какой софт может проиграть из архива переключения LD по сканам? Не текущее состояние, а архивное, ну скажем 10 сканов перед аварией.
1. Т.е у ПЛК хватает мощности проанализировать массив бит на аварийное состояние. Но при этом скопировать этот массив (а обычно достаточно скопировать 1 бит — ну или байт первопричины) при аварии мощности у него не хватает. Как?
Судя по документации, производительность вашего древнего SYSMAC CV-1000 0.15-0.45ms на операцию. Т.е вам на сохранение состояния при аварии нужно несколько миллисекунд.
2. У вас аварийный останов (шатдаун) стоит 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$. Ну так купите ПЛК поновее, дешевле будет.
Чем это поможет? Авария — это, например, перегорела лампочка на фотоконтроле положения полосы. То есть ли полоса сошла с ролика, то ли лампочка сгорела. Вы думаете при более мощном контроллере лампочки начнут перегорать реже? :-)
Правы вы только в одно — на каждом скане контроллер пишет свое состояние (кроме часто изменяемых служебных переменных) в кольцевой буфер. Который и читает программа формирования архива. А уж из архива — делается анализ первопричин аварии. В том числе — с возможность БЫСТРО (секунды) посмотреть, когда были аналогичные аварии и схожие ли были причины.
2. Мир вокруг контроллера имеет время реакции. Минимум это 14мс устранение дребезга обычным модулем в/в. Все сканы, что происходят в этот период можно считать за один.Время обработки программы аварийной ситуации в конкретном ПЛК должно быть адекватным развитию аварийной ситуации, которая у вас минута =)
2. Первопричина аварии всего одна — одна авария <= одна первопричина. Один аварийный останов <= одна авария <= одна первопричина. Понятно, что первопричиной может быть набор определенных параметров процесса, но он все равно один.
В общем у вас какая то не АСУшная логика мышления. На сим откланиваюсь, надоело.
>Так сделайте анализ каждой аварии в одном скане, а лучше нетворке.
Это делается только дублированием кода. На такую оптимизацию программы контроллеров проверяются.
> Все сканы, что происходят в этот период можно считать за один
Время скана 20-50мс. Развитие аварии — 1-5 сканов.
> Первопричина аварии всего одна — одна авария <= одна первопричина.
ДА. Повторю вопрос. КАК ваша процедура выдаст результат анализа? По сотне лампочек на каждую аварию?
Как довести информацию до электриков, гидравликов, приводчиков, химиков, технологов? Через какие механизмы? Ещё раз — у нас 100 аварий и 100 потенциальных причин на каждую. Вы предлагаете 10 тысяч сигнальных лампочек?
> В общем у вас какая то не АСУшная логика мышления.
Не выиграл, а проиграл, не в карты, а в домино…
1) АСУТП довольно сильно отличается от АСУ. АСУ — это «на таком-то стане избыток рулон оцинкованной стали, надо туда подать вагоны под погрузку.» АСУТП — это управление самим станов длиной 500 метров и высотой с пятиэтажку.
2) Программы контроллеры писали не мы, а сотрудники «Северстали». Наша работа — это программа диагностики и архивирования.
3) Логика в том, что лучше иметь универсальную систему анализа, работающую для любых программ контроллера, чем писать свою логику на каждую аварию и меть 10 тысяч сигнальных лампочек.
ЕЩЁ РАЗ. Мне реально интересно, кто ещё умеет делать многотактовый анализ? И что именно у них сделано.
ДРАКОН, для создания систем реального времени управления космическим кораблем «Буран».
Непорядок :)
(а вот BASIC заменить FORTRAN не смог)
Logo — мой первый язык программирования, изучал его в детстве, даже написал на нем игру "морской бой" на конкурс юных программистов =)))
Поиск по странице фамилии «Тюринг» дает ноль вхождений. Здравствуй, 2016 год. Привет, определения языков программирования из «Википедии».
И да, bf был создан как демонстрация Тюринг-полного минимального языка. А вовсе не потехи ради.
какая от этого практическая/теоретическая польза?
ADA… Расцвет использования этого языка пришелся на 80-е годы прошлого столетия
Вообще-то язык можно сказать, что жив:
- если C++ = C + объекты
- то PL/SQL = Ada + SQL
Не все языки программирования одинаково полезны