it-swarm.com.ru

Помощь в понимании информатики, программирования и абстракции

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

Чем больше я программирую на абстрактных языках, тем больше я скучаю по тому, что заставило меня в первую очередь попасть в компьютеры: ковыряться в компьютере и видеть, что дергается. Ассемблер и С очень подходят для тыкания :)

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

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

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

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

31
morbidCode

Нет, абстракции не мешают вам понять, как все работает. Абстракции позволяют понять, почему (с какой целью) все работает так, как они работают.

Прежде всего, давайте проясним одну вещь: почти все, что вы когда-либо знали, находится на уровне абстракции. Java это абстракция, C++ это абстракция, C это абстракция, x86 это абстракция, единицы и нули это абстракция, цифровые схемы это абстракция, интегральные схемы это абстракция, усилители абстракция, транзисторы - это абстракция, схемы - это абстракция, полупроводники - это абстракция, атомы - это абстракция, электронные полосы - это абстракция, электроны - это абстракция (и, как мы все знаем, это могут быть абстракции на всем пути вниз). логика в том, что для понимания того, как на самом деле работает что-то, требуется знание низкого уровня, если вы хотите понять, как на самом деле работают компьютеры, вам нужно изучать физику, затем электротехнику, затем вычислительную технику, затем информатику и, в сущности, продвигаться вверх в условия абстракции. (Я позволил себе не упоминать об этом сначала вам нужно изучить математику , чтобы действительно понять физику.)

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

Учтите это Java фрагмент:

public void Example() { 
    Object obj = new String("...");
    // ...
}

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

В качестве альтернативы рассмотрим этот фрагмент кода C:

void example(int i) {
    int j;
    if(i == 0) {
        j = i * 2;
        printf("Received zero, printing %d", j);
    } else {
        printf("Received non-zero, printing %d", j);
    }
}

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

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

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

В этом вымышленном примере знание языка OOP) не только не помешало вам понять C, но на самом деле научило вас концепциям, которые вы можете перенести на C. Эти концепции могут применяться выборочно. когда они нужны, чтобы облегчить управление вашим кодом, даже если язык не активно подталкивает вас к нему (я бы сказал, что между OOP и FP) есть похожая связь, но давайте не увлекайся.)

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

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

22
Theodoros Chatzigiannakis

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

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

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

Да, это абсолютно верно.

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

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

Никто знает их всех - не в глубине.

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

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

40
Telastyn

Я знаю, почему абстракция хороша, но разве это не мешает вам учиться работать на компьютере?

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

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

Хорошим началом было бы открытие различия между информатикой и программированием.

32
Lightness Races in Orbit

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

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

16
Derek Elkins left SE

Я знаю, почему абстракция хороша, но разве это не мешает вам учиться работать на компьютере? Я что-то пропустил?

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

Делай оба. Прилагать усилия. И вы можете быть оба.

Я работал на высоких уровнях SOLID, Bash, UML. Я работал на низких уровнях, TASM, Арифметические логические устройства, Аналоговые схемы. Я могу вам сказать, что нет уровня, на котором вы могли бы работать, если бы от вас не отвлекали магию.

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

Любая достаточно развитая технология неотличима от магии.

Артур К Кларк

5
candied_orange

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

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

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

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

3
Martin Maat

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

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

Для примера рассмотрим многопоточность. Традиционная многопоточность с использованием мьютексов, критических секций, условных переменных и т.д. Очень хорошо понимается на абстрактном уровне. Вам не нужно понимать, как ядро ​​переставляет потоки внутрь или наружу, или как управляемый таймер прерывает контроль за кражей у ваших пользовательских потоков, чтобы позволить ядру творить чудеса. Возможно, вам никогда не понадобится узнавать, что такое RCU или почему в какой-то момент глубоко в недрах ядра вы обязаны прекратить использование мьютексов. На самом деле, если вы попытаетесь понять это с уровня ядра, вы можете сделать опасные ошибки. Я не могу сосчитать количество случаев гонки, которые мне пришлось исправить, потому что кто-то считал, что операция "достаточно атомарна", и не защищал ее должным образом с помощью мьютексов. Вы должны действительно понять ядра (и компиляторы), прежде чем эти знания помогут вам написать безопасный многопоточный код. Гораздо эффективнее делать все на абстрактном слое мьютексов.

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

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

3
Cort Ammon

Сколько времени?

Пришло время стать программистом всезнайки или пора стать продуктивным программистом?

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

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

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


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

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

чтобы понять, что на самом деле происходит под капотом и как на самом деле работает компьютер.

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

В конце концов, я думал, что ты станешь лучшим программистом, зная это

Да, вы станете лучшим программистом, зная это.

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

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

И я думаю, что знать вещи низкого уровня гораздо интереснее, чем писать бизнес-программы.

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

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

Моя цель - стать лучшим программистом, лучше понимать компьютерные науки, и это очень смутило меня.

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

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

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

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

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

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

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

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

Не избегайте абстракций, это инструменты.

Я знаю, почему абстракция хороша, но разве это не мешает вам учиться работать на компьютере? Я что-то пропустил?

Вы забываете, что можете изучать несколько вещей. Обучение Java не мешает вам изучать C, обучение C не мешает вам изучать C #. Обучение OOP не мешает вам изучать данные структуры, изучение структур данных не мешает вам изучать AOP. Изучение языка ассемблера не мешает вам изучать электронику, изучение электроники не мешает вам изучать логические элементы.


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

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

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

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

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


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

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

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

Вы поняли идею.

3
Theraot

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

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

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

Некоторые из абстракций языка программирования C, которых нет в C, такие как foreach, контейнеры и итераторы, или даже функциональное программирование, могут компилировать большинство этих циклов сегодня более эффективно и безопасно, чем многие оптимизации, которые когда-то были сделал эффективный C-код, такой как арифметика указателей и устройство Даффа. Точно так же игры DOS были чрезвычайно эффективны, потому что они работали так близко к металлу, что люди запускали их только на эмуляторах, таких как DOSBox. Сегодня никто не беспокоится о размере кода, и программисты не держат кучу счетчиков, чтобы рассчитать время своей игры, потому что теперь намного проще сохранять одну временную метку и делить ее на оставшуюся часть. Почти как никто не делает умножение и деление путем преобразования в и из таблиц логарифмов.

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

1
Davislor

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

1
DrMcCleod

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

Решение реальной проблемы должно иметь представление, которое очень похоже на модель проблемы. Вот почему в игре в кости есть класс Die с методом roll(), а не блок кода с 011100110000001110101000100001010101000100 (при условии, что эти абстракции двоичных цифр имеют смысл на некоторой платформе). Ларман назвал это пробел в представлении . Абстракции позволяют сократить этот разрыв - стратегия, известная как низкий представительский разрыв (LRG). Это облегчает отслеживание кода в соответствии с требованиями и понимание. Подход Domain-Driven Design (DDD) аналогичен.


UML class diagram of DiceGame

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

1
Fuhrmanator

Как указано в ответ philipxy , все цифровое является абстракцией. Даже электротехнический взгляд на токи и напряжения - это абстракция.

Я работал архитектором компьютеров, разработчиком компиляторов и разработчиком операционных систем. У меня был опыт написания Java программ, которые я собирался запустить на сервере, который помогал проектировать.

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

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

0
Patricia Shanahan

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

0
Paul Smith