В классе мы узнали о проблеме остановки, машинах Тьюринга, сокращениях и т.д. Многие одноклассники говорят, что это все абстрактные и бесполезные понятия, и нет никакого реального смысла их знать (т.е. вы можете их забыть один раз курс закончился и ничего не потерял).
Почему теория полезна? Вы когда-нибудь использовали его в своем ежедневном кодировании?
Когда я окончил колледж, я предположил, что я наравне со всеми остальными: "У меня есть BS в CS, и так много других людей, и мы все можем сделать практически то же самое". В конце концов я обнаружил, что мое предположение было ложным. Я выделялся, и мой опыт имел много общего с этим - особенно моя степень.
Я знал, что существует одна "небольшая" разница, потому что у меня есть "B.S." в CS, потому что мой колледж был одним из первых (предположительно # 2 в 1987 году) в стране, чтобы получить аккредитацию для своей программы обучения в CS, и я окончил второй класс, чтобы получить эту аккредитацию. В то время я не думал, что это важно.
Я также заметил, что во время средней школы и в колледже я особенно хорошо играл в CS - намного лучше, чем мои сверстники и даже лучше, чем многие из моих учителей. Меня много просили о помощи, проводили некоторые уроки, просили помочь с исследовательским проектом, и мне было разрешено заниматься независимым изучением, когда никто другой не был. Я был счастлив, что смог помочь, но я не думал о разнице.
После колледжа (USAFA) я провел четыре года в ВВС, два из которых применяли мою степень CS. Там я заметил, что очень немногие из моих коллег имеют степени или даже обучение, связанное с компьютерами. Военно-воздушные силы отправили меня на пять месяцев обучения по сертификации, где я снова обнаружил недостаток степеней или подготовки. Но здесь я начал замечать разницу - стало совершенно очевидно, что многие из людей, с которыми я столкнулся, ДЕЙСТВИТЕЛЬНО не знали, что они делают, и это включало людей с обучением или степенями. Позвольте мне проиллюстрировать.
В моей подготовке по сертификации ВВС было в общей сложности тринадцать человек (включая меня). Как офицеры ВВС или эквивалент, у всех нас были степени бакалавра. Я был посередине по возрасту и рангу (я был O-2 среди шести O-1 и шести O-3 и выше). В конце этого обучения военно-воздушные силы оставили нас всеми одинаково компетентными в приобретении, строительстве, проектировании, обслуживании и эксплуатации ЛЮБОЙ компьютерной или коммуникационной системы для ЛЮБОЙ части Министерства обороны.
Однако из тринадцати из нас только шесть имели какую-либо форму, связанную с компьютером; другие семь имели степени от аэронавтики до химии/биологии до психологии. Из шести из нас со степенями CS я узнал, что двое никогда не писали какую-либо программу и никогда не использовали компьютер более чем случайно (писать документы, играть в игры и т.д.). Я узнал, что еще двое из нас написали ровно одну программу на одном компьютере во время своей программы обучения в CS. Только один человек и я написали более одной программы или использовали более одного вида компьютеров - действительно, мы обнаружили, что мы два написали много программ и использовали многие виды компьютеров.
К концу нашего пятимесячного обучения нашему классу был присвоен проект по программированию, и мы разделились на четыре группы, чтобы отдельно взять его на себя. Наши преподаватели разделили класс, чтобы распределить "талант программирования" справедливо, и они назначили роли ведущего, технологического руководителя и разработчика. Каждой группе была предоставлена неделя, чтобы реализовать (в Ada) полноэкранный текстовый пользовательский интерфейс (это был 1990 год) для симулятора полета на базе предоставленной инструктором библиотеки летной механики. Я был назначен техническим руководителем для моей команды из четырех человек.
Моя команда (у которой не было компьютерного факультета) попросила остальных троих разделить проект на задачи, а затем назначила треть каждого из них каждому из нас. Я закончил третью задачу к середине первого дня, а затем провел остаток дня, помогая своим двум другим товарищам по команде, разговаривая с моей командой (BSing; ^) и играя на моем компьютере.
На следующее утро (второй день) мой руководитель команды сообщил мне, что наши другие два товарища по команде не достигли прогресса (на самом деле невозможно написать выражение "если", которое будет компилироваться), и он попросил меня взять их Работа. Я закончил весь проект к середине дня, и моя команда провела остаток дня, пролетая с симулятором.
Другой парень со сравнимой степенью CS также был назначен техническим лидером для своей команды, и они закончили к концу третьего дня. Они также начали летать на своем симуляторе. Остальные две команды не закончили или даже не достигли значительного прогресса к концу недели. Нам не разрешалось помогать другим командам, поэтому он остался на этом.
Между тем, к середине третьего дня, я заметил, что симулятор полета просто казался "неправильным". Поскольку один из моих одноклассников получил степень по аэронавтике, я спросил его об этом. Он был озадачен, потом признался, что на самом деле он не знал, что заставило самолет летать! Я был ошеломлен! Оказывается, вся его программа была посвящена исследованиям в области безопасности и краха - никакой реальной математике или науке, лежащей в полете. С другой стороны, у меня был, возможно, несовершеннолетний в аэронавтике (помните USAFA?), Но мы разработали крылья и выполнили настоящие тесты аэродинамической трубы. Поэтому я спокойно провел оставшуюся часть недели, переписав предоставленную инструктором библиотеку полетной механики, пока симулятор не летел "вправо".
С тех пор я провел почти два десятилетия подрядчиком, а иногда и сотрудником, всегда занимающимся разработкой программного обеспечения, а также сопутствующими действиями (DBA, архитектор и т.д.). Я продолжал находить больше того же, и в итоге я отказался от своего юного предположения.
Итак, что именно я обнаружил? Не все равны, и все в порядке - я не лучший человек, потому что я могу эффективно программировать, но я более полезен, если это то, что вам нужно от меня. Я узнал, что мой опыт действительно имеет значение: вырос в семье электриков и инженеров-электриков, комплекты электроники здания, чтение LITERALLY каждой компьютерной книги в школьных/публичных библиотеках, потому что у меня не было доступа к реальному компьютеру, затем переезд в новый город, где в моей средней школе были компьютеры, затем получить мой собственный компьютер в качестве подарка, ходить в школы, в которых были компьютеры разных размеров и видов (ПК для мэйнфреймов), получение аккредитованной степени от ОЧЕНЬ хорошей инженерной школы, приходится писать множество программ на разных языках на разных компьютерах, (например, моя собственная виртуальная машина с пользовательским языком ассемблера или реализация сжатия Хаффмана и т.д.), для устранения неполадок для себя, создавая собственные компьютеры из частей и устанавливая ВСЕ ПО, и др.
В конечном итоге я узнал, что мои способности основаны на знании того, как компьютеры работают с электрического уровня на дискретных электронных компонентах, схемах, подсистемах, интерфейсах, протоколах, битах, байтах, процессорах, устройствах, драйверах, библиотеки, программы, системы, сети, вплоть до крупных конгломератов корпоративного класса, которые я обычно работаю сейчас. Итак, когда это чертовски плохо, я точно знаю, КАК И ПОЧЕМУ. И я знаю, что нельзя сделать, а что может. И я много знаю о том, что было сделано, что было проверено и что осталось относительно неизведанным.
Самое главное, после того, как я все это узнал, я узнал, что я не знаю проклятую вещь. Перед лицом всего, что можно узнать, мои знания незначительны.
И я доволен этим. Но я рекомендую вам попробовать.
Настоящая история:
Когда я получил свою первую работу по программированию в аспирантуре, ребята, которым принадлежала компания, над которой я работал, были пилотами. Через несколько недель после того, как меня наняли, один из них задал мне этот вопрос:
В Арканзасе есть 106 аэропортов. Не могли бы вы написать программу, которая найти кратчайший маршрут, необходимый для землю на каждом из них?
Я серьезно думал, что он спрашивает меня о моих проблемах с проблемой коммивояжера и NP-полноты. Но оказалось, что нет. Он ничего не знал об этом. Он действительно хотел программу, которая найдет кратчайший путь. Он был удивлен, когда я объяснил, что существуют 106-факториальные решения, и найти лучший из них - хорошо известная проблема с вычислительной неразрешимостью.
Итак, один пример.
Конечно, это полезно.
Представьте, что разработчик работает над движком шаблонов. Вы знаете что-то...
Blah blah blah ${MyTemplateString} blah blah blah.
Это начинается просто, с нахальным маленьким регулярным выражением для замены заметок.
Но постепенно шаблоны становятся немного более причудливыми, а разработчик включает в себя функции для шаблонизации списков и карт строк. Для этого он пишет простую небольшую грамматику и генерирует парсер.
Получение очень хитрости, механизм шаблона может в конечном итоге включать в себя синтаксис условной логики, отображать различные блоки текста в зависимости от значений аргументов.
Кто-то с теоретической базой в CS признает, что язык шаблонов постепенно становится полным, и, возможно, шаблон Interpreter будет хорошим способом его реализации.
Создав интерпретатор для шаблонов, ученый-программист может заметить, что большинство запросов шаблонов являются дубликатами, повторяя одни и те же результаты снова и снова. Таким образом, кэш разработан, и все запросы маршрутизируются через кеш, прежде чем выполнять дорогостоящее преобразование.
Кроме того, некоторые шаблоны намного сложнее других и требуют много времени для рендеринга. Возможно, кто-то получает идею оценить выполнение каждого шаблона перед его рендерингом.
Но подождите!!! Кто-то из команды указывает, что если язык шаблонов действительно завершен Turing, тогда задача оценки времени выполнения каждой операции рендеринга является экземпляром проблемы с остановкой!! Yikes, не делай этого!!!
Вещь в теории на практике заключается в том, что всякая практика основана на теории. Теоретически.
То, что я использую больше всего:
Что касается этого материала на машинах Тьюринга и т.д., я думаю, что это важно, потому что он определяет ограничения, под которыми мы все работаем. Это важно оценить.
это разница между алгеброй обучения и обучением использованию калькулятора
Если вы знаете алгебру, вы понимаете, что одна и та же проблема может проявляться в разных формах, и вы понимаете правила преобразования проблемы в более сжатую форму
Если вы знаете только, как использовать калькулятор, вы можете потратить много времени на пробивание кнопок на проблему, которая либо (а) уже решена, (b) не может быть решена, либо (c) походит на некоторую другую проблему (решена или не решена), которую вы не узнаете, потому что она в другой форме
притворяться, на мгновение, что информатика - это физика... будет ли этот вопрос казаться глупым?
Мой друг работает над языком с некоторыми шаблонами. Меня попросили немного посоветоваться. Часть нашего обсуждения была посвящена функции шаблона, потому что, если шаблоны были полностью завершены, они должны были бы действительно рассматривать свойства VM-ish и как/если их компилятор поддерживал бы его.
Моя история такова: теория автоматов все еще учит, потому что она все еще имеет значение. Проблема с остановкой все еще существует и дает ограничение на то, что вы можете сделать.
Теперь, эти вещи имеют отношение к базе данных жокей, выбирая код С#? Возможно нет. Но когда вы перейдете на более продвинутый уровень, вы захотите понять свои корни и основы.
Хотя я не применяю их прямо в повседневной работе, я знаю, что мое образование по официальной информатике повлияло на мой процесс мышления. Я, конечно, избегаю определенных ошибок с самого начала, потому что у меня есть уроки, извлеченные из формальных подходов, которые мне привили.
Это может показаться бесполезным, пока они его изучают; но я уверен, что ваш одноклассник в конце концов столкнется с проблемой, когда они будут использовать то, чему их научили, или, по крайней мере, шаблоны мышления за ним...
Воск на... Воск выключен... Воск на... Воск выключен... Что это имеет отношение к Каратэ, в любом случае?
На одном задании мне была поручена задача улучшить наш алгоритм сетевой трассировки сети распределения, поскольку тот, который они использовали, был слишком медленным. Трехфазная сеть была по существу тремя n-деревьями (поскольку петли в электрических сетях не допускаются). Сетевые узлы находились в базе данных, и некоторые из первоначальной команды не могли понять, как построить модель в памяти, поэтому трассировка была выполнена с помощью последовательных глубинных SELECT в базе данных, фильтрация на каждой фазе. Таким образом, для трассировки node десяти узлов от подстанции потребуется не менее 10 запросов к базе данных (исходные члены команды были провалами в базе данных, но в алгоритмах не было достаточного фона).
Я написал решение, которое трансформировало 3 н-древовидные сети узлов из базы данных в структуру данных, где каждый node хранился один раз в структурном массиве node, а отношение n-tree было преобразовано в три двоичных деревья, используя двунаправленные указатели внутри массива, чтобы сеть можно было легко проследить в любом направлении.
Это было, по крайней мере, на два порядка быстрее, три на действительно длинных следах ниже по течению.
Печально то, что мне пришлось практически научить класс в n-деревьях, бинарных деревьях, указателях и двусвязных списках нескольким другим программистам, прошедшим обучение в базах данных и VB, чтобы они поняли алгоритмы.
Это классическая дихотомия, между "как" и "что". Ваши одноклассники смотрят "как" на программное обеспечение, и они очень сосредоточены на ближайшем фокусе; с этой точки зрения, перспектива реализации, кажется, что знание вещей, таких как состояния остановки и машины Тьюринга, неважно.
"Как" очень мало "от фактической работы, которую вы, как ожидается, будете делать с Computer Science. Фактически, большинство успешных инженеров, которых я знаю, вероятно, поставили бы его менее чем на 20 процентов от фактической работы." Что "делать гораздо важнее; и для этого важны основы компьютерной науки." То, что вы хотите сделать, гораздо больше связано с дизайном, чем с реализацией; и хороший дизайн... ну, позвольте просто называть его "нетривиальным".
"Существует два способа построения дизайна программного обеспечения: один из способов сделать его настолько простым, что, очевидно, нет недостатков, а наоборот - сделать его настолько сложным, что нет очевидных недостатков. первый метод намного сложнее". - CAR Хора
Удачи вам в учебе!
Я думаю, что понимание фундаментальных моделей вычислений полезно: уверен, что вам никогда не нужно будет переводить машину Тьюринга в машину регистрации на практике, но научиться видеть, что две очень разные проблемы действительно являются примерами одной и той же концепции является критическим навыком.
Большинство знаний не являются "практическими", но помогают вам соединять точки так, как вы не можете предвидеть, или дает вам более богатый словарь для описания более сложных идей.
Это не те специфические проблемы, которые вы изучаете, и это принципы, которые вы изучаете, изучая их. Я использую понятия об алгоритмах, структурах данных, языках программирования и операционных системах каждый день на своей работе. Если вы работаете программистом, вы будете принимать решения все время, влияющие на производительность системы. Вы должны иметь прочную основу в основных абстрактных понятиях, чтобы сделать правильный выбор.
Я не использую его ежедневно. Но это дало мне много понимания, которое помогает мне каждый день.
Я обнаружил, что все, что мне нужно для ежедневного блаженства из теоретического мира CS, - это высказывание мантры "Низкое сцепление и высокая сплоченность". Роджер С. Прессман сделал его научным до Стив Макконнелл сделало его модным.
Ya, я обычно использую диаграммы состояний для разработки формы и потока программы. Когда он работает теоретически, я начинаю кодирование и тестирование, проверяя состояния, когда я иду.
Я нахожу, что они также являются полезным инструментом для объяснения поведения процесса для других людей.
Simple. Например: если я использую RSACryptoServiceProvider, я хотел бы знать, что это такое и почему я могу доверять ему.
Поскольку шаблоны С++ на самом деле являются своего рода лямбда-исчислением. См. Www.cs.nott.ac.uk/types06/slides/michelbrink_types_06.pdf
Сейчас я изучаю курс "Распределенные алгоритмы". Существует глава о отказоустойчивости и содержит некоторые доказательства верхней границы того, сколько процессов может потерпеть неудачу (или ошибочно), чтобы распределенный алгоритм мог корректно обрабатывать ее.
Для многих проблем оценка для ошибочных процессов составляет до одной трети от общего числа процессов. Это очень полезно, на мой взгляд, потому что вы знаете, что бессмысленно пытаться разработать лучший алгоритм (при данных предположениях).
Даже если теоретические курсы не будут использоваться напрямую, это может помочь вам лучше подумать.
Вы не знаете, что ваш босс попросит вас сделать, вам, возможно, придется использовать то, что, по вашему мнению, не принесет пользы, как сказал Джеффри Л Уитледж.
Честно говоря, я не согласен с множеством ответов здесь. Я написал свой первый компилятор (для удовольствия, у меня действительно слишком много кофе/свободного времени), не пройдя курс в компиляторах; в основном я просто просмотрел код для другого компилятора и следил за шаблоном. Я мог написать парсер в C сверху, но я не думаю, что я мог вспомнить, как нарисовать автомат с откидной крышкой, если бы от этого зависела моя жизнь.
Когда я решил, что хочу поставить вывод типа на свой игрушечный (императивный) язык программирования, я сначала просмотрел, вероятно, пять бумаг, глядя на что-то, называемое "типизированным лямбда-исчислением", что-то....... * ***....? Сначала я попытался реализовать что-то с "универсальными переменными" и "неродственными переменными" и понятия не имел, что происходит. Затем я все это сломал и сидел там с записной книжкой, выясняя, как я мог ее реализовать практически с поддержкой всех необходимых мне вещей (подтипы, первоклассные функции, параметризованные типы и т.д.). Через пару дней мышления и записывая тестовые программы, я сдул больше, чем за неделю, пытаясь понять теоретическое дерьмо.
Зная основы вычислений (то есть как работает виртуальная память, как работают файловые системы, потоки/планирование, SMP, структуры данных), все это оказалось очень полезным. Иногда теория сложности и материал Big-O оказались полезными (особенно полезными для таких вещей, как дизайн RDBMS). Проблема остановки и автоматы/Теория машины Тьюринга? Никогда.
Если вы работаете в компании, которая делает потрясающую работу, важно иметь возможность общаться с архитекторами и разработчиками, какие преимущества. Существует много шумихи по поводу всех видов технологий, и позиционирование может быть затруднено. Когда вы создаете свои инновации в научных и теоретических терминах, вы определенно выигрываете, и клиенты чувствуют, что вы - настоящая вещь. Я могу сказать людям: есть новый способ справиться с состоянием, кодированием и недетерминизмом (т.е. Сложностями), и вы определенно можете быть более продуктивными, чем вы сегодня.
Если вы возьмете длинный взгляд в своей карьере, то изучение теории даст вам глубину, глубину, которую вам нужно вырастить. Возврат инвестиций в изучение вашего 5-го или 6-го языка программирования будет намного меньше, чем изучение второго и третьего. Воздействие теории даст вам смысл для реальной инженерии, где существуют степени свободы и как вы можете сделать правильные компромиссы.
Важные понятия 1) Состояние, 2) Кодирование, 3) Недетерминизм. Если вы их не знаете, они вам не помогут. Какая теория должна предоставить вам - это общая картина и ощущение того, как основные понятия подходят друг другу. Это должно помочь вам отточить свою интуицию.
Пример: в некоторых из приведенных выше ответов упоминаются проблемы с остановкой и машины Тьюринга. Когда я встретил бумагу Тьюринга в колледже, я совсем не чувствовал себя просветленным. Однажды я столкнулся с теоремой о неполноте Геделя и, в частности, номером Геделя. Вещи начали иметь большой смысл. Несколько лет спустя я прочитал о Георге Канторе в книжном магазине. Теперь я действительно начал понимать машины Тьюринга и проблему остановки. Попробуйте сами и посмотрите "Канторский диагональный аргумент" в Википедии. Это одна из самых удивительных вещей, с которой вы когда-либо столкнетесь.
Пища для размышлений: Типичная машина Тьюринга - не единственный способ создать машину перехода состояния. Машина Тьюринга с двумя, а не одной лентой даст вам намного больше скорости для ряда алгоритмов. http://www.math.ucla.edu/~ynm/papers/eng.ps
Вы можете более эффективно подвергать себя этим соображениям, чем я, прочитав эту книгу. Ссылка внизу этой публикации. (По крайней мере, ознакомьтесь с оглавлением на Amazon, чтобы получить представление о том, что это такое):
Я нашел книгу Розенберга сенсационной. http://www.amazon.com/The-Pillars-Comput-Theory-Nondeterminism/dp/0387096388 Если у вас есть только одна книга по теории ИМХО это должно быть одно.
После того, как я окончил CS, я подумал так: вся куча теорий, которые мы изучали, на практике совершенно бесполезна. Это оказалось правильным в течение короткого периода времени, однако в тот момент, когда вы занимаетесь сложными задачами, теория, безусловно, БОЛЕЕ ЗНАЧИТЕЛЬНАЯ, чем практика. каждый после нескольких лет кодирования может писать некоторые программы, которые "работают", но не каждый может понять, как это сделать. независимо от того, что большинство из нас будет решать в определенный момент с проблемами производительности, задержками в сети, прецессией, масштабируемостью и т.д. На этом этапе теория имеет решающее значение. для разработки хорошего решения при работе с сложными системами очень важно знать, как работает управление памятью, концепции процесса и потоков, как им назначена память или эффективные структуры данных для производительности и т.д.
Однажды, например, я работал над проектом, включающим множество математических вычислений, и в определенный момент наше программное обеспечение потерпело неудачу. во время отладки я понял, что после некоторой математической операции я получил число как DOUBLE значения 1.000000000002, но с математической точки зрения не могло быть > 1, которое на каком-то более позднем этапе программы давало легендарное NaN исключение, я потратил некоторое время, чтобы понять это, но если бы я уделил больше внимания "приближению двойного и плавающего" урока, я бы не потратил впустую это время.
Я знаю, что это старо, но мой короткий ответ тем, кто утверждает, что теория "бесполезна" и что они могут практиковать свою профессию без этого:
Без основной теории нет практики.
Почему теория полезна?
Теория - это основа, на которой построены другие вещи. Когда теория применяется, практика является результатом.
Рассматривайте компьютеры сегодня. Общий компьютер сегодня моделируется и строится поверх машины Тьюринга, которая, чтобы упростить ее, является абстрактной/теоретической моделью для вычисления. Эта теоретическая модель лежит в основе вычислений, и все вычислительные устройства, которые мы используем сегодня, от высокопроизводительных серверов до карманных телефонов, работают, потому что базовая основа звучит.
Рассмотрите анализ алгоритмов. Проще говоря, анализ алгоритмов и теория сложности во времени были использованы для классификации проблем (например, P, NP, EXP и т.д.), а также того, как ведут себя алгоритмы при попытке решить различные проблемы в разных классах.
Предположим, что один из ваших друзей получает задание в каком-то месте X и, хотя там, менеджер делает несколько простых запросов, таких как эти примеры:
Пример 1: У нас есть большой парк транспортных средств, которые посещают разные города в нескольких штатах. Мы нуждаемся в вас, чтобы внедрить систему, чтобы выяснить, какой самый короткий маршрут для каждого транспортного средства и выбрать оптимальный из всех возможностей. Можете ли вы это сделать?
Мысль о том, что теория "бесполезна", твои друзья не понимают, что им только что дали Задачу Путешественника (TSP) и начать разработку этой системы без второй мысли, только чтобы обнаружить их наивную попытку проверить все возможности, как изначально запрошенные, настолько медленны, что их система непригодна для любых практических целей.
На самом деле они понятия не имеют, почему система работает на "приемлемом" уровне при проверке 5 городов, но становится очень медленной в 10 городах и просто замерзает при достижении только 40 городов. Они считают, что это всего лишь "2x и 8x больше городов, чем 5 городских тестов", и удивляйтесь, почему программа не просто требует "2x и 8x больше времени" соответственно...
Понимание теории позволило бы им понять следующее, по крайней мере с первого взгляда:
Числа говорят сами за себя:
+--------------+-------+-----------------------------------------------------------------+
| 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
+--------------+-------+-----------------------------------------------------------------+
Они могли осознать с самого начала, что их система не будет работать, как они себе представляли. Позднее система считалась непрактичной и отменена после того, как значительное количество времени, усилий и других ресурсов было выделено и, в конечном счете, потрачено впустую на проект - и все потому, что теория мысли бесполезна ".
Итак, после этого сбоя менеджеры подумали: "Ну, может быть, эта система была недооценена, ведь в нашей стране много городов, и наши компьютеры просто не так быстро, как нам нужно, чтобы они были для нашего недавнего отменил систему, чтобы добиться успеха".
Команда управления обвиняет медленные компьютеры в качестве причины отказа проекта. В конце концов, они не являются экспертами в теории CS, не обязательно, и те, кто должен быть экспертами по этой теме и могли бы сообщить им, не сделали.
Но у них есть другой проект. На самом деле проще. Они приходят через неделю и спрашивают:
Пример 2: У нас есть только несколько серверов, и у нас есть программисты, которые продолжают отправлять программы, которые по неизвестным причинам заканчиваются бесконечными циклами и забивают серверы. Нам нужно, чтобы вы записали программу, которая будет обрабатывать передаваемый код, и определить, приведет ли поданная программа к бесконечному циклу во время ее прогона или нет, и решить, разрешить ли предлагаемой программе работать на этой основе. Можете ли вы это сделать?
Ваш дорогой друг снова примет вызов и немедленно отправится на работу. После нескольких недель работы нет результатов, ваш друг подчеркнул, и не знает, что делать. Еще один провал... ваш друг теперь чувствует себя "глупым" за то, что не смог решить эту "простую проблему"... в конце концов, сам запрос сделал это простым.
К сожалению, ваш друг, настаивая на том, что "теория бесполезна", не понимала, что, по-видимому, простая просьба была на самом деле проблемой, которая не может быть решена (например, проблема остановки) и что не было известного решения для Это. Это была невыполнимая задача.
Поэтому даже начало работы по решению этой конкретной проблемы было предотвратимой и предотвратимой ошибкой. Если бы теоретические основы для понимания того, что запрашивалось, они могли бы предложить другое и достижимое решение... например, внедрение процесса мониторинга, который может просто kill -SIGTERM <id> любого пользовательского процесса (согласно список пользователей), который монополизирует ЦП для некоторого произвольного/разумного интервала при определенных предположениях (например, мы знаем, что каждый запуск программы должен был завершиться в течение 10 минут, поэтому любой экземпляр, работающий в течение 20 + минут, должен быть kill ed).
В заключение практика без теории похожа на здание без фундамента. Рано или поздно правильное количество давления под прямым углом заставит его рухнуть на себя. Нет исключений.
Вы когда-нибудь использовали его в своем ежедневном кодировании?
Да, но не напрямую. Скорее, мы полагаемся на это косвенно. Здесь предостережение заключается в том, что различные теоретические концепции будут более или менее применимы в зависимости от проблемной области, с которой вы работаете.
Конечно, мы:
Это тот факт, что кто-то, кто просто использует самолет для путешествий, не нуждается в понимании теории, которая даже позволяла строить самолеты и летать в первую очередь... но когда кто-то должен строить указанные машины и делать они работают... можете ли вы действительно ожидать хорошего результата от человека, который не понимает даже принципов полета?
Было ли действительно совпадением, что на протяжении большей части истории никто не мог построить летающую машину (а некоторые даже умерли, испытав их), пока братья Райт не поняли определенные теоретические концепции о полете и не смогли применить их на практике
Это не случайно. Сегодня у нас много рабочих технологий, потому что люди, которые их построили, поняли и применили теоретические принципы, которые позволили им работать в первую очередь.
Я думаю, это зависит от того, в какое поле вы входите.