![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Моё представление, что Михаил Донской, создатель Каиссы смотрит на мир очень через розовые очки, ибо глядя на новые WIN10 с АЙосями, ежей терзают смутные сомнения, что "культура создания операционных систем" ноне утрачена, возможно и навсегда, вместе с носителями – людьми, которые умеют это делать не только у нас, но и во всём мире, хотя и до этого нужно честно сказать получалось в лучшем случае хорошо. А когда и умеющие думать системно уйдут, то и цивилизация тоже станет совсем другой. Статью Донского кстати лучше прочитать целиком, она довольно любопытна.
Глушков и Кузин победили (а судьей был председатель ГКНТ Кириллин), но все оказалось не так-то просто. Первый компьютер серии с трудом (титаническим трудом инженеров-электронщиков, запустивших его в жаркое лето 1972 года на ВДНХ, после чего они искупались в фонтане Дружбы Народов) был запущен в 1972 году, а массовая работа на нем – только в 1979 году. Все это время я неплохо зарабатывал лекциями по ОС ЕС ЭВМ. Документация по системе переводилась моими однокурсницами и другими людьми, не представлявшими себе, что такое компьютер вообще и операционная система в частности, и разобраться по такой документации было невозможно.
Таким образом, Глушков и Кузин просчитались именно в этой компоненте – культуре пользования. Теперь я понимаю, что неправ был и Кронрод, за которого я «болел», потому что надо было и копировать IBM и делать свои машины именно для сохранения культуры. А в итоге к 80-м мы потеряли культуру проектирования элементов, потом и культуру проектирования устройств, а сейчас от нас уходит (вместе с носителями – людьми, которые умеют это делать) культура создания операционных систем.
В итоге, вместо того, чтобы догнать кого-то, мы отстали в этих компонентах навсегда. И, повторюсь, не потому, что нет нужных производств или знаний, а потому, что почти не осталось людей, которые это умеют делать.
А в 80-х началась эра языка Си на машинах, скопированных с PDP и IBM PC. Мы потеряли весь свой ассемблерный «языковый запас» и так и не достигли аналогичного уровня инструментария на Си. Это была своего рода эмиграция. Привыкнув к детальному пониманию, как происходят реальные вычисления в памяти, пришлось отвыкать и работать в гораздо более абстрактных сущностях.
Зато остался интерес к базовым понятиям программирования, выходящим за пределы конкретных языков, операционных систем и устройств. Как любят говорить мои сотрудники «В конце концов, в компьютере биты бегают».
Глушков и Кузин победили (а судьей был председатель ГКНТ Кириллин), но все оказалось не так-то просто. Первый компьютер серии с трудом (титаническим трудом инженеров-электронщиков, запустивших его в жаркое лето 1972 года на ВДНХ, после чего они искупались в фонтане Дружбы Народов) был запущен в 1972 году, а массовая работа на нем – только в 1979 году. Все это время я неплохо зарабатывал лекциями по ОС ЕС ЭВМ. Документация по системе переводилась моими однокурсницами и другими людьми, не представлявшими себе, что такое компьютер вообще и операционная система в частности, и разобраться по такой документации было невозможно.
Таким образом, Глушков и Кузин просчитались именно в этой компоненте – культуре пользования. Теперь я понимаю, что неправ был и Кронрод, за которого я «болел», потому что надо было и копировать IBM и делать свои машины именно для сохранения культуры. А в итоге к 80-м мы потеряли культуру проектирования элементов, потом и культуру проектирования устройств, а сейчас от нас уходит (вместе с носителями – людьми, которые умеют это делать) культура создания операционных систем.
В итоге, вместо того, чтобы догнать кого-то, мы отстали в этих компонентах навсегда. И, повторюсь, не потому, что нет нужных производств или знаний, а потому, что почти не осталось людей, которые это умеют делать.
А в 80-х началась эра языка Си на машинах, скопированных с PDP и IBM PC. Мы потеряли весь свой ассемблерный «языковый запас» и так и не достигли аналогичного уровня инструментария на Си. Это была своего рода эмиграция. Привыкнув к детальному пониманию, как происходят реальные вычисления в памяти, пришлось отвыкать и работать в гораздо более абстрактных сущностях.
Зато остался интерес к базовым понятиям программирования, выходящим за пределы конкретных языков, операционных систем и устройств. Как любят говорить мои сотрудники «В конце концов, в компьютере биты бегают».
Tags:
no subject
no subject
no subject
no subject
no subject
no subject
Немножечко, чуть-чуть, команд 15-50 но пишут.
no subject
первымвторым начнёт, тот вырвется вперёд из болота, в которое превратилось программирование. В виде, возникшем около 1970 (С и Юникс, со всеми их регрессивными порождениями до сего дня), программирование как технология достигло предела. Я могу показать таблицу (десятилетней давности) что это значит в валютном выражении, но пока не буду захламлять тезис второстепенными цитатами.В 1970 году процессоры были большими и штучными, а память и программы маленькими, и много программ ждали своей очереди порулить процессором. Вот из этой парадигмы вышла сама концепция операционной системы, которая даёт порулить программам. Однако сегодня процессоры стали маленькими и массовыми, а память и программы большими, и не осталось никакого смысла делить процессоры, которых изобилие, между программами, которых меньше чем процессоров (с учётом ядер GPU в типичном ПК). Всё вывернулось наизнанку: процессоры выросли на порядки больше чем имело смысл их выращивать, во всех существующих степенях свободы. Напихали кучу ядер на кристалл, которые вынуждены конкурировать за общую память на общей шине. Напихали кучу мусорных "улучшений", вроде спекулятивного выполнения, которые только греют воздух, но не дают никакой реальной пользы. И самое извращённое: разогнали ядра до гигагерц, а память осталась медленной, в результате выросли кэши, которые и стали де факто ОЗУ, а ОЗУ стала де факто накопителем. Но всё это лишь железные эффекты извращений программистов. В гадюшнике программистов извращения далеко превзошли возможности человеческих языков для их описания. И вот тут я уже покажу цитату -- результаты работы этих поэтов, музыкантов и мыслителей, среди которых давно не осталось ни одного инженера (computer engineer, как в обитали в IBM два поколения назад). Это список программистских эпикфейлов и прямого валютного ущерба от них. Список старый, составлен 10 лет назад, поэтому не думайте что всё внезапно остановилось тогда.
Есть ещё данные из одной замечательной книжки по этой теме, от них можно только рыдать и рвать волосы на теле ближайшего программиста. Я обобщу их так:
Это статистика дефектов в коде в форме их количества на тыщу строк. Обратите внимание что в статистику вошли лишь "нормальные" программы на языках вроде С. Никаких перлов и подобных пунктуационных оргий. В среднем каждая восьмая строчка содержит дефект, а количество строчек со всеми апи и библиотеками может никто не знать вообще. Вот это полезно утратить вообще и навсегда, желательно физически вместе с носителями, потому что переобучению такие привычки не поддаются. А молодёжь со школы нужно учить только хорошему: ширнармассы Спарку, а будущих инженеров -- ещё и ассемблеру. И только самых идейно-стойких и проверенных инженеров можно допускать к С, потому что на этой фене понаписано очень много очень специфических вещей, которые останутся в железе на поколение (DSP, MCU). И вот главное, что пытались сделать амы, но поторопились и сдались: законодательно заставить писать новое только на хорошем -- программы на Аде, а схемы на VHDL. Это была героическая, гениальная и наивная мысль. Всё остальное должно быть выдавлено из коммерческого и государственного применения всевозможными стандартами качества, ограничениями на применение (как с курением), валютной мотивацией и демотивацией, и прочими грязными но эффективными методами.
no subject
no subject
no subject
no subject
Хаха, главное что сотрудники - молодцы, молча получали зарплату три года ;) Где раздают такие склады?
no subject
В штатах конечно.
no subject
no subject
чем в холодильнике.no subject
no subject
no subject
no subject
Году в 1996м, одного моего знакомого попросили переписать кое-что на макинтош.
Продравшись через список функций API, он долго ходил с удивленным видом и рассказывал, что "в этой странной системе есть не меньше шести способов вывести на экран окно с текстом".
no subject
no subject
Богатейшая, но увы, проблематичная к подробному изучению тема "советские военные бортвычислители во всем их разнообразии".
Несмотря на деятельность аргоновцев (А-15 ставили самые разные КБ довольно много куда) во многих наших прославленных КБ и НПО вырастали собственные отделы конструирования ВТ, творившие кто в лес, кто и по дрова.
Вот где не хватало хоть минимальной стандартизации и упорядочения.
Правда, надо заметить, что у верпротивника стандартизированная архитектура была только в ВВС. Армия и флот оставили за собой полную свободу действий.
no subject
no subject
Я вижу довольно любопытную картину, однако, вполне предсказуемую.
Моно ли из предсказуемости извлекать какую-то пользу, на сейчас это меня, правда, больше интересует.. )
no subject
no subject
Михаил Владимирович Донской (8 августа 1948 — 13 января 2009).
Сама статья опубликована 20 августа 2008.
no subject
Программирование из высокой науки превратилось в ремесло - да, это нормальный и естественный процесс.
Машинные коды (или даже ассемблер) - вершина мысли? Ну уж нет, увольте... Это все равно, что требовать построить дачный дом при помощи только одного топора. Тем более, что Михаил Владимирович сам далее пишет, что они, еще в *те* годы начинали разработку с создания собственных операционных систем и инструментальных средств. Т.е., будучи профессионалами, свое время они ценили и хотели его использовать максимально продуктивно. А отсюда уже один шаг до создания переносимых программ, т.е., программ, написанных на ЯВУ (языке высокого уровня), в которых на ассемблере пишутся только небольшие куски кода.
"специализированного (для проекта) языка программирования, включавшего специфичные структуры и классы данных и базовые процедуры" - вообще-то это библиотеки. Просто реально крупные проекты (миллионы строк кода) почти всегда начинаются, как мелкие (или даже побочные), и где-то с версии 1.0 встает проблема рефакторинга - переписывания внутреннего программного интерфейса (API) так, чтобы он удовлетворял изменившимся требованиям. И вот в этом случае реально нужен хороший системный архитектор, который сможет разделить сущности с учетом перспективы развития. Потому что любая ошибка на этом этапе - это склад костылей в ближайшие годы.
"разбить процесс создания большой системы на проекты, выбрать для них инструментарий, подобрать исполнителей, суметь их проконтролировать и, в конечном счете, обеспечить работоспособность созданной системы" - у нас это называется главный конструктор. :) Инструментарий он, правда, не выбирает, но за совместимостью следит.
"усилиями крупных фирм по созданию программного обеспечения, в первую очередь, усилиями Майкрософта, этот процесс стандартизовался" - я лучше промолчу.
"Однажды я работал с «юниксоидом», делавшим серверную систему для салона игровых автоматов. На все мои требования сделать возможной выдачу статистики игр, он отвечал, что это уменьшает безопасность системы" - совершенно резонно, кстати. Вероятно, парень имел в бекграунде курс по безопасности информации. А там на первой же лекции объясняют (должны объяснять), что человеческий фактор программно не может быть исключен.
"В моей молодости обучение программированию в институтах было вообще смешным – изучались только синтаксисы разных языков" - ничего не изменилось.
"Они не понимают, что если заказчик меняет требования к уже почти готовой системе, это означает, что система ему нравится" - это означает, что системный архитектор (или project manager) недоработал. Мелочевку типа размера кнопок или еще одной формы для печати в расчет не берем. Если заказчик хочет получить еще одну сущность, реализуемую внутри принятой парадигмы и возникшую уже после подписания ТЗ - то все нормально. Ну, относительно нормально. А вот если вопрос стоит так, что надо изменять "специализированный язык"... А если серьезно изменять?
"изначально в нее (программу) должна быть заложена эластичность, без которой вносить изменения в программу будет крайне сложно" - я это называю масштабируемость. Масштабируемость - это не просто возможность выполнять на трех АРМ программу, написанную для двух АРМ. Это еще возможность добавлять в протокол взаимодействия разных программ новые возможности, которые не потребуют принципиальной переработки всех программ.
Ну и насчет ОС. Количество людей, которые в принципе могут создать новую ОС, на Земле не изменилось. Просто раньше считалось, что программист - это тот, который написал свою ОС или свой язык программирования, а еще лучше - ОС, для которой придумал и реализовал ЯП. Сейчас программист - это человек, который может набрать в редакторе "echo \"hello, world!\"".