Як збільшення складності систем вплинуло на наступні покоління програмістів?

Як "новий" програміст (я вперше написав рядок коду в 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, це навіть краще. Я називаю це явищем "принцеса і горох". Набивання шарів поверх чогось проблемного не обов'язково це виправляє.

Щоб припинити довгу посаду, я розробив стиль програмування (який іноді заважає мені), де

• Винахідництво не є поганим. Це добре, як і в інших галузях техніки. Звичайно, це може створювати криву навчання для інших, але якщо загальний результат - краща продуктивність, варто.
• Мінімалістичний код стилю Хайку. Це особливо стосується і дизайну структури даних. На мій досвід, найбільша проблема програмного забезпечення в наші дні - роздута структура даних.

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

Чому? Тому що люди можуть утримати стільки знань у своїх головах у будь-який момент. Сучасні широкомасштабні системи можливі лише сьогодні, оскільки можна використовувати такі абстракції. Без цих абстракцій програмні системи просто руйнуються під власною вагою.

Кожен раз, коли ви пишете метод, ви створюєте абстракцію. Ви створюєте трохи функціональності, прихованого за викликом методу. Чому ви їх пишете? Оскільки ви можете протестувати метод, довести, що він працює, а потім викликати цю функціональність у будь-який час, лише зробивши виклик методу, і вам більше не доведеться думати про код, який знаходиться всередині цього методу.

У перші дні обчислень ми використовували машинну мову. Ми писали дуже маленькі, голі металеві програми з інтимним знанням обладнання, для якого ми їх писали. Це був кропіткий процес. Не було налагоджувачів; ваша програма зазвичай або працювала, або вона вийшла з ладу. GUI не було; все було або командним рядком, або пакетним процесом. Код, який ви написали, працюватиме лише на цій конкретній машині; він не працюватиме на машині з іншим процесором або операційною системою.

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

Чи вся ця абстракція ізолює вас від обладнання? Звичайно, це і є. Життя в будинку замість того, щоб розбити палатку, ізолює вас від природи? Абсолютно. Але всі знають, чому вони живуть в будинку замість намету, а будувати будинок - це зовсім інша гра з м'ячем, ніж розбивати намет.

Тим не менш, ви все ще можете поставити намет, коли це потрібно зробити, а в програмуванні ви можете (якщо ви так схильні) все-таки опуститися до рівня, ближчого до обладнання, щоб отримати продуктивність або переваги пам’яті, яких ви могли б не зробити інакше досягайте своєї мови високого рівня.

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

Дійсно хороший тренінг передбачає як крайність, так і міст між.

З боку низького рівня: як комп'ютер виконує код з нуля *, включаючи знання мови складання та те, що робить компілятор.

З боку високого рівня: загальні поняття, наприклад, використовуючи асоціативні масиви, закриття тощо, не витрачаючи часу на занепокоєння, як це працює під кришкою.

IMHO кожен повинен мати досвід роботи з обома, включаючи свої недоліки, та смак того, як пройти шлях від понять низького рівня до концепцій високого рівня. Любите асоціативні масиви? Чудово, тепер спробуйте використовувати їх на вбудованому 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 років тому. Таке зростання означає, що ми можемо робити більш потужні речі, як йде час. Це добре.

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

Як ви думаєте, молодші програмісти отримали б більше користі від програмування на низькому рівні перед тим, як вивчити сфери експансивних бібліотек?

Як було зазначено в інших відповідях, слід досягти балансу між приверненням та підтримкою уваги неофітів та наданням їм ідеальної освіти знизу вгору. Якщо ви не можете зробити перше, останнє не може статися.

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

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

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

Тут вміло описано

або тут - "за допомогою одного рядка коду ви можете додати 500 користувачів до домену" ...

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

Чи отримують переваги молодші програмісти більше, ніж навчатись програмуванню низького рівня, перш ніж вивчити сфери розширених бібліотек? Якщо так, то чому?

Я не думаю, що так. Існує ще багато ситуацій, коли корисно бути обізнаним про низький рівень роботи «шару внизу», наприклад

• Під час налагодження проблеми на шарі n, це часто можна пояснити, розглядаючи, що відбувається на шарі n-1(тобто шарі внизу). Я думаю, що рівень 0 був би "транзисторами", але якщо ви хочете пояснити проблему з транзисторами, ви, напевно, поговоримо про фізику (наприклад, тепло), тож, можливо, фізика дійсно є рівнем 0.

• При оптимізації коду він (на жаль) допомагає часом знизити рівень абстракції, тобто реалізує алгоритм з точки зору рівня нижчого рівня. Однак компілятори стали дуже хорошими для цього, якщо вони дійсно бачать весь код. Ця причина стала популярною останнім часом із бумом мобільних та вбудованих пристроїв, які мають слабкіші процесори та де «продуктивність на Ватт» набагато актуальніша, ніж, скажімо, на настільних системах.

Однак, як правило, змусити комп’ютери робити речі (навіть якщо трохи неефективними способами) стало набагато простіше, а це означає, що програмістів набагато більше, ніж раніше. Це, в свою чергу, зробило "людський" фактор набагато важливішим: у відповіді Роберта Харві вже згадувалося, що "люди можуть утримувати стільки знань в голові в будь-який момент", і я думаю, що це є дуже актуальним аспектом в наші дні.

Основна мотивація в мові програмування та дизайні бібліотеки (тобто API) полягає в тому, щоб полегшити роботу мозку людини. На сьогоднішній день все ще збирається до машинного коду. Однак це не лише схильність до помилок, але також, як відомо, важко зрозуміти. Тож це дуже бажано

• Попросіть комп’ютер допомогти у пошуку логічних помилок у програмах, які ви пишете. Такі речі, як системи статичного типу або аналізатори вихідного коду (я чую, що Ерік Ліпперт працює на досить популярній сьогодні).

• Мати мову, яка може ефективно оброблятися компілятором і яка передає наміри програміста іншим програмістам, щоб полегшити роботу над програмою. Як абсурдна крайність, уявити, як писати програми простою англійською мовою було можливо. Колегам-програмістам, можливо, буде легше уявити, що відбувається, але все-таки опис було б важко скласти в інструктори машин, і це, як відомо, неоднозначно. Тож вам потрібна мова, яку компілятор може розуміти, але яка також зрозуміла.

Зважаючи на те, що багато (більшість?) Компіляторів все ще мають загальне призначення, вони мають дуже загальний набір інструкцій. Не існує інструкції "намалювати кнопку" або "відтворити цей фільм". Отже, рухаючись вниз по ієрархії абстракцій змушує вас закінчитись з програмами, які дуже важко зрозуміти та підтримувати (хоча тривіально їх скласти). Єдина альтернатива - просування вгору за ієрархією, що веде до все більш абстрактних мов та бібліотек.

"якщо старші програмісти бачать інновації на кшталт цих як знахідку або додатковий шар, який слід абстрагувати, і чому вони можуть так вважати?"

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

Але, ІМХО, «інновації» краще розуміти з точки зору нових форм, і не помиляємось на бік руху - повторне введення форм, які ми вже бачили, що були введені. У деякому роді плодючість екосистеми страждає, коли примітивні форми не складаються, коли вони фіксують рішення, прийняті на початку еволюції, або не можуть переробити власний детрис. Деякі, якщо не більшість конструктів, на які ми залишаємося зосередженими, не надають пріоритету довготривалому збереженню цінності як проблемі. Це почало змінюватися - такі підходи, як Орієнтація на обслуговування та Дизайн, керований доменом, не кажучи вже про гіпертекстові та графічні моделі, наприклад, змінюють ландшафт. Як і будь-яка екосистема, з часом домінуючі форми поступляться новим формам; нам найкраще служити, дозволяючи різноманітність,

"І чи отримують користь молодші програмісти більше, ніж вивчати програмування низького рівня, перш ніж вивчити сфери експансивних бібліотек? Якщо так, то чому?"

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

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

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

У той час великою була програма з декількох тисяч виписок (iepunched карт) (і теж важка, оскільки багато тисяч перфокарт важили багато кілограмів). Візуальних інтерфейсів не існувало (типова програма, прочитана зі свого "стандартного вводу", використовуючи команду перфокарт, починаючи з //GO.SYSIN DD *IIRC, але я не освоїв JCL ). Алгоритміка була важливою, і IIRC стандартна бібліотека була досить маленькою за сьогоднішнім стандартом.

Сьогодні програми з кількох тисяч рядків, як правило, вважаються невеликими. Наприклад, компілятор GCC має понад десять мільйонів рядків вихідного коду, і ніхто їх не розуміє повністю.

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

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

Основна різниця між 1970-х і сьогодні - співвідношення витрат між зусиллями розробника (людини) та потужністю комп'ютера.