Disons que le dev d'ocaml était purement universitaire, ils étaient plus intéressé dans le développement des derniers concepts avancés de typage (le dernier type à l'air super puissant, mais je n'ai toujours pas compris son fonctionnement) que dans le fait d'avoir des messages d'erreurs précis et compréhensible, ou un module Eclipse fonctionnel. Ocaml pro veut changer cela, on dirait.
cocomo ne mesure pas la difficulté de changement, mais le temps global pour écrire le code. Le problème est que le nombre exacte de kloc est connu à la fin du projet.
Et si le cout est 100x, c'est parce qu'au début, cela prend 5min pour changer une spec, alors qu'à la fin, c'est le client qui trouve l'erreur, la remonte au support, qui transmet à la validation pour confirmation, qui remonte ensuite au dev.
Le problème est assez complexe, avec Ocaml tu peux facilement prédire les données que tu va créé. Haskell dispose d'optimisation dite de "deforestation" qui supprime les arbres de données intermédiaires, quand il le peut. Ocaml n'étant pas purement fonctionnel, j'imagine que la difficulté vient de là.
Je pensais plus au fait qu'il était trés difficile de déterminer la taille des données mémoires. Certain industriel avait laisser tomber Haskell car de petites modifications pouvait faire exploser son usage de la mémoire. C'était un des arguments d'OCaml ou sa gestion des objets mémoire est très prévisible.
Disons que faire du pthread propre est une vrai horreur. Le vrai multi-process est revenu à l'honneur avec chrome. Il "suffit" d'ajouter une lib de passage de message propre et rapide.
Mais c'est vrai aussi que des traitements parallèle de data pourrait être sympa (map fold/reduce en multicpu).
"En dehors de ça, j'ai l'impression que le langage Ocaml recommence à faire parler de lui, après quelques années en sommeil. Un regain pour le fonctionnel ?"
Peut être est-ce la création de Ocaml pro ? Ou la pub sur l'usage qu'en font quelques boite comme janes street (vive le HFT en Ocaml).
Cela va te lancer n thread en découpant la clause for en morceau. Le système se débrouille même si tu peux aussi le guider. Sur du code numérique, c'est assez facile du moment que tu comprends que tu ne peux pas partager d'information entre threads.
Si tu as des ressources intéressantes à ce sujet je suis preneur, si tu estimes que ça permets vraiment d'estimer les coûts d'un projet en fonction des langages utilisés.
openMP n'est pas une api C. Ce sont des directives de compilation pour générer du code multithread.
"la taille d'un code comme un indice par rapport au fait qu'il soit lisible"
Non, mais sur sa concision. Il y a eu des études portant sur la productivité (cocomo) quelque soit le langage, la productivité en ligne de code par unité de temps est la même.
"De quel domaine parles-tu? Dans la discussion, on parlait de façon assez générale il me semble…"
Ces langages étant turing complet et bas niveau, on peut tous faire avec ou presque. Après, il y a une question de verbosité. Le code généré est plus gros, que ce tu ferais à la main, cela décale ton langage vers la gauche dans le graphe.
Donc, un langage générant du C peut être plus rapide et concis qu'un code C fait main.
"Battait, ça veut dire que C a rattrapé Lisaac ensuite?"
Oui, car lisaac générant du C, c'est facile de comprendre pourquoi il est plus rapide. Au pire, tu copie/colle sa sortie et tu dis que c'est du C manuel.
"Et sinon, le C++ n'a pas ces problèmes il me semble, et pourtant les bench disent souvent la même chose: il est souvent plus lent que le C."
Dans le shootout, il est régulièrement premier grâce à openMP et les templates.
"je suis intrigué qu'il n'ait pas réussi s'il est meilleur"
Le code du compilo n'était pas simple du tout (détermination du type réel de chaque objet). Et le dev principal a coupé les ponts du jour au lendemain.
Les codes c++ et C utilisent massivement openMP qui n'existe pas dans le monde ocaml.
"Ce benchmark est à 2 dimensions: taille du code (et pas expressivité) à l'horizontale et vitesse d'exécution sur la hauteur, si je ne me trompe pas?"
Non, c'est juste l'affichage de ce graph, il est intéressant car la case la plus intéressante est en bas à droite : compact et rapide.
"ils mesurent la taille du code en octets, en ayant enlevé commentaires et espaces, et en compressant le texte ainsi obtenu. Franchement… je trouve difficile de trouver une façon moins pertinente de mesurer la taille des codes."
Au contraire, cela évite de parler de la définition de la "ligne de code". La compression limite l'augmentation de taille des langage verbeux par rapport à ceux abusant des symboles.
"il n'y a que des algo de calcul, donc pas d'accès aux ressources, de gestion d'IHM, et caetera. Donc, comme d'hab avec les bench, résultats à n'utiliser que pour des optimisations des "zones de calcul"."
C'est vrai. Mais les problèmes de logiciels dans ce domaine, sont liés aux algos utilisés. Il faut aussi que la taille du benchmark reste accessible aux codeurs. Il y a aussi des benchs manipulant des symboles (de mémoire, le truc qui manipule de l'ADN).
J'ai écrit et optimier une IA en java. La vitesse est digne d'un gcc -O0, pas d'inline des getter/setter, etc… Cela ne peut pas être rapide, même les "clause if" n'étaient pas sorti des boucles.
Il n'y a pas un seul benchmark, mais une dizaine. L'algo est fixe.
Haskell vu sa gestion de la mémoire à forcément des cas pathologiques.
Pas la peine de vendre du rêve!
Lisaac battait le code C dans la plus part de tests donc bon. Le problème n'est pas de faire un compilo intelligent. Le problème est de faire un langage avec suffisamment de sémantique pour qu'un compilateur puisse faire un boulot intelligent. Par exemple, le C fixe le layout mémoire de ces structures de données, et 2 pointeurs de même type sont censé pouvoir pointé sur la même zone mémoire. Ces 2 caractéristiques peuvent être des killers de performances. En gros, c'est le boulot du codeur, et le compilo ne peut rien faire.
Le dev de Lisaac est arreté. Le site est mort. Il y a eu un gros article sur les concepts manipulés publiés dans linux mag en début d'année dernière de mémoire.
Sauf qu'on aura toujours besoin de langage comme C/C++ pour implémenter des trucs qui doivent aller vite, comme les interpréteurs de langage haut niveau ou des compilateurs. Chacun son domaine.
Ou que non alors ! Lisaac a déjà prouvé que l'on peut être du niveau de smaltalk en terme d'expressivité et battre le C++ en terme de vitesse.
OCaml est de trés haut niveau, mais les optimisations dans la génération de code sont minimes (pas de déroulage de boucle ou de spécialisation de fonction). Il est pourtant dans le top10 en terme de vitesse.
Scala n'est pas du tout dérivé de java, il produit du code pour jvm, c'est tout. Et je suis d'accord que la syntaxe est encore pire que celle de Ocaml.
objet ou pas objet, le but est de pouvoir parcourir un arbre en séparant la définition de l'arbre et les parcours.
Et pour ça, les types sommes et le "pattern matching" sont totalement imbattables. C'est tellement puissant que je ne comprends pas pourquoi cela n'a pas été ajouter au C++.
C'est une très bonne alternative pour tous les cas ou il y a une pléthore de petit objet à gérer ensemble.
type base_t
type derived_t
type t =
| BASE of base_t * t list
| DERIVED of derived_t * t list
let rec visitor accumulator t =
match t with
| [] -> List.rev accumulator
| BASE (base_info, suite) :: tail
-> let a = visitor ((foo_base base_info) :: accumulator) tail in
visitor ((foo_base base_info) :: a) suite
| DERIVED (derived_info, suite) :: tail
-> let a = visitor ((foo_base base_info) :: accumulator) tail in
visitor ((foo_derived derived_info) :: a) suite
(*execution : *)
let resultat_list = visitor [] my_data_tree in
...
Et encore, dans le match on peut mettre des bouts d'arbres comme :
| BASE (base_info, BASE (base_info2, []))
Le petit point difficile est l'usage d'une liste dans le type, mais on peut utilisé un type Option pour faire la terminaison de récursion.
Pour info :
(item :: list) permet d'ajouter un item au début d'une list ou de décomposer une liste dans les matchs.
(foo plop) permet d'appliquer la fonction foo au paramètre plop
En conclusion, vive les types sommes et le "pattern matching" d'arbre.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Tu as comparé avec l'outil de montage de blender ? Il m'a l'air bien complet mais très dure à prendre en main.
"La première sécurité est la liberté"
[^] # Re: Trollons
Posté par Nicolas Boulay (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.
Marrant, tu n'as pas utilisé les 3 lettres qui commencent par E et finit par L (avec un F au milieu).
"La première sécurité est la liberté"
[^] # Re: Où ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Privateur.... Évalué à 2.
X11 avait aussi un paquet de fork incompatible chez Sun et HP. Idem pour spice, qui avait un fork dans chaque outil propriétaire du domaine.
Ces fork profitaient du code libre sans rien payer en retour en contribution.
"La première sécurité est la liberté"
[^] # Re: Où ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Privateur.... Évalué à 2.
Aujourd'hui, les boite comme Google, joue le jeu de la BSD.
Ce n'était pas le cas avant, les exemples autour de X11 montrent que la BSD permet de faire n'importe quoi.
"La première sécurité est la liberté"
[^] # Re: Tellement répété…
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Privateur.... Évalué à 1.
D'où le terme de FOS :)
"La première sécurité est la liberté"
[^] # Re: Tellement répété…
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Privateur.... Évalué à 7.
La GPL protège les auteurs orignaux du code sur le fait de ne pas pouvoir changer l'usage de leur code. Et elle protège les utilisateurs.
Et en effet, elle empêche les réutilisateurs du code, de se l'approprié sans rien donner en retour.
La BSD fait confiance au gens, pas la GPL. Inutile de préciser, quel écosystème est le plus gros.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.
Disons que le dev d'ocaml était purement universitaire, ils étaient plus intéressé dans le développement des derniers concepts avancés de typage (le dernier type à l'air super puissant, mais je n'ai toujours pas compris son fonctionnement) que dans le fait d'avoir des messages d'erreurs précis et compréhensible, ou un module Eclipse fonctionnel. Ocaml pro veut changer cela, on dirait.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
cocomo ne mesure pas la difficulté de changement, mais le temps global pour écrire le code. Le problème est que le nombre exacte de kloc est connu à la fin du projet.
Et si le cout est 100x, c'est parce qu'au début, cela prend 5min pour changer une spec, alors qu'à la fin, c'est le client qui trouve l'erreur, la remonte au support, qui transmet à la validation pour confirmation, qui remonte ensuite au dev.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 0.
Le problème est assez complexe, avec Ocaml tu peux facilement prédire les données que tu va créé. Haskell dispose d'optimisation dite de "deforestation" qui supprime les arbres de données intermédiaires, quand il le peut. Ocaml n'étant pas purement fonctionnel, j'imagine que la difficulté vient de là.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.
Je pensais plus au fait qu'il était trés difficile de déterminer la taille des données mémoires. Certain industriel avait laisser tomber Haskell car de petites modifications pouvait faire exploser son usage de la mémoire. C'était un des arguments d'OCaml ou sa gestion des objets mémoire est très prévisible.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.
Disons que faire du pthread propre est une vrai horreur. Le vrai multi-process est revenu à l'honneur avec chrome. Il "suffit" d'ajouter une lib de passage de message propre et rapide.
Mais c'est vrai aussi que des traitements parallèle de data pourrait être sympa (map fold/reduce en multicpu).
"En dehors de ça, j'ai l'impression que le langage Ocaml recommence à faire parler de lui, après quelques années en sommeil. Un regain pour le fonctionnel ?"
Peut être est-ce la création de Ocaml pro ? Ou la pub sur l'usage qu'en font quelques boite comme janes street (vive le HFT en Ocaml).
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
Cela va te lancer n thread en découpant la clause for en morceau. Le système se débrouille même si tu peux aussi le guider. Sur du code numérique, c'est assez facile du moment que tu comprends que tu ne peux pas partager d'information entre threads.
Si tu as des ressources intéressantes à ce sujet je suis preneur, si tu estimes que ça permets vraiment d'estimer les coûts d'un projet en fonction des langages utilisés.
https://en.wikipedia.org/wiki/COCOMO ?
Je retient surtout : ab*(KLOC)bb. Cela veut dire que la difficulté n'est pas linéaire au nombre de ligne, mais augmente plus vite.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
openMP n'est pas une api C. Ce sont des directives de compilation pour générer du code multithread.
"la taille d'un code comme un indice par rapport au fait qu'il soit lisible"
Non, mais sur sa concision. Il y a eu des études portant sur la productivité (cocomo) quelque soit le langage, la productivité en ligne de code par unité de temps est la même.
"De quel domaine parles-tu? Dans la discussion, on parlait de façon assez générale il me semble…"
Je pensais à l'IHM.
"Ici, ça semble être le calcul scientifique?"
Non, il y a aussi manipulation de symbole.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2.
Le C génére bien de l'assembleur.
Ces langages étant turing complet et bas niveau, on peut tous faire avec ou presque. Après, il y a une question de verbosité. Le code généré est plus gros, que ce tu ferais à la main, cela décale ton langage vers la gauche dans le graphe.
Donc, un langage générant du C peut être plus rapide et concis qu'un code C fait main.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.
"Battait, ça veut dire que C a rattrapé Lisaac ensuite?"
Oui, car lisaac générant du C, c'est facile de comprendre pourquoi il est plus rapide. Au pire, tu copie/colle sa sortie et tu dis que c'est du C manuel.
"Et sinon, le C++ n'a pas ces problèmes il me semble, et pourtant les bench disent souvent la même chose: il est souvent plus lent que le C."
Dans le shootout, il est régulièrement premier grâce à openMP et les templates.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2. Dernière modification le 25 avril 2013 à 16:11.
"je suis intrigué qu'il n'ait pas réussi s'il est meilleur"
Le code du compilo n'était pas simple du tout (détermination du type réel de chaque objet). Et le dev principal a coupé les ponts du jour au lendemain.
Les codes c++ et C utilisent massivement openMP qui n'existe pas dans le monde ocaml.
"Ce benchmark est à 2 dimensions: taille du code (et pas expressivité) à l'horizontale et vitesse d'exécution sur la hauteur, si je ne me trompe pas?"
Non, c'est juste l'affichage de ce graph, il est intéressant car la case la plus intéressante est en bas à droite : compact et rapide.
"ils mesurent la taille du code en octets, en ayant enlevé commentaires et espaces, et en compressant le texte ainsi obtenu. Franchement… je trouve difficile de trouver une façon moins pertinente de mesurer la taille des codes."
Au contraire, cela évite de parler de la définition de la "ligne de code". La compression limite l'augmentation de taille des langage verbeux par rapport à ceux abusant des symboles.
"il n'y a que des algo de calcul, donc pas d'accès aux ressources, de gestion d'IHM, et caetera. Donc, comme d'hab avec les bench, résultats à n'utiliser que pour des optimisations des "zones de calcul"."
C'est vrai. Mais les problèmes de logiciels dans ce domaine, sont liés aux algos utilisés. Il faut aussi que la taille du benchmark reste accessible aux codeurs. Il y a aussi des benchs manipulant des symboles (de mémoire, le truc qui manipule de l'ADN).
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.
J'ai écrit et optimier une IA en java. La vitesse est digne d'un gcc -O0, pas d'inline des getter/setter, etc… Cela ne peut pas être rapide, même les "clause if" n'étaient pas sorti des boucles.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2.
Il n'y a pas un seul benchmark, mais une dizaine. L'algo est fixe.
Haskell vu sa gestion de la mémoire à forcément des cas pathologiques.
Pas la peine de vendre du rêve!
Lisaac battait le code C dans la plus part de tests donc bon. Le problème n'est pas de faire un compilo intelligent. Le problème est de faire un langage avec suffisamment de sémantique pour qu'un compilateur puisse faire un boulot intelligent. Par exemple, le C fixe le layout mémoire de ces structures de données, et 2 pointeurs de même type sont censé pouvoir pointé sur la même zone mémoire. Ces 2 caractéristiques peuvent être des killers de performances. En gros, c'est le boulot du codeur, et le compilo ne peut rien faire.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2.
Le dev de Lisaac est arreté. Le site est mort. Il y a eu un gros article sur les concepts manipulés publiés dans linux mag en début d'année dernière de mémoire.
http://www.ed-diamond.com/produit.php?ref=lmag148&id_rubrique=1
Comme benchmark :
http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
Lisaac a été premier de ce benchmark quelque temps avant que les téchniques soient copié pour les code C et C++.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
Sauf qu'on aura toujours besoin de langage comme C/C++ pour implémenter des trucs qui doivent aller vite, comme les interpréteurs de langage haut niveau ou des compilateurs. Chacun son domaine.
Ou que non alors ! Lisaac a déjà prouvé que l'on peut être du niveau de smaltalk en terme d'expressivité et battre le C++ en terme de vitesse.
OCaml est de trés haut niveau, mais les optimisations dans la génération de code sont minimes (pas de déroulage de boucle ou de spécialisation de fonction). Il est pourtant dans le top10 en terme de vitesse.
"La première sécurité est la liberté"
[^] # Re: Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.
Scala est un langage fonctionnel, pas java…
"La première sécurité est la liberté"
[^] # Re: Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
Sans doute, mais quand tu as 2 niveaux de fold, mon cerveau fait un overflow.
"La première sécurité est la liberté"
[^] # Re: Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
Scala n'est pas du tout dérivé de java, il produit du code pour jvm, c'est tout. Et je suis d'accord que la syntaxe est encore pire que celle de Ocaml.
"La première sécurité est la liberté"
[^] # Re: Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 5.
objet ou pas objet, le but est de pouvoir parcourir un arbre en séparant la définition de l'arbre et les parcours.
Et pour ça, les types sommes et le "pattern matching" sont totalement imbattables. C'est tellement puissant que je ne comprends pas pourquoi cela n'a pas été ajouter au C++.
C'est une très bonne alternative pour tous les cas ou il y a une pléthore de petit objet à gérer ensemble.
"La première sécurité est la liberté"
# Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 10. Dernière modification le 24 avril 2013 à 10:56.
Quand on voit la complexité du truc…
Et encore, dans le match on peut mettre des bouts d'arbres comme :
| BASE (base_info, BASE (base_info2, []))
Le petit point difficile est l'usage d'une liste dans le type, mais on peut utilisé un type Option pour faire la terminaison de récursion.
Pour info :
(item :: list) permet d'ajouter un item au début d'une list ou de décomposer une liste dans les matchs.
(foo plop) permet d'appliquer la fonction foo au paramètre plop
En conclusion, vive les types sommes et le "pattern matching" d'arbre.
"La première sécurité est la liberté"