Une dépendance excessive à l'égard des outils implique-t-elle que vous êtes paresseux? [fermé]

J'ai commencé à programmer en C ++ à uni et j'ai adoré. Lors du prochain mandat, nous sommes passés au VB6 et je détestais ça.

Je ne pouvais pas dire ce qui se passait, vous faites glisser un bouton vers un formulaire et l'ide écrit le code pour vous.

Bien que je détestais la façon dont VB fonctionnait, je ne peux pas affirmer que c'était plus rapide et plus facile que de faire la même chose en C ++, donc je peux voir pourquoi c'est un langage populaire.

Maintenant, je n'appelle pas les développeurs VB paresseux en disant simplement que c'est plus facile que C ++ et j'ai remarqué que de nombreux langages plus récents suivent cette tendance comme un C #.

Cela m'amène à penser que plus les entreprises veulent des résultats rapides, plus de personnes programmeront ainsi et tôt ou tard, ce que nous appelons la programmation n'existera plus. Les futurs programmeurs diront à l'ordinateur ce qu'ils veulent et le compilateur écrira le programme pour eux comme dans Star Trek.

S'agit-il simplement d'une opinion sous-informée d'un programmeur junior ou les programmeurs deviennent-ils paresseux et moins compétents en général?

EDIT: Beaucoup de réponses disent pourquoi réinventer la roue et je suis d'accord avec cela, mais quand il y a des roues disponibles, les gens ne se soucient pas d'apprendre à fabriquer la roue. Je peux google comment faire à peu près n'importe quoi dans n'importe quelle langue et la moitié des langues font tellement pour vous quand il s'agit de déboguer, ils n'ont aucune idée de ce que fait le code pour corriger l'erreur.

C'est comme ça que je suis arrivé à la théorie selon laquelle les programmeurs deviennent de plus en plus paresseux et moins compétents, car personne ne se soucie de la façon dont les choses fonctionnent juste ce qu'elles font jusqu'à ce qu'elles ne le soient pas.

Non, les développeurs ne sont pas paresseux ou moins compétents. Oui, il y a un besoin de développement réel en constante diminution, dans le sens où vous le savez. Et oui, c'est très bien parce que les entreprises veulent des résultats rapides, et pourquoi pas?

Cependant, il y a un point final. Il y aura toujours un besoin pour certains développeurs.

De nombreuses exigences sont les mêmes pour différents projets. Celui dont vous parlez est le code UI. La plupart des interfaces utilisateur sont constituées d'un ensemble spécifique de champs - zone de texte, case à cocher, radio, sélection, etc. - et il est vraiment inutile de les développer à partir de zéro, encore et encore et encore. Ainsi, des couches d'abstraction sont mises en place pour supprimer tout ce code passe-partout.

De même, la couche de données, qui n'est généralement rien d'autre que Insérer ceci, Supprimer ceci, Remplacer cela et un grand nombre de vues différentes des mêmes données. Pourquoi continuer à écrire ça encore et encore? Inventons les ORM.

La seule chose que vous devriez développer est un code unique à l'entreprise pour laquelle vous développez.

Mais il y aura toujours cette unicité - là où il n'y en a pas, il y a une opportunité commerciale - et il y aura toujours un besoin pour les gens d'écrire du code.

Cela dit, gardez également à l'esprit qu'il y a beaucoup plus à être développeur que d'écrire du code. Que vous codiez en assemblage pur ou assembliez des composants Drupal pour créer un site axé sur le contenu, vous traduisez le besoin de l'entreprise en quelque chose que l'ordinateur comprend.

La partie la plus importante d'un développeur de logiciels est d'être en mesure de comprendre suffisamment les besoins de l'entreprise pour les expliquer à l'ordinateur.

Peu importe la langue que vous utilisez pour expliquer les choses à l'ordinateur, il importe seulement que vous le puissiez. Et c'est un travail difficile, rien de paresseux.

Un mécanicien est-il paresseux et moins compétent parce qu'il utilise une clé hydraulique ?

Imaginez deux gars, disons Brad et Pete. Ils travaillent tous les deux dans deux garages qui changent de pneus quotidiennement. Brad est un gars intelligent, il sait que l'utilisation de meilleurs outils peut faire son travail mieux et plus rapidement. L'utilisation de la clé hydraulique l'aide à changer plus de pneus. Les clients attendent dans une file d'attente plus courte - tout le monde est content. Bard sait également que cette clé est parfois trop grosse et qu'elle ne peut pas l'aider avec différents types de vis.

D'un autre côté, Pete dit que la clé hydraulique est un blasphème et Brad n'est pas un "vrai mécanicien". Bien sûr, Pete ne peut faire que la moitié de ce que Brad fait, mais il le fait de la "bonne manière".

Maintenant que pensez-vous, quels clients de garage choisiraient? Un qui prend 20 minutes ou un avec 40 minutes d'attente.

C'est assez similaire avec la programmation. C ++ est un bon langage et a sa fonction (principalement la performance). Ce que j'aime dans les langages comme C #, c'est que je peux me concentrer sur un problème, penser à un algorithme sans tout le bruit que fait C ++ comme les avertissements ambigus du compilateur, les comportements indéfinis, etc. Le développement devient de plus en plus compliqué que dans les vieux jours des ordinateurs centraux et des premiers PC, pourtant le cerveau humain reste le même - à peu près stupide. Une application peut fonctionner dans le cloud, mobile, bureau, il y a beaucoup de dépendances, problèmes de sécurité et autres problèmes. Je veux avoir un meilleur outil pour me concentrer sur des problèmes plus complexes et les résoudre.

Utilisez de meilleurs outils pour faire le travail - il n'y a rien de mal à cela.

Alors, comment appelons-nous la programmation maintenant

Vous dites:

Les futurs programmeurs diront à l'ordinateur ce qu'ils veulent et le compilateur écrira le programme pour eux comme dans Star Trek.

faites juste une expérience: regardez Star Trek et essayez d'interpréter les choses que l'ordinateur a l'ordre de faire un peu «sans grâce».

• Thé, comte gris, chaud -> beaucoup de vapeur.
• Thé, comte gris, 60 degrés Celsius -> une flaque d'eau et un nuage de vapeur
• comte gris, 60 degrés Celsius -> une flaque d'eau
• Earl Grey, 60 degrés Celsius, dans une tasse -> une tasse avec une goutte dedans
• Earl Grey, 60 degrés Celsius, 0,2 litre, dans une tasse. -> enfin (ok, vous pouvez en savoir plus)

Lorsque vous appelez Programmation: «Connaître l'utilisation de la mémoire, les pointeurs, etc.», oui, je suppose que cela deviendra moins important (comme «Connaître http, openid, unicode» deviendra plus important).

Mais, à mon avis, tout est `` complexité accidentelle '', et le vrai travail de programmeur est `` Faire en sorte que les machines de construction résolvent les problèmes, en s'assurant que l'on comprend suffisamment les problèmes accidentels pour accomplir la tâche '', et par cette définition, quelqu'un conversant avec un ordinateur Star Trek doit être un programmeur (c'est-à-dire avoir les mêmes vertus que maintenant).

Les programmeurs ne deviennent pas paresseux. Les programmeurs ont toujours été paresseux. Être paresseux fait partie de la nature fondamentale du travail. Le problème est que les gens supposent qu'être paresseux est négatif. Être un programmeur "paresseux" est une vertu.

Rappelez-vous le vieil adage «Travaillez plus intelligemment, pas plus dur». C'est le moteur fondamental des programmeurs.

Les gars qui ont construit et programmé les premiers ordinateurs ne l'ont pas fait parce qu'ils aimaient travailler dur, ils l'ont fait pour ÉVITER un travail encore plus difficile. (faire des pages de calculs à la main)

Être «paresseux» est l'une des raisons fondamentales pour lesquelles les programmeurs programment. C'est pourquoi nous écrivons de nouveaux langages de niveau toujours plus élevé, de meilleurs débogueurs et IDE, des scripts shell et build, etc ...

Un programmeur regarde un problème, tout ce qu'il fait et pense;

"puis-je automatiser cela?" , "combien de temps cela prendrait-il?" , "combien de temps cela me ferait-il gagner?"

Nous le faisons parce que nous sommes paresseux, nous ne voulons pas faire une tâche répétitive et ennuyeuse alors que nous pourrions faire des choses beaucoup plus amusantes.

Si les programmeurs n'étaient pas paresseux, aucun programmeur n'aurait jamais vu la nécessité d'écrire un seul nouveau langage ou compilateur.

En ce qui concerne la notion qu'un programmeur est "paresseux" parce qu'il doit "chercher les choses", alors quoi, peu importe. L'hypothèse selon laquelle il est plus difficile d'apprendre chaque nuance d'une langue particulière (et de ne jamais avoir à rechercher quelque chose), puis de trouver et d'utiliser ce dont vous avez besoin quand vous en avez besoin est une erreur. En outre, le processus de recherche des choses est le processus d'apprentissage et la raison même pour laquelle des sites comme celui-ci existent.

Si quelqu'un veut un travail de programmation difficile, je lui dirais de coder manuellement du code machine brut en hexadécimal. C'est fait? Vous voulez quelque chose de plus difficile? Maintenant, allez le déboguer.

Tout d'abord, appeler des gens qui utilisent par exemple des langues avec le ramasse-miettes paresseux, c'est en quelque sorte appeler des gens qui conduisent des voitures avec une transmission automatique paresseux. OMI, c'est un peu ridicule.

Quant à la compétence, la programmation est un travail beaucoup plus populaire et égalitaire qu'elle l'était. Alors oui, il y a beaucoup de nouveaux arrivants qui manquent de connaissances. Je ne veux cependant pas dire qu'il y a soudainement des programmeurs moins compétents. En fait, il y en a plus. Vous regardez juste du mauvais côté de la courbe en cloche.

Je suis tenté de dire "oui, les programmeurs juniors avisés et non informés sont devenus paresseux et moins compétents", mais essayons une réponse sérieuse:

Beaucoup de choses sont devenues plus faciles, mais on attend plus de nous. Je suis en train de créer une application Web qui possède de nombreuses fonctionnalités généralement trouvées dans des applications graphiques bien conçues (vues tabulées, grilles modifiables et triables, exportation Excel, etc.). Les outils que j'utilise (ExtJS, etc.) rendent la création d'une telle application relativement peu coûteuse.

Il y a dix ans, il aurait été presque impossible, du moins très coûteux, de créer une telle application. Mais il y a dix ans, un simple formulaire HTML avec un tableau HTML aurait suffi aux clients. Aujourd'hui, avec le même effort, de meilleurs (au moins plus beaux) résultats sont possibles, et les clients s'attendent à les obtenir!

En général, un développeur de logiciels d'aujourd'hui doit connaître plus de langues qu'un développeur de logiciels il y a 20 ans. À l'époque, quelque chose comme C et SQL suffisait. Aujourd'hui, j'utilise JavaScript, HTML, Groovy, Java, SQL dans le même projet.

Les programmeurs deviennent moins compétents et paresseux à certains égards, mais plus compétents à d'autres, bien que la fracture C ++ / VB ne soit pas la raison ou un symptôme dans mon esprit.

L'utilisation d'un générateur d'interface graphique n'est pas paresseux, c'est juste différent, il s'agit d'outils pour le travail en cours. Si un programmeur assembleur appelé un programmeur C ++ paresseux, vous appelleriez des conneries à ce sujet (à juste titre) et il en va de même pour C ++ et VB. VB vous permet de faire certaines choses rapidement au détriment d'un certain contrôle. Les obstacles au démarrage du codage sont certainement plus faibles, mais c'est une chose très différente de la paresse - vous apprenez simplement différentes choses et les appliquez de différentes manières. Les programmeurs VB ne sont pas plus paresseux que les programmeurs C ++ sont improductifs, ils fonctionnent et produisent simplement de différentes manières.

Sur un point plus large, l'éducation des programmeurs est généralement meilleure maintenant qu'elle ne l'a jamais été. L'idée de ne pas utiliser le contrôle de source, par exemple, est assez odieuse pour presque tout le monde maintenant où il y a 10 ou 20 ans, cela n'aurait pas été aussi vrai. De même, ils sont plus susceptibles de comprendre et de vouloir utiliser des tests unitaires automatisés, une intégration continue, etc., de sorte qu'en ce sens, ils sont plus compétents qu'ils ne l'étaient.

Mais ce que je pense a changé, c'est que les gens ne savent plus comment résoudre les problèmes comme ils le faisaient auparavant, et c'est vrai dans à peu près n'importe quel langage traditionnel. La réponse instantanée à tout problème est maintenant Google et même si c'est génial et fonctionne 95% du temps, je vois trop de programmeurs qui ne savent pas quoi faire quand ce n'est pas le cas.

Ce n'est pas qu'ils ne comprennent pas les principes fondamentaux (ils ne le font pas mais ce n'est pas vraiment un gros problème), c'est qu'ils ne peuvent pas décomposer les problèmes de telle manière qu'ils peuvent même déterminer les principes fondamentaux dont ils ont besoin pour être aux prises avec.

Avant Google, vous n'aviez pas le choix. Vos ressources étaient votre équipe, quelques dizaines de livres physiques auxquels vous pourriez avoir accès et votre cerveau. Cette configuration signifie que si vous rencontrez un problème, il est probable que vous le résolviez vous-même à partir de quelque chose de proche des premiers directeurs, de sorte que vous êtes devenu très bon ou assez rapidement au chômage.

Et c'était vrai quelle que soit la langue que vous utilisiez. Le VB est de haut niveau et se cache beaucoup, mais cela signifie qu'en matière de résolution de problèmes, cela signifiait en fait qu'il fallait plus de travail. Si quelque chose ne fonctionnait pas, vous deviez faire preuve de plus de créativité et travailler plus fort, car vous aviez moins de contrôle. En tant que programmeur VB (et je parle d'expérience), vous ne saviez pas moins que les gars C ++, vous saviez juste des choses différentes mais vous saviez tous les deux comment résoudre les problèmes.

Mais il est probablement difficile de voir cela comme une critique importante des programmeurs de nos jours, ils ne développent pas les compétences parce qu'ils n'en ont pas besoin, mais c'est une faiblesse par rapport à ceux qui ont acquis les compétences quand elles étaient nécessaires.

Je constate d'après votre profil que vous avez 23 ans. Permettez-moi de mettre mes dents dedans et de vous donner le point de vue de quelqu'un d'environ deux fois votre âge qui fait cela depuis très longtemps:

Auparavant, il y avait beaucoup moins de tout, à commencer par la puissance de calcul, le stockage et la bande passante du réseau, si vous aviez un réseau. Ces pénuries imposent des limites à ce que vous pouvez raisonnablement faire, ce qui facilite beaucoup plus la compréhension de tout. Le logiciel que nous utilisons aujourd'hui est bien plus performant que les choses avec lesquelles je travaillais il y a 25 ou 30 ans, et ces capacités signifient qu'il y en a beaucoup plus. Cela rend la collecte d'une compréhension fine de tout beaucoup plus difficile pour une seule personne. Cela tient en partie au fait que les choses vont continuer à augmenter en complexité et en partie aux effets secondaires de l'âge.

L'écosystème informatique ressemble beaucoup aux systèmes biologiques: les humains sont plus complexes que les organismes unicellulaires, et certaines parties de nous doivent se spécialiser si nous voulons réussir à faire quoi que ce soit. Mes cellules cérébrales sont terriblement douées pour les choses intellectuelles, mais elles seraient perdues si elles étaient plongées dans mon rein et attendaient de faire des choses rénales. De même, le gars qui sait bien écrire des processeurs de signaux numériques pourrait ne pas avoir la moindre idée du fonctionnement de l'indexation de texte intégral, car ce n'est tout simplement pas sa spécialité. Mais les deux pourraient évoluer un peu et apprendre à le comprendre s'ils en avaient besoin, mais il y a des limites à la mesure dans laquelle vous pouvez vous propager et être toujours efficace dans ce que vous faites.

... personne ne se soucie de la façon dont les choses fonctionnent juste comme ça jusqu'à ce que ce ne soit pas le cas.

Lorsque vous avez un travail à faire, vous devez souvent faire le geste de croire qu'un outil que vous utilisez (bibliothèque, SGBDR, sous-système entier, etc.) fonctionne comme il se doit. L'une des choses que l'expérience apporte est la possibilité de choisir les trous de lapin que vous allez exécuter pour dénicher les défaillances de vos outils, résoudre le problème, puis revenir à ce que vous faisiez.

Maintenant, je n'appelle pas les développeurs VB paresseux en disant simplement que c'est plus facile que C ++ et j'ai remarqué que de nombreux langages plus récents suivent cette tendance comme un C #.

C'est une question de perspective. J'étais là pour voir le C ++ voir le jour, et il suit également cette tendance. C ++ rend les choses beaucoup plus faciles que C, C rend les choses beaucoup plus faciles que l'assemblage et l'assemblage rend les choses beaucoup plus faciles que d'écrire des opcodes à la main. En tant que personne qui a écrit beaucoup d'assemblages et assemblé quelques choses à la main à partir de zéro, cela vous mettrait, en tant que programmeur C ++, trois étapes sur le chemin "c'est plus facile".

Quelque chose que je maintiens depuis longtemps maintenant est:

L'une des plus grandes forces du langage Visual Basic est qu'un débutant peut apprendre à faire beaucoup de choses utiles assez rapidement.

L'une des plus grandes faiblesses des programmeurs Visual Basic est qu'ils apprendront à faire beaucoup de choses utiles assez rapidement, puis ils arrêteront d'apprendre quoi que ce soit.

Lorsque j'enseignais la programmation du premier exercice, le premier jour de cours était de savoir comment créer une application dans NOTEPAD et la compiler en utilisant VCC ou VBC. Oui, ce sont des choses que nous (en tant que programmeurs) ne faisons pas quotidiennement, mais nous devons comprendre ce qui se passe lorsque nous appuyons sur "F6".

Les programmeurs ne deviennent (généralement) pas plus «paresseux» que nous nous attendons à tirer le meilleur parti de nos outils. Je n'ai pas besoin de taper "get / set" 10 000 fois par jour, J'AIME que Visual Studio et d'autres outils comme Code Smith et Resharper travaillent pour moi pour faire ce que je sais déjà faire afin que je puisse appliquer mes efforts à la figuration comment faire de "nouvelles" choses. Cela ne me rend pas paresseux, cela me rend "innovant".

En tant que développeur professionnel, nous ne devrions pas «perdre du temps» à réinventer la roue, mais nous devons clairement comprendre ce qui entre dans la fabrication de la roue que nous allons utiliser. Ce sont des choses que nous «devrions» apprendre en tant que développeurs étudiants (mais malheureusement, ce n'est souvent pas le cas). Si un développeur ne comprend pas une technologie de "boîte noire", cela le rend-il vraiment moins "compétent". La plupart des développeurs ne «comprennent» essentiellement que le fonctionnement d'un pilote ODBC, ils comprennent simplement «ce qu'il» fait. Dois-je savoir comment fonctionne une transmission pour être un conducteur compétent? Je dirais que non. Cela fait-il de moi un propriétaire de voiture plus compétent pour le savoir, oui.

Le besoin de développement rapide d'applications (lien wiki obligatoire: http://en.wikipedia.org/wiki/Rapid_application_development ) signifie que les développeurs écrivent moins de code et que les développeurs plus récents comprennent moins, car ils n'ont pas besoin de comprendre comment implémenter un liste liée car ils ont quelque chose de plus élevé à se concentrer.

Je ne peux pas attraper, tuer, écorcher, boucher et soigner la viande, et je doute que le gars du café en bas le puisse, mais je reçois toujours mon sandwich au bacon de lui, tout comme les hommes d'affaires obtiennent leurs applications de développeurs qui ne connaissent pas pointeurs (comme moi!)

On a dit que les grandes disciplines scientifiques sont des exemples de géants se tenant sur les épaules d'autres géants. Il a également été dit que l'industrie du logiciel est un exemple de nains debout sur les orteils d'autres nains.
- Alan Cooper

Un bon développeur de logiciels n'est pas celui qui réinvente la roue. Il est capable d'utiliser les outils qui ont été construits avant lui. Il ne perd pas de temps à réécrire les mêmes vieux trucs ennuyeux, qui ont été écrits des centaines de fois, deviennent rapidement fastidieux et existent probablement déjà dans une version de meilleure qualité.
Si vous leur donnez une langue qui contient déjà des disques de pierre ronds, il y a de fortes chances qu'ils ne passent pas trop de temps à réinventer les roues. Si j'avais un centime pour chaque routine de copie de chaîne jamais écrite en C, je pourrais probablement acheter toute l'industrie du logiciel.

La paresse est en fait l'une des trois grandes vertus d'un programmeur. Les outils dont vous parlez ont été conçus par de bons programmeurs pour de bons programmeurs, pour réduire la redondance et l'ennui et ainsi augmenter la productivité et la motivation. De tels outils peuvent en effet avoir des effets négatifs sur les débutants, car ils empêchent une compréhension plus approfondie de l'aspect de programmation qu'ils simplifient.

Non, tu vieillis.

Sans plaisanter, ce que vous vivez est une sorte de droit de passage pour les développeurs. Depuis les premiers langages de niveau supérieur ont supplanté l'assemblage. À l'époque, vous auriez entendu tous les programmeurs ASM se plaindre de la même chose. Dans 5 ans, tous les développeurs Ruby on Rails se plaindront de la façon dont une nouvelle génération de nouveaux outils paresseux rend les gens.

Ce refrain sera répété jusqu'à ce que les machines nous détruisent tous: "Est-ce que la technologie X rend les développeurs plus paresseux et pires que la technologie Z que j'ai toujours utilisée?"

La bonne nouvelle est que, même si les compilateurs ont parcouru un long chemin, les gens ont encore besoin d'assemblage et de C et de tous les autres vieux piliers pour beaucoup de choses ... mais pas la majorité des innovations technologiques de pointe. Si vous voulez être à la pointe de la technologie, je vous suggère de mettre à jour votre ensemble de compétences.

D'après mon expérience, oui et non, mais ce n'est pas la faute des langues; c'est la faute des développeurs eux-mêmes. J'ai travaillé avec de nombreux développeurs qui ne se souciaient pas de bien faire les choses, de s'améliorer ou de faire vraiment autre chose que de produire la même merde qu'ils ont fait pendant des années. Essayer d'amener ces gens à s'améliorer, c'est comme parler à un mur de briques - la moitié du temps, ils ignorent tout ce qu'ils n'ont pas utilisé dans le passé ou ne veulent absolument pas "tenter leur chance" avec quelque chose qui pourrait améliorer leur productivité. .

Les langages plus avancés ne sont pas le problème, ce sont les programmeurs qui ne traitent pas ce métier comme un métier en constante évolution. Vous n'avez pas besoin d'être intimement au courant de tout ce qui est nouveau ou de sauter dans chaque nouveau mouvement, mais vous devriez au moins essayer de devenir meilleur dans ce que vous faites.

Pour un exemple concret: je suis développeur .NET par métier. Je m'attendrais à ce qu'un développeur .NET compétent soit au courant de choses comme LINQ, Entity Framework, WPF, MVC et similaires; ils n'ont pas besoin de l'avoir utilisé, ou de le pousser sur le lieu de travail, mais au moins une compréhension passagère de "Cela existe" vaut mieux qu'une ignorance absolue que je vois beaucoup trop souvent.

Je ne code que depuis environ 4 ans et je travaille presque entièrement en c #. J'ai appris le C ++ à l'université et à l'université, mais je ne pourrais pas en faire grand-chose maintenant.

Donc, pour le développement de l'interface graphique, cela pourrait être considéré comme paresseux, mais là encore, ne pourrait-on pas voir que vous pouvez vous concentrer moins sur le codage de cette partie et plus sur le développement de la logique de l'application elle-même.

alors peut-être que plutôt que de devenir moins compétents, ils se concentrent, probablement beaucoup vers la communication et les systèmes distribués, par exemple le cloud computing et SOA. Bien que cela puisse être aussi similaire à celui d'un programmeur intermédiaire.

Il est probablement vrai que la barrière à l'entrée dans les emplois de programmation diminue chaque année. Par exemple, il est désormais possible pour les ingénieurs dont la spécialité n'est pas principalement les logiciels et les artistes d'écrire du code à l'aide de langages de script.

Cela implique que le niveau de compétence a effectivement augmenté, si l'on considère l'étendue. Le fait que les artistes puissent programmer signifie également qu'il y a maintenant plus de programmeurs ayant des compétences artistiques.

Il y a une différence entre "programmeur" et "vrai programmeur". Veuillez ne pas appeler HTML un langage de programmation, mais il y a beaucoup de "programmeurs HTML". Chacun de vous (programmeurs / développeurs) peut faire une expérience avec ses collègues - il suffit de "désactiver Internet (en fait, ne pas leur permettre d'utiliser les moteurs de recherche)", et vous verrez qu'une grande variété de "programmeurs" seront assis sans emploi. Ce qu'ils peuvent faire, ils savent juste que s'ils ont besoin, par exemple, de rechercher dans le texte, ils devraient "rechercher" la recherche de texte dans% language_name% ""? Ils ne peuvent pas répondre à cela - quelles sont les différences dans les algorithmes de Boyer-Moore et Knuth-Morris-Pratt.

Donc, IMO, programmer signifie résoudre des problèmes, connaître très bien au moins un langage de programmation avec sa «STL» et d'autres choses importantes. La programmation est un art, c'est une sorte de vie, ce n'est pas une chose que tout le monde peut faire.

Désolé pour plus de sarcasme que nécessaire, mais je pense que cet article dit mieux que moi.

Ai-je tort?

UPD: La chose principale et importante est la connaissance des principes fondamentaux, tels que les algorithmes, les structures de données, etc. Combien d'entre vous peuvent implémenter les bibliothèques / fonctions standard / etc. au cas où aujourd'hui serait supprimé accidentellement? IMO, le programmeur devrait utiliser du code «extraterrestre» développé / bien débogué (bibliothèques / frameworks / etc), mais devrait toujours pouvoir réinventer la roue!

Concernant VB étant facile à utiliser, et les programmeurs paresseux choisissant VB à cause de cela:

Je pense que VB est entouré d'un grand mythe d'être facile à utiliser. Ce mythe était à l'origine quelque peu vrai: à l'époque de 1991 à 1994, lorsque les dinosaures ont marché sur la terre, il n'y avait que deux vrais outils RAD autour, VB et Delphi. Ils étaient assez similaires, mais NOTEZ CECI: Delphi et VB étaient tout aussi faciles à utiliser! La seule différence notable entre eux était que VB avait une syntaxe complètement illogique et produisait des programmes incroyablement lents.

Les interfaces graphiques C / C ++ ont été écrites dans MFC ou dans l'API Win brute. VB était donc certainement plus facile à utiliser que l'alternative Microsoft. Ensuite, le moulin à rumeurs s'est déroulé comme suit:

• VB est plus facile à utiliser que l'API Microsoft C / C ++ / Win. ->
• VB est plus facile à utiliser. ->
• VB est facile à utiliser. ->
• VB est le plus simple.

Cette rumeur a ensuite perduré, même si Delphi a toujours été tout aussi facile, sinon plus facile, car Pascal est un langage sensé et logique.

À la fin des années 90, Borland a publié un équivalent C ++ à Delphi: C ++ Builder. Maintenant, il y avait 3 outils tout aussi faciles. À cette époque, les quelques arguments rationnels restants pour utiliser VB sont morts. Pourtant, le mythe persistait. "VB est le plus simple".

Ensuite, Java est arrivé et il y avait aussi plusieurs outils RAD pour lui (et pour sa version fiasco de Microsoft appelée J ++). Pourtant, le mythe VB a survécu.

Ensuite, Microsoft a également pris en charge RAD pour C ++, et a également proposé C #, tout en un seul gros goo appelé .NET. Étant donné que le mythe VB persistait, ils ont réussi à inciter les anciens développeurs VB à utiliser VB.NET au lieu de C ++ ou C #. Même si VB.NET était tout à fait non compatible avec les versions antérieures de VB.

Aujourd'hui, VB est un langage complètement redondant. L'outil RAD n'est pas plus facile que tout autre outil RAD. La syntaxe du langage est carrément horrible, si mauvaise qu'elle encourage en fait une mauvaise conception de programme et de mauvaises pratiques de programmation.

Il existe une grande variété d'activités regroupées sous la bannière de la «programmation», et un nombre toujours plus grand de travailleurs impliqués au niveau «technicien» de l'échelle. Vous n'avez pas besoin d'être capable d'écrire des compilateurs, ni même de sélectionner parmi un ensemble d'algorithmes pour résoudre un problème particulier pour créer un site Web en PHP. L'industrie / la société a besoin de beaucoup de personnes produisant lesdits sites Web (apparemment), et aussi d'un certain nombre de programmeurs travaillant sur des problèmes plus difficiles. Ce deuxième groupe n'est pas paresseux ou incompétent dans son ensemble, ou nos avions tomberaient en flammes, des distributeurs automatiques de billets distribuant des quantités aléatoires d'argent liquide, des machines à rayons X délivrant des doses fatales de rayonnement, les marchés financiers s'emballant, etc. à propos de ce dernier :-)

Je pense que toutes les autres réponses ne font que jeter un coup d'œil sur le fait que ce n'est que la tendance généralisée qui va des langues de bas niveau aux langues de haut niveau.

Oui, l'industrie du logiciel passe des langues de bas niveau aux langues de haut niveau, l'a toujours fait et continuera probablement de le faire tant que nous construirons de meilleurs outils. Oui, cela pourrait être considéré comme paresseux, car vous avez dû travailler très dur pour faire des choses qui sont basiques par rapport à la norme d'aujourd'hui. Mais je ne dirais pas moins compétent. La compétence passe simplement de la mise en œuvre à la conception.

Low Level C'est quelque peu subjectif, mais à un niveau bas, vous travaillez plus près du matériel. Il y a moins de prise de main et d'hypothèses d'intention. Les outils de base sont présentés et faire avancer les choses est laissé au programmeur. Les langues de bas niveau sont venues en premier bien sûr, et sont généralement les outils de la vieille garde puisque les langues de niveau supérieur n'existaient pas au début. Il y aura toujours un développement de bas niveau. Mais je ne ferais pas de site Web en assemblage.

Niveau élevé L'objectif à des niveaux élevés est d'automatiser les fonctionnalités de base et de simplifier la programmation. Il abaisse la barre d'entrée pour les nouveaux programmeurs, accélère les tâches et standardise la façon dont nous représentons et traitons les données, souvent avec des frais généraux. Considérez une chaîne. Au début, quelqu'un utilisait probablement 1-26 pour az, et n'utilisait que 5 bits et devait simplement savoir quelle taille étaient ses mots. Ensuite, la norme ascii a été développée et nous avons eu des chaînes C avec un caractère de terminaison. Nous avons maintenant des objets qui gèrent les choses pour éviter les débordements de tampon et des sous-types spéciaux qui interdisent les caractères d'échappement. Ou une boucle. Une boucle "for" est toujours un niveau légèrement plus élevé qu'une boucle "while". Et une boucle "while" est vraiment juste une représentation d'une façon structurée d'appeler GOTO.

Également,

Les futurs programmeurs diront à l'ordinateur ce qu'ils veulent et le compilateur écrira le programme pour eux comme dans Star Trek.

Bienvenue dans le futur! C'est exactement ce que font les compilateurs. Autrefois, les gens devaient écrire le code machine à la main. Maintenant, nous avons automatisé cela et expliquons simplement à l'ordinateur comment écrire le code machine pour nous.

Je pense que quelque part en chemin, vous avez perdu de vue ce que les programmeurs sont payés pour faire.

Notre livrable n'est pas du code, c'est un logiciel qui fonctionne.

Nous ne construisons pas de meubles où les queues d'aronde découpées à la main confèrent en quelque sorte une valeur supplémentaire en raison de tout le "savoir-faire" manuel qui y est entré.

Nous sommes payés pour résoudre des problèmes commerciaux sur des ordinateurs). Si vous pouvez livrer le même produit en moins de temps pour moins d'argent, alors je pense que c'est notre OBLIGATION d'abandonner la prétention que les programmes C ++ sont supérieurs simplement parce qu'ils sont plus complexes à construire.

Le ratio (développeurs de programmes principaux / nombre de développeurs) diminue car:

• Les outils deviennent plus faciles, cela signifie que des talents plus petits sont nécessaires pour le même problème

• Les gens s'habituent aux technologies informatiques, ils sont plus disposés à dépenser de l'argent pour des outils personnalisés

• La littérature informatique est en croissance exponentielle, la spécialisation et la division du travail augmentent donc il n'y a plus de gens "aristotéliciens" qui parlent de tout (en fait ils n'ont pas besoin de tout savoir à cause des couches d'abstraction)

• Plus d'emplois offerts, le filtre est desserré

• Plus d'automatisation est nécessaire à chaque cycle de vie, la demande augmente et l'offre n'est pas suffisante

• Le ratio développeur / population augmente.

  Donc, les gens ne deviennent pas plus paresseux et moins compétents, la moyenne tombe parce que l'informatique est un domaine plus ouvert maintenant.

Beaucoup de réponses disent pourquoi réinventer la roue et je suis d'accord avec cela, mais quand il y a des roues disponibles, les gens ne prennent pas la peine d'apprendre à fabriquer la roue.

Vous ébranlez tout votre argument via le fait que les roues sont toujours fabriquées. Je vois votre point, mais j'ai remarqué que dans n'importe quelle discipline, il y a suffisamment de gens qui sont intéressés par les trucs de bas niveau pour continuer. Par exemple, j'utilise Qt pour créer des interfaces graphiques. Cet outil n'est pas arrivé par magie, les gens ont développé le lien entre les trucs de bas niveau et les trucs que je fais. Est-ce que moins de gens comprennent les choses de bas niveau, oui. Moins de gens peuvent également tuer leur propre nourriture ou réparer leur propre voiture, mais la société parvient à survivre.

Avant les années 40, les ordinateurs étaient des circuits câblés. Ensuite, Von Neuman a eu l'idée des emplacements de mémoire stockés. Je suis sûr que ces programmeurs du MIT pensaient qu'il allait dégrader leur métier en quelque chose de trop facile. Vint ensuite l'assemblage, puis FORTRAN, puis ada, puis C, puis c ++, puis java et ainsi de suite. Le fait est que le but d'une langue est de permettre une abstraction de plus en plus poussée. Cela a toujours été le but et c'est la raison pour laquelle le c ++ s'est propagé, puis java après. Mon plus gros bœuf est que les universités n'enseignent plus rien aux étudiants sur les ordinateurs. Je n'engage pas de programmeurs c # s'ils ne connaissent pas le c ++ comme le dos de leur propre main. Pourquoi? Parce qu'il est trop facile d'être un mauvais programmeur, le langage devient de plus en plus abstrait. Ils doivent comprendre les pointeurs, la gestion de la mémoire, la liaison dynamique, etc. . à l'intérieur et à l'extérieur avant de pouvoir comprendre C # au niveau auquel je leur fais confiance pour contribuer à notre base de code. Je leur fais également du mal à créer des fichiers avant de leur permettre d'utiliser Visual Studio. Cela dit, j'aime C # et un bon IDE, mais ils sont bons comme outils lorsqu'ils sont bien compris. À mon avis, une abstraction est plus utile lorsque vous comprenez les détails qui sont abstraits - c'est une idée très ancienne, voir Thomas d'Aquin sur la relation de l'abstraction aux détails.

Je pense qu'un autre bon exercice pour les développeurs débutants est de leur faire écrire quelques applications en utilisant l'API Windows. Ensuite, après l'avoir terminé, demandez-leur de le rendre orienté objet où chaque forme hérite de votre classe de fenêtre générique. Demandez-leur d'encapsuler la boucle d'événements et de remettre des pointeurs de fonction à leur classe de formulaire. Alors dites bon travail, Microsoft l'a déjà fait pour vous, son appelé System.Windows.Forms. S'amuser.

S'ils doivent être des développeurs Web, demandez-leur d'écrire quelques programmes CGI afin qu'ils comprennent le POST, le GET, etc., puis de créer un script pour la page. Cela rend ASP.NET et PHP beaucoup plus logique.

S'ils travaillent sur quelque chose de niveau inférieur sur un réseau, faites-leur écrire quelques applications à l'aide de sockets avant de les présenter aux bibliothèques qui l'ont déjà fait.

J'ai trouvé que cela améliore la productivité à long terme car cela leur donne les outils et les intuitions correctes pour résoudre leurs propres problèmes.

Les universités sont censées faire cela, mais ce n'est pas le cas, nous le devons.

Cela dit, je conviens qu'il devient de plus en plus difficile de trouver des programmeurs qui valent vraiment la peine de sortir de l'université, principalement parce qu'ils n'ont pas été éliminés en étant obligés d'écrire des algorithmes récursifs et des listes chaînées. De plus, ils n'ont généralement suivi que des cours Java ou .NET et ne comprennent donc rien à la façon dont ils fonctionnent. Pourtant, l'abstraction est très utile lorsqu'elle est correctement utilisée.

(..) tôt ou tard, ce que nous appelons la programmation

Je suis en désaccord avec ce point.
Sans savoir ce qu'est la conscience, le travail de programmeur est sûr.

Voici à quoi ressemblent actuellement les "machines à penser" :

-Arrêtez de changer de sujet!
-Je pensais que notre amour était spécial.
-Arrêtez de changer de sujet!
-Je ne change pas de sujet.
-Tu es! J'essaie de parler de votre incapacité à comprendre de quoi nous parlons.
-Pas ce n'est même pas proche. ma chanson préférée des beatles est à travers l'univers. Qu'est-ce qui est à toi?

Je crois que seuls les programmeurs qui n'obtiennent pas ce point sont un peu condamnés.

Par exemple, la réponse du déshumaniseur :

Ils ne peuvent pas répondre à cela - quelles sont les différences dans les algorithmes de Boyer-Moore et Knuth-Morris-Pratt.

Et avec "ce point", je veux dire - c'est mal d'essayer de dépasser l'ordinateur à ce qu'ils sont les meilleurs - des algorithmes. Au lieu de cela, le programmeur est censé aider l'ordinateur avec le contexte, racontant les problèmes que nous essayons de résoudre.

Les outils eux-mêmes ne résolvent pas les problèmes, ils rendent simplement (parfois) les programmeurs plus efficaces.

C'est comme avec: "les armes à feu ne tuent pas, les humains le font".

Absolument pas. D'après mon expérience, l'utilisation des bons outils de développement permet un développement rapide des applications sans sacrifier la qualité. En fait, je dirais que, pour la plupart, la qualité a augmenté en raison de notre «dépendance excessive aux outils». De plus, les outils de développement peuvent réduire la courbe d'apprentissage et initier davantage de personnes à la programmation. Bien sûr, cela a un inconvénient, car il y a beaucoup plus de programmeurs novices, mais dans l'ensemble, cela facilite le processus créatif et fait avancer la technologie.

Une dépendance excessive à l'égard des outils implique-t-elle que vous êtes paresseux?

De manière générale, «non»; mais il y a une grosse mise en garde.

J'ai commencé à programmer en C ++ à uni et j'ai adoré. Lors du prochain mandat, nous sommes passés au VB6 et je détestais ça.

Je ne pouvais pas dire ce qui se passait, vous faites glisser un bouton vers un formulaire et l'ide écrit le code pour vous.

Oui en effet. Votre expérience à uni correspond à la mise en garde que j'ai mentionnée.

Si vous ne savez pas quel problème votre outil résout, ou si vous êtes incapable de dépanner des choses lorsque votre outil a ses propres problèmes, c'est un énorme drapeau rouge. Cette circonstance n'implique pas nécessairement la paresse, mais elle implique probablement l'inexpérience.

Je pense qu'il y a 2 versions de programmeurs. Il y a des programmeurs qui programment juste pour faire le travail à cause peut-être d'une échéance ou peut-être juste pour être plus productif. Je dirais qu'ils étaient paresseux. Je crois simplement qu'ils n'ont aucun intérêt à "comment" un ordinateur fait ce qu'il fait ou "comment" un programme fait ce qu'il fait.

Ensuite, il y a des programmeurs passionnés, comme moi. Les programmeurs passionnés, comme moi, aiment savoir exactement ce qui se passe dans le CPU. Tout comme un bon psychologue essaie de comprendre ce qui se passe dans la tête humaine, le progchologue, comme moi, veut savoir ce qui se passe à l'intérieur du CPU. Nous apprenons, disséquons et analysons donc un programme et utilisons des outils tels que le réflecteur et les désassembleurs pour essayer de comprendre comment fonctionne un programme.

J'ai un espoir silencieux que les choses vont changer. Les processeurs n'évoluent pas beaucoup verticalement, seulement horizontalement, et ARM, etc. vont être limités en ressources dans un proche avenir.

Il est fort possible que la demande de programmation sans glisser-déposer diminue et nous verrons des emplois plus intéressants.