Я знаю, что это старо, но мой короткий ответ тем, кто утверждает, что теория «бесполезна» и что они могут практиковать свою профессию без нее, таков:
Без базовой теории существует нет практики.
Почему теория полезна?
Теория - это фундамент, на котором строятся другие вещи. Когда теория применяется , результатом является практика.
Рассмотрим компьютеры сегодня. Обычный компьютер сегодня смоделирован и построен на основе машины Тьюринга, которая, для простоты, является абстрактной / теоретической моделью для вычислений. Эта теоретическая модель лежит в основе вычислительной техники, и все вычислительные устройства, которые мы используем сегодня, от высокопроизводительных серверов до карманных телефонов, работают, потому что основа лежит в основе звука.
Рассмотрим анализ алгоритма. Проще говоря, анализ алгоритма и теория сложности времени использовались для классификации задач (например, P, NP, EXP и т. Д.), А также того, как алгоритмы, которые мы имеем, когда пытаясь решить разные проблемы в разных классах.
Предположим, что один из ваших друзей устроился на работу в каком-то месте X, и, пока он там, менеджер делает несколько простых запросов, например, таких примеров:
Пример 1: У нас есть большой парк транспортных средств доставки, которые посещают различные города в нескольких штатах. Нам нужно вы , чтобы внедрить систему, чтобы выяснить, какой кратчайший маршрут для каждого транспортного средства, и выбрать оптимальный один из всех возможных вариантов. Вы можете сделать это?
Думая, что теория «бесполезна», ваши друзья не понимают, что им только что была дана Задача коммивояжера (TSP), и начинают задумываться об этой системе, не задумываясь, только чтобы обнаружить их наивную попытку проверить все возможности, как первоначально запрашивалось, настолько медленны, что их система непригодна для практических целей.
Фактически, они понятия не имеют, почему система работает на "приемлемом" уровне при проверке 5 городов, но становится очень медленной в 10 городах и просто зависает при переходе только в 40 городов. Они считают, что это только"в 2 и 8 раз больше городов, чем тест с 5 городами", и удивляются, почему программе просто не требуется "в 2 и 8 раз больше времени" соответственно ...
Понимание теории позволило бы им понять следующее, по крайней мере, с первого взгляда:
- Это TSP
- TSP NP-hard
- Их алгоритм роста порядка O (n!)
Числа говорят сами за себя:
+--------------+-------+-----------------------------------------------------------------+
| No. Cities | O(N!) | Possibilities |
+--------------+-------+-----------------------------------------------------------------+
| 5 | 5! | 120 |
| 10 | 10! | 3,628,800 |
| 40 | 40! | 815,915,283,247,897,734,345,611,269,596,115,894,272,000,000,000 | <-- GG
+--------------+-------+-----------------------------------------------------------------+
Они могли с самого начала понять, что их система не будет работать так, как они себе это представляли. Впоследствии система была признана непрактичной и была отменена после того, как значительное количество времени, усилий и других ресурсов было выделено и в конечном итоге потрачено на проект - и все потому, что мысль «теория бесполезна».
Так что после этой неудачи менеджеры думают: «Ну, может быть, эта система была недооценена; в конце концов, в нашей стране очень много городов, и наши компьютеры просто не так быстры, как нам нужно, чтобы они были для наших недавних система отменена, чтобы быть успешным ".
Команда управления винит медленные компьютеры как причину провала проекта. В конце концов, они не являются экспертами в теории КС, в этом нет необходимости, и те, кто должен быть экспертами в этой области и могли бы сообщить им, не сделали этого.
Но у них есть другой проект. На самом деле проще. Они приходят через неделю и просят сказать следующее:
Пример 2: У нас всего несколько серверов, и у нас есть программисты, которые продолжают отправлять программы, которые по неизвестным причинам заканчиваются бесконечными циклами и отключают серверы. Нам нужно you , чтобы написать программу, которая будет обрабатывать отправляемый код и определять, будет ли отправленная программа вызывать бесконечный цикл во время ее выполнения, и решать, следует ли разрешить выполнение представленной программы на этом основа. Вы можете сделать это?
Ваш дорогой друг снова принимает вызов и немедленно приступает к работе. После нескольких недель работы результатов нет, твой друг испытывает стресс и не знает, что делать. Еще одна ошибка ... ваш друг теперь чувствует себя "глупым" из-за того, что не смог решить эту "простую проблему" ... в конце концов, сам запрос сделал его звук простым.
К сожалению, ваш друг, настаивая на том, что «теория бесполезна», не осознавал, что якобы простой запрос на самом деле был неразрешимой проблемой разрешимости (то есть самой проблемой остановки), и что не было никакого известного решения для Это. Это было невыполнимое задание.
Поэтому даже начало работы по решению этой конкретной проблемы было ошибкой, которую можно было избежать и предотвратить. Если бы существовала теоретическая основа для понимания того, что запрашивалось, они могли бы просто предложить другое и достижимое решение ... такое как реализация процесса мониторинга, который может просто kill -SIGTERM <id> любого пользователь процесс (согласно списку пользователей), который монополизирует ЦП на некоторый произвольный / разумный интервал при определенных допущениях (например, мы знаем, что каждый запуск программы должен был завершиться в течение 10 минут, поэтому любой экземпляр, работающий в течение 20 + минуты должны быть kill ред.)
В заключение, практика без теории подобна зданию без фундамента . Рано или поздно нужное количество давления под прямым углом заставит его обрушиться на . Без исключений.
Вы когда-нибудь использовали его в повседневном кодировании?
Да, но не напрямую . Скорее, мы полагаемся на это косвенно . Предостережение заключается в том, что различные теоретические концепции будут более или менее применимыми в зависимости от проблемной области, над которой вы работаете.
Конечно, мы:
- ежедневно используют компьютеры, которые опираются на вычислительные модели (например, машины Тьюринга)
- написать код, который опирается на теорию вычислимости (например, что даже вычислимо) и лямбда-исчисление (например, для языков программирования)
- полагаться на теорию цвета и модели (например, цветовые модели RGB и CMYK) для цветных дисплеев и печати и т. Д.
- Теоремы Эйлера в компьютерной графике, позволяющие строить матрицы для вращения объектов вокруг произвольных осей и т. Д. *
Это факт, что тот, кто просто использует самолет для путешествий, не должен понимать теорию, которая даже позволяла строить самолеты и летать в первую очередь ... но когда кого-то ожидают построить указанных машин и заставить их работать ... действительно ли можно ожидать хорошего результата от того, кто не понимает даже принципов полета?
Действительно ли это было совпадением, что на протяжении большей части истории никто не мог построить летательный аппарат (а некоторые даже умерли, испытывая свои), пока братья Райт не поняли некоторые теоретические концепции о полете и не смогли применить их на практике
Это не совпадение. Сегодня у нас много работающих технологий, потому что люди, которые их создали, понимали и применяли теоретические принципы, которые позволили им работать в первую очередь.