"write-only" pour un langage. Ca veut dire que tu as du mal à relire du code ?
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.
[^] # Re: Eiffel, Smalltalk, Ruby, OCaml
Posté par Damien . En réponse au message Pour apprendre à programmer. É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.