Quelle est la matière / théorie CS la plus difficile que vous ayez étudiée mais importante pour le domaine? Et la raison s'il vous plait?
Quelle est la matière / théorie CS la plus difficile que vous ayez étudiée mais importante pour le domaine? Et la raison s'il vous plait?
Réponses:
"Il y a 2 problèmes difficiles en informatique: les erreurs de mise en cache, de nommage et off-by-1"
Honnêtement, la construction du compilateur!
Conception et analyse d'algorithmes
Je pense que cette question dépend de l'enseignant que vous avez eu et de la façon dont cette matière a été organisée dans votre carrière.
L'analyse d'algorithmes peut être aussi difficile que quelqu'un le souhaite. Prenez en compte qu'il y a des problèmes non résolus, et pas seulement: des problèmes qui ne peuvent pas être résolus.
Le fait est que vous pouvez avoir un problème, et si vous savez qu'il ne peut pas être résolu, c'est parfait. Et si vous ne le faites pas? Vous pouvez passer beaucoup de temps à essayer de démontrer qu'il est NP-Complete ou à trouver une solution temporelle polynomiale pour le résoudre.
Démontrer la complétude NP n'est pas facile. Oui, beaucoup de problèmes sont connus, mais le problème est de trouver les réductions pour démontrer que c'est NP-Complete. Et si vous passez beaucoup d'heures / jours / mois à essayer de le démontrer, et que cela peut être résolu en temps polynomial? :)
Il y a aussi d'autres sujets, comme les compilateurs , la théorie de groupe et les fonctions récursives primitives qui peuvent être aussi difficiles que le plan du sujet ou le professeur le veut;)
Reconnaissance de formes, c'est-à-dire intelligence artificielle. Cela fait référence à l'informatique intelligente ainsi qu'à d'autres outils de reconnaissance de formes tels que la reconnaissance optique de caractères, la voix au texte, l'identification faciale, etc.
Beaucoup des choses "sympas" que vous pouvez faire ou souhaiteriez faire avec les ordinateurs s'appuient sur ces algorithmes, et nous essayons de les perfectionner depuis des décennies sans grand succès.
Mon choix est la théorie de la calculabilité
(Hmm ... peut-être que ce n'est pas si important, mais c'était sûr difficile)
Il n'y a que deux problèmes difficiles en informatique: l'invalidation du cache et le nommage. - Phil Karlton
théorie des catégories (mathématiques discrètes), mais ça vaut le coup
Cryptographie
Si vous le faites un peu mal, cela pourrait coûter des millions à une entreprise.
Systèmes d'exploitation, en particulier la partie qui a quelque chose à voir avec le filetage.
Et la raison n'est pas parce qu'il était si difficile de faire manger de la pizza à la fourchette par 5 philosophes. La raison en est que l'écriture de code multithread est en soi difficile et pas nécessairement facile à calculer pour l'esprit humain (au moins masculin - selon ma femme).
Moi aussi, je vote pour Compiler Design. Surtout là où la partie DFA et NFA entre en jeu. Je ne suis pas aussi clair sur les problèmes NP et autres.
Eh bien, techniquement, c'est une branche des mathématiques, mais elle est très pertinente en CS.
Presque tout dans CS est basé sur des files d'attente (visibles (évidentes) et invisibles (pas si évidentes ou implicites)).
Au début de CS, les files d'attente étaient évidentes.
Une file d'attente de programmes (chacun programme un jeu de cartes).
De nos jours, les files d'attente ne sont pas si évidentes. Internet par exemple: un réseau à commutation de paquets, mais les paquets forment des files d'attente et le routage des paquets est une forme de minimisation des files d'attente.
Ce n'est pas trop difficile avec les problèmes de jouets qui vous sont donnés dans le cours, mais une fois que vous commencez à considérer de vrais problèmes, cela se transforme en corvée grave.
Interpréter les exigences du client lorsque le client ne sait pas vraiment ce qu'il veut. Ce n'est pas enseigné au collège et c'est l'une des compétences les plus essentielles à posséder.
Personnellement, le mien était Formal Logic. C'était difficile de commencer, mais une fois que vous avez établi les règles et que vous avez réussi à jouer suffisamment avec, votre cerveau s'en vaLogic++;
, ce qui en développement est une très bonne chose.
En guise de note complémentaire, je réponds directement à la question - ce n'était certainement pas le sujet le plus difficile lorsque j'ai obtenu mon diplôme, mais c'était probablement le sujet le plus difficile "applicable dans la vie réelle".
Constructions du compilateur. Difficile mais doit comprendre les concepts derrière
Conception du noyau n'importe qui? Eh bien, je ne sais pas vraiment comment cela se fait et quelles sont les fonctionnalités ciblées pour un système d'exploitation, mais pour moi, penser à la conception d'un noyau doit être une tâche intimidante.
Je pense aussi à la sécurité informatique ; Je ne sais pas vraiment ce qui rend un système dangereux, sauf bien sûr, les débordements de tampon évidents, les injections XSS et SQL.
Je ne suis pas sûr, mais il semble que certains algorithmes soient également dangereux; regardez le projet MetaSploit, il répertorie tous les types et types de violations de sécurité: vous pouvez voir qu'il existe de nombreuses façons dont un programme peut être défectueux.
Il existe de nombreux sujets délicats dans le domaine, mais mes choix pour une difficulté persistante sont ceux impliquant les propriétés du système global . Voici des exemples de ce sujet général:
Ce sont difficiles parce que vous recherchez quelque chose qui n'existe que lorsque tout est correct; vous avez besoin d'une propriété système globale et pourtant pratiquement tous les outils disponibles (et tous ceux qui s'adaptent aux problèmes réels de mon expérience) ne font vraiment que du raisonnement local. C'est le processus de passer du raisonnement sur les morceaux du programme à l'ensemble du shebang qui est difficile, en particulier parce qu'il est tout à fait possible d'avoir des morceaux qui sont tous corrects en eux-mêmes mais où il y a encore des bogues subtils parce que les composants sont mal organisés; les bogues peuvent être des caractéristiques émergentes indésirables…
Services d'information sur la gestion
Pendant ma période collégiale, j'avais un sujet de gestion par semestre, ce qui me rendait complètement fou.
Dure! les sujets comme Compiler Design , OS Design etc. sont difficiles mais ils sont vraiment intéressants et stimulants. J'ai vraiment gâché des sujets comme le système / les services d'information de gestion, etc., car ils sont pleins d'ennui et vous devez passer par beaucoup de théorie.
Si vous travaillez en C / C ++, les pointeurs sont le concept le plus important à connaître. Mais d'une manière ou d'une autre, je ne l'ai jamais entièrement compris à l'université.
Conception et analyse d'algorithmes. Ce n'est pas tant qu'il est difficile de comprendre et d'analyser des algorithmes connus , c'est que la conception et l'analyse de nouveaux algorithmes pour des problèmes difficiles sont difficiles, et nécessitent une large compréhension de nombreux domaines et une pratique dans l'application de nombreuses techniques différentes.
Quelle est la matière / théorie CS la plus difficile que vous ayez étudiée mais importante pour le domaine?
Mathématiques discrètes.
C'était difficile parce que les théories sont très peu reliées entre elles mais elles sont utilisées dans CS. Trop de mémorisation je suppose ...
Preuve par induction, Big O, récursion, division et conquête, Théorie des graphes, bla bla .. argh!
Pour moi, le compilateur était facile, car nous devions prendre la théorie des automates. ^^
J'aime vos réponses (et je n'ai pas oublié de les voter), comme le compilateur, le noyau, etc., mais la plupart des programmeurs n'ont jamais rencontré ces problèmes. Il y a un problème un peu plus facile, mais plus courant: concurrence - threads, verrouillage. Il est très facile d'écrire un programme qui produit des erreurs magiques, si nous faisons même un petit bogue dans l'architecture de concurrence.
Donc, je dis, ce n'est pas le problème le plus difficile en informatique, mais parce qu'il est couramment utilisé, il est dangereux.
Programmation orientée objet
C'est probablement parce que je me suis coupé les dents sur FORTRAN et APL, mais le passage des langages strictement procéduraux aux objets est une chose avec laquelle je me bats depuis des années. Cela n'aide pas que les soi-disant «experts» écrivent des articles et des didacticiels contradictoires sur ce que signifie être orienté objet et les meilleures / bonnes façons de construire des programmes orientés objet.