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

    

У этого вопроса уже есть ответ:

    

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

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

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

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

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

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

30 голосов | спросил morbidCode 30 Jpm1000000pmSat, 30 Jan 2016 20:23:07 +030016 2016, 20:23:07

13 ответов


22

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

Прежде всего, давайте сделаем одно: ясно, что все, что вы когда-либо знали, находится на уровне абстракции. 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 не достаточно умны, чтобы понимать компьютерную архитектуру), и (б) попытался объяснить детали реализации, которые он /она не полностью понял, и которые уже развились вне его /ее ментальной модели. Этот пример является вымышленным,но это проистекает из повседневных заблуждений реального мира - такого рода, что иногда приводит к опасным ошибкам и иногда знаменитым дырам в области безопасности.

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

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

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

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

ответил Theodoros Chatzigiannakis 31 Jam1000000amSun, 31 Jan 2016 00:18:29 +030016 2016, 00:18:29
40
  

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

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

  

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

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

  

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

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

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

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

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

ответил Telastyn 30 Jpm1000000pmSat, 30 Jan 2016 20:55:17 +030016 2016, 20:55:17
31
  

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

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

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

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

ответил Lightness Races in Orbit 30 Jpm1000000pmSat, 30 Jan 2016 20:42:31 +030016 2016, 20:42:31
16

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

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

ответил Derek Elkins 30 Jpm1000000pmSat, 30 Jan 2016 20:47:57 +030016 2016, 20:47:57
5
  

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

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

Сделайте оба. Много работать. И вы можете быть оба.

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

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

  

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

     

Артур С Кларк

ответил candied_orange 30 Jpm1000000pmSat, 30 Jan 2016 23:51:55 +030016 2016, 23:51:55
3

Разработка программного обеспечения имеет несколько уровней детализации. Ваш вопрос: «Каков самый полезный, достойный, интересный уровень?»

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

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

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

ответил Martin Maat 30 Jpm1000000pmSat, 30 Jan 2016 23:32:00 +030016 2016, 23:32:00
3

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

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

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

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

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

ответил Cort Ammon 31 Jam1000000amSun, 31 Jan 2016 06:51:44 +030016 2016, 06:51:44
3

Сколько сейчас времени?

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

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

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

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


  

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

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

  

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

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

  

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

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

  

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

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

  

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

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

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

  

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

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

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

  

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

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

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

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

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

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

Не избегайте абстракций, они являются инструментами.

  

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

Ты забываешь, что можешь многому научиться. Изучение Java не мешает вам учиться C, Learning C не мешает вам учиться C #. Обучение ООП не мешает вам изучать структуры данных, обучение структурам данных не мешает вам изучать АОП. Изучение языка ассемблера не мешает вам изучать электронику; научная электроника не мешает вам изучать логические ворота.


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

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

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

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

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


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

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

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

Вы получаете идею.

ответил Theraot 31 Jpm1000000pmSun, 31 Jan 2016 17:26:07 +030016 2016, 17:26:07
1

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

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

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

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

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

ответил Davislor 31 Jam1000000amSun, 31 Jan 2016 01:43:50 +030016 2016, 01:43:50
1

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

ответил DrMcCleod 31 Jpm1000000pmSun, 31 Jan 2016 14:48:07 +030016 2016, 14:48:07
1

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

Решение проблемы реального мира должно иметь представление, которое близко напоминает модель проблемы. Именно поэтому игра в кости имеет класс под названием Die с помощью метода roll(), а не блок кода с кодом 011100110000001110101000100001010101000100 (предполагая, что эти двоичные абстракции имеют смысл на какой-то платформе). Это называется представительным пробелом от Larman. Абстракции позволяют уменьшить этот разрыв - стратегию, известную как Low Representaitonal Gap (LRG). Это делает код более легким для отслеживания требований и понимания. подход, основанный на управлении доменами (DDD) , аналогичен.


 Диаграмма классов UML DiceGame

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

ответил Fuhrmanator 31 Jpm1000000pmSun, 31 Jan 2016 23:35:51 +030016 2016, 23:35:51
0

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

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

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

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

ответил Patricia Shanahan 31 Jpm1000000pmSun, 31 Jan 2016 14:07:42 +030016 2016, 14:07:42
0

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

ответил Paul Smith 31 Jpm1000000pmSun, 31 Jan 2016 20:37:46 +030016 2016, 20:37:46

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132