Le langage ocaml

par **Dominique Lefebvre** » 15 Juin 2007, 08:31

VPE a écrit:...non je crois qu'il y a un petit qui-pro-quo.:triste:
Si VC++ est dédié a la programmation en C++ Visaul basic lui est didié au Visual basic,non au basic.

Pourquoi, on ne peut pas écrire un programme en Basic standard sous VB? Tu m'étonnes...

par **Patastronch** » 15 Juin 2007, 11:34

VPE a écrit:Juste par curiosité,en quels langages programme tu ?

Ca dépend enormément de ce que j'ai a faire. Si je me fous de la rapidité et que je veux juste faire certaines taches redondantes ca sera un langage de script tel le python ou bash.
Si je code un truc un peu plus serieu mais sans besoin de performance spécialement, j'opterais surement pour le java.
Si la complexité de ce que je veux coder n'est pas polynomiale ou que mes instances de départ sont de grande tailles alors en O'Caml si je code seul, en C++ si on est plusieurs a coder.
Et si je veux juste faire un site banal : php/struts-hibernate ou ruby on rails elon ce que propose le serveur, et si le site doit etre un peu plus poussé ca sera à coup de cgi.

Je ne fais pas de C pour la simple et bonne raison que faire un code propre en C c'est toute une aventure !

par **Patastronch** » 15 Juin 2007, 11:35

Dominique Lefebvre a écrit:Tu crois? Le premier programme exemple, celui-ci concerné par la question, comme tous les prog exemple de ce genre, ne sert à rien, sinon à donner un exemple....

Et encore, si j'avais pu placer un "hello world" je me serais pas géné :ptdr:

par **Patastronch** » 15 Juin 2007, 11:36

VPE a écrit:Oui c'est vrai,
Il en va de meme pour Ocaml.Cependant alelo demandait quel était ce "programme" j'ai donc pensé qu'il parlait de l'IDE objective caml.

Oui c'est bel et bien les 2, si j'ai fait cette remarque c'était surtout parceque j'ai cru que tu ne considerais pas le O'Caml comme un langage.

par **bruce.ml** » 19 Juin 2007, 01:44

Le premier gros avantage d'O'caml c'est que c'est un langage typé statiquement, plus précisément à typage polymorphique par inférence de types.
En gros ça veut dire que quand vous éssayez de compiler votre programme, si jamais vous éssayez d'ajouter un entier et une chaine de caractères ils vous dit : "hey coco qu'est ce que tu fabriques là, t'as pas le droit de faire ça". Alors qu'un langage comme C vous dit que tout va bien, et quand vous lancez votre programme qui est dans la fusée Ariane, C vous dit : oops en fait ça fonctionne pas, et la fusée explose ;)
Sinon le deuxième gros avantage c'est que c'est un langage fonctionnel, c'est à dire qu'on peut utiliser des fonctions, ce qui permet, quand on en a l'habitude, de programmer très rapidement, en ayant un code très concis et très clair.

par **Dominique Lefebvre** » 19 Juin 2007, 13:24

bruce.ml a écrit:Le premier gros avantage d'O'caml c'est que c'est un langage typé statiquement, plus précisément à typage polymorphique par inférence de types.
En gros ça veut dire que quand vous éssayez de compiler votre programme, si jamais vous éssayez d'ajouter un entier et une chaine de caractères ils vous dit : "hey coco qu'est ce que tu fabriques là, t'as pas le droit de faire ça". Alors qu'un langage comme C vous dit que tout va bien, et quand vous lancez votre programme qui est dans la fusée Ariane, C vous dit : oops en fait ça fonctionne pas, et la fusée explose

Heuuu, c'est pas vraiment pour ça que Ariane 5 c'est planté! C'est pour un problème de cumul d'erreurs d'arrondi. En fait, le bout de code en question provenait du code Ariane 4 (moteur Viking sur A4 et Vulcain sur A5) et a été réutilisé sans vraiment être testé à nouveau. C'est donc plutôt l'ingénierie du logiciel qui est en cause. Je ne suis pas certain que l'usage de la technologie objet empêche les erreurs dues au cumul des erreurs d'arrondi....

par **Patastronch** » 19 Juin 2007, 13:39

Dominique Lefebvre a écrit:Heuuu, c'est pas vraiment pour ça que Ariane 5 c'est planté! C'est pour un problème de cumul d'erreurs d'arrondi. En fait, le bout de code en question provenait du code Ariane 4 (moteur Viking sur A4 et Vulcain sur A5) et a été réutilisé sans vraiment être testé à nouveau. C'est donc plutôt l'ingénierie du logiciel qui est en cause. Je ne suis pas certain que l'usage de la technologie objet empêche les erreurs dues au cumul des erreurs d'arrondi....

En effet, l'objet ou le coté fortement typé d 'un langage n'est qu'une sécurité de plus mais renvoie des reusltat stoujours aussi faux dans les calculs.

A savoir que faire du calcul exact avec un ordinateur est un véritable casse tete et il y a pas de solution miracle qui marche pour tout, les techniques sont spécifique a chaque probleme et sont souvent tres gourmande en temps/place.

par **VPE** » 19 Juin 2007, 14:35

bruce.ml a écrit:En gros ça veut dire que quand vous éssayez de compiler votre programme, si jamais vous éssayez d'ajouter un entier et une chaine de caractères ils vous dit : "hey coco qu'est ce que tu fabriques là, t'as pas le droit de faire ça". Alors qu'un langage comme C vous dit que tout va bien

Absolument pas,le compilateur de VC++ est meme (trop) pointilleux.
heuresement qu'il ne laisse pas passer ce genre d'erreurs car le programme planterait en cours d'execution,il corrige meme les erreurs de "logiques" comme une variable AzertY pour AzerTy ou ligne ligne qui ne ne sera jammais exécutée ou qui n'a aucun effet ou encore la perte de préscision lors de la conversion de types de données,ect...

par **bruce.ml** » 19 Juin 2007, 14:51

Dominique Lefebvre a écrit:Heuuu, c'est pas vraiment pour ça que Ariane 5 c'est planté! C'est pour un problème de cumul d'erreurs d'arrondi.

Oui je donnais juste un exemple imagé qui voulait dire que le programme plantait sans crier gare

par **bruce.ml** » 19 Juin 2007, 14:53

VPE a écrit:Absolument pas,le compilateur de VC++ est meme (trop) pointilleux.
heuresement qu'il ne laisse pas passer ce genre d'erreurs car le programme planterait en cours d'execution,il corrige meme les erreurs de "logiques" comme une variable AzertY pour AzerTy ou ligne ligne qui ne ne sera jammais exécutée ou qui n'a aucun effet ou encore la perte de préscision lors de la conversion de types de données,ect...

La force de C c'est justement qu'on peut bidouiller en faisant des trucs interdits. Si c'est pour faire du C gentil écolier, autant faire du o'caml

par **abcd22** » 19 Juin 2007, 16:21

bruce.ml a écrit:La force de C c'est justement qu'on peut bidouiller en faisant des trucs interdits.

Est-ce vraiment une force pour un langage de programmation ?

par **Dominique Lefebvre** » 19 Juin 2007, 16:42

Patastronch a écrit:En effet, l'objet ou le coté fortement typé d 'un langage n'est qu'une sécurité de plus mais renvoie des reusltat stoujours aussi faux dans les calculs.

A savoir que faire du calcul exact avec un ordinateur est un véritable casse tete et il y a pas de solution miracle qui marche pour tout, les techniques sont spécifique a chaque probleme et sont souvent tres gourmande en temps/place.

Ouaip, je peux même t'en causer un rayon..... Vu que je passe mes journées sur ce genre de problème!

Pour la petite histoire, je n'ai jamais vu aucun intérêt à utiliser une techno objet, à condition que les programmeurs maîtrisent correctement le génie logiciel, ce qui est assez rare!

par **Dominique Lefebvre** » 19 Juin 2007, 16:42

VPE a écrit:Absolument pas,le compilateur de VC++ est meme (trop) pointilleux.
heuresement qu'il ne laisse pas passer ce genre d'erreurs car le programme planterait en cours d'execution,il corrige meme les erreurs de "logiques" comme une variable AzertY pour AzerTy ou ligne ligne qui ne ne sera jammais exécutée ou qui n'a aucun effet ou encore la perte de préscision lors de la conversion de types de données,ect...

Absolument, tous les compils C++ savent faire une chose aussi bête...

par **Dominique Lefebvre** » 19 Juin 2007, 16:44

bruce.ml a écrit:Oui je donnais juste un exemple imagé qui voulait dire que le programme plantait sans crier gare

Pas s'il est bien fait! Le traitement des exceptions, ça te dit qq chose? ça n'existe pas que dans Python ou ocaml!

par **Dominique Lefebvre** » 19 Juin 2007, 16:45

abcd22 a écrit:Est-ce vraiment une force pour un langage de programmation ?

Oui, il arrive qu'on soit obligé de bidouiller. Il faut pouvoir le faire, mais en connaissance de cause... Un peu comme des funambules sans filet!

par **bruce.ml** » 19 Juin 2007, 18:39

Dominique Lefebvre a écrit:Pas s'il est bien fait! Le traitement des exceptions, ça te dit qq chose? ça n'existe pas que dans Python ou ocaml!

Les exceptions sont détectées à l'exécution, par les erreurs de type !

par **bruce.ml** » 19 Juin 2007, 18:41

Dominique Lefebvre a écrit:Ouaip, je peux même t'en causer un rayon..... Vu que je passe mes journées sur ce genre de problème!

Pour la petite histoire, je n'ai jamais vu aucun intérêt à utiliser une techno objet, à condition que les programmeurs maîtrisent correctement le génie logiciel, ce qui est assez rare!

les objets servent effectivement aux programmeurs qui travaillent sur de gros projets et à plusieurs. Sinon ça ne sert en effet que très rarement.

par **Dominique Lefebvre** » 19 Juin 2007, 19:52

bruce.ml a écrit:Les exceptions sont détectées à l'exécution, par les erreurs de type !

De quelles erreurs parles-tu? Si ton code affecte un integer à un char, je ne suis pas certain que ton compil C/C++ ne râle pas :hum: Et d'ailleurs le cast fou est fait pour tourner ce léger inconvénient...

par **Dominique Lefebvre** » 19 Juin 2007, 19:57

bruce.ml a écrit:les objets servent effectivement aux programmeurs qui travaillent sur de gros projets et à plusieurs. Sinon ça ne sert en effet que très rarement.

Ben, un code de claul ça peut être une très gros projet! Les modèles de simu en climato ou en physique nucléaire font des centaines de milliers de lignes, voire plusieurs millions, avec de milliers de composants. Une équipe projet de modélisation/simulation comprend au moins une dizaine (22 dans ma dernière équipe) d'ingé. calcul qui programment.
Or, ils utilisent très peu pour ne pas dire pas les techno objets.

Je pense qu'il s'agit d'une limitation culturelle, de techniques de génie logiciel non orientées objets et aussi un besoin de réutilisabilité des codes pris en compte à travers des librairies de code qui existent depuis longtemps et ne sont donc OO.

par **bruce.ml** » 19 Juin 2007, 22:25

Dominique Lefebvre a écrit:De quelles erreurs parles-tu? Si ton code affecte un integer à un char, je ne suis pas certain que ton compil C/C++ ne râle pas :hum: Et d'ailleurs le cast fou est fait pour tourner ce léger inconvénient...

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

Le langage ocaml

Qui est en ligne