La science de l'informatique est-elle morte? [fermé]

Question: La science et l'art du CS sont-ils morts? J'entends par là que les véritables exigences pour penser, planifier et résoudre efficacement les problèmes semblent s'éloigner de CS de nos jours. Le domaine semble abaisser la barrière à l'entrée afin que plus de gens puissent «programmer» sans avoir à apprendre à vraiment programmer.

Contexte: Je suis récemment diplômé d'un BS en informatique. Je travaille une position de départ dans une entreprise de taille décente dans le département informatique. Je fais principalement du .NET et d'autres technologies Microsoft dans mon travail, mais avant cela, j'ai fait des trucs Java par le biais de stages et autres. Personnellement, je suis un programmeur C ++ pour mes propres projets amusants.

En profondeur: À travers le travail que j'ai fait, il me semble que les disciplines intenses d'une vraie science n'existent plus en CS. Dans le passé, les programmeurs devaient résoudre les problèmes efficacement pour que les systèmes soient robustes et rapides. Mais maintenant, avec les technologies dominantes comme .NET, Java et les langages de script, il semble que l'efficacité et la robustesse aient été échangées pour faciliter le développement.

La plupart des collègues avec qui je travaille n'ont même pas de diplôme en informatique. La plupart ont obtenu un diplôme en génie électrique, quelques-uns en génie logiciel, même certains qui venaient d'écoles de technologie sans programme de 4 ans. Pourtant, ils s'en sortent très bien sans avoir la formation technique de CS, sans avoir étudié les théories et les algorithmes, sans avoir le moindre souci de faire une solution élégante (ils optent simplement pour la solution la plus simple et la moins chère).

La société nous pousse à utiliser les technologies Microsoft, qui prennent toute la vraie pensée du sujet et la remplacent par des bibliothèques et des outils qui peuvent construire automatiquement votre projet pour vous la moitié du temps. Je n'essaie pas de détester les langues, je comprends qu'elles servent un but et le font bien, mais lorsque vos employés ne savent pas comment fonctionne une table de hachage, et utilisent les mauvaises méthodes de tri, ou exécutent des commandes SQL qui sont horriblement inefficaces (mais font le travail dans un délai acceptable), il semble que plus d'efforts soient déployés pour développer des technologies qui dorloter les nouveaux `` programmeurs '' plutôt que d'enseigner réellement aux gens comment faire les choses correctement.

Je souhaite créer des programmes efficaces et, à mon avis, beaux. S'il y a une meilleure façon de le faire, je préfère revenir en arrière et le refaçonner plutôt que de le laisser glisser. Mais dans le monde de l'entreprise, ils me poussent à effectuer des tâches plus rapidement qu'élégamment. Et cela me dérange vraiment.

Est-ce ce que j'attends avec impatience le reste de ma vie? Existe-t-il encore des postes pour les personnes qui aiment la science et l'art de la CS plutôt que le simple chèque de paie?

Et sur la même note, voici une bonne lecture si vous ne l'avez pas vue avant The Perils Of Java Schools

Oui et non

Bonne question, mais mauvaise hypothèse.

La partie scientifique de l'éducation semble faire défaut, mais l'hypothèse selon laquelle la science n'était là que pour rendre les programmes efficaces est erronée.

La science était nécessaire pour enseigner aux gens comment définir et résoudre les problèmes.

Malheureusement, cette partie de certains programmes d'études "CS" semble être complètement supprimée, remplacée par des problèmes de jouets avec des solutions triviales ou connues, et destinée simplement à enseigner la familiarité avec les outils.

Décevant; de nombreux diplômés des écoles Java ont été écourtés, n'ont jamais appris à décomposer un problème, à concevoir un algorithme, à spécifier un test ou même à déboguer efficacement.

La science de l'informatique est-elle morte? "..." Je suis un récent diplômé avec un BS en informatique. Je travaille une position de départ dans une entreprise de taille décente dans le service informatique .

Honnêtement, mes deux cents: vous ne trouverez pas la "science" de l'informatique travaillant dans un département informatique dans une entreprise de taille décente, parce que c'est le département informatique, pas le département CS. Essayez de retourner aux études pour un doctorat ou de travailler dans les départements d'ingénierie d'une entreprise spécialisée dans l'informatique (par exemple, traitement d'images, réseaux haute performance, systèmes d'algèbre informatique, aérospatiale, etc.). C'est là que vous trouverez les problèmes difficiles et intéressants où une conception bâclée [généralement] ne sera pas tolérée.

"Y a-t-il encore des postes à pourvoir pour les personnes qui aiment la science et l'art du CS plutôt que le simple chèque de paie?"

Oui, absolument, mais probablement pas dans les services informatiques des moyennes entreprises.

Si vous êtes programmeur, ne vous considérez pas comme un "informaticien"; les informaticiens sont ceux qui créent la prochaine génération d'ordinateurs, dont certains sont encore de la science-fiction jusqu'à ce que le bon mélange de matériaux, la miniatuisation et la théorie computationnelle soient dérivés. Ils ne sont que le début du pipeline. Les personnes qui développent des logiciels ici et maintenant sont des "ingénieurs logiciels"; ils prennent les théories et les outils, parfois en superposant la théorie pratique et des outils du monde réel, pour exploiter le pouvoir en puissance de cette pièce complexe de la magie électroinique et le faire faire ce que nous voulons. Il s'agit à son tour d'une spécialisation du domaine de "l'ingénierie informatique", qui reprend les théories des informaticiens et les applique, matériel et logiciel, aux solutions électroniques des utilisateurs finaux du monde réel.

C'est à l'OMI que le monde des affaires rencontre la théorie. Dans ces types de cas, le vieil adage "l'ennemi du mieux est assez bon" peut facilement être inversé pour se lire "l'ennemi du bien est mieux". Le fait de vous considérer comme un "ingénieur" au lieu d'un "scientifique" et de mettre ce que vous faites en parallèle avec d'autres disciplines de l'ingénierie met en relief les différences.

Disons qu'un client vient à vous, un ingénieur civil / structure, et vous demande de construire un pont. Le pont doit s'étendre sur 20 pieds, se soutenir et supporter une tonne de charge, il devrait durer 10 ans avec un entretien de routine, et ils le veulent dans un mois pour 20 000 $. Ce sont vos contraintes; respecter les minimums sans dépasser les maximums. Faire cela est "assez bien" et vous rapporte le salaire. Ce serait une mauvaise ingénierie pour vous de construire le Golden Gate Bridge, dépassant de loin les spécifications de conception et le budget de plusieurs ordres de grandeur. Vous finissez généralement par manger les dépassements de coûts et payer des pénalités pour les dépassements de temps. Ce serait également une mauvaise ingénierie pour vous de construire un pont de corde évalué pour le poids de 5 hommes adultes, même si cela ne coûte que 1000 $ en temps et en matériaux; vous n'obtenez pas de bons commentaires et témoignages de clients,

De retour dans le logiciel, disons que vous avez un client qui a besoin d'un système de traitement de fichiers conçu pour digérer les fichiers entrants et mettre les informations dans le système. Ils veulent que cela se fasse en une semaine et il doit gérer cinq fichiers par jour, environ 10 Mo de données, car c'est tout le trafic qu'ils reçoivent actuellement. Vos précieuses théories passent largement par la fenêtre; votre tâche consiste à créer un produit qui répond à ces spécifications en une semaine, car ce faisant, vous respectez également le budget des coûts du client (car les matériaux sont généralement une goutte dans le seau pour un contrat de logiciel de cette taille). Passer deux semaines, même pour dix fois le gain, n'est pas une option, mais le plus probable n'est pas non plus un programme construit en une journée qui ne peut gérer que la moitié du débit, avec l'instruction d'avoir deux copies en cours d'exécution.

Si vous pensez qu'il s'agit d'un cas marginal, vous vous trompez; c'est l'environnement quotidien de la plupart des internes. La raison en est le ROI; ce programme initial ne coûte pas cher et se paiera donc très rapidement. QUAND les utilisateurs finaux en ont besoin pour faire plus ou aller plus vite, le code peut être refactorisé et mis à l'échelle.

C'est la raison principale derrière l'état actuel de la programmation; l'hypothèse, confirmée par toute l'histoire de l'informatique, est qu'un programme n'est JAMAIS statique. Il devra toujours être mis à niveau et il sera éventuellement remplacé. En parallèle, l'amélioration constante des ordinateurs sur lesquels les programmes s'exécutent permet une diminution de l'attention à l'efficacité théorique et une attention accrue à l'évolutivité et à la parallélisation (un algorithme qui s'exécute en temps N carré mais qui peut être parallélisé pour fonctionner sur N cœurs sera semblent linéaires, et souvent le coût de plus de matériel est moins cher que celui des développeurs pour concevoir une solution plus efficace).

En plus de cela, il y a le principe très simple selon lequel chaque ligne de code développeur est quelque chose d'autre qui peut mal tourner. Moins un développeur écrit, moins il est probable que ce qu'il écrit a un problème. Ce n'est pas une critique du "taux de bogues" de quiconque; c'est une simple déclaration de fait. Vous savez peut-être comment écrire un MergeSort en arrière et en avant dans 5 langues, mais si vous ne touchez qu'un seul identifiant dans une ligne de code, le tri entier ne fonctionne pas, et si le compilateur ne l'a pas détecté, cela peut vous prendre heures pour le déboguer. Comparez cela avec List.Sort (); c'est là, c'est efficace dans le cas général, et, voici la meilleure chose, ça marche déjà.

Ainsi, un grand nombre des fonctionnalités des plates-formes modernes et des principes des méthodologies de conception modernes ont été construits dans cet esprit:

• POO - créez des données et une logique associées dans un objet, et partout où le concept de cet objet est valide, de sorte qu'il soit l'objet, ou une dérivation plus spécialisée.
• Modèles prédéfinis - 60% ou plus du code est une corruption syntaxique et les bases pour que le programme affiche quelque chose à l'écran. En standardisant et en générant automatiquement ce code, vous réduisez de moitié la charge de travail du développeur, ce qui permet une augmentation de la productivité.
• Bibliothèques d'algorithmes et de structures de données - Comme dans ce qui précède, vous savez peut-être comment écrire une pile, une file d'attente, un QuickSort, etc., mais pourquoi le devez-vous, alors qu'il existe une bibliothèque de code qui intègre tout cela? Vous ne réécririez pas IIS ou Apache parce que vous aviez besoin d'un site Web, alors pourquoi implémenter un algorithme QuickSort ou un objet arborescent rouge-noir lorsque plusieurs implémentations intéressantes sont disponibles?
• Interfaces fluides - Dans le même sens, vous pouvez avoir un algorithme qui filtre et trie les enregistrements. C'est rapide, mais ce n'est probablement pas très lisible; cela prendrait un jour à votre développeur junior juste pour le comprendre, et encore moins pour effectuer le changement chirurgical nécessaire pour trier sur un champ supplémentaire dans l'objet d'enregistrement. Au lieu de cela, des bibliothèques comme Linq remplacent beaucoup de code très laid, souvent fragile, par une ou deux lignes d'appels de méthode configurables pour transformer une liste d'objets en objets filtrés, triés et projetés.

IL me semble que vous le faites et non CS et cela ne devrait pas impliquer que CS est mort. CS n'est pas mort, c'est juste que la plupart des emplois sont dans le développement de logiciels. Étant donné que la plupart des étudiants CS apprennent à programmer, ils finissent généralement par embaucher comme programmeurs et non comme informaticiens. Les emplois en informatique sont minuscules par rapport aux emplois de programmation. Vous pourriez même faire une application complexe utilisant des techniques informatiques, mais à mon avis (et je n'aime pas les réponses d'opinion parce qu'elles sont subjectives), cela relève du camp d'ingénierie d'un camp de scientifiques.

De plus, un code beau et élégant est dans l'œil du spectateur , mais pour la plupart des entreprises / gestionnaires, avoir un design suffisamment bon à l'heure est beaucoup plus important qu'un beau code mais ne se termine jamais à l'heure.

Enfin, il y a le monde réel et le Lala-land. Malheureusement, nous obtenons le chèque de paie de l'ancien, et c'est là que la "science / art" du développement logiciel entre en jeu sur la façon de produire un logiciel de haute qualité avec des contraintes de temps / budget. J'ai ressenti le même type de sentiments que vous avez au début de ma carrière. J'ai toujours voulu créer "le meilleur", mais je me suis vite rendu compte que "le meilleur" n'était pas le design le plus efficace ou élégant, mais le plus rentable.

Tout d'abord, vous vous êtes trompé. «penser, planifier et résoudre efficacement des problèmes» n'est pas de la science, c'est de l'ingénierie. La science consiste beaucoup plus à explorer de nouveaux domaines. Et en réalité, dans le monde universitaire, les gens se soucient beaucoup moins de l'efficacité du code que de l'industrie. Dans le monde universitaire, il s'agit davantage de preuves de concept, etc.

Non, ce que vous décrivez, c'est que des connaissances moins approfondies sont nécessaires pour le développement de logiciels. Ce qui pourrait être vrai si les exigences étaient les mêmes. Mais de nos jours, on s'attend à ce que l'ingénieur logiciel sache comment gérer le multi-threading, l'informatique distribuée, la mise à l'échelle, etc. Ils doivent savoir comment diriger efficacement un projet. La plupart de cela n'était pas du tout dans les programmes d'études il y a quelques décennies.

Je ne pense pas que ce que vous avez dit soit tout à fait exact, mais vous avez quand même quelque chose à dire . Plus précisément, je pense qu'avec le temps, l'informatique et le génie logiciel se sont séparés.

Le génie logiciel (comme les autres ingénieurs) consiste à appliquer la science pour créer des produits, résoudre des problèmes, etc. L'informatique concerne principalement la recherche sur les algorithmes et (bien que cette partie soit souvent un peu oubliée) comment mettre en œuvre ces algorithmes (au moins dans un certain sens théorique - par exemple, peut-être traiter toutes les machines PRAM comme équivalentes).

En gardant cela à l'esprit, je pense que la raison de la bifurcation devient évidente: la plupart des problèmes algorithmiques impliqués dans quelque chose comme un site Web typique ont déjà été résolus - la plupart d'entre eux, il y a longtemps. Peut-être plus important encore, la plupart de ces problèmes ont été suffisamment résolus pour que, pour le développeur Web moyen, le problème ait presque complètement disparu. Par exemple, faire des mises à jour atomiques dans des bases de données distribuées n'est certainement pas une tâche triviale - mais un développeur Web typique écrit juste du SQL et n'a aucune idée (ou attention) sur la quantité de recherche qu'il a fallu pour comprendre comment faire le travail fiable.

À une certaine époque, il était pratiquement impossible de séparer l'informatique du génie logiciel. Si peu de problèmes ont été résolus que la rédaction d'un programme, même relativement trivial, nécessite des recherches sur les principes fondamentaux. Si vous vouliez faire quelque chose d'aussi simple que de trier un tas de données à la fin des années 50 ou au début des années 60, les chances étaient bonnes que vous alliez devoir faire une analyse de vos données et essayer de concevoir un algorithme qui correspond le mieux possible à ce qu'il faudrait pour trier ces données particulières - nulle part près autant d'algorithmes de tri n'étaient connus aujourd'hui, et même les algorithmes qui étaient connus n'étaient pas aussi bien connus qu'ils le sont aujourd'hui .

50 ans de recherche et développement ont cependant porté leurs fruits - la plupart des développements typiques peuvent utiliser non seulement des algorithmes connus, mais des implémentations pré-écrites. La plupart des problèmes typiques peuvent être résolus assez raisonnablement sur la base des connaissances existantes (et même des implémentations existantes) des algorithmes.

Cela ne signifie pas pour autant que l'informatique est morte - il y a encore plus d'algorithmes à rechercher, et les gens font des recherches sur eux. Cela signifie cependant que la plupart des recherches sont plus spécialisées et ne s'appliqueront probablement qu'à des domaines assez spécialisés. Il y a probablement aussi un plus grand «écart» entre l'acquisition et l'application des connaissances. À un moment donné, vous avez trouvé une meilleure façon de trier dans le processus d'écriture d'un programme de tri, et il a été écrit en code réel presque immédiatement. Maintenant, beaucoup d'informatique est consacrée à des choses comme la façon d'utiliser un nombre essentiellement infini de processeurs - ce qui sera probablement utile un jour, mais même les tribus primitives ne compteraient pas les deux cœurs de mon ordinateur comme "beaucoup" ... :-)

Le développement de logiciels et l'informatique ne sont pas la même chose, et j'ai constaté que la plupart de mes camarades de classe dans un B.Sc. Le programme Comp Sci en a été frustré.

Je considère le logiciel comme un produit de l'informatique ... comme les peintures sont un produit de l'art visuel.

Je pense que la plupart des gens avec des diplômes CS sont embauchés dans des emplois pour effectuer le développement de logiciels, surtout au début de leur carrière. Je pense que beaucoup de personnes dans ce rôle y restent et ne vont pas plus loin.

Je pense que la différence commence à apparaître lorsque de nouveaux problèmes ou paradigmes apparaissent ou lorsque «le gifler ensemble» n'est pas suffisant. Qui construit les nouveaux frameworks ou langages? Qui s'assoit et martèle les détails d'un nouveau moteur physique? Qui utilise la théorie des graphes / les transformations de graphes pour extraire quelques cycles par itération des performances d'un algorithme?

Je terminerai là où j'ai commencé, convenant qu'il y a beaucoup d'informaticiens dans des rôles de développement / ingénierie de logiciels, peut-être pas à la hauteur de leur potentiel.

Vous semblez confondre l'informatique avec la programmation et le développement de logiciels en général. Les deux ne sont pas les mêmes, pas même proches. Indépendamment de ce que nos diplômes peuvent dire, la grande majorité d'entre nous sont des programmeurs, pas des informaticiens. À moins que vous ne soyez activement impliqué dans le monde universitaire à un haut niveau, je parierais que vous n'avez pas vraiment la moindre idée de ce qui se passe en informatique.

Je peux vous dire que l'informatique est bel et bien vivante. Je dois résoudre de nouveaux problèmes quotidiennement et trouver une solution efficace et élégante à ces problèmes. Je dois quotidiennement utiliser mes compétences d'ingénieur et utiliser mes connaissances et celles de mes collègues pour résoudre ces problèmes pour notre client.

Je n'essaie pas de détester les langues, je comprends qu'elles servent un but et le font bien, mais lorsque vos employés ne savent pas comment fonctionne une table de hachage, et utilisent les mauvaises méthodes de tri, ou exécutent des commandes SQL qui sont horriblement inefficaces (mais font le travail dans un délai acceptable), il semble que plus d'efforts soient déployés pour développer des technologies qui dorloter les nouveaux `` programmeurs '' plutôt que d'enseigner réellement aux gens comment faire les choses correctement.

Cela ressemble à un problème avec l'employé et certainement pas vrai pour tous les programmeurs.

Ce n'est pas parce que des outils qui facilitent notre travail existent que nous ne devons pas comprendre la technologie soulignée.Si nous ne le faisons pas, nous n'aidons personne et ne faisons certainement pas notre travail pour résoudre les problèmes de la bonne manière.

Vous n'avez tout simplement pas compris le problème actuel. Le problème n'est pas d'obtenir les performances maximales, mais d'obtenir des performances suffisantes pour que votre application soit réactive et suffisamment rapide. Apprendre à programmer, c'est résoudre le problème, pour le moindre montant.

Je déteste l'exprimer ainsi, mais toute impression que vous avez à propos de la mort de CS n'est que vos propres pré-conceptions de ce qu'un "vrai" programmeur devrait avoir à faire.

Eh bien, mort ou non, c'est discutable!

Le fait est que dans l'ère technologique d'aujourd'hui, la plupart des entreprises embauchent des personnes pour résoudre des tâches de type workflow dans le monde réel grâce à l'automatisation logicielle. Ils ne sont pas intéressés par l'élégance ou la rapidité avec laquelle un programme peut être écrit, tant qu'il permet à l'entreprise de s'exécuter plus rapidement avec un rendement plus élevé.

L' accent est mis sur plus de rendement en moins de temps. (Pensez à la commercialisation des cultures / aliments; une croissance plus rapide et plus à moindre coût). La même chose se produit dans le monde de la technologie (la prochaine nouvelle idée).

Rappelez-vous, de nos jours, les choses évoluent plus rapidement que jamais en raison de la quantité et de l'accès aux connaissances que dans le passé. Autrefois, la production était petite et meilleure, les profits plus élevés. Maintenant, le jeu a complètement changé. Il suffit de regarder des choses comme la qualité du service client et en général, les choses ne durent pas plus longtemps.

L'élégance et l'efficacité sont importantes pour les entreprises technologiques comme Google, etc., même si ces endroits ne sont pas parfaits, mais vous pouvez vous en approcher en travaillant avec l'une de ces entreprises dans les années à venir.

Il y a toujours un compromis dans la vie. Vous pouvez trouver un travail qui paie moins, où vous avez tout le temps et toute l'attention. Ou, vous choisissez de nager avec le reste d'entre nous pour un meilleur salaire et d'ignorer les choses qui ne sont pas parfaites. Plus vite cette réalisation s'enfonce en vous, vous pouvez vous adapter au monde réel. Je ne dis pas que vous devez ignorer la qualité et l'élégance mais connaître la dynamique. Vous serez plus heureux :)

À mon avis, certaines des choses les plus intéressantes que l'avenir pourrait retenir seront certainement basées sur la partie scientifique de l'informatique, en particulier l'amélioration de la vision par ordinateur / de l'apprentissage automatique et d'autres algorithmes de sematisation. Ceux-ci seront probablement poussés dans l'industrie (par exemple, prenez le Microsoft Kinect), mais ce sont des problèmes extrêmement difficiles qu'ils seront certainement basés sur le grand nombre de recherches et de progrès réalisés dans les universités (encore une fois, prenez le Microsoft Kinect).

Je pense que la programmation quotidienne standard est autant un art qu'une science, mais il existe certainement des domaines qui sont profondément intéressés par les aspects scientifiques de l'informatique. Par exemple des chercheurs pour des entreprises et des universités. Si vous voulez vraiment vous impliquer professionnellement dans les sciences, vous devriez chercher un doctorat. Cependant, j'ai trouvé que les parties scientifiques de mon éducation étaient toujours précieuses, même si j'avais également besoin de compter sur mon côté plus créatif dans la réalité!

Les gens qui ne savent pas ce qu'ils font peuvent pirater les choses avec certains des outils que vous avez mentionnés, mais ils embauchent généralement les vraies personnes CS pour fabriquer les outils, il vous suffit d'obtenir plus d'abstrait pour vraiment vous pousser.