Женя здравствуй! Как идет реализация если не секрет?

Реализация Ключей. Можешь не отвечать. Помнишь обсуждение моих предложений? Ведь никто по существу обсуждать не стал. Тема не интересна. А почему? Мне кажется никого не интересует чистый MUMPS. Программистов которые работают как я на чистом MUMPSe в Союзе по моему наберется не больше 10 человек. Остальные работают на COS IS. IS точно прочувствовали куда должен развиваться MUMPS правда их реализация просто уничтожает идеологию MUMPSa. Тем не менее посмотри по обсуждению все активно используют ZEN. Мне кажется что языки программирования сейчас продвигают только визуальные среды программирования. Новый контингент даже смотреть не будет на язык без визуальной среды разработки. Поэтому я думаю что у тебя рынок сбыта без визуальной среды будет очень узок и навряд ли окупит твои затраты. Хотя ты и не первый в таком положении.
С Уважением Михаил.

Была такая тема: Что же главное в CACHE страница гдето 5-8.
Как создать ссылку не знаю поэтому просто цитирую тот пост.
Речь шла о совершенствовании языка MUMPS.
misha_sharНу начнем по порядку.
На форум мнения выносятся для обсуждения. А не для оплевывания.
Оговорюсь речь идет о чистом Мампсе. Никаких объектов и 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.

Да в CAHE реализовано , но как? Речь идет именно о реализации никуда не годной. Основные проблеммы:
1.Локализация данных. В CACHE она реализована с помощью процедуры. Это совсем другая конструкция чем подпрограмма в MUMPSE. Причем CACHE позволяет комбинировать их при этом результат действия переменных не предсказуем. IS дает рекомендации эти конструкции не смешивать. Это явный признак противоречия в CACHE. Так быть не должно. А локализация переменных жизненно необходима ее можно осуществить вставляя команду NEW в каждый вызов подпрограммы но это идеологически неверно так как к куску кода может быть обращение как к подпрограмме так и в ходе последовательного выполнения программы. В первом случае переменные должны быть локализованы во втором нет. Поэтому я предлагаю совсем другое. Не вводить новые конструкции, а локализовать все не % переменные внутри вызова подпрограммы. Это не создаст противоречий в языке.
2.Введение блочных команд. Если посмотреть на конструкцию языка то видно что команды IF, ELSE, FOR и DO отличаются от других команд MUMPSa областью действия и она распространяется до конца строки. То есть эти команды являются исключением из правила. Кроме того редко приходится применять эту команду без использования внутри блока DO. Это не удобно и архаично поэтому я предложил ввести команду конца действия этих команд. В CACHE это реализовано в виде {}. Я считаю что для MUMPSa это несколько чужеродно сильно попахивает С. Можно вообще не придумывать новых конструкций а воспользоваться существующей. В MUMPSe есть команда блока DO c '.' То есть блок задается точками. Можно команды IF, ELSE и FOR сделать блочными:
конструкцию
IF a=1 DO
.
.
Заменить
IF a=1
.
.
Команда DO в этих командах излишня. Хотя я считаю что задавать блок точками очень уж оригенально и сторонник более традиционного синтаксиса в этом случае.

4. Команды обхода коллекций существуют практически во всех языках и это очень удобно. Писать
FOR SET A=$O(B(A)) Q:A=""
Конечно не сложно. Но эта конструкция применяется очень часто и ее даже небольшая модификация придаст языку большую привлекательность по моему.

8. бработка событий в MUMPSe в зачаточном состоянии. Для построения Web технологий и клиентских приложений прийдется строить систему обработки событий практически заново. Это же касается и оконного интерфейса.

10. Объекты разговор особый. Конечно объекты должны быть в любом современном языке. Если язык не имеет объектов это сразу от него отталкивает большенство программистов. Создание идеологии объектов это одно из немногих достижений программисткой науки. Они должны быть. И они есть в CACHE. Но лучше если бы их там не было. Объекты CACHE ломают идеологию языка. Поэтому я и предлагаю другое описание Объектов которое не ломает идеологию языка.

А насчет ниши. Возможности MiniM не хуже чем CACHE я думаю. При этом он конечно значительно легче. Так что конкуренция просматривается невооруженным глазом. И сторонников MiniM взять не откуда кроме как у CACHE.
Насчет совершенствования C#.
С моей точки зрения MUMPS построен более правильно чем язык C#. MUMPS можно довести до идеала буквально несколькими штрихами. А с C# это не получится без создания фактически другого языка. В основе языка С# лежит C. И просто добавлением структуры дерева языку не поможешь. А причина лежит глубже в описании переменных. В MUMPSe описание отсутствует и дерево строится его заполнением. А С требует предварительного описания структуры перед его использованием, а это уничтожает динамику языка. Если из С убрать описания то языка не будет. Кстати по этой же причине С не может содержать косвенность.

Давай. Буду рад.

Попробуй. Обязательно примут.