Комментарии 51
НЛО прилетело и опубликовало эту надпись здесь
Разумеется, в языках программирования всё хуже, чем хотелось бы. Но всё, что вы хотите, уже давно есть. Выбирайте — php, javascript — все они радостно будут «управлять типами данных» за вас. А вам останется всего лишь написать логику программы для обработки undefined'ов.
В то же самое время высшие достижения индустриального языкостроительства фокусируются на более богатом синтаксисе типов. Алгебраические типы данных, предикаты на типах (их иногда называют трейтами или типажами), зависимые типы данных и т.д.
В то же самое время высшие достижения индустриального языкостроительства фокусируются на более богатом синтаксисе типов. Алгебраические типы данных, предикаты на типах (их иногда называют трейтами или типажами), зависимые типы данных и т.д.
Но это не значит, что богатство синтаксиса типов полезно.
Скажите, а зачем вам язык программирования? Например, какая польза от ООП, когда можно просто написать код? Вопрос о причинах существования языков программирования более интересный, чем кажется, потому что основную проблему, которую решают языки — это не «веб-сервер в две строки» (на ассемблере так тоже можно), а контроль типов.
Само существование типов данных (например, что «строка» и «число» — это разные типы) — это ограничение на то, что можно делать. В си, где эти ограничения слабые, вы можете сделать char x = 'а' + 1; и это будет валидным (хотя и означает невалидную ахинею, если a — русская в utf-8). Более благородные языки запрещают такие кульбиты без явного кастинга, т.е. лучше защищают программиста от ошибок.
Само существование типов данных (например, что «строка» и «число» — это разные типы) — это ограничение на то, что можно делать. В си, где эти ограничения слабые, вы можете сделать char x = 'а' + 1; и это будет валидным (хотя и означает невалидную ахинею, если a — русская в utf-8). Более благородные языки запрещают такие кульбиты без явного кастинга, т.е. лучше защищают программиста от ошибок.
Ограничения должны быть в голове программиста, а не в языке. Си конечно не предмет для подражания и в данном случае путаница возникает из за плохого синтаксиса Си. Операция сложения спутана с операцией соединения. В вашем примере это вполне нормальная операция с результатом 'b', а то что возможно вы хотели что то другое это к компилятору никакого отношения не имеет.
<Разумеется, в языках программирования всё хуже, чем хотелось бы. Но всё, что вы хотите, уже давно есть. Выбирайте — php, javascript — все они радостно будут «управлять типами данных» за вас. А вам останется всего лишь написать логику программы для обработки undefined'ов.>
Конечно есть MUMPS существует уже давно, нет хорошей реализации этого языка, да и некоторые конструкции этого языка устарели. Поэтому то я и занялся этим неблагодарным делом.
Конечно есть MUMPS существует уже давно, нет хорошей реализации этого языка, да и некоторые конструкции этого языка устарели. Поэтому то я и занялся этим неблагодарным делом.
К сожалению, практика показала, что идеального языка быть не может (иначе бы он у нас уже был).
Так что, как по Абатуру: «Генетические цепочки не совместимы. Нужно выбрать.»
Так что, как по Абатуру: «Генетические цепочки не совместимы. Нужно выбрать.»
Если в ассемблере все так прекрастно, зачем придумывать что-то новое?
Пассаж про статическую типизацию тоже огонь.
Пассаж про статическую типизацию тоже огонь.
Язык должен полностью брать на себя все управление данными, в том числе разбираться с их типами. Что вполне реально. А программист должен заниматься логикой программы.
Потом программист сидит и бьется головой о клавиатуру, пытаясь понять, в каком месте его программы данные из числа становятся строкой, и var + 1 вместо прибавления единицы к числу начинает приписывать единичку в хвост строки…
Передача параметров через стек. Надо просто отказаться от списка формальных параметров, а передавать параметры через какой либо список.
А извлекать эти параметры из списка потом как? По порядковым номерам? У — удобство!
Списки формальных параметров для того и придумали, чтобы не париться с нумерацией аргументов, а сразу иметь понятное имя.
Возвращать переменное число значений функции мне не совсем понятно для чего и как этим можно воспользоваться. Возвращать в любом случае надо какую то одну сущность.
Если вам непонятно — поиграйтесь с языками, поддерживающими возврат списка значений. Например, с Lua. Там можно вернуть, например, список из bool и какого-то значения: если bool == true, то в значении — полезная нагрузка, а если в bool лежит false, то это значит, что произошла ошибка, а вместо значения — дополнительные сведения об этой ошибке.
Небольшие нюансы возникают с использованием команды goto. Мне не понятно почему с таким остервенением борются с этой командой.
Потому что:
а) с помощью goto плюс if можно сэмулировать все структурные управляющие конструкции (циклы с пред- и постусловием, switch/case, и т.п.). При этом код воспринимается хуже (надо вдумываться, куда мы переходим и при каких условиях). Ну и ошибки легче допустить.
б) Очень легко превратить код в лапшу, в которой невозможно разобраться.
Чтобы понять, насколько хренов бывает goto, можно поиграть на досуге в старую игру на бейсике:
Начальный код:
10 LET A = 0
20 LET B = 0
1. Играют двое. Ходят по очереди. За один ход можно написать в программе (в свободной строке с любым номером, большим 30) одну строчку.
2. После каждого хода противник может заявить, что программа зациклена. Программу запускают и проверяют, что она действительно зациклена (т.е. не останавливается через оговоренное время — скажем, 30 секунд). Если да, то объявивший выигрывает. Если нет, то проигрывает.
3. Игрок А может писать одну из двух строк на выбор: а) LET B = NOT B, и б) IF A THEN GOTO xxx
4. Игрок Б, соответственно, может писать а) LET A = NOT A, и б) IF B THEN GOTO xxx
5. Цель для GOTO должна существовать.
По договоренности можно вводить другие допустимые команды (например, LET A = NOT B).
Как правило, уже в районе десятого хода программа превращается в фигпоймичокакработает и очень неплохо иллюстрирует, что такое спагетти-код.
Отладка простейшей программы на Си может занять месяца. И все это по моему мнению порождено типизацией в языках программирования.
Отладка простейшей программы на пыхпыхе тоже может занять месяца, если программист неопытный и не понимает, что творит. Я уж не говорю про ассемблер. Порождено ли это отсутствием типизации? Не уверен.
Кого заинтересовала моя работа пишите на почту, вышлю дистрибутив.
Уже лет десять как исходники можно выложить на какой-нибудь гитхаб. Заодно и желающие помочь смогут сразу включиться в работу над кодом.
Или вы думаете, что кто-то всерьез захочет использовать в коммерческом проекте интерпретатор неизвестного языка программирования, да еще и без исходников?
$_[0], $_[1] — в Perl всё придумано. Удобно — офигеть (когда не 1-2 параметра, память там развивется и прочие навыки), тем более первое, что делается:
local $par_name = $_[0] # или shift
И удобнее и нет доступа по индексу к массиву.
Автору же предлагаю заменить всё переменные на элементы одного массива и обращаться по номерам.
local $par_name = $_[0] # или shift
И удобнее и нет доступа по индексу к массиву.
Автору же предлагаю заменить всё переменные на элементы одного массива и обращаться по номерам.
Кого заинтересовала моя работа пишите на почту, вышлю дистрибутив.
Что за древний способ? Почему бы не выложить на GitHub?
Уж не знаю, кто и чему вас учил, но я не согласен с вами.
Объектное программирование
Если в языке нет поддержки объектов, то ваше писание в объектном стиле выльется в реализацию недостающих моментов средствами самого языка. Иногда это оправдано, но не так часто, как вам хотелось бы.
Управление данными, типизация
Нет ни какого антагонизма между статической и динамической типизацией. Вопрос в выборе наименьшего зла и извлечения максимальной пользы из сделанного выбора. Php или perl выполняют неявное приведение типов, это позволяет не задумываться об этом разработчику, но дает побочный эффект, в виде, подчас трудноуловимых, ошибок. Python позволяет динамическую типизацию, вы можете в разные моменты времени присваивать одной и той же переменной значения разных типов, но контролирует тип при выполнении операций. Языки со статической типизацией позволяют избежать некоторого количества ошибок в процессе компиляции. Go и rust пытаются извлечь еще больше пользы из знания типов переменных в процессе разбора исходного кода. Более того, как минимум, php и python совсем не прочь научится фиксировать тип переменной в своем коде.
Управление процессом выполнения
Все архитектурные вещи лучше выносить в библиотеки, оставляя среду исполнения максимально гибкой и легковесной. Если есть подозрение, что появится потребность в тонкой оптимизации, предусмотрите FFI для вашего языка, хотя бы с Си. Это, к стати, упростит появление биндингов с большими и популярными библиотеками, которые с вас обязательно спросят, как только вы убедите кого либо использовать ваш язык.
>Надо просто отказаться от списка формальных параметров, а передавать параметры через >какой либо список
Вы про Forth (Форт) язык с отказом в нём от связи фактических и формальных параметров читали? (хотя в стандарте 94-года добавили и эту возможность).
С использованием стека, при этом, построено много конкатенативных языков.
P.S. Другие моменты в Форт тоже интересны.
Вы про Forth (Форт) язык с отказом в нём от связи фактических и формальных параметров читали? (хотя в стандарте 94-года добавили и эту возможность).
С использованием стека, при этом, построено много конкатенативных языков.
P.S. Другие моменты в Форт тоже интересны.
Я не являюсь сторонником ни того, ни другого подхода.Расскажите о вашем подходе, сторонником которого вы являетесь.
Я считаю типизацию как таковую основным злом современных языков программирования.Приведите пожалуйста пример, как можно обойтись без типизации. Так или иначе, программе нужно «знать» формат хранения данных в памяти по определенному адресу.
Я вас не знаю и не знаком с вашими работами, но чисто субъективно, у меня создается ощущение, что у вас в голове какая-то каша.
Незнание не является аргументом. В моем тексте упоминается язык MUMPS. Он и является примером.
Программе знать тип конечно необходимо. Но выносить это на программиста вовсе не обязательно. Я знаю по крайней мере 2 способа это реализовать. Любую переменную приводить к одному типу, либо хранить вместе с переменной ее тип.
Программе знать тип конечно необходимо. Но выносить это на программиста вовсе не обязательно. Я знаю по крайней мере 2 способа это реализовать. Любую переменную приводить к одному типуЕсли все хранить в строках, о высокой производительности можно забыть, да и памяти это съест больше, чем могло бы.
либо хранить вместе с переменной ее тип.А тут получается tagged union, использование которого похоже на эмуляцию динамической типизации средствами языка, ее не поддерживающего. Любой интерпретатор языка с динамической типизацией должен хранить значения переменных подобным образом.
По сути получается, что вы скорее сторонник динамической типизации и ваш язык программирования не подойдет для задач, требующих максимальной производительности.
Я являюсь сторонником безтипового языка.
<Я вас не знаю и не знаком с вашими работами, но чисто субъективно, у меня создается ощущение, что у вас в голове какая-то каша.>
В голове у меня как раз все в порядке. MUMPS давно стандартизованный язык. Идеи этого языка хорошо проверены.
В голове у меня как раз все в порядке. MUMPS давно стандартизованный язык. Идеи этого языка хорошо проверены.
У динамической типизации преимуществом называлось гибкость языка, но недостатком якобы является ненадежность языка и плохая адаптируемость к средам разработки. У статической типизации все с точностью до наоборот. Я считаю доводы о лучшей надежности языков со статической типизацией абсурдными, возможно что статическая типизация помогает в разработке средств программирования, но не более того.
Одно из самых главных преимуществ статической типизации — это возможность генерации максимально быстрого машинного или байт кода. Сложение двух целых чисел со статической типизацией будет занимать одну (!) машинную команду. При динамической типизации среда исполнения выполнит ряд плясок вокруг значения, на тему: «а что там лежит? а с чем это складывать? а тип операции допустим для первого типа? а для второго?». Это значительно ухудшает быстродействие (на порядок — запросто).
Есть и другие преимущества, например со статической типизацией переменные можно размещать в стеке — это еще плюс быстродействию и экономии памяти. С динамической типизацией в стеке можно поместить лишь указатель, а сама переменная будет в другом месте, и выделить под нее памяти — это опять куча танцев у менеджера памяти, а потом и у сборщика мусора. Для выделения памяти в стеке требуется снова одна-единственная машинная команда, причем на все переменные разом. Сбор мусора для переменных в стеке не нужен в принципе, это опять экономия ресурсов.
PS: А на MUMPS я работал, и даже писал интерпретатор подобного языка.
Ну тогда вы должны быть в курсе. Я не оспариваю преимущество типизации для трансляторов, они очевидны. Но считаю, транслятор должен быть для программиста, а не наоборот. Для скорости надо писать на Ассемблере.
Для скорости надо писать на Ассемблере.
Очень сомнительное утверждение.
Если вы не гуру AVX512 и прочих хитрых расширений, то любой оптимизирующий компилятор С уделает ваш ассемблерный код как по скорости работы, так и по скорости разработки.
По быстродействию — спорно. Если уж взялся за ассемблер, то знание всех возможностей процессора подразумевается :) Иначе — зачем?
А по скорости разработки — конечно.
А по скорости разработки — конечно.
Если уж взялся за ассемблер, то знание всех возможностей процессора подразумевается :)
Человек, в отличие от машины, гораздо хуже просчитывает такты, которые занимает та или иная инструкция. Особенно с учетом всяких привходящих обстоятельств: кэшей, пайплайнов, наличия/отсутствия отдельных блоков для распараллеливания инструкций, предсказания переходов и т. п. В результате код, написанный человеком, может быть компактнее, но при этом выполняться медленнее, чем сгенерированный оптимизирующим компилятором.
Вот если компилятор староват и не умеет, скажем, использовать векторные инструкции — тогда да, ассемблер ручной выделки может в разы увеличить производительность. Но в общем случае компилятор забарывает человека.
Если бы для скорости писали на ассемблере, ты Вы бы жили в совсем другом мире. Большинство операционных систем было бы не создано.
Для скорости надо писать на языках, близких к машине. Это C/C++. Быстродействие программ, написанных на них, не уступает ассемблеру (за исключением редких специальных случаев). И их быстродействие обусловлено, в том числе, статической типизацией.
Вообще, я не против языков с динамической типизацией. Мне, например, нравится Питон. Но каждый класс языков хорош для своей задачи.
Нужен максимум быстродействия и полный контроль над железом — выбираем C/C++, где-то, возможно, Ассемблер.
Нужно писать миллионы строк для интерпрайза — для этого хороши C# или Java.
Быстро сделать скрипт или прототип — неплох Питон.
Ну и т.д.
Для скорости надо писать на языках, близких к машине. Это C/C++. Быстродействие программ, написанных на них, не уступает ассемблеру (за исключением редких специальных случаев). И их быстродействие обусловлено, в том числе, статической типизацией.
Вообще, я не против языков с динамической типизацией. Мне, например, нравится Питон. Но каждый класс языков хорош для своей задачи.
Нужен максимум быстродействия и полный контроль над железом — выбираем C/C++, где-то, возможно, Ассемблер.
Нужно писать миллионы строк для интерпрайза — для этого хороши C# или Java.
Быстро сделать скрипт или прототип — неплох Питон.
Ну и т.д.
Для скорости надо писать на Ассемблере.
Что быстрее — dec+jnz или rep?
Я не оспариваю преимущество типизации для трансляторов
Трансялятор — далеко не единственная вещь, любой расчётный софт требует производительности, ваш язык получается неким эзотерическим языком с нулевой практичностью, тем более интерпретатор в настоящее время тоже не особо полезен. Непонимание что будет результатом оператора сложения для программиста хуже, а не лучше. Вы заявляете что "транслятор для программиста", но получается ровно наоборот, если брать автомобили, то у некоторых такие роботизированные коробки, которые по заявлению созданы для облегчения, но по факту надо подгадывать момент их переключения и подстраиваться под него, иначе будет рывок. Так и у вас — у нас нет типа и надо дополнительно ещё и представлять что получим в каждой конкретной операции.
Расчетные задачи не самая сильная сторона MSH. Все MUMPS системы разработаны для создания больших информационных систем. Там они и используются. Все используемые MUMPS системы интерпретаторы и этому есть серьезные причины. Часть конструкций этих языков не могут быть оттранслированы в принципе. MUMPS языки это не экзотика, а повседневный рабочий инструмент. То что MSH будет востребован сомнений нет. Просто для языка надо создать экосистему. Это дело труда и времени. Как только экосистема будет создана, с той минуты он и начнет использоваться. Есть достаточно большое сообщество которое в курсе о чем идет речь.
Результатом сложения всегда будет число, так как это арифметическая операция. Операцией сцепления всегда будет строка, так как это операция строковая. А при манипулировании данными вообще тип переменной не имеет никакого значения.
«1»+1, «a»+1, «1»+«1».
Программисту придётся задумываться что получилось в результате прошлой операции и что может быть в текущей, в «больших информационных системах»(больших по сегодняшним меркам) может быть много неожиданностей от этого.
Программисту придётся задумываться что получилось в результате прошлой операции и что может быть в текущей, в «больших информационных системах»(больших по сегодняшним меркам) может быть много неожиданностей от этого.
Думать как раз не надо. В MUMPS все всегда однозначно:
«1»+1=2,
«a»+1=1,
«1»+«1»=2.
Всегда так. В арифметической операции «a» = 0, а «25aw7/9» = 25
И никаких неожиданностей быть не может.
«1»+1=2,
«a»+1=1,
«1»+«1»=2.
Всегда так. В арифметической операции «a» = 0, а «25aw7/9» = 25
И никаких неожиданностей быть не может.
И никаких неожиданностей быть не может.
«1,5» + «2.5» =?
«5E2» + ".01" =?
" 123" + «3 2 1» =?
«1,5» + «2.5» =3.5
«5E2» + ".01" =5.01
" 123" + «3 2 1» =126
«5E2» + ".01" =5.01
" 123" + «3 2 1» =126
«1,5» + «2.5» =3.5
Это если локаль английская. А в русской локали не выдаст ли оно 3,5?
Хотя тут я, конечно, протупил — лучше было примерчик получше подобрать. Например, так:
«1,25» + «2.5» =?
В русской локали не даст ли 3,25?
«5E2» + ".01" =5.01
Т.е. MUMPS не умеет читать числа в научной нотации? Вы уверены? Это, скажем так, довольно большой недостаток.
" 123" + «3 2 1» =126
Т.е. ведущие пробелы игнорируются, а в середине строки — нет. Неожиданно. :)
Пробелы не игнорируются. В приведенных примерах я не заметил пробела. Если 123 начинается с пробела, то это 0.
" 123"+«3 2 1»=3
" 123"+«3 2 1»=3
Если 123 начинается с пробела, то это 0.
А это — еще неожиданнее, т.к. в большинстве языков ведущий пробел в числах игнорируется. Хотите вы или нет, но данные, сгенерированные в программах на других языках, рано или поздно придется импортировать. Если при этом надо будет писать свой собственный парсер чисел в научной нотации или «убиратор пробелов», возникает большой вопрос: а тем ли мы занимаемся.
Я вообще все это к тому, что многие ваши утверждения про MUMPS в комментариях («это лучший язык для обучения программированию», «там нет никаких неожиданностей» и т. п.) попахивают синдромом утенка. Особенно если почитать внимательно ваши отзывы о других языках программирования («пощупал — не понравилось, то ли дело MUMPS»). Я вас не осуждаю — сам такой, но одно дело держаться привычного, и совсем другое дело — рекламировать то, к чему вы привыкли, как панацею от всего. :)
<А это — еще неожиданнее, т.к. в большинстве языков ведущий пробел в числах игнорируется. >
MUMPS имеет стандарт. Претензии к Американскому институту стандартов. Видимо они посчитали, что так правильно.
<Я вообще все это к тому, что многие ваши утверждения про MUMPS в комментариях («это лучший язык для обучения программированию», «там нет никаких неожиданностей» и т. п.) попахивают синдромом утенка. Особенно если почитать внимательно ваши отзывы о других языках программирования («пощупал — не понравилось, то ли дело MUMPS»). Я вас не осуждаю — сам такой, но одно дело держаться привычного, и совсем другое дело — рекламировать то, к чему вы привыкли, как панацею от всего. :)>
Это мое личное мнение, я всегда стараюсь это указывать. Вас никто не заставляет придерживаться такого же мнения. Что такое синдром утенка, я не понимаю.
<(«пощупал — не понравилось, то ли дело MUMPS»). >
Я не щупал, а довольно долго программировал на разных языках. И продолжаю это делать сейчас. А рекламирую я потому что, считаю что он как язык действительно лучше других. Но это мой личный опыт. Этот язык нуждается в рекламе. Он архитектурно построен правильно в отличии от других языков. Но для него нет нормальной реализации. Вместо того что бы писать еще один go, по моему необходимо сделать нормальный интерпретатор с этого языка и среду разработки. Чем собственно я и занимаюсь.
MUMPS имеет стандарт. Претензии к Американскому институту стандартов. Видимо они посчитали, что так правильно.
<Я вообще все это к тому, что многие ваши утверждения про MUMPS в комментариях («это лучший язык для обучения программированию», «там нет никаких неожиданностей» и т. п.) попахивают синдромом утенка. Особенно если почитать внимательно ваши отзывы о других языках программирования («пощупал — не понравилось, то ли дело MUMPS»). Я вас не осуждаю — сам такой, но одно дело держаться привычного, и совсем другое дело — рекламировать то, к чему вы привыкли, как панацею от всего. :)>
Это мое личное мнение, я всегда стараюсь это указывать. Вас никто не заставляет придерживаться такого же мнения. Что такое синдром утенка, я не понимаю.
<(«пощупал — не понравилось, то ли дело MUMPS»). >
Я не щупал, а довольно долго программировал на разных языках. И продолжаю это делать сейчас. А рекламирую я потому что, считаю что он как язык действительно лучше других. Но это мой личный опыт. Этот язык нуждается в рекламе. Он архитектурно построен правильно в отличии от других языков. Но для него нет нормальной реализации. Вместо того что бы писать еще один go, по моему необходимо сделать нормальный интерпретатор с этого языка и среду разработки. Чем собственно я и занимаюсь.
В среде решений разных примеров на rosettacode есть и MUMPS
Programming Languages
как и на многих других языках.
Programming Languages
как и на многих других языках.
Что такое синдром утенка, я не понимаю.
Синдром утенка.
Я не щупал, а довольно долго программировал на разных языках. И продолжаю это делать сейчас.
Судя по тому, какие недостатки вы нашли в «разных языках», вы пытались программировать на них, как в MUMPS. Естественно, что они для этого плохо подходят.
Он архитектурно построен правильно в отличии от других языков.
Кхм. А какая у него архитектура-то? Из ваших статей это непонятно.
Думаю, если написать несколько статей «MUMPS для чайников», где разбирались бы его архитектурные решения и давался бы краткий курс языка, это принесло бы ему гораздо больше пользы, чем критика конкурентов и публикация предполагаемых доработок.
Ссылка на утенка попахивает оскорблением. Ну а по существу. Я начинал программировать на языке Аналитик. Такой русский Алгол. Никакого отношения к MUMPS он не имеет. И я до сих пор считаю этот язык одним из двух лучших как по идеям, так и по реализации. Затем программировал на PL1, Фортран и Алгол. Затем разрабатывал на Паскале. Только потом познакомился с MUMPS. Писал на С++, С, Java и JavaScript. Поэтому по моему я не подхожу под ваше определение. Навешивание ярлыков не самый убедительный аргумент в споре. Аналитик и MUMPS абсолютно разные языки, но только их я считаю лучшими. Я много писал и пишу на Delphi(Паскаль). Основное преимущество языка богатая визуальная библиотека. Но библиотека сделана как будто в папыхах. Слепили как попало. Дорабатывать компоненты не стали. А занялись расширение библиотеки. Куча разных недоотлаженных компонентов. Но долгое время всему этому даже альтернативы не было. Остальные языки не намного лучше. Пожалуй только Си явно выделяется из за своей прекрасной интеграцией с ОС.
Ссылка на утенка попахивает оскорблением.
Прошу прощения, если обидел. Но уж очень ваша категоричность похожа на то, что я видел: проникся человек каким-то языком программирования и все остальные для него как бы перестают существовать. :)
Я много писал и пишу на Delphi(Паскаль). Основное преимущество языка богатая визуальная библиотека.
Паскаль — это да.
Но какие преимущества-то у MUMPS по сравнению с другими языками? Я пока, если честно, из ваших объяснений не очень много преимуществ увидел. Единый тип данных? Ну, у того же перла или питона преобразование типов настолько прозрачно, что можно считать, в них тоже тип данных не важен. Не надо объявлять переменные? Тоже так себе преимущество.
А что еще?
<Судя по тому, какие недостатки вы нашли в «разных языках», вы пытались программировать на них, как в MUMPS. Естественно, что они для этого плохо подходят.
>
Все языки разные. Невозможно на Паскале программировать как на MUMPS и наоборот. Это касается любого языка программирования. Даже после Си, так же на Java программировать невозможно. Для этого надо погрузиться в язык и его инфраструктуру. Для того, чтобы понять MUMPS надо начать на нем программировать. MUMPS это не питон. Может быть вам кажется, что отсутствие объявления переменных не важное свойство. Может еще, что то не так с вашей точки зрения. Но это совершенный язык, представляющей единое целое. И в этом единстве его свойств его преимущество. Преимущество любого языка невозможно доказать. Статьи подобные моей по поводу различных языков программирования появляются регулярно. В комментариях масса возражений и в результате каждый остается при своем мнении. Но у меня надежда, что кто то все таки попытается вникнуть в язык и он ему поможет. Без надежды жить нельзя.
>
Все языки разные. Невозможно на Паскале программировать как на MUMPS и наоборот. Это касается любого языка программирования. Даже после Си, так же на Java программировать невозможно. Для этого надо погрузиться в язык и его инфраструктуру. Для того, чтобы понять MUMPS надо начать на нем программировать. MUMPS это не питон. Может быть вам кажется, что отсутствие объявления переменных не важное свойство. Может еще, что то не так с вашей точки зрения. Но это совершенный язык, представляющей единое целое. И в этом единстве его свойств его преимущество. Преимущество любого языка невозможно доказать. Статьи подобные моей по поводу различных языков программирования появляются регулярно. В комментариях масса возражений и в результате каждый остается при своем мнении. Но у меня надежда, что кто то все таки попытается вникнуть в язык и он ему поможет. Без надежды жить нельзя.
Если не вникать в подробности, то мой опыт говорит, что основное преимущество MUMPS, это низкая трудоемкость разработки, внедрения и сопровождения. Правда, только при грамотном проектировании системы. Трудоемкость может отличаться на порядки.
Но вообще то мы говорим с вами о разных вещах. Вы говорите о существующих языках программирования. MUMPS как язык программирования отсутствует. Его нет. Его нельзя сравнивать ни с одним языком. Он есть в стандарте, а в реализации он присутствует в качестве языка баз данных. Это связано, как я считаю с необходимостью зарабатывать на нем. Базу данных проще продавать, чем язык программирования. То о чем я пишу, это потенциальные возможности языка. Реализацию языка надо писать. MSH это и есть такая попытка. А язык проверенный и он точно будет работать. Но его необходимо довести до рабочего состояния.
Невозможно на Паскале программировать как на MUMPS и наоборот. Это касается любого языка программирования. Даже после Си, так же на Java программировать невозможно.
Вы слишком категоричны.
Я видел довольно много программистов, которые после джавы взялись работать на С++. Даже после нескольких лет работы их код явно попахивал джавой (к примеру, смелое использование new и постоянное забывание про delete — это типичная ошибка бывшего джависта).
Про то, как пишут бывшие сишники, можно вообще саги писать. Привычки, оставшиеся после С, довольно трудно вытравить, и код бывших сишников тоже безошибочно распознается. :)
Для того, чтобы понять MUMPS надо начать на нем программировать.
Изучение нового языка — это инвестиции (вкладываем свое время и труд, в перспективе получаем некий выхлоп — деньги, славу, женщин, власть и т. п.). Ваша задача как популяризатора языка — так рассказать о потенциальном «выхлопе», чтобы у читающего возникло желание вложиться в изучение языка.
Вы же пытаетесь пойти от обратного: «сначала попробуй, и тебе понравится». Это прокатит только тогда, когда язык заведомо перспективный (например, тот же голанг, за которым стоит поддержка гугла, или джава, на которой написаны гигабайты кода). MUMPS — язык нишевый, и для него это не сработает.
Преимущество любого языка невозможно доказать.
Так и не надо доказывать.
Вы расскажите о языке с точки зрения тех его преимуществ, которые вам нравятся. Подробненько, с примерами, так, чтобы читатель мог сам их пощупать и убедиться, что да, это удобно. А у вас что? Абстрактные утверждения («это совершенный язык»), которые невозможно ни принять, ни опровергнуть.
Но у меня надежда, что кто то все таки попытается вникнуть в язык и он ему поможет. Без надежды жить нельзя.
Чтобы люди попытались вникнуть в некий язык программирования, они должны представлять, зачем им тратить время и силы. Результат-то какой будет?
Из ваших комментариев пока неясно даже, в какой сфере этот язык применим.
MUMPS как язык программирования отсутствует. Его нет. Его нельзя сравнивать ни с одним языком. Он есть в стандарте, а в реализации он присутствует в качестве языка баз данных
Вы не путайте читателей в моем лице. :)
Так есть MUMPS или нет? Если есть, то где его можно пощупать? Если полноценной реализации нет, то напрашивается логичный вывод: имеющиеся реализации узко заточены под некую область, где их можно использовать (базы данных?), при этом как они поведут себя в других областях — неведомо. Откуда тогда такая уверенность, что он — лучший для всего?
<Вы слишком категоричны.
Я видел довольно много программистов, которые после джавы взялись работать на С++. Даже после нескольких лет работы их код явно попахивал джавой (к примеру, смелое использование new и постоянное забывание про delete — это типичная ошибка бывшего джависта).
Про то, как пишут бывшие сишники, можно вообще саги писать. Привычки, оставшиеся после С, довольно трудно вытравить, и код бывших сишников тоже безошибочно распознается. :)>
Это как раз и подтверждает мою мысль.
<Чтобы люди попытались вникнуть в некий язык программирования, они должны представлять, зачем им тратить время и силы. Результат-то какой будет?
Из ваших комментариев пока неясно даже, в какой сфере этот язык применим.>
Ну для этого я написал свои статьи.
<Вы не путайте читателей в моем лице. :)
Так есть MUMPS или нет? Если есть, то где его можно пощупать? Если полноценной реализации нет, то напрашивается логичный вывод: имеющиеся реализации узко заточены под некую область, где их можно использовать (базы данных?), при этом как они поведут себя в других областях — неведомо. Откуда тогда такая уверенность, что он — лучший для всего?>
Ну попробовать то его как раз можно. Есть реализация Cache, есть GTM, есть MiniM. Хочешь попробовать, пробуй.
Я видел довольно много программистов, которые после джавы взялись работать на С++. Даже после нескольких лет работы их код явно попахивал джавой (к примеру, смелое использование new и постоянное забывание про delete — это типичная ошибка бывшего джависта).
Про то, как пишут бывшие сишники, можно вообще саги писать. Привычки, оставшиеся после С, довольно трудно вытравить, и код бывших сишников тоже безошибочно распознается. :)>
Это как раз и подтверждает мою мысль.
<Чтобы люди попытались вникнуть в некий язык программирования, они должны представлять, зачем им тратить время и силы. Результат-то какой будет?
Из ваших комментариев пока неясно даже, в какой сфере этот язык применим.>
Ну для этого я написал свои статьи.
<Вы не путайте читателей в моем лице. :)
Так есть MUMPS или нет? Если есть, то где его можно пощупать? Если полноценной реализации нет, то напрашивается логичный вывод: имеющиеся реализации узко заточены под некую область, где их можно использовать (базы данных?), при этом как они поведут себя в других областях — неведомо. Откуда тогда такая уверенность, что он — лучший для всего?>
Ну попробовать то его как раз можно. Есть реализация Cache, есть GTM, есть MiniM. Хочешь попробовать, пробуй.
<Т.е. MUMPS не умеет читать числа в научной нотации? Вы уверены? Это, скажем так, довольно большой недостаток.
>
Не уверен. Зависит от реализации.
<Это если локаль английская. А в русской локали не выдаст ли оно 3,5?
Хотя тут я, конечно, протупил >
По моему независимо от локали в MUMPS всегда используется '.'
Я не встречал использовании запятой.
>
Не уверен. Зависит от реализации.
<Это если локаль английская. А в русской локали не выдаст ли оно 3,5?
Хотя тут я, конечно, протупил >
По моему независимо от локали в MUMPS всегда используется '.'
Я не встречал использовании запятой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интерпретатор MSH