Quel impact les langages de script ont-ils sur les programmeurs juniors? [fermé]


18

J'ai eu une discussion avec un de mes professeurs l'autre jour.

Nous avons débattu de l'impact que les langages de script plus simples (comme Python ou Ruby) ont sur les programmeurs juniors.

Il a soutenu que les langages de script engendrent des techniques de codage bâclées parce que les débutants ne comprennent pas ce qui se passe "sous le capot". Il a également cité d'autres exemples de la façon dont les langages de script amènent souvent le programmeur à négliger les préoccupations concernant l'efficacité, la gestion de la mémoire, la complexité opérationnelle, etc.

J'ai soutenu que les langages de niveau inférieur pourraient être trop pour certaines personnes et qu'ils pourraient abandonner avant de développer une passion pour la programmation. Quand j'ai commencé à apprendre mon premier langage de programmation (C), je suis arrivé aux pointeurs et j'ai abandonné parce que les concepts étaient trop durs (pour ma défense, je n'avais que 14 ans). Si ce n'était pas pour Java, je ne serais peut-être pas devenu programmeur! Si j'avais commencé avec un langage plus simple, puis creusé profondément, je pense que je n'aurais pas abandonné et j'aurais appris autant que j'ai commencé par C.

La classe s'est terminée avant que chaque côté ne soit complètement exploré.


À ce point, j'ai prêché que les débutants devraient commencer par les langages de script puis creuser profondément; mais après cette discussion, j'ai commencé à me demander si c'était une pensée erronée.

Alors, quel impact les langages de script ont-ils sur les programmeurs juniors?



4
J'ai appris à conduire sur une voiture avec une transmission automatique. Plus tard, j'en ai eu une avec une transmission manuelle. J'ai mis du temps à apprendre, et j'ai eu de la chance de ne pas avoir eu à apprendre l'embrayage et à changer de vitesse avec tout le reste.
David Thornley

2
@Singletoned: True. D'une manière ou d'une autre, je devais penser à xkcd.com/326 ...


4
Personnellement, je pense que ce n'est pas naturel d'apprendre à programmer bas puis haut. Nous apprenons à ramper puis à marcher puis à courir, à parler puis à écrire. Je ne sais pas quelle est la logique du renversement de l'ordre naturel au collège. En général, j'entends juste les gens conclure "parce que si j'ai eu du mal à apprendre, cela doit rester dur pour vous". Même Joel l'a dit. Je suppose que le cycle ne finira jamais.
P.Brian.Mackey

Réponses:


26

Je ne suis pas d'accord. Premièrement, les langages de script sont à un niveau d'abstraction plus élevé, et il n'y a rien de mal à cela. Au début, on essaie simplement d'apprendre les principes. En fait, je dirais que le choix d'une langue de niveau inférieur peut encourager un mauvais codage, car il faut traiter certains détails avant de pouvoir les comprendre. Au lieu de cela, avec un langage plus simple, on peut commencer à écrire du code propre et concis dès le début.

Deuxièmement, il y a beaucoup à apprendre dans ces langues. En ce qui concerne l'apprentissage du langage, je dirais que C est plus facile que Python. Il faut gérer les pointeurs ou s'occuper des chaînes, mais il y a beaucoup plus de concepts à apprendre en Python. Compréhensions, orientation d'objet, réflexion, méthodes magiques, fonctions de première classe, lambdas, itérateurs et générateurs, métaclasses: tout cela fait partie du langage.

Je pense que commencer avec Python permet d'en apprendre beaucoup plus sur la programmation et avec une courbe d'apprentissage plus douce. Une langue de niveau inférieur peut avoir moins d'abstractions - donc moins de concepts généraux à apprendre - et submerger le débutant avec des détails dont il peut vouloir se passer.


1
+1, bien que je ne pense pas que C soit plus facile à apprendre que Python dans tous les sens. Peut-être qu'il y a moins de concepts à apprendre dans l'ensemble, mais vous en apprendrez plus dans le même temps avec Python. Et bien sûr, si le C est trop facile, il y a toujours le C ++, qui vous enseigne la complexité des langages de haut et de bas niveau. ;)
Martin

+1, c'était ma pensée! Je souhaite que j'aurais lu ceci avant la classe :)
joe_coolish

22

Peu importe où vous commencez. Il importe où vous allez après avoir commencé.

BASIC n'est peut-être pas le langage le plus élégant de la planète, mais il englobe les principes fondamentaux de la programmation procédurale, et c'est suffisant pour commencer.

J'ai commencé avec BASIC. Je n'y suis pas resté .


+1 pour la réponse parfaite - montrant de manière concise à quel point la question d'origine est déplacée! (Par pure coïncidence, j'ai aussi commencé avec BASIC ;-)
Péter Török

5
Cela m'étonne combien de personnes y séjournent ..: o /
Gary Willoughby

1
Excellente réponse. Bref, précis et précis. J'ai aussi commencé avec BASIC.
Michael Riley - AKA Gunny

11

Votre professeur a raison, sauf qu'il suppose que ses conséquences sont mauvaises.

Si vous considérez l'apprentissage des langues comme une activité purement académique pour apprendre comment fonctionnent les ordinateurs, alors il a raison. Si vous les considérez comme un moyen de faire avancer les choses, vous avez raison.


6
Je dois être en désaccord avec toi. Les conséquences sont de mauvaises choses, car la conséquence est l'ignorance. Cela signifie que finalement, quelque chose va se casser et que le problème sera à un niveau d'abstraction inférieur à ce que vous comprenez, et donc vous n'aurez aucune idée de comment le résoudre. C'est toujours une mauvaise chose.
Mason Wheeler

6
Je dois être d'accord avec toi. Les conséquences de ne pas savoir ce qui se passe sous le capot est une profonde simplicité et franchise d'expression sans aucun souci de nuance matérielle. Les niveaux d'abstraction inférieurs sont destinés aux concepteurs de langage et non aux développeurs d'applications.
S.Lott

1
@Mason: Absolument. Une fois, j'ai gagné beaucoup d'argent en sauvant les fesses d'une équipe de programmeurs qui n'avaient aucune idée de ce qui se passait vraiment sous le capot et qui ne pouvaient donc pas faire fonctionner leur système de production ou fonctionner de manière fiable. (Une fois parce que ce genre de travail est nul. La vie est trop courte!)
William Pietri

1
@Mason - Je suis d'accord avec ce que vous avez dit, qu'il est important d'avoir ces connaissances si vous voulez programmer professionnellement. J'ai trouvé ma connaissance des pointeurs, des structures discrètes et du calcul lambda extrêmement précieuse. J'ai été coincé dans des équipes où les membres de mon équipe n'avaient pas ces compétences et ils ont fini par créer du code trop compliqué ou très bogué. seulement parce qu'ils ne savaient pas mieux. Il semble que parfois, les collèges nourrissent les étudiants CS trop de lait et pas assez de viande, mais d'un autre côté, s'ils nourrissent la viande des programmeurs débutants, ils courent le risque qu'ils abandonnent.
joe_coolish

1
@Joe: Selon Joel, faire abandonner ceux qui ne peuvent pas le gérer est tout l'intérêt. Et comme non seulement un programmeur informatique mais aussi un utilisateur d' ordinateur , celui qui doit régulièrement travailler avec des programmes horribles que je ne peux que supposer ont été créés par des codeurs incompétents, je souhaite vraiment que le bit "les faire abandonner" ait plus de succès!
Mason Wheeler

5

Je pense que "langage de script" est un mot horrible, qui est extrêmement obsolète ou, au mieux, convient à une classe de langages spécifiques à un domaine. Votre professeur aligne simplement tout ce qu'il ne comprend clairement pas sur un axe du mal.

Une distinction judicieuse à faire est celle entre les langages de haut niveau et les langages de bas niveau, ou entre les langages typés statiquement et dynamiquement, qui sont vraiment orthogonaux.

L'assembleur est typé dynamiquement de bas niveau (si parler de types a du sens), C est typé statiquement de bas niveau, Ruby est typé dynamiquement de haut niveau, Haskell est typé statiquement de haut niveau. Java n'est ni de haut ni de bas niveau typé statiquement, C ++ est à la fois de haut et bas niveau statiquement typé. Etc.

La discussion ne peut être que, quels paradigmes conviennent mieux à un programmeur débutant.
Je suis assez convaincu que la programmation de bas niveau n'en est probablement pas une. C'était peut-être, il y a quelque temps, au début des années 90, où vous pouviez en fait produire des résultats intéressants dans un délai raisonnable.
Mais la programmation est alimentée par la passion. La passion se nourrit de récompenses. Par conséquent, les programmeurs de niveau d'entrée devraient commencer avec des outils enrichissants. Les outils de bas niveau ne sont plus gratifiants, car il existe une vaste mer d'outils de haut niveau qui vous permettent d'obtenir le même résultat en une fraction du temps.

La pensée humaine est abstraite. Lorsque nous apprenons à comprendre le monde, nous le faisons par des abstractions à grain très grossier et nous entrons dans les détails au besoin.
Pour qu'un enfant comprenne son environnement, vous n'allez pas lui enseigner les mathématiques, puis la physique, puis la chimie, puis la biologie, puis l'histoire, la sociologie et la philosophie. Vous lui donnez un modèle du monde très simple à gérer et vous aurez, par lui-même, longtemps à le dépasser, vous posant sans cesse des questions dans votre jeunesse et niant complètement votre autorité plus tard.

Voilà comment nous pensons. Le cerveau humain ne peut traiter que des quantités limitées d '"unités" d'information, mais le degré d'abstraction importe peu dans la quantification de l'information. Par exemple: pour nous, la lecture de l'expression '34 * 75 'est plus simple que son calcul, alors que pour les ordinateurs c'est l'inverse. Reconnaître (et ainsi abstraire) un groupe de pixels noirs en une ligne ondulée, qui peut ensuite être reconnu (et ainsi encore une fois abstrait) pour être un chiffre individuel est une énorme quantité de travail.
Ma grand-mère comprend l'idée d'ouvrir un dossier. Cependant, elle n'a aucune compréhension en dessous de ce niveau. Et franchement, si elle avait dû apprendre cela en étudiant d'abord le fonctionnement interne du matériel et du système d'exploitation et quoi d'autre, elle n'y serait jamais arrivée.

Il y a beaucoup de gens là-bas, qui compliquent les choses, car on ne leur a jamais appris à penser en termes de solutions claires, concises et donc élégantes, mais ils ont passé trop de temps à se soucier des détails de bas niveau échangeables et à résoudre des problèmes contre ceux-ci. Apprendre aux gens à penser comme des ordinateurs est la pire approche possible de la programmation.
La valeur de la programmation réside dans la recherche d'une solution à un problème. L'exprimer sous forme de code est vraiment plus une tâche mécanique ennuyeuse et devrait simplement être fait avec les outils qui conviennent.

Oh, et ne vous inquiétez pas de ne pas avoir compris les pointeurs. J'ai eu à peu près le même problème au même âge. Le problème ici est également le manque d'abstraction. En règle générale, vous vous familiarisez avec les pointeurs d'un livre C et pendant que vous avez du mal à les comprendre, cela va de pair avec l'allocation de mémoire et donc avec la mémoire de pile et de tas, etc. Le concept abstrait derrière les pointeurs est l'indirection. Une variable qui contient un index dans un tableau spécifique est juste cela (en fait, c'est vraiment la même chose en C, où le tableau spécifique est votre espace d'adressage), et vous n'avez pas besoin d'arithmétique de pointeur pour cela.
Ceci est juste destiné à illustrer que le choix d'un niveau élevé d'abstractions rend les choses beaucoup plus faciles à saisir.

EDIT: et quand il s'agit de taper, je préfère les langues typées statiquement. Et je pense que les programmeurs de niveau d'entrée devraient comprendre clairement le concept de types (qui est abstrait).


3

Il n'y a rien de simple à propos de Python. Jetez un œil à Unicode et à la méta-programmation.


Je suis d'accord que Python peut être très complexe et TRÈS puissant. Mais les bases (manipulation de chaînes, manipulation de tableaux, etc.) sont beaucoup plus faciles en Python qu'en C.
joe_coolish

1
Python est très simple au départ et de nombreuses tâches quotidiennes sont d'un ordre de grandeur plus simples que par exemple dans les langages systèmes. Non, la langue dans son ensemble, ses détails sanglants et les fonctionnalités avancées ne sont pas simples (cela vaut pour tous les langages non-jouets). Mais ce n'était pas la question.

1
Alors pourquoi mon if searchstring.lower () dans filecontent.lower (): ne fonctionnait pas? en raison de la nomenclature dans le fichier sql UTF-16LE dans tfs sur Windows avec Python2.7. Ce n'était pas amusant. l'a fait fonctionner. a pris quelques heures. string.find () ne fonctionnait pas non plus ... Argghhh!
Christopher Mahan

1
Comment Unicode est-il plus simple à gérer en C?
dan04

3

Je vois un autre problème beaucoup plus profond.

Les langues unityped ne forcent pas à prêter attention aux types, à penser en types. C'est bien beau tant que j'ai de petits scripts avec des chaînes et des nombres qui sont convertis les uns aux autres sans s'en rendre compte. Mais le jour viendra où cela se cassera. Du coup, le programme va s'arrêter, et chaque solution rapide le fera recommencer.

Ou bien, le programmeur novice en herbe découvre qu'il aura besoin d'une liste de listes au lieu d'une liste de tuples, mais n'aura pas la moindre idée de "comment faire", et il posera des questions sur stackoverflow qui montrent que c'est une impuissance absolue.


6
Mais Python et Ruby sont fortement typés. Ceci est orthogonal à un typage dynamique. Les chaînes et les nombres ne se convertissent pas implicitement.
dsimcha

3
@dsimcha: Oui - Et comment cela réfute-t-il ce que @Ingo a dit?
Jim G.20

1
Parce que cette question concerne principalement Ruby et Python. Je pensais qu'il laissait entendre qu'il pensait que Ruby et Python étaient faiblement typés, ce qui est un malentendu courant.
dsimcha

1
@ davidk01 - c'est mon point: les valeurs ont des types que nous le voulions ou non. Mais dans les langues typées dynamiquement (si ce terme vous plaît davantage), les variables ne le sont pas. Au lieu de cela, la vérification du type est effectuée au moment de l'exécution pour distinguer les nombreuses variantes de l'Unitype.
Ingo

2
@Ingo: J'avais au moins l'habitude de trouver des utilisateurs Common Lisp qui pensaient que le manque de frappe statique était un avantage (en fait, une frappe statique facultative, utilisable soit pour la vérification des erreurs soit à des fins de performance), en ce sens qu'elle accélérait le développement et que les erreurs que le typage statique aurait évitées ne se sont pas avérées difficiles à trouver et à corriger dans la pratique. Je n'ai rien vu de plus que l'opinion dans un sens ou dans l'autre.
David Thornley

2

Je maintiens toujours que l'enseignement formel et le mentorat sont un facteur beaucoup plus important que le choix de la langue dans la qualité du code débutant. Cependant, si je devais choisir une première langue pour les débutants, je choisirais python pour les programmeurs autodidactes et C ++ pour l'enseignement collégial.

La raison en est qu'avec une instruction formelle, vous pouvez commencer avec de petits programmes triviaux pour jeter des bases théoriques solides des années avant de devoir faire quoi que ce soit d'utile. Je pense que cet ordre est idéal si vous pouvez vous permettre le temps, et C ++ vous aide beaucoup avec les erreurs du compilateur et les erreurs de segmentation entre les conférences pour vous faire savoir si vous ne saisissez pas les fondamentaux.

Certains de ces principes fondamentaux sont tout simplement très difficiles à apprendre si vous êtes autodidacte, jusqu'à ce que vous ayez de l'expérience à votre actif. En outre, vous devez généralement créer quelque chose d'utile dès que possible et gagner les bases théoriques nécessaires, bien que vous risquiez de ne jamais en apprendre plus que le strict minimum avec cette approche. C'est pourquoi je recommande un langage comme python dans ce cas.


2

Nous l'avons vu dans l'autre sens au collège et je pense que c'est utile. * Nous avons commencé sur la basse levée. Pointeurs, gestion de la mémoire, tableaux de caractères ... Alors oui, nous avons commencé avec C. La même chose avec les algorithmes: implémentez d'abord une liste chaînée, une table de hachage, un arbre ... Et ensuite seulement utilisez les bibliothèques standard.

Après cela, nous sommes passés à des langages plus puissants tels que Java, C # ou perl. Mais avec l'avantage de savoir ce qui se passe sous la ceinture.

Bien que cela fonctionne, je pense que passer des langages de script à un langage de niveau inférieur est également très bien. Connaître à la fois une langue de haut et de bas niveau vous garantit la facilité d'utilisation d'une langue de haut niveau tout en comprenant ce qui se passe. L'ordre dans lequel vous les apprenez est moins important.


1

Les langages de script ne rendent pas les programmeurs bâclés. Le manque de clarté dans la compréhension du domaine problématique (par exemple, l'entreprise desservie par le programme) est à l'origine de la négligence.

Comme le dit le vieil adage: "Vous pouvez écrire COBOL dans n'importe quelle langue.", Bien que je soupçonne que lorsque chaque type de données se ressemble , il devient alors plus difficile de voir quels sont les aspects essentiels de votre programme, une caractéristique majeure de COBOL- ization.


1
Essayez-le avant de soupçonner. La principale différence est que vous ne donnez pas un putain de où il est un Fooou Barou quelque chose de complètement différent , aussi longtemps que vous le pouvez .frobnicate()ou l' autre manière. Sans interfaces explicites.

Je connais assez bien les langages dynamiques, car mon travail de jour est avec Ruby on Rails. Et oui, c'est une convention majeure au sein de la communauté linguistique dynamique. En général, cela s'appelle le «typage du canard». Dans la littérature de recherche, ils sont appelés types structurels, et il existe des conventions de syntaxe qui peuvent vous montrer à quoi ressemble un «type charlatan». Non seulement cela, il existe des systèmes de types qui peuvent les reconnaître et vérifier que votre programme traite les canards avec gentillesse.
Farley Knight

Je connais les types de structures et je les considère comme une idée assez intéressante. Mais comme il n'y a pas un seul langage mature et largement utilisé à distance (une base d'utilisateurs de niveau O'Caml serait un bon début) qui les utilise, je ne les considère pas comme une alternative pratique au typage dynamique. Triste, mais fait.

Les langages largement utilisés ne le font pas, mais cela ne vous empêche pas d'amorcer votre propre système de type sur un système largement utilisé. Je suis sûr que vous avez vu des articles sur des choses comme l'inférence de type pour les langages dynamiques.
Farley Knight

Encore une fois, je ne considère pas quelque chose utilisé par moi et le gars d'à côté comme une alternative pratique . Un programmeur a besoin de choses comme des bibliothèques, une syntaxe stable, des outils, etc.

1

Je dirais que les langages de script n'encouragent les techniques bâclée. (Notez que cela ne veut pas dire que les langues sont mauvaises , juste qu'il est difficile de maintenir de grandes bases de code dans ces langues) Cependant, je pense que pour des raisons différentes des autres réponses ici.

Je pense que pour utiliser n'importe quel langage, un programmeur doit avoir une compréhension de base de la programmation dans son ensemble. Ils ne seront efficaces nulle part s'ils ne comprennent pas des concepts tels que les vecteurs, les arbres et les tables de hachage. Ils n'ont pas nécessairement besoin de pouvoir mettre en œuvre ces choses, mais ils doivent connaître leurs caractéristiques.

Là où je pense que la négligence entre en jeu, ce n'est pas la compétence en programmation, mais quand il faut créer des composants réutilisables. Ces langages ne nécessitent pas de définir de bonnes interfaces entre les unités de code ou les mécanismes pour que les bibliothèques appliquent des contraintes sur leurs clients. Il n'est pas impossible de fabriquer de bons composants réutilisables dans de tels langages, c'est juste beaucoup plus difficile.

Les langages de script ont un attrait pour le programmeur débutant car il leur permet de faire plus de choses "ponctuelles" en moins de temps, mais lorsque ces mêmes programmeurs commencent à faire de la programmation de maintenance, ils ont souvent rapidement des problèmes avec ces langages.

Je ne dis pas que les langages de script sont mauvais - loin de là. Mais ils rendent difficile la maintenance d'énormes bases de code (plusieurs millions de lignes) (ce qui est l'une des raisons pour lesquelles vous ne voyez pas de telles bases de code dans les langages de script). Lorsque vous avez besoin de solutions relativement petites ou ponctuelles, elles vous permettent d'accomplir bien plus en moins de temps et moins de code (et moins de code est presque toujours meilleur).

N'oubliez pas qu'aucun outil n'est le mieux adapté à chaque tâche. Choisissez l'outil le plus approprié à la situation. Cela vaut pour les langages de programmation comme pour tout outil.


0

Je suis avec votre professeur, mais aussi avec @Singletoned quand il dit que votre professeur suppose que les conséquences (par exemple, aucune connaissance des performances) sont mauvaises.

Je pense qu'il est préférable de commencer par C que de commencer par les langages de script. En tant que professeur, je me concentrerais sur toute cette architecture de von Neumann (ALU, registres, mémoire, ports d' E / S, ...), je passerais directement aux pointeurs (je suis désolé, c'est vraiment un concept clé [ne pas publier les références (c.-à-d. les pointeurs) dans les langages VM sont une source principale de fuites de mémoire]), frappent certaines structures de données (arborescence, liste chaînée, table de hachage 1 ), puis ... augmentez le niveau d'abstraction dans autre chose (OO, programmation fonctionnelle, quelque chose - des règles de frappe statiques solides , yo \ m /, donc pas de "langages de script"> :().

1 Hmm, je suis peut-être d'accord avec votre professeur sur les considérations de performance, après tout.


La programmation bâclée est une source de fuites de mémoire et il ne faut pas grand-chose pour apprendre aux gens à garder une trace des ressources comme les descripteurs de fichiers. Il existe d'innombrables programmes C avec des fuites de mémoire, donc je ne suis pas sûr de savoir ce que vous voulez dire en enseignant aux gens les pointeurs dès que possible.
davidk01

C'est vrai, mais ... (a) ne pas comprendre les bases conduit à un mauvais code (via une programmation hacking-til-it-right ou bâclée), et (b) j'essayais de motiver pourquoi les pointeurs sont toujours pertinents, non affirmant que C est meilleur que les langages récupérés en termes de fuites de mémoire. L'objectif d'obtenir des pointeurs dès que possible est que nous puissions ensuite obtenir le diable de C.
JohnL4

0

Je pense que le mieux est de commencer avec un langage modulaire et de passer ensuite à des choses plus compliquées, à l'époque, nous avons commencé avec Pascal et COBOL et essayé de comprendre ce que signifient les sous-programmes, les variables de flux de contrôle, etc. Ce n'est qu'après avoir été à l'aise avec Pascal que j'ai même eu envie de passer à des langages comme C / C ++ et d'apprendre toutes les autres techniques qui sont plus un ajout au programmeur junior.


0

Vous avez raison tous les deux.

Les langages de script font en sorte qu'il est plus difficile pour les développeurs novices de comprendre ce qui se passe réellement. (Il en va de même des bases de données, des cadres et des bibliothèques. Oh, ainsi que des navigateurs, des serveurs, des réseaux et des systèmes de fichiers.) Lorsque j'interroge des développeurs plus jeunes, je suis souvent stupéfait du peu de connaissances dont ils disposent sur le fonctionnement réel des ordinateurs et de leur propension à charger. -une programmation cultivée.

D'un autre côté, la première chose que je recherche dans les interviews n'est pas une parfaite compréhension, c'est qu'ils aiment faire des choses. À mes débuts, un ordinateur faisant n'importe quoi était assez impressionnant, donc mes petites choses sur l'assembleur Apple Basic et 6502 me semblaient vraiment géniales. Mais de nos jours, les ordinateurs font beaucoup de choses incroyables, donc je pense que c'est bien pour les gens de commencer à un niveau assez élevé si c'est ce qu'il leur faut pour devenir accro.

Fondamentalement, je pense que c'est ok pour commencer dans la partie peu profonde de la piscine aussi longtemps que vous finissez par vous lancer dans des eaux plus profondes.


0

Tout d'abord, je commencerais par un langage de niveau d'abstraction supérieur. Actuellement, je recommanderais Python. La raison la plus importante pour choisir un langage de script comme première langue est que vous pouvez facilement assembler quelque chose qui fonctionne. Comme Joe le mentionne dans sa question, la première chose en devenant programmeur est que vous avez la motivation pour aller plus loin. Cette motivation est acquise lorsque vous êtes en mesure de créer un logiciel fonctionnel et utile.

Outre les points concernant la compréhension de l'abstraction (haut niveau) et la compréhension de la mise en œuvre sous-jacente (bas niveau), un troisième point est omis. Pour être un bon programmeur de nos jours, vous devez certainement maîtriser les deux points ci-dessus. De plus, il est essentiel pour votre compétence que vous examiniez constamment les nouvelles technologies et les points de vue. Peu importe à partir de quel niveau d'abstraction vous commencez, vous devez constamment vous améliorer et remettre en question vos méthodes actuelles.

Il convient de préciser dès le départ que les langages de programmation ne sont que des outils pour faire le travail. Il est très important de choisir l'outil approprié pour une tâche particulière. Je pense que pour un programmeur débutant, un langage de script de haut niveau aidera à souligner ce point. Un langage de niveau supérieur donnera une perspective plus large et motivera le programmeur à approfondir.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.