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

SVZ>>стоит вспомнить, что умел гуй 30 лет назад (про 70-е говорить нечего) и сейчас.

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

Это смешно. Сравни PCAD и Altium 19


SVZ>>Благодаря современным мощностям и объемам памяти появилась возможность что-то предвычислять и перестраивать в фоне, пока пользователь пытается чего-то напечатать/нарисовать.

ЕМ>Вы удивитесь, но это было и в 70-е. И параллельные процессы тогда тоже были.

Тогда был только PCAD. С кучей отдельных тулзей, которые надо было правильно запускать и перезапускать


SVZ>>Всякий Intellicence, Autocomplete.

ЕМ>Autocomplete тогда делали в основном для командных строк.

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


ЕМ>Вещей, подобных IntelliSense, не делали просто потому, что не было такого зоопарка в API и библиотеках, как сейчас. Для повседневной работы вполне хватало конспекта из нескольких десятков листов, для сложных вещей приходилось доставать из шкафа пару-тройку томов документации. А исчерпывающий справочник по системе команд PDP-11 вообще умещался на складной картонке, которую можно было носить в кармане.

А без этого зоопарка API и библиотек ничего и не было бы. Ты можешь и сейчас доки в шкафу хранить. Я вот купил печатный C++ Std, храню в шкафу. Чисто по приколу, потому что погуглить таки быстрее


SVZ>>То, что раньше делалось в формате "запустил задачу и пошел курить" сейчас превратилось в настоящее интерактивное редактирование.

ЕМ>В 70-е было полноценное интерактивное редактирование в реальном времени. А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4. Это не было запредельно сложной задачей — скорее баловством. Будь в этом необходимость — добавил бы туда и AutoComplete, и IntelliSense, делов-то.

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


SVZ>>Т.е. сложность и возможности гуя выросли на несколько порядков.

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

Не были реализованы по причине невозможности с теми ресурсами


SVZ>>Если раньше гуй был ориентирован на профи, требующий предварительного обучения

ЕМ>Это который гуй был так ориентирован?

PCAD, например. Мы его два семестра изучали. Правда, там гуя-то не особо и было. А сейчас Альтиум запустил, и за семестр можно материнку для современного пентиума сделать — у меня так знакомый сделал в качестве хобби, да далеко и тут ходить не надо — вон, koandrew тоже платы с плисами и пятыми ддр чуть ли на не террагерцных частотах как пирожки штампует

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

M>Глянул в вики про IBM 360 — там на всю машину 4 метра оперативы в топовых моделях

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

M>и 10К kIPS — я так понял — это кило инструкции пер секунда.

Это младшие модели.

На 4х метрах, конечно, и винда 95ая как-то работала (правда проц пошустрее нужен, раз так в десятки тыщ раз) — но и 95ую с её прямым Хэ с современными технологиями не сравнить.

Что именно Вы знаете в современных технологиях, для чего объективно недостаточно 95-й винды?

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

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

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

M>>Глянул в вики про IBM 360 — там на всю машину 4 метра оперативы в топовых моделях

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


Да и наплевать. Я раньше на WTL писал, а сейчас на кути. На кути быыстрее. Правда, простая тулза, висящая в трее, не 300 Кб, а 15 метров, но и фик с ним


ЕМ>На 4х метрах, конечно, и винда 95ая как-то работала (правда проц пошустрее нужен, раз так в десятки тыщ раз) — но и 95ую с её прямым Хэ с современными технологиями не сравнить.

ЕМ>Что именно Вы знаете в современных технологиях, для чего объективно недостаточно 95-й винды?

Не большой спец в современных технологиях. Но и чтобы из новых процов и видях выжимать максимум, 95ой недостаточно. Можно, условно говоря, дописать её, тогда 10ка и получится


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

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

Твой хелло ворд будет уметь современный C++ собирать, и предоставлять для него инструментарий, даст возможность для языкописателей ограничится написанием только фронт-энда?

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

M>Это смешно. Сравни PCAD и Altium 19

Смешно — это считать, будто любой продукт определенной эпохи всегда сделан оптимально для технологий этой эпохи. Давайте сравним штатовские автомобильные движки 60-х, про которые "заглушите двигатель, иначе полный бак никогда не наберется", с движками 40-х, а потом с движками хотя бы 80-х. Когда в 60-е американцам говорили, что двигатель не должен столько жрать, они доказывали, что технически невозможно получить те же мощности при меньшем расходе. И что получилось в итоге?

M>Тогда был только PCAD. С кучей отдельных тулзей, которые надо было правильно запускать и перезапускать

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

ЕМ>>Autocomplete тогда делали в основном для командных строк.

M>Потому что только для этого и могли.

Могли для чего угодно. Надобности особой не было.

M>А без этого зоопарка API и библиотек ничего и не было бы.

Чего именно не было бы, и почему именно?

M>IntelliSense — это не сферический конь в вакууме, а автодополнение к вводимому на основе контекста. Не, ну для бейсика, в котором нет структур — может и сделал бы.

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

ЕМ>>Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.

M>Не были реализованы по причине невозможности с теми ресурсами

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

SVZ>>>Если раньше гуй был ориентирован на профи, требующий предварительного обучения
ЕМ>>Это который гуй был так ориентирован?

M>PCAD, например.

Это проблема PCAD, а не гуя.

M>А сейчас Альтиум запустил, и за семестр можно материнку для современного пентиума сделать — у меня так знакомый сделал в качестве хобби, да далеко и тут ходить не надо — вон, koandrew тоже платы с плисами и пятыми ддр чуть ли на не террагерцных частотах как пирожки штампует

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

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

M>Да и наплевать. Я раньше на WTL писал, а сейчас на кути. На кути быыстрее. Правда, простая тулза, висящая в трее, не 300 Кб, а 15 метров, но и фик с ним

"Не плюй в колодец — вылетит, не поймаешь". Ибо сперва — "наплевать" и "фик с ним", а потом — "какого хера эта фигня не встает на мой пятилетний комп, а на трехлетнем требует апгрейда?".

M>Не большой спец в современных технологиях.

Возможно, тогда и уверенность суждений следовало бы снизить?

M>Но и чтобы из новых процов и видях выжимать максимум, 95ой недостаточно.

Единственное, чего в 95-й действительно недостаточно — это поддержки многопроцессорности. В принципе, она достаточно проста, но должна присутствовать во всем ядерном коде, включая сторонний. В NT она есть. А все остальное — вишенки на торте, ускорение сугубо отдельных процессов в отдельных приложениях.

M>Можно, условно говоря, дописать её, тогда 10ка и получится

В десятке нет ничего принципиально нового по сравнению с NT3.5 (начало 90-х). Если совсем немного подпилить старые NT, чтоб умели программировать современные северные/южные мосты на том уровне, что достаточен для их работы, опять же немного адаптировать драйверы железа, то разница в производительности составит 10-20% для обычных приложений, и в несколько раз — для тех, что используют поддержку в ОС особенностей железа вроде NUMA.

M>Твой хелло ворд будет уметь современный C++ собирать, и предоставлять для него инструментарий, даст возможность для языкописателей ограничится написанием только фронт-энда?

Не будет, конечно. Но и у LLVM и близко нет функциональности, для которой необходимы 120 Мб кода/данных.

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

M>>Это смешно. Сравни PCAD и Altium 19

ЕМ>Смешно — это считать, будто любой продукт определенной эпохи всегда сделан оптимально для технологий этой эпохи. Давайте сравним штатовские автомобильные движки 60-х, про которые "заглушите двигатель, иначе полный бак никогда не наберется", с движками 40-х, а потом с движками хотя бы 80-х. Когда в 60-е американцам говорили, что двигатель не должен столько жрать, они доказывали, что технически невозможно получить те же мощности при меньшем расходе. И что получилось в итоге?

1) А они доказывали?
2) А при тех технологиях можно было сделать намного лучше?


M>>Тогда был только PCAD. С кучей отдельных тулзей, которые надо было правильно запускать и перезапускать

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

У тебя есть другие версии?



ЕМ>>>Autocomplete тогда делали в основном для командных строк.

M>>Потому что только для этого и могли.

ЕМ>Могли для чего угодно. Надобности особой не было.

Почему не было? И откуда она сейчас появилась?



M>>А без этого зоопарка API и библиотек ничего и не было бы.

ЕМ>Чего именно не было бы, и почему именно?

M>>IntelliSense — это не сферический конь в вакууме, а автодополнение к вводимому на основе контекста. Не, ну для бейсика, в котором нет структур — может и сделал бы.

ЕМ>И что же в 70-х мешало парсить в реальном времени сишный текст, кроме лени? Или Вы думаете, что это было запредельно сложно для тех времен?

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



ЕМ>>>Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.

M>>Не были реализованы по причине невозможности с теми ресурсами

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

Во-первых, я бы поспорил насчет возможности, но лень. Во-вторых — ну, сделай мне альтиум 19 на PC XT. Это я про целесообразность. Ты 50 лет на это потратишь, но так и не сделашь



M>>А сейчас Альтиум запустил, и за семестр можно материнку для современного пентиума сделать — у меня так знакомый сделал в качестве хобби, да далеко и тут ходить не надо — вон, koandrew тоже платы с плисами и пятыми ддр чуть ли на не террагерцных частотах как пирожки штампует

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

Только делать ты будешь в сотни раз медленнее, и работать оно будет также медленнее.

ЗЫ Я самоудаляюсь из этого спора, он не имеет смысла

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

M>>Твой хелло ворд будет уметь современный C++ собирать, и предоставлять для него инструментарий, даст возможность для языкописателей ограничится написанием только фронт-энда?

ЕМ>Не будет, конечно. Но и у LLVM и близко нет функциональности, для которой необходимы 120 Мб кода/данных.

Вообще-то я про 120 Гб писал. Но я лишние obj/ilk/etc поудалял, стало поменьше. PDB очень много места занимают. В целом, конечно, в релиз пойдёт размером мегабайты, но эти гигабайты необходимы для нормальной работы с LLVMовскими либами в процессе разработки.

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

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

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

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

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

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

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

SVZ>>стоит вспомнить, что умел гуй 30 лет назад (про 70-е говорить нечего) и сейчас.

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

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

SVZ>>Благодаря современным мощностям и объемам памяти появилась возможность что-то предвычислять и перестраивать в фоне, пока пользователь пытается чего-то напечатать/нарисовать.

ЕМ>Вы удивитесь, но это было и в 70-е. И параллельные процессы тогда тоже были.

Надо смотреть не на то, что доступно было 0.1%, а на то, что доступно было хотя бы 50% пользователей компьютеров (которых самих тогда было ничтожное количество). А там ресурсы были жесточайше ограничены. Младшие S/360, например, выпускались с памятью объёма 8KB. PDPшки первые получали ещё меньше. Дисплейная установка стоила как самолёт, остальные пользовались перфокартами (в лучшем случае). Apple II за 1300$ (тогдашних!) — игрушка для богачей, параллельности на ней не водилось. Windows 2.x с кооперативной многозадачностью — предел технологий 80-х для широкой публики.
Техника, которая в 70-е позволяла параллельно что-то запускать... да никто её не использовал для тех же CAD, например. Кроме редчайших случаев — не окупалось. Почитайте историю Intel, например. Микросхемы чертили вручную.

SVZ>>Всякий Intellicence, Autocomplete.

ЕМ>Autocomplete тогда делали в основном для командных строк.

В 70-х его не было. Теоретические работы появились в 80-х. Первые реальные реализации это уже 90-е. Один из первых примеров в мире Unix и вокруг, это не bash, по которому все знают эту фичу — это Cisco IOS командная строка. Её пример вдохновил на развитие подобных фич в B-шеллах (bash, zsh) и C-шеллах (tcsh). В мире Windows ещё на десяток лет позже.
В 70-х был хилый закос в виде возможности сокращать операторы (а то и принудительно сводить в одну букву, как в FOCAL). Но там это действовало без выбора и подсказки вариантов.

EM> Вещей, подобных IntelliSense, не делали просто потому, что не было такого зоопарка в API и библиотеках, как сейчас. Для повседневной работы вполне хватало конспекта из нескольких десятков листов, для сложных вещей приходилось доставать из шкафа пару-тройку томов документации. А исчерпывающий справочник по системе команд PDP-11 вообще умещался на складной картонке, которую можно было носить в кармане.

По любой ISA времён условно до 1980 можно было свести в одну картонку, и что?
А про зоопарк — почитайте-ка, например, справочник по макрам ввода-вывода OS/360. Не уместите вы это на одной картонке, как ни старайся. Вот там объективная сложность.

SVZ>>То, что раньше делалось в формате "запустил задачу и пошел курить" сейчас превратилось в настоящее интерактивное редактирование.
ЕМ>В 70-е было полноценное интерактивное редактирование в реальном времени.

Где это оно такое было?
Даже на дисплейных комплексах какой-нибудь старшей PDP-11 нужно было вначале сохранить файл, и только тогда компилировать можно было.

EM> А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4. Это не было запредельно сложной задачей — скорее баловством. Будь в этом необходимость — добавил бы туда и AutoComplete, и IntelliSense, делов-то.

Ты половинку 80-х уточни-то. Это явно не первая.

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

Да. И сейчас придумывают много идей, которые полноценно реализуются ой не скоро. И что?

SVZ>>Правда, последние лет десять я что-то не вижу серьезной научной работы в гуестроении
ЕМ>А какие еще есть актуальные и нерешенные проблемы в обычным двумерном гуе? Серьезная работа начнется, когда появятся массовые устройства, управляемые движениями глаз, или вообще силой мысли.

Ну вот.

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

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

ЕА>>У меня на спектруме экран был 192 на 256 пикселов с глубиной 1 бит.

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

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

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

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

ЕМ>>Когда в 60-е американцам говорили, что двигатель не должен столько жрать, они доказывали, что технически невозможно получить те же мощности при меньшем расходе.

M>1) А они доказывали?

Научно, разумеется, не доказывали, но позицию занимали примерно такую же: "а где ты видел меньше? а ты сам сделай лучше!".

M>2) А при тех технологиях можно было сделать намного лучше?

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

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

M>У тебя есть другие версии?

Зачем версии, если есть очевидное объяснение? Во-первых, математика автоматической компоновки и разводки многослойных плат создавалась не одномоментно, а поэтапно. Во-вторых, в те времена никому просто не приходило в голову, что стоит тратить ресурсы на создание системы, с помощью которой плату профессионального уровня сможет делать каждый любитель (это касается и современных IDE, позволяющих накидать компонент на форму и получить заготовки кода). Компоновка/разводка платы тогда была далеко не самым затратным этапом производства.

ЕМ>>Могли для чего угодно. Надобности особой не было.

M>Почему не было?

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

M>И откуда она сейчас появилась?

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

ЕМ>>И что же в 70-х мешало парсить в реальном времени сишный текст, кроме лени?

M>думаю, в те времена даже думать о таких возможностях было из разряда фантастики

У Вас крайне примитивные представления о тогдашних возможностях.

M>ну, сделай мне альтиум 19 на PC XT.

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

M>Только делать ты будешь в сотни раз медленнее

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

M>и работать оно будет также медленнее.

Ну разумеется, коли все нынешнее железо на порядки быстрее тогдашнего. Но, как я уже говорил — медленнее будет, но не в такой пропорции.

M>ЗЫ Я самоудаляюсь из этого спора, он не имеет смысла

Это потому, что Вы упорно принимаете [не]целесообразность за [не]возможность.

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

M>Вообще-то я про 120 Гб писал. Но я лишние obj/ilk/etc поудалял, стало поменьше.

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

M>в релиз пойдёт размером мегабайты, но эти гигабайты необходимы для нормальной работы с LLVMовскими либами в процессе разработки.

Гигабайты не являются необходимыми. Единиц-десятков мегабайт хватило бы по уши.

M>На твоей любимой IBM/360

Она никогда не была моей любимой. Мне больше нравилась БЭСМ-6, но ее так и не довели до уровня 360/370 по универсальности железа и софта.

M>что-то подобное за разумное время ну никак не собрать.

Вы постоянно соотносите ресурсы, потребляемые сегодня, с имевшимися тогда. Это принципиально некорректно, поскольку известно, что бОльшая часть современного ПО многократно избыточна по ресурсам. Это примерно, как утверждать, что ЭВМ невозможно питать от батареи. Ту совокупность железа, что называлась "ЭВМ" в 70-е, действительно невозможно, а ту, что эквивалентна ей по возможностям — легко.

Хозяйке на заметку: в 70-е были реализованы компиляторы с Алгол-68, который по тем временам выглядел куда круче, чем сейчас C++20. И программы компилировались отнюдь не часами.

M>Время сборки исчислялось бы тысячелетиями, если бы перфоленты быстро бы подвозили

Почему именно перфоленты, а не "тысяча негров на переключателях"?

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

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

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

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

N>GUI хотело большинство

Я никогда не говорил, будто бы GUI не хотели. Его хотели, но сугубо в той части, что облегчает работу, а не услаждает взор.

N>Но ресурсы не позволяли.

Ресурсы позволяли делать адекватный GUI, и его делали.

N>Сейчас всяких свистелок в гуе не так-то и много, наоборот, их сокращают.

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

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

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

N>Windows 2.x с кооперативной многозадачностью — предел технологий 80-х для широкой публики.

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

N>Техника, которая в 70-е позволяла параллельно что-то запускать... да никто её не использовал для тех же CAD, например. Кроме редчайших случаев — не окупалось. Почитайте историю Intel, например. Микросхемы чертили вручную.

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

ЕМ>>Autocomplete тогда делали в основном для командных строк.

N>В 70-х его не было. Теоретические работы появились в 80-х.

Какие еще "теоретические работы"? Это отнюдь не высшие области науки, чтобы практическим реализациям непременно предшествовала теория. Такие вещи очень давно делались на банальной интуиции.

N>Первые реальные реализации это уже 90-е.

У Вас очень превратные представления. Мы с парнями чисто по приколу делали такое в 80-е, а на 360/370 оно делалось и в 70-е.

N>Один из первых примеров в мире Unix и вокруг, это не bash, по которому все знают эту фичу — это Cisco IOS командная строка. Её пример вдохновил на развитие подобных фич в B-шеллах (bash, zsh) и C-шеллах (tcsh).

Это в Unix-мире, который всегда развивался обособленно от остальных.

N>В мире Windows ещё на десяток лет позже.

Какой еще Windows? Это было в ряде сторонних интерпретаторов и в DOS, и в CP/M. Даже у ранних Apple было, если не ошибаюсь.

N>В 70-х был хилый закос в виде возможности сокращать операторы (а то и принудительно сводить в одну букву, как в FOCAL). Но там это действовало без выбора и подсказки вариантов.

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

N>А про зоопарк — почитайте-ка, например, справочник по макрам ввода-вывода OS/360.

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

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

N>Где это оно такое было?

На тех же 360/370, на Burroughs, на БЭСМ-6, еще на нескольких советских машинах, не столь известных. На PDP мы этим пользовались в начале 80-х, а сделано было, судя по всему, в конце 70-х.

N>Даже на дисплейных комплексах какой-нибудь старшей PDP-11 нужно было вначале сохранить файл, и только тогда компилировать можно было.

Интерактивное редактирование не предполагает параллельной компиляции. А если бы она и потребовалась — в чем проблема реализовать? Сохранить файл в фоне, запустить компилятор параллельным процессом, получить от него таблицы идентификаторов, зависимости и прочее — не нужно для этого ни сверхбыстродействия, ни огромной памяти. Я до сих пор пользуюсь VS 2008 на трехгигагерцовом процессоре и SSD, так и у нее IntelliSense нередко притормаживает на несколько секунд — приходится ждать, пока прожует.

EM>> А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4.

N>Ты половинку 80-х уточни-то. Это явно не первая.

87-й год, а какая разница-то? Машинка эта разработана в 70-е, в СССР ее стали делать в начале 80-х. Попади она ко мне году в 82-м — сделал бы и тогда, не вижу проблемы.

N>И сейчас придумывают много идей, которые полноценно реализуются ой не скоро. И что?

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

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

N>Ну вот.

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

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

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

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

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

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

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

ЕМ>И что же в 70-х мешало парсить в реальном времени сишный текст, кроме лени? Или Вы думаете, что это было запредельно сложно для тех времен?
В основном — нехватка памяти. И её быстродействие. На тогдашних машинках несложные С-программы компилировались минутами.
И из этого времени кодогенерация, собственно, занимала не так много времени. Так что я что-то не особо верю в autocomplete с учётом контекста даже на XT-шках.
А если мы говорим о 70х, то лучшие компьютеры того времени для многооконного гуя выдавали пару кадров в секунду.
Банальное перетаскивание окна с содержимым появилось в Win98, как часть windows plus pack. До этого все изменения размеров и положения выполнялись при помощи рамочки.
Потому, что быстродействия-с не хватало.

Читаем очевидцев:

The animations on the NOVA ran 3-5 objects at about 2-3 frames per second. Fast enough for the phi phenomenon to work (if double buffering was used), but we wanted "Disney rates" of 10-15 frames a second for 10 or more large objects and many more smaller ones. This task was put into the ingenious hands of Steve Purcell. By the fall of '73 he could demo 80 ping-pong balls and 10 flying horses running at 10 frames per second in 2½D.

ЕМ>>>Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.
А ещё очень многие идеи были отложены до наступления Закона Мура:

I spent the rest of the conference calculating just when the silicon of the FLEX machine could be put on the back of the display. According to Gordon Moore's "Law", the answer seemed to be sometime in the late seventies or early eighties. A long time off—it seemed too long to worry much about it then.

ЕМ>Не "невозможности", а "нецелесообразности". Тогда особо не было лишних ресурсов, которые нужно было забить хоть чем-нибудь, дабы показать результат. То, в чем была реальная необходимость, делалась, если это не было совсем уж затратным.
А то. Не было необходимости в WYSIWYG — не делали. Не было необходимости делать "navigate to definition" — не делали.
Необходимость — это такая интересная штука. Как-то ведь люди жили и без компьютеров, так? Эйфель, скажем, свою башню рассчитал без единого компьютера. Так что, скажем, в CAD-системах необходимости нет.
Другое дело, что с ними всё происходит заметно быстрее и дешевле.
Точно так же и все инструменты разработчика — от autocomplete до подсветки статуса тестов в gutter-е. Какие там "прогоны всех тестов, на которые может повлять это изменение, по нажатию правой кнопки мыши", о чём вы?
Получил свои 10 минут машинного времени — и будь счастлив, если тебе самому разрешили перфокарты загружать. Потому что если там ошибка, то можно быренько лишние дырки заклеить, и новые проколупать — и по новой запихать колоду в читалку. А если у тебя колоду оператор забрал — то всё, он при первой же ошибке её в сторонку отложит и чью-то другую задачу делать будет.

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

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

N>>Но ресурсы не позволяли.
ЕМ>Ресурсы позволяли делать адекватный GUI, и его делали.

Адекватный — это 320x200 с 4 цветами и неизбежно вырвиглазными шрифтами (в лучшем случае уложенными в матрицу 7*5)? Ну да, что-то передать в таком формате можно. Но "адекватным" гуём это можно назвать только в шутку (в лучшем случае).

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

Так вот — это (частичный) возврат типового гуя к уровню 1995-2000. Но не 1970-х. Между ними разница около 1000 раз по ресурсам всех видов. И то — размер экрана меньше 1600 пикселов по ширине сейчас уже в рамках неприличия, потому что фиг что отобразишь, 4096 уже норма, 8K на подходе в массы.
А на ресурсах 1970-х сейчас никто не согласится даже базовые вещи реализовывать.

N>>Надо смотреть не на то, что доступно было 0.1%, а на то, что доступно было хотя бы 50% пользователей компьютеров (которых самих тогда было ничтожное количество).
ЕМ>О том и речь, что дорогие решения внедрялись только там, где это было целесообразно. Подход "давайте это сделаем просто потому, что можем" применяется только в ситуации переизбытка ресурсов.

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

N>>Windows 2.x с кооперативной многозадачностью — предел технологий 80-х для широкой публики.

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

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

N>>Техника, которая в 70-е позволяла параллельно что-то запускать... да никто её не использовал для тех же CAD, например. Кроме редчайших случаев — не окупалось. Почитайте историю Intel, например. Микросхемы чертили вручную.
ЕМ>Прежде всего потому, что для подобных изменений должна накопиться критическая масса знаний, опыта, технологий. И лишь потом — ресурсов для вычисления и хранения.

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

ЕМ>>>Autocomplete тогда делали в основном для командных строк.
N>>В 70-х его не было. Теоретические работы появились в 80-х.
ЕМ>Какие еще "теоретические работы"? Это отнюдь не высшие области науки, чтобы практическим реализациям непременно предшествовала теория. Такие вещи очень давно делались на банальной интуиции.

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

N>>Первые реальные реализации это уже 90-е.
ЕМ>У Вас очень превратные представления. Мы с парнями чисто по приколу делали такое в 80-е, а на 360/370 оно делалось и в 70-е.

Я не помню такого на 360/370. А то, что вы "с парнями чисто по приколу" делали, оно было как, умело хотя бы подсказать, каким нескольким командам соответствует данный префикс?

N>>Один из первых примеров в мире Unix и вокруг, это не bash, по которому все знают эту фичу — это Cisco IOS командная строка. Её пример вдохновил на развитие подобных фич в B-шеллах (bash, zsh) и C-шеллах (tcsh).
ЕМ>Это в Unix-мире, который всегда развивался обособленно от остальных.

Не было никакого обособления, идеи свободно кочевали туда-сюда, особенно вокруг открытых систем, как Unix.

N>>В мире Windows ещё на десяток лет позже.
ЕМ>Какой еще Windows? Это было в ряде сторонних интерпретаторов и в DOS, и в CP/M. Даже у ранних Apple было, если не ошибаюсь.

Расскажите, как именно оно там работало. А то ой сомневаюсь.

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

N>>Где это оно такое было?

ЕМ>На тех же 360/370, на Burroughs, на БЭСМ-6, еще на нескольких советских машинах, не столь известных. На PDP мы этим пользовались в начале 80-х, а сделано было, судя по всему, в конце 70-х.

И как оно выглядело?

N>>Даже на дисплейных комплексах какой-нибудь старшей PDP-11 нужно было вначале сохранить файл, и только тогда компилировать можно было.

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

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

EM>>> А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4.

N>>Ты половинку 80-х уточни-то. Это явно не первая.

ЕМ>87-й год, а какая разница-то? Машинка эта разработана в 70-е, в СССР ее стали делать в начале 80-х. Попади она ко мне году в 82-м — сделал бы и тогда, не вижу проблемы.

Читаю: варианты исполнения: 16K, 32K, 128K.
В 70-е даже 32K в калькуляторе было неподъёмно.

N>>И сейчас придумывают много идей, которые полноценно реализуются ой не скоро. И что?

ЕМ>То, что для реализации большинства этих идей вполне достаточно имеющихся ресурсов.

Интересное обобщение. Но не вижу для него причин.

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

N>>Ну вот.

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

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

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

M>Элементарно. Глянул в вики про IBM 360 — там на всю машину 4 метра оперативы в топовых моделях и 10К kIPS — я так понял — это кило инструкции пер секунда.

Тут что-то не то, 10kIPS это как раз самые младшие модели, память которых начиналась от 8KB. У топовых этих самых инструкций получалось под миллион.

M> Ну это да — середина 60ых — начало 70ых, в 82ом году, когда спектрум выпустили, наверно было получше. На 4х метрах, конечно, и винда 95ая как-то работала (правда проц пошустрее нужен, раз так в десятки тыщ раз) -

Скорее просто в тысячу от младших и раз в 20-50 от топовых.

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

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

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

ЕМ>Она никогда не была моей любимой. Мне больше нравилась БЭСМ-6, но ее так и не довели до уровня 360/370 по универсальности железа и софта.

БЭСМ-6 — тупая кривуля. Одно отсутствие целочисленной арифметики чего стоит (да, я знаю про режим "0 цифр после запятой"). 16-битное "окно в мир" там, где давно пора сделать было шире адрес. (Да, точно так же было на PDP-11, но PDP-11 заявлялась как мини- и микро-ЭВМ, а не полноценная!) Ну и вообще 100500 глупостей в системе команд, и вокруг...
Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё. Да сейчас её какой-нибудь 8051 победит как лежачую.
Ностальгировать по этому смысла просто ноль целых фиг десятых.

ЕМ>Хозяйке на заметку: в 70-е были реализованы компиляторы с Алгол-68, который по тем временам выглядел куда круче, чем сейчас C++20. И программы компилировались отнюдь не часами.

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

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

S>На тогдашних машинках несложные С-программы компилировались минутами.

Это очень сильно зависело от реализации компилятора. Если компилятор делался "по науке", в расчете на абстрактную бесконечную программу любой сложности, и независимо применял лексический и синтаксический анализ, трансляцию в промежуточный код, генерацию двоичного кода и т.п., использовал виртуальную память потенциально неограниченного объема для работы с любыми динамическими структурами, то он, разумеется, нещадно тормозил, главным образом на этой самой виртуальной памяти и переходах между слоями абстракции. А если его делали в расчете на типовые, наиболее часто встречающиеся программы, то мог успевать и за секунды.

S>И из этого времени кодогенерация, собственно, занимала не так много времени. Так что я что-то не особо верю в autocomplete с учётом контекста даже на XT-шках.

Для реализации autocomplete нет нужды прогонять по тексту полноценный синтаксический анализ, достаточно самого примитивного. Здесь очень хорошо работает "правило 80/20".

S>А если мы говорим о 70х, то лучшие компьютеры того времени для многооконного гуя выдавали пару кадров в секунду.

Гораздо больше, да и то в чистой, пиксельной графике. Которая для GUI вовсе не обязательна. Символьные дисплеи давали десятки операций в секунду.

S>Банальное перетаскивание окна с содержимым появилось в Win98, как часть windows plus pack. До этого все изменения размеров и положения выполнялись при помощи рамочки.
S>Потому, что быстродействия-с не хватало.

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

S>

S>The animations on the NOVA ran 3-5 objects at about 2-3 frames per second.

Это об анимации произвольных объектов, к чему это здесь? Мы вроде не обсуждали игры и мультики.

S>Не было необходимости в WYSIWYG — не делали.

WYSIWYG делали еще в 60-е. "Жопа есть, а слова нет".