Drup a écrit 9 commentaires

Il est tellement moche que je n'oserais pas mettre un lien

Et tu ne t'es dit a aucun moment que peut être, juste peut être, tu essayais de forcer les idiomes haskell en OCaml ?

La monade reader est un artifice Haskellien pour palier aux restrictions sur les effets de bords. Elle ne sert rigoureusement a rien en caml.

OCaml a ses propres idiomes et essayer d'écrire du Haskell en OCaml termine tout aussi bien que d'essayer d'écrire du C en python. C'est d'autant plus vrai quand tu rends volontairement le code OCaml encore plus lourd qu'il ne devrait l'être.

Effectivement, la spec complète est un peu plus longue, car il y a beaucoup de bruit typique des RFC dedans.

Je pensais a la grammaire quand j'ai dit ça et elle est, pour le coup, excessivement courte.

Je répond en m'auto-citant (et c'est valable pour la plupart des autres commentaires aussi) :

Si vous voulez un truc plus éditable par des humains (pour les fichiers de confs), utilisez toml.

YAML n'a aucun intérêt pour des données manipulées par un programme.

YAML est un format de donnée excessivement complexe, affreux à implémenter, dont la définition n'est pas assez précise.

JSON est un format très simple, dont la spec est limpide et tient en une demi page. Il est d'autant plus facile à implémenter (et bien mieux répandu que YAML).
YAML étant un super set de JSON, je suis assez convaincu que la plupart des gens qui émettent du YAML émettent 90% de JSON (évidement, il y a 10% qui font foirer …).

S'il vous plait, utilisez JSON.

Si vous voulez un truc plus éditable par des humains (pour les fichiers de confs), utilisez toml.

Le manque de bibliothèque est loin d’être aussi terrible que les gens ici l'affirment. Il y a des domaines sous représentés (la 3D, le calcul numérique), mais tu as déjà énormément de chose, et souvent d'une très bonne qualité.

Tu as un besoin précis qui n'est pas couvert, ou alors c'est une affirmation générale "la communauté est plus petite, il manque forcement des bibliothèques" ?

pwgen -yncC 10

Et tu en prends un qui sonne bien.

Pour mon cerveau, ça marche pas mal.

Tu as des informations ou des références sur l'utilisation de parmap sur des gros calculateurs (avec un grand nombre de cœurs).

Pas vraiment, Je m’intéresse à ces histoires de hautes perfs uniquement d'assez loin, par curiosité. Je sais que le mec de SPOC a un pied dans la communauté HPC. Une vidéo de présentation (en français !) est disponible ici. Techniquement, SPOC fait tourner sur n'importe quoi openCL, donc ça inclut les multi-coeurs pas trop vieux.

Je pense que c'est surtout une question de culture et d'enseignement.
Souvent, les gens n'ont jamais fait (je veux dire, vraiment fait, pas juste vu de loin) de prog fonctionnel de leur vie et se disent "ohlala, la syntaxe n'est pas C-like, c'est trop compliqué !". C'est un peu le même syndrome que "Les maths, c'est compliqué !" sans même avoir lu l’énoncé du problème.
A ce niveau la, Rust a l'avantage
1) d'avoir une syntaxe qui ressemble a du C;
2) de ne pas trop se vendre comme un langage fonctionnel;
3) d’être amené par Mozilla, et pas par "une bande d'universitaire qui ne savent faire que des langages jouets" (rigolez pas, on me l'a déjà sorti).

Et pour faire de la parallélisation sur List.map, tu peux utiliser , ça marche très bien. Concernant le boulot de Luca, Il a un modèle de concurrence qui permet de faire des maps parallèles sans soucis. Attends de voir ce qu'il a fait avant de tout balancer. Récemment, il y a aussi eu Spoc qui promet des choses intéressantes et quelques autres avancées. Le parallèle en ocaml n'est pas complètement mort, bien au contraire.

Le but des deux langages est très différent, principalement du au fait qu'ATS n'est qu'a moitié un langage de programmation l'autre moitié étant une theorem prover (comme Coq).
On peut tracer un parallèle entre Rust/ATS et Haskell/Agda.

ATS dispose des types dépendants, ce qui veut dire que les types sont manipulables comme des valeurs et que les valeurs peuvent apparaitre dans les types. Ça semble simple dit comme ça, mais ça ne l'est pas du tout. Le typechecking devient très compliqué et demande souvent plus d'annotation, en contrepartie on peut vérifier statiquement bien plus de chose.

Un exemple : on peut encoder dans les types que les accès tableaux ne sont jamais out of bound. C'est génial ! Oui, mais ca veut dire que dès que tu fais un accès, tu dois prouver (via des manipulations sur les types, qui sont parfois devinée par le compilateur, mais pas toujours) que l'entier que tu utilises est bien dans les bornes. Ca c'est un exemple simple, mais on peut encoder des choses bien plus complexes.

Je ne sais pas trop comment ATS se comporte vis a vis de la terminaison, mais en Agda, tout programme doit terminer, il sait souvent le deviner tout seul .. mais pas toujours, et dans ce cas, il faut fournir la preuve.

La, on atteins un point ou il faut choisir : soit tu as de plus en plus de type safety, au prix d'annotations et de convolution parfois véritablement complexes, soit tu laisses passer des choses, mais ton compilateur sait inférer tout ce dont il a besoin.

Je me suis un peu étalé, mais je pense que ça répond a la question.