Средство для программирования контроллера: Си или МЭК 61131?

Очень хорошо.

А теперь поисследуйте вопрос о метафорических языках
программирования в профессиональных журналах...

Удачи.

Первоначально опубликовано Доктор Q http://brokgauz.academic.ru/misc/brokgauz.nsf/ByID/NT000035BA Метафора (греч. Мetajora, лат. Translatio, перенесение) - не в собственном, а в переносном смысле употребленное картинное или образное выражение; представляет собой как бы концентрированное сравнение, причем вместо предмета сравниваемого ставится непосредственно название предмета [...]

Первоначально опубликовано Дмитрий Теркель Z-строки - однозначно анахронизм, паскалевский подход культурнее, просто байта маловато. В Java, например, строки скорее паскалевские (длина 32 бита + юникодный массив), и геморроя никакого нет. Другое дело, что этот анахронизм не имеет никакого отношения к самому языку C, в котором понятия "строки" вообще нет, это анахронизм традиционных библиотек. Никто не мешает создать правильный класс String, хоть "паскалевский". А насчет парсить - не факт, что паскалевскую строку парсить труднее, тем более, что обычно пишется один раз токенайзер, и затем уже никто не вспоминает, как он устроен.

Ой, держите меня за другие задние ноги. Строки в уникоде - это конечно эффективность и экономия памяти.
И таки в Си есть понятие const char, плюс макросы типа __DATE__ __FUNCTION___

И вообще - паскалевские-непаскалевсие для сишников совершенно по барабану: умолчание используются с нулем на конце, что в 99% случаев короче и эффективнее; для оставшегося 1% можно либо легко и просто сделать свое, либо пользовать класс string в плюсах. И все вопли про "анахронизм" - это чушь собачья. Особенно в аспекте СТА

Первоначально опубликовано evgen И вообще - паскалевские-непаскалевсие для сишников совершенно по барабану: умолчание используются с нулем на конце, что в 99% случаев короче и эффективнее; для оставшегося 1% можно либо легко и просто сделать свое, либо пользовать класс string в плюсах. И все вопли про "анахронизм" - это чушь собачья. Особенно в аспекте СТА

Я, конечно, не совсем правильно выразился, что в Си нету строк, имелось в виду, что нет такого типа данных "строка" - литералы в кавычках, разумеется, есть (а const char здесь вообще ни при чем). То, что все "сишники" (и я в том числе) используют эту гадость - сущая правда. Вот небольшой пример из жизни z-строк:
#include <string.h>
#include <stdio.h>
#include <conio.h>

char* s="aaa , bbb; ccc";
void main()
{
printf("\nstring=%s",s);
{
    printf("\ntok=%s",strtok(s, ",;" ));
    printf("\nstring=%s",s);
}
}
Что будет, если это запустить, скажем, из под VC++?
Правильно, access violation. Нельзя токенизировать константные строки. Это нормально?
А все дело в том, что токенизатор strtok, для экономии памяти использует хакерский прием - он вставляет нуль в конец токена и портит строку, которую распарсивает. Кстати, такой побочный эффект не всегда приятен (даже если исправить char* на char[] и избавиться т.о. от exception), если токенизатор не добежал до конца, исходная строка останется укороченной.
В Java-style строках (длина-указатель) такой проблемы в принципе нет. Несколько строк могут разделять общий буфер символов, не мешая друг другу (между прочим, это еще и экономия)
А насчет юникода "в аспекте СТА", так вот, если вспомнить ("в аспекте СТА") про три кодировки кириллицы...
(про бедных китайцев я не вспоминаю :)
Есть, конечно, UTF-8, но тогда, например, такая простая вещь, как подсчет количества символов в строке превращается в высокоинтеллектуальную процедуру.
Так что юникод "в аспекте СТА" весьма даже уместен.

Владимир Е. Зюбин и статью найдете и список доп. ссылок по теме.

Значит, где-то может быть есть единственная статья где  употребляется словосочетание "метафорический язык программирования" по отношению к LD и FBD ? Или слово "метафора" употреблялось в совершенно другом смысле и контексте? Последнее наиболее вероятно, очевидно подмена понятий произошла в больном сознании г.Зюбина.

У меня вот тоже статейка на эту тему недавно проходила... кстати,
весьма интересная, говорят, получилась...

Ну точно, бред, опять ссылка на самого себя, вдобавок - с передергиванием. В статье хоть и делаются попытки "притянуть за уши" терминологию, используемую в другой предметной области (при создании GUI), к языкам программирования, но, по крайней мере, в форме намеков, а не прямого бреда.

Возвращаясь к Зюбинскому перлу и моим комментариям к нему:

Читабельность метафорических (??? бред...) языков не подтверждается экспериментально (??? фантазии Зюбинa)

После того, как г.Зюбин выдал ссылку на свою статью http://www.ict.nsc.ru/ws/elpub2003/6079/ , картина более-менее прояснилась.

В этой статье разбросано изрядное количество перлов, например:

графика не является самодостаточным выразительным средством(совершенно безосновательное утверждение) ... это связано с иероглифичностью графики, с неформализуемостью создания новых идентификаторов-пиктограмм  (сие имеет какой-то смысл для GUI, но обоснований для переноса чуждой проблемы на языки программирования Зюбин, по своему обыкновению, не приводит - поскольку их нет)

(В текстовой форме) достигается единство внешнего и внутреннего (машинного) представления (беззастенчивый ламерский бред, хотя бы потому что это единство имеется только на уровне ассемблерных программ)

Однако дело не в этих перлах. Судя по всему, построения этой статьи, а также других статей/высказываний Зюбина, касающихся графических языков, в основном базируются на ложных выводах, изложенных в работе Грина http://citeseer.nj.nec.com/green92when.html  Зюбину, кажется, невдомек, что Ashley Walton в работе http://citeseer.nj.nec.com/128125.html  камня на камне не оставил от упомянутого опуса.

Да и немудрено. Грин сравнивает (явно не лучший) графический язык LabView с текстовым Nest-INE. При сравнении Грин допускает большие натяжки, а также не приводит существенных обоснований выбора языков и не оговаривает достоверных границ применимости полученных результатов, что не очень-то добросовестно. Валтон провел серию экспериментов, которые, в частности, показали, что графические языки гораздо лучше воспринимаются чем текстовые (что и следовало ожидать), и что результатам конкретно этой Гриновской работы верить нельзя. 

Заодно выяснилось, откуда пошел Зюбинский бред о "метафорических языках программирования LD и FBD".

У Грина в упомянутой статье сказано: LabView is closely based on the metaphor of electronic block wiring diagrams, оставим это на его совести. Кроме того, в работах по графическим интерфейсам (не путать с языками программирования!) упоминается, что пиктограммы могут (но не обязаны) являться графическими метафорами объектов, которые они представляют (например, иконка Recycle Bin в виде мусорного бака).

Очевидно, именно на этой шаткой основе больное воображение Зюбина и создало пресловутые "метафорические языки программирования LD и FBD". Это просто шедевр.