Well, tu as ton avis, tu aimes tes outils et je t'incite pas à les changer. En attendant, je me permets de me poser la question vis-à-vis de l'utilité de taper sur Ruby, alors que Python est vachement plus nocif. (Plus répandu, et vachement inférieur comme langage.)

En attendant, tu peux effacer les fameux messages ?

Ce qui m'étonne toujours c'est cette haine contre le C++. C'est pourtant un langage de génie ! Tu peux tout faire avec, du procédural, du fonctionnel, de l'orienté objet, etc... Je crois que les gens sont tellement frustrés de pas comprendre les techniques avancées du genre, la métaprogrammation, la S(T)L et d'autres trucs très utiles, qu'ils n'ont qu'une envie c'est de rabaisser ce langage. Alors que c'est de loin le langage le plus riche et intéressant qui existe.

4223161584: Tu ne connais manifestement pas ocaml toi… Non seulement tu peux en faire bien plus qu'en C++, mais en plus la théorie qui est derrière est bétonnée à bloc (entre autre, ocaml trouve les types tout seul, même en POO).

IIIIIIIIIIIIIll: je ne vois pas l'intérêt de supprimer tes messages. Il n'y a rien de choquant, rien d'offensant, et ça ouvre une discussion (potentiellement) intéressante.

C'est que j'ai dit pas mal de c*nneries, 0.7L de vodka dans le sang aidant (Oui, être bourré à 18h30, c'est lamentable, mais j'ai mes raisons. ). Bref, j'ai réagi au quart de tour zappant complètement le caractère volontairement trollesque des slides. Un comportement idiot, donc.
(Je m'étais pourtant bien marré sur le chien dont on a rajouté des pattes. )

Au passage, Ruby n'est pas fonctionnel à proprement parler. C'est juste que la "Ruby way to do something" utilise des lambdas un peu partout (la librairie standard en fait un usage très intensif), qui fait qu'au final, tu fais plutôt du fonctionnel impur que de l'OO au sens classique genre Java.

4223161584 C++ a ses problèmes aussi. Personnellement, ce me gêne principalement, c'est la gestion de la mémoire qui est pas toujours transparente : Y a-t-il une copie ou non ? Le destructeur appelé est-il le bon ? Toutes ces choses sont logiques, mais en pratique, y a pas mal d'erreurs qui viennent de là, et elles sont pas toujours triviales. (Typiquement, quand tu veux faire du polymorphisme et que le destructeur de la classe mère est le destructeur par défaut -> pas d'implémentation du destructeur par défaut dans la classe fille, et seg fault à l'exécution. Trouver l'origine d'une erreur pareille, c'est vraiment la misère, sachant que les linkers laissent passer ça. )
Ou encore l'héritage d'une classe template, qui est assez foireux. (Ah, OK, en plus d'hériter de la classe, il faut encore la déclarer comme amie... Mais comment ils ont trouvé cette solution, eux ?!?)
Ou encore les pointeurs de fonction qui ont un typage trop restrictif. (Dans le sens que tu dois surcharger n fois ta fonction, si tu veux pouvoir passer aussi des méthodes à ta fonction. C'est pa bô.)

Chris>> Il y a beaucoup de différences entre le ocaml et le Caml light ( ) ?

Moi, la seule chose que j'ai eu besoin de faire quand j'ai du migrer de caml light à caml, c'est découvrir ce qu'est un module (il faut faire List.hd au lieu de hd, etc.).

Après, tout dépend si tu veux t'attaquer au O ou pas. Si tu veux juste faire joujou avec le prompt, tu peux le faire sans soucis (autre que celui ci-dessus).

IIIIIIIIIIIIIll: spas grave de mordre au troll hein. Ça ne serait pas un troll sinon.
Quant au fonctionnel, ça s'applique pour moi dès que tu as des « lambdas » justement.

IIIIIIIIIIIIIll: La gestion de la mémoire c'est le seul point technique que tu soulèves. Cependant il y a plein d'outils qui gèrent bien cela facilement. Et si jamais tu dois faire tes propres pool ou autre, c'est pas insurmontable non plus. Et les deux autres points, je trouve quand même que pour faire hériter une classe template, c'est une erreur de conception. Et en ce qui concerne les fonctions, je préfère utiliser des foncteurs.

Je ne suis pas un troll C++ > all.

Pour répondre à la question sur les différences entre le OCamL et le CamL light :

- Comme l'a dit Chris, il faut appeller chaque fonction avec son petit nom de module (List.truc pour toutes les fonctions s'appliquant sur des listes, Array.bidule, etc.)
- Le code compilé est beaucoup plus rapide (un facteur variant entre 5 et 15 est généralement observé, je me souviens que des mecs avaient fait des tests pour Taupic)
- Les erreurs obtenues sont plus claires (je trouve)
- L'OCamL dispose de modules en plus (de fonctions par défaut dont ne dispose pas CamL light)
- Les entrées-sorties sont différentes (et je dirais, mais ça c'est personnel, que là enore c'est mieux foutu en OCamL, où ils ont repris le Printf du C)
- Pour certains modules ça change vraiment tout (je me rappelle que j'avais été un peu perdu les fois où j'avais dû utiliser le module qui fait des tas et celui qui fait des ensembles) m'enfin après une période d'adaptation ça passe.

En résumé, de mon point de vue, l'OCamL est utilisable dans la vie de tous les jours (c'est le langage vers lequel je me dirige dès que je dois coder de l'algorithmique), le CamL light non

À propos de la gestion de la mémoire, j'ai vraiment du mal à comprendre comment un langage comme le C++ dont la devise semble être "démerdez-vous" a autant de succès, et même on considère ça comme un avantage ! Le nombre de programmeurs capables d'écrire du code plus propre d'un point de vue gestion de la mémoire que celui généré automatiquement par OCamL, c'est quoi, 2% ?

« Et les deux autres points, je trouve quand même que pour faire hériter une classe template, c'est une erreur de conception. » non, ce sont les template de C++ qui sont une erreur de conception. Quand on compare aux foncteurs d'un langage fonctionnel digne de ce nom, on pleure quoi…

Un autre truc qui me rend malade, c'est de taper des :
   std::map< int, std::list<std::pair<int,bool> > >::const_iterator
dans mes boucles for. J'espère vraiment que le nouveau standard va mettre fin à ce calvaire quasi-quotidien, parce que devoir saisir des types pareils alors que le compilo a déjà toutes les infos, c'est la mort.

Enfin, le C++ est quelque chose d'extrêmement vaste. Et si les gens crachent dessus, c'est en grande partie parce beaucoup de développeurs l'exploite très mal.

XKCD: heu… et si tu compilais avec ocamlopt ?

Sinon, j'ignorais que caml light avait un module pour les ensembles. Effectivement, s'il en a un, c'est sûrement pas un foncteur comme dans la version de Ocaml.

Enfin, je te rejoins sur ton résumé. Caml light c'est un outil purement pédagogique, mais Ocaml lui est un vrai langage utilisé en production.

"std::map< int, std::list<std::pair<int,bool> > >::const_iterator"

Dans C++0x, c'est corrigé avec le mot clef auto.

Heu, je compile déjà avec ocamlopt... J'ai jamais vraiment compris la différence avec ocamlc, d'ailleurs

Pour la comparaison de rapidité entre CamL Light et OCamL, je me basais sur cette source http://taupic.telecom-bretagne.eu/forum/viewtopic.php?f=4&amp;t=8#p62

Oui, sauf que c'est c++1x et que ça n'a pas passé le cap de draft, que ce n'est donc pas supporter unanimement dans les compilateurs, et donc que je ne peux pas utiliser ça en production.

Quand je disais « J'espère », je pensais à une apparition rapide des choses actuellement proposées dans le c++1x dans les compilateurs de ma vraie vie.

Beaucoup de compilateurs sont assez au point sur certains points clefs de C++0x :

http://wiki.apache.org/stdcxx/C++0xCompilerSupport

Sinon personnellement je trouve pas que la syntaxe soit un problème. Les erreurs renvoyés sont parfois assez bof avec les template, mais j'utilise stlfilt qui corrige tout donc bon.

Non, pas assez pour passer en production. Les options -std=c++0x ça reste trop expérimental pour ce que je dois faire.

4223161584, je fais du C++ toute la journee, et c'est pas un langage que je recommanderait pour un projet simple comme les projets de suckless. Suckless vise des binaires petits, ce qui est peu compatible avec l'utilisation de template. Suckless vise des outils cout et facil a comprendre, ce qui est assez peu compatible avec les constructeurs et les operateurs en C++. C'est parfois difficile pour moi de comprendre pourquoi tel code marche ou tel code ne marche pas. Et je fais du C++ depuis 99 et je pense que j'ai vraiment compris le langage depuis 2005.

Maintenant replace ca le contexte de suckless ou tu veux du code simple a comprendre par une large communaute de developpeurs et tu comprends que faire du C++ est une connerie.

De toute façon le seul langage valable c'est le C.

Merci pour les précisions sur le Ocaml, je vais le mettre sur ma todo list.
En attendant je reste sur le C++ et le Python, les deux langages les plus utilisés en maths financières... Tiens, je vais profiter du fait que je bosse chez moi aujourd'hui pour essayer le compilo Intel.

l'ICC? On le trouve ou? Je suis allé voir sur le site d'intel et je crois que c'est payant..

http://software.intel.com/en-us/articles/intel-software-evaluation-center/

30 jours d'évaluation.