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.
Если моя система никому не будет интересна то воспоминания о ней останутся только на этом форуме.

Шваров Евгенийmisha_shar,
Может быть Вам на Кикстартер ?

А можно по русски что все это значит? Я не силен в Английском.
Шваров ЕвгенийТолько чем результат будет лучше minimdb и gt.m?
minim и gt.m это реализации языка MUMPS. MSH это развитие MUMPS. Это разные языки. То что MUMPS надо развивать по моему это бесспорно иначе он умрет естественной смертью. Речь может идти только о том насколько MSH соответствует духу MUMPS и насколько необходимы предложенные изменения.

Шваров ЕвгенийА, Вы предлагаете развитие стандарта?
С другой стороны, и Cache, и gt.m и mini.m не только поддерживают стандарт MUMPS, но и развивают сам язык - конечно больше всего в этом направлении сделано в Cache, хотя тут я, естественно, субъективен.
Безусловно в Cache сделано больше всего и больше всего испорчен MUMPS. Расширения сделаны в разрез языка. Противоречат ему и не совместимы с ним.

Блок А.Н.misha_shar,

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

Блок А.Н.misha_shar,

если отбросить религиозную составляющую, чем же был испорчен язык М?
1. Процедуры введены в разрез идеологии MUMPS поэтому IS просит их не смешивать с MUMPS кодом. В смешанном коде сложно понять видимость переменных. Команда X выполняется как внешняя процедура и переменные в ней указанные не видны внутри неё.
2. Команда While ничего нового не дает.
3. Введено декларирование классов. MUMPS не декларативный язык.
4. Объекты порождают собственную структуру данных. Чего быть не должно.

Шваров Евгенийmisha_shar,
Может быть Вам на Кикстартер ?

Спасибо! Интересное предложение.

Блок А.Н.,
Я не возражаю. Если вам нравится эта помесь языков Си и MUMPS это ваше дело. Но я не думаю что это можно включить в стандарт.

DAiMor,
Процедуры, While, {}

DAiMorиии, это есть в огромном числе языков и все они таким образом на Си похожи ?
Язык Си во много раз сложнее чем MUMPS, и много чего еще есть, там есть и переменные которые есть и в MUMPS о ужас.
чем вас все это не угодило.
гораздо красивее блоки циклов и условий оформлены в фигурных скобках а не с точками, которые очень легко пропустить.
и процедуры, что вам в них не устраивает, почти все языки их имеют.
Язык Си оказал огромное влияние на другие языки например Java JS да и многие другие даже FreePascal заимствовал некоторые операции из Си. Я ничего не имею против Си. Некоторые конструкции в нем удачней чем в MUMPS. Я только против неудачного сваливания в кучу разных архитектурных схем. Процедуры меня устраивают они не устраивают команду New. Си не сложнее MUMPSa а проще. Оператор MUMPS Set A=1 выполняет гораздо больше работы оператор Си A=1; У этих языков совершенно разные ниши. И против фигурных скобок я ничего не имею против но в языке должно быть что то одно либо то либо другое. Точки в MUMPSe я тоже считаю неудачным выбором.

Alexey MaslovЕдва ли имеет смысл всерьёз говорить о выпуске нового стандарта языка. Вам же Эд де Моель, кажется, отписался о текущем состоянии MDC, который вот уже 15 лет как бездействует, и совершенно непонятно, что может вывести его из этого состояния. Вся надежда была на вас ))), но похоже MSH не вызвал интереса и за океаном.
ИМХО, ISC поступила абсолютно правильно, вставив в язык то, что посчитала нужным, но сохранив совместимость с классическим M, тем самым оставив пользователям выбор, насколько далеко идти за ними.
А я все помню я был не пьяный...
Я ему снова написал.
Но если не двигаться то прогресса не будет. Надо работать. Делать реализацию. Я надеюсь что все же дело сдвинится с мертвой точки. Прошлые мои предложения Эд де Моель переслал в какой то университет. Я так понял что кто то все же занимается MUMPSом.

DAiMormisha_shar,

А давайте так, вы создадите свою первую реализацию, запустите на этом какой-нибудь крупный проект.
А мы посмотрим на все это дело.
Да это конечно удобное решение. Так и придется делать. Дело только очень трудоемкое. Надо написать не просто транслятор но и среду разработки. Я расчитываю использовать NetBeans в качестве среды разработки только там почти вся документация на Английском и это напрягает. Разработку MSH на Си я делаю в NetBeans думаю со временем осилю.

В спецификацию языка внес изменения:
раздел 5. Переменные
Было:
4. Аргументы передаваемые в подпрограмму. Они имеют префикс ^.
1. Структура сплошного массива.
Эта структура имеет один целочисленный индекс. Все элементы массива расположены подряд. Эта структура применяется для быстрого доступа к данным. Индекс массива внутри фигурных скобок {}

Например : {25}
Таких массивов 4:
2.1 Массив приложения %%{ind}
2.2 Массив задания %{ind}
2.3 Массив блока Run {ind}
2.4 Массив аргументов ^{ind}

Стало:
4. Аргументы передаваемые в подпрограмму. Они имеют префикс @.
2. Структура сплошного массива. Эта структура имеет один целочисленный индекс. Все элементы массива расположены подряд. Эта структура применяется для быстрого доступа к данным. Индекс массива следует за знаком $
Например : $25
Таких массивов 4:
2.1 Массив приложения %%$ind
2.2 Массив задания %$ind
2.3 Массив блока Run $ind
Массив Аргументов имеет префикс @
2.4 Массив аргументов @ind


Раздел 10. Списки.
Было:
Любая переменная может быть списком. Список состоит из одного или нескольких значений. Значения могут быть любых типов в том числе и списками. Список может быть создан либо специальной конструкцией либо возвращен аргументом команды Query.
Создать cписок можно конструкцией:
ref=[exp[,exp]]@
ref — ссылка на переменную куда будет записан список.
exp — выражение которое станет соответствующим элементом списка.

Развернуть список в индексы:
[@ref]
Ссылка ref будет развернута.Каждый элемент списка станет соответствующим индексом. В ссылке обычные индексы могут чередоваться со списками. Например переменная может выглядеть так :
[Af,@[B,2],125,@{1},5.6]
если переменные[B,2] и {1} являются списками то они будут развернуты в индексы в соответствии с размером списка.

Стало:
Любая переменная может быть списком. Список состоит из одного или нескольких значений. Значения могут быть любых типов в том числе и списками.
Создать cписок можно конструкцией:
ref={exp[,exp]}
ref — ссылка на переменную куда будет записан список.
exp — выражение которое станет соответствующим элементом списка.
Список может быть также возвращен командой Query.

Если ссылка ref является списком то в индексе она будет развернута в соответствующее количество индексов.
[ref]
Каждый элемент списка станет соответствующим индексом. В ссылке обычные индексы могут чередоваться со списками. Например переменная может выглядеть так :
[Af,[B,2],125,$1,5.6]
если переменные[B,2] и $1 являются списками то они будут развернуты в индексы в соответствии с размером списка.

Полный текст спецификации приведен во вложении.

Работу над языком я начал. В первом приближении на Си написана система ведения локальных и глобальных данных. Нужна помощь в отладке. У кого есть возможность и желание прошу помочь. Разработка ведется в Linux в системе NetBeans 7.4 С предложениями пишите в email
misha_shar53@mail.ru

misha_shar,
Вариант языка на данный момент.

DAiMormisha_sharmisha_shar,
Вариант языка на данный момент.

http://www.sql.ru/forum/actualfile.aspx?id=18457590] Приложенный файл (MSH_COMPLETE_ru_108.doc - 101Kb) Что-то не нашел там нативного JSON. Не взлетит. Хотя было бы чему взлетать ?
Там много чего еще нет. Взлетит не взлетит, время покажет. Ваше мнение я учел.

misha_shar,
Спасибо за моральную поддержку.