Как увеличение сложности систем повлияло на последующие поколения программистов?

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

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

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

Мой вопрос заключается в том, видят ли пожилые программисты такие инновации как находку или дополнительный слой, через который можно абстрагироваться, и почему они могут так думать? И помогают ли более молодые программисты изучать низкоуровневое программирование ПЕРЕД изучением областей расширенных библиотек? Если так, то почему?

это просто не нужно из-за увеличенного количества вычислительной мощности и доступной памяти.

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

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

Мой вопрос, однако, заключается в том, как люди относятся к этому «сокрытию» элементов более низкого уровня. Вы, старшие программисты, видите это как находку или ненужный слой для прохождения?

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

Все программирование сводится к абстрагированию слоя под вами, чтобы сделать более ценный слой поверх него. Если вы сделаете «диаграмму слоев», показывающую все подсистемы и то, как они построены друг на друге, вы обнаружите, что между оборудованием и пользовательским интерфейсом существуют буквально десятки слоев. Я думаю, что в диаграмме слоёв Windows есть что-то вроде 60 уровней необходимых подсистем между необработанным оборудованием и способностью выполнять «привет мир» в C #.

Как вы думаете, молодым программистам будет полезно больше изучать низкоуровневое программирование ПЕРЕД изучением сфер экспансивных библиотек?

Вы делаете акцент ДО, поэтому я должен ответить на ваш вопрос отрицательно. Я помогаю 12-летнему другу научиться программировать прямо сейчас, и вам лучше поверить, что я запускаю их в Processing.js, а не на ассемблере x86. Если вы начинаете молодого программиста в чем-то подобном, Processing.jsони будут писать свои собственные игры-стрелялки примерно через восемь часов. Если вы запустите их на ассемблере, они будут умножать три числа примерно за восемь часов. Как вы думаете, что больше заинтересовать молодого программиста?

Теперь, если вопрос таков: «Пользуются ли программисты, которые понимают уровень n торта, пониманием уровня n - 1?» ответ - да, но это не зависит от возраста или опыта; всегда можно улучшить свое программирование более высокого уровня, лучше понимая основные абстракции.

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

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

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

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

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

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

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

Это правда, у нас есть очень полезные библиотеки. Тем не менее, я думаю, что мы должны быть очень осторожны с абстракцией. Мы не должны предполагать, что если B строится на A, и это хорошо, то, если C строится на B, это даже лучше. Я называю это феноменом "принцесса на горошине". Накладывание слоев поверх чего-то неприятного не обязательно исправляет это.

Чтобы завершить длинный пост, я разработал стиль программирования (который иногда доставляет мне неприятности), где

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

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

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

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

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

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

Вся эта абстракция изолирует вас от аппаратного обеспечения? Конечно, это так. Жизнь в доме вместо палатки изолирует вас от природы? Абсолютно. Но все знают, почему они живут в доме, а не в палатке, и строительство дома - это совсем другая игра с мячом, чем установка палатки.

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

Вы можете абстрагироваться слишком много? "Обгони водопровод", как сказал бы Скотти ? Конечно вы можете. Писать хорошие API сложно. Написание хороших API, которые правильно и всесторонне воплощают проблемную область интуитивно понятным и обнаруживаемым способом, еще сложнее. Накопление новых слоев программного обеспечения не всегда является лучшим решением. Шаблоны разработки программного обеспечения в некоторой степени усугубили эту ситуацию, потому что неопытные разработчики иногда достигают их, когда более подходящий и более тонкий инструмент более уместен.

Действительно хорошее обучение включает в себя как крайности, так и мост между ними.

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

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

ИМХО, каждый должен иметь опыт работы с обоими, включая их недостатки, и уметь понимать, как перейти от низкоуровневых концепций к высокоуровневым. Любите ассоциативные массивы? Отлично, теперь попробуйте использовать их на 50-центовом встроенном процессоре с 1 КБ ОЗУ. Как писать быстрый код с использованием C? Отлично, теперь у вас есть три недели, чтобы написать веб-приложение; вы можете потратить свое время на работу со структурами данных и управлением памятью с помощью C, или вы можете потратить время на изучение новой веб-инфраструктуры и затем внедрить веб-приложение в течение нескольких дней.

Что касается сложности этого аспекта: я думаю, что в наши дни слишком просто создавать сложные системы без четкого понимания стоимости этого . В результате мы, как общество, накопили огромное количество технических долгов, которые время от времени нас кусают. Это как землетрясения (просто стоимость жизни около геологического разлома, верно?), Только постепенно становится хуже. И я не знаю, что с этим делать. В идеале, мы бы научились справляться со сложностями, и становились лучше, но я не думаю, что это произойдет. Ответственное инженерное образование должно включать гораздо больше дискуссий о последствиях сложности, чем большинство наших университетов в настоящее время предоставляют.

* и, в любом случае, где "основа" в том, как компьютер выполняет код? Это ассемблер? Или компьютерная архитектура? Или цифровая логика? Или транзисторы? Или физика устройства?

Я чувствую, что программирование высокого уровня имеет много преимуществ и является неотъемлемой частью языка программирования. Одной из причин успеха Java было то, что она имеет обширную библиотеку. Вы достигаете большего с меньшим количеством кода - просто вызовите предопределенную функцию.

Теперь мы можем отличить пользователей языка программирования от авторов языка программирования (авторов компиляторов). Мы оставляем оптимизацию авторам компилятора. Мы больше ориентируемся на ремонтопригодность, повторное использование и т. Д.

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

Я программирую уже более 40 лет, написав код на 50-100 различных языках или диалектах, и стал экспертом в 5-10. Причина, по которой я могу утверждать так много, состоит в том, что в основном это один и тот же язык, с настройками. Твики добавляют сложности, делая каждый язык немного отличающимся.

Я реализовывал одни и те же алгоритмы бесчисленное количество раз: коллекции, преобразования, сортировка и поиск, кодирование / декодирование, форматирование / анализ, буферы и строки, арифметика, память, ввод / вывод. Каждая новая реализация добавляет сложность, потому что каждая немного отличается.

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

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

Microsoft и IBM убили эту идею, вернувшись в C для написания приложений для Windows и OS / 2, в то время как dBase / Foxpro и даже Delphi томились. Затем веб сделал это снова с конечным набором языков ассемблера: HTML, CSS и JavaScript / DOM. Оттуда все было под гору. Всегда больше языков, больше библиотек, больше фреймворков и больше сложности.

Мы знаем, что должны делать это по-другому. Мы знаем о CoffeeScript и Dart, о Less и Sass, о шаблонах, чтобы избежать необходимости писать HTML. Мы знаем, и мы делаем это в любом случае. У нас есть наши фреймворки, полные неплотных абстракций, и мы видим, какие чудеса могут сделать те немногие избранные, кто изучает тайные заклинания, но мы и наши программы попали в ловушку решений, принятых в прошлом. Слишком сложно изменить или начать все сначала.

В результате вещи, которые должны быть легкими, не легки, а вещи, которые должны быть возможными, почти невозможны из-за сложности. Я могу оценить стоимость внесения изменений для реализации новой функции в установленной кодовой базе и быть уверенным, что я буду прав. Я могу оценить, но я не могу оправдать или объяснить это. Это слишком сложно.

Отвечая на ваш последний вопрос, я бы настоятельно советовал молодым программистам начинать как можно выше на слоеном пироге и погружаться только в нижние слои, когда потребность и желание дают импульс. Я предпочитаю языки без циклов, с небольшим или отсутствующим ветвлением и явным состоянием. Лисп и Хаскелл приходят на ум. На практике я всегда заканчиваю с C # / Java, Ruby, Javascript, Python и SQL, потому что именно там находятся сообщества.

Заключительные слова: сложность - главный враг! Удар, и жизнь становится проще.

Мой вопрос, однако, заключается в том, как люди относятся к этому «сокрытию» элементов более низкого уровня. Вы, старшие программисты, видите это как находку или ненужный слой для прохождения?

Ни на самом деле.

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

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

Как вы думаете, молодым программистам будет полезно больше изучать низкоуровневое программирование ПЕРЕД изучением сфер экспансивных библиотек?

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

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

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

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

Это умело описано здесь

или здесь - «одной строкой кода вы можете добавить 500 пользователей в домен» ...

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

Полезно ли молодым программистам больше изучать низкоуровневое программирование ПЕРЕД изучением областей расширенных библиотек? Если так, то почему?

Я так не думаю. Есть еще много ситуаций, когда полезно знать о низком уровне «слой ниже», например

• При отладке проблемы на слое nее часто можно объяснить, рассмотрев, что происходит на слое n-1(то есть на слое ниже). Я предполагаю, что слой 0 будет «транзисторами», но если вы хотите объяснить проблему с транзисторами, вы, вероятно, поговорите о физике (например, о тепле), так что, возможно, физика действительно уровня 0.

• При оптимизации кода это (к сожалению) иногда помогает снизить уровень абстракции, то есть реализовать алгоритм в терминах уровня более низкого уровня. Тем не менее, компиляторы очень хорошо справились с этим, если увидели весь задействованный код. Эта причина стала более популярной в последнее время благодаря буму мобильных и встраиваемых устройств, которые, как правило, имеют более слабые процессоры и где «производительность на ватт» гораздо более актуальна, чем, скажем, в настольных системах.

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

Основной мотивацией в разработке языков программирования и библиотек (т.е. API) является упрощение работы человеческого мозга. По сей день все по-прежнему компилируется в машинный код. Тем не менее, это не только подвержено ошибкам, это также общеизвестно трудно понять. Так что очень желательно

• Пусть компьютер поможет вам найти логические ошибки в программах, которые вы пишете. Такие вещи, как системы статического типа или анализаторы исходного кода (я слышал, Эрик Липперт работает над довольно популярной в наши дни), помогают в этом.

• Иметь язык, который может эффективно обрабатываться компилятором и который передает намерение программиста другим программистам упростить работу над программой. В качестве абсурдной крайности представьте, что написание программ на простом английском языке возможно. Другим программистам, возможно, было бы легче представить, что происходит, но все же описание было бы очень трудно компилировать в машинных инструкторов, и оно, как известно, неоднозначно. Таким образом, вам нужен язык, который компилятор может понять, но который также понятен.

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

«Если пожилые программисты видят инновации, подобные этим, как находку или дополнительный слой, через который можно абстрагироваться, и почему они могут так думать?»

Я занимался программированием, когда учился в средней школе, около 34 лет, начиная с Basic и Z80 Assembler, переходя на C, различные языки 4GL, Scheme, SQL и теперь различные веб-языки. Масштабы, масштабы и глубина проблем, которые решает профессия, пережили инфляционный период за это время, особенно в 1990-х годах. Такие конструкции, как библиотеки, фреймворки и службы ОС - все это устройства, предназначенные для устранения сложности, которая сопровождается расширением пространства проблем. Они не находка и не бремя сами по себе - это просто постоянное исследование огромного пространства решений.

Но, ИМХО, «инновация» лучше понимается в терминах новых форм, и ее не принимают за боковое движение - повторное введение форм, которые мы уже видели, введено. В некотором смысле, плодовитость экосистемы страдает, когда примитивные формы не сочетаются, когда они фиксируют решения, принятые в начале эволюции, или не могут переработать свой собственный детрит. Некоторые, если не большинство, конструкций, на которых мы остаемся сфокусированными, не рассматривают долгосрочное поддержание ценности как проблему. Это начало меняться - такие подходы, как Service Orientation и Domain Driven Design, не говоря уже о гипертекстовых и основанных на графике моделях, например, меняют ландшафт. Как и любая экосистема, в конечном итоге доминирующие формы уступят место новым формам; нас лучше всего обслуживают,

«И полезны ли более молодые программисты для обучения низкоуровневому программированию ДО того, как исследовать области расширенных библиотек? Если так, то почему?»

Я бы сказал, что большинство человеческого языка основано на метафорах, давно забытых, поэтому, хотя я бы поддержал изучение низкоуровневого программирования с точки зрения научной / числовой грамотности, более важно, чтобы мы искали примитивы, которые будут поддерживать масштаб и охват проблемы, которые мы решаем так, что мы можем спокойно игнорировать более низкий уровень детализации. Фреймворк не является примитивным, равно как и ОС или библиотека - они довольно слабы в том виде абстракции, который нам действительно нужен. Реальный прогресс потребует людей, которые (а) знают, что было раньше, и (б) могут мыслить достаточно оригинально, чтобы придумать что-то совершенно другое, чтобы исследовать пространство решения, которое не было исследовано ранее или было исследовано и забыто.

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

Моя первая программа (в возрасте 15 лет) была в 1974 году в PL / 1 на перфокартах для мэйнфрейма IBM 370/168. Мой отец работал в IBM, и мне посчастливилось по воскресеньям отправиться в центр обработки данных.

В то время программа из нескольких тысяч утверждений (неперфорированных карт) была большой (и очень тяжелой), так как многие тысячи перфокарт весили много килограммов). Визуальные интерфейсы не существовали (обычная программа считывала из своего «стандартного ввода» команду перфокарты, начиная с //GO.SYSIN DD *IIRC, но я не справлялся с JCL ). Алгоритмика была важна, и стандартная библиотека IIRC была довольно мала по сегодняшнему стандарту.

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

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

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

Основным отличием между 1970-ми и сегодняшним днем ​​является соотношение затрат между усилиями разработчика (человека) и вычислительной мощностью компьютера.