Pull to refresh

Comments 96

У вас путается строгая/слабая типизация со статической/динамической.
Уже фраза «С одной стороны это языки с жесткой типизацией данных такие как Си, С++, Паскаль, Фортран, Java с другой стороны JavaScript и его клоны.» выдаёт в авторе большого специалиста по современным языкам программирования :)
UFO just landed and posted this here
Это мнение того человека. А излагаю свое мнение. Я и без него знаю что этот язык не распространен но это никакого отношения к свойствам языка не имеет. То что он безграмотный кодер это его горе. MUMPS это мощный инструмент и им надо уметь пользоваться. А вообще эта статья не о реализации этого языка а о его свойствах, а они уникальны.
То что он безграмотный кодер это его горе.

Вы, похоже, даже не знаете, что это за сайт, судя по фразе «мнение того человека» и «он безграмотный кодер».
Комментарий доставляет
Build in obfuscation? oO
Скрытый текст
Appendix 7: An example of «traditional» M coding style

%DTC

%DTC; SF/XAK — DATE/TIME OPERATIONS ;1/16/92 11:36 AM

;;19.0;VA FileMan;;Jul 14, 1992

D I 'X1!'X2 S X="" Q

S X=X1 D H S X1=%H,X=X2,X2=%Y+1 D H S X=X1-%H,%Y=%Y+1&X2

K %H,X1,X2 Q

;

C S X=X1 Q:'X D H S %H=%H+X2 D YMD S:$P(X1,".",2) X=X_"."_$P(X1,".",2)

K X1,X2 Q

S S %=%#60/100+(%#3600\60)/100+(%\3600)/100 Q

;

H I X<1410000 S %H=0,%Y=-1 Q

S %Y=$E(X,1,3),%M=$E(X,4,5),%D=$E(X,6,7)

S %T=$E(X_0,9,10)*60+$E(X_«000»,11,12)*60+$E(X_«00000»,13,14)

TOH S

%H=%M>2&'(%Y#4)+$P("^31^59^90^120^151^181^212^243^273^304^334","^",%M)+%D

S %='%M!'%D,%Y=%Y-141,%H=%H+(%Y*365)+(%Y\4)-(%Y>59)+%,%Y=$S(%:-

1,1:%H+4#7)

K %M,%D,% Q

;

[...]
Там еще можно поискать на сайте по слову MUMPS, будет и дальше доставлять.
Не хватает красивого примера на MUMPS, который, будучи переписанным на другой язык, терял бы всю красоту…
Преимущества MUMPS проявляются в больших информационных системах. Когда необходимо обрабатывать большие и сложные структуры данных.
Я на MUMPS построил серверную часть бух.учета при этом мне не пришлось кувыркаться с чудесными базами данных вроде Оракла и MS SQL. А писать обращение к базе в виде:
Set ^A[«организация»,«подотчетник»,«материал»]=89,28
намного проще чем открывать закрывать базу и корректировать данные с помощью SQL операторов мало приспособленных для этих целей.
Аналогу MUMPS среди языков программирования просто нет. Приходится комбинировать язык с базой. Комбинация не очень удачная с моей точки зрения.
А перемножить 2 числа можно на любом языке, хотя на MUMPS это проще
W 2*3.5
Я на MUMPS построил серверную часть бух.учета при этом мне не пришлось кувыркаться с чудесными базами данных вроде Оракла и MS SQL.

Приходится комбинировать язык с базой. Комбинация не очень удачная с моей точки зрения.

Ты вы за или против этой фичи?
Хм, только сейчас заметил, что безобидное «Так» каким-то странным образом превратилось в странное «Ты».
Я что хотел сказать. Базы данных создавались не просто так, а с какими-то определёнными целями, и поэтому получили вполне определённые особенности. Если вам нужно очень простое хранилище, то берите SQLite и какой-нибудь ORM для любого другого языка, и получите ту же простоту.
Я против. Комбинация не удачна. Я что то ни разу не обнаруживал простоты. Сейчас масса всяких фреймворков баз данных. Но чем больше слоев в этом пироге тем больше там ошибок. В результате то что получилось отладить невозможно. Для написания таких проектов требуется все больше и больше людей, что само по себе создает дополнительные трудности.
Что мы имеем?
SQL базы данных и так называемые NoSQL базы.
С первыми все понятно. Корректировка-костыль. Выборка только стандартная. Мне ею ни разу не удалось воспользоваться без дополнительной обработки либо на клиенте либо на сервере с помощью курсора. Курсор конечно для SQL еще один костыль. Да и не все SQL базы его имеют. Так что в моем случае SQL оператор ничего не дает.
В штатном режиме SQL базы работают с клиентским приложением в синхронном режиме. И если я послал запрос на более менее глубокую выборку на клиенте все замирает.
Скорость выборки SQL баз на порядок ниже чем в не самой быстрой MUMPS системе.
NoSQL базы это примитивные базы Ключ-значение. Строить на них сложные взаимосвязанные структуры данных сложно.
Я понимаю всем этим можно пользоваться если бы не было MUMPS. Но он ведь есть. Что это за языки с примитивной организацией данных и файловым вводом выводом.
Много данных мало данных MUMPS все равно. Прекрасный богатый язык с превосходной организацией данных.
Создается впечатление, что у вас не получилось разобраться в специализированных инструментах, и в дело пошел универсальный комбайн.
NoSQL базы это примитивные базы Ключ-значение. Строить на них сложные взаимосвязанные структуры данных сложно.

Расскажите об этом создателям Reddit, а то они не знают.
NoSQL — отличное гибкое решение, когда данные не имеют постоянной структуры. При расширении структуры в SQL придётся добавлять столбец в таблицу (трудоёмкая операция), в NoSQL — всего лишь добавить новый ключ.
Полностью с вами согласен. Только в MUMPS можно добавить сколько угодно глубокую структуру ключей.
А мне кажется, MUMPS по своей сути — не очень удобный язык для работы с иерархической СУБД, рожденный на «рубеже 60-70 годов» ещё до публикаций Кодда и массовой любви к реляционным БД и SEQUEL. Я работал с MUMPS и мне не понравилось, потому что код совсем не читабелен другому человеку: c2.com/cgi/wiki?MumpsLanguage. Ну что это, извините, такое в наше-то время? Похоже на MODULA-2 или ещё хуже.
Ну это зависит от стиля программирования. Будешь писать понятно будет понятно нет так нет. Чем он хуже других? Выражения они и в других языках выражения ну еще допустим код команды и условие выполнения команды. Как это влияет на читабельность?
А писать обращение к базе в виде:
Set ^A[«организация»,«подотчетник»,«материал»]=89,28
намного проще чем открывать закрывать базу и корректировать данные с помощью SQL операторов мало приспособленных для этих целей.

Зато есть операции, для которых SQL-операторы намного удобнее.

Как, бишь, в вашем прекрасном языке сказать «для всех организаций в России, у которых численность больше 50 человек, установить ставку налога 28% и пересчитать сумму причитающегося за 2014 год налога на основании всех доходов за этот год»?
SQL это не организация данных, хотя он предполагает что данные организованы в виде таблиц, а метод доступа к данным. Кстати есть реализации MUMPS систем где SQL надстроен над MUMPS. Правда этим чудом я никогда не пользовался, но ничто не мешает это делать.
А я что-то говорил про организацию данных? Так нет же, я говорил как раз о методе доступа.
primer; Многозадачность
; Связь заданий будем осуществлять через файловую переменную удалим ее если она существует
Kill ^Ajob
; начальное значение
Set ^Ajob=0
; в цикле запускаем задания
For j=1:`1:20 job primjob(j)
; в цикле проверяем завершение всех заданий
For Lock +^Ajob Quit:^Ajob=20 Lock -^Ajob Halt .1
; снимаем блокировку
Lock -^Ajob
; и очищаем файловую переменную
Kill ^Ajob
Q
; запускаемое задание
primjob(j) Lock +^Ajob; блокирование переменной
Set ^Ajob(j)=1,^Ajob=^Ajob+1; изменение значений
Lock -^Ajob; разблокирование
; завершение задания
Quit
Вы задачу-то озвучьте сначала, а то из вашего примера понять ее невозможно.
Одновременное выполнение 20 заданий.
Какой же ужас у вас получился. Вот на Гоу:

// будем выполнять по 20 заданий одновременно
ch := make(chan byte, 20)

// всего тысяча заданий
for i := 0; i < 1000; i++ {
    ch <- 1

    // внутрь можно передавать значения,
    // например, номер выполняемого задания
    go func(index int) {
        // тело вашего задания

        // как выполнили, освобождаем очередь
        <-ch
    }(i)
}

// проверяем все ли уже отработали после завершения
// цикла, а пока делаем что-то бесполезное — спим, например
for len(ch) > 0 {
    time.Sleep(100 * time.Millisecond)
}
Да разница потрясающая. Job заменили на go. И сразу ужас превратился в шедевр. Только job изобретен в 70 годах а Go совсем вчера. Я кстати считаю что многозадачность в Go на высоте только там нет всего остального что мне нужно. Мой пример демонстрирует не только многозадачность но и синхронизацию данных. Если бы создатели новых языков программирования знали бы что нибудь еще кроме языка Си то я думаю что мне не пришлось бы расхваливать язык MUMPS созданный в 70 годах.
Вы Гоу-то, похоже, не знаете. Тут как раз демонстрация синхронизации данных тоже. Посмотрите — куда делся ваш Lock, например.

В Гоу вообще всё принципиально лучше, чем в примере, который вы написали. Функция анонимная, внутри неё работает замыкание, для пересылки данных есть канал, можно отдельно регулировать количество заданий и размер очереди, да и язык сам куча читаемее.
| да и язык сам куча читаемее.
Ну это утверждение спорно. Мой пример смотрится непрезентабельно из за моего неумения форматировать текст. Каналы есть и в MUMPS. Принципиального преимущества я не заметил.
Ну пусть это спорно, ок. С остальным-то вы согласны?
Я согласен. В Go многозадачность сделана хорошо.
Т.е. вас не порадовало, что мне не пришлось засорять глобальную зону видимости лишней функцией (в MUMPS есть замыкания?), не пришлось ничего лочить? Не понравилось, что нет цикла, оббегающего все задания? Что мой пример более функционален (есть очередь из 100 заданий и очередь из 20 воркеров)?
| Т.е. вас не порадовало, что мне не пришлось засорять глобальную зону видимости лишней функцией (в MUMPS есть замыкания?),

Точка входа primjob(j) не засоряет глобальную зону видимости она локальна внутри модуля primer. primer засоряет глобальную зону видимости.
Анонимные подпрограммы в MUMPS есть но они не используются в команде Job. Остальное я не понял. Язык Go я не знаю. Понятия замыкания в MUMPS нет. Что делает замыкание в вашем случае я не понял.
Lock стандартный механизм. Чем он вас не устраивает? Существуют и другие способы обмена данными те же каналы они не требуют Lock. Это не более чем пример синхронизации данных.

| Не понравилось, что нет цикла, оббегающего все задания?

// цикла, а пока делаем что-то бесполезное — спим, например
for len(ch) > 0 {
time.Sleep(100 * time.Millisecond)
}

А это что не цикл?
Замыкание в моём случае позволяет внутри функции, выполняемой в отдельном «потоке» получать переменные своего окружения, в вашем же случае их придётся слать параметрами.
А это что не цикл?

Это — цикл, только вы оббегаете все свои задания, а я проверяю в цикле одно условие (длину массива вычислять не нужно, функция len просто возвращает значение длины, которое уже есть), а цикл у меня холостой. Я мог бы его не использовать, а идти дальше заниматься своими делами, а в конце проверить — выполнились задания или нет. Одним условием. Вам, опять же, цикл понадобился бы, причём вам нужно ещё и хранить сколько заданий вы запустили и везде это протаскивать, как переменную.

Если вы не чувствуете такие нюансы, то я с вами спорить не буду, посмотрите сначала с десяток хороших языков, а там поговорим.
А понял с помощью замыкания вы передаете параметр анонимной функции. В MUMPS нет анонимных функций и замыкание ненужно.
Я передаю параметр анонимной функции в качестве параметра анонимной функции, а не замыкания. То, что в MUMPS нет замыканий — очень грустно.
| Я передаю параметр анонимной функции в качестве параметра анонимной функции, а не замыкания. То, что в MUMPS нет замыканий — очень грустно.

Зря грустите. Нет анонимных функций и нет связанных с ними проблем.

| Это — цикл, только вы оббегаете все свои задания, а я проверяю в цикле одно условие (длину массива вычислять не нужно, функция len просто возвращает значение длины, которое уже есть), а цикл у меня холостой. Я мог бы его не использовать, а идти дальше заниматься своими делами, а в конце проверить — выполнились задания или нет. Одним условием. Вам, опять же, цикл понадобился бы, причём вам нужно ещё и хранить сколько заданий вы запустили и везде это протаскивать, как переменную.|

Я кстати тоже проверяю только одно значение и цикл у меня холостой. И я мог бы его не использовать, а идти дальше заниматься своими делами, а в конце проверить — выполнились задания или нет. Все остальное к моему примеру никакого отношения не имеет.

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

С этим я полностью согласен и обязательно последую вашему совету. Только пожалуйста прежде чем решите начать беседовать со мной познакомтись с языком MUMPS. Это недолго. Нескольких часов вполне хватит. Первой документацией по MUMPS была книжка небольшого формата на 20 листов. Она кстати актуальна и сейчас. С наилучшими пожеланиями.
Это не задача, а решение. А я спрашивал задачу.

Но так, для сравнения:

await Task.Factory.ContinueWhenAll(
    Enumerable.Range(1, 20).Select(t => Task.Factory.StartNew(() => {})).ToArray(),
    ct => {});


Выполнение определяется шедулером, поток не блокируется на время ожидания.
А какой ужас, когда вам на русском языке приходится писать, а не на MUMPS.
Гм. Честно говоря, статья вызывает противоречивые ощущения.
С одной стороны — мне нравится читать MUMPS. Писать не пробовал.
С другой стороны — некоторые аспекты представления автора о современных языках (русском и программирования) переполняют мой стек и вводят обработчик исключения этого переполнения в бесконечный цикл.
А если по-делу, то во-первых автор игнорирует например Python (по-моему, за его потомками — будущее прикладных языков); во-вторых декларация переменных нужна не сколько трансляторам (реализовать автоматическое создание переменных по первому вызову — рас плюнуть), сколько программисту — во избежание опечаток; в-третьих у меня проблемы прямо противоположные авторским — все современные ЯП слишком много на себя берут. Для меня оптимальным языком был бы BLISS. Но увы…
Ну насчет Python я не согласен и не верю в его перспективы. С моей точки зрения ничем не примечательный язык. Мне он не показался. Хотя я судить здесь не могу.
Ну опечатки не аргумент. Опечатки могут быть но создавать декларации ради этого. Это слишком.
Язык который делает только то что ты пишешь это Си. Хорошо и со вкусом. В своей области он верх совершенства. Но в области информационных систем нужен другой инструмент. На большом объеме программ отладка превращается в кошмар.
Информационную систему необходимо проектировать, а не кодировать. Тщательно разрабатываешь структуры данных и цикл их жизни. А программы это вторично. Их можно постоянно менять. Поэтому так важен язык с хорошей организацией данных.
Поэтому так важен язык с хорошей организацией данных.

Скажите, пожалуйста, а как MUMPS обрабатывает следующую ситуацию: вот предположим, что некая сумма у нас адресовалась как «исполнитель — год» (т.е., деньги, выплаченные исполнителю за год). Теперь по требованиям бизнеса нужно, чтобы суммы адресовались как «исполнитель — год — контракт» (т.е., деньги выплаченные исполнителю в этом году по конкретному контракту). Мы хотим соответствующим образом изменить структуру данных — и мы хотим, чтобы язык/среда разработки еще на этапе компиляции/статической проверки указали нам на то, где мы забыли изменить старую адресацию на новую.

Иными словами, как MUMPS поддерживает рефакторинг?
Нет MUMPS не поддерживает рефакторинг. Проблема рефакторинга глубже просто добавления одного индекса.
В подобных случаях пишу программу которая и выполняет рефакторинг. Вы имеете какое то дерево в котором надо изменить структуру. Как вы себе представляете команду которая должна объяснить как изменить эту структуру. Существует очень много структур в которые может быть преобразовано исходное дерево. Из исходного дерева можно получить 2^n различных структур где n глубина индекса. Мне не приходилось сталкиваться с простым добавлением индекса как правило требовалась одновременная обработка нескольких деревьев а это уже простым рефакторингом не выполнишь. Средств рефакторинга данных нет ни в одном языке программирования, а в базах данных подобную работу выполняют внешние утилиты.
Средств рефакторинга данных нет ни в одном языке программирования

Это утверждение не вполне верно. Языки данных со статической типизацией поддерживают практику rely on compiler для изменения структур данных.
В си как в системном языке мне не нравится следующие вещи:
1) Отсутствие модулей/пространств имен и аналога with..do.
2) Statement-oriented syntax. Это вообще, я считаю, бич большинства существующих языков.
3) Отсутствие безымянных структур.
4) Крайне непродуманный набор примитивных типов.
5) Кривые управляющие конструкции. Хотелось бы такие, как в Аде, но без адского количества ключевых слов.
6) Нет шаблонов. В C++ они есть, но в таком виде, что уж лучше бы не было.
3) Отсутствие безымянных структур.

C11: Anonymous structures and unions, useful when unions and structures are nested, e.g. in struct T { int tag; union { float x; int n; }; };.

Си неидеален, но он прост. Более адекватного инструмента для системного программирования не создано до сих пор, я считаю. Пытаются делать замены, но пока безуспешно.
А вот со стороны C++ адекватной заменой видится Rust. Безопасный и производительный язык.
C11: Anonymous structures and unions, useful when unions and structures are nested, e.g. in struct T { int tag; union { float x; int n; }; };.
— Это не то. Вот если бы:
struct X {int a,b;};
struct Y {struct X; int c;} y;

int main()
  {
    y.a=1;
  }

был бы торт.
Но ведь у вас именованная структура, а пример для union. Вот пример анонимной структуры:

ideone.com/7PAlIk

Печально, что C11 ещё не поддерживается системными библиотеками. Там потоки есть. С другой стороны, в embedded C89 живёт и здравствует.
Я и имел ввиду не анонимные типы-структуры, а безымянные члены. Чтобы можно было реализовать ООП from scratch. Proposal был, но его, к сожалению, отклонили. А то, что вы показываете — совсем из другой оперы.
Извиняюсь. Уяснил разницу. Увидел, что у вас структура без имени переменной.
-не поддерживаются привычные приоритеты арифметических операций (например, выражение 2+3×10 даёт в MUMPS значение 50);
-лишний пробел или разрыв строки может совершенно изменить смысл синтаксической конструкции;
-ключевые слова языка не зарезервированы и могут широко использоваться в качестве идентификаторов.

Сомнительное удовольствие этим пользоваться.
-не поддерживаются привычные приоритеты арифметических операций (например, выражение 2+3×10 даёт в MUMPS значение 50);
Кстати очень удобно. Попробуй. Пока у тебя операции +-*/ еще можно ориентироваться но когда включается логика и сравнения разбираться в этой каше становится проблематично. Я начинаю везде ставить скобки. Без приоритета операций работать намного проще.

-лишний пробел или разрыв строки может совершенно изменить смысл синтаксической конструкции;
Лишние символы во всех языках меняют смысл написанного.

-ключевые слова языка не зарезервированы и могут широко использоваться в качестве идентификаторов.
Ключевые слова это команды. У них строго определенное место и их резервирование ничего не дает.

-Сомнительное удовольствие этим пользоваться.
Не пользуйся. Законодательно это не запрещено.
>Попробуй.
Как по мне, так все-таки лучше расставить скобки, как в математике. Речь же не о языке вроде Forth.

>Лишние символы во всех языках меняют смысл написанного
Лишние пробелы во многих языках приводят к ошибке лексического/синтаксического разбора исходника, а не по тихому ломают логику.
Антипримерами могу назвать return в JS, где ключевое слово «return» и возвращаемое значение обязаны быть на одной строке, и, вроде в fortran с его DO и игнорированием пробелов, где чтобы понять, что имел ввиду программист, нужно просмотреть кучу лексем вперед.

>У них строго определенное место и их резервирование ничего не дает.
IF THEN THEN ELSE ELSE=THEN END
или «классический»
TRUE=FALSE
-Как по мне, так все-таки лучше расставить скобки, как в математике. Речь же не о языке вроде Forth.
А мне проще опираться на простое правило всегда верное.

-IF THEN THEN ELSE ELSE=THEN END
Не понял. Это синтаксически не верная конструкция. Не понял смысла.
Как в MUMPS будет выглядеть аналог?
1+2*3 — 4*5 + 6 (выражение записано с учетом приоритетов)
Тут или стек использовать, или таки скобки. Есть третий вариант?

В ЯП с незарезервированными ключевыми словами такая конструкция верная и рабочая. Но выглядит это ужасно.
Безусловно скобки. Стека нет. Можно использовать промежуточные переменные. но какой в этом смысл.
2*3+1-(4*5)+6
Скобки стандартный инструмент. И если у тебя не стековая машина то всегда есть выражения когда тебе придется использовать скобки.
-IF THEN THEN ELSE ELSE=THEN END
Не понял. Это синтаксически не верная конструкция. Не понял смысла.

А вот такая?

IF IF=THEN DO THEN
Ну тут все очевидно если переменная IF равна переменной THEN то вызвать подпрограмму THEN. Кстати THEN не является командой.
Вас никто не заставляет использовать имена переменных совпадающих с командами. В голове у себя зарезервируйте эти имена и не используйте.
Можно и бухучет «в голове у себя» вести, только зачем тогда вообще компьютеры?
Декларирование переменных вообще не нужно.

Нужно. Это и определение области видимости и защита от опечаток.
Для предметной области не важно целое или действительное значение имеет переменная. Какое значение пользователь ввел с клавиатуры такое и есть.

Серьёзно? Пользователя спрашивают сколько штук пришло товара и сколько денег он стоит и пользователь вводит 1.5 штук и 1,444 денег. Так и писать? Штуки всегда целые, а деньги округляются до целого или до двух знаков после запятой (могут быть и другие правила учёта, но банк не примет перевод на 1,444 рубля или доллара, а вообще имелось в виду 1444).

А так согласен, что без примеров преимущества не ясны.
-Нужно. Это и определение области видимости и защита от опечаток.

Управление областью видимости переменных можно и другими средствами. Декларирование не единственный способ. В MUMPS для этого используется другая методика.

-Серьёзно? Пользователя спрашивают сколько штук пришло товара и сколько денег он стоит и пользователь вводит 1.5 штук и 1,444 денег. Так и писать? Штуки всегда целые, а деньги округляются до целого или до двух знаков после запятой (могут быть и другие правила учёта, но банк не примет перевод на 1,444 рубля или доллара, а вообще имелось в виду 1444).

Ну товарищи не серьезно. Весь ввод необходимо проверять и типов данных намного больше это могут быть и телефоны и коды из классификатора причем тут декларация переменных.
Ок, ввод проверяем, а как быть с арифметикой? Иногда нужна целочисленная, иногда с фиксированной точностью, иногда с плавающей точкой. Везде вставлять что-то типа round(a/b, 2), а то и round(round(a, 2)/round(b, 2), 2)?
Любая переменная в зависимости от операции трактуется либо как число либо как логическое значение либо как строка. Если тебе нужен целый результат то округляй.
3.6 + .5 \ 1
Скажите, пожалуйста, а MUMPS (в той его версии, которой пользуетесь вы) — интерпретируемый или компилируемый язык?
Исходный код компилируется в Pi код затем этот код интерпретируется.
Разговор получается несколько верхушечным. Как и всякий язык этот имеет свои достоинства и недостатки. Пока речь идет о стандарте языка. Реализации могут отличаться от стандарта иногда значительно. Но ядро реализованных языков всегда в той или иной мере соответствует стандарту.
Достоинства:
-Самый удачный метод управления памятью. Автоматическое выделение и освобождение памяти без сборщика мусора и утечек памяти.
-Многозадачность заложенная в языке. Просто и переносимо.
-Синхронизация процессов и данных заложенная в языке.
-Синхронный и асинхронный ввод вывод реализован в языке.
-Гибкость языка. Отсутствие деклараций и в языке есть косвенная адресация(в терминах MUMPS) и команда XECUTE которые позволяют сформировать и выполнить команду на лету. Аналог команды XECUTE есть в JavaScript — eval.
-Полнофункциональная база данных с транзакциями и журналированием.
-Распределенная база данных. Узлы базы данных могут находиться в любой точке мира.
Возможно есть и другие достоинства.

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

Предположим, некая подпрограмма выделила блок памяти и вернула его вызывающему коду. Кто, как и когда его автоматически удалит?

Гибкость языка. Отсутствие деклараций

Как одно связано с другим?
| Предположим, некая подпрограмма выделила блок памяти и вернула его вызывающему коду. Кто, как и когда его автоматически удалит?

В MUMPS кроме записи в переменную никаких других способов выделения памяти не существует. Если в подпрограмме переменная была объявлена через команду New то она будет уничтожена после выхода из подпрограммы, если нет то она может быть уничтожена далее в любой программе с помощью команды Kill иначе вся память будет освобождена при завершении приложения.

| Гибкость языка. Отсутствие деклараций. Как одно связано с другим?

Прямо. Я имею возможность писать обработку данных независимо от структуры переданной мне переменной. это может быть просто переменная, а может быть и дерево произвольной структуры. В MUMPS декларирование смысла не имеет. Тип данных известен. Структура-дерево. Что еще надо знать?
она может быть уничтожена далее в любой программе с помощью команды Kill

Ручное управление памятью?
И что будет в таком случае: в переменной foo хранится большой массив, мы делаем bar=foo, а после Kill ^foo?
Не понял. Команды
bar=foo
нет.
Либо Set bar=foo в этом случае одно значение хранящееся в вершине foo будет скопировано в вершину bar массив останется в foo
либо Merge bar=foo в этом случае массив foo будет скопирован в bar
Kill ^foo переменная ^foo находится в файле и никакого отношения к foo расположенной в памяти не имеет. это разные переменные.
если вас интересует случай Kill foo то переменная foo будет удалена, а в bar останется копия.
Ссылок в MUMPS нет.
Да, немножко запутался в синтаксисе.
если вас интересует случай Kill foo то переменная foo будет удалена, а в bar останется копия.
Ссылок в MUMPS нет.

Спасибо. А что будет если сделать Set bar=6 без Kill foo? Память очистится?

И непонятно, где же
Автоматическое выделение и освобождение памяти без сборщика мусора и утечек памяти

Ведь если я забуду сделать Kill foo и больше не буду использовать эту переменную, то память так и будет висеть балластом. Или нет?
| А что будет если сделать Set bar=6 без Kill foo? Память очистится?
В переменной bar будет значение 6, а переменная foo будет удалена. У меня впечатление что вы не об этом спрашиваете. Что было перед этими командами?
Команды Set Merge Kill это ручное управление памятью. Автоматическое управление памятью осуществляется с помощью команды New. Команда New не резервирует память, а только определяет новые значения для переменных которые будут освобождены при выходе из программы. Если во внешней программе были переменные с такими же именами как в New то они как бы помещаются в стек и становятся недоступными внутри этой программы. После выхода из программы эти переменные как бы выталкиваются из стека. Но какой механизм при этом используется зависит от реализации.
Если во внешней программе были переменные с такими же именами как в New то они как бы помещаются в стек и становятся недоступными внутри этой программы.

Это называется «область видимости», а не управление памятью.

А управление памятью в MUMPS — если верить вашим словам — обычное ручное, без какой-либо автоматики, и с утечками.
Set foo=6 конечно. Что будет с предыдущим значением переменной?
А с помощью New получается можно просто создавать локальные переменные?
| Set foo=6 конечно. Что будет с предыдущим значением переменной?

Предыдущее значение находящееся в вершине foo будет потеряно, а массив который хранится в других вершинах дерева не изменится.

|Это называется «область видимости», а не управление памятью

Пусть будет область видимости.
Если в подпрограмме переменная была объявлена через команду New то она будет уничтожена после выхода из подпрограммы, если нет то она может быть уничтожена далее в любой программе с помощью команды Kill иначе вся память будет освобождена при завершении приложения.

Типичное ручное управление памятью.

И что случится, если у вас долгоиграющая программа (скажем, демон/сервис, который работает 24/365), а переменная создается, но не удаляется с помощью Kill?

Я имею возможность писать обработку данных независимо от структуры переданной мне переменной

Это не отсутствие деклараций, а отсутствие типизации; две совершенно разные вещи.

Ну и вы лукавите, ваша обработка данных прямо зависит от структуры переданной вам переменной — иначе что случится, если вы попробуете обработать скалярную переменную как дерево, или дерево как дерево другой структуры?
| И что случится, если у вас долгоиграющая программа (скажем, демон/сервис, который работает 24/365), а переменная создается, но не удаляется с помощью Kill?

Если это внешняя переменная то она будет постоянно использоваться, если нет то используем New.

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

Нет не лукавлю. Если я собираюсь обрабатывать структуру то у меня есть набор механизмов обойти эту структуру и выполнить нужную операцию. В MUMPS это стандартный метод. И я всегда так поступаю.

|Это не отсутствие деклараций, а отсутствие типизации; две совершенно разные вещи.

А что декларации используются для чего нибудь другого кроме описания типа переменной?
Если это внешняя переменная то она будет постоянно использоваться, если нет то используем New.

А если она больше не используется?

Если я собираюсь обрабатывать структуру то у меня есть набор механизмов обойти эту структуру и выполнить нужную операцию

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

А что декларации используются для чего нибудь другого кроме описания типа переменной?

Конечно.

var temp;
temp = "qqq";
temp = 123;


Переменная объявлена (декларирована), но тип ее неизвестен (и меняется на ходу). Собственно, динамическая типизация в полный рост.
|А если она больше не используется?

В MUMPS нет возможности узнать будет ли использоваться переменная или нет. Часть кода формируется во время исполнения и возможно в цикле. Возможности транслятору узнать будет ли в дальнейшем использоваться переменная нет в принципе.

|Тем не менее, ваши операции зависят от того, ожидаете вы структуру или простое значение. Вы не можете просто взять и использовать одно вместо другого (или же вам нужно много дополнительных проверок на успешность обращения).

Конечно я должен ожидать на входе дерево и тогда смогу обработать и скалярное значение.

|Конечно.
Я с вами согласен но для MUMPS это не актуально. Декларирование отсутствует как таковое, а типизация происходит в момент выполнения любой операции и от нее зависит.
В MUMPS нет возможности узнать будет ли использоваться переменная или нет. Часть кода формируется во время исполнения и возможно в цикле. Возможности транслятору узнать будет ли в дальнейшем использоваться переменная нет в принципе.

ЧТД: никакой уникальной системы автоматического управления памятью нет, обычное ручное управление со всеми его плюсами и минусами.

Конечно я должен ожидать на входе дерево и тогда смогу обработать и скалярное значение.

ЧТД: вы не можете писать операции независимо от структуры данных.

Декларирование отсутствует как таковое, а типизация происходит в момент выполнения любой операции и от нее зависит.

ЧТД: отсутствие деклараций никак не влияет на гибкость.
| Переменная объявлена (декларирована), но тип ее неизвестен (и меняется на ходу). Собственно, динамическая типизация в полный рост.
Ясно. Только зачем в этом случае декларация? Что бы программист не дай бог в именах переменных не запутался?
Только зачем в этом случае декларация? Что бы программист не дай бог в именах переменных не запутался?

Чтобы избежать ошибок вида

received = 15;
//много кода
recieved = size + 13;
Все зашли в цикл. Я говорю есть и привожу пример вы говорите нет.
Вы пока не привели ни одного примера, где MUMPS реально бы выигрывал у современных языков.

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

В частности, конкретно для этой ветки: какова польза от отсутствия декларирования переменных? Вред мы уже увидели (пример я привел), а польза? (ну и да, ничего уникального в этом тоже нет, в JavaScript прекрасно работают недекларированные глобальные переменные, равно как и их сокрытие в локальной области видимости)
| Вы пока не привели ни одного примера, где MUMPS реально бы выигрывал у современных языков.

Я привел целый перечень уникальных свойств языка MUMPS. Вы оспариваете один из них об автоматическом управлении данными. По команде New создается новая область видимости переменной при завершении подпрограммы Автоматически освобождается эта переменная. У нас диаметральный взгляд на одни и те же вещи.

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

Контр пример привести можно особенно если собрать весь остальной мир. Многозадачность берем из Go отсутствие деклараций из JS базу данных из Оракл правда распределенную базу данных взять неоткуда, да ладно забудем про нее. Получается MUMPS против всего остального мира. Только я нигде не встречал чтобы такую кашу из языков и технологий кто нибудь использовал.
Вы оспариваете один из них об автоматическом управлении данными. По команде New создается новая область видимости переменной при завершении подпрограммы Автоматически освобождается эта переменная.

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

А во-вторых, в этом нет ровным счетом ничего уникального, этого добра в большей части современных языков — т.н. «переменные на стеке».

Только я нигде не встречал чтобы такую кашу из языков и технологий кто нибудь использовал.

Вообще-то, многие современные крупные проекты так и устроены: отдельная БД, отдельная серверная часть (на своем стеке технологий), отдельная клиентская часть (на своем стеке технологий). И, что характерно, для каждого звена выбирается тот инструмент, который наиболее точно соответствует задаче.
| Во-первых, по команде new не создается новая область видимости, создается переменная в текущей области видимости (ограниченной подпрограммой), скрывающая существующую в глобальной области видимости переменную с таким же именем.

Ну я рад за вас. С моей помощью вы стали даже немного разбираться в MUMPS. Но моих комментариев для изучения MUMPS сильно недостаточно. Команда New в одной из форм создает именно область видимости.

|Вообще-то, многие современные крупные проекты так и устроены: отдельная БД, отдельная серверная часть (на своем стеке технологий), отдельная клиентская часть (на своем стеке технологий). И, что характерно, для каждого звена выбирается тот инструмент, который наиболее точно соответствует задаче.

Вообще-то да только я не знаю ничего хуже такого слоеного пирога. Если создать такие приложения большой командой с разными специалистами еще как то можно. То ввод в эксплуатацию и сопровождение требует огромных трудозатрат. А поиск ошибок когда валится в каком то слое незабываемое удовольствие.
Команда New в одной из форм создает именно область видимости.

Приведите, пожалуйста, пример.

Вообще-то да только я не знаю ничего хуже такого слоеного пирога.

Удивительно, что это тем не менее доминирующая методология.

То ввод в эксплуатацию и сопровождение требует огромных трудозатрат. А поиск ошибок когда валится в каком то слое незабываемое удовольствие.

У вас есть какие-то фактические подтверждения этим словам?
| Команда New в одной из форм создает именно область видимости.
Команда New без аргументов.

| Удивительно, что это тем не менее доминирующая методология
Удивительно но это так

| У вас есть какие-то фактические подтверждения этим словам?
А что разве это не так? В любом банке сопровождение осуществляется целым отделом IT и каких только специалистов там нет.
Команда New без аргументов [создает именно область видимости]

Вообще, нет. «With no arguments, make all current local variables undefined.» Это не новая область видимости, это сброс всех переменных в текущей области видимости (до ближайшего QUIT). Иными словами, в конструкции NEW ... NEW ... QUIT не значения после QUIT вернутся к значениям до второго NEW, а будет выход из текущего блока выполнения (который не обязательно начат NEW).

А что разве это не так? В любом банке сопровождение осуществляется целым отделом IT и каких только специалистов там нет.

Это не доказывает, что сопровождение классической трехзвенной или so-архитектуры требует больше ресурсов, нежели сопровождение системы, написанной на MUMPS.
|А что разве это не так?
Это именно так как вы написали. Но это по существу мало чем отличается от области видимости.
Я вижу описание языка вы все таки прочитали. Я рад за себя. А то я уже начал думать что зря затеял всю эту бодягу. Значит не зря. Технологии вы можете выбирать на свое усмотрения, но альтернативные все таки следует знать.

| Это не доказывает, что сопровождение классической трехзвенной или so-архитектуры требует больше ресурсов, нежели сопровождение системы, написанной на MUMPS.
Ну доказательство здесь довольно проблематично. Надо одну и туже задачу реализовать на разных технологиях и затем сравнить. Я такого примера не знаю. Да и это не совсем корректно. Квалификация исполнителей должна быть идентичной, что уже переносит данное сравнение в область фантазий. Я могу опираться только на свой опыт, а он меня ведет только в сторону MUMPS.
Но это по существу мало чем отличается от области видимости.

Как раз нет. Но спорить с вами об этом достаточно бессмысленно, учитывая, что этот термин в дискуссию ввел я.

Ну доказательство здесь довольно проблематично. Надо одну и туже задачу реализовать на разных технологиях и затем сравнить. Я такого примера не знаю. Да и это не совсем корректно. Квалификация исполнителей должна быть идентичной, что уже переносит данное сравнение в область фантазий.

Что говорит нам о том, что ваше утверждение о стоимости поддержки таких решений бездоказательно. ЧТД.

Технологии вы можете выбирать на свое усмотрения, но альтернативные все таки следует знать. [...] Я могу опираться только на свой опыт, а он меня ведет только в сторону MUMPS.

Это, собственно, то, что вам написали в самом начале этой беседы: прежде, чем превозносить свой язык, говоря о его уникальности, ознакомьтесь сначала с другими технологиями и языками.
Ну понятно. Замолчи и сиди тихо. А многие ли знали вообще о технологии MUMPS? Вам она не нужна. Но вы не допускаете, что кому нибудь она станет полезной?
Если бы вы написали пост с позиции «есть такой язык, давайте познакомимся» — все было бы нормально. Но вы начали с заявления «язык, в котором нет недостатков других языков» — естественно, что реакция была прямо противоположной.
Для идеальной BolgenOS нужен не менее идеальный язык программирования, который применят во всех школах страны…
Попов, не ты ли ?)
На самом деле жду продолжения, хотелось бы узнать сколько времени вы потратили…
Что такое BolgenOS я не знаю. Но языка лучше MUMPS для обучения не найдете. Это компактный логически точный и самодостаточный язык. Ну а возможностях этого языка я уже писал при поразительной простоте этого языка. На его изучение потребуется минимальное время. Конструкции языка единообразны не имеют побочных эффектов и умолчаний.
Поражает только неосведомленность о нем.
Средств этого языка хватает даже для управления OS. На базе только этого языка была создана OS DSM11 для PDP11. Которая была достаточно распространена в мире. В DSM11 был только этот язык и его хватало. У нас тогда локальных сетей не было, но многотерминальные сети широко использовались. Трудоемкость создания приложений была на порядок ниже чем теперь на локальных сетях.

> На самом деле жду продолжения, хотелось бы узнать сколько времени вы потратили…
не понял на что?

> Попов, не ты ли ?)
Нет не я. В моем профиле написано кто я.
Sign up to leave a comment.

Articles