+ Répondre à la discussion
Page 2 sur 5 PremièrePremière 12345 DernièreDernière
Affichage des résultats 21 à 40 sur 84
  1. #21
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par nonpoluant Voir le message
    si tu n'utilises pas de boucles for ni de boucles whiles, et si tu n'utilises pas le caractere '!', le :=, et le mot clef ref, et bien tu es quasiment assuré de faire de la programmation fonctionnelle.
    T'as quand même oublié les tableaux là... Ainsi que le mot clé mutable dans la définition des structures (mais en lisant plus bas, je pense que tu ne le connais pas..)


    Citation Envoyé par nonpoluant Voir le message
    Pour éviter de faire de la programmation objet, et bien... il suffit de ne pas utiliser les objets A noté qu'un module n'est pas un objet (pas d'héritage par exemple).
    Programmation objet ne signifie pas nécessairement programmation impérative ! Bon ok, c'est souvent le cas. Mais tu peux recopier les objets avec le changement. Et là, c'est purement fonctionnel.



    Citation Envoyé par nonpoluant Voir le message
    La c'est bien, c'est fonctionnel, c'est pas des champs mutables. Si tu avais fait ceci alors ça aurait été des champs mutables :
    Code :
    1
    2
    3
    4
    5
    6
    # type complexe = { re: float ref; im : float ref} ;;
    type complexe = { re : float ref; im : float ref; }
    # let z1 = ref {re= ref 0. ; im = ref 3.14 } ;;
    val z1 : complexe ref =
      {contents = {re = {contents = 0.}; im = {contents = 3.14}}}
    Un champ mutable, c'est définis avec le mot clé mutable !

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    # type foo = {mutable bar : int};;
    type foo = { mutable bar : int; }
    
    # let a = {bar = 3};;
    val a : foo = {bar = 3}
    
    # a.bar <- 42;;
    - : unit = ()
    # a;;
    - : foo = {bar = 42}
    Citation Envoyé par nonpoluant Voir le message
    [...]le typage statique ça veut dire que si ton programme plante à cause d'une erreure de typage, il plantera seulement à la compilation, et non pas à l'execution quand l'utilisateur (le client, ou la fusée arianne 5 qui est sencé l'utiliser) l'executera.
    Bon, je suis notoirement un grand fan du typage statique, mais pour ariane 5, c'était un dépassement de capacité d'un entier, donc au contraire, ça aurait eu plus de chance de tenir avec un langage dynamique :-)

  2. #22
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 331
    Points
    2 331

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    [...]
    Bon, je suis notoirement un grand fan du typage statique, mais pour ariane 5, c'était un dépassement de capacité d'un entier, donc au contraire, ça aurait eu plus de chance de tenir avec un langage dynamique :-)
    Ouuuaiiis Ariane en Scheme

    Plus sérieusement, le problème était plus complexe, même si la source du problème est effectivement un dépassement de capacité. Je pense que ça aurait péter plus fort encore dans un langage dynamique

  3. #23
    Membre émérite

    Inscrit en
    juin 2006
    Messages
    1 116
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : juin 2006
    Messages : 1 116
    Points : 976
    Points
    976

    Par défaut

    Citation Envoyé par Garulfo Voir le message
    Le système d'enseignement dispose d'une énorme inertie. Ce qui fait qu'on enseigne encore souvent le C/C++ en premier langage « parce que c'est comme ça ».
    C'est vrai que j'ai appris un ersatz de C++ en IUT.
    Citation Envoyé par alex_pi Voir le message
    T'as quand même oublié les tableaux là...
    Utiliser les listes en Ocaml, ce n'est pas de la programmation fonctionnelle ? Je ne suis pas certain... Les listes sont GROSSO MODO des tableaux, non ?
    Citation Envoyé par Garulfo Voir le message
    Ouuuaiiis Ariane en Scheme

    Plus sérieusement, le problème était plus complexe, même si la source du problème est effectivement un dépassement de capacité. Je pense que ça aurait péter plus fort encore dans un langage dynamique
    N'était ce pas un problème d'unité ? L'unité dans laquelle comptait l'informaticien empêchait le dépassement de capacité, mais pas l'unité utilisée par le calculateur ?

  4. #24
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par kromartien Voir le message
    Utiliser les listes en Ocaml, ce n'est pas de la programmation fonctionnelle ? Je ne suis pas certain... Les listes sont GROSSO MODO des tableaux, non ?
    Oui, les listes sont des structures fonctionnelles. En revanches, les tableaux (en tout cas en Caml) sont des structures par essence mutable, donc typiquement pas ce que l'on appelle "fonctionnel

    Citation Envoyé par kromartien Voir le message
    N'était ce pas un problème d'unité ? L'unité dans laquelle comptait l'informaticien empêchait le dépassement de capacité, mais pas l'unité utilisée par le calculateur ?
    Non. Ils avaient réutilisé du code d'Ariane 4, mais les capteurs d'Ariane 5 retournait des valeurs plus importantes (soit par un gain de précision, soit tout simplement parce qu'Ariane 5 était plus puissante et donc l'accélération plus grande), et donc, paf, dépassement.

    Il y a eu des soucis d'unité avec des sondes pour mars, mais c'est encore un autre problème.

  5. #25
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 308
    Points
    1 308

    Par défaut

    Citation Envoyé par kromartien Voir le message
    Utiliser les listes en Ocaml, ce n'est pas de la programmation fonctionnelle ? Je ne suis pas certain... Les listes sont GROSSO MODO des tableaux, non ?
    Les listes sont tout à fait fonctionnelles. Leur implémentation encourage vraiment l'utilisation du fonctionnel et de la récursion.

    Les tableaux, c'est un peu différent. En plus des différences algorithmiques, les tableaux de Caml sont mutables, contrairement aux listes. Même si on peut utiliser un tableau de façon fonctionnelle, l'impératif se mélange assez bien avec les tableaux. Par exemple, la fonction Array.sort modifie le tableau, alors que List.sort renvoie une nouvelle liste.

  6. #26
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 183
    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 183
    Points : 8 332
    Points
    8 332

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    Non. Ils avaient réutilisé du code d'Ariane 4, mais les capteurs d'Ariane 5 retournait des valeurs plus importantes (soit par un gain de précision, soit tout simplement parce qu'Ariane 5 était plus puissante et donc l'accélération plus grande), et donc, paf, dépassement.
    Bien sûr s'ils avaient utilisés des nombres à précision arbitraire, ce n'aurait pas été un problème... Et cette question n'a rien à voir avec la distinction "typage statique/typage dynamique" si ce n'est qu'un certain nombre de langage dynamique ont opté pour ne proposer que des nombres à précision arbitraire, dégradant ainsi globalement leurs performances mais obtenant des réponses plus correctes de temps en temps. Par ailleurs, dans un environnement tel que celui d'Ariane 5, l'usage d'un des langages dynamique actuel est complètement prohibé par les contraintes de hard real time.

    Citation Envoyé par alex_pi Voir le message
    Il y a eu des soucis d'unité avec des sondes pour mars, mais c'est encore un autre problème.
    Ca par contre ça fait partie des problèmes qui peuvent être traités avec un bon système de type, sans même une pénalité en temps d'exécution (puisque toutes les vérifications sont faites à la compilation et les types effacés à l'exécution) (cf dimensional en
    Haskell par exemple).

    --
    Jedaï

  7. #27
    Membre chevronné
    Avatar de GnuVince
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2004
    Messages
    679
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2004
    Messages : 679
    Points : 774
    Points
    774

    Par défaut

    Pour un débutant, je suggère toujours Scheme. J'ai expliqué mes raisons sur mon blog: http://gnuvince.wordpress.com/2008/0...ommend-scheme/

    Pour ce qui est de la documentation majoritairement en anglais, je pense que n'importe quel développeur qui n'est pas assez fort en anglais pour lire un ouvrage de programmation devrait commencer par suivre un cours d'anglais avant d'apprendre un autre langage de programmation.

  8. #28
    Membre du Club
    Inscrit en
    août 2008
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : août 2008
    Messages : 47
    Points : 52
    Points
    52

    Par défaut

    Je tiens à remercier ceux qui m'ont corrigés.
    Effectivement je ne connaissais pas ce mot clef mutable je vais de ce pas l'apprendre.
    J'ai dis Ariane 5 pas forcément en raport avec le probleme qu'il y a effectivement eu, et de plus j'ai mis le numero 5 au hasard, je ne sais pas si c'est ce numéro d'ariane qui a pété. Je voulais enfait simplement dire qu'il y avait certaines utilisations de programmes où on veut que l'éxécution ne plante jamais (j'aurais pu prendre l'exemble d'un airbus, ou bien d'un robot d'hopital).
    Effectivement, j'ai oublié les tableaux, merci de l'avoir précisé.

    Citation Envoyé par kromartien Voir le message
    Les listes sont GROSSO MODO des tableaux, non ?
    A l'énorme difference pret qu'une case d'un tableau est accessible en temps constant, alors qu'un élément d'une liste est accessible en temps linéaire en moyenne (il faut parcourir toute la liste pour aller jusqu'au dernier élément). Toi qui a l'air de t'interesser à l'algorithmique, tu devrais savoir ça.

  9. #29
    Membre émérite

    Inscrit en
    juin 2006
    Messages
    1 116
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : juin 2006
    Messages : 1 116
    Points : 976
    Points
    976

    Par défaut

    Citation Envoyé par nonpoluant Voir le message
    A l'énorme difference pret qu'une case d'un tableau est accessible en temps constant, alors qu'un élément d'une liste est accessible en temps linéaire en moyenne (il faut parcourir toute la liste pour aller jusqu'au dernier élément). Toi qui a l'air de t'interesser à l'algorithmique, tu devrais savoir ça.
    Merci pour cette information, cependant je ne suis pas trop au fait de l'implémentation des objets dans Ocaml. C'est peut être pour ça que je m'interrogeais sur la différence liste/tableau. Je suppose que les listes en Ocaml sont les listes chaînées du C, ceci expliquant cela.

  10. #30
    Membre émérite

    Inscrit en
    juin 2006
    Messages
    1 116
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : juin 2006
    Messages : 1 116
    Points : 976
    Points
    976

    Par défaut

    Citation Envoyé par GnuVince Voir le message
    Pour un débutant, je suggère toujours Scheme. J'ai expliqué mes raisons sur mon blog: http://gnuvince.wordpress.com/2008/0...ommend-scheme/

    Pour ce qui est de la documentation majoritairement en anglais, je pense que n'importe quel développeur qui n'est pas assez fort en anglais pour lire un ouvrage de programmation devrait commencer par suivre un cours d'anglais avant d'apprendre un autre langage de programmation.
    Scheme et Caml sont tous les deux apprentés à Lisp, contrairement à Haskell, d'après ce cours.

    Est-ce que cette parenté n'est pas suffisante pour pouvoir aussi bien adopter Ocaml que Scheme comme premier langage ?

    Concernant Haskell, je suis assez d'accord quant à sa difficulté au premier abord.
    J'ai essayé Haskell il y a peu à partir d'un des tuto de http://www.developpez.com , et j'ai tout de suit abandonné, car le premier exemple était une suite de fibonacci sur une ligne (voir ce cours). Je ne voulais pas continuer à me casser les dents là dessus, parce que c'était clairement au dessus de mes moyens, et comme j'avais le choix entre Haskell et Ocaml j'ai opté logiquement pour un essai à Ocaml.

    Je trouve Ocamll bien plus convivial, personnellement. J'ai trouvé pas mal de cours intéressants sur le net :

    Scheme me paraît un peu limité, j'ai l'impression que Ocaml est plus générique (bien que mon seul objectif est d'apprendre la programmation fonctionnelle, je pense que plus tard le système d'objet d'Ocaml peut m'être profitable sur le plan de la réflexion générale du programmeur, etc). Enfin, Scheme me paraît certainement plus ésotérique dans le sens qu'il paraît largement comme un langage d'enseignement et peu étendu à d'autres fonctionnalités (je pense que Ocaml est plus riche en bibliothèques externes, il a un compilateur, etc).

    Un point de vue plus personnel :

    Un mauvais argument selon toi, c'est le manque de ressources en français pour scheme. Ça ne me gène pas de devoir lire un peu l'anglais, mais bon Ocaml est un beau produit de la recherche française, pourquoi se géner ?

    Je veux dire que je suis plus content de voir des papier de chercheurs français sur Ocaml (exemple en suivant ce lien) , que de devoir lire des introduction en anglais de professeurs que je risque de ne jamais rencontrer et avec qui j'ai si peu de points communs, au moins par le cursus et la formation universitaire (Je connais assez peu le système d'enseignement aux états unis). Enfin, c'est mon point de vue actuellement, il n'est pas limitatif.

    Le dernier point pour ne pas avoir choisi Scheme, c'est le fait que je l'ai essayé il y a plus longtemps, et que, ayant échoué à saisir la syntaxe, j'ai abandonné, remettant le projet d'apprendre la programmation fonctionnelle à plus tard. Je l'avais donc d'emblée rayé de ma liste avant de commencer. (Ceci dit, cela me fait penser que je pourrai aussi bien reprendre Scheme, si il s'agit uniquement de faire de la programmation fonctionnelle à titre éducatif, il paraît indiqué).

  11. #31
    Membre chevronné
    Avatar de GnuVince
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2004
    Messages
    679
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2004
    Messages : 679
    Points : 774
    Points
    774

    Par défaut

    Citation Envoyé par kromartien Voir le message
    Scheme et Caml sont tous les deux apprentés à Lisp, contrairement à Haskell, d'après ce cours.

    Est-ce que cette parenté n'est pas suffisante pour pouvoir aussi bien adopter Ocaml que Scheme comme premier langage ?
    O'Caml ressemble plus à Haskell qu'à Lisp. Et beaucoup des points que je mentionne concernant Haskell s'appliquent à OCaml:

    • Le typage est statique, comme Haskell (mais en un peu moins compliqué, car moins flexible.) Je tiens à répéter que je ne suis pas contre le typage statique: j'ai définitivement appris à l'apprécier cette année. Mais le fait reste qu'un système de typage statique est plus complexe qu'un système de typage dynamique et apprendre et comprendre ce système n'a rien à voir avec l'apprentissage de la programmation fonctionnelle.
    • La syntaxe: la syntaxe de OCaml est, à mon avis, barroque. Plus encore que celle de Haskell (remarquez que c'est subjectif, donc pas besoin de débattre là dessus.) La syntaxe de Scheme est très simple à apprendre et l'étudiant peut se concentrer sur la compréhension du paradigme plutôt que sur le placement d'un point-virgule.
    • OCaml n'est pas un langage paresseux comme Haskell, donc c'est un point en sa faveur ici.
    • Environnement: tuareg-mode n'est définitivement pas aussi "user-friendly" que DrScheme.
    • Litérature: le nombre d'ouvrages disponibles gratuitement (voir message de garulfo plus haut) pour Scheme est impressionnant. OCaml ne possède pas autant de documentation. Par contre, j'ai vu plusieurs références sur OCaml en français, ce qui pourrait aider les gens unilingues (remarque que je suggère *fortement* de posséder une solide connaissance de l'anglais.)

  12. #32
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 130
    Points
    1 130

    Par défaut

    Citation Envoyé par GnuVince Voir le message
    • Le typage est statique, comme Haskell (mais en un peu moins compliqué, car moins flexible.) Je tiens à répéter que je ne suis pas contre le typage statique: j'ai définitivement appris à l'apprécier cette année. Mais le fait reste qu'un système de typage statique est plus complexe qu'un système de typage dynamique et apprendre et comprendre ce système n'a rien à voir avec l'apprentissage de la programmation fonctionnelle.
    Oui et non. Le typage statique sophistiqué est quand même une des grandes victoires des langages fonctionnels dérivés de ML, et dire qu'il n'a "rien à voir" avec la programmation fonctionnelle me paraît excessif.

    Je suis tout à fait d'accord pour dire que Scheme, bien qu'un langage au typage dynamique, est un langage fonctionnel (même si le terme même "langage fonctionnel" peut être un leurre, car c'est plutôt le style des programmeurs qui est fonctionnel ou non, à partir du moment où le langage est assez riche pour laisser le choix : on peut écrire de l'impératif (laid ou non) en Scheme ou OCaml ou Haskell, mais peut-être pas aussi facilement que dans d'autres langages).

    Cependant, je pense que le typage statique à la ML fait partie des outils qu'un programmeur qui s'intéresse à la programmation fonctionnelle, de même que le filtrage de motif. C'est d'ailleurs la raison pour laquelle j'ai une préférence pour OCaml pour débuter (même si Scheme reste un bon choix) : il donne de solides bases dans ce domaine, ce qui peut se révéler un avantage de taille pour aborder bien d'autres domaines, fonctionnels ou non; par exemple, quand on est familier avec l'idée des types, on accepte naturellement la notion d'interface, qui joue aussi un rôle déterminant en Programmation Orientée Objet.

  13. #33
    Membre éprouvé Avatar de KindPlayer
    Inscrit en
    février 2007
    Messages
    471
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 471
    Points : 440
    Points
    440

    Par défaut

    Citation Envoyé par kromartien Voir le message
    Scheme et Caml sont tous les deux apprentés à Lisp, contrairement à Haskell, d'après ce cours.

    Est-ce que cette parenté n'est pas suffisante pour pouvoir aussi bien adopter Ocaml que Scheme comme premier langage ?

    Concernant Haskell, je suis assez d'accord quant à sa difficulté au premier abord.
    J'ai essayé Haskell il y a peu à partir d'un des tuto de http://www.developpez.com , et j'ai tout de suit abandonné, car le premier exemple était une suite de fibonacci sur une ligne (voir ce cours). Je ne voulais pas continuer à me casser les dents là dessus, parce que c'était clairement au dessus de mes moyens, et comme j'avais le choix entre Haskell et Ocaml j'ai opté logiquement pour un essai à Ocaml.

    Je trouve Ocamll bien plus convivial, personnellement. J'ai trouvé pas mal de cours intéressants sur le net :

    Scheme me paraît un peu limité, j'ai l'impression que Ocaml est plus générique (bien que mon seul objectif est d'apprendre la programmation fonctionnelle, je pense que plus tard le système d'objet d'Ocaml peut m'être profitable sur le plan de la réflexion générale du programmeur, etc). Enfin, Scheme me paraît certainement plus ésotérique dans le sens qu'il paraît largement comme un langage d'enseignement et peu étendu à d'autres fonctionnalités (je pense que Ocaml est plus riche en bibliothèques externes, il a un compilateur, etc).

    Un point de vue plus personnel :

    Un mauvais argument selon toi, c'est le manque de ressources en français pour scheme. Ça ne me gène pas de devoir lire un peu l'anglais, mais bon Ocaml est un beau produit de la recherche française, pourquoi se géner ?

    Je veux dire que je suis plus content de voir des papier de chercheurs français sur Ocaml (exemple en suivant ce lien) , que de devoir lire des introduction en anglais de professeurs que je risque de ne jamais rencontrer et avec qui j'ai si peu de points communs, au moins par le cursus et la formation universitaire (Je connais assez peu le système d'enseignement aux états unis). Enfin, c'est mon point de vue actuellement, il n'est pas limitatif.

    Le dernier point pour ne pas avoir choisi Scheme, c'est le fait que je l'ai essayé il y a plus longtemps, et que, ayant échoué à saisir la syntaxe, j'ai abandonné, remettant le projet d'apprendre la programmation fonctionnelle à plus tard. Je l'avais donc d'emblée rayé de ma liste avant de commencer. (Ceci dit, cela me fait penser que je pourrai aussi bien reprendre Scheme, si il s'agit uniquement de faire de la programmation fonctionnelle à titre éducatif, il paraît indiqué).
    La syntaxe de scheme est pourtant relativement simple, mais c'est vrai un peu déroutante au premier abord. Je ne connais pas bien Caml mais la syntaxe est sans doute un peu plus "parlante". L'avantage de la syntaxe de scheme c'est qu'on peut difficilement faire des erreurs de syntaxe justement, donc ça peut etre pas mal pour débuter. Le désavantage, c'est qu'un programme scheme devient très rapidement illisible. Une fonction d'une dizaine de lignes est déjà assez pénible à lire si on a pas fait quelques commentaires.
    La science est ce que nous comprenons suffisamment bien pour l'expliquer à un ordinateur. L'art, c'est tout ce que nous faisons d'autre.
    Donald E. Knuth

  14. #34
    Membre chevronné

    Inscrit en
    juillet 2008
    Messages
    228
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 228
    Points : 641
    Points
    641

    Par défaut

    ML est peut-etre un descendant de Lisp, mais OCaml en est assez eloigne, au contraire de Scheme.

    La syntaxe de base de Scheme est ultra-simple, il faut juste s'habituer un peu a toutes les parentheses. Un bon editeur devrait aider.

  15. #35
    Membre émérite Avatar de HanLee
    Profil pro
    Inscrit en
    mai 2004
    Messages
    738
    Détails du profil
    Informations personnelles :
    Âge : 27
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2004
    Messages : 738
    Points : 859
    Points
    859

    Par défaut

    Citation Envoyé par GnuVince Voir le message
    [*] Environnement: tuareg-mode n'est définitivement pas aussi "user-friendly" que DrScheme.
    Tu as vu ça ?
    http://ocaml.eclipse.ortsa.com:8480/ocaide/

  16. #36
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 130
    Points
    1 130

    Par défaut

    Citation Envoyé par bredelet Voir le message
    ML est peut-etre un descendant de Lisp, mais OCaml en est assez eloigne, au contraire de Scheme.

    La syntaxe de base de Scheme est ultra-simple, il faut juste s'habituer un peu a toutes les parentheses. Un bon editeur devrait aider.
    ML n'est pas à strictement parler un descendant de Lisp, même si les auteurs ont sûrement été influencés par Lisp qui est certainement le premier langage utilisé à s'être déclaré "fonctionnel". Cependant, il faut aussi noter que ML a eu dès sa naissance des bases théoriques plus solides que Lisp (car le binding dynamique utilisé par les premiers lisps ne correspond pas du tout au lambda calcul); Scheme corrige la tendance (avec un binding statique) mais il ne faudrait pas pour autant considérer automatiquement les lisps comme "supérieurs" (je ne dis pas que quelqu'un le fait, je dis qu'il ne faut pas le faire).

    Je pense que les discussions sur la syntaxe sont hors-sujet. La syntaxe lisp a ses avantages et ses inconvénients, tout comme les syntaxes plus structurées comme celles de OCaml ou Haskell, mais c'est une question de préférence personnelle et je pense que ça ne change rien pour le débutant. De toute façon (qu'il débute en programmation ou qu'il vienne du pot-pourri C/C++/C#/Java/PHP) la syntaxe sera plutôt déroutante pour lui, mais ce n'est de loin pas le plus important. La sémantique, la découverte de la programmation ou l'adaptation à un nouveau modèle de pensée seront bien plus déterminants que les détails syntaxiques qui n'ont, dans le fond, pas grande importance quand on apprend.

  17. #37
    Membre du Club
    Inscrit en
    août 2008
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : août 2008
    Messages : 47
    Points : 52
    Points
    52

    Par défaut

    C'est vrai que OCaml est très soutenu par la recherche française. Mais mon avis est que dans tous les domaines de recherche, même si la derniere pierre d'une trouvaille, ou bien une avancé significative, peut-être fait par une équipe de recherche isolée, le concepte fini (qui ne l'est jamais vraiment d'ailleur) est quasiment toujours le fruit d'une étroite colaboration entre tous les chercheurs de tous les pays du monde.

    Citation Envoyé par HanLee Voir le message
    J'utilise ce greffon eclipse, pour OCaml, mais j'ai un peu de mal, surtout en ce qui concerne la compilation, je n'arrive pas à trouver comment compiler mes programmes en incluant des bibliothes, etc... bref faire de la compilation "compliqué" quoi.

  18. #38
    Membre chevronné

    Inscrit en
    juillet 2008
    Messages
    228
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 228
    Points : 641
    Points
    641

    Par défaut

    Citation Envoyé par nonpoluant Voir le message
    C'est vrai que OCaml est très soutenu par la recherche française. Mais mon avis est que dans tous les domaines de recherche, même si la derniere pierre d'une trouvaille, ou bien une avancé significative, peut-être fait par une équipe de recherche isolée, le concepte fini (qui ne l'est jamais vraiment d'ailleur) est quasiment toujours le fruit d'une étroite colaboration entre tous les chercheurs de tous les pays du monde.
    Il me semble que OCaml est assez diffuse dans le monde. Par exemple, il est liste sur http://www.langpop.com/
    (bien qu'il vienne loin apres Scheme).

    La tendance semble s'orienter vers Haskell, Scala et F#. Mais ca ne veut pas dire que les "vieux" langages sont depasses.

  19. #39
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro
    Inscrit en
    juin 2007
    Messages
    1 578
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 578
    Points : 2 712
    Points
    2 712

    Par défaut

    Citation Envoyé par Wachter
    Si on veut se lancer dans la programmation fonctionnelle, que recommandez-vous comme langage fonctionnel
    C'est surtout une question de préférences et d'orientation, tu peux utiliser une grille de lecture simple comme celle-ci :
    • le plus Java/JVM → Scala
    • le plus Windows/C#/.Net → F#
    • le plus 'performant' → OCaml
    • le plus 'pur' → Haskell
    • le plus 'expérimental' → Scheme
    • le plus 'télécoms' → Erlang

    C'est forcément caricatural, mais ça évite de te tromper complètement.
    (c'est pas la peine de te conseiller Haskell si plus tard tu nous dis que c'est pour faire du Silverlight)
    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.

  20. #40
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 308
    Points
    1 308

    Par défaut

    Le plus Python/Ruby/Perl → Common Lisp

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
  •