Le paradoxe du programmeur
|
05-09-2014, 13h52
Message : #5
|
|
Kiwazaru
Padawan d'un super escargot Messages : 284 Sujets : 26 Points: 139 Inscription : Mar 2012 |
RE: Le paradoxe du programmeur
Là en fait, je pense qu'il faut différencier une chose: Un programmeur n'est pas un hacker ni un bidouilleur ou quoi que ce soit d'autre. J’emploie le terme programmeur dans le sens de la profession, c'est-à -dire que son but n'est pas de comprendre (il est censé l'avoir un peu fait avant ça), mais de confectionner ce que lui demande son client le plus rapidement possible et avec une fiabilité maximum (ce qui est l'utilité double d'une librairies).
Et là , on fait une différence majeure, entre celui qui fait ça dans le cadre de son travail, et celui qui fait ça dans un cadre personnel. Et c'est de ces personnes, qui font cela dans un cadre personnel, qu'il vaut mieux parler. Ces personnes peuvent se nommer avec n'importe quel statut, hacker, bidouilleur, passionné, n'importe quoi, la seule chose qui les définis c'est ce qu'ils savent, ce qu'ils sont capable de donner et la manière dont ils le font. Un hacker, comme tu le dis si bien, est une personne censée être en recherche constante du fonctionnement d'un certains système, d'un certains concept, afin d'en déceler les problèmes, ou de détourner son usage; Or aujourd'hui, les librairies et les logiciels qui font tout à notre place se sont démocratisés, et c'est dans ce cas précis, qu'un gros problème intervient. Prenons un exemple simple: Un "hacker" qui utilise metasploit pour pénétrer un système est-il un hacker, ou un simple utilisateur ? Je pense que là , la réponse est simple et honnête, il est utilisateur. Mais il ne faut pas voir que jusqu'au bout de son nez, ce "hacker" a peut-être très bien compris le concept de l'exploit qu'il utilise, et c'est ça qu'on demande n'est-ce pas? Alors d'un côté, ces programmes et librairies sont utiles, de l'autre elle ruinent l'expérience que certaines personnes pourraient avoir à termes si ces choses n'existaient pas, mais en réalité, c'est ce que tu en fait toi qui est important. Mon avis est clair aujourd'hui, une personne qui ne fait qu'utiliser sans comprendre est un utilisateur, contrairement à celle qui utilise, en fouinant et en essayant de comprendre. Et en effet, on peut remarque qu'aujourd'hui beaucoup de personnes se prétendant "hacker" ne font qu'utiliser des programmes pour découvrir des ports exploitables, des scanners pour détecter différentes failles sur un site web, les légendaires "tools de script kiddies" nommés les RAT, ou encore les Stealers; Et tout ça sans réellement comprendre comment au final, ils ont eu un accès au PC de la victime, ou comment ils ont réussi à mettre leur deface trop d4rk sur le site attaqué. Je prends l'exemple des programmes car je le trouve très représentatif en vérité; Aujourd'hui le problème n'est pas le fait qu'il existe des librairies nous facilitant la tâche, c'est utile, ça permet de développer et de créer de nouvelles idées à une vitesse incroyable, c'est beau et c'est bien. Non, cela n'est pas le problème, le problème réel est celui de la démocratisation des apprentissages par la voie de la facilité. Il suffit de regarder l'évolution des études, nous n'utilisons plus que des librairies par-ci, par-là sans même expliquer aux élèves pourquoi on l'utilise, et encore moins comment fonctionnent les fonctions qui sont utilisées, on nous formate juste à pondre un code fonctionnel pour le monde en entreprise. Je pense qu'un apprentissage en profondeur, en expliquant la source serait un bon choix. Alors certains diront perte de temps, moi je dirais gain de temps, et cela pour une simple et bonne raison: La compréhension claire, et précise d'un concept de bas niveau de base, permet la compréhension instinctive de son utilisation dans tous les autres concepts de plus haut niveau par la suite. En clair, et pour faire un exemple simple, quand j'étais au collège, j'ai commencé l'apprentissage du langage VB.net, c'était simple, efficace et on pouvait même faire une fenêtre, c'est vraiment cool; Mais en réalité, je me suis vite rendu compte qu'il fallait apprendre par coeur son texte, pour que le compilateur nous donne une bonne note à la fin. Alors j'ai commencé à ingurgiter des samples de code, encore et encore, et je n'ai finalement pas réussi à tenir. Après avoir appris une dizaine de nouvelle fonction, j'avais déjà oublié comment fonctionnaient les autres, la place de l'argument, qu'est-ce qu'il fallait définir avant etc... Alors une idée simple m'est venue à l'esprit: Et si j'apprenais toute les bases de l'ordinateur? En allant chercher au plus profond du fonctionnement, finalement je finirais pas comprendre comment un concept fait fonctionner une petite partie de ces foutues fonctions qui me paraissaient toute si différentes; Et là intervient le langage Assembleur, un langage où il n'y a que quelques centaines d'opcodes qui permettent à des milliers de milliers de fonctions d'exister. De là , le choix était simple, comprendre la bases des bases, ça permet finalement de comprendre ce que tout le monde s'acharne à retenir. Savoir coder c'est bien, connaître plein de fonction c'est bien, mais les faire devenir instinctives c'est mieux, et c'est là que l'avancée de l'informatique se trompe sur toute la ligne, ce n'est pas sur son évolution même, mais sur l'apprentissage par tout les sites, tutoriels whateveruwant qui ne font que rabâcher comment utiliser un set de fonctions afin d'arriver à faire fonctionner un programme, sans même comprendre pourquoi le programme nous pond ce résultat. Et je pense qu'à terme, nous serons tellement inondé de fonction par-ci, par-là qui se cumulent pour faire ci et ça que nous ralentirons la croissance de l'informatique et l'efficacité des futurs programmeurs. Alors essayons de transmettre le plus possible notre passion et nos convictions qui sont celle d'un génération de personnes qui veulent perpétuer le bon apprentissage pour le bien du futur de l'informatique, mais ne crachons pas sur les librairies et sur tous les concepts qui nous permettent entre autre, de pouvoir partager celui-ci plus aisément.
Toucher au Kernel, c'est un peut comme se shooter au LSD, on pense pouvoir tout faire mais ça finit souvent mal.
|
|
Messages dans ce sujet |
Le paradoxe du programmeur - par Commodor - 04-09-2014, 14h47
RE: Le paradoxe du programmeur - par b0fh - 04-09-2014, 17h21
RE: Le paradoxe du programmeur - par Mika - 05-09-2014, 01h05
RE: Le paradoxe du programmeur - par Booster2ooo - 05-09-2014, 13h31
RE: Le paradoxe du programmeur - par Kiwazaru - 05-09-2014, 13h52
RE: Le paradoxe du programmeur - par gruik - 05-09-2014, 16h41
RE: Le paradoxe du programmeur - par formollover - 05-09-2014, 20h37
|
Utilisateur(s) parcourant ce sujet : 1 visiteur(s)