Разные языки. Преимущества и недостатки

[незваный гость]

Еще одно дополнение к графике в программировании:

Стадарт IEC-1131 описывает шесть языков для проектирования промышелнных систем управления. Из них четыре — графические. Стандарт написан из рук вон плохо. По-видимому, наиболее видимый поставщик систем программирования 1131 — IsaGRAPH. Инженеры (обычно не программисты), программирующие системы управления на 1131 обычно остаются довольны.

[Yuri Gendelman]

незваный гость писал(а):

... нужен даже не стандарт, а хотя бы метод описания графических элементов языка. В чем-то это аналогично грамматикам Бэкуса-Наура. У нас нет грамматик графических элементов...

Этот круг вопросов скорее всего уже изучался при разработке CAD-систем. Особенно для систем топологического проектирования СБИС. И статьи по грамматикам графических объектов попадались. Вот нагуглил сейчас ссылку: Е.А.Жоголев. Графические редакторы и графические грамматики. // Программирование, 2001, №3, стр.30-42 (статью не видел).

Cube писал(а):

Цитата:

промышленное программирование

Это что такое ?

Добавлю еще термин: именно это и называется Software Engineering.

незваный гость писал(а):

а как бы Вы перевели “three amigos”?

Наверное можно и "3 кореша". Я не настолько понимаю психологию американцев, чтобы уловить, как они ощущают испанские слова в английском тексте. Можно еще "3 веселых гуся"

bugmaker писал(а):

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

Чисто графические среды программирования существуют и применяются, хотя и не очень широко.
Первый пример - Ladder Logic для PLC. Для PLC появились и текстовые языки (стандарт 1131), но они гораздо менее популярны.
Второй пример - довольно известная в определенных кругах (145 запросов на Dice.Com за месяц) система программирования LabVIEW. Входной язык для нее – G-language (графический язык). Программа на G выглядит как схема, напоминающая электронную. Есть в ней и аналог подпрограмм: можно определить свою подсхему (VI – виртуальный инструмент) с входными / выходными параметрами и использовать ее как элемент в других схемах (как ИС на электронной схеме). Существовали и планы "G with Objects". Мне пришлось в течение 4 месяцев разрабатывать на LabVIEW небольшой проект, так что могу о ней высказать свое мнение: мне с текстовыми языками удобнее.
Главная особенность обоих примеров: программы получаются параллельными. Возможно для параллельного программирования графические среды более естественны, чам текстовые.

[bugmaker]

Цитата:

Видите ли, Вы пока еще не настолько великий писатель, чтобы учить Вас наизусть.

Тем не менее позволю себе посоветовать Вам постараться в дальнейшем не допускать столь грубого извращения смысла цитат, на которые ссылаетесь. Иначе складывается впечатление, что я веду дискуссию с человеком, не только не ориентирующимся в программировании, но и неспособному понять смысл короткой фразы на чистом русском языке.

Цитата:

А считаете его всего лишь ...

Я считаю что читал несколько статей, не чорнопиарного толка, а вполне осмысленных, в которых приведен сравнительный анализ OCaml и ряда других языков. На основе приведённых данных можно сделать вывод об оптимальности этого языка.

Цитата:

А сам по себе OCaml - вполне нормальный функциональный язык.

Не чисто функциональный.

Цитата:

Среди функциональных языков чаще упоминаются Lisp, Haskell и Scheme.

Если под словом Lisp здесь имелся в виду Common Lisp, он не функциональный. Если всё семейство его диалектов, непонятно почему один из его диалектов - Scheme, упомянут отдельно.

[незваный гость]

Yuri Gendelman писал(а):

И статьи по грамматикам графических объектов попадались. Вот нагуглил сейчас ссылку

Спасибо. Очень интересно. Попробую найти. Похоже, я отстал от жизни.

[Yuri Gendelman]

незваный гость писал(а):

Попробую найти.

Ключевыми словами могут быть "visual grammars" и "shape grammars".
На русский переводилась книжка К.С.Фу. Структурные методы в распознавании образов. М.: Мир, 1977, в которой было немного о грамматиках образов более высокой размерности. Когда-то книжка была в "Колхозе".

[uni]

Ну и огород тут. Каких только грядок нет. Добавлю ещё пару культур.
Вроде бы тут Mathcad не вспомнили, там собственный язык программирования - математический графический.
Есть и для микроконтроллеров графическая среда уже - Algorithm Builder.
Я бы даже не побоялся назвать программами документы сред схемотехничекого моделирования, коих вообще не мерено. Там тоже задаёшь задание на графическом языке и получаешь результат, в виде графиков или чисел.
Ещё мне интересно согласно каким отчётам что считать узкоспециализированным? Вы видели сколько техники находится постоянно вокруг Вас в наше время? Цифровой техники. В каждом устройстве стоит микроконтроллер или DSP процессор или их комбинация. Только одна мысль об этом (!) приводит к следствию, что программеров и программ для них просто огромное количество. Загляните под крышку ваших девайсов - там труд тысяч программеров, которым до лампочки .NET, Java и прочие макро навороты. Мелкие контроллеры будут существовать всегда, покуда существуют для них задачи - современные авто упитаны под завязку такими штуками, чуть ли не в каждой фаре по такой многоногой "тваре". И вы думаете на чем там писаны программы? Асм и Си - вот на это паре. И не простой Асм - для для каждого контроллера свой. Си слава богу более менее стандартизирован с ним полегче ситуация.
Для интереса возьмите и пройдитесь по комнатам и посчитайте цифровые девайсы, откройте крышку системника и почитайте надписи на микрухах - там везде трудятся сотни программ написанных на Си и асме.
Я к тому, что споры на счёт языков не нужны. Они появляются, когда кого-то заставляют писать на том, что он не учил и чем пользуется хуже, чем чем-то другим. Эта ломка и порождает споры. Как по-моему, так нужно давать возможность решать задачи теми средствами, которые более освоены. Если уж хотите привлечь внимание на свою какую сторону, то тут нужно солидные аргументы приводить и не в виде каких статей там и прочей лабуды. КОД, только непосредственный код (программа) и результаты тестов выявят плюсы и минусы, но это ещё ничего не говорит о желании человека изменить своему инструменту. Код нужен разный, т.к. задачи не сводятся к сложению пары чисел и неравненствам. Здесь столько факторов, что можно все извилины скрутить. Особено в столь специфичных областях как цифровая техника - тут нужно образование соотв-щие иметь, а если не имеете - то не судите и не судимы будете теми кто имеет. В мировом масштабе рассуждать - дело спорное - о применении языков. А вот в желание человека лезть не надо. Тут и есть свобода. Ответственность у каждого своя и свои мозги на плечах.

Как мне как-то сказали: "Всю бы твою энергию да на реальные задачи."
С уважением, Вячеслав (радиоинженер).

[bugmaker]

Цитата:

Ещё мне интересно согласно каким отчётам что считать узкоспециализированным?

То, что предназначено решать узкий класс задач.

Цитата:

Я к тому, что споры на счёт языков не нужны.

Почему нет? В споре, как извесно, рождается истина. Там же, собственно, и подыхает

Цитата:

Они появляются, когда кого-то заставляют писать на том, что он не учил и чем пользуется хуже, чем чем-то другим.

Далеко не всегда. Мыслящий человек просто обязан всё время расширять круг своих познаний. Если есть подозрение, что какой-то инструмент может облегчить в дальнейшем жизнь, почему бы его не освоить и не использовать, буде он действительно окажется полезным?

Цитата:

КОД, только непосредственный код (программа) и результаты тестов выявят плюсы и минусы

Далеко не всегда. Как пример, функция на С, вычисляющая факториал, может быть просто и красиво записана как

long fac (long x) {return x ? x * fac (x-1) : 1;}

однако далеко не всегда даст корректно работающую программу. Нужно учитывать также и механизм распределения памяти. Что такое всегда одна строчка, освобождающая память? Как просто её напечатать вручную... Однако её можно легко забыть или в сложной программе расположить не там, где следует, и качество программы значительно упадёт, как и производительность труда программиста, за счёт большой затраты времени на отладку. И много ещё чего, особенно трудозатраты на создание этого самого кода. В конце концов и качество кода бывает разное.

Цитата:

А вот в желание человека лезть не надо. Тут и есть свобода. Ответственность у каждого своя и свои мозги на плечах.

Дык жалко же, живой человек ведь, а ему бейсик с дельфями...

[bugmaker]

Цитата:

VB сделал популярными такие понятия, как property, визуальные компоненты, компонентное программирование.

А тот факт, что VB намного тяжелее в обучении, гораздо менее эффективен в разработке, а также сам изготовлен весьма некачественно, чем современные ему средства, Вас не смущает? Или есть какие нибудь сомнения в точности приведённых мной характеристик?

Цитата:

Именно с этим связаны трудности перехода с VB6 на VB.NET, основные различия между ними – не языковые, а платформенные.

Нормально ли это, что язык программирования настолько зависит от платформы? Ведь остальные языки, как низкоуровневые, например С, так и высокоуровневые, как неоднократно мной упомянутый здесь лисп, если и имеют платформо-зависимые вещи, то весьма в небольшом количестве.

Цитата:

В промышленном программировании: а) мало читать только спецификацию; б) после двух дней изучения ничего толкового, кроме школярских упражнений, не пишут.

А что же ещё нужно? Ну, естественно, кроме специфичных для задачи алгоритмов и методов?

[нг]

Дискуссия о достоинствах Delphi vs. C++ выделена в отдельную тему.