Здравствуйте, netch80, Вы писали:

N>Адекватный — это 320x200 с 4 цветами и неизбежно вырвиглазными шрифтами (в лучшем случае уложенными в матрицу 7*5)?

Адекватный — это соответствующий поставленной задаче. Не нужно оценивать всю индустрию по игрушке IBM PC.

N>размер экрана меньше 1600 пикселов по ширине сейчас уже в рамках неприличия, потому что фиг что отобразишь, 4096 уже норма, 8K на подходе в массы.

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

N>А на ресурсах 1970-х сейчас никто не согласится даже базовые вещи реализовывать.

Да, только одни не согласятся потому, что это сложно и трудоемко, а другие — потому, что не понимают, как такое вообще возможно.

N>догонка мощностей GUI до уровня примерно 1024*768*truecolor это целесообразно.

1024x768 — целесообразно, а TrueColor — на фиг не нужно. В подавляющем большинстве GUI используются стандартные палитры, там 16 цветов хватит за глаза, для особых эстетов — 256.

N>нормально такая многозадачность вместе с другими фичами типа автодетекта железа, построения дерева драйверов, фоновыми задачами по обслуживанию системы и т.п. — начинала хоть как-то работать на 2MB оперативки

На каком основании Вы неразрывно связываете многозадачность со всем перечисленным? Сама по себе многозадачность может быть реализована очень экономно — есть множество различных реализаций, даже для простых микроконтроллеров с десятками килобайт памяти.

N>То-то сейчас на колоссальных ресурсах делают мелкие поделки.

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

ЕМ>>Такие вещи очень давно делались на банальной интуиции.

N>Ну да, для себя и двух коллег в предельно специфичном варианте.

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

N>Я не помню такого на 360/370.

Оно и на ЕС работало, по понятным причинам.

N>А то, что вы "с парнями чисто по приколу" делали, оно было как, умело хотя бы подсказать, каким нескольким командам соответствует данный префикс?

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

ЕМ>>>>В 70-е было полноценное интерактивное редактирование в реальном времени.
N>И как оно выглядело?

Вы видели типичный визуальный текстовый редактор под DOS, работающий в текстовом режиме, типа MultiEdit/Lexicon? Вот так и выглядело, с поправкой на разрешение терминала, монохромность и способы управления отображением текста.

ЕМ>>Сохранить файл в фоне, запустить компилятор параллельным процессом, получить от него таблицы идентификаторов, зависимости и прочее

N>Ну вот, видимо, только от уровня где-то 4MB стало хватать. До этого — нет.

Да откуда Вы это взяли? Для компиляции программы в десяток килобайт исходника (вполне себе серьезная программа по тем временам, многие утилиты ОС такими были) хватало нескольких десятков килобайт памяти, какие мега байты?

N>В 70-е даже 32K в калькуляторе было неподъёмно.

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

ЕМ>>И что из этого объективно невозможно без гигабайт и гигафлопсов?

N>Даже просто проанализировать движения глаз.

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

Здравствуйте, netch80, Вы писали:

N>БЭСМ-6 — тупая кривуля.

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

N>Одно отсутствие целочисленной арифметики чего стоит

А чего оно стоит? Кому конкретно оно мешало настолько, что они "даже кушать не могли"?

16-битное "окно в мир" там, где давно пора сделать было шире адрес.

Даже не 16-ти, а 15-ти. Но для большинства задач этого хватало (надеюсь, про явление локальности Вы в курсе?). Так же, как и сегментной организации памяти в 286 тоже хватало для большинства задач, но это было банально неудобно. Понимаете разницу между неудобством и невозможностью?

N>(Да, точно так же было на PDP-11, но PDP-11 заявлялась как мини- и микро-ЭВМ, а не полноценная!) Ну и вообще 100500 глупостей в системе команд, и вокруг...

Где именно было "100500 глупостей"? Отдельные глупости есть везде, уж в PC их считать устанешь. А те системы команд вообще никогда не испытывали многократных переделок.

N>Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё.

По удобству — однозначно выигрывала, а по объему — лишь в том случае, когда на 360 имелась подходящая библиотека, встроенная в ОС. Самой большой слабостью БЭСМ-6 было то, что на ней не было единой программной системы. Где-то писали все свое, где-то стыковали разнородные программы через промежуточные носители, где-то делали универсальные системы вроде "Дубны". Но это были проблемы не самой техники, а организации разработки в СССР, где работы распылялись по организациям, и плохо управлялись.

N>Да сейчас её какой-нибудь 8051 победит как лежачую.

Это вообще к чему?

N>Ностальгировать по этому смысла просто ноль целых фиг десятых.

Мне совершенно не свойственна ностальгия по технике тех времен — разве что по самим временам. Мне досадно, когда люди теряют адекватное представление о ресурсах, реально потребных для решения той или иной задачи. Здесь очень уместно вспомнить классическую притчу Дейкстры о том, кто был "первым компетентным программистом".

N>"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен.

А термин "безнадежен" — конкретизируемый? Алгол-68 "круче" C++ прежде всего в плане сложности его реализации, а отнюдь не удобства программирования или модности.

Здравствуйте, netch80, Вы писали:

M>>Я тут LLVM собирал — сорцы гиг где-то занимают (3 гига, если считать с гитовой репой), пол дня компилятся, на выходе 120Гб только для одной конфигурации — платформа/дебаг|релиз. Просто не вижу, чего тут можно сравнивать

N>Вот это мне крайне подозрительно, потому что например во FreeBSD собирается по умолчанию clang, и там объём полного дерева компиляции всего мира в разы меньше, чем у тебя один LLVM. Скорее оно тебе таки на промежуточных билдах, а может и на окончательных, собирало все таргеты, какие вообще знает.

Ну то есть да, LLVM мне сам по себе не нужен, мне нужен clang и clang-tools (-DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra), оно там в итоге много чего собирает

Здравствуйте, xma, Вы писали:

xma>офигеть, в СССР даже жёсткие диски выпускали — "самые большие в мире" (c)

Самые большие в мире выпускал IBM.



А первый в мире жесткий диск в современном понимании был сделан в 1980-м и выглядел вот так:



Его аналог и сделал СССР через 5 лет.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Помнится, в 70-е бОльшую часть электроники делали на "рассыпухе", микросхем тогда было мало, в основном цифровая логика...

ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.

Ну, ПО тоже шагнуло довольно далеко. А главное шагнули процессы разработки. Если тогда ПО писалось одиночками или командами до 7 человек, то теперь над некоторым коробочным ПО работают тысячи человек одновременно. Я вообще не понимаю как у нас продукт собирается.

За это время в ПО вошли:
1. ООП.
2. ФП.
3. DSL.
4. Системы контроля (управления) версий (прошли 3 эволюции и стали распределенными).
5. Сборочные конвеер.
6. Виртуальные машины для тестирования и даже их фермы. У нас в компании тесты гоняются на тысячах виртуалок которые доступны всем в конторе.
7. Системы отслеживания ошибок (вроде TFS)
8. Системы планирования.

Появились мощные IDE поддерживающие интелиснс, рефакторинги, отладку (локальную, удаленную и даже дмпом).

Одних только языков программирования появилось несколько тысяч.

Далее виртуальные машины. Кроскомпиляторы.

Думаю электронщикам столько и не снилось. Да сами электронщики используют автомазированные системы проектирования. И не только они. Сейчас уже никакое производство без них не обходится.

Здравствуйте, VladD2, Вы писали:

VD>Ну, ПО тоже шагнуло довольно далеко.

Блин, да не в том дело, насколько шагнуло. А в том, что развитие микросхем сопровождалось улучшением всех без исключения потребительских характеристик. А развитие ПО, помимо улучшения одних характеристик, сопровождалось ухудшением (и значительным) других. И если сейчас вдруг потребуется получить гораздо бОльшую производительность ПО на имеющихся мощностях, или сохранить имеющуюся на меньших, то подавляющее большинство разработчиков этого банально не сможет, и будет искренне утверждать, будто невозможно совершить чудо. А на тех, кто сможет, будут действительно смотреть, как на шаманов.

VD>Если тогда ПО писалось одиночками или командами до 7 человек

Это когда? С самого начала разработки ПО в середине прошлого века оно писалось тем количеством людей, которое или объективно требовалось, или имелось в наличии. Никаких ограничений не было никогда.

VD>теперь над некоторым коробочным ПО работают тысячи человек одновременно. Я вообще не понимаю как у нас продукт собирается.

Примерно так и работали советские НИИ. Несколько институтов, десятки-сотни отделов, сотни-тысячи человек, и почти никто не представлял себе продукта во всей совокупности. Для секретных разработок это было хорошо, а вот для всего остального... Потом, разумеется, каждый отдел спихивал ответственность за косяки на смежников.

VD>Да сами электронщики используют автомазированные системы проектирования.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>Ну так я сравниваю сопоставимые системы, что у меня было на столе тогда и что сейчас.
а почему нет?

ЕМ>То есть, свой стол Вы полагаете наиболее репрезентативным источником?

ЕА>>Давайте сравним с другой. Какие параметры дисплеев там были?

ЕМ>Тогда дисплеи были в основном текстовые (чисто графические были дороже, и гораздо менее востребованы). Например, VT52 — 80x24 символа, матрица символа — 7x7 (заглавные, прописные, спецсимволы, псевдографика). На нем делали полноценный GUI с меню, прокруткой списков и прочим, разве что управление было клавишным, как в ранних безмышовых редакторах под DOS. То есть, разница была чисто количественной, отнюдь не качественной.

Гм, переход к графической системе с многооконностью и многозадачностью и разрешениям экрана, от которых не болят глаза вы называете количественным?

Здравствуйте, Евгений Музыченко, Вы писали:

N>>БЭСМ-6 — тупая кривуля.

ЕМ>Я правильно понимаю, что Вы не имели с нею дела, по крайней мере — в те времена, и оцениваете сугубо в сравнении с более новой техникой?

Ну почему с более новой? CDC1604, с которой любят сравнивать. Те из линии PDP, которые были на 1965 (декларированный в википедии год старта разработки БЭСМ-6).
Даже S/360, у которой модели 20 и 30 вполне в том же классе, что БЭСМ-6.

N>>Одно отсутствие целочисленной арифметики чего стоит
ЕМ>А чего оно стоит? Кому конкретно оно мешало настолько, что они "даже кушать не могли"?

Оно мешало тем, что толщина кода на всё, что не было непосредственно вычислениями с плавающей точкой, на ней становилось дороже в несколько раз. А так как даже просто подсчитать индексы в матрице это целочисленные вычисления, то подобная диверсия била по всему.
В IBM это поняли давно и сделали хотя бы систему команд универсальной с возможностью адаптации под конкретный стиль, но по крайней мере это отражалось в плюс-минус пяток раз по скорости. А у Лебедева что-то тяжело заклинило.

ЕМ>16-битное "окно в мир" там, где давно пора сделать было шире адрес.

ЕМ>Даже не 16-ти, а 15-ти. Но для большинства задач этого хватало (надеюсь, про явление локальности Вы в курсе?).

Если "локальность" это "у нас машина для численных расчётов, а всё остальное пофиг", то да, в курсе. Если что-то другое — уточните, какую именно из 100501 локальностей вы тут имеете в виду.
Ну а "большинство" задач в которых нельзя считать что-то размером больше чем 100x100 без жутких извратов... может, для 50-х это нормально, но уже в 70-х (а машина которую начали разрабатывать в 1965 целится таки на 70-е) это несерьёзно.

EM> Так же, как и сегментной организации памяти в 286 тоже хватало для большинства задач, но это было банально неудобно. Понимаете разницу между неудобством и невозможностью?

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

N>>(Да, точно так же было на PDP-11, но PDP-11 заявлялась как мини- и микро-ЭВМ, а не полноценная!) Ну и вообще 100500 глупостей в системе команд, и вокруг...

ЕМ>Где именно было "100500 глупостей"? Отдельные глупости есть везде, уж в PC их считать устанешь. А те системы команд вообще никогда не испытывали многократных переделок.

А БЭСМ-6 что, испытывала? И тянула совместимость с МЭСМ? Под неё надо было всё переписать.

N>>Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё.

ЕМ>По удобству — однозначно выигрывала, а по объему — лишь в том случае, когда на 360 имелась подходящая библиотека, встроенная в ОС. Самой большой слабостью БЭСМ-6 было то, что на ней не было единой программной системы. Где-то писали все свое, где-то стыковали разнородные программы через промежуточные носители, где-то делали универсальные системы вроде "Дубны". Но это были проблемы не самой техники, а организации разработки в СССР, где работы распылялись по организациям, и плохо управлялись.

Нет, как раз описывают не связанное с библиотеками — а именно код типа "перемножить матрицу на вектор".
Единственность аккумулятора — вообще самая первая глупость дизайна, которая приводит к тому, что операции загрузить в аккумулятор и выгрузить из него занимают больше всего остального. Для чего-то мелкого типа 8080 это нормально. Для полноценного компа уже некультурно.

N>>Да сейчас её какой-нибудь 8051 победит как лежачую.
ЕМ>Это вообще к чему?

К логичности и сбалансированности системы команд.
Ладно, 8051 плохой пример, это не те масштабы... но вот в линии PDP (не обязательно PDP-11!) есть куда более интересные примеры. И даже CDC1604 (и похожие), с которой любят сравнивать БЭСМ-6...

N>>Ностальгировать по этому смысла просто ноль целых фиг десятых.

ЕМ>Мне совершенно не свойственна ностальгия по технике тех времен — разве что по самим временам. Мне досадно, когда люди теряют адекватное представление о ресурсах, реально потребных для решения той или иной задачи. Здесь очень уместно вспомнить классическую притчу Дейкстры о том, кто был "первым компетентным программистом".

Притча хорошая, но она не про ресурсы.
Если кому-то хочется посмотреть на использование ресурсов — сейчас под те же 8051 продолжают писать реальные шедевры. Или есть конкурсы по минимизации объёма, доходящие до "Pacman в 90 байт". Но при чём тут ужасы древнего дизайна?

N>>"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен.
ЕМ>А термин "безнадежен" — конкретизируемый?

Да, его можно спроецировать на оценку планов использования, на развитие или деградацию.

EM> Алгол-68 "круче" C++ прежде всего в плане сложности его реализации, а отнюдь не удобства программирования или модности.

Ну вот потому он и почти забыт — что его сложность была неоправданной.

Здравствуйте, AntoxaM, Вы писали:

ЕА>>>Ну так я сравниваю сопоставимые системы, что у меня было на столе тогда и что сейчас.
AM>а почему нет?

Ну вот у кого-то в 70-е был москвич, а сейчас — тесла. Означает ли это, что мировой уровень автомобилестроения в 70-х определялся именно москвичом?

ЕМ>>То есть, свой стол Вы полагаете наиболее репрезентативным источником?

AM>переход к графической системе с многооконностью и многозадачностью и разрешениям экрана, от которых не болят глаза вы называете количественным?

Графические системы, многооконность и многозадачность были и тогда, они лишь не сочетались между собой в каждом утюге. Глаза у подавляющего большинства не болели. Где именно Вы видите качественный переход?

Это как если, опять же в сравнении с автопромом, объявить "качественным переходом" то, что нынче во многих автомобилях есть одновременно и кожаный салон, и навигатор, и электрические стеклоподъемники, а когда-то оно было лишь по отдельности.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Блин, да не в том дело, насколько шагнуло. А в том, что развитие микросхем сопровождалось улучшением всех без исключения потребительских характеристик. А развитие ПО, помимо улучшения одних характеристик, сопровождалось ухудшением (и значительным) других.

Так и ПО сопровождалось улучшением всех без исключения потребительских характеристик. Скажем MS SQL Server 6 в подметки не годится MS SQL Server 2019. Он стал быстрее, надежнее, научился использовать современные железки...

ЕМ>И если сейчас вдруг потребуется получить гораздо бОльшую производительность ПО на имеющихся мощностях, или сохранить имеющуюся на меньших, то подавляющее большинство разработчиков этого банально не сможет, и будет искренне утверждать, будто невозможно совершить чудо. А на тех, кто сможет, будут действительно смотреть, как на шаманов.

Ну, вот пример с MS SQL Server 2019 это твое утверждение опровергает. Так что обсуждать не чего, так как исходное утверждение ложно.

Вот только производительность не всегда бывает самой важной характеристикой ПО. Когда она нужна есть масса способов ее улучшить. Можно профилировать ПО. Можно более производительные алгоритмы реализовывать.

ЕМ>Это когда?

Цитирую твой текст:

Помнится, в 70-е бОльшую часть электроники делали

ЕМ>С самого начала разработки ПО в середине прошлого века оно писалось тем количеством людей, которое или объективно требовалось, или имелось в наличии. Никаких ограничений не было никогда.

Это вранье. В середине прошлого века ПО вообще не писалось. Тогда компьютеров еще не было. А вот в 70-е ПО писалось очень небольшими группами людей. Просто не было технологий позволяющих писать ПО даже сотнями программистов. ДОС был написан одиночкой. Над Эплами работали 2 человека. А это уже 80е. Я помню как ПО писалось в Госплане СССР. Его писали одиночки. Отлаживали чтением листингов. Загружали с перфокарт. Мрак! Никаких git-ов, TFS-ов и тому подобного еще не было. Железо было настолько медленным, что софт часто писали на ассемблерах и доводили до блеска.

ЕМ>Примерно так и работали советские НИИ.

Да ни хрена подобного. В те времена вообще сложного софта не было. У нас один ГУЁ сейчас сложнее всего софта, что был в Госплане СССР. Это факт.

ЕМ>Несколько институтов, десятки-сотни отделов, сотни-тысячи человек, и почти никто не представлял себе продукта во всей совокупности. Для секретных разработок это было хорошо, а вот для всего остального... Потом, разумеется, каждый отдел спихивал ответственность за косяки на смежников.

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

ЕМ>Только электронщикам это позволяет делать многофункциональные, скоростные, надежные, и одновременно компактные и экономичные устройства, а вот автоматизация программирования пока работает в основном на bloatware.

Мы уже выяснили, что твои заявления о ПО ложны. Мне кажется обсуждать тут не чего. Ты просто придумал себе миф и веришь в него. Меж тем софт, как и микросхемы, стал намного сложнее. Там где нужно он работает очень быстро. Но сот не отделим от железа. Ну, ежу понятно, что нельзя сделать софт для IBM PC который сможет быстро обрабатывать БД размером в несколько гигабайт. А на современном железе за просто. Весь объем памяти у PC-ки был жалкие 640 Кб да еще и с сегментным доступом. А сейчас все эти гигабайты можно тупо в память поднять. Да память с процессором быстрее в миллионы раз. Иногда быстрое железо позволяет писать менее эффектиный софт и при этом решать задачи. Ну, и фиг бы с ним. Как я уже сказал скорость не всегда самая важная характеристика.

Здравствуйте, Евгений Музыченко, Вы писали:

N>>Адекватный — это 320x200 с 4 цветами и неизбежно вырвиглазными шрифтами (в лучшем случае уложенными в матрицу 7*5)?

ЕМ>Адекватный — это соответствующий поставленной задаче. Не нужно оценивать всю индустрию по игрушке IBM PC.

Не надо домысливать за других. Я судил по Apple II Вполне достойный зверь на середину 70-х (а не на начало 80-х, как IBM PC). И IBM PC — не игрушка, как бы некоторым ни хотелось это утверждать.

N>>размер экрана меньше 1600 пикселов по ширине сейчас уже в рамках неприличия, потому что фиг что отобразишь, 4096 уже норма, 8K на подходе в массы.
ЕМ>Из того, что все это существует, никак не следует, что оно является необходимым для тех целей, для которых используется, и без этого достижение целей якобы невозможно. Почувствуйте разницу между возможностью и комфортом.

Почувствовал, да. По меркам военного коммунизма, конечно, работать можно и на ведре, когда всей еды чёрный хлеб с кипятком. Но если нужна нормальная эффективность работы, долговременной и без изматывающего напряга — то необходимы и нормальные средства, и я говорю как раз о минимуме этой нормы.

N>>А на ресурсах 1970-х сейчас никто не согласится даже базовые вещи реализовывать.
ЕМ>Да, только одни не согласятся потому, что это сложно и трудоемко, а другие — потому, что не понимают, как такое вообще возможно.

Потому что вложены огромные затраты человеческого времени, которые можно было бы пустить на что-то другое?

N>>догонка мощностей GUI до уровня примерно 1024*768*truecolor это целесообразно.

ЕМ>1024x768 — целесообразно, а TrueColor — на фиг не нужно. В подавляющем большинстве GUI используются стандартные палитры, там 16 цветов хватит за глаза, для особых эстетов — 256.

Я даже на "safe" 216 тут соглашусь, раз так вы согласны с необходимостью адекватных размеров
Главное, чтобы не 16 (и тем более не меньше).

N>>нормально такая многозадачность вместе с другими фичами типа автодетекта железа, построения дерева драйверов, фоновыми задачами по обслуживанию системы и т.п. — начинала хоть как-то работать на 2MB оперативки

ЕМ>На каком основании Вы неразрывно связываете многозадачность со всем перечисленным? Сама по себе многозадачность может быть реализована очень экономно — есть множество различных реализаций, даже для простых микроконтроллеров с десятками килобайт памяти.

Потому что эти фичи в мире средних компьютеров требовались примерно одновременно.

N>>Ну да, для себя и двух коллег в предельно специфичном варианте.
ЕМ>Так я и не говорю, что все это уже тогда было близко к идеалу. Именно так — было несовершенно, ограничено, но таки работало. А большинство искренне считает, что переход на PC произошел непосредственно с перфокарт.

Я так не считаю, и где вы нашли такое большинство — я не знаю. У многих не было доступа к СМ/ДВК/... но то, что заметная часть думает, ещё не значит, что большинство.

N>>Я не помню такого на 360/370.
ЕМ>Оно и на ЕС работало, по понятным причинам.

Нет, непонятно. На каких работало и где? Если "по приколу", то это не в счёт — нужно в чём-то распространённом хотя бы за пределами пары ВЦ (кто там жаловался про проблемы единства софта для БЭСМ-6)?

N>>А то, что вы "с парнями чисто по приколу" делали, оно было как, умело хотя бы подсказать, каким нескольким командам соответствует данный префикс?
ЕМ>Умело, оно перебирало команды при нажатиях управляющих клавиш. Я, честное слово, не понимаю, что Вас удивляет — это же голимый примитив, мы тогда почти всё писали на ассемблере, и отнюдь не считали, что реализуем что-то авангардное или сложное.

Хорошо, не вижу причины не верить — накулибинить можно что угодно даже на коленке. Мне тогда интересно другое — почему такое не было реализовано в каком-то широко распространённом средстве.
Я вижу, например, следующую причину: такая возможность требует большого потока данных в обе стороны. Система, которая больше затачивалась на "у нас 1000 терминалов на один процессор, и терминал передаёт только изменённые поля" (как в БТМД) — плохо сочеталась с такой интерактивной подсказкой.

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

Для сравнения — LISP придуман в 1958-м, но его железо не тянуло. Первые реальные эксперименты — конец 60-х. Первые более-менее промышленные использования — 70-е. Заметно массово — 80-е.

И так фактически со всеми открытиями в IT... делались на бумаге и только через много лет получали реализацию.

ЕМ>>>>>В 70-е было полноценное интерактивное редактирование в реальном времени.
N>>И как оно выглядело?
ЕМ>Вы видели типичный визуальный текстовый редактор под DOS, работающий в текстовом режиме, типа MultiEdit/Lexicon? Вот так и выглядело, с поправкой на разрешение терминала, монохромность и способы управления отображением текста.

Такое редактирование вообще-то появилось в 60-е, с первыми дисплеями. Это вы уже недооцениваете прогресс. Но: никто его не делал через передачу каждого символа и обратно. У дисплея было поле ввода, в котором и возились. Я в 80-е даже работал в таких "IDE" для ЕС 10xx. По нажатию Enter шёл сигнал к процессору, и тот мог отдать команду "передать изменённое" или "передать всё".
Соответственно, например, не было прокрутки в современном виде (любое листание это передача полного буфера туда-обратно).

И даже в убойно дорогих дисплеях были смешнейшие проблемы вида:

> One effect of the 2848 delay line was that if a heavy person walked next to the controller, or if it was mounted next to a vibration source (like an elevator), digital bits of screen images would be lost on all of the video displays, which would then be repeated continuously through the feedback loop until a new video display was transmitted to all of the connected terminals.

Сейчас не поймут

ЕМ>>>Сохранить файл в фоне, запустить компилятор параллельным процессом, получить от него таблицы идентификаторов, зависимости и прочее
N>>Ну вот, видимо, только от уровня где-то 4MB стало хватать. До этого — нет.
ЕМ>Да откуда Вы это взяли? Для компиляции программы в десяток килобайт исходника (вполне себе серьезная программа по тем временам, многие утилиты ОС такими были) хватало нескольких десятков килобайт памяти, какие мега байты?

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

N>>В 70-е даже 32K в калькуляторе было неподъёмно.
ЕМ>И зачем Вы уперлись именно в калькулятор?

Ну вы ж Д3-28 вспомнили. Я тут говорю в контексте этого воспоминания.

EM> Я привел пример создания достаточно сложной даже по современным меркам программы в голом машинном коде весьма примитивной машины, силами одного человека, за небольшой срок. В 70-е же хватало гораздо более мощной техники.

Да, хватало. И применяли её под заметно другие цели, а иначе нифига не окупалось.

ЕМ>>>И что из этого объективно невозможно без гигабайт и гигафлопсов?
N>>Даже просто проанализировать движения глаз.
ЕМ>В мозгу это успешно делают десятки-сотни тысяч нейронов, имеющих быстродействие на несколько порядков ниже.

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

Здравствуйте, netch80, Вы писали:

N>>>Одно отсутствие целочисленной арифметики чего стоит
ЕМ>>А чего оно стоит? Кому конкретно оно мешало настолько, что они "даже кушать не могли"?

N>Оно мешало тем, что толщина кода на всё, что не было непосредственно вычислениями с плавающей точкой, на ней становилось дороже в несколько раз.

Какая еще "толщина кода"? За счет чего "дороже в несколько раз"? Можете объяснить подробнее? Только имейте в виду, что Вы про эту систему команд лишь где-то отрывочно читали, а я непосредственно в ней программировал несколько лет.

N>А так как даже просто подсчитать индексы в матрице это целочисленные вычисления, то подобная диверсия била по всему.

У тех, кто "где-то что-то слышал", возможно, и била. У тех, кто работал с машиной, арифметические команды над целыми числами, не требующие выравнивания порядков и нормализации, выполнялись за то же время, что и логические — примерно 0.5 мкс.

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

Я знал немало людей, одновременно работавших на уровне системы команд как с IBM/ЕС, так и с БЭСМ-6. Ни разу не слышал сколько-нибудь систематических жалоб на любую из них. Обе были достаточно комфортны в постоянной работе, и лишь при первом знакомстве каждая казалась неудобной. А Вы где черпаете сведения?

ЕМ>>Даже не 16-ти, а 15-ти. Но для большинства задач этого хватало (надеюсь, про явление локальности Вы в курсе?).

N>Если "локальность" это "у нас машина для численных расчётов, а всё остальное пофиг", то да, в курсе. Если что-то другое — уточните, какую именно из 100501 локальностей вы тут имеете в виду.

Я имею в виду принцип локальности, он один, и работает везде, в том числе и в численных расчетах. Про остальные 100500 я не в курсе, Вас не затруднит бегло перечислить хотя бы десяток?

N>Ну а "большинство" задач в которых нельзя считать что-то размером больше чем 100x100 без жутких извратов...

Да Вы, похоже, толком и не представляете, как это работает. Вам вообще приходилось делать на ассемблере/автокоде не короткие вставки для ЯВУ, а достаточно сложные законченные программы?

N>В сегментной организации можно хотя бы без регулярного напряга ОС обратиться к другому сегменту, просто загрузил номер и пошёл. А тут что — просить ОС каждый раз хлопать страницами?

Какая разница, кого просить — процессор или ОС? В 286 переключение сегментов тоже занимало далеко не один такт. Переключение страниц через ОС, конечно, работало медленнее, но и там, и там грамотное программирование заключалось в том, чтобы не делать этого без нужды.

N>>>Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё.

N>как раз описывают не связанное с библиотеками — а именно код типа "перемножить матрицу на вектор".

Можно примеров, где это прям "в несколько раз"?

N>Единственность аккумулятора — вообще самая первая глупость дизайна, которая приводит к тому, что операции загрузить в аккумулятор и выгрузить из него занимают больше всего остального.

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

N>в линии PDP (не обязательно PDP-11!) есть куда более интересные примеры. И даже CDC1604 (и похожие), с которой любят сравнивать БЭСМ-6...

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

N>>>Ностальгировать по этому смысла просто ноль целых фиг десятых.

ЕМ>>Мне совершенно не свойственна ностальгия по технике тех времен — разве что по самим временам. Мне досадно, когда люди теряют адекватное представление о ресурсах, реально потребных для решения той или иной задачи. Здесь очень уместно вспомнить классическую притчу Дейкстры о том, кто был "первым компетентным программистом".

N>cейчас под те же 8051 продолжают писать реальные шедевры. Или есть конкурсы по минимизации объёма, доходящие до "Pacman в 90 байт".

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

N>>>"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен.
ЕМ>>А термин "безнадежен" — конкретизируемый?

EM>> Алгол-68 "круче" C++ прежде всего в плане сложности

N>потому он и почти забыт — что его сложность была неоправданной.

Это отдельный вопрос. Вы скажите, каким образом эту сложность сумели реализовать (и не раз) те "древние люди", что работали с "ужасами дизайна", не используя ни ООП, и ФП, ни прочих страшных слов?

Здравствуйте, VladD2, Вы писали:

ЕМ>>Блин, да не в том дело, насколько шагнуло. А в том, что развитие микросхем сопровождалось улучшением всех без исключения потребительских характеристик. А развитие ПО, помимо улучшения одних характеристик, сопровождалось ухудшением (и значительным) других.

VD>Так и ПО сопровождалось улучшением всех без исключения потребительских характеристик. Скажем MS SQL Server 6 в подметки не годится MS SQL Server 2019. Он стал быстрее, надежнее, научился использовать современные железки...

"Научился использовать современные железки" вообще не относится к этому сравнению.
"Быстрее" — точно быстрее, если сравнить на _одинаковом_ железе? Или просто всё вокруг стало быстрее, от процессоров до SSD?

ЕМ>>С самого начала разработки ПО в середине прошлого века оно писалось тем количеством людей, которое или объективно требовалось, или имелось в наличии. Никаких ограничений не было никогда.

VD>Это вранье. В середине прошлого века ПО вообще не писалось. Тогда компьютеров еще не было.

Давай ты всё-таки будешь ближе к фактам, потому что "враньё" тут однозначно в твоих утверждениях. (Отредактировал со смягчением формулировок.)

Компьютеры появились в 1940-х в виде, близком к современному. Первый компьютер на архитектуре "хранимой программы", обычно называемой фоннеймановской — EDSAC — сделан в 1949 — до середины века.
OS/360, тот проект, по мотивам которого написан знаменитый "Мифический человеко-месяц", стартовал в 1964 и закончен в основе в 1966 (хм, таки быстро). Читаем оттуда же у Брукса:

Мое профессиональное становление в вычислительной технике первоначально было связано с программированием, однако в период 1956–1963 годов, когда разрабатывались автономные управляющие программы и языки высокого уровня, я занимался
в основном архитектурой компьютеров.

То есть на 1956 уже можно отнести вполне себе разработку ПО.
Ну или для тебя 1956, 1966 уже не середина прошлого века — ну тогда начни писать на русском языке ;\ а то на каком это не середина века, мне непонятно.

VD> А вот в 70-е ПО писалось очень небольшими группами людей. Просто не было технологий позволяющих писать ПО даже сотнями программистов.

То есть ты Брукса вообще не читал. Я как-то раньше полагал, что без этой книги (хотя бы раз прочитать) качественный программист не может существовать.
Спойлер: над OS/360 работало больше тысячи человек — явно указано в книге. А то и больше:

С 1963 по 1966 год на ее проектирование, реализацию и написание документации было затрачено, вероятно, около 5000 человеколет.

5000/3 ~= 1667, а учесть неравномерность — в пике до 2000, наверно.

И технология такая была и есть — называется "человеческий разум" со вспомогательными технологиями типа "декомпозиция", "спецификация интерфейсов", "прототипирование" и ещё много других, известных сейчас. Может, для кого-то это и новость

Тут интересно то, что Брукс говорит про "грубую силу" — эффективность такого комбината, наверно, была на порядок-два ниже современных. Но основы были заложены именно тогда — анализ разработки данного проекта заложил всю программную индустрию на десятилетия (IBM не стала скрывать эти детали, к счастью).

VD> ДОС был написан одиночкой. Над Эплами работали 2 человека. А это уже 80е. Я помню как ПО писалось в Госплане СССР. Его писали одиночки. Отлаживали чтением листингов. Загружали с перфокарт. Мрак! Никаких git-ов, TFS-ов и тому подобного еще не было. Железо было настолько медленным, что софт часто писали на ассемблерах и доводили до блеска.

ЕМ>>Примерно так и работали советские НИИ.

VD>Да ни хрена подобного. В те времена вообще сложного софта не было. У нас один ГУЁ сейчас сложнее всего софта, что был в Госплане СССР. Это факт.

Это факт одного отдельно взятого Госплана, который тут скорее антипример.

Я видел работу (сам не работал — ещё был совсем мал) работу киевского НИИ цен (подчинён Госплану? Госснабу? уже неважно) и чуть меньше — НИИ нефтехимии в 1984-1986. Перфокарты — только для особых режимов. Диски для основного софта и данных. Ленты для переноса данных между участниками процесса (а иногда и диски — но тут хуже с совместимостью).

И у нас было две "IDE" для редактирования любых текстов на дисплеях (дисплеи были — 4 штуки 7066 на ЕС1022 в Ценах и 8(?) штук 7920 на ЕС1033 в Нефтехиме) и запуска системных команд — примерно как сейчас из vim можно запускать команды — питерская JEC и киевская Вектор. Вокруг была больше знаменита московская Primus, но у нас в тех двух точках её почему-то не было.

И это провинциальное ведомство. А уж центральный Госплан... В таком богатом ведомстве "загружать с перфокарт"... Ну или ты работал в каком-то дохлом НИИ подчинённом пятому помощнику заместителя третьего дворника — это вероятнее всего — и ваша работа реально никому не была нужна.

ЕМ>>Несколько институтов, десятки-сотни отделов, сотни-тысячи человек, и почти никто не представлял себе продукта во всей совокупности. Для секретных разработок это было хорошо, а вот для всего остального... Потом, разумеется, каждый отдел спихивал ответственность за косяки на смежников.

VD>Да институтов то было дохера. Но даже компьютеров то в них было раз два и обчелся. Доступ к ним был по времени. Каждый писал свою мелкую программульку. Система учета зарплат уже была чем-то большим.

Что общение софтом было слабым — факт — всё держалось на личных связях. Но всё остальное что ты пишешь — какой-то лютый гон с обобщением личного опыта на весь космос, который не подтверждается как минимум моими данными и наверняка ещё нескольких современников (вон интересно, что Privalov вспомнит).

ЕМ>>Только электронщикам это позволяет делать многофункциональные, скоростные, надежные, и одновременно компактные и экономичные устройства, а вот автоматизация программирования пока работает в основном на bloatware.

VD>Мы уже выяснили, что твои заявления о ПО ложны.

Они спорны, и я их обсуждаю с EM, но твой метод участия тут точно не сработает.

Здравствуйте, netch80, Вы писали:

N>"Научился использовать современные железки" вообще не относится к этому сравнению.
N>"Быстрее" — точно быстрее, если сравнить на _одинаковом_ железе? Или просто всё вокруг стало быстрее, от процессоров до SSD?

Точно быстрее. Иначе все бы ставили MS SQL 6 на новое железо. Но сама по себе постановка вопроса не корректна. Для того чтобы задействовать возможности нового железа уже нужны новые версии софта. Например, MS SQL 6 просто не умел использовать память за пределами первых 2 Гб.

N>Компьютеры появились в 1940-х в виде, близком к современному. Первый компьютер на архитектуре "хранимой программы", обычно называемой фоннеймановской — EDSAC — сделан в 1949 — до середины века.

Первый компьютер и "писались программы" — это две большие разницы. Смягчать тут просто не чего. Первые компьютеры вообще программировались в машкодах и только своими авторами.

N>OS/360, тот проект, по мотивам которого написан знаменитый "Мифический человеко-месяц", стартовал в 1964 и закончен в основе в 1966 (хм, таки быстро).

Тебе придется признать, что 1966-й — это совсем не середина прошлого века. Это уже почти 70-й год о котором мы и говорил. И 70-м начался реальный прогресс в области разработки ПО. Шел довольно долго и только в 2010-х пришел к тому, что можно называть современным уровнем.

70-е года — это были года развития языков программирования и компиляторов. Писать софт большими командами тогда было невозможно просто из-за отсутствия необходимого дял этого ПО. Ну, или производительность у подобных команд была ниже плинтуса.

N>Читаем оттуда же у Брукса:

N>Мое профессиональное становление в вычислительной технике первоначально было связано с программированием, однако в период 1956–1963 годов, когда разрабатывались автономные управляющие программы и языки высокого уровня, я занимался

Я для тебя специально жирным выделил. И 1956-й — это уже тоже не совсем середина века.

N>То есть на 1956 уже можно отнести вполне себе разработку ПО.

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

И того компьтеры появлись где-то во второй половине 20го века. До 70-х годов шло их становление и разработка языков высокого уровня. Первая пародия на систему контроля версий была создана в 1972. Но это была локальная система для IBM-мовских мэйнфрэймов. Публично ее зарелизили только в 1977 г. Реальное их развитие началось где-то в 80-е. В это же время были придуманы ООЯ и т.п. Причем вещи вроде сборочных конвейеров были придуманы еще позже, так как на мэйнфрэймах они вообще не имели смысла. Эволюция тех же систем контроля версий проходила банально на моих глазах. Еще в середине 90-х это было сташное говно плохо работающее по стеи. О каких тысячах разработчиков можно говорить в таком случае? Сотня то уже упиралась в их качество, а нормально их использовать можно было только на коллективах из десятков человек. CVS — 1990. Subversion — 2004. GIT — 2005. Причем до народа тот же гит доехал куда позже. И даже сейчас, на объемах реального коммерческого продукта GIT дико тормозит. MS сделал даже специальную версию гита с виртуальной файловой системой, чтобы можно было использовать подход Монорепы.

N>Ну или для тебя 1956, 1966 уже не середина прошлого века — ну тогда начни писать на русском языке ;\ а то на каком это не середина века, мне непонятно.

Конечно! Середина это 1950 год в который в реальности просто не было компьютеров у людей. Их только только налаживали к выпуску. Ни о какой разработке больших систем и речи в те времена идти не могло. А 1966 — это уже почти 1970, который ни при каких условиях к середине 20го века не отнесешь. А главное, что то, что что-то появлись в 1966м не значит, что это что-то попало в общественное пользование.

N>Спойлер: над OS/360 работало больше тысячи человек — явно указано в книге. А то и больше:
N>

N>С 1963 по 1966 год на ее проектирование, реализацию и написание документации было затрачено, вероятно, около 5000 человеколет.

IBM — это были пионеры, которые до этого еще на механических машинах умудрялись не хилые объемы данных обрабатывать. Не надо выдавать единичный случай за общую практику. Ну, и производительность труда у них была по нашим меркам (нашим временам) никакая. И было это так именно из-за отсутствия необходимого софта. Они в общем-то и родили предков этого самого софта. Первая система контроля версий как раз и была на коленке для OS/360 сделаны в 1972 году. А до этого они без них обходились. Причем это была внутренняя тула IBM, т.е. для всего мира она не существовала. А зарелизили они ее в 1977м году, т.е. практически в 80-х когда и пошло эволюционное развитие систем управления разработки софтом и не закончилось и по сей день.

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

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

Читая разных Бруксов ты даже представить не можешь как они там в реальности работали.

N>5000/3 ~= 1667, а учесть неравномерность — в пике до 2000, наверно.

А что это за "3"?

Ну, так нулевая эффективность. О чем я тебе и говорю. Пробовать то такими коллективами что-то тварить можно было. Но результат плачевный. По современнм меркам это мелкая система.

В общем, околонулевая, да. Были б у них современные средства сделали бы тоже самое в десятки, а то и сотни раз быстрее и проще.

N>И технология такая была и есть — называется "человеческий разум" со вспомогательными технологиями типа "декомпозиция", "спецификация интерфейсов", "прототипирование" и ещё много других, известных сейчас. Может, для кого-то это и новость

Я главное выделил. Вот тогда только декомпозиция и знали, а банальной системы контроля версий не было. Народ экспериментировал в области ЯП. Только только от машкодов ушли. Люди уже понимали, что, например, кодом нужно управлять, но как — было не известно. SCCS — ту самую систему контроля версий — разработали только для System/370. System/360 писали без нее. Естественно испытывали боль. Два программиста уже один исходник поправить не могли. Интерактивности разработки не было. Ты должен был отдать свою программу операторам и те поставят ее в очередь. А результат на распечатке, на следующий день (а то и через неделю, если тебе время не выделили).


N>Тут интересно то, что Брукс говорит про "грубую силу" — эффективность такого комбината, наверно, была на порядок-два ниже современных. Но основы были заложены именно тогда — анализ разработки данного проекта заложил всю программную индустрию на десятилетия (IBM не стала скрывать эти детали, к счастью).

Да основы наверно были заложены еще теми кто мануфактуры придумал в 14 веке, а так же Генри Форд, когда придумал конвейер. Но одно дело основы, а другое готовые методологии и софт. А мы то сравнивеем не пионеров, а говорим о разработке ПО как об индустрии.

N>Это факт одного отдельно взятого Госплана, который тут скорее антипример.

Да все так работали. Мой отец был начальником отдела. В подчинении у него было где-то 10-20 баб. Но ты думаешь они писали софт? Вот их когда человекочасы считали, то учитывали не только их но еще операторов машинного зала и прочих вахтеров (коими там милиция выступала). У них был WANG на котором наверное какую-то отчетность писали. У них потом ПК повились на которых эта орда баб развлекалась.

N>Я видел работу (сам не работал — ещё был совсем мал) работу киевского НИИ цен (подчинён Госплану? Госснабу? уже неважно) и чуть меньше — НИИ нефтехимии в 1984-1986. Перфокарты — только для особых режимов. Диски для основного софта и данных. Ленты для переноса данных между участниками процесса (а иногда и диски — но тут хуже с совместимостью).

Ну, к 1986му в Госплане уже писюки появились, а перфокарты действительно стали отходить. Но в 1981м, когда я ходил в первый класс, блин, еще во всю использовались и у нас дома в комнате родителей стоял Лейпциг (стенка мебели во всю стену) верхние шкафы которой были заставлены перфокартами. Потом я их в школу относил, чтобы из них делать разного рода карточки со словами и рисунками.

N>И у нас было две "IDE" для редактирования любых текстов на дисплеях (дисплеи были — 4 штуки 7066 на ЕС1022 в Ценах и 8(?) штук 7920 на ЕС1033 в Нефтехиме) и запуска системных команд — примерно как сейчас из vim можно запускать команды — питерская JEC и киевская Вектор. Вокруг была больше знаменита московская Primus, но у нас в тех двух точках её почему-то не было.

Дисплеи были, но почему-то их особо для ввода программ не использовали. Стояли себе рядом с машинным залом. На них даже световые перья были. Вот только сделать с их помощью было ничего не льзя. Так только ребенку по экрану поводить.

N>И это провинциальное ведомство. А уж центральный Госплан... В таком богатом ведомстве "загружать с перфокарт"... Ну или ты работал в каком-то дохлом НИИ подчинённом пятому помощнику заместителя третьего дворника — это вероятнее всего — и ваша работа реально никому не была нужна.

Я тогда не работал. Работал мой отец. Но точно знаю, что загружали именно с перфокарт. А дисплеи эти почеу-то простаивали.

Просто реальность такова, что все огромные коллективы (причем не только у нас, но и у них) в реальности грели воздух! А работали в реальности одиночки или коллективы из нескольких десятков человек. А далее пошла эра ПК и до мэйнфрэймов первые годы им было как до луны. Все сильно деградировало. Те же системы контроля версий изобретались по новой. CVS появился в 1990м году!

N>Что общение софтом было слабым — факт — всё держалось на личных связях. Но всё остальное что ты пишешь — какой-то лютый гон с обобщением личного опыта на весь космос, который не подтверждается как минимум моими данными и наверняка ещё нескольких современников (вон интересно, что Privalov вспомнит).

Нет, просто ты начитался Брукса и думаешь, что то что он рассказывает было везде и всегда. А он писал об истории развития компьютерной техники. О пионерах. О том как делали лутую херню за бешенные деньги! Но и ее покупали потому как другой не было. Наше развитие всегда шло с отставанием. Наши ЕС — это и были копипасщенные IBM-ы с отставанием лет на 5. А эти огромные коллективы ни хера не делали. Работали в них одиночки и мелкие группы. НИИ цен? Сейчас это даже звучит смешно. Задачу вычисления оптимальной цены невозможно решить и сейчас. А главное ее просто не надо решать. Надо просто повышать цены на то, что пользуется излишним спросом пока цена не уравновесит предложение. Коммунисты занимались лютой херней!

N>Они спорны, и я их обсуждаю с EM, но твой метод участия тут точно не сработает.

Нет, нет. Я пример привел. Он это утверждение четко опровергает. Значит утверждение ложно. Других вариантов нет.

То что сегодня не обязательно писать идеальное по производительности ПО не означает, что его не пишут. Это всего лишь вопрос выбора приоритетов. Если производительность важна и за это платят, то софт будет быстрым. За эти десятки лет изобретены более быстрые алгоритмы. Софт адаптирован к более быстрому железу (чтобы иметь возможность использовать его преимущества). При прочих равных я всегда выберу оптимальный по производительности подход. Вопрос лишь в том стану ли я тратить большие ресурсы на оптимизацию, если производительности и так хватает. На выписывание и оптимизации может уйти много времени. Зачем его тратить, если и у пользователя и более простое решение не взывает нареканий? А ты берешь какой-то частный случай и делаешь на его основе общий вывод — "Софт не становится лучше". Становится еще как! Просто не всегда быстродействие критерий качества.

Здравствуйте, VladD2, Вы писали:

Чтобы не отвечать по каждому абзацу (слишком много текста):
1. Я говорил про возможность такой разработки сверхбольшим коллективом в принципе, что ты отрицал с начала, а ты — переключился на её эффективность по сравнению с нынешними средствами.
2. "Середина века" нельзя понимать как один момент, это период минимум в 20 лет.

Прочее попунктно:

N>>"Научился использовать современные железки" вообще не относится к этому сравнению.
N>>"Быстрее" — точно быстрее, если сравнить на _одинаковом_ железе? Или просто всё вокруг стало быстрее, от процессоров до SSD?

VD>Точно быстрее. Иначе все бы ставили MS SQL 6 на новое железо. Но сама по себе постановка вопроса не корректна. Для того чтобы задействовать возможности нового железа уже нужны новые версии софта. Например, MS SQL 6 просто не умел использовать память за пределами первых 2 Гб.

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

VD>Первый компьютер и "писались программы" — это две большие разницы. Смягчать тут просто не чего. Первые компьютеры вообще программировались в машкодах и только своими авторами.

А что по-твоему это "писалось в машкодах", как не ПО?

Или есть ты признаешь за ПО только то, что продавалось? Ну тогда так и уточняй с самого начала.

VD> Это уже почти 70-й год о котором мы и говорил. И 70-м начался реальный прогресс в области разработки ПО. Шел довольно долго и только в 2010-х пришел к тому, что можно называть современным уровнем.

А тем временем придумано ещё множество фишек, которые выстрелят реально только в ближайшие 10-20 лет. И что?
Наработка началась одновременно с появлением компьютеров. То, что Брукс завершил свои концепции в конце 60-х, какой-нибудь Кент Бек оформил TDD в 2004 (а сейчас мы скорее видим его "диалектическое отрицание на новом витке развития") — это верхушка айсберга, 1% от него.
Подпишись на публикации ACM и посмотри, что нового приходит сейчас. Уверяю — там много интересного

VD>70-е года — это были года развития языков программирования и компиляторов. Писать софт большими командами тогда было невозможно просто из-за отсутствия необходимого дял этого ПО.

Писали. В той же OS/360 было несколько компиляторов.

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

Да, многого не было. Но они смогли стартовать на этой базе и показать пример остальным. Производительность и сейчас сильно разная — например, если учесть, что ~99% кода в итоге уходит в никуда, это какая производительность? Что толку с того, что мы сейчас можем наклепать компилятор или ОС за неделю? Те были сделаны за 3 года и использовались в миллионах экземпляров. Может, это тогда производительность была выше?

VD>К начальным стадям на которых не что не задумывались о разработке ПО тысячными коллективами, а думали о том как с машкодов съахать на ассмеблеры, а с них на высокоуровневые языки. Если просто посмотреть на языки тех времен, то сразу поймешь какое они были говно и что на них можно было делать.

О, ты ещё Nemerle вспомни, как раз в тему приплести.;(
Да, языки уровня повыше ассемблера развивались медленно — соответственно уровню техники и типовым задачам. Научная мысль всегда шла чуть впереди задач. Мы все избалованы законом Мура, а до начала активного внедрения его результатов (считай, начало-середина 1970х) техника мало что позволяла.

VD>И того компьтеры появлись где-то во второй половине 20го века.

Совершенно неадекватное определение, которое выхолащивает всю суть. Я не могу принять такое "итого" даже за первичную основу.

VD> До 70-х годов шло их становление и разработка языков высокого уровня. Первая пародия на систему контроля версий была создана в 1972. Но это была локальная система для IBM-мовских мэйнфрэймов. Публично ее зарелизили только в 1977 г. Реальное их развитие началось где-то в 80-е. В это же время были придуманы ООЯ и т.п. Причем вещи вроде сборочных конвейеров были придуманы еще позже, так как на мэйнфрэймах они вообще не имели смысла. Эволюция тех же систем контроля версий проходила банально на моих глазах. Еще в середине 90-х это было сташное говно плохо работающее по стеи.

Последнее слово не расшифровал, но вот тут точно не надо судить о всей индустрии по продукции Microsoft. Если ты другого не видел, это проблема личного кругозора.

VD> О каких тысячах разработчиков можно говорить в таком случае?

Ты, насколько вижу, совсем не понимаешь проблемы разработки в такой среде. Она не в отсутствии как таковой какой-то системы контроля версий (кому нужна была — тот покупал). Проблема в том, что вся среда (не только слабость VCS, а и, например, нереальная цена средств рефакторинга) приводила к дороговизне применения "гибких" подходов, неподъёмной для большинства — и поэтому "водопадная" модель была единственной массово пригодной для крупных разработок. А дальше — практически лотерея с качеством предсказания требований к моменту завершения разработки.

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

И ещё раз: решалось человеческим умом и стандартными средствами вроде определения интерфейсов между компонентами.
Проектировать крупные системы любого рода к тому времени уже научились. Что плохо умели — предсказывать требования к моменту запуска в эксплуатацию. Но это и сейчас не умеют, поэтому решают проблему средствами Agile.

VD>IBM — это были пионеры, которые до этого еще на механических машинах умудрялись не хилые объемы данных обрабатывать. Не надо выдавать единичный случай за общую практику.

И сколько таких "единичных случаев" будет? Вот с ходу второй вспомнился (см. фото со стопкой распечаток). Покопаться — ещё десяток найдём. Это сравнимо с объёмом всей индустрии того времени. Может, проблема не в бобине?

VD> Ну, и производительность труда у них была по нашим меркам (нашим временам) никакая. И было это так именно из-за отсутствия необходимого софта. Они в общем-то и родили предков этого самого софта. Первая система контроля версий как раз и была на коленке для OS/360 сделаны в 1972 году. А до этого они без них обходились. Причем это была внутренняя тула IBM, т.е. для всего мира она не существовала. А зарелизили они ее в 1977м году, т.е. практически в 80-х когда и пошло эволюционное развитие систем управления разработки софтом и не закончилось и по сей день.

Да, железо стало массово тянуть применение таких средств (без часовых задержек).

VD>То что они сделали обычные фирмы стали повторять только через десятки лет. Я лично видел как писался код в Госплан СССР, так как мой отец там работал. Они про системы контроля версий и не знали. А когда у них появились первые Писюки они просто визжали от счастья, так как программы стало возможно компилировать, запускать и получить результат сразу, а не записавшись в очередь и получив распечатку на следующий день. Сраный писюк поднял производительность программиста в сотни раз, так как программирование стало интерактивным процессом.

Ну вот это сходится с тем, что предполагает EM — сколько народу получило такую возможность только с приходом PC. А я ещё школьником видел и СМ-4, и СМ-1420, и ДВК, которые ещё в начале 80-х были, и всякие "Агаты", и побочные ответвления типа Электроники-85... (да, большинство PDP-11 в разных вариациях...) Да, это Киев, не совсем село, но и не Москва. Повторюсь — твой отец (и ты?) работали в каком-то совсем странном месте, если эти средства прошли мимо вас...

VD>Читая разных Бруксов ты даже представить не можешь как они там в реальности работали.

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

N>>5000/3 ~= 1667, а учесть неравномерность — в пике до 2000, наверно.
VD>А что это за "3"?

Года (1963-1966). Как ты читаешь, что это не очевидно?

VD>Я главное выделил. Вот тогда только декомпозиция и знали, а банальной системы контроля версий не было.

И им хватало еженедельных (например) бэкапов на бумаге и лентах.

VD> Народ экспериментировал в области ЯП. Только только от машкодов ушли. Люди уже понимали, что, например, кодом нужно управлять, но как — было не известно. SCCS — ту самую систему контроля версий — разработали только для System/370. System/360 писали без нее. Естественно испытывали боль. Два программиста уже один исходник поправить не могли.

И они успешно обсуждали друг с другом как это решать. И даже получалось

VD> Интерактивности разработки не было. Ты должен был отдать свою программу операторам и те поставят ее в очередь. А результат на распечатке, на следующий день (а то и через неделю, если тебе время не выделили).

И сейчас есть задачи, над которыми надо так работать (какие-нибудь нейросети — оно считает неделю и после этого ты видишь, правильно ли подобрал параметры). И что, от этого они становятся нерешаемыми?

N>>Это факт одного отдельно взятого Госплана, который тут скорее антипример.
VD>Да все так работали. Мой отец был начальником отдела. В подчинении у него было где-то 10-20 баб. Но ты думаешь они писали софт? Вот их когда человекочасы считали, то учитывали не только их но еще операторов машинного зала и прочих вахтеров (коими там милиция выступала). У них был WANG на котором наверное какую-то отчетность писали. У них потом ПК повились на которых эта орда баб развлекалась.

Тогда не понимаю, зачем им перфокарты. На них приносили данные?

N>>И у нас было две "IDE" для редактирования любых текстов на дисплеях (дисплеи были — 4 штуки 7066 на ЕС1022 в Ценах и 8(?) штук 7920 на ЕС1033 в Нефтехиме) и запуска системных команд — примерно как сейчас из vim можно запускать команды — питерская JEC и киевская Вектор. Вокруг была больше знаменита московская Primus, но у нас в тех двух точках её почему-то не было.
VD>Дисплеи были, но почему-то их особо для ввода программ не использовали. Стояли себе рядом с машинным залом. На них даже световые перья были. Вот только сделать с их помощью было ничего не льзя. Так только ребенку по экрану поводить.

Значит, у вас почему-то не хотели ставить этот софт. Причины мне неизвестны, но он был — уж из трёх-то возможных источников можно было выбрать.

Или дисплеи поставили нерабочими (да, вполне верю).

VD>Просто реальность такова, что все огромные коллективы (причем не только у нас, но и у них) в реальности грели воздух! А работали в реальности одиночки или коллективы из нескольких десятков человек. А далее пошла эра ПК и до мэйнфрэймов первые годы им было как до луны. Все сильно деградировало. Те же системы контроля версий изобретались по новой. CVS появился в 1990м году!

CVS стал развитием RCS с принятием части идей из SCCS. RCS была сделана как упрощение SCCS для доступных средств. SCCS это, похоже, и есть та система, что ты говоришь про S/370.
Ничего не "изобреталось", использовались уже существовавшие идеи, хотя многое в деталях подновлялось (алгоритмы мержей, например, активно развиваются и сейчас).

Деградация была только у нас, потому что был тотальный перелом. У остальных шёл эволюционный процесс переноса существующих идей на новые технические средства, которые заполняли новую, неизвестную до того нишу. Вот что показательно это что именно новые ниши становились основными (PC это один пример, а мобилки, например, достаточно свежий).
Для примера: CP/M, а позднее MS-DOS, разрабатывались на эмуляторах на мейнфрейме

N>>Что общение софтом было слабым — факт — всё держалось на личных связях. Но всё остальное что ты пишешь — какой-то лютый гон с обобщением личного опыта на весь космос, который не подтверждается как минимум моими данными и наверняка ещё нескольких современников (вон интересно, что Privalov вспомнит).
VD>Нет, просто ты начитался Брукса и думаешь, что то что он рассказывает было везде и всегда.

И снова странная приписка мне, что я думаю. Не надо так делать.

VD> А он писал об истории развития компьютерной техники. О пионерах. О том как делали лутую херню за бешенные деньги! Но и ее покупали потому как другой не было.

Эти "бешеные деньги" сравнимы со стоимостью того же железа. Всё это было дорого, да.

VD> Наше развитие всегда шло с отставанием.

Я не ориентируюсь на специфику СССР в этом обсуждении.

VD> Наши ЕС — это и были копипасщенные IBM-ы с отставанием лет на 5.

Ближе к 10, и что?

VD> А эти огромные коллективы ни хера не делали. Работали в них одиночки и мелкие группы. НИИ цен? Сейчас это даже звучит смешно. Задачу вычисления оптимальной цены невозможно решить и сейчас. А главное ее просто не надо решать. Надо просто повышать цены на то, что пользуется излишним спросом пока цена не уравновесит предложение. Коммунисты занимались лютой херней!

Вообще-то разумное планирование нужно везде и всегда, даже там, где в мелочах процветает рыночный подход. И весь мир так и делает (и США, и Европа, и Китай, и Россия, и Индия...) И есть ресурсы, для которых рыночное поведение недопустимо в условиях перекосов и дефицитов. Странно слышать от тебя предложение не управлять ценами вообще.

N>>Они спорны, и я их обсуждаю с EM, но твой метод участия тут точно не сработает.
VD>Нет, нет. Я пример привел. Он это утверждение четко опровергает. Значит утверждение ложно. Других вариантов нет.

Что именно ты считаешь таким примером? Я не понял, тут слишком много разного.

VD> А ты берешь какой-то частный случай и делаешь на его основе общий вывод — "Софт не становится лучше". Становится еще как! Просто не всегда быстродействие критерий качества.

Ты меня явно с EM перепутал. И он говорил не о частных случаях, он говорил об общей картине (статистически значимой) так, как он её видит, с несколькими иллюстрациями.
Это принципиально. И вот насколько его видение адекватно — можно и нужно обсуждать, но не циклиться на примерах.

Здравствуйте, netch80, Вы писали:

N>1. Я говорил про возможность такой разработки сверхбольшим коллективом в принципе, что ты отрицал с начала, а ты — переключился на её эффективность по сравнению с нынешними средствами.

Мы говорили о прогрессе в разработке ПО. Ты заявил о том, что в середине века разрабатывали большие системы большим количеством людей. Но это враньё, так как середине века компьютеры только разрождались. Единственный пример — IBM доказывает ровно обратное. 5000 человеколет на то, что сейчас за 5 человеколет, а то и за один. Ни в 1950-м, ни в 1960-м компьютеров, в смысле массового явления, в мире еще не было. А стало быть серьезно о разработке больших систем говорить нельзя. Не было и никакого ПО для автоматизации разработки. Не было даже баз данных.

N>2. "Середина века" нельзя понимать как один момент, это период минимум в 20 лет.

Вообще-то середина века понятие четко детерминирована — это хх50 год. Но даже если обобщить это понятие до второй трети, она закончилась в 1965-м году и в это время опять таки компьютеры еще не вышли за пределы лабораторий. В СССР же первые серийные компьютеры появились вообще в середине восьмидесятых.

N>Вот именно — само по себе расширение до 64 бит уже в чём-то ускоряет, а в чём-то замедляет. И 100500 других фишек, которые могут быть на пользу в новых условиях, но никак не ускоряют чисто в аппаратных операциях.

Да не обязательно даже 64-бит. В 32битных версиях можно было задействовать 3-й Гб в Виндовс или расширенную помять. Но факт в том, что даже если ограничить память первыми двумя гигабайтами, MS SQL 7.0 переписали чуть ли не с нуля, что сильно увеличило его производительность. В MS SQL 6 тормозила даже компиляция запроса с дойном на 10 таблиц по схеме звезда. В MS SQL 7 с этим стал по лучше. В 2000 всякие проблемы исчезли. В общем, развитие шло как по пути улучшения алгоритмов, так и по пути улучшения взаимодействия с железом. Например, в одной из версий (уже не помню какой) появилась поддержка версионирования, что повысило многопользовательскую производительность. MS SQL 6 здесь уже просто сравнивать нельзя, так как в нем многопользовательские сценарии все приводили к блокировкам.

N>А что по-твоему это "писалось в машкодах", как не ПО?

Боль! Примерно как сроить компьютеры на механических вычислителя или на лампах. А переход от машкодов хотя бы к ассемблерам был грандиозным скачком сравнимым с переходом с механики на лампы или с ламп на полпроводники.

N>Или есть ты признаешь за ПО только то, что продавалось? Ну тогда так и уточняй с самого начала.

Мы говорили об индустрии разработке ПО и о средствах их разработки. Ты решил поддержать не выдерживающую критики, на мой взгляд, теорию Музыченко о том, что разработка ПО не развивалась как это было в области микросхем. Начал утверждать про какие-то мифические возможности разработки ПО средствами тысяч разработчиков в середине прошлого века. Но это ж чушь! Середина прошлого века — это точка в которой компьютеры стали появляться. Шла бурная эволюция, как и в микросхемах. Причем эволюция шла в сторону развития мэйнфреймов. А в 80 она пошла заново, так как от мэйнфреймов отказались и перешли сначала на ПК, а потом на их сети.

Люди учились писать софт от малого к большому. Нарабатывали технологии совместной разработки. В некоторых областях и сейчас дремучие 60-е прошлого столетия. Например, в C++ до сих пор нет модульной системы! А это язык, с дуру, повсеместно использует и приводит к дикому замедлению сборочного процесса. Но, конечно, есть и хорошие примеры. Почти все другие языки имеют те или иные модульные системы.

N>А тем временем придумано ещё множество фишек, которые выстрелят реально только в ближайшие 10-20 лет. И что?

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

N>И что?

И то. Это и есть прогресс. Не важно встрелят они или просто эволюционно улучшат положение дел — это прогресс, которые очень даже ощутим, если не звиздить как Троцкий, что "еще в середине прошлого века...".

N>Наработка началась одновременно с появлением компьютеров. То, что Брукс завершил свои концепции в конце 60-х, какой-нибудь Кент Бек оформил TDD в 2004 (а сейчас мы скорее видим его "диалектическое отрицание на новом витке развития") — это верхушка айсберга, 1% от него.

Да ничего Брукс не придумал в 60-х. Они базу создали. ГовноОС, если сравнивать ее с любой ОС из современного телефона. Эволюция разработки софта шла всю жизнь и идет сейчас. В те времена современные объемы кода были просто не мыслим. IBM просто обосрался бы, если бы попытался написать современную Windows 10 или Android 12 на том развитии софтостроения (даже если железо бы того позволяло). Собственно IBM и обосрался чуть позже, когда выпустил свои OS/2. В прочем его своим и назвать то нельзя, так как по сути там уже в базе была Windows. Брутфорс он не канает в наши времена.

N>Подпишись на публикации ACM и посмотри, что нового приходит сейчас. Уверяю — там много интересного

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

N>Писали. В той же OS/360 было несколько компиляторов.

Говноязков. А потом все на С переписали. Ты путаешь индустриальную разработку и пионеров граничащих с исследовательской деятельностью. IBM сделал большой вклад в развитие софтостроения. Но кроме него в этом процессе принимало участие множество других компаний. И было это уже в 70-е, 80-е, 90-е, 00-е и даже в 10 и 20. Процесс идет до сих пор. Не так бурно как в начале, но идет.

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

N>Да, многого не было. Но они смогли стартовать на этой базе и показать пример остальным. Производительность и сейчас сильно разная — например, если учесть, что ~99% кода в итоге уходит в никуда, это какая производительность?

А если глупостей не учитывать? Я что-то не заметил, чтобы мой код уходил в никуда. Если я даже его переписываю, но прошлая версия этого кода уже работала в релизной версии продукта. Иногда не долго, так как это тестовое использование (например, A/B-тестирование). Но все же несколько тысяч человек его использует.

N>Что толку с того, что мы сейчас можем наклепать компилятор или ОС за неделю?

Не можем. Точнее можем такое же говно как OS/360 для 1-2 железок. Но такое качество сейчас никому не нужно. Современная ОС — это огромныные кучи кода, большая часть из которой — драйвера.

N>Те были сделаны за 3 года и использовались в миллионах экземпляров. Может, это тогда производительность была выше?

Какими на фиг миллионами? Акстись! Миллоны — это сейчас. Выпуск IBM System/360 чуть не завалил саму IBM. Она тупо надорвалась. И выпустили они ее в 1964-м году, так что в реальности ее стали осваивать уже в третьей трети 20го века. И о какой-то там разработке масштабного ПО просто не приходилось говорить. Повторюсь сраный сорс-контрол был зарелизен IBMом в 1977м году!

70-е стали первой вехой в эволюции разработки ПО. А в итоге все эти мэйнфреймы пошли в помоечку, а сегодняшние суперкомпьютеры — это банальные кластеры серверов, т.е. по сути связка ПК. Вычислительные мощности одной современной топовой видеокарты сравнимы с вычислительными мощностями всех компьютеров 70-х, наверно.

N>О, ты ещё Nemerle вспомни, как раз в тему приплести.;(

А что мне его вспоминать то? Он и на сегодня по ряду свойств является передовым языком, а появился он только в 00-ых. Разные IBM-ы и Microsoft-ы тупо пока не дорасли до такого. Макросы для них это "слишком большая пушка" (точная цитата Хельсберга). Хотя отдельные фичи они за 20 лет переняли. И вот через 20 лет современный C# недотягивает до Nemerle 2003-го года.

N>Да, языки уровня повыше ассемблера развивались медленно — соответственно уровню техники и типовым задачам. Научная мысль всегда шла чуть впереди задач. Мы все избалованы законом Мура, а до начала активного внедрения его результатов (считай, начало-середина 1970х) техника мало что позволяла.

Закон мура на производительность уже давно не влияет, кстати. Транзисторы удваиваются, но общая производительность от этого линейно не растет. Казалось бы уже можно науку привлекать. Но процесс действительно идет медленно. Но мы то не об этом. Мы о том, что процесс шел и идет! От полупроводников тут особых отличий нет. Он был более бурным в 70-80, но идет и сейчас.

N>Совершенно неадекватное определение, которое выхолащивает всю суть. Я не могу принять такое "итого" даже за первичную основу.

Набором, совершенно адекватное, в отличии от утверждения, что в середине века что-то там делали большого объема.

Именно в середине века фактическое появление. В 60-х развивались архитектуры, ОС, параллельные вычисления, в 70-повявление зачатков софта для разработки ПО большими коллективами, в 80 крах мэйнфреймов и новая эволюция ПК, которые переизобретали все с нуля. Далее в развитие включилась масса народа и пошло стабильное эволюционное развитие. Сейчас этот процесс замедлился, но все же идет. То же железо до сих пор не предоставляет массового параллелизма (если не считать случаев суперкомпьютеров). А казалось еще в 70 об этом мечтали.

Вообще, все очень похоже на освоение космоса. Бурное развитие на энтузиазме. Угасание энтузиазма и переход в стадию постепенного эволюционного развития.

N>Последнее слово не расшифровал, но вот тут точно не надо судить о всей индустрии по продукции Microsoft. Если ты другого не видел, это проблема личного кругозора.

Я видел все. Но МС отличный представитель своего времени. Все развивались точно так же. Первые Макинтоши собирались на коленке из процессоров выдранных из каких-то там бытовых девайсов. Точно так же писались первые СБУД. Да еще в IBM придумали SQL и саму идею реляционной СУБД. Но их труд сдох вместе с мэйнфреймами. Да и звезд он с небе на хватал. А верх взяли разные Oracle и Sybase, которые в те времена были игрушками. Ну, а МС сумел развиться из компании состоящей из нескольких человек в мега-корпорацию.

Я вот тебе больше скажу. Я сейчас в Касперсом работаю. Сейчас флагманский продукт — Каспексий Антивирус для ПК — это огромная гора кода давно переставшая быть просто антивирусом, а начинался то он с утилитой которую Касперский написал в одиночку. И так было почти с любым ПО. ДОС написал одиночка и в последствии продал его МС. Оракл написал Лари Элисон с двумя приятелями. Было это в 1977-м. В последствии Оракл превратил в мегакорпорацию.

N>Ты, насколько вижу, совсем не понимаешь проблемы разработки в такой среде. Она не в отсутствии как таковой какой-то системы контроля версий (кому нужна была — тот покупал). Проблема в том, что вся среда (не только слабость VCS, а и, например, нереальная цена средств рефакторинга) приводила к дороговизне применения "гибких" подходов, неподъёмной для большинства — и поэтому "водопадная" модель была единственной массово пригодной для крупных разработок. А дальше — практически лотерея с качеством предсказания требований к моменту завершения разработки.

Ну, конечно, куда мне серому и убогому до понимания того как пишется большой софт.

Системы контроля версий и еще 100500 систем — это без чего разработка софта большого объема невозможны. Ну, или превращают разработку в мало эффективный АД. Конечно, это все инструменты. Но без них попросту нельзя. Производительность твоего труда снизится настолько, что ты завязнешь и тебя обойдут конкуренты.

Что по поводу водопад vs. агил, то мне кажется это надуманно. Я вот и не возьмусь сказать что у нас в итоге получается. Может это классический водопад, а может SCRUM со спринтами в полгода-год.

С одной стороны, у нас постоянный выпуск релизов на билдконвеере. Но с другой есть реальные релизы между которыми идет полноценный водопадный процесс. Ну, требования в виде огромных талмудов с кучей текста у нас нет. Но набор требований все же есть. Причем как в виде екселек, так и в виде экранов гуев (для гуевых фич). И пойди скажи что это, гибкий водопад или затянутый SCRUM. Постоянное тестирование и выпуск реализов по 2-3 раза в день как в агилах. Но полноценные и затяжные итерации с планированием, реализацией, тестирование и последующей поддержкой как в водопаде.

Вот декомпозиция она всегда рулит — да. Почти любая разработка сегодня — это добавление функционала к чему-то готовому и большому. А значит нужно вплетать новый код в уже имеющийся и при этом его не поломать. Отсюда вытекает необходимость в тестах или постоянном ручном тестировании (или и в том и в другом). Задача тестов — предотвратить регрессию. Но сами тесты — это зло, которое приходится терпеть. Ведь требуют время на поддержку и фиксируют реализацию (а значит препятствуют изменению кода). А идея TDD она, на мой взгляд, не сильно производительная.

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

N>И ещё раз: решалось человеческим умом и стандартными средствами вроде определения интерфейсов между компонентами.
N>Проектировать крупные системы любого рода к тому времени уже научились. Что плохо умели — предсказывать требования к моменту запуска в эксплуатацию. Но это и сейчас не умеют, поэтому решают проблему средствами Agile.

Еще раз: IBM OS/360 — это детская игрушка по сегодняшним времена. 5000 человекочасов на нее — это немыслимый перерасход времени и средств. И все это из-за неумения создавать такие системы и отсутствия ПО поддержки разработки.

А с интерфейсами проблему научились решать довольно быстро. Хотя до модулей некоторые не дожили и по сей день.

Что до предсказания требований, то это, похоже, только в твоей голове имеющаяся проблема. У нас с этим проблем особо нет. Требования расписываются еще до разработки новой версии и полностью выполняются в процессе. Ну, разве что уточняются в процессе, так как формализация требований процесс недетерминированный и не автоматизированный, к сожалению. Программист всегда найдет что-то не описанное. Но в целом с требованиями проблем нет. А вот с определением сроков всегда проблема есть. Обычно люди сильно занижают сроки. Ведь редко когда видно все детали наперед. А черт кроется в деталях.

N>И сколько таких "единичных случаев" будет? Вот с ходу второй вспомнился (см. фото со стопкой распечаток). Покопаться — ещё десяток найдём. Это сравнимо с объёмом всей индустрии того времени. Может, проблема не в бобине?

Да вот он наверно один и есть. Еще параллельно работала Bell Labs (AT&T). Но они долгое время работали в стол (для внутренних нужд). Толпа нарастала уже потом, когда IBM и Bell Labs зарелизили свои системы. Unix появился в 1971м, например. Мы до сих пор это ощущаем, так как системное время унихах измеряется от 1970го года. Собственно в процессе работы над Unix родился один из самых успешных ЯП — C. А вот долгие заседания комитетов по Алголу ни хрена по сути не дали. Ну, разве что толкнули Вирта на создание другого довольно популярного языка — Паскаля.

N>Да, железо стало массово тянуть применение таких средств (без часовых задержек).

Да ладно! По тем времена они очень даже тянули. А на сегодня у нас, откровенно говоря, git не тянет. Даже с костылями от MS (GVFS) тормозит на наших объемах адски! В прочем, это скорее из-за новомодных Монорем.

N>Ну вот это сходится с тем, что предполагает EM — сколько народу получило такую возможность только с приходом PC. А я ещё школьником видел и СМ-4, и СМ-1420, и ДВК, которые ещё в начале 80-х были, и всякие "Агаты", и побочные ответвления типа Электроники-85... (да, большинство PDP-11 в разных вариациях...) Да, это Киев, не совсем село, но и не Москва. Повторюсь — твой отец (и ты?) работали в каком-то совсем странном месте, если эти средства прошли мимо вас...

Ты что-то там себе навыдумывал. СМ-1420 появилась в 1983-ем и была страшным говном. СМ-1420-1 с аж почти 2 мегами оперативки в 1985-м. А до людей это все доезжал еще позже. Ты еще расскажи мне историю, как на СМ-1420 (первого выпуска) работал коллектив из 100 человек. Не может и работали. Но выглядело это очень грустно. Каждому приходилось небольшой кусочек времени в дено, а то и в неделю.

Я вот сейчас вспоминаю сколько мой отец притаскивал домой бумаги в виде распечаток. Его одна отладочная сессия стоила государству, наверное, в сотню баксов.

В общем, ты как-то странно оцениваешь время и развитие. Вот появился СМ-1420 и все у всех он есть, все уже прогаммы коллективами в 1000 человек к нему разрабатывают. Но это же лажа. Говномашина с 128К оперативки работающая крайне медленно. Крайне дорогие носители памяти. Все это надо освоить. Переложить на программы то что раньше считали полуручным способом. Это все требовало времени. Наверно были те кто брался за все это большими коллективами, но они испытывали боль и имели крайне низкую эффективность. Потом люди тупо привыкли все делать по старым лекалам. Написать пару талмудов документации! Провести пару симпозиумов и конференций. А в итоге родить мышь.

N>Не надо высасывать из пальца то, чего ты не знаешь и не можешь знать. Могу. Я работал с бумагой и перфокартами.

Ну, и сколько сотен человек было в твоей команде?

N>Вот с перфолентами не довелось, но видел их вплотную

Я слава Богу с перфокартами только играл, а перфолентами только обматывался. Но по счастливому лицу отца сразу понял, что PC — это круто. Потому и учился программировать на них. Но все это я видел. И у мет сомнений, что с современными методами это все сравнивать нельзя. Между ними пропасть. Ваши агилы сталы возможны только потому, что железо стало это позволять. Я вот комичу код и через пару часов получаю релиз продукта, который прошел тесты и проверяется тестерами. А мой отец вставал в очередь. Получал распечатку на следующий день и все выходные ее просматривал (длинна у них порой была адская). А я из ни потом разную херню мастерил. У нас производительность труда несопоставимая.

N>И им хватало еженедельных (например) бэкапов на бумаге и лентах.

Если бы хватало, они бы их не создали. А они создали.

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

N>И они успешно обсуждали друг с другом как это решать. И даже получалось

Ну, вот между обсуждением и реальным решением лежит пропасть. Уверен, что прежде чем они создали VCS они несколько раз хлебнули говна в результате затирания кода и ручного мержа. Потом придумали дифилку. А затем и VCS. Вот и получилось, что с условного 1950-го до 1960-го было развитие вообще базовых вещей вроде перехода от машкодов к высокоуровневым ЯП и создание ОС. В 60 поперло базове развитие. К 1970-м что-то даже можно было использовать. А там началась эра ПК и все начлось сначал

N>Ты меня явно с EM перепутал. И он говорил не о частных случаях, он говорил об общей картине (статистически значимой) так, как он её видит, с несколькими иллюстрациями.
N>Это принципиально. И вот насколько его видение адекватно — можно и нужно обсуждать, но не циклиться на примерах.

Ну, так я понимаю ты его теорию и защищаешь. Как по мне это просто не знание истории. Или не желание ее знать. За 70 лет прошел не хилый такой прогресс. Если Брукс увидел средства которые есть у нас сейчас и софт который мы сейчас создаем он бы офигел. Тут кто-то правильно заметил, что в 1988м бурам сел на автомате. Но это почти 90-й! И тогда это было чудом. А сейчас в любом сразном Боинге или Аэрбасе система автоматической посадки, которой хлопают разные дебилы при посадке.

Здравствуйте, VladD2, Вы писали:

N>>1. Я говорил про возможность такой разработки сверхбольшим коллективом в принципе, что ты отрицал с начала, а ты — переключился на её эффективность по сравнению с нынешними средствами.

VD>Мы говорили о прогрессе в разработке ПО. Ты заявил о том, что в середине века разрабатывали большие системы большим количеством людей. Но это враньё, так как середине века компьютеры только разрождались.

И опять твоё странное понятие что считать серединой века и "враньё" всё что не входит в неё. Как-то сложно дискутировать при таком стиле оппонента.

VD> Единственный пример — IBM доказывает ровно обратное. 5000 человеколет на то, что сейчас за 5 человеколет, а то и за один. Ни в 1950-м, ни в 1960-м компьютеров, в смысле массового явления, в мире еще не было. А стало быть серьезно о разработке больших систем говорить нельзя. Не было и никакого ПО для автоматизации разработки. Не было даже баз данных.

Именно, что при тотальном отсутствии автоматизации — была произведена первая обкатка подходов в принципе — и сформулированы концепции, которые актуальны и сейчас, и будут оставаться актуальны ещё долго.

С твоим же подходом нужно отрицать, например, всю теорию численных расчётов за времена до формализации IEEE 754 — хотя управлять точностью расчётов умели ещё в древнем Вавилоне. Да, им это было в ~1000 раз дороже, чем нам сейчас с бумагой — но они это сумели.

VD> В СССР же первые серийные компьютеры появились вообще в середине восьмидесятых.

Моя твоя совсем перестать понимать. "Серийные" это какие? Смотрю в вики:
БЭСМ-2: 1958-1962, 67 штук.
М-20: 1959-1962, 20 штук.
БЭСМ-4: 1965-?, 30 штук.
БЭСМ-6, которую так хвалит ЕМ: 1967-1987, 355 штук.
ЕС-1030: 1973-?, 436 штук.
ЕС-1050: 1973-?, 87 штук.
ЕС-1022: 1975-?, 3929 штук.
М-220: 1968-1974, 810 штук (если с М-222).
Минск-32: 1968-1975, 2889 штук.
Наири: 1964-1970, 500 штук.

Какие "в середине восьмидесятых"? Это ты безнадёжно занёсся (смягчённо говоря), потеряв хоть какое-то понимание реальности (и всё время говоришь "враньё" на других).

VD> MS SQL 7.0 переписали чуть ли не с нуля, что сильно увеличило его производительность. В MS SQL 6 тормозила даже компиляция запроса с дойном на 10 таблиц по схеме звезда.

OK, ты замечательно выбрал ветряную мельницу для битья. А теперь сравни MS SQL 7 (а не 6, раз для тебя 7 так переписан с нуля) с современным.
Впрочем, я не разбираюсь в MS SQL на уровне дальше запустить сервис и нарисовать пяток таблиц, так что наверняка ты и тут какой-то пример найдёшь — но о чём это говорит?
Возьми что-то другое. Windows, Visual Studio...

N>>А что по-твоему это "писалось в машкодах", как не ПО?
VD>Боль! Примерно как сроить компьютеры на механических вычислителя или на лампах. А переход от машкодов хотя бы к ассемблерам был грандиозным скачком сравнимым с переходом с механики на лампы или с ламп на полпроводники.

Тем не менее писали. И то, что результат сохранён, было ценнее, чем сложность написания. Если уж так считать, то революция произошла не на этом этапе, а когда появились 1) ассемблер который генерирует объектники вместо абсолютных бинарников и 2) линкер для создания бинарника из объектников (в современных терминах). Потому что без линкера хотя на Idris пиши — всё одно собирать и запускать это будет тяжело.

N>>Или есть ты признаешь за ПО только то, что продавалось? Ну тогда так и уточняй с самого начала.
VD>Мы говорили об индустрии разработке ПО и о средствах их разработки. Ты решил поддержать не выдерживающую критики, на мой взгляд, теорию Музыченко о том, что разработка ПО не развивалась как это было в области микросхем.

Нет, я её не поддерживал. Я возражал против твоей откровенно неумеренной и фантастической критики на основе твоего глубокого невежества в истории, и продолжаю делать это и сейчас.
"Теория" EM содержит очень много преувеличений, но и здравое зерно в ней есть — надо только его аккуратно отделить, а не рубить бензопилой всё, как делаешь ты.

VD> Начал утверждать про какие-то мифические возможности разработки ПО средствами тысяч разработчиков в середине прошлого века. Но это ж чушь! Середина прошлого века — это точка в которой компьютеры стали появляться. Шла бурная эволюция, как и в микросхемах. Причем эволюция шла в сторону развития мэйнфреймов. А в 80 она пошла заново, так как от мэйнфреймов отказались и перешли сначала на ПК, а потом на их сети.

И снова ты не учитываешь множество промежуточных элементов истории, причём так, что нельзя иначе понять, что ты настолько невежественен, что не знаешь самых основ
Для сравнения: S/360 это 1964 год. А PDP-1 (один из первых серийных компьютеров тогдашнего класса "мини", а не "мейнфреймов" это 1958-й (в вики 1959-й)! Линия "мини" пошла очень рано параллельно "мейнфреймам". В 1970-х их уже было около десятка видов. Далее, Apple I это 1976, и он не первый в классе "микро" (вон, MCM/70 это 1973). Какие 80-е?

Может, ты начнёшь хоть иногда читать источники прежде чем изрекать утверждения "фантастического масштаба и фантастической же глупости" (c)?

VD>Люди учились писать софт от малого к большому. Нарабатывали технологии совместной разработки. В некоторых областях и сейчас дремучие 60-е прошлого столетия. Например, в C++ до сих пор нет модульной системы! А это язык, с дуру, повсеместно использует и приводит к дикому замедлению сборочного процесса.

И кого это волнует из пользователей софта?

N>>А тем временем придумано ещё множество фишек, которые выстрелят реально только в ближайшие 10-20 лет. И что?
VD>Я таких фишек не видел.

Я ж говорю — сходи ACMовские журналы почитай
Мировой прогресс отражается в основном именно там.
Ну да, я понимаю, это ж платить надо. Бяда...

N>>Наработка началась одновременно с появлением компьютеров. То, что Брукс завершил свои концепции в конце 60-х, какой-нибудь Кент Бек оформил TDD в 2004 (а сейчас мы скорее видим его "диалектическое отрицание на новом витке развития") — это верхушка айсберга, 1% от него.

VD>Да ничего Брукс не придумал в 60-х. Они базу создали.

Да. Именно так это и делается. Создаётся база — в 10-100 раз дороже, чем потом можно было бы. Почитай труды, из которых возникло какое-нибудь дифференциальное исчисление. Ты просто ничего не поймёшь, а когда продерёшься — будешь в ужасе, как это громоздко и запутанно. Его потом вычищали лет 200 до современного состояния.
И тем не менее мы пользуемся их результатами.
Точно так же с OS/360 и Бруксом.

N>>Подпишись на публикации ACM и посмотри, что нового приходит сейчас. Уверяю — там много интересного
VD>Спасибо, у меня есть чем заняться и чем развлекаться. В разработке софта тоже есть много нового.

Ну как хочешь.

N>>Писали. В той же OS/360 было несколько компиляторов.
VD>Говноязков. А потом все на С переписали.

Для System/Z на C в основном не пишут. Продолжают писать на ассемблере ("high-level assembler", HLASM — у меня хороший знакомый на нём продолжает писать через прокладку в виде киевского GlobalLogic).

VD> Ты путаешь индустриальную разработку и пионеров граничащих с исследовательской деятельностью. IBM сделал большой вклад в развитие софтостроения. Но кроме него в этом процессе принимало участие множество других компаний.

Я с этим никогда и не спорил. Тем не менее, первый такой огромный проект оказал влияние на всех. Схожие по масштабу у конкурентов появились только через несколько лет.
Даже в 80-х были люди вроде Крэя не понимавшие ценности среды/инфраструктуры и ОС (на чём, по утверждениям многих, Крэй и погорел).

N>>Что толку с того, что мы сейчас можем наклепать компилятор или ОС за неделю?
VD>Не можем. Точнее можем такое же говно как OS/360 для 1-2 железок. Но такое качество сейчас никому не нужно. Современная ОС — это огромныные кучи кода, большая часть из которой — драйвера.

N>>Те были сделаны за 3 года и использовались в миллионах экземпляров. Может, это тогда производительность была выше?

VD>Какими на фиг миллионами? Акстись! Миллоны — это сейчас. Выпуск IBM System/360 чуть не завалил саму IBM. Она тупо надорвалась.

Вначале — надорвалась. Потом — взлетела на этом так, что её пришлось осаживать административно.
В пике одновременно было около сотни тысяч. Для того мира это уже фантастика. Сейчас zSeries около 40 тысяч постоянно используемых.

Драйвера — да, с подходом стиля PC они такие нужны. С подходом IBM всё-таки проще.

VD> И выпустили они ее в 1964-м году, так что в реальности ее стали осваивать уже в третьей трети 20го века. И о какой-то там разработке масштабного ПО просто не приходилось говорить. Повторюсь сраный сорс-контрол был зарелизен IBMом в 1977м году!

Не вижу, из-за чего такой кипиш по поводу этого source control. Ну да, раньше его было неоптимально использовать.

VD>70-е стали первой вехой в эволюции разработки ПО. А в итоге все эти мэйнфреймы пошли в помоечку,

Расскажи это про помоечку самой IBM. Тысяч 40, повторюсь, живых установок только System/Z. Считай, с каждой по 2-3k$ в месяц минимум, если в лизинг (очень удобно, кстати). Где-то ещё столько же для софта. Не миллиарды, конечно, но достаточно. А ещё System/i, чуть поменьше количеством, но по деньгам может быть ещё больше.

То, что IBM, испугавшись возможности принудительного раздела, как AT&T, выделила рынок PC в отдельный сектор и отдала в Microsoft — стандартная сейчас конспирология, которую я считаю адекватной. В любом случае у неё огромный R&D сектор, патенты и прочее. Чьи HDD были лучшими в 90-х? IBM. Чьи люди придумали SSA, который в современных компиляторах? IBM. И 100500 других инноваций. Ну ты себе можешь думать, что они ничего не могут, на это и рассчитано — обмануть иванов родства не помнящих

VD> а сегодняшние суперкомпьютеры — это банальные кластеры серверов, т.е. по сути связка ПК. Вычислительные мощности одной современной топовой видеокарты сравнимы с вычислительными мощностями всех компьютеров 70-х, наверно.

Стандартный процессор IBM z15 — 12-ядерный (и 2 треда на ядро), 14 нм технология, out-of-order execution и прочие стандартные современные фишки... в одну систему ставятся до 240 процессоров. Память RAIM (как RAID, но на памяти; обычно — уровень 5 или 6). Для желающих — режим повторения каждой команды дважды, чтобы всякие горячие нейтрино не портили данные — Intel до такого в жизни не дорастёт, они даже ECC фиктивный делают, сколь их ни просят.
Каналы ввода-вывода со скоростями в гигабиты в секунду (если надо далеко — на оптике). Интеграция со всеми современными стандартами железа? Без проблем.
Стиль во всём специфический, да. Терминология своя. Учиться надо.

N>>Да, языки уровня повыше ассемблера развивались медленно — соответственно уровню техники и типовым задачам. Научная мысль всегда шла чуть впереди задач. Мы все избалованы законом Мура, а до начала активного внедрения его результатов (считай, начало-середина 1970х) техника мало что позволяла.
VD>Закон мура на производительность уже давно не влияет, кстати. Транзисторы удваиваются, но общая производительность от этого линейно не растет.

Растёт. Мы тут на днях одну штуку тестировали... Corei 11-го поколения в 2 раза быстрее 4-го (Haswell) при даже меньшей частоте и лаптопе вместо десктопа. Не быстро растёт, да, но не остановился.

N>>Совершенно неадекватное определение, которое выхолащивает всю суть. Я не могу принять такое "итого" даже за первичную основу.

VD>Набором, совершенно адекватное, в отличии от утверждения, что в середине века что-то там делали большого объема.

VD>Именно в середине века фактическое появление. В 60-х развивались архитектуры, ОС, параллельные вычисления, в 70-повявление зачатков софта для разработки ПО большими коллективами, в 80 крах мэйнфреймов и новая эволюция ПК, которые переизобретали все с нуля.

"Крах мэйнфреймов" тут только в представлении советского человека, который ничего кроме двух крайностей не видел. Я продолжаю не понимать — ты что, в 80-х ни разу несчастную СМ-4 не видел? Да их на каждом углу в этих НИИ стояло.
В цивилизованном мире переход был плавным, с массой промежуточных этапов. Да, там была несовместимость (увы, или к счастью — у IBM даже кодировка своя), но перейти спокойно без напряга было тривиально. Ну и PC стали заполнять новые ниши, которых не было до их введения (как 10 лет назад смартфоны).

Ну и снова — пока для тебя "софт для разработки большими коллективами" это VCS, разумного обсуждения не будет.

VD> Далее в развитие включилась масса народа и пошло стабильное эволюционное развитие. Сейчас этот процесс замедлился, но все же идет. То же железо до сих пор не предоставляет массового параллелизма (если не считать случаев суперкомпьютеров).

А тебя HAC и все подходы по балансингу не устраивают? Хочешь всё в одной железяке?

N>>Последнее слово не расшифровал, но вот тут точно не надо судить о всей индустрии по продукции Microsoft. Если ты другого не видел, это проблема личного кругозора.

VD>Я видел все. Но МС отличный представитель своего времени. Все развивались точно так же. Первые Макинтоши собирались на коленке из процессоров выдранных из каких-то там бытовых девайсов. Точно так же писались первые СБУД. Да еще в IBM придумали SQL и саму идею реляционной СУБД. Но их труд сдох вместе с мэйнфреймами. Да и звезд он с небе на хватал. А верх взяли разные Oracle и Sybase, которые в те времена были игрушками.

DB2 продолжает работать и массово использоваться в самых ответственных местах (куда МС не допускают, не доверяют).

VD> Ну, а МС сумел развиться из компании состоящей из нескольких человек в мега-корпорацию.

Ну ещё бы — после того, как им создали все условия (сначала железо в виде готового концепта IBM PC, потом хитрым образом контракт на ОС через маму Гейтса...) Типовая накачка ресурсами нового проекта. Ещё бы он не выстрелил.

VD>Я вот тебе больше скажу. Я сейчас в Касперсом работаю. Сейчас флагманский продукт — Каспексий Антивирус для ПК — это огромная гора кода давно переставшая быть просто антивирусом, а начинался то он с утилитой которую Касперский написал в одиночку. И так было почти с любым ПО. ДОС написал одиночка и в последствии продал его МС.

Этот "одиночка" перекопировал CP/M чуть ли не 1:1 по заказу MS. А за CP/M стоял опыт не только его автора Гэри Килдалла, но и опыт DEC в виде RSX-11, из которой (убив несколько важных концепций) сделали CP/M. Перестань мучить сову.

Что там писал Касперский и кто ему помогал — тоже минимум натрое делить надо.

VD> Оракл написал Лари Элисон с двумя приятелями. Было это в 1977-м. В последствии Оракл превратил в мегакорпорацию.

Oracle — да, возможно. Тут деталей не знаю. Но остальные твои примеры не в тему.

N>>Ты, насколько вижу, совсем не понимаешь проблемы разработки в такой среде. Она не в отсутствии как таковой какой-то системы контроля версий (кому нужна была — тот покупал). Проблема в том, что вся среда (не только слабость VCS, а и, например, нереальная цена средств рефакторинга) приводила к дороговизне применения "гибких" подходов, неподъёмной для большинства — и поэтому "водопадная" модель была единственной массово пригодной для крупных разработок. А дальше — практически лотерея с качеством предсказания требований к моменту завершения разработки.

VD>Ну, конечно, куда мне серому и убогому до понимания того как пишется большой софт.

До понимания, какие проблемы у этого были в 1960-х — да, видимо, далеко.

VD>Системы контроля версий и еще 100500 систем — это без чего разработка софта большого объема невозможны. Ну, или превращают разработку в мало эффективный АД. Конечно, это все инструменты. Но без них попросту нельзя. Производительность твоего труда снизится настолько, что ты завязнешь и тебя обойдут конкуренты.

Темп конкуренции был ниже. Поэтому успели.

VD>Что по поводу водопад vs. агил, то мне кажется это надуманно. Я вот и не возьмусь сказать что у нас в итоге получается. Может это классический водопад, а может SCRUM со спринтами в полгода-год.

VD>С одной стороны, у нас постоянный выпуск релизов на билдконвеере. Но с другой есть реальные релизы между которыми идет полноценный водопадный процесс. Ну, требования в виде огромных талмудов с кучей текста у нас нет. Но набор требований все же есть. Причем как в виде екселек, так и в виде экранов гуев (для гуевых фич). И пойди скажи что это, гибкий водопад или затянутый SCRUM. Постоянное тестирование и выпуск реализов по 2-3 раза в день как в агилах. Но полноценные и затяжные итерации с планированием, реализацией, тестирование и последующей поддержкой как в водопаде.

Вопрос в длине минимального элемента. Если 2-3 раза в день — значит, очень гибкое. Это не мешает на верхнем уровне строить планы хоть на десятилетия.
Водопад 60-70-80-х это как раз когда сделал спеку и фидбэк через год, если повезёт.

VD>Вот декомпозиция она всегда рулит — да. Почти любая разработка сегодня — это добавление функционала к чему-то готовому и большому. А значит нужно вплетать новый код в уже имеющийся и при этом его не поломать. Отсюда вытекает необходимость в тестах или постоянном ручном тестировании (или и в том и в другом). Задача тестов — предотвратить регрессию. Но сами тесты — это зло, которое приходится терпеть. Ведь требуют время на поддержку и фиксируют реализацию (а значит препятствуют изменению кода). А идея TDD она, на мой взгляд, не сильно производительная.

За TDD само по себе я и не агитирую. Но на индустрию оно сильно повлияло.

VD>А вот как изменять ПО без системы контроля версий, отладки дампов и прочих современных фич я действительно представить не могу. Ну, если ты пишешь код один и этот код работает только у тебя, то может без этого и можно обойтись. Но если у тебя есть хотя бы пара десятков коллег пишущих код, ты пузо надорвешь без таких систем.

Да вот делали. Работало.
И сейчас можно. Только неудобно и таки в разы медленнее.

VD>Еще раз: IBM OS/360 — это детская игрушка по сегодняшним времена. 5000 человекочасов на нее — это немыслимый перерасход времени и средств. И все это из-за неумения создавать такие системы и отсутствия ПО поддержки разработки.

Ты уверен, что знаешь, что в неё входило тогда?
Ты знаешь все системные и пользовательские утилиты, например? Их было много.
Перерасход — очевидно, но ты его преувеличиваешь на порядок, похоже.

VD>А с интерфейсами проблему научились решать довольно быстро. Хотя до модулей некоторые не дожили и по сей день.

VD>Что до предсказания требований, то это, похоже, только в твоей голове имеющаяся проблема. У нас с этим проблем особо нет.

Это от цели софта зависит.
У меня на прошлой работе больше половины этого зависело от того, кто из кастомеров решится заплатить за какую фичу. В принципе этих фич 100500 можно придумать с ходу, но какие из них реально востребованы — слабо предсказуемо.
И в результате мы даже цифры выводили типа — 10-15% спеков заметно изменятся за пару лет, 50% — за десяток или даже чуть раньше.
В случае Касперского, похоже, проще. Не уверен, что всё понимаю, но очевидности типа "ой, Windows 11 анонсировали, бежим выяснять, что они сломали" не отличаются от такого же "ой, Windows 10 2204 анонсировали". Всё равно ломают и надо адаптироваться
ну а поток вирусов где-то постоянный.
Хотя, думаю, когда криптователи появились — это было неожиданностью.

N>>И сколько таких "единичных случаев" будет? Вот с ходу второй вспомнился (см. фото со стопкой распечаток). Покопаться — ещё десяток найдём. Это сравнимо с объёмом всей индустрии того времени. Может, проблема не в бобине?

VD>Да вот он наверно один и есть. Еще параллельно работала Bell Labs (AT&T). Но они долгое время работали в стол (для внутренних нужд). Толпа нарастала уже потом, когда IBM и Bell Labs зарелизили свои системы.

Да. Потому что железо подешевело. Но и до того — какой объём кода у VM/370? А у RSTS-E?

VD> Unix появился в 1971м, например.

Путём упрощения Multics до "подъёмного" объёма фич.

VD> Мы до сих пор это ощущаем, так как системное время унихах измеряется от 1970го года.

И оно там сдвигалось несколько раз. Могли себе позволить.

N>>Да, железо стало массово тянуть применение таких средств (без часовых задержек).
VD>Да ладно! По тем времена они очень даже тянули. А на сегодня у нас, откровенно говоря, git не тянет. Даже с костылями от MS (GVFS) тормозит на наших объемах адски! В прочем, это скорее из-за новомодных Монорем.

Ну теперь представь себе скорость работы железа того времени на вашей монорепе

N>>Ну вот это сходится с тем, что предполагает EM — сколько народу получило такую возможность только с приходом PC. А я ещё школьником видел и СМ-4, и СМ-1420, и ДВК, которые ещё в начале 80-х были, и всякие "Агаты", и побочные ответвления типа Электроники-85... (да, большинство PDP-11 в разных вариациях...) Да, это Киев, не совсем село, но и не Москва. Повторюсь — твой отец (и ты?) работали в каком-то совсем странном месте, если эти средства прошли мимо вас...

VD>Ты что-то там себе навыдумывал. СМ-1420 появилась в 1983-ем и была страшным говном. СМ-1420-1 с аж почти 2 мегами оперативки в 1985-м. А до людей это все доезжал еще позже. Ты еще расскажи мне историю, как на СМ-1420 (первого выпуска) работал коллектив из 100 человек.

100 не видел. Десяток — видел. В 86-м, кажется. Не сильно позже. А в чём проблема, если хватало терминалов?

VD> Не может и работали. Но выглядело это очень грустно. Каждому приходилось небольшой кусочек времени в дено, а то и в неделю.

100 человек по часу в неделю... ну может быть, а зачем на неё 100 человек грузить?
Десять редактирующих и 2-3 запуска одновременно — вполне реально.

VD>Я вот сейчас вспоминаю сколько мой отец притаскивал домой бумаги в виде распечаток. Его одна отладочная сессия стоила государству, наверное, в сотню баксов.

Машинное время на таком звере стоило 15-20 рублей в час. По честному курсу (4-5 рублей за доллар, а не мифический 0.6) — получается 4$. Отладочная сессия это сколько часов?

VD>В общем, ты как-то странно оцениваешь время и развитие. Вот появился СМ-1420 и все у всех он есть, все уже прогаммы коллективами в 1000 человек к нему разрабатывают. Но это же лажа. Говномашина с 128К оперативки работающая крайне медленно. Крайне дорогие носители памяти. Все это надо освоить. Переложить на программы то что раньше считали полуручным способом. Это все требовало времени. Наверно были те кто брался за все это большими коллективами, но они испытывали боль и имели крайне низкую эффективность. Потом люди тупо привыкли все делать по старым лекалам. Написать пару талмудов документации! Провести пару симпозиумов и конференций. А в итоге родить мышь.

Такая инерция есть и сегодня. Но это мало о чём говорит.
Ну да, у меня, возможно, аберрация, что университет. Там народ быстрее реагировал, ну и задачи, в основном всякие расчёты, перенести проще (основная проблема — разница в плавучке — это то, что IEEE 754 стабилизировал).

N>>Не надо высасывать из пальца то, чего ты не знаешь и не можешь знать. Могу. Я работал с бумагой и перфокартами.
VD>Ну, и сколько сотен человек было в твоей команде?

А при чём тут это?

N>>Вот с перфолентами не довелось, но видел их вплотную
VD>Я слава Богу с перфокартами только играл, а перфолентами только обматывался. Но по счастливому лицу отца сразу понял, что PC — это круто.

Потому что личное.
И опять же, нам раньше доставался кафедральный ДВК в схожем режиме.

VD> Потому и учился программировать на них. Но все это я видел. И у мет сомнений, что с современными методами это все сравнивать нельзя. Между ними пропасть. Ваши агилы сталы возможны только потому, что железо стало это позволять.

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

VD> Я вот комичу код и через пару часов получаю релиз продукта, который прошел тесты и проверяется тестерами. А мой отец вставал в очередь. Получал распечатку на следующий день и все выходные ее просматривал (длинна у них порой была адская). А я из ни потом разную херню мастерил. У нас производительность труда несопоставимая.

С таким подходом — естественно. А мы на ЕС-1022 в терминале правили код, запускали...
можно было и в файл заставить вывести и на терминале его просмотреть. Проблема — что в том же окне не получится, окна-то нет... поэтому чуть сложнее тривиального ляпа — таки печатали. За вечернюю смену можно было 3-4 цикла осилить нормально.
Сочувствую, что твоему отцу такого не давали, но такой режим со стокилометровой очередью уже ой был не обязательным.

N>>И им хватало еженедельных (например) бэкапов на бумаге и лентах.
VD>Если бы хватало, они бы их не создали. А они создали.
VD>Понимаешь, можно все делать дико через жопу. Например, можно копать траншеи лопатами.

Ты кэпствуешь о совершенно очевидном. Это и так понятно. Я говорю о принципиальной подъёмности. Проект сработал и обеспечил IBM баблом на десятилетия. ЧТД.

N>>Ты меня явно с EM перепутал. И он говорил не о частных случаях, он говорил об общей картине (статистически значимой) так, как он её видит, с несколькими иллюстрациями.
N>>Это принципиально. И вот насколько его видение адекватно — можно и нужно обсуждать, но не циклиться на примерах.
VD>Ну, так я понимаю ты его теорию и защищаешь.

1/10 от неё. Остальные 9/10 в моей позиции тебе померещились.

Здравствуйте, netch80, Вы писали:

N>Растёт. Мы тут на днях одну штуку тестировали... Corei 11-го поколения в 2 раза быстрее 4-го (Haswell) при даже меньшей частоте и лаптопе вместо десктопа. Не быстро растёт, да, но не остановился.

Мне кажется Вы говорите про многопоток, т.к. для однопотока прирост в районе 30% (это еще с учетом, что boost-овые частоты подросли):
https://www.cpubenchmark.net/compare/Intel-i7-4770K-vs-Intel-i7-11600H/1919vs4629

Лет 7 уже пользуюсь i7-4770, на нём одна из однопоточных задач выполняется 40 сек, на лаптопе с i7-11600H, около 27 сек.

Здравствуйте, 4058, Вы писали:

N>>Растёт. Мы тут на днях одну штуку тестировали... Corei 11-го поколения в 2 раза быстрее 4-го (Haswell) при даже меньшей частоте и лаптопе вместо десктопа. Не быстро растёт, да, но не остановился.

4>Мне кажется Вы говорите про многопоток, т.к. для однопотока прирост в районе 30% (это еще с учетом, что boost-овые частоты подросли):

Нет, одно-.
Ну, какая-то специфика влияет.

4>https://www.cpubenchmark.net/compare/Intel-i7-4770K-vs-Intel-i7-11600H/1919vs4629

4>Лет 7 уже пользуюсь i7-4770, на нём одна из однопоточных задач выполняется 40 сек, на лаптопе с i7-11600H, около 27 сек.

У меня тут Xeon E3-1220V3.

Здравствуйте, netch80, Вы писали:

N>"Научился использовать современные железки" вообще не относится к этому сравнению.
N>"Быстрее" — точно быстрее, если сравнить на _одинаковом_ железе?
Да, будет быстрее на одинаковом железе.
Потому, что умеет применять новые оптимизации — от компиляции запросов в натив и до применения эвристик вроде "в джойне участвует verified foreign key, поэтому кардинальность результата точно известна заранее".