Quand l'informatique théorique est-elle utile?

https://stackoverflow.com/questions/235394

04-07-2019
|

Question

En classe, nous avons appris le problème de l’arrêt, les machines de Turing, les réductions, etc. De nombreux camarades de classe disent que ce sont des concepts abstraits et inutiles, et qu’il est inutile de les connaître (c’est-à-dire que vous pouvez les oublier une fois). le cours est terminé et ne perd rien).

Pourquoi la théorie est-elle utile? Est-ce que vous l'utilisez déjà dans votre codage quotidien?

La solution

Quand j'ai eu mon diplôme universitaire, j'ai supposé que j'étais à égalité avec tout le monde: & "J'ai un BS en CS et beaucoup d'autres personnes, et nous pouvons tous faire essentiellement les mêmes choses . " J'ai finalement découvert que mon hypothèse était fausse. Je me suis démarqué et mes antécédents y étaient pour beaucoup - en particulier mon diplôme.

Je savais qu'il y avait un & "léger &"; différence, en ce sens que j’avais un " B.S. " en CS parce que mon collège était l’un des premiers (prétendument n ° 2 en 1987) à avoir reçu une accréditation pour son programme de licence en CS et que j’ai obtenu mon diplôme en deuxième classe pour obtenir cette accréditation. À l'époque, je ne pensais pas que cela importait beaucoup.

J’avais aussi remarqué au lycée et au collège que j’avais particulièrement bien réussi à CS - bien mieux que mes pairs et même mieux que bon nombre de mes professeurs. On m'a souvent demandé de l'aide, j'ai suivi des cours particuliers, participé à un projet de recherche et autorisé à faire des études indépendantes alors que personne d'autre ne le faisait. J'étais heureuse de pouvoir aider mais je ne pensais pas beaucoup à la différence.

Après l’université (USAFA), j’ai passé quatre ans dans l’armée de l’air, dont deux à appliquer mon diplôme de CS. Là-bas, j'ai remarqué que très peu de mes collègues avaient des diplômes ou même une formation en informatique. La Force aérienne m'a envoyé suivre une formation de certification de cinq mois au cours de laquelle j'ai encore constaté un manque de diplômes ou de formation. Mais là, j'ai commencé à remarquer la différence - il devint tout à fait évident que beaucoup de personnes que je rencontrais ne savaient VRAIMENT pas ce qu'elles faisaient, et cela incluait les personnes ayant une formation ou des diplômes. Permettez-moi d’illustrer.

Dans ma formation à la certification de la Force aérienne, treize personnes au total (dont moi) ont participé. En tant qu'officiers de la Force aérienne ou l'équivalent, nous avions tous un diplôme de BS. J'étais au milieu en fonction de l'âge et du rang (j'étais un O-2 parmi six O-1 et six O-3 et plus). À la fin de cette formation, la Force aérienne nous a tous reconnus comme étant tout aussi compétents pour acquérir, construire, concevoir, entretenir et utiliser TOUT système informatique ou de communication pour TOUT élément du département de la Défense.

Cependant, sur les treize d’entre nous, seuls six avaient une quelconque forme de diplôme en informatique; les sept autres avaient des diplômes allant de l'aéronautique à la chimie / biologie et à la psychologie. Parmi les six d'entre nous qui avons obtenu un diplôme en sciences humaines, j'ai appris que deux d'entre eux n'avaient jamais écrit de programme et n'avaient jamais utilisé un ordinateur de manière plus naturelle (rédaction de documents, jeux, etc.). J'ai appris que deux autres d'entre nous avaient écrit exactement un programme sur un seul ordinateur au cours de leur programme de licence. Une seule autre personne et moi-même avons écrit plus d'un programme ou utilisé plus d'un type d'ordinateur. Nous avons en effet constaté que nous avions tous deux écrit de nombreux programmes et utilisé de nombreux types d'ordinateurs.

Vers la fin de notre formation de cinq mois, notre classe s’est vu confier un projet de programmation et nous avons été divisés en quatre groupes pour l’entreprendre séparément. Nos instructeurs ont divisé la classe afin de diffuser le & "Talent de programmation" & "; équitablement, et ils ont attribué les rôles de chef d’équipe, de responsable technique et de développeur. Chaque groupe a eu une semaine pour mettre en place (en Ada) une interface utilisateur plein écran à base de texte (datant de 1990) pour un simulateur de vol s'ajoutant à une bibliothèque de mécanique de vol fournie par un instructeur. J'ai été affecté en tant que responsable technique pour mon équipe de quatre personnes.

Mon responsable d’équipe (qui n’avait pas de diplôme en informatique) a demandé aux trois autres d’entre nous de diviser le projet en tâches, puis d’en attribuer un tiers à chacune d’elles. J'ai terminé ma troisième tâche au milieu de cette première journée, puis j'ai passé le reste de la journée à aider mes deux autres coéquipiers, à parler à mon chef d'équipe (BSing; ^) et à jouer sur mon ordinateur.

Le lendemain matin (jour deux), le responsable de mon équipe m'a informé en privé que nos deux autres coéquipiers n’avaient fait aucun progrès (l’un ne pouvait pas écrire un " if " déclaration qui compilerait), et il m'a demandé de prendre en charge leur travail. J'ai terminé l'ensemble du projet en milieu d'après-midi et mon équipe a passé le reste de la journée à piloter le simulateur.

L’autre type ayant obtenu un diplôme comparable en CS a également été nommé responsable technique de son équipe, qui a terminé à la fin de la troisième journée. Ils ont également commencé à piloter leur simulateur. Les deux autres équipes n’avaient pas terminé, ni même réalisé de progrès importants, à la fin de la semaine. Nous n’avions pas le droit d’aider d’autres équipes, nous en sommes restés là.

En attendant, au milieu du troisième jour, j’avais remarqué que le simulateur de vol semblait se comporter & «Faux &»; Comme l'un de mes camarades de classe avait un diplôme en aéronautique, je lui en ai parlé. Il a été mystifié, puis a avoué qu'il ne savait pas vraiment ce qui faisait voler un avion!?! J'étais abasourdi! Il s’avère que tout son programme d’études portait sur la sécurité et les enquêtes sur les accidents - aucun calcul ni aucune science n’est à l’origine du vol. Par contre, j'avais peut-être une mineure en aéronautique (vous vous souvenez de l'USAFA?), Mais nous avions conçu des ailes et effectué de vrais tests en soufflerie. Par conséquent, j'ai tranquillement passé le reste de la semaine à réécrire la bibliothèque de mécanique de vol fournie par l'instructeur jusqu'au vol du simulateur & "Right &";

Depuis lors, j'ai passé près de deux décennies en tant que contractant et occasionnellement en tant qu'employé, réalisant toujours le développement de logiciels ainsi que des activités connexes (administrateur de base de données, architecte, etc.). J'ai continué à en trouver davantage et finalement j'ai abandonné mon hypothèse de jeunesse.

Alors, qu'est-ce que j'ai découvert exactement? Tous ne sont pas égaux, et ça va. Je ne suis pas une meilleure personne parce que je peux programmer efficacement, mais je suis plus utile SI c'est ce dont vous avez besoin. J'ai appris que mes antécédents comptaient vraiment: grandir dans une famille d'électriciens et d'ingénieurs électriciens, kits électroniques de construction, lire littéralement tous les livres informatiques des bibliothèques scolaires / publiques parce que je n’avais pas accès à un vrai ordinateur, puis déménage dans une nouvelle ville où mon lycée avait des ordinateurs, puis obtenir mon propre ordinateur en cadeau, se rendre dans des écoles équipées d'ordinateurs de tailles et de types différents (PC à mainframes), obtenir un diplôme accrédité d'une très bonne école d'ingénieurs, avoir à écrire beaucoup de programmes dans différentes langues sur différents types d'ordinateurs, avoir à écrire des programmes difficiles (comme ma propre machine virtuelle avec un langage d'assemblage personnalisé, ou une implémentation de compression Huffman, etc.), avoir à résoudre moi-même, construire mes propres ordinateurs à partir de pièces et installer TOUS les logiciels, etc.

En fin de compte, j’ai appris que mes compétences reposaient sur la connaissance du fonctionnement des ordinateurs à partir du niveau électrique: composants électroniques discrets, circuits, sous-systèmes, interfaces, protocoles, bits, octets, processeurs, périphériques, pilotes, etc. bibliothèques, programmes, systèmes, réseaux, jusqu'aux énormes conglomérats de classe entreprise sur lesquels je travaille couramment actuellement. Alors, quand la fichue chose se comporte mal, je sais exactement comment et pourquoi. Et je sais ce qui ne peut pas être fait aussi bien que ce qui peut. Et j'en sais beaucoup sur ce qui a été fait, ce qui a été essayé et ce qui reste relativement inexploré.

Plus important encore, après avoir appris tout cela, j'ai appris que je ne savais rien du tout. Malgré tout ce qu'il y a potentiellement à savoir, mes connaissances sont minimes.

Et je suis assez content de ça. Mais je vous recommande d'essayer.

Autres conseils

Histoire vraie:

Lorsque j'ai obtenu mon premier emploi en programmation après des études de troisième cycle, les personnes à la tête de l'entreprise pour laquelle je travaillais étaient des pilotes. Quelques semaines après mon embauche, l'un d'entre eux m'a posé la question suivante:

Arkansas compte 106 aéroports. Pourriez-vous écrire un programme qui trouver la déroute la plus courte nécessaire pour atterrir à chacun d’eux?

J'ai sérieusement pensé qu'il me questionnait sur ma connaissance du problème du voyageur de commerce et de la NP-Completeness. Mais il s'avère qu'il ne l'était pas. Il n'en savait rien. Il voulait vraiment un programme qui trouverait le chemin le plus court. Il a été surpris lorsque j’ai expliqué qu’il existait 106 solutions factorielles et que trouver la meilleure était un problème informatique bien connu et insoluble.

Voilà donc un exemple.

Bien sûr, c'est utile.

Imaginez un développeur travaillant sur un moteur de template. Vous connaissez le genre de chose ...

Blah blah blah ${MyTemplateString} blah blah blah.

Cela commence simplement, avec une petite expression régulière effrontée pour remplacer les remplaçants.

Mais progressivement, les modèles deviennent un peu plus sophistiqués et le développeur inclut des fonctionnalités pour la modélisation des listes et des cartes de chaînes. Pour ce faire, il écrit une petite grammaire simple et génère un analyseur.

De façon très astucieuse, le moteur de gabarit pourrait éventuellement inclure une syntaxe pour la logique conditionnelle, permettant d'afficher différents blocs de texte en fonction des valeurs des arguments.

Quelqu'un ayant une formation théorique en informatique reconnaîtrait que le langage de modèle est en train de devenir complètement complet, et peut-être que le modèle Interpreter serait un bon moyen de le mettre en œuvre.

Après avoir créé un interpréteur pour les modèles, un informaticien peut remarquer que la majorité des demandes de modèles sont des doublons, régénérant les mêmes résultats à maintes reprises. Ainsi, un cache est développé et toutes les demandes sont acheminées à travers le cache avant d’effectuer la transformation coûteuse.

De plus, certains modèles sont beaucoup plus complexes que d’autres et leur rendu est beaucoup plus long. Quelqu'un aurait peut-être l'idée d'estimer l'exécution de chaque modèle avant de le rendre.

Mais attendez !!! Un membre de l'équipe fait remarquer que, si le langage de modèle est vraiment complet, le travail d'estimation du temps d'exécution de chaque opération de rendu est une instance du problème Halting !! Ouais, ne fais pas ça!

Le problème de la théorie, dans la pratique, est que toute pratique est basée sur la théorie. Théoriquement.

Ce que j'utilise le plus souvent:

complexité de calcul pour écrire des algorithmes évolutifs
compréhension du fonctionnement de l'allocation de mémoire, de la pagination et de la mise en cache de la CPU afin de pouvoir écrire du code efficace
compréhension des structures de données
compréhension des problèmes de threading, de verrouillage et des problèmes associés

En ce qui concerne ce matériel sur les machines de Turing, etc. Je pense que c'est important car il définit les contraintes auxquelles nous sommes tous soumis. C’est important à apprécier.

c'est la différence entre apprendre l'algèbre et apprendre à utiliser une calculatrice

Si vous connaissez l'algèbre, vous réalisez que le même problème peut se manifester sous différentes formes et vous comprenez les règles permettant de le transformer en une forme plus concise.

si vous savez seulement utiliser une calculatrice, vous risquez de perdre beaucoup de temps à cogner les boutons sur un problème qui est (a) déjà résolu, (b) ne peut pas être résolu ou (c) est comme un autre problème (résolu ou non résolu) que vous ne reconnaissez pas car il est sous une forme différente

prétendre un instant que l'informatique est la physique ... la question semblerait-elle idiote?

Un de mes amis travaille sur une langue avec des modèles. On m'a demandé de faire une petite consultation. Une partie de notre discussion a porté sur la fonctionnalité de modèle, car si les modèles étaient complets, ils devraient vraiment considérer les propriétés de VM-ish et comment / si leur compilateur le prendrait en charge.

Mon histoire est à ce point: la théorie des automates est toujours enseignée, car elle a toujours sa pertinence. Le problème d’arrêt existe toujours et limite les possibilités.

Maintenant, ces éléments sont-ils pertinents pour un jockey de base de données martelant du code C #? Probablement pas. Mais lorsque vous commencez à passer à un niveau plus avancé, vous aurez besoin de comprendre vos racines &. fondations.

Bien que je ne les applique pas directement au travail quotidien, je sais que mes études en informatique formelle ont affecté mon processus de réflexion. J'évite certainement certaines erreurs dès le départ, car j'ai les leçons tirées des approches formelles qui m'ont été inculquées.

Cela peut sembler inutile pendant qu’ils l’apprennent; mais je parie que votre camarade de classe finira par rencontrer un problème où ils utiliseront ce qu'ils ont appris, ou du moins les schémas de pensée qui le sous-tendent ...

Cire ... Cire ... Cire ... Cire ... Qu'est-ce que cela a à voir avec le Karaté, de toute façon?

Lors d’un travail, j’ai été chargé d’améliorer l’algorithme de traçage réseau de notre modèle de distribution électrique car celui-ci était trop lent. Le réseau triphasé comportait essentiellement trois arbres n (car les boucles ne sont pas autorisées dans les réseaux électriques). Les nœuds du réseau se trouvaient dans la base de données et certains membres de l'équipe d'origine n'avaient pas compris comment créer un modèle en mémoire. Le traçage a donc été effectué par sélections de profondeur successives sur la base de données, en filtrant chaque phase. Donc, pour retracer un nœud, dix nœuds de la sous-station nécessiteraient au moins 10 requêtes de base de données (les membres de l’équipe initiale étaient des experts de la base de données, mais ils n’avaient pas de bases en algorithmes).

J'ai écrit une solution qui a transformé les 3 réseaux de nœuds de la base de données en une structure de données dans laquelle chaque nœud était stocké une fois dans un tableau de structure de nœuds et la relation n-arbre a été convertie en trois arbres binaires à l'aide de pointeurs liés au sein de la matrice afin que le réseau puisse être facilement tracé dans les deux sens.

Il était au moins deux fois plus rapide, trois sur des traces très longues en aval.

Ce qui est triste, c’est que j’ai dû enseigner pratiquement une classe de n-trees, binaires, pointeurs et listes doublement chaînées à plusieurs autres programmeurs formés aux bases de données et à VB afin qu’ils comprennent les algorithmes.

C’est une dichotomie classique, entre & "comment &"; et " quel " ;. Vos camarades de classe regardent & "Comment &"; pour programmer des logiciels, et ils sont très concentrés sur le proche; de ce point de vue, du point de vue de la mise en œuvre, il semble que connaître des choses comme arrêter des états et des machines de Turing ne soit pas important.

& "Comment &" n’est cependant que très peu du travail que vous êtes censé faire en informatique. En fait, les ingénieurs les plus expérimentés que je connaisse diraient probablement moins de 20% du travail réel. " Qu'est-ce que " faire est de loin plus important; et pour cela, les bases de l’informatique sont essentielles. " Qu'est-ce que " vous voulez faire concerne beaucoup plus la conception que la mise en œuvre; et un bon design, c'est ... eh bien, appelons-le simplement & "non-trivial &";

& "; Il existe deux manières de concevoir un logiciel: l'une consiste à simplifier les choses, de sorte qu'il n'y ait manifestement aucune anomalie, et l'autre à les rendre si compliquées que il n'y a pas de lacunes évidentes. La première méthode est beaucoup plus difficile. & "; - C.A.R. Hoare

Bonne chance dans vos études!

Je pense qu'il est utile de comprendre les modèles fondamentaux de calcul: vous ne devez jamais être capable de traduire une machine de Turing en une machine à registre, mais apprendre à voir que deux problèmes très différents sont vraiment des exemples du même concept est une compétence critique.

La plupart des connaissances ne sont pas & "pratiques &"; mais vous aident à relier des points d’une manière que vous ne pouvez pas anticiper ou vous fournissent un vocabulaire plus riche pour décrire des idées plus complexes.

Ce ne sont pas les problèmes spécifiques que vous étudiez qui importent, ce sont les principes que vous apprenez en les étudiant. J'utilise quotidiennement des concepts sur les algorithmes, les structures de données, les langages de programmation et les systèmes d'exploitation. Si vous travaillez en tant que programmeur, vous prendrez tout le temps des décisions qui affectent les performances du système. Vous devez avoir une base solide dans les concepts abstraits fondamentaux pour pouvoir faire les bons choix.

Si vous travaillez dans une entreprise qui effectue des travaux révolutionnaires, il est important de pouvoir communiquer aux architectes et aux développeurs les avantages qui en découlent. Il y a beaucoup de battage médiatique sur toutes sortes de technologies et il peut être difficile de se positionner. Lorsque vous définissez votre innovation en termes scientifiques et théoriques, vous êtes définitivement un avantage et les clients pensent que vous êtes la vraie chose. Je peux dire aux gens: il existe une nouvelle façon de traiter les problèmes d’état, d’encodage et de non-déterminisme (c'est-à-dire les complexités) et vous pouvez certainement être plus productif qu'aujourd'hui.

Si vous envisagez une carrière dans votre carrière, apprendre la théorie vous donnera de la profondeur, la profondeur dont vous avez besoin pour grandir. Le retour sur investissement dans l’apprentissage de votre 5ème ou 6ème langage de programmation sera bien moindre que d’apprendre vos 2ème et 3ème. L'exposition à la théorie vous donnera une idée de l'ingénierie réelle, indiquant où sont les degrés de liberté et comment vous pouvez faire les bons compromis.

Les concepts importants 1) Etat, 2) Encodage, 3) Non déterminisme. Si vous ne les connaissez pas, ils ne vous aideront pas. Ce que la théorie devrait vous fournir est une vue d'ensemble et une idée de la manière dont les concepts de base s'imbriquent. Cela devrait vous aider à affiner votre intuition.

Exemple: certaines des réponses ci-dessus mentionnent le problème d’arrêt et les machines de Turing. Quand je suis tombé sur le journal de Turing au collège, je ne me suis pas senti éclairé du tout. Un jour, je suis tombé sur le théorème d'inachèvement de Goedel et sur la numérotation de Goedel en particulier. Les choses ont commencé à avoir beaucoup de sens. Des années plus tard, j'ai lu à propos de Georg Cantor dans une librairie. Maintenant, j'ai vraiment commencé à comprendre les machines de Turing et le problème persistant. Essayez par vous-même et recherchez & "; Argument diagonal de Cantor &"; sur Wikipedia. C'est l'une des choses les plus impressionnantes que vous rencontrerez intellectuellement.

Matière à réflexion: Une machine de Turing typique n’est pas le seul moyen de concevoir une machine à transition d’état. Une machine de Turing avec deux bandes plutôt qu'une seule vous donnerait beaucoup plus de vitesse pour un certain nombre d'algorithmes. http://www.math.ucla.edu/~ynm/papers/ eng.ps

Vous pouvez vous exposer à ces informations plus efficacement que je ne l’ai fait en lisant ce livre. Lien au bas de ce post. (À tout le moins, consultez la table des matières sur Amazon pour avoir un aperçu de ce dont il s'agit):

J'ai trouvé le livre de Rosenberg sensationnel. http://www.amazon.com/The-Pillars-Computation-Theory-Nondeterminism/ dp / 0387096388 Si vous n'avez qu'un seul livre sur la théorie à mon humble avis, ce devrait être celui-ci.

Après avoir obtenu mon diplôme de CS, je pensais de la même manière: toutes les théories que nous avons étudiées sont totalement inutiles dans la pratique. Cela s'est avéré juste pour une courte période de temps, mais au moment où vous traitez avec des tâches complexes, la théorie est définitivement PLUS VALABLE que la pratique. tous les utilisateurs après quelques années de codage peuvent écrire des programmes qui & "; fonctionnent &"; mais tout le monde n'est pas capable de comprendre comment. peu importe ce que la plupart d’entre nous traiterons à un moment donné avec des problèmes de performances, des retards de réseau, une précision, une évolutivité, etc. À ce stade, la théorie est cruciale. Pour concevoir une bonne solution sur des systèmes complexes, il est très important de connaître le fonctionnement de la gestion de la mémoire, les concepts de processus et de threads, la manière dont la mémoire leur est affectée ou les structures de données efficaces pour la performance, etc.

Une fois, par exemple, je travaillais sur un projet comportant de nombreux calculs mathématiques et, à un moment donné, notre logiciel a échoué. lors du débogage, j’ai compris qu’après quelques opérations mathématiques, j’avais reçu un nombre DOUBLE d’une valeur de 1,000000000002, mais du point de vue mathématique, il ne pouvait pas être > 1 qui, à un stade ultérieur du programme, donnait la légendaire exception NaN . J'ai passé du temps à comprendre cela, mais si j'avais prêté plus d'attention à & "; l'approximation de Double and Float &"; leçon que je n'aurais pas perdu ce temps.

Je ne l'utilise pas quotidiennement. Mais cela m'a apporté beaucoup de compréhension qui m'aide chaque jour.

J'ai découvert que tout ce dont j'avais besoin pour le bonheur quotidien du monde théorique CS était l'énoncé du mantra & "Couplage faible et cohésion élevée &". Roger S. Pressman a mis les choses au point avant Steve McConnell l’a rendu à la mode.

Oui, j’utilise généralement des diagrammes d’état pour concevoir la forme et la fluidité du programme. Une fois que cela fonctionne en théorie, je commence à coder et à tester, en cochant les états au fur et à mesure.

Je trouve qu'ils constituent également un outil utile pour expliquer le comportement d'un processus à d'autres personnes.

Simple. Par exemple, si j'utilise RSACryptoServiceProvider , j'aimerais savoir ce que c'est et pourquoi je peux lui faire confiance.

Parce que les templates C ++ sont en réalité une sorte de calcul lambda. Voir www.cs.nott.ac.uk/types06/slides/michelbrink_types_06.pdf

J'étudie actuellement pour mon cours sur les algorithmes distribués. Il existe un chapitre sur la tolérance de panne qui contient quelques preuves sur la limite supérieure du nombre de processus pouvant échouer (ou se comporter mal) de sorte que l’algorithme distribué puisse la gérer correctement.

Pour de nombreux problèmes, la limite des processus qui se conduisent mal correspond au tiers du nombre total de processus. Ceci est très utile à mon avis car vous savez qu'il est inutile d'essayer de développer un meilleur algorithme (sous des hypothèses données).

Même si les cours théoriques ne seront pas utilisés directement, cela pourrait vous aider à mieux penser à quelque chose.

Vous ne savez pas ce que votre patron va vous demander de faire, vous devrez peut-être utiliser quelque chose qui, à votre avis, ne sera pas bénéfique, comme l'a dit Jeffrey L. Whitledge.

Pour être honnête, je suis en désaccord avec beaucoup de réponses ici. J’ai écrit mon premier compilateur (pour le plaisir; j’ai vraiment trop de café / de temps libre) sans avoir suivi un cours de compilateur; fondamentalement, je viens de scanner le code pour un autre compilateur et ai suivi le modèle Je pourrais écrire un analyseur syntaxique en C, mais je ne pense pas pouvoir me rappeler comment dessiner un automate à pile si ma vie en dépendait.

Lorsque j’ai décidé de mettre l’inférence de type dans mon langage de programmation (impératif), j’ai tout d’abord examiné cinq papiers, en regardant quelque chose appelé & "lambda calculus typé &"; aller quoi .... le .... **** ....? Au début, j'ai essayé d'implémenter quelque chose avec & Quot; variables génériques & Quot; et " variables non génériques " et n'avait aucune idée de ce qui se passait. Ensuite, j'ai tout abandonné et je me suis assis avec un cahier expliquant comment je pouvais le mettre en œuvre de manière pratique, avec un support pour tout ce dont j'avais besoin (sous-typage, fonctions de première classe, types paramétrés, etc.). Après quelques jours de réflexion & amp; En écrivant des programmes d’essais, j’ai perdu plus d’une semaine à essayer de comprendre la merde théorique.

La connaissance des bases de l’informatique (fonctionnement de la mémoire virtuelle, des systèmes de fichiers, threading / ordonnancement, SMP, structures de données) s’est avérée extrêmement utile. La théorie de la complexité et les éléments Big-O se sont parfois révélés utiles (particulièrement utiles pour des tâches telles que la conception de SGBDR). Le problème d’arrêt et la théorie des automates / machines de Turing? Jamais.

I know this is old, but my short reply to those who claim that theory is 'useless' and that they can practice their profession without it is this:

Without the underlying theory, there is no practice.

Why is theory useful?

Theory is the underlying foundation on top of which other things are built. When theory is applied, practice is the result.

Consider computers today. The common computer today is modeled and built on top of the Turing Machine, which, to keep it simple, is an abstract/theoretical model for computation. This theoretical model lies at the foundation of computing, and all the computing devices we use today, from high-end servers to pocket phones, work because the underlying foundation is sound.

Consider algorithm analysis. In simple terms, algorithm analysis and time-complexity theory have been used to classify problems (e.g. P, NP, EXP, etc) as well as how the algorithms we have behave when trying to solve different problems in different classes.

Suppose one of your friends gets a job at some place X and, while there, a manager makes a few simple requests, such as these examples:

Ex 1: We have a large fleet of delivery vehicles that visit different cities across several states. We need you to implement a system to figure out what the shortest route for each vehicle is and choose the optimal one out of all the possibilities. Can you do it?

Thinking the theory is 'useless' your friends don't realize that they've just been given the Traveling Salesman Problem (TSP) and start designing this system without a second thought, only to discover their naive attempt to check all the possibilities, as originally requested, is so slow their system is unusable for any practical purposes.

In fact, they have no idea why the system works at an "acceptable" level when checking 5 cities, yet becomes very slow at 10 cities, and just freezes when going up to only 40 cities. They reason that it's only "2x and 8x more cities than the 5 city test" and wonder why the program does not simply require "2x and 8x more time" respectively...

Understanding the theory would've allowed them to realize the following, at least at a glance:

It's the TSP
The TSP is NP-hard
Their algorithm's order of growth is O(n!)

The numbers speak for themselves:

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

They could've realized at the outset that their system was not going to work as they imagined it would. The system was later considered impractical and cancelled after a significant amount of time, effort, and other resources had been allocated to, and ultimately wasted on, the project --and all because thought "theory is useless".

So after this failure, the managers think "Well, maybe that system was underestimated; after all, there're a LOT of cities in our country and our computers are simply not as fast as we need them to be for our recently cancelled system to have been a success".

The management team blames slow computers as the cause of the project's failure. After all, they're not experts in CS theory, don't need to be, and those who're supposed to be the experts on the topic and could've informed them, didn't.

But they have another project in mind. A simpler one actually. They come the week later and ask say the following:

Ex 2: We have only a few servers and we have programmers who keep submitting programs that, due to unknown reasons, end up in infinite cycles and hogging down the servers. We need you to write a program that will process the code being submitted and detect whether the submitted program will cause an infinite cycle during its run or not, and decide whether the submitted program should be allowed to run on this basis. Can you do it?

Your dear friend accepts the challenge again and goes to work immediately. After several weeks of work, there're no results, your friend is stressed, and doesn't know what to do. Yet another failure... your friend now feels "dumb" for not having been able to solve this "simple problem"... after all, the request itself made it sound simple.

Unfortunately, your friend, while insisting that "theory is useless" didn't realize that the, allegedly simple, request was actually an intractable problem about decidability (i.e. the halting problem itself), and that there was no known solution for it. It was an impossible task.

Therefore, even starting work to solve that particular problem was an avoidable and preventable mistake. Had the theoretical framework to understand what was being requested been in place, they could've just proposed a different, and achievable, solution... such as implementing a monitoring process that can simply kill -SIGTERM <id> of any user process (as per a list of users) that monopolizes the CPU for some arbitrary/reasonable interval under certain assumptions (e.g. we know every program run should've terminated within 10 minutes, so any instance running for 20+ minutes should be killed).

In conclusion, practice without the theory is like a building without a foundation. Sooner or later, the right amount of pressure from the right angle will make it collapse in on itself. No exceptions.

Do you ever use it in your day-to-day coding?

Yes, but not directly. Rather, we rely on it indirectly. The caveat here is that different theoretical concepts will be more or less applicable depending on the problem domain you happen to be working on.

Surely, we:

use computers daily, which relies on computational models (e.g. turing machines)
write code, which relies on computability theory (e.g. what's even computable) and lambda calculus (e.g. for programming languages)
rely on color theory and models (e.g. RGB and CMYK color models) for color displays and printing, etc.
Euler's theorems in computer graphics so that matrices can be built to rotate objects about arbitrary axes, and so on...

It's a fact that someone who simply use a plane to travel doesn't need to understand the theory that even allowed planes to be built and fly in the first place... but when someone is expected to build said machines and make them work... can you really expect a good outcome from someone who doesn't understand even the principles of flight?

Was it really a coincidence that, for most of history, no one was able to build a flying machine (and a few even died testing theirs) until the Wright brothers understood certain theoretical concepts about flight and managed to put them into practice?

It's no coincidence. We have a lot of working technology today because the people who built them understood, and applied, the theoretical principles that allowed them to work in the first place.

I guess it depends on which field you go into.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow