theory - segun - que es la teoria memetica

¿Cuándo es útil la informática teórica? (24)

Aunque no los aplico directamente en el trabajo diario, sé que mi educación en informática formal ha afectado mi proceso de pensamiento. Ciertamente evito ciertos errores desde el inicio porque tengo las lecciones aprendidas de los enfoques formales que me inculcaron.

Puede parecer inútil mientras lo aprenden; pero apuesto a que tu compañero de clase eventualmente se encontrará con un problema en el que usarán lo que se les enseñó, o al menos los patrones de pensamiento detrás de eso ...

Cera encendida ... Cera apagada ... Cera encendida ... Cera ... ¿Qué tiene eso que ver con Karate, de todos modos?

En clase, aprendimos sobre el problema de detenerse, las máquinas de Turing, las reducciones, etc. Muchos compañeros de clase dicen que estos son conceptos abstractos e inútiles, y no hay ningún punto real en conocerlos (es decir, puedes olvidarlos una vez que el curso es más y no perder nada).

¿Por qué la teoría es útil? ¿Alguna vez lo usaste en tu codificación diaria?

Claro, es útil.

Imagine un desarrollador que trabaja en un motor de plantillas. Usted sabe el tipo de cosas...

Blah blah blah ${MyTemplateString} blah blah blah.

Comienza de manera simple, con una pequeña y descarada expresión regular para reformar los reemplazos.

Pero, gradualmente, las plantillas se vuelven un poco más sofisticadas, y el desarrollador incluye características para listas de plantillas y mapas de cadenas. Para lograr eso, escribe una pequeña gramática simple y genera un analizador sintáctico.

Siendo muy astuto, el motor de plantillas podría eventualmente incluir una sintaxis para la lógica condicional, para mostrar diferentes bloques de texto dependiendo de los valores de los argumentos.

Alguien con una formación teórica en CS reconocería que el lenguaje de la plantilla se está convirtiendo lentamente en completo, y tal vez el patrón de Intérprete sería una buena manera de implementarlo.

Después de haber construido un intérprete para las plantillas, un científico de la computación podría notar que la mayoría de las solicitudes de plantillas son duplicados, regenerando los mismos resultados una y otra vez. Por lo tanto, se desarrolla un caché y todas las solicitudes se enrutan a través del caché antes de realizar la costosa transformación.

Además, algunas plantillas son mucho más complejas que otras y tardan más tiempo en renderizarse. Tal vez alguien tenga la idea de estimar la ejecución de cada plantilla antes de representarla.

¡¡¡Pero espera!!! Alguien en el equipo señala que, si el lenguaje de la plantilla realmente está completo, entonces la tarea de estimar el tiempo de ejecución de cada operación de renderización es una instancia del problema de detención. ¡Ay, no hagas eso!

Lo que pasa con la teoría, en la práctica, es que todas las prácticas se basan en la teoría. Teóricamente

Creo que es útil comprender los modelos fundamentales de computación: seguro que nunca es necesario poder traducir una máquina de Turing a una máquina de registro en la práctica, pero aprender a ver que dos problemas muy diferentes son en realidad ejemplos del mismo concepto es crítico. habilidad.

Descubrí que todo lo que necesito para la felicidad cotidiana del mundo teórico CS es la expresión del mantra "Bajo acoplamiento y alta cohesión". Roger S. Pressman lo hizo académico antes de que Steve McConnell lo pusiera de moda.

Historia verdadera:

Cuando obtuve mi primer trabajo de programación fuera de la escuela de postgrado, los tipos que eran dueños de la empresa para la que trabajaba eran pilotos. Unas semanas después de que me contrataron, uno de ellos me hizo esta pregunta:

Hay 106 aeropuertos en Arkansas. ¿Podría escribir un programa que encontraría la ruta más corta necesaria para aterrizar en cada uno de ellos?

En serio, pensé que me estaba interrogando sobre mi conocimiento del Problema de Vendedor Viajero y NP-Completitud. Pero resulta que no fue así. Él no sabía nada al respecto. Él realmente quería un programa que encontraría el camino más corto. Se sorprendió cuando le expliqué que había 106 soluciones factoriales y que encontrar el mejor era un problema computacionalmente difícil de resolver.

Entonces ese es un ejemplo.

La mayoría del conocimiento no es "práctico", pero te ayuda a conectar puntos de formas que no puedes anticipar, o te da un vocabulario más rico para describir ideas más complejas.

Las cosas que uso más:

complejidad computacional para escribir algoritmos que escala con gracia
Comprensión de cómo funcionan la asignación de memoria, la paginación y el almacenamiento en caché de la CPU, así puedo escribir un código eficiente
comprensión de las estructuras de datos
comprensión de enhebrar, bloquear y problemas asociados

En cuanto a eso en las máquinas de Turing, etc., creo que es importante porque define las restricciones bajo las cuales todos operamos. Eso es importante de apreciar

No lo uso a diario. Pero me dio mucho entendimiento que me ayuda cada día.

Supongo que depende de en qué campo entren.

Un amigo mío está trabajando en un idioma con algunas plantillas. Me pidieron que hiciera un poco de consultoría. Parte de nuestra discusión fue sobre la característica de plantilla, porque si las plantillas se completaran, tendrían que considerar realmente las propiedades de VM-ish y cómo / si su compilador las soportaría.

Mi historia es sobre este punto: la teoría de autómatas aún se enseña, porque todavía tiene relevancia. El problema de detención todavía existe y proporciona un límite a lo que puede hacer.

Ahora, ¿estas cosas tienen relevancia para un jinete de base de datos que elabora el código C #? Probablemente no. Pero cuando empiece a moverse a un nivel más avanzado, querrá comprender sus raíces y fundamentos.

Es una dicotomía clásica, entre "cómo" y "qué". Tus compañeros de clase están buscando "cómo" programar el software, y están muy enfocados en el enfoque cercano; desde esa perspectiva, desde la perspectiva de la implementación, parece que saber cosas como detener los estados y las máquinas de Turing no son importantes.

Sin embargo, "cómo" es muy poco del trabajo real que se espera que haga con la informática. De hecho, la mayoría de los ingenieros exitosos que conozco probablemente lo pondrán en menos del 20 por ciento del trabajo real. "Qué" hacer es mucho más importante; y para eso, los fundamentos de la informática son críticos. "Lo que" desea hacer se relaciona mucho más con el diseño que con la implementación; y un buen diseño es ... bueno, llamémoslo "no trivial".

"Hay dos formas de construir un diseño de software: una forma es hacerlo tan simple que obviamente no hay deficiencias, y la otra es hacerlo tan complicado que no haya deficiencias obvias. El primer método es mucho más difícil. " - CAR Hoare

¡Buena suerte con sus estudios!

No son los problemas específicos que estudias lo que importa, sino los principios que aprendes al estudiarlos. Utilizo conceptos sobre algoritmos, estructuras de datos, lenguajes de programación y sistemas operativos todos los días en mi trabajo. Si trabajas como programador, tomarás decisiones todo el tiempo que afecten el rendimiento del sistema. Debe tener una base sólida en los conceptos abstractos fundamentales para tomar las decisiones correctas.

Ya, generalmente uso diagramas de estado para diseñar la forma y el flujo del programa. Una vez que funciona en teoría, comienzo a codificar y probar, marcando los estados a medida que avanzo.

Encuentro que también son una herramienta útil para explicar el comportamiento de un proceso a otras personas.

Cuando me gradué de la universidad, asumí que estaba a la par con todos los demás: "Tengo un BS en CS, y también lo hacen muchas otras personas, y todos podemos hacer esencialmente las mismas cosas". Eventualmente descubrí que mi suposición era falsa. Me destaqué, y mi formación tenía mucho que ver con eso, particularmente mi título.

Sabía que había una "pequeña" diferencia, ya que tenía un "BS" en CS porque mi universidad fue una de las primeras (supuestamente # 2 en 1987) en el país en recibir la acreditación para su programa de licenciatura en CS, y yo se graduó en la segunda clase para tener esa acreditación. En ese momento, no pensé que importaba mucho.

También me di cuenta durante la escuela secundaria y en la universidad que lo hice especialmente bien en CS, mucho mejor que mis compañeros e incluso mejor que muchos de mis profesores. Me pidieron mucha ayuda, hice algunas tutorías, me pidieron que ayudara con un proyecto de investigación, y me permitieron hacer un estudio independiente cuando no había nadie más. Me alegré de poder ayudar, pero no pensé mucho acerca de la diferencia.

Después de la universidad (USAFA), pasé cuatro años en la Fuerza Aérea, dos de los cuales aplicaban mi título de CS. Allí noté que muy pocos de mis compañeros de trabajo tenían títulos o incluso capacitación relacionada con las computadoras. La Fuerza Aérea me envió a cinco meses de entrenamiento de certificación, donde nuevamente encontré una falta de títulos o entrenamiento. Pero aquí empecé a notar la diferencia: se hizo totalmente obvio que muchas de las personas con las que me encontré realmente NO sabían lo que estaban haciendo, y eso incluía a las personas con entrenamiento o títulos. Permíteme por favor para ilustrar.

En mi entrenamiento de certificación de la Fuerza Aérea había un total de trece personas (incluyéndome a mí). Como oficiales de la Fuerza Aérea o su equivalente, todos teníamos títulos de BS. Estaba en el medio según la edad y el rango (era un O-2 entre seis O-1 y seis O-3 y superiores). Al final de este entrenamiento, la Fuerza Aérea nos selló a todos como igualmente competentes para adquirir, construir, diseñar, mantener y operar CUALQUIER computadora o sistema de comunicación para CUALQUIER parte del Departamento de Defensa.

Sin embargo, de los trece de nosotros, solo seis tenían algún tipo de título relacionado con la informática; los otros siete tenían grados que van desde la aeronáutica a la química / biología a la psicología. De los seis de nosotros con títulos de CS, me enteré de que dos nunca habían escrito un programa de ningún tipo y que nunca habían usado una computadora más que por casualidad (escribir documentos, jugar juegos, etc.). Aprendí que otros dos de nosotros habíamos escrito exactamente un programa en una sola computadora durante su programa de CS degree. Solo una persona más y yo habíamos escrito más de un programa o habíamos usado más de un tipo de computadora; de hecho, descubrimos que nosotros dos habíamos escrito muchos programas y utilizado muchos tipos de computadoras.

Hacia el final de nuestra capacitación de cinco meses, a nuestra clase se le asignó un proyecto de programación y nos dividieron en cuatro grupos para que lo llevaran a cabo por separado. Nuestros instructores dividieron la clase para distribuir el "talento de programación" de manera justa, y asignaron roles de líder de equipo, líder tecnológico y desarrollador. A cada grupo se le dio una semana para implementar (en Ada) una interfaz de usuario de pantalla completa, basada en texto (esto fue en 1990) para un simulador de vuelo en la parte superior de una biblioteca de mecánica de vuelo proporcionada por un instructor. Fui asignado como líder tecnológico para mi equipo de cuatro.

El líder de mi equipo (que no tenía un título en informática) nos pidió a los otros tres que dividiéramos el proyecto en tareas y luego le asignamos un tercio a cada uno de nosotros. Terminé mi tercera tarea a mediados del primer día, luego pasé el resto del día ayudando a mis otros dos compañeros de equipo, hablando con el líder de mi equipo (BSing; ^) y jugando en mi computadora.

A la mañana siguiente (día dos), el líder de mi equipo me informó en privado que nuestros otros dos compañeros no habían progresado (uno no podía escribir una declaración "si" que compilaría) y me pidió que asumiera su trabajo. Terminé el proyecto completo a media tarde, y mi equipo pasó el resto del día volando el simulador.

El otro tipo con el grado CS comparable también fue asignado como líder técnico para su equipo, y terminaron al final del tercer día. También comenzaron a volar su simulador. Los otros dos equipos no habían terminado, o incluso hecho un progreso significativo, para el final de la semana. No se nos permitió ayudar a otros equipos, por lo que quedó en eso.

Mientras tanto, a la mitad del tercer día, noté que el simulador de vuelo parecía comportarse "mal". Como uno de mis compañeros de clase tenía un título en aeronáutica, le pregunté al respecto. Él estaba desconcertado, y luego confesó que no sabía realmente lo que hacía volar un avión. ¡Me quedé estupefacto! Resulta que todo su programa de grado fue sobre investigaciones de seguridad y choques, no hay matemática real o ciencia detrás del vuelo. Por otro lado, quizás tenía un menor en aeronáutica (¿recuerdas USAFA?), Pero habíamos diseñado alas y realizamos pruebas reales en túneles de viento. Por lo tanto, silenciosamente pasé el resto de la semana reescribiendo la biblioteca de mecánica de vuelo proporcionada por el instructor hasta que el simulador voló "a la derecha".

Desde entonces, he pasado casi dos décadas como contratista y ocasionalmente como empleado, siempre haciendo desarrollo de software más actividades relacionadas (DBA, arquitecto, etc.). He seguido encontrando más de lo mismo, y finalmente abandoné mi suposición juvenil.

Entonces, ¿qué es exactamente lo que descubrí? No todos son iguales, y eso está bien. No soy una persona mejor porque puedo programar de manera efectiva, pero soy más útil SI eso es lo que necesitas de mí. Aprendí que mi formación realmente importaba: crecer en una familia de electricistas e ingenieros eléctricos, fabricar juegos de electrónica, leer LITERALMENTE cada libro de informática en las bibliotecas escolares / públicas porque no tenía acceso a una computadora real, y luego pasar a una nueva ciudad donde mi escuela secundaria tenía computadoras, luego obtenía mi propia computadora como regalo, yendo a escuelas que tenían computadoras de diferentes tamaños y tipos (PC a mainframes), obteniendo un título acreditado de una escuela de ingeniería MUY buena, teniendo que escribir muchos programas en diferentes idiomas en diferentes tipos de computadoras, tener que escribir programas duros (como mi propia máquina virtual con un lenguaje ensamblador personalizado o una implementación de compresión Huffman, etc.), tener que solucionar mis problemas, crear mis propias computadoras desde partes e instalar TODO el software, etc.

Finalmente, aprendí que mis habilidades se basan en saber cómo funcionan las computadoras desde el nivel eléctrico hacia arriba: componentes electrónicos discretos, circuitos, subsistemas, interfaces, protocolos, bits, bytes, procesadores, dispositivos, controladores, bibliotecas, programas. , sistemas, redes, hasta los conglomerados masivos de clase empresarial en los que rutinariamente trabajo ahora. Entonces, cuando la maldita cosa se comporta mal, sé exactamente CÓMO y POR QUÉ. Y sé lo que no se puede hacer tan bien como lo que se puede. Y sé mucho sobre lo que se ha hecho, lo que se ha intentado y lo que queda relativamente inexplorado.

Lo más importante, después de haber aprendido todo eso, he aprendido que no sé nada. Frente a todo lo que potencialmente hay que saber, mi conocimiento es minúsculo.

Y estoy bastante contento con eso. Pero te recomiendo que lo intentes.

Sencillo. Por ejemplo: si estoy usando RSACryptoServiceProvider, me gustaría saber qué es eso y por qué puedo confiar en él.

es la diferencia entre aprender álgebra y aprender a usar una calculadora

si conoces álgebra, te das cuenta de que el mismo problema puede manifestarse en diferentes formas, y entiendes las reglas para transformar el problema en una forma más concisa

Si solo sabe cómo usar una calculadora, puede perder mucho tiempo presionando botones en un problema que ya sea (a) ya resuelto, (b) no se puede resolver, o (c) es como algún otro problema (resuelto o sin resolver) que no reconoce porque está en una forma diferente

pretender, por un momento, que la informática es física ... ¿le parecería tonta la pregunta?

En un trabajo se me asignó la tarea de mejorar el algoritmo de rastreo de red de nuestro modelo de distribución eléctrica ya que el que estaban usando era demasiado lento. La red trifásica era esencialmente tres n-árboles (ya que los bucles no están permitidos en las redes eléctricas). Los nodos de red estaban en la base de datos y parte del equipo original no pudo encontrar la manera de construir un modelo en memoria, por lo que el rastreo se realizó mediante sucesivos SELECT de profundidad en la base de datos, filtrando en cada fase. Por lo tanto, para rastrear un nodo, diez nodos de la subestación requerirían al menos 10 consultas de bases de datos (los miembros originales del equipo eran zumbidos de la base de datos, pero carecían de un historial decente en algoritmos).

Escribí una solución que transformó las 3 redes nano de nodos de la base de datos en una estructura de datos donde cada nodo se almacenó una vez en una matriz de estructura de nodos y la relación n-tree se convirtió en tres árboles binarios utilizando punteros doblemente vinculados la matriz para que la red pueda rastrearse fácilmente en cualquier dirección.

Fue al menos dos órdenes de magnitud más rápido, tres en trazas muy largas aguas abajo.

Lo triste fue que tuve que enseñar prácticamente una clase en n-árboles, árboles binarios, punteros y listas doblemente vinculadas a varios de los otros programadores que habían sido entrenados en bases de datos y VB para que pudieran entender los algoritmos.

Porque las plantillas de C ++ son realmente un tipo de cálculo lambda. Consulte www.cs.nott.ac.uk/types06/slides/michelbrink_types_06.pdf

Estoy estudiando para mi curso de algoritmos distribuidos ahora. Hay un capítulo sobre tolerancia a fallas y contiene algunas pruebas en el límite superior de cuántos procesos pueden fallar (o portarse mal) para que el algoritmo distribuido pueda manejarlo correctamente.

Para muchos problemas, el límite para los procesos que no funcionan es de hasta un tercio del número total de procesos. Esto es bastante útil en mi opinión porque sabes que no tiene sentido intentar desarrollar un mejor algoritmo (bajo supuestos dados).

Incluso si los cursos teóricos no se van a utilizar directamente, podría ayudarlo a pensar mejor de algo.

No sabe lo que su jefe le va a pedir que haga, puede que tenga que usar algo que pensó que no sería beneficioso, como dijo Jeffrey L. Whitledge.

Para ser sincero, estoy un poco en desacuerdo con muchas de las respuestas aquí. Escribí mi primer compilador (por diversión, realmente tengo demasiado café / tiempo libre) sin haber tomado un curso de compiladores; básicamente escaneé el código de otro compilador y seguí el patrón. Podría escribir un analizador sintáctico en C de la parte superior de mi cabeza, pero no creo poder recordar cómo dibujar un autómata de empuje si mi vida dependía de ello.

Cuando decidí que quería poner inferencia de tipo en mi lenguaje de programación de juguetes (imperativo), primero revisé probablemente cinco documentos, mirando algo llamado "cálculo lambda mecanografiado" yendo a qué ... el ... **** ....? Al principio intenté implementar algo con "variables genéricas" y "variables no genéricas" y no tenía idea de lo que estaba pasando. Luego lo descarté todo, y me senté allí con un cuaderno descubriendo cómo podría implementarlo prácticamente con soporte para todo lo que necesitaba (subtipos, funciones de primera clase, tipos parametrizados, etc.) con un par de días de pensamiento y escribiendo programas de prueba, desperdicié más de una semana tratando de descubrir la basura teórica.

Conocer los conceptos básicos de la informática (es decir, cómo funciona la memoria virtual, cómo funcionan los sistemas de archivos, enhebrar / programar, SMP, estructuras de datos) ha demostrado ser ALTAMENTE útil. La teoría de la complejidad y Big-O a veces ha demostrado ser útil (especialmente útil para cosas como el diseño de RDBMS). ¿El problema de la detención y la teoría de la máquina autómata / Turing? Nunca.

Después de graduarme de CS, pensé de manera similar: todo el conjunto de teorías que estudiamos son completamente inútiles en la práctica. Esto resultó ser correcto durante un corto período de tiempo, sin embargo, en el momento en que se ocupa de tareas complejas, la teoría es definitivamente MÁS VALIOSA que la práctica. cada uno después de algunos años de codificación puede escribir algunos programas que "funcionan", pero no todos son capaces de entender cómo. no importa lo que la mayoría de nosotros trate en un cierto punto con problemas de rendimiento, retrasos de red, precisión, escalabilidad, etc. En esta etapa, la teoría es crítica. para diseñar una buena solución cuando se trata de sistemas complejos es muy importante saber cómo funciona la administración de memoria, los conceptos de proceso y subprocesos, cómo se les asigna la memoria, o estructuras de datos eficientes para el rendimiento, etc.

Una vez, por ejemplo, estaba trabajando en un proyecto que incluía muchos cálculos matemáticos y, en cierto punto, nuestro software falló. Mientras depuraba, descubrí que después de una operación matemática, recibí un número como DOBLE de un valor 1.000000000002, pero desde la perspectiva matemática no podía ser> 1, que en una etapa posterior del programa daba la legendaria excepción NaN . Pasé algún tiempo para resolver esto, pero si hubiera prestado más atención a la lección " Aproximación de Doble y Flotante ", no hubiera desperdiciado ese tiempo.

Si trabaja en una empresa que realiza un trabajo pionero, es importante poder comunicar a los arquitectos y desarrolladores cuáles son los beneficios. Hay mucha exageración sobre todo tipo de tecnologías y posicionarse puede ser difícil. Cuando enmarca su innovación en términos científicos y teóricos, definitivamente tiene una ventaja y los clientes sienten que usted es el verdadero. Puedo decirle a la gente: hay una nueva forma de lidiar con el estado, la codificación y el no determinismo (es decir, las complejidades) y definitivamente puede ser más productivo de lo que es hoy.

Si tomas la visión a largo plazo en tu carrera, aprender sobre teoría te dará profundidad, la profundidad que necesitas para crecer. El retorno de la inversión en el aprendizaje de su 5º o 6º lenguaje de programación será mucho menor que el aprendizaje de su 2º y 3º. La exposición a la teoría le dará un sentido para la ingeniería real, sobre dónde están los grados de libertad y cómo puede hacer las concesiones correctas.

Los conceptos importantes 1) Estado, 2) Codificación, 3) No determinismo. Si no los conoces, no te ayudarán. Lo que la teoría debería proporcionarle es el panorama general y una idea de cómo los conceptos básicos encajan. Debería ayudarlo a perfeccionar su intuición.

Ejemplo: algunas de las respuestas anteriores mencionan el problema de detención y las máquinas de Turing. Cuando me encontré con el trabajo de Turing en la universidad, no me sentí iluminado en absoluto. Un día encontré el teorema de la incompletud de Goedel y la numeración de Goedel en particular. Las cosas comenzaron a tener mucho sentido. Años después leí sobre Georg Cantor en una librería. Ahora realmente comencé a entender las máquinas de Turing y el problema de la detención. Pruébelo usted mismo y busque "Diagonal Argumento de Cantor" en Wikipedia. Es una de las cosas más increíbles intelectualmente que encontrarás.

Algo en lo que pensar: una máquina Turing típica no es la única forma de diseñar una máquina de transición de estado. Una máquina de Turing con dos cintas en lugar de una le daría mucha más velocidad para una serie de algoritmos. http://www.math.ucla.edu/~ynm/papers/eng.ps

Puede exponerse a estas ideas más eficientemente que yo leyendo este libro. Enlace al final de esta publicación. (Por lo menos, revisa la tabla de contenido en Amazon para obtener una idea de lo que se trata):

El libro de Rosenberg me pareció sensacional. http://www.amazon.com/The-Pillars-Computation-Theory-Nondeterminism/dp/0387096388 Si tiene un solo libro en teoría en mi humilde opinión, este debería ser el indicado.

Sé que esto es viejo, pero mi breve respuesta a los que afirman que la teoría es "inútil" y que pueden practicar su profesión sin ella es la siguiente:

Sin la teoría subyacente, no hay práctica.

¿Por qué la teoría es útil?

La teoría es la base subyacente sobre la cual se construyen otras cosas. Cuando se aplica la teoría, la práctica es el resultado.

Considera las computadoras hoy. La computadora común hoy en día se modela y se construye sobre la Máquina Turing, que, para simplificar, es un modelo abstracto / teórico para la computación. Este modelo teórico se encuentra en la base de la informática, y todos los dispositivos informáticos que utilizamos en la actualidad, desde servidores de gama alta hasta teléfonos de bolsillo, funcionan porque la base subyacente es sólida.

Considera el análisis de algoritmos. En términos simples, el análisis algorítmico y la teoría de la complejidad temporal se han utilizado para clasificar problemas (p. Ej., P, NP, EXP, etc.), así como la forma en que los algoritmos se han comportado al tratar de resolver diferentes problemas en diferentes clases.

Supongamos que uno de tus amigos consigue un trabajo en algún lugar X y, mientras está allí, un administrador realiza algunas simples solicitudes, como estos ejemplos:

Ej. 1: Tenemos una gran flota de vehículos de reparto que visitan diferentes ciudades en varios estados. Necesitamos que implemente un sistema para descubrir cuál es la ruta más corta para cada vehículo y elegir la óptima de entre todas las posibilidades. ¿Puedes hacerlo?

Al pensar que la teoría es "inútil", tus amigos no se dan cuenta de que acaban de recibir el Problema de Vendedor Viajero (TSP) y comienzan a diseñar este sistema sin pensarlo dos veces, solo para descubrir su ingenuo intento de verificar todas las posibilidades, como originalmente solicitado, es tan lento que su sistema no se puede usar para ningún propósito práctico.

De hecho, no tienen idea de por qué el sistema funciona a un nivel "aceptable" al consultar 5 ciudades, pero se vuelve muy lento en 10 ciudades, y simplemente se congela cuando llega a solo 40 ciudades. Ellos razonan que solo son "2x y 8x más ciudades que las 5 pruebas de la ciudad" y se preguntan por qué el programa no solo requiere "2x y 8x más tiempo" respectivamente ...

Comprender la teoría les habría permitido realizar lo siguiente, al menos de un vistazo:

Es el TSP
El TSP es NP-duro
El orden de crecimiento de su algoritmo es O (n!)

Los números hablan por si mismos:

+--------------+-------+-----------------------------------------------------------------+ | 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 +--------------+-------+-----------------------------------------------------------------+

Al principio se habrían dado cuenta de que su sistema no iba a funcionar como imaginaban. Posteriormente, se consideró que el sistema no era práctico y se canceló después de que se asignara una cantidad significativa de tiempo, esfuerzo y otros recursos, y finalmente se desperdiciara en el proyecto, y todo porque el pensamiento "la teoría es inútil".

Entonces, después de este fracaso, los gerentes piensan "Bueno, tal vez ese sistema fue subestimado, después de todo, hay MUCHAS ciudades en nuestro país y nuestras computadoras simplemente no son tan rápidas como las necesitamos para nuestro sistema recientemente cancelado. ha sido un éxito ".

El equipo de gestión culpa a las computadoras lentas como la causa de la falla del proyecto. Después de todo, no son expertos en teoría de CS, no necesitan serlo, y aquellos que se supone que son expertos en el tema y podrían haberles informado, no lo hicieron.

Pero tienen otro proyecto en mente. Una más simple en realidad. Vienen la semana más tarde y preguntan lo siguiente:

Ej 2: Tenemos solo unos pocos servidores y tenemos programadores que siguen enviando programas que, por razones desconocidas, terminan en ciclos infinitos y acaparan los servidores. Necesitamos que escriba un programa que procesará el código que se envía y detectará si el programa enviado causará un ciclo infinito durante su ejecución o no, y decidirá si el programa enviado debe ejecutarse sobre esta base. ¿Puedes hacerlo?

Tu querido amigo acepta el desafío nuevamente y se pone a trabajar de inmediato. Después de varias semanas de trabajo, no hay resultados, su amigo está estresado y no sabe qué hacer. Sin embargo, otro error ... su amigo ahora se siente "tonto" por no haber podido resolver este "problema simple" ... después de todo, la solicitud en sí lo hizo sonar simple.

Desafortunadamente, su amigo, al insistir en que "la teoría es inútil" no se dio cuenta de que la solicitud, supuestamente simple, era en realidad un problema insoluble sobre la decidabilidad (es decir, el problema de detención) y que no había una solución conocida para ello. Fue una tarea imposible.

Por lo tanto, incluso comenzar a trabajar para resolver ese problema en particular fue un error evitable y prevenible. Si el marco teórico para entender lo que se estaba solicitando estuviera en su lugar, podrían haber propuesto una solución diferente y alcanzable ... como implementar un proceso de monitoreo que simplemente puede kill -SIGTERM <id> de cualquier proceso de usuario ( según una lista de usuarios) que monopoliza la CPU por algún intervalo arbitrario / razonable bajo ciertas suposiciones (por ejemplo, sabemos que cada ejecución del programa debería haber terminado en 10 minutos, por lo que cualquier instancia que se ejecute durante más de 20 minutos debería kill ).

En conclusión, la práctica sin la teoría es como un edificio sin una base . Tarde o temprano, la cantidad correcta de presión desde el ángulo correcto lo hará colapsarse sobre sí mismo . Sin excepciones.

¿Alguna vez lo usaste en tu codificación diaria?

Sí, pero no directamente . Por el contrario, confiamos en ello indirectamente . La advertencia aquí es que los diferentes conceptos teóricos serán más o menos aplicables dependiendo del dominio del problema en el que estés trabajando.

Sin duda, nosotros:

utilizar computadoras a diario, que se basa en modelos computacionales (por ejemplo, máquinas de turing)
escribir código, que se basa en la teoría de la computación (por ejemplo, lo que es incluso computable) y el cálculo lambda (por ejemplo, para los lenguajes de programación)
confíe en la teoría y los modelos de color (por ejemplo, modelos de color RGB y CMYK) para la impresión y visualización en color, etc.
Los teoremas de Euler en gráficos de computadora para que las matrices se puedan construir para rotar objetos sobre ejes arbitrarios, y así sucesivamente ...

Es un hecho que alguien que simplemente usa un avión para viajar no necesita entender la teoría de que incluso permitió que los aviones se construyeran y volaran en primer lugar ... pero cuando se espera que alguien construya dichas máquinas y las haga funcionar. ¿Realmente puedes esperar un buen resultado de alguien que no entiende ni siquiera los principios del vuelo?

¿Fue realmente una coincidencia que, durante la mayor parte de la historia, nadie fue capaz de construir una máquina voladora (y algunos incluso murieron probando la suya) hasta que los hermanos Wright entendieron ciertos conceptos teóricos sobre el vuelo y lograron ponerlos en práctica?

No es una coincidencia Hoy tenemos mucha tecnología en funcionamiento porque las personas que los construyeron entendieron y aplicaron los principios teóricos que les permitieron trabajar en primer lugar.