Bonsoir,

je m’intéresse depuis peu aux langages haskell, ruby et python et je viens ici avec quelque questions auquel je n'ai pas réussi à trouver les réponses.

En fait je me demandais quels avantages pouvait apporter ses langages par rapport au C/C++.

En gros ce qu'il vaut mieux faire en haskell/ruby/python et ce qu'il vaut mieux ne pas faire dans ces même langages? (ce qu'ils font de mieux / moins mieux). J'ai pas réussi à trouver d'information précise à ce sujet...

Si vous pouvez me renseigner, je vous en remercie!

Allez!!!
Personne ne connait ses langages?

Je les connais, mais je n'ai pas d'expérience suffisante en Ruby, Python et Haskell pour te répondre tout à fait objectivement.

Mais ils ne sont pas dédiés à la résolution des mêmes problèmes. Et en celà ils sont différents.

Par exemple, avec Ruby et python, tu gagnes du temps lors de l'écriture du code.
Et avec Haskell, tu as certaines notions intéressantes comme l'évaluation paresseuse, et c'est un langage fonctionnel. On peut faire un tas de choses avec mais le code écrit en revanche sera souvent imbuvable pour la résolution de gros problèmes pour lesquels le langage n'était pas prévu à la base.

Donc tous ces langages ne sont pas plus performants que le C/C++ ou Java, mais en revanche ils sont leurs avantages dans leurs domaines de compétence.
Tout comme tu ne penseras pas au C++ quand tu veux réaliser une appli web --> Php... (je caricature mais l'idée est là)

Tu ne penseras pas au C++ quand tu veux résoudre un problème dont la solution peut s'écrire en langage fonctionnel -> Haskell.

Et tu ne penseras pas au C++ quand tu n'as pas besoin de te préoccuper de la gestion de la mémoire, ou les performances, et que tu veux un code concis et qui exprime uniquement ce qui est nécessaire à exprimer -> Python, Ruby.

Tout comme il y a des langages pour chaque domaine... le Haskell, Ruby, Python, Java, Php, Prolog, COBOL, Fortran, Natural, ASP, Flash, etc ont chacun leur raison d'être. Il ne faut pas forcément les comparer sur les mêmes points.

Bonjour,

Puisque tu insistes, je vais te donner mon avis.

Je commence par Ruby. Ce langage, c'est la fusion de deux idées contradictoire : d'un coté les langages de scripts qui ont pour vocation à fournir un cadre agréable pour faire une suite courte d'actions avec effet de bord (lecture/écriture dans un fichier, …); de l'autre les langages fonctionnels où le but est de séparer la partie effet de bords de la partie calcul, ce qui ne prend réellement son sens que lorsque la quantité de vrai calcul est non négligeable par rapports aux entrées/sorties (et donc surement pas dans un script).

Bref, je trouve que l'idée sous-jacente à Ruby est stupide et que ça donne un langage inutilisable (on pourra s'amuser à chercher quelques unes des incohérences hors du commun dans la syntaxe).

Passons à Python. Là, l'objectif affiché semble être de fournir un langage de programmation simple. Et bien d'expérience, Python c'est tout sauf simple, surtout quand on sait déjà programmer. Il suffit de regarder l'interface fournie pour manipuler les listes Python : insertion en queue (WTF?) mais parcours de la tête à la queue (Mais... WTF???). En prime, coder en Python implique un résultat fondamentalement lent pour diverses raisons.

Donc c'est éventuellement bien pour essayer un algo simple avant de l'implanter dans un langage efficace, mais ça s'arrête là.

Enfin, viens Haskell. Là, tu as devant toi le plus "pur" des langages de programmation fonctionnelle connus. J'entends par là que c'est lui qui sépare le plus la partie calcul de la partie effet de bord. Et c'est là que vient la force du langage :
- Fonctions au premier ordre = une fonction est un objet manipulable au même titre qu'un entier, ce qui permet de faire simplement certaines opérations complexes
- Paresse = un calcul n'est jamais utilisé dans un effet de bord ? ok, on ne fait pas le calcul
- Persistance = quand tu dis "y = <calcul long et compliqué>", le <calcul long et compliqué> sera exécuté qu'au moment où on aura besoin de y dans un effet de bord (pour l'afficher à l'écran par exemple). Ensuite, la valeur sera mémorisée si y est utilisé par la suite, garantissant ainsi que le calcul n'est fait qu'une fois.
- Inférence de Type / Typage statique = pas de ralentissement à cause des vérifications de type à l'exécution du programme, contrairement à Python
- Parallélisation automatique de code = quand c'est possible, gain en performance sans effort coté programmeur

Bien évidemment, tout cela a un coût : la façon de coder est radicalement différente de celle du C/C++ : utilisation des listes en priorité (au lieu des array du C), récursivité à la place des boucles, structures de données différentes de celles de la STL pour s'adapter au fonctionnel pur, etc.

Une autre conséquence de tout ça est qu'il est difficile d'évaluer le temps d'exécution d'un code Haskell (surtout quand le code est parallélisable). En contre-partie, les fonctions sont complétement déterministes (si tu as prouvé que ton code pour une fonction f est juste, alors il restera juste quelque soit le contexte), ce qui facilite la réutilisation de code et la diminution du nombre de bugs.

Bref, si tu as une application du type "lecture de données traitement compliqué sur ces données écriture du résultat", tu peux te tourner vers Haskell qui est un bon compromis entre performances et langage de haut niveau.

« On peut faire un tas de choses avec mais le code écrit en revanche sera souvent imbuvable pour la résolution de gros problèmes pour lesquels le langage n'était pas prévu à la base. » j'espère que cette phrase s'appliquait à Ruby et non à Haskell.
Surtout compte tenu de la quantité de code énorme que tu peux réutiliser aveuglement (cf ma remarque sur le déterminisme des fonctions) en Haskell.

J'ai pas vraiment de bench sous la main, mais Haskell c'est compilé + typage statique, donc ça doit être bien plus rapide que Java.

« Et tu ne penseras pas au C++ quand tu n'as pas besoin de te préoccuper de la gestion de la mémoire, ou les performances, et que tu veux un code concis et qui exprime uniquement ce qui est nécessaire à exprimer » il faut TOUJOURS penser aux performances, même quand ce n'est pas la propriété. Quand à la mémoire, si je ne veux pas la gérer... j'utilise du C++ quand la quantité de mémoire est un facteur à prendre en compte (oui oui, la couche objet et les conteneurs de la STL font qu'on n'a rien à gérer à part écrire un destructeur par classe), et sinon j'utilise Ocaml/Haskell.

Je trouverais intéressant qu'on parle aussi de PERL pour avoir une idée de qqun d'expérimentè. Car personnellement, je trouve qu'avec ce langage, la manipulation de fichier,tableau,regex dans un système Unix est vraiment pas mal (je dis ça car on peut très facilement faire tab = résultat de ma commande).

De avis dessus ?

Chris_27 : je me suis mal exprimé, mais j'ai bâclé mon argumentation en effet.
Pour la performance du langage, pour compléter ma réponse, on ne va évidemment pas volontairement écrire un code lent ou chercher un langage qui comparativement à un autre à de mauvais benchmarks, mais ce que je veux dire est que lorsqu'on cherche avant tout un langage qui convient à un problème donné, il se peut que la solution écrite soit très performante mais qu'elle le soit moins que si elle avait été programmée dans un autre langage.

Et concernant ma critique de Haskell, c'est à prendre pour certains cas de librairies. En effet, quand je navigue sur http://hackage.haskell.org/packages/archive/pkg-list.html , j'y trouve des librairies où je peux naviguer dans le code en ayant une compréhension claire de ce qui se passe, et d'autres où je dois lire les commentaires sans arrêt pour comprendre l'intention du programmeur, et d'ailleurs, la quantité énorme de commentaires de certaines librairies montre bien que sans celà, le programmeur ne s'en sort pas.

Alors, peut-être que je suis tombé sur des librairies où le code n'est pas clair simplement.

vive_cod4: Perl est un très bon langage de script. Il remplit parfaitement le cahier des charges de Ruby, et en prime le langage est cohérent avec l'objectif fixé cette fois.

« on ne va évidemment pas volontairement écrire un code lent » évidemment, non. Mais j'insistais parce que très souvent, on voit des gens qui ne se posent aucunes questions, et qui finissent avec du code clairement lent.

Quant aux librairies Haskell, j'aurais du ne pas effacer ce passage dans mon message précédent : "En Haskell, on se fiche un peu de regarder le code d'une librairie. Si ça marche, ça marchera quelque soit le contexte. Au contraire, quand on veut réutiliser du code en Ruby, ça ne marche pas toujours et là il faut malheureusement mettre le nez dans la merde. "

J'ajoute à ça que, quelque soit le langage de programmation, tu trouveras toujours des gens pour faire des choses moches/illisibles/inefficaces avec. La question est alors plus de savoir ce que tu pourras faire de ce code, et à quel prix.

+Silvermo:
au début du second paragraphe.

Je suis d'accord qu'on se fiche de regarder le code d'une librairie si on veut juste que ça marche. Mais quand on a envie d'en savoir plus, ou qu'on en a besoin (débogage), il s'avère indispensable, pour sa santé mentale, d'avoir un code clair sous les yeux

Ruby est un super langage ( ) si tu penses comme son créateur.
Au cas contraire, tu ne feras que t'énerver sur ton code, et il vaudra mieux pour toi de passer à autre chose.

Ce que j'aime avec Ruby, c'est que c'est le langage avec lequel j'arrive le plus rapidement à faire un code concret et tester les concepts sous-jacents. Bref, pour faire une maquette, j'ai rien de meilleur.
Après, quand il s'agît de faire quelque chose d'officiel, j'utiliserais pas ce langage.

Si tu penses comme le créateur de Ruby, vas élever des moutons en montagnes. (cf mon premier message pour l'argumentaire)

Pour prototyper, Python ou Haskell (suivant que c'est de la manipulation de données avec I/Os ou plutôt du calcul pur) sont à mon avis bien meilleurs. Et comme je n'aime pas Python, je suggère même le prototypage en Perl.

Bonsoir,

merci à tous pour vos réponses!

Python est très bien pour tester rapidement un algo compliqué c'est bien ça? J'ai cru voir qu'on n'avait pas besoin de compiler un programme python, c'est donc un avantage? (on perd pas de temps à tester l'algo et a le compiler en C?)

Pour haskell il est bien pour la lecture et le traitement de données si j'ai bien compris?
Il serait plutôt efficace pour quel genre de programme?
-traitements d'image? reconnaissance de forme par exemple ou manipulation des couleurs?
-gérer les données sur un gps?
-cryptage?
-des calculs mathématiques complexes?

J'espère avoir a peu près compris, si vous pouvez me confirmer?

Je suis très intéressé à étudier python et haskell pour étoffer mes compétences en fait (avoir plus que C et C++...)

J'ai cru voir aussi qu'on pouvait exécuter du code haskell dans un programme en C, ce genre de mélange peut donner de très bon programme? (je suppose que oui, à moins que ça soit compliqué à faire?)

Je vous remercie tous d'avance
A bientôt!

Chris_27 Je vis déjà en montagne, et j'ai pas besoin de moutons, les vaches me conviennent très bien !
(À part ça, je suis une des rares personnes dans mon entourage qui n'a ni bétail ni vignes. )

Pour le prototypage, je te rassure, Perl et Python sont loin de convenir à mes envies.
Quant à Haskell, c'est pas adapté à toutes les utilisations. (Mais rassure-toi, quand je code en Haskell, j'ai le même feeling que quand je code en Ruby, chose que je n'ai avec aucun autre langage. )

"J'ai cru voir aussi qu'on pouvait exécuter du code haskell dans un programme en C, ce genre de mélange peut donner de très bon programme? (je suppose que oui, à moins que ça soit compliqué à faire?)"
-> Quand tu compiles ton code Haskell, c'est dans une première étape des fichiers objets qui en sortent, donc des fichiers que tu peux linker avec n'importe quels autres fichiers objets, du moment qu'il y a pas de conflit. (Un peu comme quand tu fais de l'assembleur combiné à du C.)

Aussi, GHC possède un mode "C", mais j'ai pas testé ça, par contre.

« Python est très bien pour tester rapidement un algo compliqué c'est bien ça? J'ai cru voir qu'on n'avait pas besoin de compiler un programme python, c'est donc un avantage? (on perd pas de temps à tester l'algo et a le compiler en C?) » tout dépend du "compliqué".

Si c'est compliqué parce que le code est très long, moi je n'ai aucune envie de coder la bête deux fois.

Si en revanche c'est compliqué parce qu'il y a une structure de données complexe dessous, mais que pour valider la correction de l'algo on peut utiliser une structure de donnée un peu moins bonne mais fournie en Python, alors là le prototypage est le bienvenu.

« Pour le prototypage, je te rassure, Perl et Python sont loin de convenir à mes envies. » si tu dis ça, repose toi la question de ce que tu as envie (car ce n'est assurément pas de coder en ruby).

Yunfa:
« Pour haskell il est bien pour la lecture et le traitement de données si j'ai bien compris? » je vais prendre les choses par l'autre bout. Haskell c'est l'horreur lorsqu'il s'agit de faire des tas d'entrées/sorties un peu partout dans le programme. Si tu dois passer ton temps à lire et écrire dans des fichiers de façon un peu subtile, n'utilise pas Haskell.

En fait, Haskell c'est très bon pour faire du calcul pur et dur (avec des objets en RAM, donc).

« Il serait plutôt efficace pour quel genre de programme?
-traitements d'image? » oui.
« reconnaissance de forme par exemple ou manipulation des couleurs? » aussi.
« -gérer les données sur un gps? » sans doute moins. Il faut voir ce que signifie "gérer" ici.
« -cryptage? » oui.
« -des calculs mathématiques complexes? » oui.

À noter que, bien que je dise oui, ça ne veut pas dire qu'un autre langage ne serait pas aussi bien.

Sinon, mélanger les langages, c'est LE DÉMON. Ça demande strictement plus qu'une bonne maîtrise des deux langages à mélanger, ce que peut de gens ont (et ceci est valable y compris pour le C et le C++).

Si tu veux une culture assez large de la programmation, Haskell est un choix très pertinent. Après, il faut voir ce que tu connais en C et en C++. Suivant les cas, Python peut être un bon complément.