Je me pose la grave question suivante : quel est le/les langages à utiliser/conseiller pour apprendre à programmer ?
Il y a de nombreuses approches :
- certains diront qu'il faut un langage proche des mathématiques, pour insister sur l'aspect logique plutôt que l'aspect "technique" de la programmation, pour que ce soit presque "transparent" pour le débutant ; c'est l'esprit des cours que j'ai suivi à l'Insa de Rennes avec le Scheme, et ça avait le don d'énerver quasiment tous ceux qui apprenaient à programmer de cette manière :/
- certains privilégient le Pascal ou ses descendants pour son aspect didactique, simple et clair (et il me semble que Pascal a été écrit dans l'optique d'être un langage d'initiation ?)
- certains parlent aussi du Basic (surtout dans le monde Windows je suppose) malgré sa mauvaise réputation, pour son aspect simple et "facile"
- certains parlent même du C (ça me semble à moi bien trop compliqué), ou du Java ou du Python (l'objet est-elle une notion abstraite qui complique la tâche d'apprentissage et l'alourdit comme il se dit beaucoup, ou au contraire permet d'appréhender les données manipulées d'un point de vue plus proche du monde réel ce qui semble logique ?)
- est-ce un handicap d'apprendre à programmer avec un langage donné, lorsque le but ultime est de programmer avec un autre langage (j'aurais tendance à penser que connaître plusieurs langages est plutôt un atout qu'un handicap) ?
- est-ce un handicap d'apprendre à programmer avec des langages qui ne sont pas faits théoriquement pour faire des programmes (Bash, Php, voire Perl), ou au contraire leur facilité d'accès lisse-t-elle les premières difficultés ?
J'aimerais votre avis, et surtout si vous avez déjà conseillé et/ou supervisé l'apprentissage de la programmation d'une connaissance, quel a été le retour de cette expérience ?
Forum Programmation.autre Pour apprendre à programmer
12
juil.
2004
# Je vote pour ADA
Posté par bastien (site web personnel) . Évalué à 4.
C'est un langage assez strict et proche de l'algorithmique, et meme si il peut etre lourd a programmer a la longue pour certain (declaration obligatoire etc...) il te fera prendre de bonnes habitudes, et quand tu passeras a un autre langage tu auras moins de mal, et tu programmeras plus proprement que si tu commence par php par exemple. Il est en plus moins découragent que le c, et il existe des binding (pour gtk, pe pour qt) pour utiliser tes outils favoris :)
# il faut s'adapter
Posté par TImaniac (site web personnel) . Évalué à 2.
Donc, programmation :
Fonctionnelle : un langage basé sur le ML comme OCaml par exemple
Logique : Prolog (mais celà reste du domaine de la fac ;) )
Impérative : Pascal pour débuter peut être un bon choix (parcque conçu pour les débutants)
orienté objet : Java (parcque contient des concepts répendus et simple à utiliser)
parallèle : CSP ou ADA (mais commence pas par là ;) )
système (pas vraiment une méthode) : C (mais là encore, peut être pas pour débuter)
déclarative : XML
Tu auras compris que le but n'est pas d'apprendre un langage par coeur mais d'en comprendre les principes et surtout les atouts. N'essai pas de reproduire un algo à l'identique d'une méthode à l'autre mais au contraire essai d'appliquer les spécificités de la méthode pour cerner les avantages et inconvénients.
[^] # Re: il faut s'adapter
Posté par bastien (site web personnel) . Évalué à 2.
C'est etrange. A l'iut depuis cette année ils commencent par ADA, ils n'utilisent pas les fonctions paralleles, et de ce que j'ai vu il a l'air assez simple, clair et proche de l'algorithmique. Je lui trouve les meme avantage qu'a Pascal
D'ailleur, c'est quoi la programmation parallele :) ???
# tu ne dis pas ...
Posté par kesako . Évalué à 3.
Pour un mome ? un ado ? un etudiant ? quelqu'un d'age mur ?
"apprendre a programmer" ca ne veut rien dire. On programme aussi son magnetoscope !
Il faut preciser quoi : faire de la vraie programation ? En faire son metier ? ou faire juste un petit truc pour se faciliter la vie ? pour le plaisir ?
[^] # Re: tu ne dis pas ...
Posté par gc (site web personnel) . Évalué à 2.
Au sujet du magnétoscope, je ne cerne pas bien où tu veux en venir. Si je reformule "apprendre à développer des applications" ça peut aider ? C'est une question générique pour l'apprentissage de la programmation en général, "d'un ou plusieurs des langages de programmation informatiques les plus répandus actuellement mais surtout des principes de la programmation" si tu veux :).
[^] # Re: tu ne dis pas ...
Posté par Victor . Évalué à 2.
Oui ! Tout le monde sait qu'il est plus simple d'apprendre une langue (a ecrire je sais pas mais je suppose) quand on est enfant que lorsqu'on est adulte.
Et donc par consequent les methodes d'apprentissage sont quand meme assez differentes.
A mon avis la meme chose s'applique a la programmation.
Et pas seulement d'un point de vue biologique (je parle bien sur de la maelabilité (bizzare ce mot) du cerveau) mais aussi d'un point de vue sociale, un ado a plus de temps qu'un adulte qui travaillerait par exemple.
[^] # Re: tu ne dis pas ...
Posté par totof2000 . Évalué à 1.
Voir http://www.framasoft.net/article1971.html,(...) ça te donnera peut-être une piste.
[^] # Re: tu ne dis pas ...
Posté par LeXav . Évalué à 1.
Certes, le sujet est vaste ; mais n'y a-t-il pas un point commun entre programmer son magnetoscope et programmer un tracer de rayons en C par exemple ?
Dans les deux cas, tu indiques à la cible les actions que tu veux accomplir, dans un ordre donné.
Ne pourrait-on pas voir le langage de programmation d'un magnétoscope comme un langage de très haut niveau ?
Bien sûr, ce n'est pas vraiment reconnu pour trouver du boulot, mais c'est un début. Combien de personnes savent programmer leur magnétoscope ?
[^] # Re: tu ne dis pas ...
Posté par kesako . Évalué à 2.
Ce pourrait justement etre un bon point de depart pour reflechir a la methode a utiliser :
Donner un magnetoscope à quelqu'un avec le manuel et regarder comment il s'y prend pour arriver à le programmer . Et en fonction du resultat choisir le langage de programation avec lequel il a le plus de chance de bien se debrouiller. Du moins au debut. Un language qui correspond a ca representation intelectuelle des problemes.
:-)
# Je raconte un peu ma vie, là ! :o)
Posté par Beurt . Évalué à 2.
Puis j'ai vraiment voulu faire des trucs sur ordinateur, et je me suis naturellement tourné vers le basic. J'ai trouvé ça très simple, mais à l'époque (Atari ST) mes programmes étaient trop lents. C'est pourquoi j'en suis arrivé à l'assembleur ! (vers 90)
Avec le recul, je trouve ça dingue d'avoir essayé de programmer des trucs compliqués en assembleur pendant plusieurs années. Ma dernière folie a même été un utilitaire système en assembleur. Récemment j'ai retrouvé le source imprimé (environ 30 pages !), c'est incompréhensible (et pourtant j'ai commenté ).
J'ai arrêté de programmer, car à l'époque je n'ai pas su passer de l'assembleur MC680x0 à quelque chose de plus raisonnable et multi-plateforme comme le C ou même le pascal.
Cela faisait bien 8 à 10 ans que je n'avais pas écrit la moindre ligne d'un programme, quand je me suis retrouvé confronté au php alors que je voulais faire un site web. Si j'ai pu, un peu (très peu ), bidouiller du php pour arriver à peu près à mes fins avec daCode, je ne prétend pas être capable de faire quoi que ce soit avec php.
Pour résumer, je suis aujourd'hui incapable d'écrire un programme. Pourtant j'en ai besoin et récemment je me suis posé la même question que toi. Comment remettre le pied à cet étrier ?
J'ai acheté le hors série de Linux Mag sur le Perl. J'ai l'impression d'avoir compris le principal. Mais je n'ai pas encore eu le temps de passer à l'application.
Toutefois, je constate que la programmation, c'est pas comme le vélo, ça s'oublie aussitôt qu'on arrête. Et puis surtout, les techniques de programmation (l'objet, par exemple, je n'arrive même pas à comprendre ce que c'est, et son intérêt) évoluent tellement vite qu'on perd facilement pied. Sans parler de la diversité des langages.
Je ne répond pas vraiment à ta question, mais j'espère que cet exemple t'aidera à y répondre (et puis, moi ça me coûte moins cher en psy ! :o))
En tout les cas, si tu trouve une très bonne méthode, je suis preneur.
[^] # Re: Je raconte un peu ma vie, là ! :o)
Posté par gc (site web personnel) . Évalué à 2.
Bien qu'amateur moi-même de Perl, il ne me semble pas très adapté à l'apprentissage, à cause du nombre de ses spécificités sous-entendues, sa syntaxe courte et par la même un peu difficile d'approche.
Je n'ai pas de méthode clé en mains à te proposer, d'où ce forum justement, mais si les post que l'on peut lire ici t'aident un peu ce serait déjà pas mal (cependant il ne faut pas rêver, les langages c'est tellement quelque chose de "personnel" que l'on aura tous tendance à défendre le langage que l'on connaît le mieux et que l'on apprécie, plutôt qu'autre chose ;p).
Quant aux techniques de programmation, je ne sais pas si elles évoluent aussi vite que ça... En parlant de l'objet par exemple, il semble qu'on puisse le dater de 1967[1], même si c'est vrai que le hype de l'objet date de l'utilisation de masse de C++ et de Java (il me semble). Je ne pense pas que ça évolue vraiment vite en fait, c'est peut-être plus l'évolution des capacités matérielles des ordinateurs qui ont permis l'utilisation bien plus massive des langages interprétés, des langages à gestion automatique de la mémoire et des langages à objets.
Sinon, c'est amusant : au lycée vers 1993, passionné de langages et utilisateur de Pascal et d'assembleur, j'avais discuté avec le directeur du centre de ressources informatiques de l'université qui m'avait chaudement recommandé C++ ; j'avais acheté le bouquin de Stanley Lippmann (le Stroustrup m'ayant été déconseillé à cause d'une grande complexité) et j'avais eu la même réaction que toi face aux objets : "ça sert à rien ce truc", pour moi c'était juste un hype pour dire "attribut" plutot que variable et "méthode" plutôt que fonction. Pour moi, j'ai découvert l'intérêt de l'objet en programmant en objet, pas vraiment en "apprenant" et lisant dessus... peut-être sera-ce pareil pour toi ? Mais sur le fond je te recommande fortement de persévérer : les objets c'est fantastique.
[1] http://merd.sourceforge.net/pixel/language-study/concepts-history.h(...)
# Eiffel, Smalltalk, Ruby, OCaml
Posté par Damien (site web personnel) . Évalué à 2.
j'ai moi aussi eu droit au scheme à l'insa, en tant qu'élève puis vacataire :)
Scheme est bien pour commencer parce qu'il a une syntaxe ultra simple. À mon avis c'est aussi son inconvénient parce que tout se ressemble, on ne sait pas qu'est-ce qui fait partie du langage ou pas. C'est aussi dommage de rester bloqué à faire des programmes dans le toplevel, sans voir clairement comment on peut faire des vrais programmes qui marchent comme les autres applis du système.
Pascal pourquoi pas mais autant prendre un langage plus récent et utilisé...
Basic... à part le hype sur la simplicité je vois vraiment pas l'intérêt, surtout si c'est pour utiliser VB qui a tellement évolué que c'est plus du basic.
Le C c'est très bien pour des choses un peu bas niveau, en cours d'archi ou de système par exemple, pour débuter y'a mieux je pense.
Java comme remplaçant de pascal, pourquoi pas, mais on peut pas passer à côté des classes etc. ce qui est gênant ; avec les casts, les classes Integer, etc c'est autant de trucs superflus pour l'enseignement mais qu'on ne peut pas ignorer. Et pour apprendre l'objet tu peux essayer C++ aussi, ça aura le même résultat.
Bash, Php Perl, n'y pensons même pas : faut avoir à l'esprit qu'un des problèmes typiques au début c'est (if (test a b) then true else false). Va expliquer le problème quand il y a une syntaxe cryptique avec moultes expansions de quotes et de $MACHIN...
Voilà pour mon avis sur les langages que tu cites, mon sujet en cite d'autres :
Eiffel : pareil que Java, on ne peut pas passer à côté des classes, mais le reste est bien mieux fait, bien plus clair. Bien pour des cours de génie logiciel ou pour des projets (contrats roxor).
OCaml : très bien pour l'algorithmique. Perso je le trouve un peu write-only mais le typage bien carré c'est sympa pour apprendre.
Smalltalk : la syntaxe est bizarre mais très simple, l'environnement Squeak est sympa, et surtout il y a un projet appelé eToys qui rend la programmation accessible aux très jeunes, et qui à mon avis ça remplacerait génialement le LOGO au collège. Pour le reste on aussi bosser du génie log, faire des programmes graphiques très simplement. Franchement ça devrait être plus répandu.
Finalement je pense que Ruby est un bon candidat, voire le meilleur, parce qu'il fait un compromis entre pas mal de bonnes choses : la syntaxe est claire, et surtout on peut commencer par des programmes linéaires et introduire la structuration, les objets très progressivement.
bon, c'est très parti{a,e}l mais j'en ai déjà mis des tartines donc hop.
[^] # Re: Eiffel, Smalltalk, Ruby, OCaml
Posté par gc (site web personnel) . Évalué à 2.
Je ne connais pas le terme "write-only" pour un langage. Ca veut dire que tu as du mal à relire du code ?
Finalement je pense que Ruby est un bon candidat, voire le meilleur, parce qu'il fait un compromis entre pas mal de bonnes choses : la syntaxe est claire, et surtout on peut commencer par des programmes linéaires et introduire la structuration, les objets très progressivement.
Ça me semble de bons arguments - même si je me dis que comme "tout es objet" en Ruby, je ne pense pas que tu puisses les introduire progressivement puisque tu en as besoin dès que tu veux faire une opération basique comme la lecture d'un fichier ou le parcours d'une liste (tout du moins, la notation objet "pointée", qui diffère bien plus que la notation fonctionnelle classique du "modèle mathématique" qu'on peut supposer connu par les apprenants, et qui présente donc un risque d'augmentation de la difficulté).
[^] # Re: Eiffel, Smalltalk, Ruby, OCaml
Posté par Damien (site web personnel) . Évalué à 2.
Oui : on (je) arrive souvent à des expressions trop imbriquées, ou au contraire à devoir faire plein de let...in (autant de noms à trouver)... les applications partielles rendent difficile un nommage clair, l'indentation est pas toujours triviale.... ce genre de trucs.
la notation objet "pointée", qui diffère bien plus que la notation fonctionnelle classique
bof... c'est aussi différent que (+ 42 51) en scheme...
On peut voir ça comme un opérateur, voire comme le produit scalaire :
v.x -> on projète le vecteur v sur x, ou on projète la structure v sur le champ x
l'ordre de lecture est pas mal aussi... en caml :
List.map (fun x -> predicat) maliste
je fais un map de (ce prédicat qui rend blabla si blabla) à telle liste
en ruby maliste.select{ |x| predicat }
cette liste, j'en garde que les x qui correspondent à telle et telle condition
C'est comme en rédaction de doc technique, il faut dire d'abord ce qui est connu pour donner le contexte, et ensuite ce qui est nouveau. Le lecteur peut lire incrémentalement au lieu d'empiler le prédicat en attendant de savoir à quoi il va servir.
En fait ce que je voulais dire c'est surtout que la syntaxe de Ruby peut être introduite petit à petit. On est pas dès le départ obligé d'expliquer pourquoi il faut un class Machin avec un public static void main(String args[]) dedans etc.
Pour l'objet, la notion elle-même est simple à apprendre à qqn qui n'a pas d'à-priori fonctionnel ou procédural... "Les objets, c'est comme des employés qui ont chacun leur métier et qui travaillent ensemble." Pas besoin de parler de d'héritage et de polymorphisme, on commence par voir comment on donne des ordres aux objets disponibles, puis ensuite comment construire les siens, etc.
# Argh...
Posté par tgl . Évalué à 3.
Bouhouhou, méchant... ;(
Puis c'est pas vrai d'abord, enfin, on a aussi qlqs étudiants qui l'aiment bien ce cours :)
Bon, plus sérieusement, je ne pense pas qu'il faille prendre cet enseignement comme un apprentissage de la programmation. Pour ceux qui ne connaissent pas, il s'agit d'un cours donné en 1ère année du cycle préparatoire INSA, donc à niveau bac+1 et à des gens qui ne se dirigent pas particulièrement vers l'informatique.
Le but est juste de donner un petit avant-goût d'une partie du schmilblic informatique. Il s'intitule d'ailleurs "Initiation à l'algorithmique". En gros, les objectifs sont de donner l'intuition que la résolution d'un problème par l'informatique passe entre autres par de la modélisation (choix de structures de données adaptées au problème) et une analyse assez carré des traitement à appliquer à ce modèle pour obtenir la solution (càd qu'il faut cogiter sur l'algorithme à utiliser, bien le caractériser, le découper, tout ça quoi).
Scheme se prête pas mal à ces objectifs, notament parceque :
- cet enseignement est très cours, et plus le langage est simple, plus vite on peut s'en servir. Je sais que les parenthèses filent des boutons à certains, mais dans les faits on est très peu emmerdés par la syntaxe dans les TP, parcequ'il y a très peu de choses à savoir pour faire des programmes bien formés.
- le paradigme fonctionnel est le plus proche de ce que les étudiants connaissent déjà, à savoir les maths, et impose un raisonnement assez linéaire (la dernière ligne d'un TP, c'est à peut près toujours du style "(define solution (lambda (données) (f (g (h données)))))", le tout étant de déterminer les f,g et h, mais elles sont totalement indépendantes les unes des autres, et bien caractérisable individuellement).
Relativement à ses objectifs modestes, cet enseignement fait je pense son boulot. Au niveau de la perception qu'en ont les étudiants, c'est en fait extrêment hétérogène. Parmis ceux qui n'ont jamais programmé en quoi que ce soit, on a des gens qui assimilent très bien le mode de raisonnement (et qui en général nous disent que le lien aux mathématiques les a aidé), alors que d'autre n'accrocheront jamais. Et parmis ceux qui ont déjà une petite expérience personnelle en programmation (toujours impérative dans les faits), ça va du pur rejet ("la récursivité c'est nul, y'a qu'à utiliser un compteur de boucle plutôt" ou encore "c'est bien mignon votre truc, mais moi je fais des applets en swing le weekend alors vous avez pas grand chose à m'apprendre"), à la fascination pour la clarté, la concision et l'élégance de certains des bouts de code qu'ils sont amenés à pondre. Bref, on les mettra jamais tous d'accord, mais bon, c'est comme ça pour toutes les matières je crois.
Mais pour vraiment apprendre à quelqu'un à développer des applications, il y a tant d'autres choses à aborder que ce à quoi on se cantonne dans ce cours. Je crois qu'il n'y a pas de miracle, quel que soit le langage, c'est long.
Pour rester en Scheme, il y a moyen, par exemple en suivant le HTDP. C'est un cours largement plus complet que ce que l'on fait nous, et qui laisse peu de chose de côté :
http://htdp.org/2003-09-26/Book/(...)
Et comme autres langages, je pense que Python est un bon choix, parcequ'il permet vraiment un crecendo dans l'apprentissage de la structuration et la complexité des programmes (tu commences avec des petits scripts, et puis tu fais des fonction, puis des classes, et des modules, tout ça sans changer de langage). Le fait d'avoir une bonne base de structures de donnée (listes, dictionnaires, etc.) integrée au langage est aussi un sacré plus. Et puis biensûr, d'être interprété, ça facilite bien le tatonnement en général.
On pourra biensûr avantageusement remplacer Python par Ruby dans le paragraphe qui précède, le seul inconvénient que j'y vois étant qu'il existe beaucoup moins de support pédagogiques déjà écrits (surtout si on cherche en français). Pour Python, il y a ça qui est un peu fourre-tout mais très bien quand même :
http://www.oreilly.fr/catalogue/2841772942.html(...)
http://www.ulg.ac.be/cifen/inforef/swi/download/python_notes.pdf(...)
Pour Ruby, à part ça :
http://www.rubycentral.com/book/(...)
je connais rien. Or ça c'est pas vraiment orienté débutant ras-les-paquerettes.
Sinon, en vrac, deux langages que je trouve intéressant pour l'enseignement :
- OCaml : très complet, permet de présenter autant le fonctionnel que l'objet, impose de la rigueur au programmeur via le typage statique, bref très bien. Mon seul bémol est que pour des gens niveau zéro et pas forcement super motivés, le premier contact syntaxique est rebutant.
- Eiffel : niveau objet, c'est clean, et puis je me suis toujours dis que les contrats, pour enseigner la rigueur en programmation, ça pouvait être vachement bénéfique.
Et puis bon, c'est aussi vachement important de completer tout ça avec des initiations à qlqs langages plus spécifiques, genre prolog, sql, csp, etc., histoire que les gens ne foncent pas toujours tête baissée à faire 100% de leur code dans un seul langage juste parceque c'est leur langage de prédilection.
Mince, j'ai été verbeux...
# moi perso mais je suis trés vieux jeu et un peu c...
Posté par jo7 . Évalué à 1.
Ca rejoint ce qui a été dit au dessus entre ruby et python.
L'apprentissage de la programmation, et surtout la "bonne programmation" c'est essentiellement une question d'échange, tous les gens avec qui j'en ai parlé, et qui avaient appris tout seul le disaient, et ça se voyaient dans leur programmes.
LE bon langage c'est celui qui est partagé autour de soi, au début pour apprendre, aprés on fait ce qu'on veut.
Parce que si c'est pas pour faire du bon code, facile à reprendre, facile à tester, facile à adapter - alors autant pas avoir de conseils.
Ce qui rend l'apprentissage facile c'est une syntaxe stable et cohérente, univoque je dirais.
[^] # Re: moi perso mais je suis trés vieux jeu et un peu c...
Posté par RuleZ . Évalué à 1.
Pour cette raison, moi je conseillerais le Java qui permet:
- D'apprendre à coder vraiment proprement
- De structurer ses programmes assez facilement et clairement
- De ne pas s'enfermer dans un langage qui perdra toute utilité avec l'expérience
- Qui est doté d'une plateforme en standart, sans variance selon le compilateur et le système
- Qui est parfait pour se familiariser avec l'algorithmie du plus simple ou plus complexe
- Qui permet une familiarisation avec les concepts objets très rapidement
- Qui est sécurisé contre les graves erreurs de programmation, et qui permet un débugage simple et rapide
- etc...
# Un passage rapide...
Posté par bobert . Évalué à 2.
De mon côté je distingue surtout 2 catégories d'élèves, sans tenir compte de l'âge:
- les gens qui ne se serviront de la programmation que pour automatiser leurs tâches personnelles, ou peut-être automatiser quelques tâches au sein d'un groupe de travail.
Pour ceux-là l'approche que j'adopte c'est: langage de haut niveau + emploi systématique de la programmation objet + mini-rudiments de l'UML (du niveau "avant d'écrire une classe, dessine simplement un rectangle sur une feuille de papier ; en haut, écris le nom de la classe, etc..."). Python répond bien au besoin. Pour l'approche objet, ça roule tout seul si on va doucement.
- les gens qui à un moment ou à un autre, auront la tâche de développer tout ou partie d'un logiciel. Par exemple des étudiants en IUT telecom & reseau, à qui j'enseigne en ce moment le C et le Java. Ils ont l'impression, et beaucoup de gens avec eux, qu'apprendre le C (comprendre, faire de la programmation de "bas niveau" -- c'est comme ça qu'on l'appelle ! Il y a 25 ans le C était un langage de haut niveau...) est ringard et inutile, la "vraie" programmation c'est de la POO en C++ ou à la rigueur en Java.
Je ne souscris bien sûr pas à cette idée ; mon approche est plutôt celle (désolé d'être rapide) de "Back to basics" de Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000319.html(...))
Par contre je ne sais pas s'il vaut mieux passer d'abord par le C, l'allocation dynamique ou statique de mémoire, les pointeurs, etc, avant de passer à un langage de plus haut niveau, ou l'inverse. Pas évident.
[^] # Re: Un passage rapide...
Posté par Damien (site web personnel) . Évalué à 1.
Je vote pour l'inverse :) Ce qui est primordial c'est de savoir résoudre un problème, l'algorithmique et la complexité, structurer intelligemment le code pour qu'il soit maintenable.
# language
Posté par ghostX . Évalué à 1.
Puis tu peut tater au php et perl, qui sont de sympatique language.
Puis tu veras que a part quelque petit truc, les algo sont tjs les memes!
while; for etc...
Puis quand t'est pres a mettre les main dans le vrais comboui( c'est ce que je fais en ce moment ) tu peut tester du C.
De toute facon logiquement quoi que tu apprenne tu seras plus fort pour un autre language, et ainsi de suite.
# Pascal, Smalltalk et eiffel
Posté par Djax . Évalué à 1.
- iterations (boucle)
- récursion
- conditionnel
- routine:
-- fonction
-- procédure
Une fois ces notions comprises, passer à un langue à objet.
Eiffel est une bonne suite, la syntaxe etant assez proche.
en Eiffel, tu auras la programmation par contrat, ainsi tu apprendras à programmer proprement. tu auras le multihéritage et la généricité (classe paramétable, en très gros).
sinon il y a une bonne règle à utiliser: la règle de 10 lignes, toutes routines ne fera pas plus de 10 lignes (et je ne parles pas de lignes de 2 km). Ainsi les programmes sont compréhensibles.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.