• Российские операционные системы: говорим сейчас, ждём на OS DAY
    –1
    Как делается я знаю. Вопрос в другом, надо ли так делать. Сколько можно толкаться на тропинке Windows-Linux. Неужто нет других дорог. Сегодняшнее состояние это тупик. Так жить в мире IT нельзя. Принципиально Windows и Linux это одно и тоже. Основная их проблема это объем кода. Его в принципе невозможно отладить и тем более сколько нибудь надежно сопровождать. Ну и в придачу зоопарк архитектур процессоров. Если придерживаться ваших концепций никакого прорыва в построении ОС никогда не будет. Будет еще один Linux который красиво завязывает шнурки. Ну очевидно тупик. Нет все продолжают топтаться на той же тропинке. Ну не знаешь куда идти. Посмотри назад может там есть другие пути. Оказывается есть. То что я описал не открытие Америки, а проверенная но заброшенная дорога. В уже в далеких 70-х годах в нашей стране была создана уникальная ЭВМ МИР-2 которая как раз была построена по этому принципу. Был взят язык почти Алгольного типа. С уникальными свойствами, но не о нем сейчас речь. Под этот язык была разработана ЭВМ. В ней был только один этот язык, который был прямо в ней прошит. Никакого ассемблера там и не было. Может в СССР были самые умные? Нет примерно в это же самое время в США была разработана одна из лучших на тот момент операционных систем DSM-11. Так вот в ней то же был только один язык высокого уровня и никаких Си и других ассемблеров. Который с блеском выполнял и функции языка программирования и языка управления ОС. Почему свернули с этого пути это уже совсем другая история. Может просто потеряли дорогу? Мне довелось работать с обеими системами и впечатление такое что пересел с легковушки на каток. Да он лучше умеет укатывать асфальт, но передвигаться на нем очень медленно. Windows и Linux для меня напоминает свалку, в которой не разбирается ни один человек в мире. Каждый живет в своем кусочке интуитивно изучив этот мирок. После Мир-2 и DSM-11 с их небольшими и исчерпывающими свойствами эти монстры произвели на меня гнетущее впечатление. Нет это не наш путь и никакими НИИ это не исправишь. Нельзя качество заменить количеством. Давно пора архитектуру процессора создать с ориентацией на единственный эффективный язык высокого уровня и от этой печки плясать. Система любая должна быть легкой и обозримой. Чтобы ее легко мог держать в голове любой человек, и это главное как показывает история возможно.
  • Российские операционные системы: говорим сейчас, ждём на OS DAY
    –1
    За основу надо брать язык высокого уровня. Под него проектировать процессор. Затем на этом языке написать браузер и на его основе создать ОС. Осталось только выбрать подходящий язык высокого уровня.
  • Когда появится следующий большой язык программирования с точки зрения Дарвина
    –1
    Эволюционное развитие по определению не предполагает революционных изменений. Но это не доказывает, что их не может быть вовсе. Как раз наоборот. Вообще то раньше в высших заведениях изучали философию и даже заставляли по ней сдавать экзамены. Так вот там написано, что эволюционное развитие время от времени прерывается революционными изменениями. И этот закон философии назывался переход количественных изменений в качественные. Как только количественных изменений будет достаточно они перейдут в качественные и эволюционное развитие перейдет на другой уровень. Так что вопрос о появлении качественно нового языка следует не из теории эволюционного развития. Вопрос в том накопилось ли достаточно новых эволюционных идей для качественно нового языка. Я считаю что да. И в ближайшее время возможно появление качественно нового языка, который сотрет со сцены все предыдущие языки программирования.
  • Почему я не люблю синтетические тесты
    –1
    Обязательно попробую в ближайшее время. Требования считаю вполне обоснованными. Мне надо еще разобраться как все это присобачить к NetBeans.
  • Почему я не люблю синтетические тесты
    +2
    Хотел попробовать вашу студию в Linux. Но оказывается нужна лицезия. Средствами не распологаю.
  • Google I/O 2016: Подробности об Android N и Android-экосистеме
    –11
    А язык Си в Андроид есть?
    А система отображения файлов в память есть?
  • Хабр умирает?
    0
    Плюсы и минусы без комментариев это нормально для сайтов об искустве и литературе, где оценка эмоциональная, нравится не нравится. А для технических сайтов по моему это неприемлемо. Конечно оценщикам это удобно. Не надо напрягаться и не надо внятно сформулировать причину. А может и нет никакой причины? А при наличии комментариев дурь каждого видна будет.
  • Особенности и отличия языка программирования MSH от MUMPS
    0
    |Насколько мне известно(я конечно могу ошибаться) деревья в MUMPS физически не хранятся как деревья. И для обращения к локали — |идёт только поиск по хэш таблице. Что конечно дольше, чем обращение по смещению, если массив не сильно разреженный, и индексы |не велики.
    — Этого не может быть. Хеш таблицы не упорядочены, дерево на них не построить.
  • Особенности и отличия языка программирования MSH от MUMPS
    0
    Согласен. Это мое слабое место.
  • Особенности и отличия языка программирования MSH от MUMPS
    0
    |«MUMPS (англ. Massachusetts General Hospital Utility Multi-Programming System — Массачусетская основная мульти-программная система для |госпиталей; иногда M, или М-система) — язык программирования, созданный в 1966—1967 годах для использования в лечебной индустрии.»

    В датах я не силе и должен с вами согласиться. То что он создан для лечебной индустрии в MUMPS никак не проявляется, кроме как в названии взятом из названия болезни. Это полнофункциональный язык программирования и на это указывает его стандарт.

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

    Быстрее по сравнению с чем? Другими реализациями? Я не могу быть точно уверенным, но по моему, чтобы обратиться к дереву надо прочитать каталог, найти на головной странице нужный ключ и найти на странице данных нужное значение. Как то это все можно оптимизировать, но по сравнению с прямым обращением в память это разные порядки. Обращение к элементу массива в MSH выполняется как к массиву в языке Си. Берется начало массива и по индексу находится значение за одно обращение к памяти. Оно в принципе быстрее обращения к любому дереву.
  • Особенности и отличия языка программирования MSH от MUMPS
    0
    |Скорее не появилось изменений, соответствующих современному представлению большинства об удобном языке.
    Почему не появилось? MSH как раз и есть новое представление об удобном языке. Ну а большенство надо убеждать, что это оно и есть.

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

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

    |Мне кажется, что как раз от такой магии в языках и надо избавляться.

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

    |А почему бы не поступить наоборот: Нужна декларативная часть для описания объектов, поэтому в MSH добавлена декларация переменных.

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

    |MUMPS во главу угла ставит данные, соответственно в нём вместо событий — триггеры.

    Ничего о триггерах не слышал.

    |А как вам такой (не осуществлённый к сожалению) вариант для развития MUMPS — MOLE?

    Интересная попытка. Я категорически против декларативной части класса. И мне не нравится описание класса взятое в лоб из декларативных языков. Да и дополнительные описатели по моему только запутывают. С итератором по одному уровню я согласен, а где итератор по Query?
    Оператор while интересное решение. Перечень методов обработки строк хорош, но по моему недостаточно полон.
  • Особенности и отличия языка программирования MSH от MUMPS
    –2
    Код чего?
    В предыдущей публикации //habrahabr.ru/post/241369/ есть описание языка MSH.
  • Замечательные zippers, или как я научился не волноваться и полюбил древовидные структуры данных
    0
    Ну допустим в MUMPS транзакции есть. А нужны они для сохранения целостности данных. Но проблему формирования отчета из одного состояния данных. транзакции не решают.
  • Замечательные zippers, или как я научился не волноваться и полюбил древовидные структуры данных
    0
    Выход конечно славный. Но я слабо представляю как это можно практически осуществить, кроме как остановив корректировку сделав копию в сторонку и работать с этой копией. Технически это возможно сделать. Но практически достаточно затратно и долго. Я в подобной ситуации работаю с кривоватыми данными. Заморозить всю систему и делать копию не выход. Хотя можно отложить корректировку до определенного момента времени, но тогда возникнут проблемы на рабочем месте у корректирующего данные.
  • Замечательные zippers, или как я научился не волноваться и полюбил древовидные структуры данных
    0
    Пример на MUMPS
    Set A=5
    Write A
    ; до этого момента имеем старое значение и никакого времени нет
    Set A=6
    ; здесь новое значение =6 момент определен командой Set причем тут время? Какие проблемы могут здесь возникать?
  • Замечательные zippers, или как я научился не волноваться и полюбил древовидные структуры данных
    0
    Я вынес из статьи, что речь идет о доступе к иерархическим данным и поэтому об этом и написал. Изменение данных в MUMPS осуществляется командой Set. Как при этом вносится время мне не понятно. Команда одномоментно изменяет структуру данных. Если изменения выполняются в одном потоке то коллизий не возникает, если в разных заданиях то есть примитивы синхронизации. Но это по моему всегда так. По поводу экономии места на диске и в ОП то же не понял. Ведь речь шла об интерфейсе к деревянным данным независимо от способа хранения этих данных.
    Извините дядюшку Боба понять не в состоянии, английским не владею.
  • Замечательные zippers, или как я научился не волноваться и полюбил древовидные структуры данных
    –1
    Ограничение на только <персистентных структур данных> сводит на нет ценность зипперов.
    Инструменты для работы с деревом данных достаточно развиты и ничего нового зипперы не дают.
    В MUMPS для работы с деревом данных используются 3 функции
    1 Next — следующий или предыдущий узел на том же уровне.
    2 Qery — следующий или предыдущий узел с данными на уровне ниже текущего.
    3 Data — состояние вершины. Есть ли в ней данные и есть ли потомки у узла.
    Хотя для работы с деревом хватило бы и одной функции Next.
    Такого интерфейса вполне достаточно для работы с любым деревом и без дополнительных ограничений.
  • Хабр умирает?
    +7
    Меня сильнее всего напрягает, когда ставят минусы без комментариев, либо с совершенно бессмысленными комментариями.
    Считаю, что система оценок должна быть более определенной. Если +, то почему, если — , то за что.
    Комментарии обязательны и должны контролироваться администрацией хабра. Особенно одиозных оценщиков надо лишать права оценивать.
    А так создается впечатление, что многие оценщики просто не в теме.
  • Разработка языков программирования и компиляторов в СССР
    0
    Если интересно то в интернете можно найти информацию по запросу:
    Аналитик язык Мир-2
  • Разработка языков программирования и компиляторов в СССР
    0
    Совсем забыли Глушкова. Его языки Мир-2 и Аналитик были революционными. И что очень важно были созданы под ЭВМ Мир-2. Это наверно единственное аппаратно программное решение по крайней мере на то время. Правда Аналитик вроде бы адаптировали для СМ-4. Но деталей не знаю. Так что кое где мы все таки первыми в мире были. А до возможностей языка Мир-2 и сейчас ни один язык не дорос.
  • Почему наши высокоуровневые языки до сих пор не такие уж и высокоуровневые?
    –1
    По моему самая простая реализация MUMPS http://www.minimdb.com/
    Там же есть книга по MUMPS http://www.minimdb.com/mbook/mumps_dbms.pdf
  • Почему наши высокоуровневые языки до сих пор не такие уж и высокоуровневые?
    –8
    Еще как замахнулся. И таких скелетов в шкафу хоть отбавляй. Для программирования типы данных вообще не нужны.И тип данных массив с индексацией с 0 тоже ненужен. В языке высокого уровня MUMPS ни типов ни массивов. А структура данных только одна дерево. Это тебе и массив с индексацией хоть от чего и список и стек. На все случаи жизни хоть в оперативной памяти хоть на диске. А все современные языки это топтание вокруг языка Си с его базовыми концепциями.
  • Почему Go — это плохо продуманный язык программирования
    –3
    Я тоже пытаюсь написать свой язык программирования. Если можете вышлите спецификацию своего языка и комментарии на misha_shar53@mail.ru. Хотелось бы ознакомиться.
  • Блоки. Внутреннее устройство файла базы данных Caché
    –2
    Не так. Низкоуровневое понимание ненужно. Обращение к данным элементарно, как к индексированному массиву. Администрирование эпизодическое. Установка и настройка необходимого уровня архивирования. За много лет работы с CACHE мне ни разу не пришлось ремонтировать блоки. Есть архивы, журнал.
  • Ликбез по типизации в языках программирования
    0
    >Критики MUMPS прямо называют эту технологию устаревшей[3]
    А Си, Паскаль, Си++ не устаревшие? А новые, что принципиально лучше старых? Чем это? Новые языки делаются очень просто. Берем Си и добавляем пробел в конце или еще что нибудь. Принципиально нового, кроме MUMPS ничего нет. Только в MUMPS управление данными полностью взял на себя язык. Унифицировано обращение к данным в памяти и на внешних носителях. В MUMPS работать с встроенной базой данных так же легко как и с памятью. То что я на MUMPS писал месяц, потом на Delphi переносил 2 года при этом пришлось купить и прочитать целый стеллаж книг. Программирование не на MUMPS это убийство времени, ресурсов и сил.
  • Ликбез по типизации в языках программирования
    0
    >Это такой тонкий толлинг? Открываем Википедию и читаем:
    А что Википедия истина в последней инстанции? А для обвинений надо быть в курсе.

    >Критики MUMPS прямо называют эту технологию устаревшей[3] и указывают на такие >недостатки MUMPS как[3][4]:
    >отсутствие типизации (все данные хранятся как строки);
    Это достоинство а не недостаток. А как что хранится неизвестно и даже безразлично. Программиста это никак не касается. Я думаю, что различные реализации MUMPS данные хранят по разному.
    >низкий уровень абстракции;
    Совершенно бездоказательное утверждение. На чем основан такой вывод? Абстракция от типов точно есть. Ни разу не встречал анализа уровня абстракции языка MUMPS.
    >нечитабельность синтаксиса, особенно при использовании сокращений.
    Не сокращай. Но даже с сокращениями вполне читабельный синтаксис. Ничем принципиально не отличающийся от других языков программирования.

    >Язык MUMPS критики называют провоцирующим ошибки, поскольку[3][4]:
    >отсутствует обязательное объявление (декларирование) переменных;
    Ну это никак не провоцирует ошибки. Все перевернуто с ног на голову. Само декларирование порождает массу понятий и правил их использования. И как следствие именно оно и провоцирует ошибки.
    >не поддерживаются привычные приоритеты арифметических операций (например, >выражение 2+3×10 даёт в MUMPS значение 50);
    Да именно так. Непривычно не значит хуже. Приоритеты операций отсутствуют. Это очень простое правило которым легко пользоваться и трудно допустить ошибку. А вы попробуйте запомнить приоритеты всех операций в Си. Голова идет кругом. Я все равно вынужден либо расставлять скобки, либо каждый раз лезть в справочник. Приоритеты в Си не везде очевидны.

    >лишний пробел или разрыв строки может совершенно изменить смысл синтаксической конструкции;
    ключевые слова языка не зарезервированы и могут широко использоваться в качестве идентификаторов.
    Ну и что? Во многих языках пробел завязан в синтаксисе. И как это влияет на надежность программ? MUMS на порядки надежней любого другого языка. Это простой, логичный, компактный и не противоречивый язык. В нем нет подводных камней. Описание всего языка вместе с примерами занимало 20 страниц книжки половинного формата A4. И этого вполне достаточно. При программировании в основном встречается 2 ошибки деление на ноль и неопределенный индекс. Так как нет декларирования и развитая структура переменных, программы просты, компактны и надежны. Я с 1984года программирую на MUMPS и считаю, что то что написано в Википедии поверхностный взгляд некомпетентного специалиста.
  • Ликбез по типизации в языках программирования
    –1
    Интересная статья. Впервые столкнулся с систематическим изложением данного вопроса. У меня в голове от всего этого была каша. Смешение понятий в вопросе типизации довольно частое явление в статьях. Хочу добавить несколько своих замечаний. Конечно ассемблер безтиповой язык. На уровне языка нет типов. Есть регистры, память и операции над ними. Как то на них отображаются типы языков высокого уровня. Но это уже проблемы этих языков.
    В статье хорошо изложены концепции типизации и хорошо видны противоречия возникающие в типизированных языках. Ясно, что необходима и статическая и динамическая и сильная и слабая типизация. И различные языки по разному находят этот баланс. В основном за счет расширения типов в языке или встроенных библиотеках. При этом совершенно очевидно что базовых типов недостаточно и появляются типы вроде даты и IP адресов. В целом все это мне напоминает ситуацию, когда сначала строят стену, а затем ее героически преодолевают. И очень горды там, как это удачно удалось осуществить. Популярный миф о том что типизация помогает создавать более надежные программы, не более чем миф. Все обстоит с точностью до наоборот. Яркий пример тому бестиповой язык MUMPS. Отсутствие в нем типов решает все проблемы типизации. Они в MUMPS просто отсутствуют. В результате имеется язык который можно освоить за один вечер. При этом простота языка никак не сказалась на его возможностях. Типизация это зло. Конечно картина с типизацией неоднозначна. Типы тесно связаны со структурой данных. Декларирование данных позволяет так же описать структуру данных, например массив. Встроенные библиотеки добавляют другие структуры стеки, очереди, хеш таблицы. Безтиповой язык должен решать и эту проблему. И MUMPS ее блестяще решил. Любая переменная может являться деревом произвольной структуры, в том числе и простой переменной. А уж из дерева сделать массив, стек или хеш таблицу ничего не стоит. Все типы ненужны. Транслятор сам разбирается с типом переменной. Операции однозначно задают тип операндов и результата. Такие понятия как типы переменных можно выбросить из головы и заняться поставленной задачей. Кстати рассматриваемый пример на MUMPS будет выглядеть так:
    find(.mass,element) set node=»»
    for i=0:1 set node=$O(mass(node)) q:node=»»!(node=element)
    q i
    При этом переменная mass может моделировать и массив и стек и хеш таблицу.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Хороший совет. Жаль не могу им воспользоваться.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Согласен с вами, нарушения целостности будут. Но в этом случае на порядок реже, да и они будут заметнее. Легче это проконтролировать. Да и все равно другого выхода нет.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    В идеальном мире свет в городе не отключают. УПС держит скачки напряжений, а базы корректно восстанавливаются из журналов. Увы у меня все не так. В городе и особенно в области отключение света банальная ситуация да и стабильного напряжения никто не гарантирует. Хочешь работай, не хочешь не работай.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Конечно не предоставляет. Но других систем у рядовых заказчиков нет. Обычные китайские компы. А вы наверно обитаете в стране чудес? Мне бы к вам. Тогда и буду использовать индексы и зависимые глобали. А пока приходится как то выкручиваться. Так и живем.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Наверно да. В 99% случаев все работает корректно. Транзакции используются. Блокировки нет. Эти глобали не корректируются из разных потоков. Обработка ошибок да. Но сообщений об ошибках не было.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Ну значит у нас разный опыт. А насчет отсутствия аппаратных проблем ничего сказать не могу в обоих случаях они могли иметь место. Что происходит у заказчика мы постоянно не контролировали. Возможно после выключения питания при повторном пуске шло какое то восстановление из журналов. Может еще что. Обычная дворцовая жизнь. Но системы в обоих случаях продолжали работать и ничего криминального не сообщали.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Конечно InterBase. А вы что верите сказкам, что такого не бывает в природе?
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Мне тоже.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Именно так. Транзакции есть, но они не всегда гарантируют корректность результатов. С подобной проблемой я сталкивался и в SQL базах при использовании индексов. Мир к сожалению не идеален и очень сложен. Сказать точно в какие моменты это происходит и почему я не могу, но с подобными явлениями я переодически сталкиваюсь.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Что пояснить? Что индекс в SQL базе может стать некорректным? Что дополнительная глобаль с индексацией может перестать соответствовать первичной глобали?
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    В глобалах есть транзакции. Теоретически все должно оставаться корректным. На практике это не так. Редко но бывает нарушение целостности данных, при этом это никак не проявляется внешне кроме как проверкой специальными утилитами или противоречий в выходных документах. А так как приложение работает у заказчика и нами постоянно не администрируется, обнаружиться нарушение целостности данных может поздно. Это проблема не только индексов, а любого дублирования первичных данных.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Безусловно волнует. Но из 2-х зол я всегда выбираю меньшее. А в моих случаях всегда корректность данных была важнее скорости. Но возможны варианты.
  • Глобалы — мечи-кладенцы для хранения данных. Деревья. Часть 1
    0
    Другого способа нет. В подобном случае пользуюсь прямым перебором.