Journal Choix d'un langage de programmation

Posté par  .
Étiquettes : aucune
0
9
juil.
2003
Salut,

Je travaille actuellement sur un projet divisé en deux modules :
- un noyau en C++ contenant des primitives de calculs (opérations sur des matrices, calcul vectoriel, ...) ;
- une surcouche dans un langage de haut niveau appelant les primitives C++.

La question est donc la suivante : Quel langage de haut niveau choisir sachant qu'il doit être fonctionnel (la surcouche implémente des équations physiques, donc fonctionnelles), si possible objet et surtout capable de communiquer efficacement avec des bibliothèques en C++ ?

La notoriété du langage n'est pas très importante mais constitue tout de même un plus. Par contre l'idéal serait qu'il soit portable.

Je connais bien l'OCaml et il semble bien répondre à mes besoins. La seule limite concerne apparement ( mais je ne suis pas trop sur car j'ai regardé rapidement la doc ) la communication C++ qui n'existe pas (en fait il ne sait communiquer qu'avec du C). Est-ce exact ?

Qu'en est-il des autres langages de haut niveau : ruby (connait pas du tout), python (pas fonctionnel), java (nan jdéconne ;-) ?

Merci
  • # Re: Choix d'un langage de programmation

    Posté par  . Évalué à 4.

    python (pas fonctionnel)

    heu... je ne dit pas que c'est un language fonctionnel complet mais il apporte des possibilités dans ce sens avec les fonctions anonymes (lambda) et les méthodes map, apply, reduce et d'autres techniques de sioux que j'ai dû oublier.

    regarde ces articles :
    http://www-106.ibm.com/developerworks/linux/library/l-prog.html(...)
    http://www-106.ibm.com/developerworks/linux/library/l-prog2.html(...)

    quand à l'intégration avec c++, python est bien un langage à objets et il me semble que swig n'est pas méchant à utiliser et y'a toujours d'autres wrappers qui existent.
  • # Re: Choix d'un langage de programmation

    Posté par  . Évalué à 2.

    Lambda-Prolog rulez!!!

    _____________
    Ceci est un commentaire provenant d'un prolog-addict en phase terminale.
    Il n'implique que son auteur.
    Merci de votre compréhension.

    "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

  • # Re: Choix d'un langage de programmation

    Posté par  . Évalué à 5.

    >python (pas fonctionnel)
    pas du tout, efface.

    plus sérieusement, il semblerait (jamais essayé, mais lu des trucs à droite à gauche) que python puisse s'en sortir question programmation fonctionnelle.

    Si c'est pour une utilisation "scientifique", tu peux jeter un oeil sur http://www.python.org,(...) il y a pas mal de retour de gens qui utilisent python comme glue entre différentes libs de calcul en C, en fortran...
    pour reprendre tes points:
    -portabilité: pas de problème, ça doit même tourner sur plus de plate-formes que Ocaml
    -objet: pas de problème, python est fait (entre autres) pour ça
    -communication avec C++:de base oui, même si traditionnellement les modules python sont plutôt écrits en C. Les bibliothèques boost.python ou swig semblent aplanir certaines difficultés propres à la communication python/c++.

    >java (nan jdéconne ;-)
    tu m'étonne... à moins que ça ait changé depuis deux ans, j'ai testé JNI et c'est vraiment beurk (et pas portable du tout)

    voila pour mes deux centimes...
    • [^] # Re: Choix d'un langage de programmation

      Posté par  . Évalué à 2.

      Python me parait pas mal en effet, surtout avec l'utilisation du lambda. Mais ce que je veux absolument ne pas avoir c'est la notion de variable ou emplacement mémoire (exit pointeurs, références, ...). Je m'explique, j'aimerais éviter ce type d'instruction (un classique) :

      x = x + 1;

      qui n'a en effet aucun sens en mathématiques. OCaml et tous les langages fonctionnels en général satisfont cette contrainte et permettent d'écrire des équations et des algorithmes très facilements (sans le "bruit" induit par des langages impératifs comme le C). Je désire donc que le langage utilisé s'adapte au modèle codé et non l'inverse.
    • [^] # Re: Choix d'un langage de programmation

      Posté par  (site web personnel) . Évalué à 2.

      >java (nan jdéconne ;-) tu m'étonne... à moins que ça ait changé depuis deux ans, j'ai testé JNI et c'est vraiment beurk (et pas portable du tout) JNI ça marche pas mal du tout. Je l'ai encore utilisé dernièrement pour "wrapper" une librairie C++ en Java et ça fonctionne nickel. A côté de ça, non ce n'est pas portable et c'est normal : JNI fait le lien entre une librairie native et du code Java, donc, à moi que la librairie n'existe sur plusieurs plateformes, ça ne peut évidemment pas tourner sur une autre plateforme que celle qui contient la librairie native ...
  • # Re: Choix d'un langage de programmation

    Posté par  . Évalué à 1.

    Je te conseil l'Ada.
  • # Re: Choix d'un langage de programmation

    Posté par  (site web personnel) . Évalué à 4.

    Tout dépend de ce que tu appelles haut-niveau...
    C++, j'apelles ça déjà du haut-niveau.
    sinon du perl :)
    • [^] # Re: Choix d'un langage de programmation

      Posté par  . Évalué à 2.

      Bon ok alors du très haut niveau ;-)

      Comme je l'ai expliqué plus haut, je cherche un langage s'adaptant au problème plutôt que d'adapter le problème au langage. (ce qui n'est pas le cas du C)
      • [^] # Re: Choix d'un langage de programmation

        Posté par  . Évalué à 0.

        Mais pourquoi ne pas utiliser le Perl comme le dit si bien Pooly? ------------------- Attention, thread 100% INSA (50% Rouen / 50% Rennes)

        "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

  • # Re: Choix d'un langage de programmation

    Posté par  (site web personnel) . Évalué à 2.

    Je connais bien l'OCaml et il semble bien répondre à mes besoins.

    toutafé

    La seule limite concerne apparement ( mais je ne suis pas trop sur car j'ai regardé rapidement la doc ) la communication C++ qui n'existe pas (en fait il ne sait communiquer qu'avec du C). Est-ce exact ?

    Oui. Mais ça ne veut pas dire que tu ne peux pas interfacer ton bazar, seulement il faut que tu encapsules les méthodes que tu veux utiliser dans une fonction. Il faut aussi faire gaffe aux exceptions C++ (les convertir en exceptions ocaml).
    • [^] # Re: Choix d'un langage de programmation

      Posté par  . Évalué à 1.

      Est-il possible d'instancier des objets C++ depuis caml ?
      • [^] # Re: Choix d'un langage de programmation

        Posté par  (site web personnel) . Évalué à 3.

        toujours pareil, il faut passer par une fonction. -- a.ml -- type truc external new_truc : unit -> truc = "ml_new_truc" -- a_stub.c -- CAMLprim value ml_new_truc(value unit) { Truc *t = new Truc; value v; v = alloc_small(1, Abstract_tag); Field(v, 0) = t; return v; } Un truc comme ça.
  • # Re: Choix d'un langage de programmation

    Posté par  . Évalué à 2.

    C'est difficile de répondre sans prêcher pour sa paroisse :)

    J'ai déjà fait des appels à une bibliothèque de calcul matriciel en C++ à partir de servlets Java. Tout ce que je peux dire c'est que l'encapsulation JNI est assez facile à réaliser. Enfin il vaut mieux avoir de bonnes connaissances en Java quand même et un minimum en C++ pour le wrapper.

    cf le tutorial http://java.sun.com/docs/books/tutorial/native1.1/index.html(...)
    Et bon courage !
  • # Re: Choix d'un langage de programmation

    Posté par  . Évalué à 10.

    Interview de Bjarn Stroustrup (le créateur du C++)
    les vrais raisons du C++


    Interviewer : Cela fait quelques années maintenant que vous avez change le monde de la conception logicielle, qu'est-ce cela vous fait en regardant en arrière ?

    Stroustrup : En fait, je repensais à cette époque juste avant que vous
    n'arriviez. Vous vous souvenez ? Tout le monde écrivait en C et le
    problème était qu'ils étaient vachement bons. Les universités dispensaient
    également un bon enseignement du C. Elles produisaient des diplômes
    compétents - et j'insiste sur le mot compétent. Et c'est ce qui a pose
    problème.

    Interviewer : Problème ?

    Stroustrup : Oui, problème. Vous vous souvenez du temps ou tout le monde
    écrivait en COBOL ?

    Interviewer : Bien sur, j'ai moi-même écrit en COBOL.

    Stroustrup : Et bien au début ces gars étaient des demi-dieu. Leurs
    salaires étaient élevés et ils étaient traités comme des princes.

    Interviewer : C'etait l'bon temps, hein ?

    Stroustrup : Hé oui. Et qu'est-ce qu'il s'est passe ? IBM en a eu marre,
    et a investi des millions dans la formation de programmeurs COBOL, jusqu'a
    ce qu'ils ne valent qu'une bouchée de pain pour une douzaine.

    Interviewer : C'est la que j'ai quitte ce métier. Les salaires ont chuté
    en moins d'un an, au point que cela payait plus d'être journaliste.

    Stroustrup : Exactement. Et la même chose est arrive aux programmeurs en
    'C'.

    Interviewer : Je vois, mais ou voulez-vous en venir ?

    Stroustrup : Et bien, un jour j'étais à mon bureau et j'ai conçu un petit
    stratagème qui pourrait retourner un peu la situation. Je pensais : 'je me
    demande ce qu'il se passerait s'il existait un langage si complique, si
    difficile a apprendre que personne ne pourrait jamais inonder la marche de
    programmeurs ? ' En fait, une partie de ces idées viennent de X10, vous
    savez, XWindows. C'etait un système graphique si complique que cela ne
    tournait que sur ces choses Sun3/60. Tous les ingrédients que je voulais
    étaient présents : une syntaxe ridiculement complexe, des fonctions
    obscures, et une structure pseudo orientee-objet. Même maintenant,
    personne n'écrit du code X-Windows. Motif est le seul moyen de coder sans
    perdre sa raison.

    Interviewer : Vous n'êtes pas sérieux ?

    Stroustrup : Bien au contraire. En fait, il y avait un autre problème.
    Unix était écrit en 'C', ce qui signifie que tout programmeur 'C' pouvait
    facilement devenir programmeur système. Vous vous souvenez de ce qu'un
    programmeur de mainframe avait pour habitude de gagner ?

    Interviewer : Bien sur, c'était aussi mon type de salaire.

    Stroustrup : OK, donc ce nouveau langage devait se séparer d'Unix, en
    masquant tous les appels qui liaient les deux si élégamment. Cela
    permettrait aux gars qui ne connaissent que le DOS de gagner de nouveau
    correctement leur vie.

    Interviewer : Je ne peux pas croire que vous ayez dit cela.

    Stroustrup : Bah, cela fait longtemps maintenant, et je suppose que la
    plupart des gens se sont rendus compte par eux-même que le C++ est une
    perte de temps, mais je dois dire que cela a pris plus de temps que je ne
    l'aurais cru.

    Interviewer : Alors, comment exactement vous vous y-êtes pris ?

    Stroustrup : C'etait suppose être une blague, jamais je n'aurais cru que
    les gens prendrait le bouquin au sérieux. N'importe qui avec 2 grammes de
    bon sens peut voir que la programmation orientée-objet est
    contre-intuitive, illogique et inefficace.

    Interviewer : Quoi ?!

    Stroustrup : Et concernant le 'code réutilisable'!... Vous avez déjà
    entendu d'une compagnie qui a jamais réutilise du code ???

    Interviewer : En fait,... jamais, mais...

    Stroustrup : Hé ben voila. Je ne dis pas que quelques uns n'aient pas
    essaye au début. Il y avait cette compagnie d'Oregon - je crois qu'elle
    s'appelait Mentor Graphics - qui s'est vraiment fait une belle frayeur en
    essayant de tout réécrire en C++ dans les années 1990 ou 1991. J'en suis
    désolé pour eux, vraiment, mais je pensais que les gens en auraient tire
    des leçons.

    Interviewer : Manifestement, ils ne l'ont pas fait ?

    Stroustrup : Pas le moins du monde. Le problème, c'est que la plupart des
    compagnies ont du étouffer leurs échecs majeurs, et que expliquer des
    pertes de 30millions de $ a leurs actionnaires aurait été difficile.
    Cependant, rendons leur crédit, c'est eux qui ont permis que cela marche
    en fin de compte.

    Interviewer : Ha oui ? Et bien vous voyez, l'oriente-objet, cela marche !

    Stroustrup : Moui presque. L'exécutable était si énorme qu'il mettait 5
    minutes a se charger sur des HP avec 128Mo de RAM. Il tournait si
    lentement. En fait, je pensais que cela serait un obstacle rédhibitoire,
    et je me suis rendu compte en moins d'une semaine que tout le monde s'en
    foutait. SUN et HP n'étaient que trop content de vendre des ordinateurs
    d'une puissance énorme, dotées d'immenses ressources juste pour faire
    tourner des programmes triviaux. Vous savez, lorsque l'on a eu notre
    premier compilateur C++ chez AT&T, j'ai compile le programme 'Hello
    World', et je ne pouvais pas croire la taille de l'exécutable: 2.1 Mo.

    Interviewer : Quoi ? Les compilateurs ont fait du chemin depuis.

    Stroustrup : Vraiment ? Essayez donc avec la dernière version de g++. La
    différence n'excédera pas 0.5Mo. De plus, j'ai plusieurs exemples récents
    pour vous, et ce depuis tout pays. British Telecom s'est retrouvé avec un
    désastre entre les mains, mais par chance, ils ont pu tout effacer et
    repartir de zéro. Et ils ont eu plus de chance que Australian Telecom.

    Aujourd'hui, j'apprends que Siemens construit une usine a gaz, et
    s'inquiète de la taille croissante du matériel afin de pouvoir y faire
    tourner les exécutables. Est-ce que l'héritage multiple n'est pas
    merveilleux ?

    Interviewer : Oui, mais C++ est à la base un langage solide.

    Stroustrup : Vous en êtes vraiment convaincu, n'est-ce pas ? Avez-vous
    déjà participe à un projet C++ ? Voila ce qui se passe: d'abord, j'y ai
    introduit suffisamment de piège pour être sur que seuls les projets les
    plus simples fonctionneront la première fois. Considérez la surcharge des
    opérateurs. A la fin du projet, tous les modules l'ont utilise, surtout
    parce que les gars ont pense qu'ils devaient le faire, comme pendant leur
    formation. Le même opérateur qui signifie complètement autre chose d'un
    module a l'autre. Essayez de rassembler tout cela lorsque vous avez une
    centaine de module environ. Quant a l'encapsulation de données, mon Dieu,
    parfois je ne peux m'empêcher de rigoler lorsque j'entends parler des
    problèmes qu'ont des compagnies pour faire communiquer leurs modules. Je
    pense que le mot 'synergie' a été invente pour remuer le couteau dans la
    plaie des manager de projet.

    Interviewer : Je dois avouer que tout cela commence à me troubler. Vous
    dites que vous avez fait tout cela juste pour augmenter le salaire des
    programmeurs ? C'est choquant !

    Stroustrup : Pas vraiment. Tout le monde a le choix. Je ne m'attendais pas
    a ce que cela soit si incontrôlable. De toute façons, j'ai en gros réussi.
    C++ est en train de passer de mode, et les programmeurs ont toujours des
    salaires élevés, surtout ces pauvres diables qui doivent maintenir toute
    cette merde. Vous réalisez bien sur qu'il est impossible de maintenir un
    gros programme C++ si vous ne l'aviez pas vous-même écrit

    Interviewer : Et pourquoi donc ?

    Stroustrup : Vous êtes vraiment hors du coup, pas vrai ? Vous vous
    souvenez du typedef ?

    Interviewer : Oui, bien sur.

    Stroustrup : Vous souvenez-vous du temps qu'il vous fallait pour explorer
    les fichiers de déclaration de fonction avant de vous rendre compte que
    'RoofRaised' était un double ? Alors, imaginez le temps que cela prend
    pour traduire tous les typedef implicites de toutes les classes d'un
    projet important en C++ !

    Interviewer : Alors, en quoi reconnaissez-vous avoir réussi ?

    Stroustrup : Rappelez-vous de la durée moyenne d'un projet en 'C' :
    environs 6 mois. Pas assez longtemps pour gagner correctement sa vie pour
    un gars marie avec enfants. Prenez le même projet, concevez-le en C++ et
    qu'est-ce que vous obtenez ? Je vais vous le dire : un a deux ans. C'est
    pas super, ça ? Toute cette sécurité de l'emploi a cause d'une erreur de
    jugement. Et autre chose : les universités n'ont pas enseigne le 'C'
    depuis si longtemps qu'il y a maintenant pénurie de programmeurs valables
    en 'C'. Surtout concernant ceux qui y connaissent quelque chose sur la
    programmation système Unix. Combien de gars saurait quoi faire avec un
    'malloc', alors qu'ils utilisent 'new' ces dernières années, et ce sans
    jamais vérifier le code de retour ? En réalité, la plupart des
    programmeurs C++ ignorent complètement leur code de retour. Qu'est-ce qui
    est arrive au bon vieux '-1'? Au moins, vous saviez que vous aviez une
    erreur, sans tout emberlificoter dans des 'throw' et 'try'.

    Interviewer : Mais a l'évidence, l'héritage fait gagner du temps ?

    Stroustrup : Vraiment ? Avez-vous remarque la différence entre un planning
    de projet 'C' et 'C++' ? La phase de planning d'un projet C++ est trois
    fois plus longue. Et justement pour s'assurer que tout ce doit être dérivé
    l'est, et ce qui ne doit pas l'être ne l'est pas. Et en plus, ils se
    gourent. Qui a entendu parler de 'fuites mémoire' en 'C' ? Maintenant, on
    les trouve dans les plus grandes industries. La plupart des compagnies
    abandonnent et commercialisent leurs produits en sachant qu'ils fuient
    comme des passoires, simplement pour éviter le coût de débuguer toutes ces
    fuites.

    Interviewer : Il y a des outils...

    Stroustrup : La plupart d'entre eux ont été écrit en C++ !

    Interviewer : Si on publie cela, vous serez probablement lynche , vous le
    savez, non ?

    Stroustrup : Ca m'étonnerait. Comme je vous l'ai dit, C++ est maintenant
    sur son déclin, et aucune compagnie sensée ne commencerait un projet sans
    un prototype. Cela devrait suffire à les convaincre de la nature
    désastreuse de cette voie. Sinon, ils mériteront ce qu'il leur arrivera.
    Vous savez, j'ai essaye de convaincre Dennis Ritchie de réécrire Unix en
    C++.

    Interviewer : Oh mon Dieu, et qu'est-ce qu'il a dit ?

    Stroustrup : Ben heureusement, il a un bon sens de l'humour. Je pense que
    lui et Brian se sont aperçu très tôt de ce que je faisais, mais ne l'ont
    jamais fait savoir. Il m'a dit qu'il m'aiderait à écrire une version C++
    de DOS, si j'étais intéressé.

    Interviewer : Et vous l'étiez ?

    Stroustrup : En fait, j'ai écrit DOS en C++. Je vous donnerai une demo
    après. Je le fais tourner sur un Sparc20 dans la salle des ordinateurs. Ca
    tourne comme une flèche sur 4 CPU, et cela ne prends que 70Mo sur le
    disque.

    Interviewer : Et-ce que cela tourne comme sur un PC ?

    Stroustrup : La vous blaguez. Avez-vous déjà vu Windows95? Je le considère
    comme un de mes plus gros succès. Ca a même failli tout arrêter avant que
    je ne sois prêt.

    Interviewer : Vous savez, cette idée de Unix++ m'avait vraiment fait
    réfléchir. Il y a des gars quelque part qui sont en train d'essayer de le
    faire. [en fait, le ?-kernel L4 en est un bon exemple...]

    Stroustrup : Non, pas après cette interview !

    Interviewer : Je suis désolé, mais je ne nous vois pas capable de publier
    quoique ce soit de cela.

    Stroustrup : Mais c'est l'histoire du siècle ! Je veux juste être
    considère par mes collègues programmeurs pour ce que je leur ai apporte.
    Savez-vous combien peut toucher un programmeur C++ ces jours-ci?

    Interviewer : D'après ce que j'ai entendu, un vrai pro peut valoir 70 a
    80$ de l'heure.

    Stroustrup : Vous voyez ? Et je parie qu'il les mérite. Tenir compte de
    tous les pièges à con que j'ai introduit dans le C++ n'est pas un job
    facile. Et comme je vous l'ai dit, tous les programmeurs C++ sont comme
    lie par un serment mystique pour employer toutes les fonctionnalités du
    langage dans tous les projets. En fait, cela finit même par m'ennuyer
    parfois, même si cela sert mon but original. J'en finis presque par aimer
    ce langage.

    Interviewer : Vous voulez dire que ne l'aimiez pas avant ?

    Stroustrup : Je le détestais. Il n'est même pas élégant, vous ne trouvez
    pas ? Mais quand les royalties du bouquin ont commence à arriver... vous
    voyez l'idée.

    Interviewer : Attendez une minute... et les références ? Vous devez
    reconnaître que cela représente une amélioration sur le pointeur 'C'.

    Stroustrup : Hmmm, je me suis toujours pose des questions a ce sujet. Au
    début, je pensais que s'en était une. Et puis un jour, j'ai discute avec
    un gars qui avait programme depuis ses débuts en C++. Il me disait qu'il
    ne pouvait jamais se souvenir si ses variables étaient référencées ou
    déréférencées, alors il utilisait toujours les pointeurs. Il disait que le
    petit '*' astérisque l'aidait à se souvenir.

    Interviewer : Et bien, a ce stade je dis généralement 'Merci beaucoup',
    mais cela ne semble pas très approprié.

    Stroustrup : Promettez-moi que vous allez publier cela. Ma conscience
    prend le dessus ces derniers temps.

    Interviewer : Je vous le ferai savoir, mais je pense deviner ce que mes
    éditeurs vont dire.

    Stroustrup : Qui le croirait de toutes façons ? Toutefois, pourriez-vous m'envoyer une copie de cette bande ?

    Interviewer : Oui, je peux faire ça.
  • # Re: Choix d'un langage de programmation

    Posté par  . Évalué à 2.

    J'ai un gros doute sur la pertinance de o'caml complet si tu dois développer le compilo, t'as vraiment besoin du système de modules de ML, des objets, des labels du système de types de ouf ? Si tu ne développes pas le compilo et que tu ne fait que des appels externes tu peux l'utiliser (o'caml) en wrappant le C++ dans du C. Sinon, tu prends un ML plus simple (voir le ML standard, tout simplement) ou un Haskell pas trop traffiqué (qui te mettras un peu plus de puissance dans les doigt sans trop d'efforts). évite les langages dynamiquements typés (python, lisp et ses potes ...), t'as déjà le C++ pour faire baisser la qualité de ton application, ne cumule pas les tares.
  • # Re: Choix d'un langage de programmation

    Posté par  . Évalué à 2.

    Franchement je vois pas l'intérêt. Pourquoi ne pas directement tout faire en C++ ? Parce que se compliquer la vie juste parce qu'on trouve horrible une notation telle que x=x+1, ça me semble pas une bonne raison. Quel genre de problème as-tu à résoudre ? A mon avis, si tu veux faire tes primitives de calcul en C++ tu vas te retrouver à utiliser des templates, tels que valarray, et il n'y a aucun langage capable de s'interfacer avec.
    • [^] # Re: Choix d'un langage de programmation

      Posté par  . Évalué à 2.

      Pourquoi ne pas directement tout faire en C++ ? A chaque problème son langage. Pourquoi des logiciels comme Blender propose d'intégrer des plugin en les codant en Python ? Les raisons d'avoir une couche application codée dans un langage de haut niveau (supérieur à C++) sont nombreuses : - Extension du logiciel : créé des plugins dans ce langage est plus simple que de plonger la tête dans le code source C++ ; - Séparation des fonctionnalités : la bibliothèque C++ d'un coté (pour les perfs) et l'appli caml de l'autre (pour la faciliter de développement) ; - prototypage rapide et debugage facile (langage interprété) ; - syntaxe proche du problème : comme je l'ai déjà dit, le langage s'adapte au problème et non l'inverse ; - du code caml reste beaucoup plus lisible que du code C++ (c'est mon avis personnel ;-) ; - caml est plus facile à apprendre et plus intuitif que le C++ ; - portabilité (disons que moins il y a de code C++, plus le code est facilement portable) ; - caml propose des mécanismes par défaut très pratique, en particulier les flots qui permettent d'écrire des parser en quelques lignes (et comme par hasard mon appli a besoin de parser) En gros pour résumer, la couche application est essentiellement fonctionnele, peut être objet, proche des mathèmatiques (implémentation de modéle). Donc exit le C++, un langage fonctionnel est beaucoup plus adapté.
      • [^] # Re: Choix d'un langage de programmation

        Posté par  . Évalué à 2.

        Je suis d'accord avec la plupart des points que tu abordes, mis à part la portabilité du C++ (en quoi est-il moins portable qu'un autre langage ? il suffit d'utiliser les bibliothèques appropriées) et le fait qu'un langage interprété serait plus facile à débugger et à prototyper (pourquoi ? parce que compiler un programme prend une seconde ou deux ?). Par contre c'est vrai que pour les plugins c'est pas pratique. Heureusement il existe Under C qui est un C++ interprété. Note que je ne l'ai pas essayé mais ça rend la chose faisable.
        • [^] # Re: Choix d'un langage de programmation

          Posté par  . Évalué à 1.

          en quoi est-il moins portable qu'un autre langage ?
          Un programme C++ est moins portable qu'un programme Caml, meme en utilisant les bonnes bibliothèques. Des différences existent entre les compilateurs (certains compilateurs implémentent la norme C++ à leur sauce, dixit MSCV), l'OS utilisé (les appels systèmes ne sont pas identiques d'un système à l'autre), et l'architecture (système 64 et 32bits). Un programme Caml ne necessitera aucune modification pour s'éxecuter alors qu'un programme C++ pourra "peut être" se comporter différement (si vous voulez des exemples j'en ai).


          parce que compiler un programme prend une seconde ou deux ?
          Ce n'est pas vraiment le fait qu'il soit interprété qui est un avantage. Je me suis mal exprimé. J'ai voulu dire qu'un langage fonctionnel facilite le prototypage.

          il existe Under C
          Under C n'implémente pas toute la norme.
      • [^] # Re: Choix d'un langage de programmation

        Posté par  . Évalué à 2.

        - du code caml reste beaucoup plus lisible que du code C++ (c'est mon avis personnel ;-) ; - caml est plus facile à apprendre et plus intuitif que le C++ ; C'est drôle, j'aurais tendance à penser le contraire : qu'un langage impératif est beaucoup plus facile à apprendre car plus intuitif qu'un langage fonctionnel. Et du fait qu'il soit plus intuitif, il n'en est que plus lisible (ok, y'a toujours moyen de coder comme un cochon, qlq soit le langage). Les 'philosophies' qui se cachent derrière les langages non impératifs (fonctionnel, logique, ...) me paraîssent beaucoup plus difficiles à aborder, même si au final les possibilités offertes sont amha beaucoup plus intéressantes.

        "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

        • [^] # Re: Choix d'un langage de programmation

          Posté par  . Évalué à 2.

          qu'un langage impératif est beaucoup plus facile à apprendre car plus intuitif qu'un langage fonctionnel

          C'est vrai que dans un premier temps un débutant en programmation aura plutot tendance à s'orienter vers des programmes impératifs. Pourquoi ? Car les principaux langages sont impératifs, car le fait de donner une suite d'instructions parait plus naturel au premier abord ...

          Mais la logique fonctionnelle est plus proche du raisonnement scientifiques que la logique impérative. L'ordinateur fonctionne suivant une logique impérative, l'homme sur une logique fonctinnelle (les suites en math, les fonctions f(x), les équations, ...). Exprimer des algorithmes est donc beaucoup plus facile et intuitif en fonctionnel qu'en impératif.

          Sur la lisibilité du code, compare le code d'une factorielle en C++ et en Caml. Je crois que d'un point de vue de lisibilité le caml remporte la palme.

          Une dernière chose, pourquoi dans les formations informatiques apprend-t-on souvent au début un langage fonctionnel plutot qu'impératif.
          • [^] # Re: Choix d'un langage de programmation

            Posté par  . Évalué à 2.

            Exprimer des algorithmes est donc beaucoup plus facile et intuitif en fonctionnel qu'en impératif.

            Tout à fait pas d'accord avec toi! Mais sûrement parce que pour moi l'introduction aux langages fonctionnels n'est intervenu que très tard, et j'avais déjà pris beaucoup de réflexes en langage impératif.

            Sur la lisibilité du code, compare le code d'une factorielle en C++ et en Caml. Je crois que d'un point de vue de lisibilité le caml remporte la palme.

            Boarf. Entre une fonction caml avec un match, et une fonction C(++) avec une boucle for, je prefere un prédicat Prolog (/o\ pas taper).

            Une dernière chose, pourquoi dans les formations informatiques apprend-t-on souvent au début un langage fonctionnel plutot qu'impératif.

            [ma_vie]
            INSA de Rouen, 1er cycle (à mon époque, càd en 1998-2000):
            1ere année : C
            2eme année : C++, Java, Fortran
            Les programmes ont changé maintenant, Java est enseigné dès la 1ère année.

            INSA de Rennes, 1er cycle :
            1ere année : Scheme (très mal enseigné)
            2eme année : Java (mal enseigné aussi)
            [ma_vie]

            Même si l'INSA n'est pas la plus grande école d'ingé de France, il reste quand même un bon indicateur de ce qui est enseigné en général.

            Par contre, je ne connais pas le programme de 1er cycle des 3 autres INSA, si y'a des lyonnais, toulousains ou strasbourgeois qui trainent, faites signe!

            "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

            • [^] # Re: Choix d'un langage de programmation

              Posté par  . Évalué à 2.

              Dans pratiquement toutes les facs le premier langage est fonctionnel. Dans les prépas c'est souvent du caml.

              et j'avais déjà pris beaucoup de réflexes en langage impératif.
              Donc il s'agit plus d'une préférence. L'impératif est plus intuitif pour toi car tu as commencé par ça (comme la plupart d'entre nous).
              • [^] # Re: Choix d'un langage de programmation

                Posté par  . Évalué à 2.

                Donc il s'agit plus d'une préférence.

                Quoi quoi quoi? Tu ne sais pas encore que je suis entièrement soumis à la cause Prolog, que je dors avec un pyjama "Logic Programming rulez"? Préférence pour les langages impératifs, kesk'il faut pas entendre...

                L'impératif est plus intuitif pour toi car tu as commencé par ça

                C'est vrai, je l'avoue, j'ai fait mes débuts sur TI-85 (qui utilise une variante de Pascal si mes souvenirs sont bons)...
                Puis il y a eu le C (cool, on peut coder comme un porc!!!), le C++ (trop cool les classes!!!), le Java (et en plus je peux faire des fenêtres avec des boutons!!!), le Fortran (¿gni?)...
                Et mon aversion pour le Caml (jamais rien compris, merci mon binôme qui assurait comme une brute en TP) et la découverte de la programmation logique...

                "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

                • [^] # Re: Choix d'un langage de programmation

                  Posté par  . Évalué à 2.

                  lol, mais t'aurais pas fait l'INSA toi ? bon ok je sors.
                  • [^] # Re: Choix d'un langage de programmation

                    Posté par  . Évalué à 2.

                    'Tain, merde, je m'ai fait démasqué...

                    Il manquerait plus que deux autres insaïens de ma connaissance n'aient posté dans ce journal...

                    "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

      • [^] # Re: Choix d'un langage de programmation

        Posté par  . Évalué à 2.

        Pourquoi ne pas tout faire en Ocaml ? Il me semble que c'est très très rapide quand tu le compile en code natif.
        • [^] # Re: Choix d'un langage de programmation

          Posté par  . Évalué à 1.

          Bonne question. La raison est simple, rapidité. Un code caml même compilé en natif sera plus lent que du C++ (sauf si c'est Gcc ;-). Je ne sais pas, à vérifier, mais AMA ils n'ont pas implémenté toutes les optimisations que l'on trouve dans les compilo modernes. L'idée est donc de faire une bibliothèque de base représentant 30% du code total et 90% du code éxécuté en C++. (stat évaluée à la louche)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.