Как далеко мы ушли...
как в анекдоте: 4 ядра и все тупят из-за кривого софта!
или в другом: каждый раз, когда ты пишешь int i вместо short i, сотни пользователей вынуждены докупать планку памяти
мощность вычислителя нивелируется кривизной рук и самих систем разработки
Когда программист не знает, что стоит сделать сдвиг целочисленного числа право на 2 бита, то оное уменьшится ровно в 4 раза, и подключает ВСЮ математическую библиотеку - это жесть!
когда Hello word занимает 12 МБ, когда преподаватель ВУЗа не знает ничего выше записей в своей же студенческой тетрадке с описание i51 40-летней давности, когда преподаватель "электроники" уровня Аспирант(!) не знает основ... то о чем можно говорить?
раскрыть ветку (72)
Когда программист не знает, что стоит сделать сдвиг целочисленного числа право на 2 бита, то оное уменьшится ровно в 4 раза, и подключает ВСЮ математическую библиотеку - это жесть!
Из книги "Совершенный код" следовало что все современные компиляторы подобные штуки сами правят. Код сейчас очень сильно вырос в размере и по сложности больее высокого уровня чем ебля со сдвигом вправо. Поэтому ГОРАЗДО важнее читабельность кода чем подобные заморочки. И сдивги куда то там это не читабельно.
Гораздо выгоднее, с точки щрения затрат денег на программистов, сначала написать рабочую программу с читабельным кодом, а потом оптимизировать все узкие места. Если на средних компах не лагает - и так сойдёт. И это НОРМАЛЬНО.
раскрыть ветку (4)
Всегда бесит разбирать астральные надписи, которые хоть и очень лаконично и просто решают задачу, но нихрена не читабельно и очевидно, в результате поддержка кода становится невозможной из-за таких вот хитрых выебонов. Код в первую очередь должен быть понятен, даже если он будет на пару 10 строк больше, исправить и оптимизировать надо на стадии окончания уже готовую программу с юнит тестами.
"Premature optimization is the root of all evil."© Кнут
"Premature optimization is the root of all evil."© Кнут
ещё комментарии
Астральный код можно комментировать. Просто "следующие 5 строк производят сдвиг...". Читаемость кода, эта мантра совроменного копробизнеса, выкатывающего по три обновления в месяц уже подзадолбала. Время программистов нужно экономить отказом от постоянных правок и обновлений (в пекло аджайл) а не поощрением написания говнокода.
раскрыть ветку (2)
Читаемость кода для проектов, рассчитанных на десятилетия, еще важнее, чем для обновляемых раз в три месяца, потому что за десять лет и люди, и технологии не один раз сменяются, а допилить прошивку контроллера какой-нибудь крекинговой колонны иногда все равно надо.
раскрыть ветку (1)
Не спорю, в серьезном энтерпрайзе это важно. Но постоянные обновления и аджайл достали уже, именно из-за них современный софт стал таким говном.
ещё комментарии
Когда программист не знает, что стоит сделать сдвиг целочисленного числа право на 2 бита, то оное уменьшится ровно в 4 раза, и подключает ВСЮ математическую библиотеку - это жесть!
ну это же подход ассемблера =) сейчас такая фигня это обычно экономия на спичках, потому что чтобы увидеть разницу в производительности этими операциями деления должен быть постоянно занят весь процессор. к тому же, в большинстве языков есть абсолютно стандартное "деление без остатка", не требующее подключения библиотек. а некоторые умеют инт так делить и обычным (/) делением.
раскрыть ветку (21)
Надо профайлером bottleneck'и искать, а не тупо оптимизировать все и вся, как говорил Кнут: "Premature optimization is the root of all evil in programming." Если нет проблемы или она решается апгрейдом железа то не стоит и заморачиваться, Железо нынче дешевое, а время программиста все так же дорогое. Современные компиляторы лучше оптимизируют, чем средний программист вручную.
раскрыть ветку (9)
раскрыть ветку (7)
С точки зрения производства и бизнеса да. Это рядового пользователя жаба душит топовую конфигурацию собрать, а для бизнеса не проблема выложить несколько миллионов для обновления парка техники. Главное убедить что новая заебатая софтина новее и заёбистей заебатей.
раскрыть ветку (6)
Это обсуждалось в подскасте радио т. Что есть 2 варианта решения проблеммы производительности. Нанимаем программера и он оптимизирует или тупо закидывает деньгами на железо. И подход с железом оказывается дешевле.
раскрыть ветку (5)
А как же геймдев? У игроделов нет другого выхода, кроме как оптимизировать, иначе их игра пойдет на 5% ПК
раскрыть ветку (4)
что-то в последнее время я видел мало оптимизированных игр. Обычно это делается ужатием текстурок и все. Да и геймдев это капля в мире разработки серверного ПО.
Оптимизация переменных и пр., которую описал комментатор выше не сыграет никакой роли. Это как облегчать многотонный ковш экскаватора на 12 грамм. Оптимизация игр в основном идёт за счёт ухудшения графики, детализации и т.д.
раскрыть ветку (2)
Оптимизация может идти многими путями, не на уровне переменных, но на уровне упрощения алгоритмов и более рационального вызова методов, кэширования каких-либо данных. Там где у косорукого инди возможно memory leak или тупо создаются объекты под данные которые уже болтаются в памяти, у хорошего разработчика как раз оптимизация.
Проблема в том что это как облегчать космический спутник удалением лишних или дублирующих узлов, оно конечно можно , но поиск и аккуратное удаление стоит огромного времени и денег.
ещё комментарии
верно.
но я не программист, а "электронщик"-разработчик, работаю с микроконтроллерами на самом нижнем уровне...
там сразу такие ляпы видны.
но я не программист, а "электронщик"-разработчик, работаю с микроконтроллерами на самом нижнем уровне...
там сразу такие ляпы видны.
раскрыть ветку (10)
Так на микроконтроллере ты сразу ограничен в ресурсах, и не можешь использовать высокоуровневые языки.
раскрыть ветку (5)
Ловите попаданца!
P.S.: Уже давно можно. По крайней мере, на AVR и STM32 точно можно, с другими я покамест не работал. Си - достаточно высокоуровневый?
P.P.S.: Хотя да, ограничение памяти в 2 кб лично для меня вначале стало сурпрЫзом, потому что за годы на ПК как-то отвыкаешь экономить память НАСТОЛЬКО.
раскрыть ветку (4)
Если у тебя 2КБ то С становится низкоуровневым, библиотеки досвиданья, ассемблерные вставки - здравствуйте. Я сбёг от микроконтроллеров на С в счастливый мир Питона.
раскрыть ветку (3)
> В счастливый мир Питона
Одноглазого?))) извини, не мог не пошутить. Это ж пикабу…
В смысле становится низкоуровневым? Как это понимать?
Что имеется ввиду под библиотеками? Я не профессионал просто, так, балуюсь. Предварительно скомпилированный чужой код я не использую, не умею.
Просто инклуды с посторонними методами работают, сам код выглядит вполне обычно, то есть уровень абстракции довольно высок, просто для понимания – я пишу AlarmOn(); IgnitionStart(30); вместо PORTB |= 1<<PinID; (что в принципе тоже где-то в глубинах инклудов есть). Да и потом – на том же STM32 оперативки уже от 32 до дофига кб, и при желании там, наверное, можно впендюрить библиотеку.
Даже на 2кб-камне у меня получилось поднять т.н. систему событий, примерно как используется в платформе 1С8, когда нужно вызвать функцию с временной задержкой, возможно вызывать циклично, и при этом не блокировать работу камня, т.к. кроме отложеной функции на нём ещё управление другими системами. Получился эдакий динамический список заданий, который каждый проход основного цикла проверялся на наличие заданий, готовых к запуску. Единственное, чем пришлось пожертвовать из-за оперативки – это строковые человекопонятные названия заданий, но замена из на однобайтные константы с понятными именами сэкономила много места в памяти и много тактов процессора при сравнении.
Так что не знаю, мне казалось что запись вида PlanEvent(ACTION_ENGINE_START, 30000, RPM_STARTED, MAX_IGNITION_TIME, EVENT_NO_REPEAT); // пуск через 30 секунд
, подразумевающая неблокирующее планирование действий, это уже не низкий уровень. Сравнительно, конечно.
SUB ECX, Hehe
CMP ECX, EDX
JNE Kuku
JMP Pipi
Вот с этим, в смысле.
Одноглазого?))) извини, не мог не пошутить. Это ж пикабу…
В смысле становится низкоуровневым? Как это понимать?
Что имеется ввиду под библиотеками? Я не профессионал просто, так, балуюсь. Предварительно скомпилированный чужой код я не использую, не умею.
Просто инклуды с посторонними методами работают, сам код выглядит вполне обычно, то есть уровень абстракции довольно высок, просто для понимания – я пишу AlarmOn(); IgnitionStart(30); вместо PORTB |= 1<<PinID; (что в принципе тоже где-то в глубинах инклудов есть). Да и потом – на том же STM32 оперативки уже от 32 до дофига кб, и при желании там, наверное, можно впендюрить библиотеку.
Даже на 2кб-камне у меня получилось поднять т.н. систему событий, примерно как используется в платформе 1С8, когда нужно вызвать функцию с временной задержкой, возможно вызывать циклично, и при этом не блокировать работу камня, т.к. кроме отложеной функции на нём ещё управление другими системами. Получился эдакий динамический список заданий, который каждый проход основного цикла проверялся на наличие заданий, готовых к запуску. Единственное, чем пришлось пожертвовать из-за оперативки – это строковые человекопонятные названия заданий, но замена из на однобайтные константы с понятными именами сэкономила много места в памяти и много тактов процессора при сравнении.
Так что не знаю, мне казалось что запись вида PlanEvent(ACTION_ENGINE_START, 30000, RPM_STARTED, MAX_IGNITION_TIME, EVENT_NO_REPEAT); // пуск через 30 секунд
, подразумевающая неблокирующее планирование действий, это уже не низкий уровень. Сравнительно, конечно.
SUB ECX, Hehe
CMP ECX, EDX
JNE Kuku
JMP Pipi
Вот с этим, в смысле.
раскрыть ветку (2)
Подключая библиотеку ты добавляешь её код к программе (т.к. это динамическая библиотека всё немножко по другому, но кто знает тот поймёт) и инклюднув например библиотечку ввода-вывода и математики у тебя теряется куча памяти, поэтому либо вырываем функции из библиотек либо если совсем всё плохо пишем эти функции на ассемблере.
Низкий уровень ведь не подразумевает что ты что-то там не можешь, просто всё становится сложнее для написания.
Я с микроконтроллерами только год общался год назад, так что не могу сказать подробней.
Для меня С низкоуровневый потому что я могу обратится напрямую к любому участку памяти. Плюсы уже повыше будут.
раскрыть ветку (1)
А, кажется, начинаю потихоньку понимать. Ну да, так на МК делать, конечно же, не стоит. Хотя чисто теоретически, думаю, возможно. Кстати, болие-лимение дорогие МК (вроде старших линеек ARM Cortex) по идее должны сожрать те же библиотеки без проблем, т.к. на них код наверняка уже хранится не в собственной памяти, а где-то снаружи.
Для меня С низкоуровневый потому что...
По поводу этого я засомневался и погуглил, первый абзац Вики говорит всё-таки об абстракции смысла от машинного кода, что С в принципе и делает :)
https://ru.wikipedia.org/wiki/Высокоуровневый_язык_программи...
А как оно там на самом деле - конечно, фиг его знает. По идее, в грамотно организованных высокоуровневых языках тоже должен быть какой-то произвольный доступ к памяти, другое дело что там он наверное обычно и не нужен, (по крайней мере, лично мне трудно представить себе задачу, которая в контексте большого проекта с точки зрения удобства кодера не решалась бы лучше элегантными обёртками над прямой работой с памятью).
раскрыть ветку (3)
а это простой метод показать к чему приводит какчество кода и индийский код... со стороны пользователя, так сказать.
раскрыть ветку (2)
раскрыть ветку (1)
Я тоже работаю в VS 2017, например. А ещё в Sublime Text и VS Code иногда.
И я видел код индусов. Вот прям настоящих индусов из Индии. Это ужас.
Написать код, делающий примерно одно и то же в разных местах 5 разными, не совместимыми друг с другом способами? Да не вопрос! Сделать это одному индусу в одном коммите? Изи!
Тесты, которые проходят потому что ничего не тестируют? Других в том проекте не было.
Каждый раз, когда ты пишешь "int i" вместо "short i", открываешь Википедию и читаешь про оптимизацию при компиляции)))
раскрыть ветку (5)
ох! Вы не поверите какие "краснодипломники" у меня бывали (приятели брата).
Это нечто!
нет! они не тупые! им просто этого не рассказывали.
Это нечто!
нет! они не тупые! им просто этого не рассказывали.
рассказываю одному, основы рассказываю...
А он каждые 20 минут выбегает покурить со словами "...мать! не может быть!"
раскрыть ветку (3)
Ничего нового. В учебниках разжевывают как писать хеловорлд, а на следующей странице просят наводить ПО для полета на луну.
Периоды в универе не всегда знают больше твоего.
На форумах и сообществах ЧСВ-шники пол часа объясняют какой ты мудак, а потом говорят что не собираются бесплатно учить джуна уму-разуму.
А потом ты приходишь на работу и на реальном примере узнаешь "ух ты, можно было не прописывать исключения, а вписать IS NOT NULL, ибо просто NOT NULL блокирует вывод"
Все это рассказывать о тысячи раз, но это по прежнему происходит.
Периоды в универе не всегда знают больше твоего.
На форумах и сообществах ЧСВ-шники пол часа объясняют какой ты мудак, а потом говорят что не собираются бесплатно учить джуна уму-разуму.
А потом ты приходишь на работу и на реальном примере узнаешь "ух ты, можно было не прописывать исключения, а вписать IS NOT NULL, ибо просто NOT NULL блокирует вывод"
Все это рассказывать о тысячи раз, но это по прежнему происходит.
Хах)
Наверное, ничто, кроме практики и искреннего интереса, не может дать уверенных знаний в таких областях. Просто выучить не удастся, мозг будет сопротивляться, это я знаю по себе. Не любил химию, поэтому в школе ни хера не получалось с ней. Зато в универе прекрасно разбирался и с криптографией, и с ЯП. Потому что с 9 или 10 лет уже сам этим интересовался, и когда пришел в универ, знал уже все вплоть до 4-го или 5-го курса.
Наверное, ничто, кроме практики и искреннего интереса, не может дать уверенных знаний в таких областях. Просто выучить не удастся, мозг будет сопротивляться, это я знаю по себе. Не любил химию, поэтому в школе ни хера не получалось с ней. Зато в универе прекрасно разбирался и с криптографией, и с ЯП. Потому что с 9 или 10 лет уже сам этим интересовался, и когда пришел в универ, знал уже все вплоть до 4-го или 5-го курса.
раскрыть ветку (1)
Наверное, ничто, кроме практики и искреннего интереса, не может дать уверенных знаний в таких областях.
в любых областях, потому что развитие рабочего процесса идёт чуть медленнее прогресса в своей сфере, а вот учебный процесс эволюционирует гораздо медленнее.
Он максимум может оптимизировать переменную у которой область видимости в пределах 1 функции. Остальные же переменные оптимизировать нельзя, т.к. данные могут прийти откуда угодно, а в случаие высокоуровневых языков то там вся библиотека (dll, или java package) может быть переиспользован в другом коде. В результате компилятор не может заменить тип, т.к. не известно где и как используется переменная.
Ну да:) Я как-то писал
Mega Man 1994:
2048K RAM, 64K VRAM
Castle In The Darkness 2015:
2097152K RAM, 1048576K VRAM
Но тут еще дело в скорости разработки:) Если Мегамэна толпа народа делала кучу времени, то CITH - яркий пример индюшатинки:) Да, куча различных фрэймворков и библиотек непомерно раздувает системные требования, но, с другой стороны облегчает (снижает порог вхождения) и ускоряет разработку:)
раскрыть ветку (9)
моя первая программа управляет автоматикой освещения города, уже лет так, блин, больше 13 лет.
Ассемблер, около 670 байт :) в том МК было всего 1 КБ ПЗУ...
раскрыть ветку (6)
Дело в том, что каждый язык программирования создан решать определенные задачи. Так и с ассемблером. Вы же не будете брать микроскоп, чтобы забить гвоздь?
раскрыть ветку (5)
согласен
но тут речь не о конкретном продукте, а самой идеологии: зачем продумывать Хороший алгоритм, если железо "и так тянет!".
История из жизни, лет 17-20 назад было.
Приятель пишет бухгалтерский софт. Использует FoxPro (и старую версию Dbase IV). Программы летают!
Появляется Visual FoxPro: красивые окошечки, менюшечки! Это вам не DOS! А тут как раз контора заказывает софт для учета чего-то там. Он решает перейти на новое и красивое.
Делает. Приходит к заказчику, а у оного древние ПК стоят, уровня 486. Занавес! Да, его ПО работает, но скорость черепашья! Вздыхает, переписывает под DOS - всё летает.
Получается, что ради "чтобы красиво было" надо 4 ядра по 1ГГц?
раскрыть ветку (3)
Просто в ТЗ надо заранее согласовывать производительность рабочих станций. Ибо любая дополнительная оптимизация это дополнительные расходы, которые увеличивают конечную стоимость ПО.
Если Мегамэна толпа народа делала кучу времени
Первый мегамен делало 6 человек. По времени хз
Второй мегамен делала та же команда в течение 3-4месяцев, одновременно работая над другим проектом.
При этом они изобретали новые жанровые особенности, попутно впихивая свою игру под системные возможности NES
раскрыть ветку (1)
Я не просто так написал год:) Mega Man: The Wily Wars для Megadrive, японка была выпущена в октябре 1994, европейка в апреле 1995. На Genesis она не распространялась на носителях, только через Sega Channel с конца 1994 (вообще с конца - с 31 декабря). Это - ремейк трех первых игр серии Mega Man на Famicom/NES. Вот титры игры https://youtu.be/A9ZeKTcNyuY?t=135
Слухи о Мегамэне для Sega начали распространяться в начале 1994, значит разрабатывалась игра не меньше 9-10 месяцев, ну, 6 если утечка была на очень ранней стадии.
Помню, как удивлялся и негодовал, что программа-пустое окно на делфи весит 600 килобайт и демонстрировал такое же окно, написанное на ассемблере, весом в 1.5 кб.
раскрыть ветку (13)
А сейчас на асме так же быстро как на делфях накидай туда кучку контролов, повяжи между собой и базой.
Что, не получилось? "А ты как думал - 40 тонн" (с)
раскрыть ветку (9)
Не придумывайте, я прекрасно осознаю сложность ассемблера. Я 2.5 года на нем писал. В том числе (исключительно ради развлечения) и виндовые оконные приложения.
Я понимаю, почему он здесь не применим.
Хотя, ради справедливости, тупо накидать контролов и подключиться к БД - не слишком сложно. Когда занимался - что-то простое за день точно справился бы, а может - и меньше. Но делать это нужно только для обучения или развлечения. В продакшне - нет.
раскрыть ветку (6)
Я ведь только хочу натолкнуть вас на мысль у каждого инструмента свое применение. И передергивать факты для вау-эффекта не стоит.
АСМ хоть и легок, но писать на нем сложные вещи очень долго и соотвественно дорого. Делают это только если цель оправдывает.
Да, при простом приложении с пустым окном 600Кб это много, но в этих 600Кб скрыт потенциал который понадобится и раскроется когда задача будет соотвествующая.
раскрыть ветку (5)
Правда? А я и не знал. наверное, стоит прекратить клавиатурой землю копать, как вы думаете?
Мысль совершенно капитанская.
Кстати, это было году, если я не ошибаюсь, в 98-м, тогда у меня жесткий диск был на 1 гб. И тогда эти 600Кб казались совершенно не оправданными. Кстати, законченные приложения тоже были очень даже не маленькими.
раскрыть ветку (4)
Мало кто умеет видеть перспективу более чем на пару дней вперед.
А вот в Борланде (и Майкрософте кстати тоже) умели. Они еще тогда знали что размер приложения не особо важен, а в перпективе станет вообще не важным критерием выбора инструмента. А вот что действительно важно - это эффективность разработки которая экономит время - невосполнимый и дорогой ресурс.
Как видим они были правы.
раскрыть ветку (3)
Мало кто умеет видеть перспективу более, чем на пару дней вперед.
Но вы умеете видеть то, что умели видеть другие. Как живется с третьим глазом? Что сейчас я думаю о вас?
Делфи, кстати, не слишком эффективен. У меня регулярно было так, что дома работает, принес в универ - нет. Вылетел за пределы массива и похерил чужую память. Дома повезло, память была не нужная, в универе - нет.
Кроме этого, делфи прививал ужасный стиль программирования: программирование в button1.onClick().
А накидывание кнопок на форму не слишком сильно экономит время.
В общем, ушел он на свалку истории - туда ему и дорога. Для своего времени делфи был прорывом, но это время прошло.
раскрыть ветку (2)
Делфи "ушел на свалку истории" из-за проигрыша microsoft в конкурентной борьбе, а не из-за концепции. И никуда его время не ушло. C# сейчас очень даже развит, а принцип RAD в его основе как и у делфи. Разница только в финансовом потенциале microsoft.
Программирование button1.onClick() используется повсеместно студентами которые обчно не заморачиваются тонкостями архитектуры, а так как делфи из-за своей доступности и низкого порога вхождения полюбился студентам, то легенды об этом разошлись в широкие массы. Такой же код можно писать (студенты и дальше так пишут) и в C# и в Java и в любом другом RAD. Но это проблема не делфи как RAD инструмента и не object pascal, который лежит в его основе. Это проблема "радиуса кривизны" рук тех кто пишет. Любой инструмент можно использовать неверно, от этого сам инструмент не становится хуже.
раскрыть ветку (1)
Делфи - конкурент С#? Данунафиг. Они настолько разные, что... А что именно по-вашему между ними общего? Почему вы считаете их конкурентами? Только без пространных философских рассуждений, а конкретно, с примерами.
Данунафиг2. Про С# говорить не буду, а вот в Java, чтобы создать button1.onClick() надо так заморочиться, что никто так не делает.
Это именно косяк в архитектуре потому, что при двойном щелчке на buttin1 создается именно процедура, в которой можно писать (и пишут). А не "слоты\сокеты", эвент листенеры и прочее, что именно вызывает вашу функцию.
А нам в универе в 2013 году преподавали Office 2003, ибо преподу лень методичку менять было...
Ох, друг стоит тебе выкинуть старые книжки и почитать про современные компиляторы и branch prediction.
Современный код уже не должен быть столь оптимизирован, а большой объем вызван необходимостью поддержки различных платформ, других условий.
Но, если ты напишешь лишний if твой код не замедлится.
Современный код уже не должен быть столь оптимизирован, а большой объем вызван необходимостью поддержки различных платформ, других условий.
Но, если ты напишешь лишний if твой код не замедлится.
раскрыть ветку (3)
большой объем вызван необходимостью поддержки различных платформ
мне кажется это дешёвой отмазкой. Где можно такое встретить? ну к примеру чтобы и в винде работало, и в андроиде.
или что значит "поддержка различных платформ"?
раскрыть ветку (2)
Сложно пояснить. Часто ПО необходимо поддерживать различное поведение, разную архитектуру, CPU/GPU, многопоточность. Мы же ведь не про приложение в аппстор говорим.
раскрыть ветку (1)
любое приложение работает на уровне абстракций. То что вы описали это уровень драйверов и всяких фреймов. Это их проблемы поддерживать всё подряд и иметь описание всего на свете. Это проблемы уровня ядра, куда простого пользователя и его приложения не пускают. К примеру, вам нужно обратиться к мышке. Вы так и пишете в программе "опросить мышку" и вам абсолютно пофиг какая она, что может и через что подключена. За это отвечает какой-нибудь директ-х или что-то подобное. А если всё так, то почему с каждым годом простой "хело ворлд" раздувается и раздувается, и требует всё больше и больше ресурсов?
Смотри:
- Программист тогда: хороший математик -> знает основы математики и низкоуровневого программирования
- Программист сейчас: чтобы стать "быдло-кодером" надо выучить язык программирования; если учат в ВУЗе, математику да, ее дают, но низкоуровневое программирование мало кто знает.
раскрыть ветку (2)
Хороший программист сейчас знает математику не меньше, если не больше.
Хороший программист сейчас умеет проектировать приложения, которые ни в одном сне не снились ни одному программисту тогда.
Хороший программист читает объемы кода несуществующие тогда ежедневно.
Хороший программист сейчас пишет код понятный человеку.
Хороший программист сейчас следит за новыми технологиями, развитием инструментов, новыми веяниями в разработке и объем такой работы больше чем раньше.
Хороший программист сейчас должен правильно выбирать и применять инструменты, будь то фреймворк, хранилище, алгоритм и среда разработки.
Хороший программист сейчас все еще должен знать низкоуровневую часть, пусть и не так детально как раньше.
И так далее.
Остается лишь позавидовать "программисту тогда", которому достаточно было школьного курса математики + уметь мало-мало переводить системы счисления + выучить набор команд своего процессора и десяток-другой правил оптимизации под него. Тогда что бы стать хорошим программистом достаточно было иметь мат. склад ума и полгода времени на изучение мат-части.
ещё комментарии