• [^] # Re: Perl 6 ?

    Posté par . En réponse au journal Sortie de Perl 5.14.0. Évalué à 4.

    Un peu comme en C et tout un tas d'autres langages.

    Tu penses que c'est un bon point pour OCaml d'être comparé au C ? :-)

    Tu aurais du garder ton programme :)

    C'était dans des contextes différents en fait. Et c'est pas que la sortie d'ocamldep n'est pas bien triée, c'est plutôt qu'il ne fait pas ce dont j'avais besoin ici.

    En gros, le cas d'utilisation, c'est que j'ai une liste de .ml dans un ordre quelconque, et je dois les compiler en .o pour les linker avec du C++ derrière. ocamldep est incapable de me sortir les trucs dans le bon format (il ne sait générer que des foo.cmo: foo.cmi et foo.cmx: foo.cmo, ou alors la forme « brute » qui est « a: b c ». Dans tous les cas, avoir besoin d'ocamldep pour linker son binaire c'est honteux : pourquoi est-ce que le linker d'OCaml ne sait pas faire ce travail tout seul ?

    C'est ça, si tu veux profiter des multiples processeurs il faut forker ton processus.

    Et induire une plus grosse utilisation de mémoire et des IPC. Cool.

    De ces inconvénients je retiens surtout la petite dimension de la communauté d'utilisateur, qui implique un nombre assez restreint de contributions de bibliothèques.

    Il y a aussi un autre problème que je vais illustrer par deux exemples. Je cherche une lib OCaml qui binde OpenGL. J'ai le choix entre LablGL, glcaml, glmlite et un autre dont j'ai plus le nom en tête. Pareil pour SDL : sdlcaml et ocamlsdl. Sans compter que la plupart des ces libs sont buggées et non maintenues (il y a des bouts de l'interface SDLmixer d'OCamlSDL qui segfaultaient systématiquement à cause d'une typo dans le code C il y a environ un an, c'est peut-être encore le cas, j'en sais rien).