Мои соображения по поводу языка MUMPS.
Язык М процедурный язык этим он похож на остальные языки типа С, явы, паскаля. Но М отличается от них
несколькими принципиальными моментами:
1. Управление задачами. Язык М единственный имеет встроенное средство порождения задачи.
Это команда JOB. Можете сравнить это с созданием класса потока в других языках.
2.Управление данными. Переменная возникает в момент ее использования.
Локальная переменная так же может быть создана командой NEW.
Я считаю что это минимальный и гибкий механизм управления данными хотя он с моей точки зрения
недостаточно изолирует локальные переменные.
3.Описание данных. Оно в М отсутствует это принципиальное отличие языка . Благодаря этому
в М отсутствуют ссылочные данные и связанные с ними ошибки. Из моего опыта 80% ошибок в программе
на других языках это обращение к несуществующим данным. В результате сколько нибудь большые
проекты на этих языках практически не отлажены. В М таких ошибок вообще не бывает. Основной
ошибкой в М программах неопределенная переменная. Эта ошибка легко локализуется и исправляется.
Программы на М поэтому легко и быстро отлаживаются.
Описание переменных в других языках создает для них же колосальные трудности которые они затем
героически преодолевают. В Паскале огромная библиотека программ многие из которых отличаются
только типом передаваемых параметров либо возвращаемых значений. В М по сравнению с Паскалем
библиотечных функций совсем мало но они функционально полнее библиотеки Паскаля. После встроенных
функций языка М библиотеки на других языках оставляют впечатление сумбурной кучи бессвязных
программ.
4. Переменные в М являются деревьями. Это значит что это готовые структуры данных. Дерево
является частью языка М. Другие языки встроенных структур данных неимеют вообще. А примитивные
структуры реализованы в виде библиотеки классов. Такими классами в яве являются списки, карты,очереди.
Нет необходимости говорить что возможности дерева значительно шире и работать с ним намного проще.
Большая часть кода в проектах занимается работой со структурами данных и во многих случаях
мне вообще не важно знать тип данных. Тип данных становится важным в основном при вводе и проверке
данных а это незначительная часть кода приложения да и тип данных мне в этом случае мало помогает.
Получается что я выполняю описание переменных не для себя а для транслятора.
Благодаря этим особенностям язык MUMPS является компактным, мощным и надежным языком
программирования и ему нет равных среди других языков.

Да слова Вадима подтверждают высказывание предыдущего оратора, что IS ориентируется не на МИМПС а на другие технологии. С точки зрения коммерции может быть это и оправдано, но с точки зрения технологии МИМПС безусловно нет. Они свели МИМПС к языку базы данных.

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

{
Тут на самом деле ситуация не настолько хороша - ибо помимо UNDEFINED есть
еще и SUBSCRIPT - а это ошибка куда неприятнее будет.
}
Ошибка неприятная но не смертельная. И возникант она только при прямом
обращении к глобали. При обходе дерева она возникнуть не может. И если
не использовать ассоциированые массивы то мест ее возникновения
не так уж много. Ну в конце концов не одна а две ошибки.
{Деревья.
Это несомненный плюс... с точки зрения языка и алгоритмов обработки, но
с точки зрения хранения глобалов это, как не странно, еще и ахиллесова пята -
ибо ряд задач - например последовательная выборка большого объема -
на деревьях работает медленнее.
}
Самых быстрых структур для всех организаций данных пока не открыто.
Если у тебя преобладает последовательная организация данных. То
их хранить надо в обыкновенных файлах. И будешь иметь самый быстрый
доступ к данным.
{
Мне кажется, что InterSystems ориентируется прежде всего на своих клиентов, а не на MUMPS или технологии.
В WRC для этого есть специальный тип запроса на новую функциональность или её улучшение.
}

Все что я написал не для того чтобы расхвалить МИМПС. С современной точки зрения
это довольно архаичный язык. Но это самый перспективный из языков. Минимальных
изменений достаточно чтобы довести его. Я хочу предложить форумчанам свои
предложения по совершенствованию МАМПСА. Я их написал и отправил в комитет
по развитию языка, в ИнтерСистем, в GTM, MIniM. Далее привожу текст письма.

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

1.Локальные переменные за исключением начинающихся с % должны быль
локализованы внутри вызова подпрограммы (команда DO) или вызова функции.
А вот внутри вызова команды XECUTE (X) локализовать переменные нельзя.
2.Ввести команду конец блока для блочных команд.
DO (D)
ENDDO (END)

IF (I)
ENDIF (END)

ELSE (E)
ENDELSE(END)

FOR (F)
ENDFOR(F)
3.Ввести команду CASE
CASE выражение
M1 END
M2 END
ENDCASE (END)
Значение выражения должно соответствовать именам меток
4. Расширить синтаксис команды FOR для обхода деревьев.
FORO имя_узла:DAN:IND
ENDFOR
DAN – переменная куда помещается значение
IND - значение выбранного индекса

FORQ имя_узла:DAN:REF
ENDFOR
REF- ссылка на выбранный узел.

5, Модифицировать команду NEW добавив префиксное описание переменных.
Например NEW pref*

6.Ввести системную функцию которая бы производила разбор выражения глобальной ссылки.
Давала либо имя переменной либо любые из индексов.

7.Синтаксис вызова программ с передачей параметров по имени неудачен.
Можно вообще отказаться от этой конструкции никаких новых возможностей это не дает. А параметр по имени можно передавать с помощью передачи параметра по значению а использовать в виде косвенного обращения. Например
Вызов по имени:
D A(.B)
A(X) X=1 Q
Вызов по значению:
D A(“B”)
A(X) @X=1 Q
Результат будет аналогичным. И применение точки неудачно.

7.Время в командах ожидания должно задаваться в милисекундах а не в секундах.
Команды HANG, READ,OPEN,JOB.
8.Надо ввести систему обработки событий Для этого использовать индексированную
системную переменную $EVENT В узлах которой должны быть ссылки на программы обработки.
первый уровень индекса должен определять тип события которое надо обрабатывать.
$EVENT(“ER”) ошибки в программе
второй индекс здесь сама ошибка.
$EVENT(“IO”) события ввода вывода — открытие закрытие чтение, запись.
2-индекс вид события открытие закрытие чтение, запись
3-й индекс имя устройства

$EVENT(“TIME”) события таймера.

$EVENT(“VL”) обращение к переменной
2-индекс вид события чтение, запись
3-й индекс имя переменной

$EVENT(“WN”) события возникающие в интерфейсе пользователя.
И тал далее.
9. Надо создать систему работы с оконным интерфейсом пользователя и для этого использовать индексированую системную переменную $WINDOWS в узды этой переменной разместить компоненты пользовательского интерфейса. Обработку событий пользовательского интерфейса организовать на основе системной переменной $EVENT -рассмотрена ранее.

10. Ввести объекты. Этот пункт требует дополнительных пояснений.
Как известно программные системы это структуры + данные. Структуры могут быть
представлены либо реляционными таблицами либо деревьями либо массой других структур (в JAVA это LIST, MAP)
Ясно что в области структур у MUMPSa нет достойных конкурентов. А вот описание данных на основе
классов развивалось очень бурно. Ясно что любой современный язык должен предлагать
какую то модель классов. Но идеология MUMPSa не содержит описаний переменных и поэтому
классический подход по введению CLASS в MUMPSe не подходит. Значит необходим другой путь.
И он есть с помощью программ. Ввести понятие программного модуля. Каждый такой модуль
должен соответствовать CLASS. Каждому свойству поставить в соответствие точку входа в
этом модуле. Все свойства определить через методы. Ввести стандартные методы get,set,new
Точку входа определить как имя свойства_'.'_имя метода.
Внутри модуля определить перечень локальных переменных модуля. Которые могут быть видны
только внутри методов данного модуля.Это будет аналог privat varibles.
Аналог public valibles это свойства определяемые методами get, set. В метод new передавать ссылку
на узел которой будет соответствовать объект. Сами свойства определяются методами set , get и
могут хранится как в глобальных так и в локальных переменных на усмотрение программиста.
В методе new записывать имя модуля в специальную переменную модуля например CLASS.
И при последующих обращениях к переменной поиск методов осуществлять на основе этого значения.

CLASS должен поддерживать:
- Инкапсуляцию — это реализуется свойствами(public) и переменными модуля(private) этого достаточно.
-Наследование в заголовок модуля добавить утверждение extends за которым поместить перечень
наследуемых модулей. Реализацию наследования организовать вызовом либо метода модуля,
а если его нет то продолжить поиск в родительских модулях.
-Полиморфизм это требование в этой модели выполняется автоматически так как отсутствует
явное описание CLASS.
В результате мы получим полное соответствие модели CLASS.
Мне бы хотелось чтобы MUMPS занял среди языков программирования достойное место благодаря
его уникальным возможностям. Я считаю что язык программирования будущего может быть создан
только на основе MUMPSa.

По поводу моих предложений мне пришло 2 ответа.
ИнтерСистем меня не удостоил даже ответом.
Первый от комитета по МАМПСУ привожу его в оригенале:

От: "Ed Demoel" <demoel@radix.net>;
Кому: "kreit" <kreit@kaznet.kz>;
Копия: <edemoel@forerunsystems.com>;; <art@artsmithphotography.com>;
Тема: Re: Suggestion to MUMPS language development.
Дата: 3 февраля 2010 г. 15:31

Dear Mr. Sharymov,

I received your e-mail of 2 February 2010 in good order.

Before I go into much detail, I think I'll need to explain first
that the most recent meeting of the MUMPS Development Committee
was in September 1998, and that currently no new meetings are
scheduled.

I will forward your message to the current Chair of the MUMPS
Development Committee, and he should provide a formal response.
(I will also include my draft response below.)

While some of the ideas in your proposals may be worth pursuing,
it is important to be aware that changes to languages nowadays tend to be
directed by the people who foot the bills for the work, and no longer by
committees whose interest is typically more of an academic nature.

Sincerely,

Ed de Moel
MUMPS Development Committee Secretary


Draft response:

While I cannot predict if and when the MDC will ever reconvene,
and even if they do, I could not predict how they would vote
on any specific issue, there are some patterns from the past
that are worth being aware of:

a. The Committee has typically voted against any change to
the language that would break software that is currently
in compliance with the language standard.
(This affects proposals 1, 5 and the first one numbered 7)

b. The Committee rarely approved changes that would introduce
a new way of doing something without introducing new
functionality.
(This affects proposals 2, 3, 4, 6, 8, 9)
2: the first line with a lesser number of dots already
accomplishes this
3: indirection already accomplishes this, and in a much
more powerful manner
6: the functions $NAME and $QSUBSCRIPT already accomplish
this
8: The "Structured System Variable" ^$EVENT already
provides this functionality.
9: The "Structured System Variable" ^$WINDOW already
provides this functionality.

c. Some language constructs are often misunderstood, leading
to proposals for changes that would remove essential features.
(This affects the both proposals numbered 7.)

First 7: the dot syntax for "passing by name" has more
usages than just a name-indirection
Second 7: the parameters in these contexts are "numbers".
These numbers may be integers, but also fractional
numbers. The level of resolution is left to the
implementor, the language definition does not
specify any restrictions.

d. Object extensions have been proposed in the past.
Many object-related proposals have been put before the
Committee. Some were approved, some were rejected.
While there currently is a set of proposals that have
"been approved for inclusion in a future standard", it
is not clear if or when a future standard would be published.
It should also be noted that each implementor has chosen
their own fashion of implementing objects.
I believe that at least one of the implentors has brought
a system on the market that implements all of the features
mentioned in your proposal.

Второй от разработчика МиниМ Каратаева.

Мне пока не интересно если предложения на таком недоработанном уровне.
Пока это просто треп, и тут я не силен. Если речь о собственно языке, то мне
больше интересен компатибл с другими М системами, если речь идет о
дополнениях
того что Вы предлагаете непосредственно в MiniM, то нужна доработка т
основания для изменений.
В задачи проекта MiniM сейчас не входит создание чего-то нового и
экспериментального.
Если вносить что-то, какие-то изменения, то мне придется их документировать,
приводить примеры, соответственно мне надо всю внутреннюю кухню
понимать детально как никто другой.
Кроме того, это все большая работа и для нее должны быть основания.
Пока ничего такого не вижу.

Может, предложите обсуждение где-то на публичном ресурсе?

С уважением,
Евгений Каратаев.

{
- По поводу модифицируемости, инкапсуляции и т.д.
На самом деле в итоге в том же С++ инкапсуляция, наследование, полиморфизм и прочее в итоге преобразуются в ассемблерный код.
Т.е. эти понятия существуют только в сознании программиста и чисто технически то же самое можно получить тот же результат
с помощью С или даже ассемблера.
}
Полностью согласен но все же я пишу на МИМПСЕ а не на Асемблере. Я речь веду о свойствах языка. Есть ли в нем
определенные конструкции и насколько они удобны для пользователя.
В стандартном МИМПСЕ нет объектов их нет и в МиниМ хочу предложить вспомогательные программы, которые позволят
писать в объектном стиле в МиниМ. Аналогичные программы могут быть использованы и в Каше хотя не поворачивается
язык предлогать им это.
Вот эта программа

%Type ;Объектная модель
;создание объекта ref-ссылка где будет создан объект type-класс объекта
new(ref,type) N (ref,type)
ZT:ref="" "noREF"
ZT:type="" "noType"
S L=$QL(ref) S:L>0 ref=$NA(@ref,L-1) S ^type(ref)=type
Q
;получить свойство объекта
get(ref,prop) N (ref,prop)
ZT:ref="" "noREF"
ZT:prop="" "noProp"
S PR="S R=$$"_$$FindProp(ref,"get"_prop)_"("""_ref_""")",$ZT="ERRget"
X PR
Q R
ERRget ZT "syntObjget"
;изменить свойство объекта
set(ref,prop,val) ZT:ref="" "noRef" ZT:prop="" "noProp"
S PR=$$FindProp(ref,"set"_prop)_"("""_ref_""","""_val_""")",$ZT="ERRset"
D @PR
Q
ERRset ZT "syntObjset"
;Вспомогательные программы не для внешнего использования
FindExt(type) N (type)
S A="S R=$$^"_type_"()",$ZT="ERRFindExt"
X A
Q R
ERRFindExt
ZT "noObjType"
FindType(ref) N (ref)
S L=$QL(ref) S:L>0 ref=$NA(@ref,L-1)
S type=^type(ref)
ZT:type=""||(type'?1A.AN) "noObj"
S A=$$FindExt(type)
Q type
FindProp(ref,pr) N (ref,pr)
S type=$$FindType(ref),A=pr_"^"_type
Q:$T(@A)'="" A
S EXT=$$FindExt(type)
ZT:EXT="" "noObjProp"
S F=1
F J=1:1:$L(EXT,",") S A=pr_"^"_$P(EXT,",",J) I $T(@A)'="" S F=0 Q
ZT:F "noObjProp"
Q A
-------------------------------------------------------
Далее привожу пример использования
Реализация объекта XPerson
XPerson() Q "" ;Должен вернуть список родителей возможно множественное наследие
;свойство FIO
;получить значение свойства
getFIO(ref) Q @ref@("FIO")
;записать значение свойства
setFIO(ref,val) S @ref@("FIO")=val
;свойство Age
getAge(ref) Q @ref@("Age")
setAge(ref,val) S @ref@("Age")=val

Реализация объекта XWorker с родителем XPerson
XWorker() Q "XPerson" ;Тип Работник
getPOSITION(ref) Q @ref@("POS")
setPOSITION(ref,val) S @ref@("POS")=val
getMONEY(ref) Q @ref@("MON")
setMONEY(ref,val) S @ref@("MON")=val
--------------------------------------------------------
Пример программы использования этих классов

X ;Персоны
D new^Type("^A(1,2)","XPerson"),new^%Type("^A(1,3)","XPerson"),new^%Type("^A(1,4)","XPerson")
D set^%Type("^A(1,2)","FIO","Иванов Иван Иванович")
D set^%Type("^A(1,3)","FIO","Петров Петр Петрович")
D set^%Type("^A(1,4)","FIO","Сидоров Сидор Сидорович")
D set^%Type("^A(1,2)","Age","50")
D set^%Type("^A(1,3)","Age","60")
D set^%Type("^A(1,4)","Age","70")
W #
W $$get^%Type("^A(1,2)","FIO")," возраст ",$$get^%Type("^A(1,2)","Age"),!
W $$get^%Type("^A(1,3)","FIO")," возраст ",$$get^%Type("^A(1,3)","Age"),!
W $$get^%Type("^A(1,4)","FIO")," возраст ",$$get^%Type("^A(1,4)","Age"),!
;Работники
D new^%Type("^A(2,2)","XWorker"),new^%Type("^A(2,3)","XWorker"),new^%Type("^A(2,4)","XWorker")
D set^%Type("^A(2,2)","FIO","Иванов Иван Иванович")
D set^%Type("^A(2,3)","FIO","Петров Петр Петрович")
D set^%Type("^A(2,4)","FIO","Сидоров Сидор Сидорович")
D set^%Type("^A(2,2)","Age","50")
D set^%Type("^A(2,3)","Age","60")
D set^%Type("^A(2,4)","Age","70")
D set^%Type("^A(2,2)","POSITION","Администратор")
D set^%Type("^A(2,3)","POSITION","Директор")
D set^%Type("^A(2,4)","POSITION","Рабочий")
D set^%Type("^A(2,2)","MONEY","50000")
D set^%Type("^A(2,3)","MONEY","60000")
D set^%Type("^A(2,4)","MONEY","20000")
W #
W $$get^%Type("^A(2,2)","FIO")," возраст ",$$get^%Type("^A(2,2)","Age")," ",$$get^%Type("^A(2,2)","POSITION")," ",$$get^%Type("^A(2,2)","MONEY"),!
W $$get^%Type("^A(2,3)","FIO")," возраст ",$$get^%Type("^A(2,3)","Age")," ",$$get^%Type("^A(2,3)","POSITION")," ",$$get^%Type("^A(2,3)","MONEY"),!
W $$get^%Type("^A(2,4)","FIO")," возраст ",$$get^%Type("^A(2,4)","Age")," ",$$get^%Type("^A(2,4)","POSITION")," ",$$get^%Type("^A(2,4)","MONEY"),!
Q
-----------------------------------------------------------------
Не скажу что все отлажено но идея должна быть ясна.

{
- по поводу проблем с SQL
Возможно, вы просто не умеете его готовить. В том же Каше SQL просто чудесно дополняет объектную модель.
Сборка данных из нескольких классов буквально в одно движение.
}
Возможно не умею. Но у меня все приложение в основном построено на выборке фильтрации и
изменении структуры одной глобали. Я конечно могу все это выполнить SQL запросами но очень
напряжно. Тем более заранее не известно что надо фильтровать и какая структура должна быть
получена на выходе.
{
Ошибки вообще можно поделить на разные типы, каждый следующий тип на порядок сложнее в исправлении:
1. ошибки компиляции
2. ошибки выполнения (undefined и subscript т.д.)
3. ошибки логики выполнения
(когда программа отрабатывает, но работает неправильно, причем это не всегда заметно)
4. ошибки постановки задачи
Так вот, ошибки 2го типа вообще говоря это не то, о чем есть смысл спорить, они исправляются буквально
через несколько тестовых запусков. Ошибки логики выполнения уже сложнее, и они зависят от того, насколько
прозрачен язык. И пока я не уверен, что М самый простой в восприятии.
}
Ошибки логики выполнения конечно сложнее. Их количество и качество существенно зависят от
стиля программирования и возможностей языка. Язык М самый простой логичный и компактный.
Объем программы на нем в разы меньше чем на других языках поэтому я считаю его
самым надежным языком. А насчет восприятия это зависит только от стиля программирования.
{
большинство производителей М побоятся отойти от стандарта.
Те доработки, которые вы предлагаете, на мой взгляд, слишком слабые, чтобы ради них
кардинально ломать формат языка
}
Слабыми можно назвать что угодно это вообще не аргумен. Предложение по
расширению языка введением объектов я считаю очень Актуальным и важным.
И самое главное кардинально ломать формат языка мои предложения не должны.
Кардинально ломают формат языка расширения Интер Система.
{
Интерсистемс в этом смысле исключение, т.к. она сама себе стандарт.
}
Интерсистемс достаточно точно осознало проблеммы языка М но их
реализация говорит о их полном не понимании логики этого языка.
{
Про локальные переменные: в каше есть ProcedureBlock
}
Да есть но он сломал весь синтаксис языка М.Поведение
переменных и меток кардинально изменилось не в лучшую сторону.
И часто противоречит концепциям М. Выполнение команды X
вообще маразм. Выполняется команда как внешняя процедура.
Не получить не передать значения кроме как через % переменные
нельзя.
{
Кстати, DO (D) ENDDO (END), IF (I) ENDIF (END) зачем нужны? чем не нравится синтаксис в фигурных скобках?
}
По моему введение фигурных скобок аля С вообще не нужно. В синтаксисе
языка М есть блоки с точкой. Не надо было порождать новую конструкцию
а уж тогда в IF просто использовать такой блок
IF выражение операторы
.операторы
.операторы
ELSE операторы
.операторы
.операторы
Хотя я считаю что введение команды конца блока более предпочтительно и наглядно.
Конечно это мое мнение

Операторы while и do while тоже вообще не нужны. Команда FOR без аргументов
прекрасно справляется с этими функциями.

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