Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, jamesq, Вы писали:
ЕМ>>>И что из этого было технически невозможно в 70-е?
J>>Хотя бы развитый GUI?
ЕМ>GUI в те времена вполне себе существовал — с управлением через трекбол, световое перо, или просто стрелки навигации. Не такой навороченный, как сейчас, но это чисто количественная разница, никак не объясняющая рост требований к ресурсам на несколько порядков.
У меня на спектруме экран был 192 на 256 пикселов с глубиной 1 бит. = 6144 байт + цвета задавались на каждый квадратик 8x8 — это еще 768 байт итого 6912 байт
Сейчас у меня 2 монитора 3840 на 2160 с глубиной цвета 3 байта на пиксел = 49 766 400 байт
это в 7200 раз больше (!) — и это мы сравниваем с безумной по тем временам роскошью — графическим режимом.
В 90-е большая часть GUI работала в текстовом режиме
Здравствуйте, vsb, Вы писали:
vsb>Современный программист без интернета программировать не может в любом случае.
Я могу программировать без интернета, пока не возникнет проблемы, трудноразрешимой с имеющейся информацией. Для разрешения можно воспользоваться интернетом, но далеко не всегда там можно найти решение. Своими силами решение можно найти всегда, но это может потребовать неприемлемого времени.
Но во многих случаях таких проблем не возникает, и интернет может не потребоваться вообще.
Re[6]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
ЕМ>>А старый одновременно перестали и выпускать, и поддерживать?
M>Выпускать — да, перестали. Такое бывает. M>Поддерживать — это как?
Например, разыскали старые версии по всем складам, и уничтожили их. Или в старой версии были глюки, с которыми ее было невозможно использовать, и они были исправлены одновременно с переходом на новую версию.
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>А старый одновременно перестали и выпускать, и поддерживать?
M>>Выпускать — да, перестали. Такое бывает. M>>Поддерживать — это как?
ЕМ>Например, разыскали старые версии по всем складам, и уничтожили их. Или в старой версии были глюки, с которыми ее было невозможно использовать, и они были исправлены одновременно с переходом на новую версию.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>На ардуинке делал скетч, чтобы шаговиком шагать. Получилось выжать шагов 200 в минуту.
ЕМ>Как-то совсем уж мало, это чуть больше трех шагов в секунду, или пять миллионов команд на шаг. Там точно все было минимизировано?
Да, мало. Там, правда, ещё было сканирование матричной клавы, логика меню и дисплей 1602, но сути это особо менять не должно. Ну и само собой, всё было сделано на ардуиновских либах, ничего я там не оптимизировал.
А на STM — у меня всё своё было, три шаговика, с обсчётом перемещения по трем осям, с учетом ускорений, и выдавало 5-6 килогерц на каждый движек
Здравствуйте, Евгений Музыченко, Вы писали:
ЕА>>У меня на спектруме экран был 192 на 256 пикселов с глубиной 1 бит.
ЕМ>Вы действительно полагаете, что во времена спектрумов другой вычислительной техники не существовало?
Во времена поздних спектрумов — существовало. Когда он только появился — было сильно похуже
Здравствуйте, Marty, Вы писали:
ЕМ>>Вы действительно полагаете, что во времена спектрумов другой вычислительной техники не существовало?
M>Во времена поздних спектрумов — существовало. Когда он только появился — было сильно похуже
Вы тоже никогда не слышали об IBM 360/370, БЭСМ-6 и прочих серьезных системах?
Re[6]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
M>Не понял, а причем тут какая-то поддержка?
При том, что софту часто требуется доработка при переходе на другое железо или версию ОС, хотя формально все совместимо. У большинства микросхем такой проблемы нет, поэтому и поддержка по факту не требуется.
Re[9]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>Вы действительно полагаете, что во времена спектрумов другой вычислительной техники не существовало?
M>>Во времена поздних спектрумов — существовало. Когда он только появился — было сильно похуже
ЕМ>Вы тоже никогда не слышали об IBM 360/370, БЭСМ-6 и прочих серьезных системах?
Слышали. Чутка побыстрее, зато весили сотни кг и стоили тонны нефти
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Не понял, а причем тут какая-то поддержка?
ЕМ>При том, что софту часто требуется доработка при переходе на другое железо или версию ОС, хотя формально все совместимо. У большинства микросхем такой проблемы нет, поэтому и поддержка по факту не требуется.
Да как бы не так. Те же STMки — вроде бы во многом совместимы между собой, но перепиливать из-под одной под другую — то ещё развлечение. И есть какой-нибудь SPL, которая вроде бы должна нивелировать различия, но, внезапно, в нецй имена одних и тех же по смыслу констант — немножко блджад разные. И вот когда ты вроде перепилил, и оно вроде бы даже собирается, внезапно обнаруживается, что на новом проце — новые баги, и идешь искать эррату и искать воркэраунды.
Я уж не говорю про какие-нибудь сенсоры по шине SPI/I2C — вроде одна буковка отличается, и шина та же, а работает всё по другому
Здравствуйте, Евгений Музыченко, Вы писали:
M>>всё было сделано на ардуиновских либах, ничего я там не оптимизировал.
ЕМ>То есть, проблема снова в софте. Сама по себе ATMega328 выдает 16 млн оп/с, для подобных задач этого достаточно по уши.
Я отвечал на
Вот именно, что "какие-то". Чтобы накидать несложную схемку с датчиками и исполнительными устройствами для Arduino, а потом накидать скетч для управления всем этим, достаточно самых общих познаний, а получится не намного хуже, чем у профессионального разработчика. А ведь ATMega, по нынешним временам — очень простенький МК, где-то на уровне 80286. Если при таких же общих познаниях делать софт для десктопа или мобильника, то получится ужас — неимоверно толстый, и столь же тормозной.
"накидать скетч для управления всем этим, достаточно самых общих познаний, а получится не намного хуже, чем у профессионального разработчика" — получится говно
Хотя на атмеге и фрезеры и 3д принтеры делают. Я, кстати, свой 3д станок сделал на сотке 24 мгц, не сильно быстрее атмеги, единственно, что у STM вроде периферия получше развита
Здравствуйте, Marty, Вы писали:
M>Чутка побыстрее, зато весили сотни кг и стоили тонны нефти
И как это соотносится с заявлениями о том, что с техникой и методами программирования 70-х было якобы принципиально невозможно большинство современных технологий и решений?
Re[11]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И как это соотносится с заявлениями о том, что с техникой и методами программирования 70-х было якобы принципиально невозможно большинство современных технологий и решений?
Если придраться к гую, то стоит вспомнить, что умел гуй 30 лет назад (про 70-е говорить нечего) и сейчас.
Благодаря современным мощностям и объемам памяти появилась возможность что-то предвычислять и перестраивать в фоне, пока пользователь пытается чего-то напечатать/нарисовать.
Всякий Intellicence, Autocomplete.
То, что раньше делалось в формате "запустил задачу и пошел курить" сейчас превратилось в настоящее интерактивное редактирование.
Т.е. сложность и возможности гуя выросли на несколько порядков.
Если раньше гуй был ориентирован на профи, требующий предварительного обучения, то сейчас всё значительно упрощается и сводит обучение к минимуму.
Правда, последние лет десять я что-то не вижу серьезной научной работы в гуестроении — всё больше дизайнеры косметику наводят.
Ну и повышение сложности неизбежно ведет к увеличению числа ошибок. Эта проблема применима ко всем отраслям — что к софту, что к железу.
_____________________
С уважением,
Stanislav V. Zudin
Re[12]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>стоит вспомнить, что умел гуй 30 лет назад (про 70-е говорить нечего) и сейчас.
Говоря о том, что гуй умеет сейчас, не стоит забывать, что изрядное количество свойств добавлено исключительно из эстетических целей. Они не ускоряют работу, не делают ее более надежной или безопасной, они просто забавляют и радуют глаз. Их появление стало возможным только из-за избытка дешевых ресурсов, раньше в них попросту не видели никакого смысла.
SVZ>Благодаря современным мощностям и объемам памяти появилась возможность что-то предвычислять и перестраивать в фоне, пока пользователь пытается чего-то напечатать/нарисовать.
Вы удивитесь, но это было и в 70-е. И параллельные процессы тогда тоже были.
SVZ>Всякий Intellicence, Autocomplete.
Autocomplete тогда делали в основном для командных строк. Вещей, подобных IntelliSense, не делали просто потому, что не было такого зоопарка в API и библиотеках, как сейчас. Для повседневной работы вполне хватало конспекта из нескольких десятков листов, для сложных вещей приходилось доставать из шкафа пару-тройку томов документации. А исчерпывающий справочник по системе команд PDP-11 вообще умещался на складной картонке, которую можно было носить в кармане.
SVZ>То, что раньше делалось в формате "запустил задачу и пошел курить" сейчас превратилось в настоящее интерактивное редактирование.
В 70-е было полноценное интерактивное редактирование в реальном времени. А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4. Это не было запредельно сложной задачей — скорее баловством. Будь в этом необходимость — добавил бы туда и AutoComplete, и IntelliSense, делов-то.
SVZ>Т.е. сложность и возможности гуя выросли на несколько порядков.
Не выросли они на порядки. Максимум — в разы. Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.
SVZ>Если раньше гуй был ориентирован на профи, требующий предварительного обучения
Это который гуй был так ориентирован?
SVZ>Правда, последние лет десять я что-то не вижу серьезной научной работы в гуестроении
А какие еще есть актуальные и нерешенные проблемы в обычным двумерном гуе? Серьезная работа начнется, когда появятся массовые устройства, управляемые движениями глаз, или вообще силой мысли.
— всё больше дизайнеры косметику наводят.
SVZ>Ну и повышение сложности неизбежно ведет к увеличению числа ошибок. Эта проблема применима ко всем отраслям — что к софту, что к железу.
Re[11]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Чутка побыстрее, зато весили сотни кг и стоили тонны нефти
ЕМ>И как это соотносится с заявлениями о том, что с техникой и методами программирования 70-х было якобы принципиально невозможно большинство современных технологий и решений?
Элементарно. Глянул в вики про IBM 360 — там на всю машину 4 метра оперативы в топовых моделях и 10К kIPS — я так понял — это кило инструкции пер секунда. Ну это да — середина 60ых — начало 70ых, в 82ом году, когда спектрум выпустили, наверно было получше. На 4х метрах, конечно, и винда 95ая как-то работала (правда проц пошустрее нужен, раз так в десятки тыщ раз) — но и 95ую с её прямым Хэ с современными технологиями не сравнить.
Я тут LLVM собирал — сорцы гиг где-то занимают (3 гига, если считать с гитовой репой), пол дня компилятся, на выходе 120Гб только для одной конфигурации — платформа/дебаг|релиз. Просто не вижу, чего тут можно сравнивать
