Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 8 sur 13 PremièrePremière ... 456789101112 ... DernièreDernière
Affichage des résultats 141 à 160 sur 247
  1. #141
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 358
    Points
    4 358

    Par défaut

    Citation Envoyé par SpiceGuid Voir le message
    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.

    Citation Envoyé par SpiceGuid Voir le message
    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.

    Citation Envoyé par SpiceGuid Voir le message
    Les bons usages s'apprennent mieux pas à pas, l'un après l'autre.
    Pas à pas... Séquentiellement... Impératif...

    Citation Envoyé par SpiceGuid Voir le message
    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.

    Citation Envoyé par SpiceGuid Voir le message
    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 ? ...).

    Citation Envoyé par ZoinX Voir le message
    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...

    Citation Envoyé par chaplin Voir le message
    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.

    Citation Envoyé par SpiceGuid Voir le message
    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.

    Citation Envoyé par jabbounet Voir le message
    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...

  2. #142
    Membre Expert Avatar de chaplin
    Inscrit en
    août 2006
    Messages
    1 213
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 1 213
    Points : 1 437
    Points
    1 437

    Par défaut

    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:
    Citation Envoyé par F.Saad Voir le message
    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.

  3. #143
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par SpiceGuid Voir le message
    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...

  4. #144
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 358
    Points
    4 358

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    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.

  5. #145
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 164
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : avril 2003
    Messages : 6 164
    Points : 7 656
    Points
    7 656

    Par défaut

    Code Haskell :
    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 :
    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ï

  6. #146
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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 ?

  7. #147
    Membre émérite Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 944
    Points
    944

    Par défaut

    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 :
    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.

  8. #148
    Membre émérite Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 944
    Points
    944

    Par défaut

    Je voulais dire :

    Code :
    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))))))

  9. #149
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 358
    Points
    4 358

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    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.

  10. #150
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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 :-\

  11. #151
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 358
    Points
    4 358

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    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 ?

  12. #152
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro Damien Guichard
    Inscrit en
    juin 2007
    Messages
    1 573
    Détails du profil
    Informations personnelles :
    Nom : Homme Damien Guichard
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 573
    Points : 2 448
    Points
    2 448

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    Citation Envoyé par 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 :
    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 :
    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
    Du même auteur: le cours OCaml, le dernier article publié, le blog dvp et le jeu vidéo.
    Avant de poser une question je lis les règles du forum.

  13. #153
    alex_pi
    Invité(e)

    Par défaut

    Hihi, Coq pour un débutant :p
    Version "calculatoire" :
    Code :
    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.

  14. #154
    Membre émérite Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 944
    Points
    944

    Par défaut

    Citation Envoyé par Jedai Voir le message
    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.

  15. #155
    Expert Confirmé Avatar de jabbounet
    Homme Profil pro frederic frances
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 902
    Détails du profil
    Informations personnelles :
    Nom : Homme frederic frances
    Âge : 38

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 902
    Points : 2 675
    Points
    2 675

    Par défaut

    Citation Envoyé par I_believe_in_code Voir le message
    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.

  16. #156
    Membre émérite Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 944
    Points
    944

    Par défaut

    Citation Envoyé par jabbounet Voir le message
    Langage puissant
    Et comment !

    Citation Envoyé par jabbounet Voir le message
    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."


    Citation Envoyé par jabbounet Voir le message
    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)

    Citation Envoyé par jabbounet Voir le message
    je le verrais plus dans des cours de programmation avancée.
    LISP est un bon langage pour n'importe quelle partie d'un cursus.

  17. #157
    Invité régulier
    Étudiant
    Inscrit en
    juillet 2009
    Messages
    5
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2009
    Messages : 5
    Points : 5
    Points
    5

    Par défaut

    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é.

  18. #158
    Membre émérite Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 944
    Points
    944

    Par défaut

    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.

  19. #159
    Invité régulier
    Étudiant
    Inscrit en
    juillet 2009
    Messages
    5
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2009
    Messages : 5
    Points : 5
    Points
    5

    Par défaut

    Citation Envoyé par I_believe_in_code Voir le message
    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...

  20. #160
    Expert Confirmé Avatar de jabbounet
    Homme Profil pro frederic frances
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 902
    Détails du profil
    Informations personnelles :
    Nom : Homme frederic frances
    Âge : 38

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 902
    Points : 2 675
    Points
    2 675

    Par défaut

    Citation Envoyé par I_believe_in_code Voir le message
    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •