<Мой код отвечает на вопрос «Как с этим работать», а как код разрабов, привыкших к динамической типизации — «Как это работает». Оба подхода имеют право на жизнь, и есть инструменты для обоих, но только один может стоять во главе угла.>
Но это не все типизация в языке может вообще отсутствовать.
<Статическая хороша для больших проектов, которые годами делают сотни разрабов, а динамическая — для маленьких команд, для задач, где часто нужен write-only код. С динамической ты экономишь время и силы в начале разработки, а со статической — в конце.>
Сомнительное утверждение. Связь не просматривается.
Плохо то что на нем и его различных вариантах написаны огромные программные комплексы, а он для этого не подходит. С ростом объема кода на нем он становится совершенно неотлаживаемым. Кроме тогот он оказал негативное влияние на создателей других языков. Хотя не только он. Отличился в этом и Паскаль.
Со статьей согласен на 200%. Программирование превратилось в слоеный даже не пирог, а башню. Весь этот стек программных слоев не отлажен и никогда отлажен не будет. Фундамент этого стека ОС состоит из тысяч программ на Си. Уже там неимоверное количество ошибок. Остальные слои не лучше. Попытка совершенствовать этого монстра ведет в никуда. И бросить нельзя и тащить невыносимо. Нужен другой подход. Начиная от нормального языка к архитектуре процессора, новому протоколу интернета, разработке нового функционального браузера и создании на его основе ОС.Программирование должно быть в развитой среде, где вопросы манипулирования данными, коммуникаций и GUI должны быть решены ОС. Просто выбросить все наработки конечно же нельзя. Поэтому придется какое то время поддерживать оба направления. Но от нынешнего положения дел необходимо уходить. И искать новые пути не в мире языков Си, архитектуры x86 и OC UNIX.
Как делается я знаю. Вопрос в другом, надо ли так делать. Сколько можно толкаться на тропинке Windows-Linux. Неужто нет других дорог. Сегодняшнее состояние это тупик. Так жить в мире IT нельзя. Принципиально Windows и Linux это одно и тоже. Основная их проблема это объем кода. Его в принципе невозможно отладить и тем более сколько нибудь надежно сопровождать. Ну и в придачу зоопарк архитектур процессоров. Если придерживаться ваших концепций никакого прорыва в построении ОС никогда не будет. Будет еще один Linux который красиво завязывает шнурки. Ну очевидно тупик. Нет все продолжают топтаться на той же тропинке. Ну не знаешь куда идти. Посмотри назад может там есть другие пути. Оказывается есть. То что я описал не открытие Америки, а проверенная но заброшенная дорога. В уже в далеких 70-х годах в нашей стране была создана уникальная ЭВМ МИР-2 которая как раз была построена по этому принципу. Был взят язык почти Алгольного типа. С уникальными свойствами, но не о нем сейчас речь. Под этот язык была разработана ЭВМ. В ней был только один этот язык, который был прямо в ней прошит. Никакого ассемблера там и не было. Может в СССР были самые умные? Нет примерно в это же самое время в США была разработана одна из лучших на тот момент операционных систем DSM-11. Так вот в ней то же был только один язык высокого уровня и никаких Си и других ассемблеров. Который с блеском выполнял и функции языка программирования и языка управления ОС. Почему свернули с этого пути это уже совсем другая история. Может просто потеряли дорогу? Мне довелось работать с обеими системами и впечатление такое что пересел с легковушки на каток. Да он лучше умеет укатывать асфальт, но передвигаться на нем очень медленно. Windows и Linux для меня напоминает свалку, в которой не разбирается ни один человек в мире. Каждый живет в своем кусочке интуитивно изучив этот мирок. После Мир-2 и DSM-11 с их небольшими и исчерпывающими свойствами эти монстры произвели на меня гнетущее впечатление. Нет это не наш путь и никакими НИИ это не исправишь. Нельзя качество заменить количеством. Давно пора архитектуру процессора создать с ориентацией на единственный эффективный язык высокого уровня и от этой печки плясать. Система любая должна быть легкой и обозримой. Чтобы ее легко мог держать в голове любой человек, и это главное как показывает история возможно.
За основу надо брать язык высокого уровня. Под него проектировать процессор. Затем на этом языке написать браузер и на его основе создать ОС. Осталось только выбрать подходящий язык высокого уровня.
Эволюционное развитие по определению не предполагает революционных изменений. Но это не доказывает, что их не может быть вовсе. Как раз наоборот. Вообще то раньше в высших заведениях изучали философию и даже заставляли по ней сдавать экзамены. Так вот там написано, что эволюционное развитие время от времени прерывается революционными изменениями. И этот закон философии назывался переход количественных изменений в качественные. Как только количественных изменений будет достаточно они перейдут в качественные и эволюционное развитие перейдет на другой уровень. Так что вопрос о появлении качественно нового языка следует не из теории эволюционного развития. Вопрос в том накопилось ли достаточно новых эволюционных идей для качественно нового языка. Я считаю что да. И в ближайшее время возможно появление качественно нового языка, который сотрет со сцены все предыдущие языки программирования.
Плюсы и минусы без комментариев это нормально для сайтов об искустве и литературе, где оценка эмоциональная, нравится не нравится. А для технических сайтов по моему это неприемлемо. Конечно оценщикам это удобно. Не надо напрягаться и не надо внятно сформулировать причину. А может и нет никакой причины? А при наличии комментариев дурь каждого видна будет.
|Насколько мне известно(я конечно могу ошибаться) деревья в MUMPS физически не хранятся как деревья. И для обращения к локали — |идёт только поиск по хэш таблице. Что конечно дольше, чем обращение по смещению, если массив не сильно разреженный, и индексы |не велики.
— Этого не может быть. Хеш таблицы не упорядочены, дерево на них не построить.
|«MUMPS (англ. Massachusetts General Hospital Utility Multi-Programming System — Массачусетская основная мульти-программная система для |госпиталей; иногда M, или М-система) — язык программирования, созданный в 1966—1967 годах для использования в лечебной индустрии.»
В датах я не силе и должен с вами согласиться. То что он создан для лечебной индустрии в MUMPS никак не проявляется, кроме как в названии взятом из названия болезни. Это полнофункциональный язык программирования и на это указывает его стандарт.
|Про Caсhe писали, что локальные деревья показывают очень неплохую скорость. И поэтому стоит подробнее описать архитектуру
| вашего решения по массивам, чтобы было понятно, за счёт чего оно работает быстрее.
Быстрее по сравнению с чем? Другими реализациями? Я не могу быть точно уверенным, но по моему, чтобы обратиться к дереву надо прочитать каталог, найти на головной странице нужный ключ и найти на странице данных нужное значение. Как то это все можно оптимизировать, но по сравнению с прямым обращением в память это разные порядки. Обращение к элементу массива в MSH выполняется как к массиву в языке Си. Берется начало массива и по индексу находится значение за одно обращение к памяти. Оно в принципе быстрее обращения к любому дереву.
|Скорее не появилось изменений, соответствующих современному представлению большинства об удобном языке.
Почему не появилось? MSH как раз и есть новое представление об удобном языке. Ну а большенство надо убеждать, что это оно и есть.
|Про Caсhe писали, что локальные деревья показывают очень неплохую скорость. И поэтому стоит подробнее описать архитектуру
| вашего решения по массивам, чтобы было понятно, за счёт чего оно работает быстрее.
Быстрее по сравнению с чем? Другими реализациями? Я не могу быть точно уверенным, но по моему, чтобы обратиться к дереву надо прочитать каталог, найти на головной странице нужный ключ и найти на странице данных нужное значение. Как то это все можно оптимизировать, но по сравнению с прямым обращением в память это разные порядки.
|Мне кажется, что как раз от такой магии в языках и надо избавляться.
Ну какая магия. Как раз это традиционное решение. Локализация переменных одно из немногих идей которые я взял из традиционных языков. Единственно мне пришлось опереться на префиксы, так как предварительного описания переменных у меня нет. Меня честно достало глобальность локальных переменных по умолчанию. А в каждой программе писать New и следить чтобы содержание этой команды соответствовало локальным для данной программы переменным дополнительная ненужная работа.
|А почему бы не поступить наоборот: Нужна декларативная часть для описания объектов, поэтому в MSH добавлена декларация переменных.
Объекты декларировать, а переменные нет? Но чем модуль не есть декларация класса? Методы там есть. Ну нет перечня защищенных переменных. Да и не надо. Переменные не имеют типа, что у них описывать, имя? Можно обойтись без этого.
|MUMPS во главу угла ставит данные, соответственно в нём вместо событий — триггеры.
Ничего о триггерах не слышал.
|А как вам такой (не осуществлённый к сожалению) вариант для развития MUMPS — MOLE?
Интересная попытка. Я категорически против декларативной части класса. И мне не нравится описание класса взятое в лоб из декларативных языков. Да и дополнительные описатели по моему только запутывают. С итератором по одному уровню я согласен, а где итератор по Query?
Оператор while интересное решение. Перечень методов обработки строк хорош, но по моему недостаточно полон.
Ну допустим в MUMPS транзакции есть. А нужны они для сохранения целостности данных. Но проблему формирования отчета из одного состояния данных. транзакции не решают.
Выход конечно славный. Но я слабо представляю как это можно практически осуществить, кроме как остановив корректировку сделав копию в сторонку и работать с этой копией. Технически это возможно сделать. Но практически достаточно затратно и долго. Я в подобной ситуации работаю с кривоватыми данными. Заморозить всю систему и делать копию не выход. Хотя можно отложить корректировку до определенного момента времени, но тогда возникнут проблемы на рабочем месте у корректирующего данные.
Пример на MUMPS
Set A=5
Write A
; до этого момента имеем старое значение и никакого времени нет
Set A=6
; здесь новое значение =6 момент определен командой Set причем тут время? Какие проблемы могут здесь возникать?
Но это не все типизация в языке может вообще отсутствовать.
<Статическая хороша для больших проектов, которые годами делают сотни разрабов, а динамическая — для маленьких команд, для задач, где часто нужен write-only код. С динамической ты экономишь время и силы в начале разработки, а со статической — в конце.>
Сомнительное утверждение. Связь не просматривается.
А система отображения файлов в память есть?
— Этого не может быть. Хеш таблицы не упорядочены, дерево на них не построить.
В датах я не силе и должен с вами согласиться. То что он создан для лечебной индустрии в MUMPS никак не проявляется, кроме как в названии взятом из названия болезни. Это полнофункциональный язык программирования и на это указывает его стандарт.
|Про Caсhe писали, что локальные деревья показывают очень неплохую скорость. И поэтому стоит подробнее описать архитектуру
| вашего решения по массивам, чтобы было понятно, за счёт чего оно работает быстрее.
Быстрее по сравнению с чем? Другими реализациями? Я не могу быть точно уверенным, но по моему, чтобы обратиться к дереву надо прочитать каталог, найти на головной странице нужный ключ и найти на странице данных нужное значение. Как то это все можно оптимизировать, но по сравнению с прямым обращением в память это разные порядки. Обращение к элементу массива в MSH выполняется как к массиву в языке Си. Берется начало массива и по индексу находится значение за одно обращение к памяти. Оно в принципе быстрее обращения к любому дереву.
Почему не появилось? MSH как раз и есть новое представление об удобном языке. Ну а большенство надо убеждать, что это оно и есть.
|Про Caсhe писали, что локальные деревья показывают очень неплохую скорость. И поэтому стоит подробнее описать архитектуру
| вашего решения по массивам, чтобы было понятно, за счёт чего оно работает быстрее.
Быстрее по сравнению с чем? Другими реализациями? Я не могу быть точно уверенным, но по моему, чтобы обратиться к дереву надо прочитать каталог, найти на головной странице нужный ключ и найти на странице данных нужное значение. Как то это все можно оптимизировать, но по сравнению с прямым обращением в память это разные порядки.
|Мне кажется, что как раз от такой магии в языках и надо избавляться.
Ну какая магия. Как раз это традиционное решение. Локализация переменных одно из немногих идей которые я взял из традиционных языков. Единственно мне пришлось опереться на префиксы, так как предварительного описания переменных у меня нет. Меня честно достало глобальность локальных переменных по умолчанию. А в каждой программе писать New и следить чтобы содержание этой команды соответствовало локальным для данной программы переменным дополнительная ненужная работа.
|А почему бы не поступить наоборот: Нужна декларативная часть для описания объектов, поэтому в MSH добавлена декларация переменных.
Объекты декларировать, а переменные нет? Но чем модуль не есть декларация класса? Методы там есть. Ну нет перечня защищенных переменных. Да и не надо. Переменные не имеют типа, что у них описывать, имя? Можно обойтись без этого.
|MUMPS во главу угла ставит данные, соответственно в нём вместо событий — триггеры.
Ничего о триггерах не слышал.
|А как вам такой (не осуществлённый к сожалению) вариант для развития MUMPS — MOLE?
Интересная попытка. Я категорически против декларативной части класса. И мне не нравится описание класса взятое в лоб из декларативных языков. Да и дополнительные описатели по моему только запутывают. С итератором по одному уровню я согласен, а где итератор по Query?
Оператор while интересное решение. Перечень методов обработки строк хорош, но по моему недостаточно полон.
В предыдущей публикации //habrahabr.ru/post/241369/ есть описание языка MSH.
Set A=5
Write A
; до этого момента имеем старое значение и никакого времени нет
Set A=6
; здесь новое значение =6 момент определен командой Set причем тут время? Какие проблемы могут здесь возникать?