Здравствуйте, 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-й! И тогда это было чудом. А сейчас в любом сразном Боинге или Аэрбасе система автоматической посадки, которой хлопают разные дебилы при посадке.