MUMPS замечательный язык. Он обладает многими уникальными свойствами. Но в мире программирования он мало известен. Этому есть причины. Я считаю что таких причин несколько.
1. теоретики от программирования считают его неправильным,
2. отсутствие средств построения клиентской части.
3. язык не получил средств визуальной разработки,
Возможно были и другие причины. Первая причина по моему связана с отсутствием в языке декларирования переменных. С моей точки зрения это свойство языка является его сильной стороной. При проектировании декларации уничтожают гибкость языка. Практики от программирования пытаются ослабить типизацию. Языки типа JavaScript яркое тому подтверждение. Но теоретики тянут одеяло на себя и появляется ActionScript. Только почему то никому не приходит в голову отказаться от декларирования переменных вообще. В этом отношении язык MUMPS единственный находящийся на верном пути. MUMPS имеет самые мощные механизмы манипулирования данными в этом ему нет равных среди языков программирования.
Вторая причина с развитием браузеров и языка HTML полностью потеряла свою актуальность. Клиентская часть должна строиться не средствами языка программирования, а средствами специализированного языка браузеров.
Третья причина тесно связана со второй. Средства визуальной разработки должен иметь HTML а не язык программирования. Поэтому я считаю что приходит время языка MUMPS и уверен в его перспективах. Но сам язык практически не развивался с момента своего создания и на данный момент с моей точки зрения довольно архаичен. Современный язык должен быть объектным. И желательно чтобы он поддерживал известные методы программирования. Таковыми я считаю средства обработки событий. Средств построения диалогов я считаю в нем не должно быть вообще. Это задача специализированного языка.
Поэтому нужен новый язык построенный в духе MUMPS. Я попытаюсь создать такой язык и предлагаю вашему вниманию спецификацию такого языка MSH. Хотел бы услышать ваше мнение.

Alexey MaslovСамыми живучими оказываются языки, возникшие для решения реальных задач, а не придуманные теоретиками. Даже если выяснялось, что первые версии языка "не очень" (что нормально), важность задачи вытягивала язык. Примеры приводить не буду, они и так у всех на слуху.
Мысль не понял. А теоретиком я себя никогда не считал.

Alexey MaslovКакая сверхзадача стоит перед вами, Михаил, для которой, на ваш взгляд, требуется разработка нового ЯП, т.е. не подходит ни один из существующих?

Подходит и это язык MUMPS. Но он требует доработки. Почему я по моему объяснил.
Alexey MaslovВот Роб Твидд, которого тут уже не раз цитировали, предлагает в новых разработках переходить на серверный JavaScript (Node.js). Мне кажется, для привлечения новых сил в M-сообщество в этом больше смысла, чем в попытке придумать новый сверхязык. У нас, например, уже появилась пара новых разработчиков, которые раньше M/COS на дух не переносили.
JavaScript - язык уступающий MUMPS. Заниматься им никакого смысла нет. Надо разрабатывать MUMPS.

Alexey MaslovНемного упрощая: Си возник для разработки UNIX. JavaScript - для разработки динамических web-страниц. И т.д. Даже если языки оказались чем-то плохи, задачи их "вытянули". На них пишут сотни тысяч, и даже миллионы.
Количество пишущих не аргумент. Для разработки динамических web-страниц MUMPS подходит гораздо лучше.
Alexey MaslovЯ не предлагаю им заниматься, и вовсе не обязательно - JS. Важна сама идея - интеграции популярного языка с малоизвестной, но мощной М-средой.
При создании удачной версии MSH я думаю что он станет популярнее JS. Я собственно хочу этого и добиться.
misha_sharНадо разрабатывать MUMPS.Alexey MaslovА вот это вряд ли...
Категорически не согласен. Если бы ресурсы потраченные на Java или JS были вложены в MUMPS то эти языки навряд ли бы понадобились вообще.
Беда MUMPSa в отсутствии современной спецификации языка и отсутствии вменяемой реализации хотя бы близко сопоставимой хотя бы с той же Java.

DirksDRD_De1mos Мне кажется, что писать сейчас серьезное приложение основанное на программах и подпрограммах несколько не удобно...
Что Вы имеете ввиду? Намекаете, что весь код надо засунуть в объекты и методы? Или другое?

MSH позволяет обращаться к модулям программам как к программам так и как к свойствам объектов.
DirksDRПо топику:
Из свойств языка, которые автор называет "средствами"

(извиняюсь, я перенумеровал их, чтобы ссылаться)

1-е свойство я понимаю, как "легкочитаемость" программ, с этой точки зрения даже сокращение команд MUMPS вредно.
Свойство 3, имхо, противоречит 1-у свойству. Насколько "легкочитаемы" будут программы на MSH
судить не берусь, хорошо бы увидеть фрагмент такой программы с комментариями.

Противоречия нет . Чем короче программа тем легче она читается.
DirksDR2-е (и 6-е) свойство - чем обеспечивается? Отсутствие деклараций имен переменных этому, опять же имху, не способствует.

Отсутствие деклараций имен переменных этому способствует. Но главное в том что MUMPS полностью управляет переменными и не допускает прямого обращения к памяти. Это ликвидирует 80% ошибок в программах.
DirksDRЛично я всегда ставлю Option Explicit, когда программирую на VBA, и исправляю тем ошибки написания переменных.
Уменьшение ошибок может дать повышение уровня языка. В команде Object.Save трудней сделать ошибку, чем в самописной
программе сохранения данных (с индексами и пр.). То же с командой SELECT...

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

DirksDR4 и 5 - не понял, что под этим понимается и чем обеспечивается.

4 свойство обеспечивается тем что MUMPS полностью управляет переменными и не допускает прямого обращения к памяти.
5 свойство обеспечивается наличием в языке команд управления транзакциями.

Onix_misha_shar,

в итоге выродится в М-ОС, с чего начался unix, тем похоже и закончится..
всё упирается не только в язык, а в данные которые мы обрабатываем, храним, собираем...

Например, сделай файловую для линуха в духе mumps и получи систему , вообще ни на что не похожую. Будет даже круче, чем все существующие файловые системы/вклюяая reiser/.

и потом , не востребовано будет, технарям может и интересно, а бизнес пройдет мимо.

а над файловой подумай..
Вполне разумная мысль. В свое время существовала ОС DSM 11 основанная только на MUMPSe. И она была востребована. И будет востребованной. Все зависит от реализации.

D_De1mosmisha_shar,

Прочитал приложенный документ. Мне кажется, что писать сейчас серьезное приложение основанное на программах и подпрограммах несколько не удобно (но это лично мое мнение), а концепции программирования мне кажется охвачены немного не полностью.
Но больше всего меня заинтересовали ограничения на длины наименований в 29 и 20 байт, за что вы так людей не любите?
Ограничение на длину связано со скоростью трансляции. Если не вводить каких то ограничений то она может и будет работать но использовать ее навряд ли будет возможно.Трансляция критична по времени так как язык имеет оператор Execute. И трансляцию будет необходимо выполнять во время выполнения программ.

Блок А.Н.misha_shar,
Я повторю вопрос, который уже кто-то задавал выше: ради чего?
Для вас факт того, что язык новый - плюс (саморазвитие, самореализация), для всех остальных новизна - огромный минус.

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

Пока речь идет о спецификации языка. А эти проблемы будет решать тот кто сделает реализацию языка. Все перечисленные проблемы являются обычными для любого языка и их необходимо решать.
Блок А.Н. Я пока револючионных изменений не увидел.
Что вы положите на другую чашу весов? Сомнительное улучшение читаемости и удобства программирования? Вряд ли это стоит того.
Вот в каше действительно революционные изменения - интеграция идеи языка М c объектной и реляционной парадигмой. Причем интеграция не только М-Объекты и М-SQL, но и SQL-Объекты.

То что вы не обнаружили изменений меня конечно больше всего удручает. Объекты в язык введены и сделано это в отличии от Cache правильно не нарушаю структуры данных. SQL - я считаю не только ненужным но и вредным дополнением. На данный момент SQL- является стандартным методом доступа, но с появлением в JS прямых запросов он становится не единственным. Достаточно написать удобный интерфейс к браузеру и необходимость в SQL доступе отпадет.
Блок А.Н.Смотрите, вы не можете убедить даже профессионально близких вам коллег. Представьте, что вам придется проводить агитацию среди программистов MSSQL,Oracle, C#. Попробуйте убедить владельцев бизнеса купить систему с вашим языком.

Попробую.
Блок А.Н.Я в студенчестве был фанатом языка С++. Умел на нем много (для студента). Со временем понял, что многие его плюсы на самом деле являются минусами. Понял, что мой фанатизм был во многом из-за перекоса знаний, когда о чем-то знаешь много, а о другом не знаешь почти ничего. Вы мне сейчас меня тогдашнего напоминаете :)
И о чем это я ничено не знаю?

Блок А.Н.misha_shar -Простотой и наглядностью программ.
-Минимально возможных ошибок в программе.
-Программы должны содержать минимум строк.

Сокращение времени сопровождения достигается следующими средствами:
-Надежностью языка.
-Язык должен иметь средства обеспечения целостности данных.
-Минимально возможных ошибок в программе.
Простите за хамство, но из выделенных приоритетов я делаю вывод, что вы программист, причем больше частью кодирующий программист. Ничего из этого не является ключевым для языка. Мало того, многие даже не особо относится к языку.

Да я кодирующий программист. А вы я так понимаю почти что полубог и точно знаете что является ключевым для языка , а что нет. А вот при сопровождении программного продукта это почему то является ключевым.
Блок А.Н.- Простота и наглядность программ - это к культуре программирования. В целом языки выше уровня ассемблера и не являющиеся брейнфаком достаточно наглядны. Я не так чтобы много видел, но в любом случае это не является проблемой. Писать w или write, o или open - да нет никакой разницы.

Культура программирования необходима. Но свойства языка либо способствуют этому либо нет. И разница в объеме программы на Си и MUMPSe колосальна.
Блок А.Н.- Минимально возможных ошибок в программе. - В языке могут быть такие атавизмы, как видимость переменных на всех уровнях стека, заложенные мины, как свободная работа с памятью или похожесть разных операторов. Но в целом все это решается культурой разработки и нормально поставленным процессом тестирования.

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

В информационной системе к арифметике как раз и не сводится. Основной объем кода занимается манипулированием данными.
Блок А.Н. -Надежностью языка. Простите, я не понял. Как язык может быть надежным или ненадежным? Может быть глючной среда, но не язык.

-Язык должен иметь средства обеспечения целостности данных. - Опять не понял.

-Минимально возможных ошибок в программе. - ээ, мы не повторяемся?

Язык как раз и может быть надежным и не надежным. Попробуйте написать не травиальную программу на Си и на MUMPSe и почувствуйте разницу.
Блок А.Н.-----------------------------------------
Так вот, все это фигня. И количество строк, и подверженность языка ошибкам.
А не фигня, когда в системе, состоящей из сотен модулей, тысяч (а может и десятков тысяч) программ/процедур/методов вдруг внезапно и очень срочно нужно что-то изменить. Может быть, изменить структуру хранение нескольких сущностей. Что вы будете делать на своем MSH? Или когда нужно сконструировать что-то, от чего даже у постановщиков задач мозги начинают плавиться, а реализаторам еще приходится учитывать уже существующую структуру из вот этих вот сотен моделей? Как поможет вам различие читаемости оператора w и write? Да никак.
А поможет вам то, какие парадигмы может поддерживать ваша система.
Поддерживает объектно-ориентированную - хорошо, можно будет развязать логику системы на максимально незавимые модули и отдельно внутри модулей делать правки, учитывая не сотни сущностей, а уже десятки. (Да простят меня апологеты ООП за ошибки в высказывании)
Поддерживает SQL - замечательно, можно будет строить,модифицировать структуры данных и также быстро писать программы по работе с ними.
Поддерживает М - круто, можно будет строить супербыстрые алгоримты обработки данных в критичных местах.
Поддерживает многопоточность - ура, сможем построить систему, в которой будет работать десятки и сотни людей, а на тяжелых алгоритмах максимально использовать мощности сервера.

misha_shar, вы можете предложить это? Или быть может, у вас есть в рукаве парадигма, которую я не перечислил и которой нет, например, в каше? Тогда ваша система кому-то, возможно, будет интересна.
Фигня вашы высказывания. Судя по тексту вы не кодировщик, а теоретик. Это тоже хорошо. Но поверьте у меня есть опыт написания и сопровождения большого информационного комплекса и я знаю что пишу. Язык не заменит голову но при наличии головы позволит написать программный комплекс который можно сопровождать.
Cache все что нужно реализовал и реализовал даже то что не нужно но сделал это сломав язык MUMPS.
Если моя система никому не будет интересна то воспоминания о ней останутся только на этом форуме.