Le langage ocaml

[Dominique Lefebvre]

Si justement, gcc laisse passer ce genre de choses, car C permet de caster justement.

Tu l'as dit bouffi... le compilateur C permet de caster, il ne le fait pas tout seul sans prévenir...

[bruce.ml]

Tu l'as dit bouffi... le compilateur C permet de caster, il ne le fait pas tout seul sans prévenir...

Je n'ai jamais dit le contraire sauf que certains casts laissés passer provoqueront une erreur à l'execution.

[Dominique Lefebvre]

Je n'ai jamais dit le contraire sauf que certains casts laissés passer provoqueront une erreur à l'execution.

C'est clair, mais avoue qu'il faut être bien inattentif pour laisser passer un cast...
Par principe, et pour ma part, je hais les casts et je me garde bien d'utiliser cette méthode de bidouilleurs. Il ya bien que les ingé système pour caster comme des fous!

[bruce.ml]

C'est clair, mais avoue qu'il faut être bien inattentif pour laisser passer un cast...
Par principe, et pour ma part, je hais les casts et je me garde bien d'utiliser cette méthode de bidouilleurs. Il ya bien que les ingé système pour caster comme des fous!

Parfois on est obligé de caster, pour quelque raison que ce soit. Mais si tu n'utilises pas les casts et que tu programmes proproment, il faut se mettre au caml

[Dominique Lefebvre]

Parfois on est obligé de caster, pour quelque raison que ce soit. Mais si tu n'utilises pas les casts et que tu programmes proproment, il faut se mettre au caml

Pourquoi pas! Mais ce n'est pas très à la mode chez les physiciens... En ce moment, le langage In c'est Python! Le dernier numéro de l'IEEE computing in science and engineering nous vante sa parfaite adéquation à nos besoins, exemples à l'appui! J'ai regardé ça en diagonal et effectivement ça a l'air sympa...

Mais bon, entre le code de calcul multi-physiques qu'on connait depuis 10 ans, scilab dont on ne peut se passer pour maqueter et les langages fétiches de notre métier, FORTRAN et C, j'ai du mal à me convaincre de me remettre en cause. Je ne vois pas de raison suffisante à produire l'effort de réapprendre un langage...

Ah oui, j'avoue qu'il marrive très rarement de caster, seulement pour utiliser certaines API de windows lorsque c'est indispensable (et c'est rare!)

[Patastronch]

Pourquoi pas! Mais ce n'est pas très à la mode chez les physiciens... En ce moment, le langage In c'est Python! Le dernier numéro de l'IEEE computing in science and engineering nous vante sa parfaite adéquation à nos besoins, exemples à l'appui! J'ai regardé ça en diagonal et effectivement ça a l'air sympa...

Mais bon, entre le code de calcul multi-physiques qu'on connait depuis 10 ans, scilab dont on ne peut se passer pour maqueter et les langages fétiches de notre métier, FORTRAN et C, j'ai du mal à me convaincre de me remettre en cause. Je ne vois pas de raison suffisante à produire l'effort de réapprendre un langage...

Ah oui, j'avoue qu'il marrive très rarement de caster, seulement pour utiliser certaines API de windows lorsque c'est indispensable (et c'est rare!)

Euh le python reste un langage interprété, pas terrible pour la rapidité d'éxecution, pour le coup autant utiliser le Caml qui utilise les memes paradigmes de programmation.

Pour moi le python est un bon langage car tres simple et tres riche, mais niveau sécurité (notemment a cause du typage dynamique qui en fait une force et a la fois une faiblesse du langage) et perf ca laisse à désirer.

Donc le python oui, mais si ton algo est en O(n²) (grand max O(n^3)) pour des instances de tailles raisonable, sinon t'en a pour la semaine pour faire ce que le C aurait fait en 1 heure !

[Dominique Lefebvre]

Euh le python reste un langage interprété, pas terrible pour la rapidité d'éxecution, pour le coup autant utiliser le Caml qui utilise les memes paradigmes de programmation.

Pour moi le python est un bon langage car tres simple et tres riche, mais niveau sécurité (notemment a cause du typage dynamique qui en fait une force et a la fois une faiblesse du langage) et perf ca laisse à désirer.

Donc le python oui, mais si ton algo est en O(n²) (grand max O(n^3)) pour des instances de tailles raisonable, sinon t'en a pour la semaine pour faire ce que le C aurait fait en 1 heure !

Certes, il s'agit d'un interpréteur! Ce fut d'ailleurs ma première et principale objection. Puis en analysant la situation je me suis dit que:
- je n'utiliserai pas Python pour écrire un code de calcul. Pour cela, rien ne vaut C ou FORTRAN.
-je pourrais utiliser Python comme scilab: pour faire des maquettes ou pour coder rapidement des algos. Un des avantages de Python est de posséder des librairies de calcul très riches (Numpy, scipy, CCpy, etc..) qui satisfont tous mes besoins. Après tout, on a souvent besoin d'écrire un code sur un coin de table pour expérimenter une idée ou pour faire un petit traitement.
- je peux interfacer du code python et du code C ou FORTRAN.
- l'interpréteur Python est assez rapide sur les plateformes que j'utilise, aussi performant que java, ce qui n'est pas difficile remarque...

Sais-tu qu'il existe un projet EC d'écriture d'un compilateur Python en Python (le projet PyPy)!

Enfin bref, c'est un outil à ne pas négliger. Mais comme je l'ai écris, je ne suis pas près à renoncer au C/FORTRAN...

[Sinus]

Salut, j'ai lu en diagonale la discussion et plusieurs points n'ont pas été abordés me semble-t-il :

- L'Ocaml peut être compilé en code-objet (comme du .NET ou du Java), mais il peut également être interprêté, ou bien entendu compilé en natif.
C'est extrèmement commode pour développer/porter/débugger.

- Les performances de l'ocaml sont excellentes. Evidemment le C est meilleur, mais par rapport au Java, .NET, ou même la plupart des langages compilés en natif, il n'y a pas photo.

- Les fuites mémoires sont très courantes dans plein de programmes en C/C++ (la faute au programmeur, certes). OCaml est à la base un langage fonctionnel (pas de variables explicites) et dispose d'un garbage collector. Pas de fuites en RAM, donc.

P.S : J'avais fait un petit jeu en début de L2 en OCaml, l'executable et la source sont ici : http://sinusop.free.fr/pperso/pperso/serpent/