Discussion :

[Mac LAK]

Il y aura peut être un jour du multi-coeur à grande échelle exploité par de la programmation fonctionnelle, dans tous les cas ça restera une techno de niche.

Ou, chose beaucoup plus vraisemblable, intégré en tant que coprocesseur, comme le sont actuellement les FPU, MMX et autres SSE au sein des processeurs... Il est indéniable qu'un cœur fonctionnel au sein d'un processeur serait un énorme atout, tout comme l'est un FPU dès que l'on veut faire du calcul ou un SSE pour les traitements SIMD...

Mais pour moi, ça restera soit des CPU de niches, soit des coprocesseurs. La seconde solution serait d'ailleurs bien plus profitable aux approches fonctionnelles que la première ! Il y a dix ans, qui connaissait (et utilisait !) les processeurs SIMD, à part les étudiants en architecture parallèle ? Avec l'arrivée du MMX, puis du SSE, ces principes de calcul sont devenus quasiment courants, et connus de la plupart des développeurs. Ils ne l'auraient pas été autant si les CPU SIMD étaient restés "dédiés" à des niches.

Les débutants recherchent-ils un tel niveau de lisibilité ?

Non, c'est ce que je me tue à expliquer... Débuter par un des extrêmes (que ce soit du ML ou de l'ASM) est, à mon sens, néfaste car cela empêche l'ouverture d'esprit.

Les bons usages s'apprennent mieux pas à pas, l'un après l'autre.

Pas à pas... Séquentiellement... Impératif...

Donc je serais plutôt de l'avis de Mac LAK, un programmeur qui a acquis les bons reflexes (bien indenter, bien nommer ses variables, toujours utiliser la portée de déclaration la plus petite,...) est devenu autonome et libre de choisir s'il veut aller davantage du côté de la qualité (par exemple avec un langage déclaratif), du protypage (par exemple avec un langage dynamique), de la programmation système, des web services ....

Merci.

Ceci dit je suis d'accord pour dire que le principe de récurrence n'est pas assez prégnant dans l'apprentissage de la programmation. Toutefois aller jusqu'à l'imposer à ceux qui se destinent aux web services, non seulement ça me paraît overkill mais surtout je doute que beaucoup l'acceptent.

Tiens, effectivement, je n'ai pas parlé de la récursivité... Chapitre pourtant souvent délicat à enseigner à ceux qui ignorent ce qu'est une suite (au sens mathématique, bien sûr).
Ceci étant dit, c'est une notion qui peut être enseignée facilement si l'on prends la peine de montrer l'analogie avec les boucles, et en quoi une récursion est différente d'une boucle (concept de "pile").

Pour ma part, j'utilisais l'analogie de la découpe de bois : on commence par couper le tronc en deux, puis chaque moitié en deux, puis encore, et encore, jusqu'à obtenir des cure-dents. Il est facile de montrer que la version "boucle" (analogie : un trajet à pied, un pas, puis un pas, puis un pas, ...) serait bien plus difficile à faire, car tailler un cure-dent dans un tronc d'arbre n'est pas évident (quelle taille ? quel diamètre ? où commencer ? ...).

Si les enseignants ont souvent du mal à expliquer les pointeurs aux débutants et si les débutants ont souvent du mal à comprendre les pointeurs, peut-être que c'est justement parce que c'est difficile à conceptualiser et difficile à concilier avec pédagogie... et du coup peut-être que les langages utilisant les pointeurs ne sont pas les plus pédagogiques et adaptés aux débutants, et peut-être qu'il est nécessaire de commencer avec des langages plus simples à appréhender, comme le java ou le c#

Ce serait plutôt que les enseignants en question ont été formés à une époque un peu trop reculée des réalités modernes, et de façon beaucoup trop autodidacte. Sans parler du fait que peu de profs acceptent de se remettre en question sur le sujet !!

Dans toutes mes études, j'ai rencontré très exactement TROIS profs d'informatique "valables", notamment un de mes profs d'algo. Les autres, comme je l'ai dit, étaient soit des matheux reconvertis, soit des "bidouilleurs" ayant accédé au professorat. Dans un cas comme dans l'autre, c'étaient de très mauvais pédagogues.

Conceptualiser les pointeurs et l'expliquer correctement n'est ni difficile à faire, ni difficile à comprendre. Mais comme beaucoup de domaines, il n'est pas possible d'expliquer clairement quelque chose que l'on ne maîtrise pas TOTALEMENT.

Et quand je voyais un de mes profs de DEUG complètement largué par des doubles indirections et des pointeurs fonctionnels, on peut légitimement se demander s'il était apte à enseigner la notion de pointeurs...

On peut aussi faire de la récursivité sans les pointeurs, autrement dit on peut étudier l'un indépendamment de l'autre, puis les deux en même temps, quand les deux notions sont comprises individuellements.

La récursivité n'est pas dépendante de la notion de pointeurs, je dirais même qu'il vaut mieux éviter d'en parler en approche du concept récursif. Toutefois, il n'est pas toujours trivial de trouver un exemple concret de récursivité qui n'implique pas des notions de mathématiques.
Le concept lui-même n'a pas besoin de maths, mais faire sa première fonction récursive, c'est souvent des maths par contre... A moins d'avoir avancé suffisamment dans les algos pour avoir expliqué les tris, et donc pouvoir illustrer la récursivité avec QuickSort.

Commencer tout de suite avec un langage objet, j'y crois pas.

Moi non plus... D'où l'intérêt des langages multi-paradigmes, d'ailleurs. La POO n'est pas très difficile à comprendre, mais quelques bases saines sont quand même nécessaires auparavant je pense.

CE serait bien que le language pour débutant identifie aussi clairement les paramètres "in" et "out" des fonctions/methodes/procédures

Ce qui est le cas de Pascal et Ada, notamment...

[chaplin]

Je sais qu'à mes débuts, j'ai coincé sur les déclarations de variables, les entrées sorties des fonctions, les échanges de données entre variables (permutations), les boucles imbriquées et de loin la compilation (ie erreurs).

Peut être que le premier outil qui m'a donné envie de programmer c'est Mapple (lointain souvenir), mais le réel apprentissage, je l'ai fais avec Fortran et au début on en bave avec le compilateur, car il fallait faire attention aux colonnes.

Je ne critique pas les langages fonctionnels, ils insistent sur des points qu'on ne voit pas dans d'autres paradigmes, d'où l'importance de voir différents langages de programmation.

Ensuite, il faut faire une nuance entre apprentissage scolaire et autodidacte.

Pour débuter, il faut apprendre, faire des exercices, s'entraîner et le compilateur joue le rôle de correcteur orthographique/grammatical et c'est là qu'on passe le plus de temps.

Je ne regrette pas mon premier langage d'apprentissage. Même s'il ne permettait pas de faire du graphique, on acquiert les réflexes en algorithmique.

EDIT:

Je ne suis encore qu'un gros débutant. Sinon, j'apprends via les tutos d'ici , + Les mods d'ici pour réaliser des mini projets bizarre et pas utile pour l'instant
http://code.google.com/p/sleeptime/s...wse/#svn/trunk
je dirais que le seul echec jusqu'a maintenant c'est le temps que ca me prend pour justement faire ces trucs tres simple
3h pour mon petit sleeptime, 2h 30 de recherche de classes adéquate et 10 min de tappage de code + 20 min de débogage

FSaad montre l'exemple du débutant confronté aux difficultés liées à la syntaxe d'un langage et la documentation ad hoc.
Quand on débute, on découvre, c'est à dire qu'on ne sait rien à priori.

[alex_pi]

Un fondeur ne peut pas continuer indéfiniment à produire un cpu pour un langage ou un paradigme déterminé. Ça a été tenté pour Lisp, pour Java et pour d'autres et aucun n'a percé durablement. Il y aura peut être un jour du multi-coeur à grande échelle exploité par de la programmation fonctionnelle, dans tous les cas ça restera une techno de niche.

Gnih ? Ce qu'ils disent, c'est que pour avoir une chance de faire des programmes tournant sur des ordis à 1024 coeurs, avec une probabilité raisonnable que le programme fasse ce que l'on attend de lui, la programmation fonctionnelle est une des seules chance que l'ont ait, puisque, réduisant de façon drastique le nombre d'effet de bord, elle permet d'avoir une chance de faire coopérer des threads sans faire n'importe quoi. Ils ont jamais parlé de mettre des fermetures au niveau processeur !

Bon et sinon, pour revenir à l'aspect débutant, il n'y a que moi qui suis capable d'écrire un parcours d'arbre en moins de 3 jours ? Histoire de montrer les différentes approches...

[Mac LAK]

Bon et sinon, pour revenir à l'aspect débutant, il n'y a que moi qui suis capable d'écrire un parcours d'arbre en moins de 3 jours ? Histoire de montrer les différentes approches...

Pourquoi l'écrire encore une fois ?

En Pascal, et surtout cette page, cherche les "Spécification d'implantation en Pascal" dans la page.
En Ada (sachant que via un paquetage, on peut rendre le type géré totalement générique, de la même manière qu'avec un template C++).

Dans tous les cas, une fois l'algo décrit en "langage algorithmique" classique, l'implémentation en Pascal ou Ada se fait de façon presque littérale... Et il y a tellement d'exemples d'arbres sur le net que "voir" l'approche Pascal / Ada ne pose vraiment aucun problème.

[Jedai]

Code Haskell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
-- un arbre binaire est soit une feuille soit un noeud interne
-- avec une valeur et deux sous-arbres comme fils
data Arbre a = Feuille | Noeud (Arbre a) a (Arbre a)
 
-- les annotations de types ne sont pas nécessaires 
-- mais souvent ajoutées pour être plus clair
profondeur :: Arbre a -> Int
profondeur Feuille                        = 0
profondeur (Noeud filsGauche _ filsDroit) = 
    1 + max (profondeur filsGauche) (profondeur filsDroit)

Evidemment ça ressemble pas mal à OCaml, la syntaxe est relativement proche de la famille ML puisqu'il s'agissait d'une des inspirations lorsqu'Haskell a été créé en 90.

Edit : Je réalise que la question ne portait pas sur un arbre binaire en particulier, voici donc pour un arbre quelconque :

Code Haskell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
data Tree a = Leaf a | Node [Tree a]
 
depth :: Tree a -> Int
depth (Leaf _)      = 0
depth (Node forest) = 1 + maximum (map depth forest)

--
Jedaï

[alex_pi]

Pourquoi l'écrire encore une fois ?

Peut être parce qu'un "débutant" l'a demandé, histoire qu'on puisse comparer les styles et voir lequel semble le plus simple à expliquer ?

[I_believe_in_code]

On suppose qu'il existe des primitives FilsGauche et FilsDroit. En lisp on peut les implémenter simplement avec des paires pointées (FG . FD). En C ou C++ (par exemple) il faudrait créer les structures soi-même et les fonctions d'allocation / désallocation et d'accès qui vont avec.


En langage algorithmique (version récursive)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
fonction hauteur (ENTREE  a : arbre) : entier
début
    si arbre = NULL alors retourner 0 ;
    retourner 1 + MAX (hauteur (FilsGauche (a), hauteur (FilsDroit (a))) ; 
fin

;;EN LISP  :
;;version récursive
(defun hauteur (a)
  (if (nullp a)
      0
      1 + (max (hauteur (FilsGauche (a)) (hauteur (FilsDroit (a))))))

Je laisse ceux qui ont du temps à perdre proposer une version itérative correcte. Dans n'importe quel langage.

[I_believe_in_code]

Je voulais dire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
fonction hauteur (ENTREE a : arbre) : entier
début
  si arbre = NULL alors retourner 0 ;
  retourner 1 + MAX (hauteur (FilsGauche (a), hauteur (FilsDroit (a))) ; 
fin

;;EN LISP :
;;version récursive
(defun hauteur (a)
  (if (nullp a)
    0
    1 + (max (hauteur (FilsGauche (a)) (hauteur (FilsDroit (a))))))

[Mac LAK]

Peut être parce qu'un "débutant" l'a demandé, histoire qu'on puisse comparer les styles et voir lequel semble le plus simple à expliquer ?

Je répète : pourquoi l'écrire de nouveau (= le "refaire"), alors qu'il y a tant d'exemples dispos sur le net, notamment sur DVP ? La gestion d'arbres, ça reste quand même aussi basique côté algo que les tris et les listes chaînées, "l'exercice obligatoire".

De plus, tu confonds l'explication du concept avec son implémentation (notamment lorsque tu parles de "simplicité). En Pascal ou Ada, l'implémentation, c'est quasiment le pseudo-code algo à quelques conventions syntaxiques près, tout comme l'implémentation en fonctionnel est quasiment l'écriture du TAD. Cependant, expliquer les TAD n'est pas forcément plus simple qu'expliquer un pseudo-code, loin de là.

Mais ce n'est pas parce qu'un code est plus court qu'il est plus simple ou plus compréhensible... Tu peux aller voir IOCCC si tu veux t'en convaincre.

[alex_pi]

Je répète : pourquoi l'écrire de nouveau (= le "refaire"), alors qu'il y a tant d'exemples dispos sur le net, notamment sur DVP ? La gestion d'arbres, ça reste quand même aussi basique côté algo que les tris et les listes chaînées, "l'exercice obligatoire".

Fais gaffe quand même, parce qu'à systématiquement refuser de montrer comment ça s'écrit en Pascal, et à le mettre à coté du code Caml, tu vas finir par faire croire au gens que c'est parce que tu te rends compte que c'est beaucoup moins simple à montrer à un débutant. Ce serait con quand même :-\

[Mac LAK]

Fais gaffe quand même, parce qu'à systématiquement refuser de montrer comment ça s'écrit en Pascal, et à le mettre à coté du code Caml, tu vas finir par faire croire au gens que c'est parce que tu te rends compte que c'est beaucoup moins simple à montrer à un débutant. Ce serait con quand même :-\

Les liens mis dans le message #152, tu les as ouverts au moins avant de (re)(re)(re)(re)troller ?

[SpiceGuid]

Un fondeur ne peut pas continuer indéfiniment à produire un cpu pour un langage ou un paradigme déterminé. Ça a été tenté pour Lisp, pour Java et pour d'autres et aucun n'a percé durablement. Il y aura peut être un jour du multi-coeur à grande échelle exploité par de la programmation fonctionnelle, dans tous les cas ça restera une techno de niche.

Gnih ? Ce qu'ils disent, c'est que pour avoir une chance de faire des programmes tournant sur des ordis à 1024 coeurs, avec une probabilité raisonnable que le programme fasse ce que l'on attend de lui, la programmation fonctionnelle est une des seules chance que l'ont ait, puisque, réduisant de façon drastique le nombre d'effet de bord, elle permet d'avoir une chance de faire coopérer des threads sans faire n'importe quoi. Ils ont jamais parlé de mettre des fermetures au niveau processeur !

Il y aurait quand même une fermeture de fait: de l'aveu même du fondeur ces futurs cpu ne seraient raisonnablement exploitables qu'à l'aide de la programmation fonctionnelle. Il faudrait être aveugle pour ne pas voir que ça leur ferme les portes du marché mainstream.
(je ne dis pas que la programmation fonctionnelle n'est pas la bonne solution pour le multi-coeur, je dis juste que si c'est la seule alors le multi-coeur n'aura qu'un avenir commercial de niche)

Code Coq 8.1 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Require Import Max.

Inductive tree : Set :=
  | Leaf: tree
  | Node: tree -> tree -> tree.

Inductive height : tree -> nat -> Prop :=
  | leaf_height :
      height Leaf 0
  | node_height :
      forall l r lh rh,
      height l lh ->
      height r rh ->
      height (Node l r) (max lh rh + 1).

Code 68020 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
STRUCTURE Tree,0
        APTR  tree_left
        APTR  tree_right
        LABEL tree_sizeof

height_enter:
        MOVE.L   4(SP),D0
        BEQ.S    height_exit0
        MOVE.L   D0,A0
        MOVE.L   tree_left(A0),-(SP)
        BSR.S    height_enter
        MOVE.L   4(SP),A0
        MOVE.L   D0,-(SP)
        MOVE.L   tree_right(A0),-(SP)
        BSR.S    height_enter
        MOVE.L   (SP)+,D1
        CMP.L    D1,D0
        BGT.S    height_exit1
        EXG.L    D1,D0
height_exit1:
        ADDQ.L   #1,D0
        RTD      #4
height_exit0:
        MOVEQ.L  #0,D0
        RTD      #4

[alex_pi]

Hihi, Coq pour un débutant :p
Version "calculatoire" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Require Import Max.

Inductive tree : Set :=
  | Leaf: tree
  | Node: tree -> nat -> tree -> tree.

Fixpoint height tree : nat :=
match tree with
  | Leaf => O
  | Node l _ r => S (max (height l) (height r))
end.

[I_believe_in_code]

Donc tu serais plutôt partisan d'apprendre avec un langage de haut niveau, fonctionnel ?

Je suis partisan d'apprendre avec COMMON LISP (un de ses meilleurs dialectes). LISP a la réputation d'être une langage fonctionnel mais je n'ai jamais lu ni écrit de code purement fonctionnel en LISP (en tout cas pas de plus de vingt lignes)

Les bons langages sont multiparadigmes et les bons programmeurs aussi. Quand je code en LISP je mets du fonctionnel où il faut, de l'impératif où il faut, de l'objet où il faut, j'invente ma propre syntaxe quand il faut (les macros extrêmement puissantes de ce langage le permettent) et j'écris des programmes qui écrivent des programmes quand il faut (grâce aux macros et aux fonctions de première classe) J'utilise toutes les spécificités de LISP qui permettent de faire du développement à la fois rapide et performant (compilation à la demande, données persistentes qui peuvent avantageusement remplacer un SGBG dans bien des cas, déclarations pour optimiser les routines critiques, innombrables types de boucles, extensions régulièrement standardisées si la communauté les utilise beaucoup de fait, couplage avec Emacs et SLIME pour un déboggage ultra rapide, implémentation du paradigme objet (CLOS) bien plus puissante que celles de C++ ou de Java, etc)

A Bordeaux 1 il y a quelques années, LISP était très utilisé dans l'enseignement de la programmation, mais pas comme premier langage. J'ai trouvé cela dommage car commencer par C++ (ce qui était le cas des élèves qui passaient par l'IUT par exemple), franchement, ça ne prépare pas à la programmation multi-paradigme.
Bref.
A côté de LISP, les étudiants voyaient aussi des trucs bas niveaux (Assembleur et C), des langages "pour faire plaisir aux recruteurs" (C++ et Java) et OCAML et Coq qui avaient le don d'exaspérer ceux pour qui LISP était déjà "trop matheux" mais qui ont eu beaucoup de succès chez les autres.

Ce qui m'énerve avec les informaticiens, c'est qu'il y en a beaucoup trop qui ne jurent que par l'impératif au détriment du fonctionnel, que par l'objet au détriment du procédural, que par C++ au détriment de tout autre langage (ce ne sont pas les discussions sur Developpez.com qui me contrediront). Le marché leur donne raison donc ils ne se remettent pas en cause (et ce sont eux qui donnent des leçons d'ouverture d'esprit !) Pourtant, les choix du marché ne sont pas forcément les bons, les décideurs et les recruteurs ne font pas forcément bien leur travail. Sinon il n'y aurait pas autant de projets annulés, retardés, explosant leur budget, etc.

[jabbounet]

Je suis partisan d'apprendre avec COMMON LISP (un de ses meilleurs dialectes). LISP a la réputation d'être une langage fonctionnel mais je n'ai jamais lu ni écrit de code purement fonctionnel en LISP (en tout cas pas de plus de vingt lignes)

Langage puissant (je l'aime bien celui là, et j'ai même eu a maintenir un application en lisp quand j'ai commencé a bosser) il est peu être un peu trop pour débuter de plus sa syntaxe et la façon de penser pour programmer en lisp est assez éloignée des autres langages "classique" que l'on peux rencontrer de façon plus fréquente ce qui rend le passage a un autre langage peu être plus compliquée.

L'approche et les concept sous lisp sont peu être un peu trop hard pour débuter dans le sens ou devoir expliquer 3 ou 4 lignes de lisp reviens a expliquer une cinquantaine de lignes dans un langage "classique"

je le verrais plus dans des cours de programmation avancée.

[I_believe_in_code]

Langage puissant

Et comment !

il est peu être un peu trop pour débuter de plus sa syntaxe et la façon de penser pour programmer en lisp est assez éloignée des autres langages "classique" que l'on peux rencontrer de façon plus fréquente ce qui rend le passage a un autre langage peu être plus compliquée.

Les problèmes posés par la syntaxe sont les parenthèses et la notation préfixée pour les opérations arithmétiques. Ce sont deux points qui font peur AVANT de s'y mettre mais avant seulement. La façon de penser en LISP n'est pas toujours éloignée des langages classiques... disons que LISP permet d'écrire du code de la même manière qu'on le fait en langage algorithmique ou en C, mais qu'il permet aussi des tas d'autres choses (LISP est multi-multi-paradigme) dont certaines sont bien compliquées effectivement. Un bon cours de LISP ne doit évidemment pas commencer par ces choses-là. Un cours pour débutants non plus. Il faut en mettre juste un peu pour que les élèves puissent deviner l'effrayante puissance de la bête. Comme ça, quand plus tard on leur enseigne C ou Java, ils se rendent compte que ces langages ont beaucoup moins de choses à proposer et son plus faciles (quoique, pour C ça se discute, il y a tellement de petits détails à régler à la main, il est assez difficile d'écrire du bon C... finalement c'est presque aussi dur que d'écrire du bon LISP) Alors que si on enseigne d'abord Java et ensuite LISP, on forme des générations d'incultes qui pensent que "Puisque java permet déjà de tout faire, on ne va pas s'ennuyer à appendre LISP qui a l'air bien plus difficile et qui n'est pas recherché par les recruteurs."

devoir expliquer 3 ou 4 lignes de lisp reviens a expliquer une cinquantaine de lignes dans un langage "classique"

Il arrive que ce qui prend cinquante lignes dans un autre langage s'écrive en dix lignes en LISP. Mais ces dix lignes sont beaucoup plus faciles à expliquer que les cinquantes lignes équivalentes dans un langage classique. (C'est en tout cas ce que j'ai constaté en enseignant un module de LISP)

je le verrais plus dans des cours de programmation avancée.

LISP est un bon langage pour n'importe quelle partie d'un cursus.

[simcoin]

Concernant les langages fonctionnels, j'ai commencé sur caml (light) en prépa. J'avoue que j'aime bien les maths, mais la découverte de Java après m'a fait un choc à cause de la verbosité et du manque d'expressivité du langage. Bon je suis un débutant n'ayant encore programmé aucun projet d'envergure raisonnable
, mais après avoir touché à du caml, du lisp (scheme en fait), du python, du java et un bout de C++ je pense que les fonctionnels sont largement plus agréables à manipuler (plutôt que jongler entre char[] et string en C++ par exemple, oiu se prendre la tête sur un problème de mémoire qui n'a strictement rien à voir avec l'algo qu'on tente d'implémenter) pour un débutant.

Python me semble aussi un bon choix, quand on débute on se contrefiche de la performance. Par contre le laxisme du typage dynamique est fâcheux, ce qui nous ramène aux langages fonctionnels à typage statique comme caml ou haskell, qui combinent concision, sûreté et efficacité.

[I_believe_in_code]

Attention à ne pas amalgammer Lisp et Scheme qui n'ont autant rien à voir l'un avec l'autre que C avec Java, malgré les similitudes syntaxiques.

[simcoin]

Attention à ne pas amalgammer Lisp et Scheme qui n'ont autant rien à voir l'un avec l'autre que C avec Java, malgré les similitudes syntaxiques.

C'est vrai, seul scheme propose callcc
En fait à part la question des namespaces variables/fonctions séparés, je suis dans le flou le plus complet, n'ayant jamais touché à CL...

Quoi qu'il en soit, les deux restent des langages très puissants à la syntaxe simple (une seule règle de syntaxe, ça va) offrant des macros et des fonctions de premier ordre, c'est-à-dire plus agréables à utiliser que C/C++/Java dans lesquels un map prend au minimum 2 lignes et/ou une encapsulation de fonction...

[jabbounet]

Attention à ne pas amalgammer Lisp et Scheme qui n'ont autant rien à voir l'un avec l'autre que C avec Java, malgré les similitudes syntaxiques.

n'ayant jamais vu scheme je ne ferais pas la confusion.

ceci dit faire du procédural et de l'algorithmie classique en lisp est un peu lourd, il est facile de se passer des boucle "for/while" par exemple.