La nouvelle version 4.00.0 du langage OCaml est disponible en ligne depuis le 26 juillet 2012. Aussi, la réunion des développeurs OCaml (OUD'2012) aura lieu cette années à Copenhague le 14 septembre. Venez nombreux !
Parmi les dernières nouveautés disponibles dans cette version 4.00.0 :
- l'introduction des types de données algébriques généralisés (Generalized Algebraic Data Types - GADTs), qui permettent de détecter encore plus de bugs dès la compilation ;
- le générateur de code pour ARM a été complètement réécrit ;
- les types des modules de première classe sont maintenant inférés quand cela est possible, et les modules peuvent eux-mêmes être extraits par filtrage ;
- le compilateur est disponible sous forme de bibliothèque, et une nouvelle option -bin-annot permet de sauver l'arbre de syntaxe typé, ce qui devrait permettre l'apparition de nouveaux outils de développement plus évolués (refactoring, etc.) ;
- optimisation des fonctions partielles ;
- détection de code mort ou inutile (variables, open, champs, constructeurs, labels, etc.) ;
- émission de directives CFI pour améliorer le debuggage sous GDB.
Pour ceux qui ne connaissent pas, OCaml est un langage à mi-chemin entre C et Python, avec des performances proches de C avec la concision de Python. Mais contrairement à ces deux langages, OCaml appartient à la famille des langages à typage très fort, ce qui permet de détecter la plupart des bugs à la compilation, raccourcissant encore plus le temps de développement ! Rien d'étonnant à ce qu'OCaml ait gagné à plusieurs reprises la ICFP Programming Contest, compétition très sélective de programmation sur trois jours organisée tous les ans.
OCaml permet aussi un mélange des styles impératifs, fonctionnels et objets. Par exemple, une fonction transformant un fichier en une liste de chaînes peut s'écrire :
(* val lines_of_file : string -> string list *)
let lines_of_file filename =
let ic = open_in filename in
let lines = ref [] in
try
while true do
lines := (input_line ic) :: !lines
done;
assert false
with End_of_file ->
close_in ic;
List.rev !linesOn y voit à la fois l'utilisation des exceptions (try...with), une boucle (while...do...done), mais la même fonction aurait pu être écrite sous forme complètement récursive par un partisan de la programmation fonctionnelle !
Pour la prochaine version majeure, l'apparition des namespaces, de foncteurs multi-modules et la possibilité de profiler en utilisant le nouvel outil 'perf' sous Linux, sont sur les bancs, et on entend même parler de support des multicœurs dans les couloirs…
Aller plus loin
- Télécharger (70 clics)
- Tous les fichiers (41 clics)
- OCaml (224 clics)
- OCaml Users & Developers (OUD'2012) (57 clics)
- Le ChangeLog complet (57 clics)
- ICFP Programming Contest 2012 (81 clics)
# C'est triste ton avis sur Ocaml
Posté par Enjolras . Évalué à -9.
Tu veux dire, à mis chemin entre un langage avec un systéme de type pourri et un langage avec un systéme de type pourri et incapable de faire correctement du fonctionnel ?
[^] # Re: C'est triste ton avis sur Ocaml
Posté par Enjolras . Évalué à -4. Dernière modification le 11 août 2012 à 14:52.
Comme stratégie marketing, on a vu mieux quand même, essayer de pas faire peur aux gens et leur faire croire qu'ils vont se ramener à quelque chose de connu, alors qu'en fait, c'est pas le cas. Je pense qu'on peut se réjouir des efforts faits pour promouvoir Ocaml, comme Ocamlpro, mais de là à tomber dans la démagogie pure, je ne suis pas certain que ça soit une idée lumineuse.
[^] # Re: C'est triste ton avis sur Ocaml
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 6.
Merci pour la publicité pour OCamlPro, c'est toujours bien de mentionner qu'il y a maintenant une entreprise pour aider les utilisateurs industriels d'OCaml ! Heureusement, on est visiblement meilleurs en programmation qu'en communication ! ;-)
[^] # Re: C'est triste ton avis sur Ocaml
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 7.
C'est juste, j'aurais dû dire le "meilleur de C et de Python", i.e. la performance de C et la concision de Python. Merci pour la remarque constructive !
[^] # Re: C'est triste ton avis sur Ocaml
Posté par Maclag . Évalué à 6.
Sans vomir sur le C et le Python, il est vrai que j'ai le plus grand mal à placer OCaml à mi-chemin entre ces deux là tant il me semble dans une direction différente.
La concision, c'est une propriété résultante d'un tas d'autres trucs. Je ne dirais pas qu'un langage est proche d'un autre en me basant sur la concision.
Allez, il reste le fait que Python et OCaml proposent tous les deux la programmation orientée objet. Mais demandez donc aux dévs chez JaneStreet ce qu'ils pensent du modèle objet de OCaml (indice: dans une présentation par JaneStreet sur OCaml, le dév souriait en disant "Personne ne l'utilise!").
Cela dit, OCaml, c'est bon, mangez-en!
C'est le seul langage dont j'ai lu les débuts de tutoriaux qui m'ait jamais vraiment donné envie de m'y mettre (après avoir regardé du C, C++, Java, Python, Ruby). Pour les non-informaticiens mais avec un parcours plutôt sciences dures, c'est du bonheur: une impression de rigueur mathématique claire que je ne retrouve pas ailleurs!
[^] # Re: C'est triste ton avis sur Ocaml
Posté par rogo . Évalué à 1.
En terme de rigueur et d'esprit mathématique, je pense qu'Haskell va bien au-delà d'OCaml. Son insistance sur la notion de "pureté" lui donne un aspect terriblement mathématique. Par contre, sa rigueur est parfois pénible quand on débute, sur du code un peu complexe (E/S, combinaisons de monades, etc).
[^] # Re: C'est triste ton avis sur Ocaml
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 3. Dernière modification le 20 août 2012 à 12:42.
Ceux qui veulent vraiment toute la rigueur et l'esprit des mathématiques peuvent sauter la case Haskell, et passer directement à Coq: programmer en Coq, c'est écrire la preuve mathématique que l'algorithme qu'on veut écrire est correct, puis Coq génère automatiquement le code OCaml correspondant. Du coup, c'est des vraies maths, et impossible de laisser un bug trainer dans le code.
Bien sûr, ça demande un gros effort, et ça ne s'applique donc que dans des domaines où une telle sûreté est nécessaire : le compilateur Compcert a été écrit ainsi pour certains des logiciels embarqués dans les avions.
Le problème d'Haskell, c'est qu'un programme Haskell n'est lisible que de son auteur, et encore, pendant quelques mois. A force d'utiliser des identificateurs à 4 lettres, de la surcharge avec les classes de types et tous les symboles possibles et imaginables, pour pouvoir se vanter de la concision de leurs programmes, les développeurs Haskell rendent simplement leurs programmes immaintenables !
# A mi chemin ?
Posté par Firwen (site web personnel) . Évalué à -4.
Sinon, pour les gens qui ne sont pas nazi du typage, y a
def read_file(filename):
return open(filename).readlines()
( Godwin point +=1 )
[^] # Re: A mi chemin ?
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 6.
Pour la publication de Spying the World from your Laptop, nous avons fait de nombreuses analyses sur 500 millions d'adresses IP présentes sur le site PirateBay, les fichiers qu'ils téléchargeaient et leurs sessions sur plusieurs mois. Au début, l'équipe utilisait Python, pour des calculs relativement simples et sur qques millions d'adresses seulement. Finalement, nous avons changé pour OCaml, nous avons pu faire des calculs beaucoup plus complexes, obtenir les résultats beaucoup plus vite (et donc réduire les itérations pour obtenir les résultats intéressants), et sur l'ensemble des 500 millions d'adresses.
Outre l'intérêt de détecter les bugs avant de lancer les calculs, c'est la concision d'OCaml (écrire en qques lignes un calcul complexe sur le graphe), la compacité mémoire (le graphe complet tenait dans les 16 GB de RAM de ma machine) et les performances qui nous ont fait préférer OCaml à Python pour ces analyses, et pas une "idéologie du typage" comme tu le sous-entends !
PS: j'utilise
File.read_linespour OCaml, dans ma bibliothèque perso, j'écris rarement cette fonction, sauf pour montrer un exemple…[^] # Re: A mi chemin ?
Posté par Enjolras . Évalué à 7.
Tu as l'air de considérer "Nazi du typage" comme un défaut. Permets moi de te contredire. Dans la plupart des cas, un typage fort apporte beaucoup plus d'avantages que d'inconvénients.
Le premier avantage d'un bon système de type est la sûreté. Un système de type sûr rejette les programmes absurdes et sémantiquement invalides dont l'évaluation échouairait. Donc, même si on ne peut pas garrantir que le programme termine bien et qu'il fasse ce qu'on veut qu'il fasse (c'est le problème de l'arrêt, indécidable de toute manière), on peut au moins essayer de garratir que le code va s'éxécuter. Ce n'est clairement pas le cas de C, ni de python. En C, les programmes invalides qui segfault compilent souvent trés bien. Je ne dis pas qu'Ocaml ne segfault jamais, mais il faut aller s'amuser avec des fonctions un peu avancés et pousser le systéme de type dans ses retranchements pour y arriver.
Un autre avantage du typage statique fort, c'est qu'il permet de compiler un code plus efficace. En effet, si on ne connait pas le type des expressions pour une opération polymorphe, on est obligé de savoir traiter tout les cas, même si ce n'est pas forcément nécessaire. Exemple, l'expression + polymorphe qui sait prendre en compte plusieurs types. En Ocaml, les opérateurs ne sont pas polymorphes, ce qui évite d'avoir implictement des comportements auquel le développeur n'a pas pensé, comme ajouter un float et un int.
Le typage augmente aussi la lisibilité du code. Dans un bon code ocaml, en lisant le nom d'une fonction et sa signature, on a souvent une bonne idée de ce qu'elle fait.
Maintenant, les inconvénients. Souvent, les gens qui aiment le typage dynamique prennent comme argument qu'il est ennuyeux de déclarer le type des variables/fonctions en permanence. Ocaml n'a pas vraiment se problème, encore une fois grace à son système de type. Le compilateur utilise un algorithme d'inférence des types, qui permet, à partir d'une expression, d'en déduire sont type de manière déterministe. Dans la majorité des cas, (à moins d'utiliser des choses comme les foncteurs, ou les paramètres optionnels), on n'ajoute pas d'annotation de type. C'est le compilateur qui se charge de le faire pour nous, et qui, en prime, vérifie que le code est cohérent. Comme précisé dans la dépêche, Ocaml n'est pas plus verbeux que python.
Pour finir, je pense qu'il faut considérer le typage comme une énorme aide au développeur plutôt que comme une contrainte.
[^] # Re: A mi chemin ?
Posté par lasher . Évalué à 5.
Si ce n'était que ça … J'adorerais n'avoir que des bugs qui provoquent un segfault en C. Le problème d'un langage qui ne propose pas de typage fort est justement qu'à l'exécution, le programme pourrait continuer de tourner et même renvoyer un résultat incorrect, mais « réaliste » dans le contexte de la spécification du programme. La sureté des types permet justement de s'affranchir de ce problème. Après, OCaml propose un typage statique, mais on peut parfaitement proposer une sureté qui s'effectue dynamiquement (par exemple, Java propose un typage fort pour les types non-primitifs, mais une grande partie des problèmes de types n'est détectée qu'à l'exécution).
[^] # Re: A mi chemin ?
Posté par Enjolras . Évalué à 2.
Le typage ne résout pas vraiment ce problème… Il te faut un assistant de preuve et un compilateur prouvé si tu veux éviter ça. Le fait qu'ocaml n'ait pas de pointeurs ni de gestion mémoire manuelle évite en effet certains problèmes, le typage en évite quelques autres en évitant les cast implicites, mais bon, compiler en -Wall -Werror peut aider en C.
Le typage n'est pas non plus magique.
[^] # Re: A mi chemin ?
Posté par lasher . Évalué à 3.
Je parle bien entendu dans le contexte des interactions entre types. Les langages fortement typés empêchent justement de se retrouver bloqué à l’exécution pour des raisons de "mauvaises interactions" entre variables de types différents. Le C ne permet pas d’éviter ce genre d'erreur. OCaml, Java (pour les types non-primitifs), C++ (si si) proposent un typage fort, bien plus que le C. La vérification des types peut se faire statiquement ou dynamiquement, ça ne l’empêche pas d’être forte.
Et si, je maintiens, les erreurs liées aux types peuvent donner des résultats incorrects dans les langages faiblement typée tels que le C, qui sont parfois difficiles à comprendre ou même détecter. Le fait que le typages de OCaml soit statique est bien pratique pour détecter ce genre de problème a la compil', mais en Java on les détecterait à l’exécution avec une jolie exception.
[^] # Re: A mi chemin ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Pour être complet, on peut dire que l'on peut utiliser le typage un peu plus fortement que d'habitude pour interdire certaine forme de données qui sont en fait des bugs.
Par exemple, en C, on aura tendance à retourner un nombre positif en cas normal et -1 en cas d'erreur, en ocaml, on utilise le type "a' option".
On peut utiliser les type phantom pour typer différente type de string (raw, utf-8 ou binaire vs hexadécimal), ce qui est impossible en C.
Je suis sûr qu'il y a plein d'autres exemples.
"La première sécurité est la liberté"
[^] # Re: A mi chemin ?
Posté par Krunch (site web personnel) . Évalué à 2.
Je préfère les nazis du typage aux nazis de l'indentation :
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: A mi chemin ?
Posté par Zylabon . Évalué à 2.
Haha c'est drôle que tu dise ça parce qu'Haskell est encore pire au niveau de l'indentation. Des erreurs d’indentation provoquent des bugs stupide. Mais heureusement il est possible d'utiliser les accolades et les virgules pour contourner ce problème.
Please do not feed the trolls
[^] # Re: A mi chemin ?
Posté par Enjolras . Évalué à -1.
Au passage tu as lu le titre de la dépêche ? Ocaml a pas mal de différences avec Haskell. Déjà il n'est pas fonctionnel pur.
[^] # Re: A mi chemin ?
Posté par Zylabon . Évalué à 0.
Krunch n'a pas droit à la même remarque désobligeante et à coté de la plaque ? Mon commentaire n'avait pas grand chose à voir avec le sujet. En revanche vu qu'il était question de nazis du typage ET de nazis de l'indentation, Haskell est LA référence. Ensuite, Haskell ressemble énormément à ML, infiniment plus qu'Ocaml à python ou C.
C'est la mauvaise période du mois ?
Please do not feed the trolls
# Version fonctionnelle
Posté par Michaël (site web personnel) . Évalué à 8.
Voilà une proposition pour une version fonctionnelle (sans gestion des erreurs).
Je suis hyper heureux de la sortie de OCaml 4, préparez-vous à le voir arriver sous FreeBSD!
[^] # Re: Version fonctionnelle
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 5.
Il ne manquerait pas une petite inversion de la liste à la fin :
[^] # Re: Version fonctionnelle
Posté par Michaël (site web personnel) . Évalué à 3.
Si tout à fait! Merci.
[^] # Re: Version fonctionnelle
Posté par reno . Évalué à 1.
J'ai toujours du mal avec les langages qui préfèrent les math aux utilisateurs, je m'explique: pour moi une fonction a des entrées et des sorties mais sous prétexte qu'il y a la curryfication, au lieu d'avoir des fonction avec plusieurs entrées et plusieurs sorties, on a: fonction: entree1 -> entree2 -> … sortie1 -> sortie2 (1)
Beurk, ce n'est pas parce que la curryfication existe qu'il faut la montrer systématiquement!
1: par exemple si on tape le programme du dessus dans l'interpréteur OCaml on a en sortie:
val process_file : (in_channel -> 'a) -> string -> 'a = < fun >
mais la fonction dans le code du programme avait des entrées et des sorties, pourquoi l'interpréteur n'affiche pas:
val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
ça serait beaucoup plus fidèle au code..
[^] # Re: Version fonctionnelle
Posté par GNU_Eths . Évalué à 1.
J'ai l'impression que tu ne sais pas de quoi tu parle.
[^] # Re: Version fonctionnelle
Posté par reno . Évalué à 1.
C'est possible, mais il faudrait que tu m'explique en quoi je ne sais pas de quoi je parle!
Quand je définis une fonction f(x:int, y:int)->int et que l'interpréteur affiche
f: x:int -> y:int -> int (pas la vrai syntaxe d'OCaml) donc comme une fonction de fonction qui retourne un résultat alors qu'on lui a donné une fonction qui prend 2 valeurs et retourne un résultat.
Certes mathématiquement c'est la même chose, mais visuellement je trouve le choix d'OCaml (et d'Haskell) moins lisible..
[^] # Re: Version fonctionnelle
Posté par GNU_Eths . Évalué à 1.
La currification c'est juste le fait de découper l'application d'une fonction en plusieurs fois.
En C par exemple tu pourrais faire:
au lieux de:
Donc tu va récupérer le résultat de la fonction (ici 5) dans les deux cas en applicant y à la fonction f1.
Sauf que un cas est plus simple que l'autre.
Je ne vois pas il y aurait plusieurs sorties ou en quoi ça serais moins lisible ?
[^] # Re: Version fonctionnelle
Posté par reno . Évalué à 1.
Effectivement je m'était trompé sur le cas avec plusieurs sorties, il faut utiliser un tuple de données donc tu as:
entree1 -> … -> entreeN -> (sortie1, sortie2, …, sortieM)
mais ce que j'aimerais avoir moi c'est:
(entree1, … , entreeN) -> (sortie1, sortie2, …, sortieM)
ça rend l'affichage du type des entrées et des sorties identiques.
[^] # Re: Version fonctionnelle
Posté par GNU_Eths . Évalué à 1.
Je crois que tu n'as toujours pas saisie.
Pourquoi t'obstine-tu à vouloir des tuples ?
Que veux-tu dire par « l'affichage du type des entrées et des sorties identiques » ?
[^] # Re: Version fonctionnelle
Posté par reno . Évalué à -2.
Parce que normalement on a des fonctions a plusieurs entrées, quand je dit la fonction qui calcule l'aire d'un triangle, elle a pour paramètre la longueur et la hauteur donc si tu affiches
long -> haut -> résultat, ça ne correspond pas a ma vision normale d'une fonction a entrées multiple, un tuple de variable (j'ai bien compris que c'est possible en Ocaml, j'ai juste été surpris que ça ne soit pas la coutume).
Et en Ocaml, si tu veux avoir plusieurs sorties, tu es obligé d'utiliser un tuple pour les sorties, je trouve qu'il y a une certaine asymétrie mais bon c'est débatable.
[^] # Re: Version fonctionnelle
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 5. Dernière modification le 17 août 2012 à 19:17.
Il y a grosso-modo deux raisons: la première, c'est qu'il est possible en OCaml de faire une fonction qui prend un n-uplet d'argument, comme en C, et de tout programmer comme cela:
Tu peux généraliser la fonction précédente au nombre d'arguments que tu veux. Le compilateur natif d'OCaml est d'ailleurs assez intelligent pour compiler de la même façon un appel
f x yet un appelf (x,y)au niveau du code assembleur, c'est donc uniquement un choix du programmeur.La seconde raison, c'est effectivement qu'il est parfois très pratique d'écrire des fonctions auxquelles on ne fournit pas tous les arguments: par exemple, si je définis une fonction
println : out_channel -> string -> unit, je peux la faire itérer sur un répertoire pour afficher tous ses éléments de la façon suivante, puis définir des fonctions spécialisées pourstderretstdout:Le même programme à la C:
Personnellement, je trouve la version avec l'application partielle beaucoup moins verbeuse, mais les deux sont aussi efficaces l'une que l'autre…
[^] # Re: Version fonctionnelle
Posté par Michaël (site web personnel) . Évalué à 7.
L'interpréteur fait ce qu'on lui demande. Si tu veux définir une fonction dont la signature est
c'est possible, il suffit de changer la déclaration
comme te l'a déjà fait remarquer Fabrice. Bien que ces deux définitions soient très semblables, il existe une différence dont les conséquences pratiques sont très importantes: il est beaucoup plus facile d'appliquer partiellement la première version que la seconde.
Ainsi, si tu as un traitement
f: in_channel -> 'aque tu veux appliquer sur une liste de fichiersltu peux écrireavec la première version, tandis que la seconde t'oblige à introduire une fonction auxiliaire (on peut choisir une fonction anonyme) ce qui rend le code moins lisible.
Depuis que je travaille dans une boîte qui utilise C++ je suis très malheureux car:
— je redécouvre les charmes des boucles
for;— personne ne sait programmer.
# Librairie graphique sous ocaml
Posté par FueL . Évalué à 4.
Je profite de cette nouvelle, pour demander quelles sont les librairies graphiques utilisables avec ocaml notamment pour le dev d'interface graphique.
Il y'a bien Tcl/Tk, mais je n'ai pas l'impression qu'elle est beaucoup employée.
Il y'a également GTK visiblement, mais je n'ai pas vu beaucoup d'applications écrites en ocaml/GTK et il me semble que les dernières version de GTK ne sont plus supportées.
Je ne sais pas non plus si ce qu'offre GTK/ocaml est comparable à ce qu'offre Swing/java par exemple.
Si vous avez des retours d'expériences, ou connaissez un peu le sujet n'hésitez pas.
[^] # Re: Librairie graphique sous ocaml
Posté par Michaël (site web personnel) . Évalué à 5.
Les dernières versions de GTK ne sont effectivement pas supportées, mais le binding disponible est écrit à la main, d'où une interface très OCaml bien plus agréable à utiliser que l'interface C que j'ai longtemps pratiquée.
# types de données algébriques généralisés ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Quelqu'un aurait un exemple ? La page wikipedia est incompréhensible.
"La première sécurité est la liberté"
[^] # Re: types de données algébriques généralisés ?
Posté par Enjolras . Évalué à 2.
le manuel
[^] # Re: types de données algébriques généralisés ?
Posté par Ontologia (site web personnel) . Évalué à 2.
Disons que l'explication fournie par le manuel ne m'a toujours pas permis de comprendre les GADT..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: types de données algébriques généralisés ?
Posté par Enjolras . Évalué à 2. Dernière modification le 14 août 2012 à 08:07.
Hmm… Essaye ce papier alors peut être.
Ou de manière plus concrète, ce wikibook.
# Un petit merci
Posté par FReEDoM (site web personnel) . Évalué à -2.
J'en profite pour remercier le CAML et l'OCAML qui m'ont décidé a arrêté ma licence à Jussieu pour faire une école d'ingénieur.
13 ans plus tard je ne regrette toujours pas ce choix. Vraiment Merci.
[^] # Re: Un petit merci
Posté par Thom (site web personnel) . Évalué à 8.
Tu as préféré payer que réfléchir.
À réfléchir.
;)
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Un petit merci
Posté par FReEDoM (site web personnel) . Évalué à 1.
Ecole d'état donc je n'ai pas payé…
[^] # Re: Un petit merci
Posté par Enjolras . Évalué à 4.
Et c'est pour ça que tu es devenu un troll lourdaud alors que tu aurais pu apprendre les nuances de ce que tu critiques pour le troller dans les règles de l'art.
Think about that.
[^] # Re: Un petit merci
Posté par Almacha (site web personnel) . Évalué à 2.
Maintenant c'est le Scheme et le C qui sont enseignés en première année (j'encadre des TD et TP à Jussieu).
[^] # Re: Un petit merci
Posté par FReEDoM (site web personnel) . Évalué à 0.
Je pense que c'est une bonne chose. Heureusement on apprenait aussi le C, le Pascal, un dérivé de Prolog dont je ne me rappelle plus le nom et plein d'autre choses.
Oui mon troll est gros, mais je ne dis surtout pas que la FAC, et Jussieu en particulier sont nuls, loin de là. Mais pour avoir essayé de faire un simple tetris avec des textures en CAML, je pense qu'à l'époque ce langage était un langage d'étude uniquement sans trop d'application derrière.
# Pour tester ocaml
Posté par Sylvestre Ledru (site web personnel) . Évalué à 7.
Je trouve que cette application web de découverte de Ocaml particulièrement sympa et accessible pour découvrir le langage:
http://try.ocamlpro.com/
# Ça a l'air balèze en tout cas
Posté par jseb . Évalué à 4.
C'est amusant comme formulation, ça donne l'impression que OCaml est venu sur ses petites jambes et a codé tout seul pour gagner.
Plus sérieusement, cela démontre t-il la supériorité du codeur ou du langage, là est la question.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Ça a l'air balèze en tout cas
Posté par Michaël (site web personnel) . Évalué à 6.
Voilà un extrait du règlement:
De façon très explicite, ce sont les langages qui sont mis en avant par l'épreuve.
(Le principe est que tous les participants humains sont infiniment doués en programmation et ne sont limités que par leur outil. :)
[^] # Re: Ça a l'air balèze en tout cas
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 9.
Oui, on peut toujours dire que c'est les développeurs qui font la différence. Donc la conclusion est : les meilleurs développeurs codent souvent en OCaml… :-)
C'est ce que m'avait répondu l'un des développeurs de Xen-api: vers 2004, après avoir développé Xen, la jeune société XenSource avait embauché une trentaine de développeurs (Ruby,C,Python,etc.) pour développer la couche de communication pilotant les hyperviseurs Xen (15% du Cloud, vous connaissez Amazon EC2 ?). Deux ans plus tard, toujours pas de produit, quand ils recrutent 4 développeurs à Cambridge, qui devaient écrire la doc, mais comme le produit n'arrivait pas, ils se sont dit qu'ils pourraient écrire un petit proto de leur coté… en OCaml. Un an plus tard, XenSource sort son produit, c'est le proto OCaml qui est dedans (et y est toujours !), et ils sont rachetés par Citrix pour qques centaines de millions de dollars…
[^] # Re: Ça a l'air balèze en tout cas
Posté par chicco . Évalué à 2.
D'ailleurs cette année, la seule équipe qui, au second round, est encore dans les 5 premiers du classement à 24h et 72h, code en OCaml ( et pour certains, moulent par ici … ).
[^] # Re: Ça a l'air balèze en tout cas
Posté par Antoine . Évalué à 2.
Ou plutôt : les meilleurs développeurs qui participent à la compétition ICFP codent en OCaml.
Vu que ICFP veut dire (d'après son site Web) International Conference on Functional Programming, l'échantillon doit être assez biaisé.
[^] # Re: Ça a l'air balèze en tout cas
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 2.
Il suffit de regarder les équipes participantes des concours des années précédentes pour se rendre compte que cette compétition a largement dépassé le cercle de la conférence pour toucher tous les bons développeurs du monde entier, et tous les langages sont largement représentés.
Cela dit, c'est facile de tester: participez l'année prochaine, et vous verrez où vous vous classez !
[^] # Re: Ça a l'air balèze en tout cas
Posté par Antoine . Évalué à 0.
Mmmh, c'est scientifique, ça.
Ah, « tous » ? vraiment ?
J'en ai un peu rien à battre, à vrai dire :)
(et les bons développeurs de ma connaissance non plus, je crois)
[^] # Re: Ça a l'air balèze en tout cas
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 3.
Oui, merci d'insister sur ce point, c'est ce que font les scientifiques, ils vérifient les faits, et pour cela, ils font des expériences, ou examinent des événements du passé s'ils ne peuvent pas les tester facilement. Donc, oui, un scientifique irait examiner les équipes des concours précédents, pour déterminer combien de programmeurs ont participé, d'où ils vennaient, et quels langages ils représentaient.
Ben alors, pourquoi tu réponds ???
[^] # Re: Ça a l'air balèze en tout cas
Posté par Antoine . Évalué à 1.
Et l'échantillon est constitué / sélectionné comment ? Sérieusement, si c'est juste sur la base du volontariat, les résultats n'ont aucune valeur statistique.
Parce que l'argument insinuant qu'OCaml est meilleur sous prétexte que des développeurs OCaml gagnent régulièrement dans un concours de programmation donné n'a aucune valeur si l'échantillon n'est pas rigoureusement constitué.
(il y a un autre problème à examiner, à savoir les règles pour gagner le concours et leur pertinence en fonction de la question posée ; mais bon, tant que l'échantillon n'a pas l'air rigoureux, inutile d'aller plus loin)
Note que des études sérieuses ont été faites concernant la productivité de différents langages de programmation. Je n'ai pas les références, et je ne sais pas si OCaml était inclus, mais ça doit se retrouver.
[^] # Re: Ça a l'air balèze en tout cas
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 2.
Merci en tout cas pour cette discussion, elle attire l'attention sur le prestigieux concours ICFP, qui mérite d'être connu de tous les développeurs ! La prochaine session aura lieu en juillet 2013, ça dure normalement 3 jours, en équipe, mais il y a une session "light" d'un jour seulement pour ceux qui ont une vraie vie ;-)
[^] # Re: Ça a l'air balèze en tout cas
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 1.
Tiens, un autre indice que le concours ICFP est bien connu, une News sur ce forum datant de 2002 et relatant la victoire d'une équipe en OCaml (et en second, d'une équipe en C) !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.