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

C>>А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода.
DO>2 миллиарда строк говнокода. Наверное так точнее
Вот не надо. В Гугле каждый пакет принадлежит какой-то команде, которые ответственны за его поддержку. При этом регулярно делаются рефакторинги, затрагивающие всё дерево.

DO>Как в ДНК куча накопленного легаси, никто уже не помнит что это, зачем это, когда появилось, но трогать нельзя.
Это как раз лучше описывает пресловутые системы начала 80-х на КОБОЛе, которые до сих пор патчат эволюционными методами, так как всё поменять сразу нереально из-за наслоений геологических слоёв.

C>>И вот умение управлять развитием таких систем — это как раз достижение 90-х и 2000-х.
DO>Управлять развитием говнокода это безусловно достижение, особенно добиться при этом, чтобы целевой продукт не падал, не лагал и в полном объеме реализовывал свой функционал.
И вот насколько часто Гугл падает?

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

C>>В Шаттле объём исходного кода — около 400 тысяч строк. Это сейчас уровень небольшого проекта. В Windows — около 50 миллионов строк кода.
LVV>Система управления маленькая, но СЛОЖНАЯ.
Не особо. В смысле, делать её было, конечно, не просто (особенно с инструментами того времени). Но по нынешним меркам — не особо она и сложная. Сейчас с такой задачей справится небольшая группа товарищей за сравнительно небольшое время.

Если что, сейчас любители в свободное время делают спутники: https://upsat.gr/ — с системой ориентации и связи, тестовыми стендами, системой визуализации и т.п.

LVV>А винда не показатель. За 35 лет накопилось. Из которых сколько ненужных?
Большая часть нужна.

C>>А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода.
C>>И вот умение управлять развитием таких систем — это как раз достижение 90-х и 2000-х.
LVV>Ну, про 90-е ты загнул, тогда только интернет появился.
Тем не менее, опыт развития таких систем именно тогда и начал нарабатываться. В частности: необходимость итеративного развития и постоянного тестирования, дизайн отказоустойчивости на уровне систем, методы планирования разработки, и т.д.

Если грубо разделить по десятилетиям и выделить самое важное:
70-е и раньше — первобытно-общинный строй.
80-е — появление проектов, имеющих достаточно заметный размер.
90-е — множество реально крупных проектов и опыт управления ими, развитие полноценных языков, пригодных для больших систем.
00-е — совершенствование инструментов разработки (git, умные IDE) и методов управления (Agile Manifesto), понимание важности continuous integration.

10-е пока ещё только закончились, так что не очень понятно что именно самое важное для IT произошло.

LVV>И, наверное, можно как-то обозначить класс таких систем.
LVV>Распределенные?
То что они распределённые — это как раз не так важно. Та же Винда занимает около 50 миллионов строк кода, а с учётом установленных приложений вполне может за несколько сотен миллионов строк перевалить.

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

C>>А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода.
C>>И вот умение управлять развитием таких систем — это как раз достижение 90-х и 2000-х.
S>Это речь об agile или о чем? Я про управлять, а не писать.
Так agile — это как раз про управление.

До agile'а некоторые пытались пихать бред типа RUP'а (интересно, кого из участников тут в универе им мучали?).

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

DO>>Управлять развитием говнокода это безусловно достижение, особенно добиться при этом, чтобы целевой продукт не падал, не лагал и в полном объеме реализовывал свой функционал.
C>И вот насколько часто Гугл падает?
К чему этот вопрос? Я же вроде написал «это безусловно достижение», без иронии. Это реально достижение, чтобы всё это хозяйство не падало.

LVV>>Ну, про 90-е ты загнул, тогда только интернет появился.
C>Тем не менее, опыт развития таких систем именно тогда и начал нарабатываться. В частности: необходимость итеративного развития и постоянного тестирования, дизайн отказоустойчивости на уровне систем, методы планирования разработки, и т.д.
Просто изменился мир.
Вместо очень специализированной сферы деятельности компьютеры попали на каждый стол.
Попали на бытовой уровень. Персоналки и сети — два краеугольных камня, без которых больших проектов могло и не быть.
Отсюда и экономика: программы можно продавать ВСЕМ. А не только для специализированных научных и секретных институтов.
C>Если грубо разделить по десятилетиям и выделить самое важное:
C>70-е и раньше — первобытно-общинный строй.
Не забываем, что без этого "первобытно-общинного строя" не было бы ничего.
Родились unix и базы данных. Родилась ветка С-подобных языков.
Без БД просто не о чем говорить.
C>80-е — появление проектов, имеющих достаточно заметный размер.
IBM PC и развитие сетей...
C>90-е — множество реально крупных проектов и опыт управления ими, развитие полноценных языков, пригодных для больших систем.
Появился интернет, понятно. Ну, и Линукс.
Интересно, какие языки именно ты считаешь пригодными для разработки БОЛЬШИХ систем.
C>00-е — совершенствование инструментов разработки (git, умные IDE) и методов управления (Agile Manifesto), понимание важности continuous integration.
Ну, это уже современность
C>То что они распределённые — это как раз не так важно. Та же Винда занимает около 50 миллионов строк кода, а с учётом установленных приложений вполне может за несколько сотен миллионов строк перевалить.
То и удивительно — что там делают эти 50 лимонов строк...
Когда для полноценной работы пользователя в GUI вполне хватит и пары сотен тысяч...

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

C>>То что они распределённые — это как раз не так важно. Та же Винда занимает около 50 миллионов строк кода, а с учётом установленных приложений вполне может за несколько сотен миллионов строк перевалить.
LVV>То и удивительно — что там делают эти 50 лимонов строк...
LVV>Когда для полноценной работы пользователя в GUI вполне хватит и пары сотен тысяч...

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

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

LVV>Просто изменился мир.

На самом деле мир не изменился, как не странно.
А причина роста "сложности" (не difficult тут) состоит в правиле 20/80. То есть накручивание еще одной казалось бы никому не нужной рющечки приводит к увеличению "связей" в квадрате,я бы даже больше сказал — либо експоненциальная зависимость либо кубическая. )

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

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

C>Вот не надо. В Гугле каждый пакет принадлежит какой-то команде, которые ответственны за его поддержку. При этом регулярно делаются рефакторинги, затрагивающие всё дерево.

Гуголь адсоке говно стало — меня youtube с связке с хромкаст ультра (4К по 5Гц), выбешивает своими багами уже до иступления.

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

S>А это нереально сложно, что никто до этого не сделал? Вроде языку более 30 лет, а нормальных ide -- по пальцам.

Сейчас нормальная IDE это последний Kdevelop написан на с++, это единственная IDE которая не падая парсит современное ядро линукса с конфигами для навигации. )

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

C>>Тем не менее, опыт развития таких систем именно тогда и начал нарабатываться. В частности: необходимость итеративного развития и постоянного тестирования, дизайн отказоустойчивости на уровне систем, методы планирования разработки, и т.д.
LVV>Просто изменился мир.
Ну так он же не сам изменился

LVV>Вместо очень специализированной сферы деятельности компьютеры попали на каждый стол.
LVV>Попали на бытовой уровень. Персоналки и сети — два краеугольных камня, без которых больших проектов могло и не быть.
LVV>Отсюда и экономика: программы можно продавать ВСЕМ. А не только для специализированных научных и секретных институтов.
Да. Потому и пришлось разрабатывать способы делать программы не со стоимостью $1000 за строку кода (это примерно столько стоил код для Apollo 11, если что).

C>>Если грубо разделить по десятилетиям и выделить самое важное:
C>>70-е и раньше — первобытно-общинный строй.
LVV>Не забываем, что без этого "первобытно-общинного строя" не было бы ничего.
LVV>Родились unix и базы данных. Родилась ветка С-подобных языков.
LVV>Без БД просто не о чем говорить.
Ну так и без первобытно-общинного строя не было бы и дальнейшей цивилизации, с этим я не спорю.

C>>80-е — появление проектов, имеющих достаточно заметный размер.
LVV>IBM PC и развитие сетей...
Сети тогда ещё были в зародыше, и существенного влияния на индустрию не оказывали до конца 80-х.

C>>90-е — множество реально крупных проектов и опыт управления ими, развитие полноценных языков, пригодных для больших систем.
LVV>Появился интернет, понятно. Ну, и Линукс.
LVV>Интересно, какие языки именно ты считаешь пригодными для разработки БОЛЬШИХ систем.
В 90-е это C, С++ и Java. До этого были Фортран (на котором большие системы просто не написать), КОБОЛ (ноу комментс), PL/I (на котором вообще ничего нельзя писать), Паскаль (стандартный язык был ещё хуже Фортрана).

C>>00-е — совершенствование инструментов разработки (git, умные IDE) и методов управления (Agile Manifesto), понимание важности continuous integration.
LVV>Ну, это уже современность
Таки 10 лет назад.

C>>То что они распределённые — это как раз не так важно. Та же Винда занимает около 50 миллионов строк кода, а с учётом установленных приложений вполне может за несколько сотен миллионов строк перевалить.
LVV>То и удивительно — что там делают эти 50 лимонов строк...
LVV>Когда для полноценной работы пользователя в GUI вполне хватит и пары сотен тысяч...
Не хватит. Одна только реализация OpenGL занимает миллионы строк.

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

A>Оснащение рабочих мест компьютерами всегда делается исходя из нескольких соображений. Тому же инженеру-конструктору нужна была нормальная рабочая станция для работы с CAx-пакетами (CAD/CAE/CAM). Варианты чего-то приличного на x86-процессорах стали появляться лишь начиная с 1996-1997 годов. И это была новая веха, потому как ранее IBM PC не тянули даже серьёзных ОС и не годились на роль десктопа сопоставимого с рабочей станцией.

Я с 94-го года админил серваки на NT, которые были более чем сопоставимы с рабочими станциями от Sun'а. Так что, не надо тут про новые вехи заливать.

A>Если же имелись аппликейшен сервера приличные, на тех же UltraSPARC, то рабочие места инженеров можно было оснастить уже и IBM PC, для использования, по большей части, в роли терминалов — пробросив на эти десктопы через «иксы» тот софт, что выполняется реально на сервере.

Еще раз, кому эти аппсервера нужны были? Не в теории, а в реальности? Где были такие инженеры, которым не хватало возможностей x86?

A>Ни сколько не удивительно, что где так и сделали — серваки приличные поставили, а рабочие места сделали на базе x86-десктопов, но использовалось это всё через задницу.

Угу, не удивительно. Потому что на x86 уже были нормальные user-friendly ОС, а не убожества, с которыми нужно было страдать в случае "сантехники".

A>Именно потому что кому-то захотелось винду держать, а потребности в CAE/CAD/CAM реально не было. Поскольку компьютерная грамотность была почти нулевая и никто их толком не освоил.

Винду "кому-то" хотелось держать просто потому, что это было удобно и выгодно. А твои CAE/CAD/CAM — это мизерная доля рынка, которая большинству нафиг не нужна была.

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

L> Я с 94-го года админил серваки на NT, которые были более чем сопоставимы с рабочими станциями от Sun'а. Так что, не надо тут про новые вехи заливать.

А на кой лад сравнивать рабочие станции с серваками? Это чтобы не сравнивать x86-сервера с решениями на UltraSPARC?

L>Еще раз, кому эти аппсервера нужны были? Не в теории, а в реальности? Где были такие инженеры, которым не хватало возможностей x86?

Тем же, кому и сейчас — проектирование и обсчёт любых вещей связанных с жидкостями или газами. Как турбины для энергетики (гидравлические или паро-газового цикла), так и системы охлаждения прокачивающие воду/масло. Блоки управления электрическими машинами (генераторы, электродвигатели), типа тех асинхронных, на которые теперь весь транспорт перешёл. Разводка плат в схемотехники давно идёт программными пакетами, тоже именующимися САПР.

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

L>Угу, не удивительно. Потому что на x86 уже были нормальные user-friendly ОС, а не убожества, с которыми нужно было страдать в случае "сантехники".

Видеть доводилось компьютеризированные рабочие места? У инженера конструктора-проектировщика там две с половиной программы, каждая из которых сама по себе на операционку тянет по сложности и масштабам. Ему не документики в Excel'е шарашить и не отчёты в Word'е набирать.

L>Винду "кому-то" хотелось держать просто потому, что это было удобно и выгодно. А твои CAE/CAD/CAM — это мизерная доля рынка, которая большинству нафиг не нужна была.

Любой рынок делится на сегменты, непонимание этой элементарной вещи приводит к рассуждениям об очень ценных вещах, типа средней температуры по больнице.
На кой лад и кому были нужны компьютеризированные рабочие места в середине 90-х то? Интернета в РФ толком не было, за пределами инженерии ПК использовались лишь как замена печатной машинки и для ведения бухгалтерии с каталогом ассортимента товаров. Электронный документооборот в РФ не существовал как явление, а в мире стал появляться лишь к концу 1990-х (спасибо MS Exchange с его календарями и паблик фолдерами).

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

A>А на кой лад сравнивать рабочие станции с серваками? Это чтобы не сравнивать x86-сервера с решениями на UltraSPARC?

По цене они сопоставимы. По мощности тоже, так почему бы не сравнить?

A>Тем же, кому и сейчас — проектирование и обсчёт любых вещей связанных с жидкостями или газами. Как турбины для энергетики (гидравлические или паро-газового цикла), так и системы охлаждения прокачивающие воду/масло. Блоки управления электрическими машинами (генераторы, электродвигатели), типа тех асинхронных, на которые теперь весь транспорт перешёл. Разводка плат в схемотехники давно идёт программными пакетами, тоже именующимися САПР.

С научными расчетами понятно, хотя не понятно чем там поможет рабочая станция. Там вычислительный кластер скорее нужен.
Разводку плат, вроде, вполне успешно и на x86 делали и делают.

A>Видеть доводилось компьютеризированные рабочие места? У инженера конструктора-проектировщика там две с половиной программы, каждая из которых сама по себе на операционку тянет по сложности и масштабам. Ему не документики в Excel'е шарашить и не отчёты в Word'е набирать.

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

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

Спасибо кэп.

A>На кой лад и кому были нужны компьютеризированные рабочие места в середине 90-х то? Интернета в РФ толком не было, за пределами инженерии ПК использовались лишь как замена печатной машинки и для ведения бухгалтерии с каталогом ассортимента товаров. Электронный документооборот в РФ не существовал как явление, а в мире стал появляться лишь к концу 1990-х (спасибо MS Exchange с его календарями и паблик фолдерами).

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

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

D>Это всё было в Visual Studio .NET, и не только для Java и C#, правда только для Windows

Это как сказать, что паровая повозка 19 века ничем не отличается от Tesla Model S, она тоже умела передвигаться и у нее были колёса

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

I>Во все времена была Питерская и Московская IT-тусовка, IT-школа, и пр.

Нет

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

C>10-е пока ещё только закончились, так что не очень понятно что именно самое важное для IT произошло.

Облака,ml&dl,devops.

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

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

Эхх, современность.
А вот ты смотришь на всё это, и думаешь: а оно надо вообще?
Я вот смотрю на рюшечки современных BMW — HUD экран на ветровом стекле, ё-маё!
Насколько оно необходимо? Что, водитель не может ездить по старинке?
Очень много, что есть на белом свете, это просто мусор какой-то, не нужный.
Начали фары делать на основе LED. Как по мне, старые добрые галогеновые куда приятнее.

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

C>В Шаттле объём исходного кода — около 400 тысяч строк. Это сейчас уровень небольшого проекта. В Windows — около 50 миллионов строк кода.

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

C>А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода.
Ну неудивительно. Если толпы кодеров будут сидеть 20 лет, писать код. И ничего из этого не выбрасывается.
К концу столетия страшно подумать, сколько кода накопится.

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

J>Эхх, современность.
Старческое брюзжание?

J>А вот ты смотришь на всё это, и думаешь: а оно надо вообще?
Безопасность на дорогах? Да, нужна

J>Я вот смотрю на рюшечки современных BMW — HUD экран на ветровом стекле, ё-маё!
J>Насколько оно необходимо? Что, водитель не может ездить по старинке?
Простая статистика по количеству погибших и пострадавших в ДТП говорит, что да, надо.

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

J>Начали фары делать на основе LED. Как по мне, старые добрые галогеновые куда приятнее.
В чем проблема-то? Ездите на старом автомобиле, хоть на копейке

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

C>>В Шаттле объём исходного кода — около 400 тысяч строк. Это сейчас уровень небольшого проекта. В Windows — около 50 миллионов строк кода.
J>Не сравнивай код Шаттла и Винды.
Почему не сравнивать?

J>Винду могли писать хоть в дупель пьяные говнокодеры не просыхая, в то время как к Шаттлу совсем другие требования по надёжности. Вероятно, там ещё и формальная верификация проведена. А это значит, что собственно написание кода совершенно затмевается этой верификацией.
Верификации кода Шаттла не делалось. Делался тщательный review и тестирование на симуляторах.

C>>А реально сложные системы (типа сервисов Гугла или Амазона) уже перевалили за 2 миллиарда строк кода.
J>Ну неудивительно. Если толпы кодеров будут сидеть 20 лет, писать код. И ничего из этого не выбрасывается.
Выбрасывается, почему же. Просто объём функциональности постоянно растёт.

J>К концу столетия страшно подумать, сколько кода накопится.
Системы в триллион строк кода, которые будут управляться с помощью AI.