С практической точки зрения - это попытка сделать нечто лучшеe, чем UML, ER?
(Бегло посмотрел текст).

Насколько знаком с областью языков спецификаций - побеждают те языки, у которых больше
отношений [полезность]/[сложность]. (Товарная аналогия - качество/цена).

Эти изыскания по созданию универсального языка спецификаций напоминают изыскания по созданию "вечного двигателя". Такой Perpetuum mobile в IT.

Чтобы эдак на естественного языке писать, а компьютер понимал и выполнял.

P.S. В одной из организ., где работал раньше, пытались применить язык Z-спецификаций
Z , придуманный в Oxford University.
Хотя это не на естественном языка, но на языке математических нотаций. Вообще в Штатах,
Канаде и Европе даже есть софт для написания спецификаций на Z и даже трансляции Z в языки программирования.

К "перпетуум мобиле ИТ"
Противоречит "закону сохрания смысла":
Сколько смысла сможешь выразить формально,
столько и воплотится компьютерно.
А естественные языки неформальны по сути.

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


Заказчик скорее особо не мыслит, а выражает желания: ЭСКИЗ ТЕХН. ЗАДАНИЯ. Потом программисты переписывают технич. задание, приведя иррациональные пожелания к техническим возможностям (и своим возможностям). Программирование само неформально, но продукт программирования формальная запись. Также и жизнь - все, кто может думать, думают неформально, но продукт - формальные действия, движения, ...


vkoaes
Спрашивается, как помочь этому процессу? Давайте все выражать на языке Эллочки Щукиной (Ильф и Петров, 12 стульев), на котором, собственно, и говорят современные программисты. Или попробуем развивать выразительные возможности используемых языков. Можно закрыть глаза на эту проблему, однако основной вектор развития технологий программирования направлен именно в эту сторону (язык Z спецификаций в Оксфорде, система Масима Кизуба SymADE, Intentional Programming Чарзльза Симони, meta-programming system питерских JetBrains, Nemerle и др.)


А у меня в ВУЗ-е был курс, где программировали на 0 и 1. Программа - цепочка 0 и 1.
Это с какой-то точки зрения язык Эллочки-людоедки! (Хотя для составления такой программы использовались методы дискретной математики - ПОМОЩЬ).
Но ведь Элочка по жизни была не такой уж дурой. (Может быть она мощно думает в своих
слово-невыразимых формах.) Она
с помощью своих 0 и 1 (не более десятка слов) тоже строила сложные
мысли-поступки-программы своего поведения. Плюс неформальный эмоциональный фон.

vkoaes
Многие возражения понятны - психологически трудно согласится с потерей стольких лет, потраченных на изучение неестественного языка низкого уровня (С, С++, С#, Java, и др.). Однако, история показывает, что все меняется. Изменяются и языки программирования.

А разве потеря - изучение ассемблеров?
Вообще всякое знание - разве потеря?
Потеря наверно тогда, когда при "деланиях и думаниях" не приобретены новые знания и новый опыт.
Delphi С++ Java останутся как и остались ассемблеры, которые для определенных задач незаменимы. Так и Delphi C++ Java.
Диалеты ЛИСП-а и Пролога красивы, но не практичны для создания полноценных ИС.
Может быть ПОКА непрактичны.
Nemerle красиво, но ещё непрактично из-за того, что метапрограммно не всем удается думать,
а ведь надо еще ошибки искать, разбираться почему сбои, стыковаться с драйверами периферии, ... Так и остальное.

vkoaesУ AlexandrPlus нашел ключевую фразу, которая, по-моему, отличает подход в диссертации от других - "метапрограммно не всем удается думать". А зачем, спрашивается, как-то неестественно и особым образом думать при создании программ?

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

Конечно, это вызывает определенный "напряг" у программиста, требует от него другой парадигмы постановки и решения задач. И этому тоже надо учиться.

?? в тексте - записывается на русском языке структура и алгоритм решения задачи, называя это понятийным анализом, потом под это якобы строится некоторая виртуальная машина - алгоритм реализуется на машине Тьюринга или нормальных алгоритмах Маркова или на ассемблере

Собственно просто ПРОГРАММИРУЕТСЯ эта виртуальная машина. Примитивы команд для всех задач виртуальной машины одни и теже - примитивы. Так можно напрямую программировать виртуальную машину Java без Java или виртуальную машину Net без С# на языке CRL.

???????? обман или непонимание чего ?????????

P.S. Языки спецификаций - это приближение к естественному языку настолько насколько могут, чтобы остаться формальными для возможности автоматического отображения в программный код.

авторvkoaes
... - пусть прикладной программист сам пишет себе язык. Для этого не надо продвинутости языковых программистов - определение прикладного языка стало доступно на прикладном уровне.

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


Так из истории известно, что до появления C, Pascal, Basic, ... на каждом крупном предприятии под решения своих задач создавался свой макроязык, чтобы не морочится на ассемблере, вникая и тяжело осваивая множество разных сложных моментов, не нужных для решения задач в рамках модели класса задач. ПРОГРАММИСТЫ сами для себя СОЗДАВАЛИ СВОИ ЯЗЫКИ.
И потом увидев во всех языках нечто общее и обобщив многие моменты появлялись С и Pascal. Это наверно была одна из причин нужности языков более высокого уровня.

И что - предлагать программисту под свои задачи создавать свой язык, чтобы получилось нечто не на много отличное от программ Delphi, С++, Java, Python, Ruby, Forth, Scheme, ...

То есть с чего это "определение прикладного языка стало доступно на прикладном уровне".
Метапрограммирование вроде это не обеспечит и не для этого и не о том.

Известна шутка язык NecroSoft


И как полушутка: для заказчика - программу, которая выглядит как его эскизное техническое задание.

vkoaes
Вот и получается, что от технологии переходим к метатехнологии, т.е. совершаем метапереход по терминологии Турчина [Турчин. Феномен науки. 2000]. ...

Это слишком обобщенное философское ессе. И наверно имеется в виду не мета- (что-то между чем-то и чем-то разного уровня и разного рода), а супертехнологии.
Технологии, создающие технологии. -> Самовоспроизводящиеся машины. ... И прочее такого рода.

Турчин конечно вне критики.
Будучи физиком, создал РЕФАЛ.
А какой ёщё язык программ., созданный в России, известен в мире?
P.S. К тому же вопросу - НАВЕРНО в тех организациях, где работал, создавали свой язык под свои задачи. Не с того, ни с сего дома для жены из любви к искусству не стал бы язык создавать НАВЕРНО.

vkoaes что-то не все так гладко в современной индустрии программирования. Подтверждение этого - перманентное развитие языковых средств. Причем это развитие не определяется только совершенстованием железа. Скорее всего новая платформа позволяет реализовать в языке то, что раньше было невозомжно или неэффективно.


Вроде времена, когда на программирование тратились гиганские усилия, остались в прошлом,
но инструментарий став эффективным, стал сложным и многозначным. Порядок внесло объектно-ориентир. программ., но оно добавило ещё сложность. Плата за простоту - тяжелость и силовремязатратность, плата за универсальность - сложность. Но для умников программирование стало в радость. Работяги, но тугодумы, но которые были ценны для преодоления рутинных моментов, оказались не нужны.

Вроде уже хард и софт развиваются независимо, не влияя друг на друга. (Здесь и виртуальные машины - с хардом только виртуальная машина. Пробовали создавать специальные виртуальные машины под, например, Пролог.). Но вот грядут нанокомпьтерные архитектуры, что может повлиять на софт у основания, так как ассемблеры обещают быть
иными. Хотя наноархитектуры не заменят традиционные, а встанут рядом.

vkoaes
AlexandrPlusТо есть с чего это "определение прикладного языка стало доступно на прикладном уровне".
Судя по всему, основная проблема конструирования прикладных языков - отсутствие эффективных и простых методов описания их семантики. Почему это сейчас стало доступным? Наверное потому, что предложено семантику описывать не на жестко заданных семантических языках, например: аксиоматически (путем сопоставления продукциям грамматики формул аксиоматической теории), алгебраически (сопоставление продукций формул алгебраической теории), денотационно (сопоставление функциональных донотатов), операционно (сопоставление командам процессора), а индуктивно, т.е. определять синтаксический и семантический языки одновременно и взаимо-обусловленно.


Всё же семантика в теории формальных языков для абстрагирования от того, что принципиально
формально нерассмотримо.

vkoaes
AlexandrPlus Метапрограммирование вроде это не обеспечит и не для этого и не о том.
Конечно, метапрограммирование – это, образно выражаясь, программирование програмами, т.е. такое программирование, при котором в качестве обрабатываемых данных выступают не типы данных, а программы. Реализацию такого подхода можно посмотреть у последователей Турчина [Абрамов, Методы метавычислений и их применение, 2006]. Согласен, что в обсуждаемом тексте этого нет. Хотя Турчин назвал свой Рефал почему-то метаалгоритмическим языком [Турчин, Метаалгоритмический язык, Кибернетика, 1968]. Дыма без огня не бывает.

На Рефале очень удобно и лихо писать трансляторы. (Упражнялся как-то в реализации символьных вычислений на Рефале). Транслятор и есть программа, которая генерирует программы, которые в свою очередь тоже могут генерировать программы.
Фантазия сразу же ставит вопрос - так может быть сделать транслятор с естественного языка?
Вот и изыскания в метавычислениях.
У меня был знакомый, который писал на Рефале трансляторы для разного встроенных микропроцессорных систем и станков с ЧПУ. Для станков с ЧПУ существует некий стандарт, которому уже более 40 лет, и который был заточен для ввода С ПЕРФОЛЕНТ. Само собой - команды лишь примитивные перемещения и переключения. Само собой очень нужен более человеко-ориентированный язык для программирования станка, где бы просто можно было задавать траекторию движения инструмента во времени, комплексно управлять всем оборудованием станка в понятиях технолога (такой тоже "понятийный анализ" при создании языка), просто модифицировать уже написанные программы, ...
Рефал был очень уместен и полезен.

AlexandrPlusНа Рефале очень удобно и лихо писать трансляторы. (Упражнялся как-то в реализации символьных вычислений на Рефале). Транслятор и есть программа, которая генерирует программы, которые в свою очередь тоже могут генерировать программы.
Фантазия сразу же ставит вопрос - так может быть сделать транслятор с естественного языка?
Вот и изыскания в метавычислениях.
У меня был знакомый, который писал на Рефале трансляторы для разного встроенных микропроцессорных систем и станков с ЧПУ. Для станков с ЧПУ существует некий стандарт, которому уже более 40 лет, и который был заточен для ввода С ПЕРФОЛЕНТ. Само собой - команды лишь примитивные перемещения и переключения. Само собой очень нужен более человеко-ориентированный язык для программирования станка, где бы просто можно было задавать траекторию движения инструмента во времени, комплексно управлять всем оборудованием станка в понятиях технолога (такой тоже "понятийный анализ" при создании языка), просто модифицировать уже написанные программы, ...
Рефал был очень уместен и полезен.

То есть для этого класса задач (программирование станков с ЧПУ) программист стал не нужен и технолог сам программирует станок.
И аналогичное будет со всем прикладным программированием.
То есть прикладное программирование будет все легче в смысле малых силовремязатрат, но при этом сложнее и сложнее, но дойдя до какого-то пика потом случится революция и сложность начнет уменьшатся.
И заказчик будет сам программировать свои задачи, только могут быть сложные алгоритмы - но это вопросы уже не программирования, а к математикам, инженерам-техногогам, экономистам, юристам, ...
Будут фирмы, которые будут создавать системные программы и инструментарии.
Будут сервис-фирмы - ремонт и сопровождение систем и инструментария.
Будут тюнинг-фирмы - для создания чего-то штучного, навороченного и экзотичного.

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

Хотя это тоже шаги эволюции - если вспомнить Жигули, то водитель должен был понимать в деталях не только - как всё работает, но мог сам ремонтировать и даже сам создавать новые сови автомобили из разных вроде неподходящих деталей. Жигули - как игрушка "сделай сам".