Je trouve la généricité, les modules très utile. Mais je trouve que leur forme dans ocaml est très complexe et très peu lisible. Cela parait peut être évident pour toi qui est tombé dedans que tu es petit. Mais pour un concept complexe, il faut qu'il ressemble le plus possible à quelques choses de connu (principe UX de moindre surprise). Les modules ressemblent ici vaguement à des objets, avec des définitions de type dedans, mais avec une autre syntaxe.
En fait, je pense qu'il doit être possible de proposer des modules en GO mais avec une syntaxe ultra simplifié pour la compréhension.
Genre :
package toto (type t, int i)
func sort(tab t[i]) {…
import "toto"(int, 1024) -> l'idéal serait d'avoir un seul module instancié pour ce couple de paramètre
Pour l’extension d'un package, j'imagine qu'il doit y avoir déjà l'équivalent d'un "open".
En fait, je pensais au cas d'usage qui reviennent au même. Dans l'esprit, c'est 3 façon d'écrire la même chose, c'est anti-ergonomique, même si c'est formel.
let rp : pt_2D = {x = 1.0; y = 2.0}
let op : obj_pt_2d = object method x = 1.0 method y = 2.0 end
module MP : mod_pt_2D = struct let x = 1.0 let y = 2.0 end
Ils veulent des exemples, et nous on voudrait les types sum. Ils manquent sans doute une bonne explication entre les 2.
L'idéal serait de faire la même chose pour transformer les packages en module, en rajoutant une déclaration "parameter" pour définir des paramètres à remplir à l'import d'un package ou simplement d'ajouter une liste de paramètre à la déclaration de package, puis de fixer un moyen de créer des package "complet" avec ses paramètres. Cela évite un peu la duplication de code, si l'instanciation est faite une seul fois. Si la syntaxe de ces paramètres est exactement symétrique avec des paramètres de fonction, cela devrait rester simple. Il reste la création de signature de package dont je ne vois pas trop à quoi il pourrait ressembler en go. L'idéal serait qu'un package soit à la fois une signature de module et un module, c'est plus simple.
Les modules permettent de pousser la généricité du code à un niveau inaccessible aux enregistrements et aux objets.
J'avais bien compris. Par contre, ce n'est pas du tout évident en lisant tes exemples. Et pourquoi 3 syntaxes différentes pour faire la même chose ou presque ?
"Il a comparé Linux, en 1992 quand Torvalds était encore qu'un étudiant, qu'il ne lui donnerait même pas la moyenne pour ce projet à cause de ce choix architectural dépassé."
Et on peut voir que Linus avait raison. Les tentatives de micronoyau ont tous abandonné, ou on finit avec des très gros noyau pour des raisons de performances (windows NT, le truc d'apple,…). Rien ne va plus vite qu'un appel de fonction.
Si tu veux de la sécurité, il faudrait activer les protections mémoires dans le noyau lui-même( avec une gestion de droit interne). Il le font bien maintenant même pour les DMA.
C'est démontré maintenant? Parce que j'avais retenu que le Go est lent.
En fait, c'est compliqué :
- go est un langage compilé, il n'a pas de warm-up time à la java et n'a pas de load d'une énorme jvm
- go n'a pas de fonction virtuelle, ce qui peut avoir un cout en java dans les piles d'appel de library
- le compilo go sait choisir entre allouer une variable ou la mettre dans la stack de la fonction, la pression sur la mémoire est moins forte (moins de boxing), et le Gc est largement au niveau de celui de java
- le modèle concurrent de Go est limpide et facile, il monte très bien à l'échelle (pas besoin d'être un dieu pour utiliser 20 cpu)
Donc, dans le cas général, d'un programme d'une taille raisonnable, go sera rapide, dans le cas d'un programme optimisé java sera plus rapide grâce au compilateur runtime.
Je n'ai pas eu le choix. Je voulais garder ocaml, mais pour faire un server web, c'est juste pas possible. ocsigen est peut être très bien, mais il faut un bac+12 en théorie des langages pour comprendre l'exemple de 100 lignes, en plus, ce n'est plus vraiment du ocaml.
La simplicité de go me repose l'esprit. Tu retrouves toujours les mêmes pattern de code, tu rentres en 10s dans un nouveau code. Tu ne passes pas ton temps sur une nouvelle particularité du langage. J'aime bien aussi le système d'interface qui rend inutile les class mère, ce qui permet d'avoir plus de réutilisation de code.
Tu ne travailles pas dans l'industrie, je me trompe ? Personne ou presque n'utilise de langage si avancé que ça. Un utilisateur d'ocaml/scala/haskell est vu comme un fou avant-gardiste. Les principaux langages sont toujours javascript, php, C, C++, Java, C#, perl, Go, ruby…
si elles demandaient d'introduire des choses difficiles à formaliser dans le langage.
Non pas seulement. Difficile à comprendre par exemple, le comportement de la généricité avec les sous classe, le comportement de l'héritage multiple en diamant, etc… La gestion des multiples constructeur en C++ qui nécessite de bien comprendre le fonctionnement sous-jacent.
En Ocaml, le code de base ne me pose pas de problème, si tu joues avec les modules et leur définition et un gadt au milieu, je vais beaucoup transpirer.
A l'inverse, l'immutabilité de Ocaml permet d'éviter le concept de pointeur que tout débutant déteste.
Bonne question : Vitesse de compilation, sécurité plus simple qu'en C++, un seul binaire : zéro runtime mammouth, faire un serveur web performant en 3 ligne, simplicité (beaucoup moins de blague que C++, ou de gestion mémoire que Rust), plus performant que Java.
C'est sûr qu'il ne faut pas coder en go comme en java.
1) pour avoir des briques de base sur lesquelles réfléchir
2) parce que la beauté théorique n'est qu'une des multiples dimensions d'un langage (clarté, simplicité, debug, vitesse de compile, performance au runtime, …)
Si on ne spécifiait tout qu'une seule fois, sans jamais aucun recouvrement, on ne pourrait pas détecter automatique d'incohérence.)
Je suis assez d'accord avec toi. Mais tu peux rajouter une dimension : on peut vouloir forcer l'usage d'une library d'une certaine façon (contrat). Ainsi, on évite les bug d'un usage de travers. Il y a duplication, mais dans le temps.
Cela me rappelle une discussion sur un codeur MS qui avait rajouter des checks de cohérence avec des assert() dans une lib. Ses utilisateurs râlaient, mais cela voulait surtout dire que des bug étaient masqués.
D'ailleurs si tu regardes la normes aéronautiques (FACE), il y a une description des variables d'entrée assez mortel avec 4 dimensions (ex: vitesse, vitesse par rapport au sol, en m/s, en fixe 32 bit de 0 à 300). Cela permet de coller des lib qui traitent de vitesse et de faire des conversions automatiques par génération de code statiques si l'unité n'est pas la bonne.
Par contre ça en a beaucoup pour la clarté du programme (sans annotation de type, c'est plus dur de lire le code et de comprendre ce qu'il fait), et la redondance apportée par ces annotations permet à nos outils (les compilateurs) de dire parfois "attention, tu utilises la variable x comme un pointeur, mais tu l'as déclarée comme un entier, n'y a-t-il pas confusion ?", ce qui élimine des bugs.
Il me semble que tu te limites trop. Tu embarques ça dans le terme "outils", mais je ne pense pas qu'un code informatique doit se limiter à du texte dans un éditeur de fichier. Eclipse introduit des sorte de lien hypertexte, l'auto-completion et la vérification d'erreur en ligne, cela aide beaucoup le codeur. Il y a une masse d'information qui pourrait être fournis par l'outil de dev, qui ne nécessite pas une notation du codeur. L'idée est qu'un codeur veut de la concision, quitte à faire trop de raccourci (oublies de vérifier les erreur ou les exceptions), mais un relecteur veut de la clarté (il est plus facile de vérifier l'oublie d'un test d'erreur qu'un catch d'exception). Un codeur veut un texte pour décrire ses objets rapidement, un relecteur veut un diagramme de classe ou de machine d'état ou de block pour tout appréhender rapidement.
Je pense vraiment qu'il faut arrêter de voir la sémantique d'un langage uniquement à travers une suite de caractère. Et la meilleur méthode pour écrire un code, n'est pas forcément la meilleur pour le relire.
ocaml sans l'objet et sans le gadt, et le coté module illisible pour non-initié est un super langage simple, mais avec un lib pauvre.
ELM http://elm-lang.org/ est un nouveau langage qui veut reprendre les bonne pratique des nouvelles lib javascript mais vérifier correctement l'usage (react, DOM virtuel…). Il inclus le type sum. C'est un truc à regarder.
Avec la lib de base de Ocaml tu ne fais pas grand chose. En dehors d'un "filtre unix", tu n'as rien sous la main (tout ce qui prend des fichiers en entré et qui produit une sortie). Tout ce qui est serveur ou interface graphique, est obsolète ou niveau bricolage dans ocaml.
Pour faire un compilateur ocaml est génial, pour du web ou une interface graphique, il faut tout refaire soi-même. c'est d'ailleurs pour ça que j'ai regardé golang.
Et si ocaml stagne, c'est Rust qui risque de lui prendre un peu de sa niche écologique restante.
une question d'approche par la simplicité (au risque d'être simpliste parfois), optique qui n'est pas du tout à la mode et qui manquait visiblement à pas mal de monde ; je pense que des langages avec des systèmes de types plus évolués pourraient essayer de s'en inspirer un peu.
Cela me rappelle ocaml qui est léger graphiquement en virant les "," et les "()" avec des mots clef simple comme "let" et "let in", et puis ils ont rajouté un tas de machin comme ".+", le truc le pire étant camlp4 et les notations à base de "<>" et autre "%". qui ressemble à du "modem line noise".
Un des trucs que j'aimais bien dans Lisaac, c'était sa syntaxe à mot clef. C'est à dire que l'on pouvait écrire des fonctions "à trou" genre func CreateUnObjet (string name) with (string comment). Dans les fonctions à grand nombre de paramètres, c'est plus lisible et moins lourd que les langages utilisant le nom du paramètres (ada, vhdl).
Un des trucs pourris mais finalement génial de ocaml, c'était l'absence d'espace de nom pour les type sum. Je pense que c'est génial, car il n'y a jamais aucune ambiguïté sur le mauvais usage d'un type. En cas d'usage de name space, celui-ci est souvent sous-entendu ce qui peut poser des problèmes pour retrouver le bon.
C'est hors du cadre discuté dans mon journal ci-dessus, et personellement je ne comprends pas encore très bien, scientifiquement, l'articulation entre un langage de programmation et les outils qui l'entourent.
Il faut voir cela comme une tache à accomplir avec une quantité non négligeable de code déjà existante. Plus le cycle "mise en avant du problème - correction - test", est rapide plus les développeurs sont contents. Cela peut venir d'outils de check statique ou de vitesse d’exécution (compilation rapide, déploiement simple, lancement de teste en une seul ligne de commande standardisé, possibilité d'instrumentation, etc…)
Le cerveau n'est pas fait pour la logique. Comprendre une suite de if avec un simple AND ou OR est facile, si le nombre de variable augmente, il est souvent bien plus lisible d'imbriquer les if ou d'utiliser un pattern matching ocaml.
Go est un langage simple qui permet d'être productif bien plus que les autres.
Les generics peuvent aussi devenir anti-productif, et complexifie beaucoup les outils. Type sum, oui cela serait bien mais une méthode tagless final, avec transformation des package en module, cela serait peut être mieux. J'aimerais beaucoup des packages avec des paramètres.
clairement aux antipodes de la plupart des systèmes à la pointe de la recherche (par exemple mezzo, ou même rust) qui sont plutôt du coté fonctionnel avec un typage expressif.
Les langages à la pointe de la recherche sont loin d'être les langages de programmation de choix. Ce n'est pas Ocaml, haskell, prolog ou autre qui sont le plus utilisé. C'est les trucs bricolés comme javascript, php, voir java, c++ ou perl.
Un programmeur moyen est incapable d'utiliser un type gadt complexe.
Je me demande si des ergonomes se sont penché sur les langages. J'imagine qu'il aimerait plutôt des dessins type UML simplifié pour décrire les objets, la preuve : on documente de cette façon. Mais je ne connais pas beaucoup de langages qui fonctionnent avec une parti graphique non anecdotique.
Je trouve aussi qu'il n'y a jamais de moyen pour forcer une architecture. Dans un gros projet, le plat de spaghetti arrive quand tout dépend de tout, alors qu'il faudrait définir quel ensemble de module ne doit dépendre de rien et quelle sont les groupes de modules indépendants. En gros, il faudrait pouvoir décrire la barrière conceptuelle qu'il y a entre un ensemble de classe/type à la manière des membres privés d'un objet. C'est souvent ce mélange à terme qui rend les micro-services à la mode : pouvoir séparer "violemment" le code.
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je trouve la généricité, les modules très utile. Mais je trouve que leur forme dans ocaml est très complexe et très peu lisible. Cela parait peut être évident pour toi qui est tombé dedans que tu es petit. Mais pour un concept complexe, il faut qu'il ressemble le plus possible à quelques choses de connu (principe UX de moindre surprise). Les modules ressemblent ici vaguement à des objets, avec des définitions de type dedans, mais avec une autre syntaxe.
En fait, je pense qu'il doit être possible de proposer des modules en GO mais avec une syntaxe ultra simplifié pour la compréhension.
Genre :
package toto (type t, int i)
func sort(tab t[i]) {…
import "toto"(int, 1024) -> l'idéal serait d'avoir un seul module instancié pour ce couple de paramètre
Pour l’extension d'un package, j'imagine qu'il doit y avoir déjà l'équivalent d'un "open".
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5.
En fait, je pensais au cas d'usage qui reviennent au même. Dans l'esprit, c'est 3 façon d'écrire la même chose, c'est anti-ergonomique, même si c'est formel.
let rp : pt_2D = {x = 1.0; y = 2.0}
let op : obj_pt_2d = object method x = 1.0 method y = 2.0 end
module MP : mod_pt_2D = struct let x = 1.0 let y = 2.0 end
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Franchement écrit une proposition propre sur les type sum et poste un lien sur le blog de go 2.0
https://github.com/golang/go/wiki/ExperienceReports
Ils veulent des exemples, et nous on voudrait les types sum. Ils manquent sans doute une bonne explication entre les 2.
L'idéal serait de faire la même chose pour transformer les packages en module, en rajoutant une déclaration "parameter" pour définir des paramètres à remplir à l'import d'un package ou simplement d'ajouter une liste de paramètre à la déclaration de package, puis de fixer un moyen de créer des package "complet" avec ses paramètres. Cela évite un peu la duplication de code, si l'instanciation est faite une seul fois. Si la syntaxe de ces paramètres est exactement symétrique avec des paramètres de fonction, cela devrait rester simple. Il reste la création de signature de package dont je ne vois pas trop à quoi il pourrait ressembler en go. L'idéal serait qu'un package soit à la fois une signature de module et un module, c'est plus simple.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
tu devrais lire le lien sur la discussion sur les types sum.
Il demande par exemple comment filtrer "int | interface{}" sachant que interface{} fonctionne pour tout.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
J'avais bien compris. Par contre, ce n'est pas du tout évident en lisant tes exemples. Et pourquoi 3 syntaxes différentes pour faire la même chose ou presque ?
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Oui mais si tu passes un tel GC sur 32 Go de RAM tu te retrouves avec des pauses de plusieurs secondes. C'est rarement acceptable.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3. Dernière modification le 19 octobre 2017 à 10:24.
Et on peut voir que Linus avait raison. Les tentatives de micronoyau ont tous abandonné, ou on finit avec des très gros noyau pour des raisons de performances (windows NT, le truc d'apple,…). Rien ne va plus vite qu'un appel de fonction.
Si tu veux de la sécurité, il faudrait activer les protections mémoires dans le noyau lui-même( avec une gestion de droit interne). Il le font bien maintenant même pour les DMA.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
En fait, c'est compliqué :
- go est un langage compilé, il n'a pas de warm-up time à la java et n'a pas de load d'une énorme jvm
- go n'a pas de fonction virtuelle, ce qui peut avoir un cout en java dans les piles d'appel de library
- le compilo go sait choisir entre allouer une variable ou la mettre dans la stack de la fonction, la pression sur la mémoire est moins forte (moins de boxing), et le Gc est largement au niveau de celui de java
- le modèle concurrent de Go est limpide et facile, il monte très bien à l'échelle (pas besoin d'être un dieu pour utiliser 20 cpu)
Donc, dans le cas général, d'un programme d'une taille raisonnable, go sera rapide, dans le cas d'un programme optimisé java sera plus rapide grâce au compilateur runtime.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je n'ai pas eu le choix. Je voulais garder ocaml, mais pour faire un server web, c'est juste pas possible. ocsigen est peut être très bien, mais il faut un bac+12 en théorie des langages pour comprendre l'exemple de 100 lignes, en plus, ce n'est plus vraiment du ocaml.
La simplicité de go me repose l'esprit. Tu retrouves toujours les mêmes pattern de code, tu rentres en 10s dans un nouveau code. Tu ne passes pas ton temps sur une nouvelle particularité du langage. J'aime bien aussi le système d'interface qui rend inutile les class mère, ce qui permet d'avoir plus de réutilisation de code.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Tu ne travailles pas dans l'industrie, je me trompe ? Personne ou presque n'utilise de langage si avancé que ça. Un utilisateur d'ocaml/scala/haskell est vu comme un fou avant-gardiste. Les principaux langages sont toujours javascript, php, C, C++, Java, C#, perl, Go, ruby…
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Non pas seulement. Difficile à comprendre par exemple, le comportement de la généricité avec les sous classe, le comportement de l'héritage multiple en diamant, etc… La gestion des multiples constructeur en C++ qui nécessite de bien comprendre le fonctionnement sous-jacent.
En Ocaml, le code de base ne me pose pas de problème, si tu joues avec les modules et leur définition et un gadt au milieu, je vais beaucoup transpirer.
A l'inverse, l'immutabilité de Ocaml permet d'éviter le concept de pointeur que tout débutant déteste.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Bonne question : Vitesse de compilation, sécurité plus simple qu'en C++, un seul binaire : zéro runtime mammouth, faire un serveur web performant en 3 ligne, simplicité (beaucoup moins de blague que C++, ou de gestion mémoire que Rust), plus performant que Java.
C'est sûr qu'il ne faut pas coder en go comme en java.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5. Dernière modification le 18 octobre 2017 à 17:17.
1) pour avoir des briques de base sur lesquelles réfléchir
2) parce que la beauté théorique n'est qu'une des multiples dimensions d'un langage (clarté, simplicité, debug, vitesse de compile, performance au runtime, …)
"La première sécurité est la liberté"
[^] # Re: Concernant la clarté
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je suis assez d'accord avec toi. Mais tu peux rajouter une dimension : on peut vouloir forcer l'usage d'une library d'une certaine façon (contrat). Ainsi, on évite les bug d'un usage de travers. Il y a duplication, mais dans le temps.
Cela me rappelle une discussion sur un codeur MS qui avait rajouter des checks de cohérence avec des assert() dans une lib. Ses utilisateurs râlaient, mais cela voulait surtout dire que des bug étaient masqués.
D'ailleurs si tu regardes la normes aéronautiques (FACE), il y a une description des variables d'entrée assez mortel avec 4 dimensions (ex: vitesse, vitesse par rapport au sol, en m/s, en fixe 32 bit de 0 à 300). Cela permet de coller des lib qui traitent de vitesse et de faire des conversions automatiques par génération de code statiques si l'unité n'est pas la bonne.
"La première sécurité est la liberté"
[^] # Re: Concernant la clarté
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5.
Il me semble que tu te limites trop. Tu embarques ça dans le terme "outils", mais je ne pense pas qu'un code informatique doit se limiter à du texte dans un éditeur de fichier. Eclipse introduit des sorte de lien hypertexte, l'auto-completion et la vérification d'erreur en ligne, cela aide beaucoup le codeur. Il y a une masse d'information qui pourrait être fournis par l'outil de dev, qui ne nécessite pas une notation du codeur. L'idée est qu'un codeur veut de la concision, quitte à faire trop de raccourci (oublies de vérifier les erreur ou les exceptions), mais un relecteur veut de la clarté (il est plus facile de vérifier l'oublie d'un test d'erreur qu'un catch d'exception). Un codeur veut un texte pour décrire ses objets rapidement, un relecteur veut un diagramme de classe ou de machine d'état ou de block pour tout appréhender rapidement.
Cette vidéo est absolument à voir : https://www.youtube.com/watch?v=PUv66718DII C'est un rêve de dev d'avoir une boucle de rétroaction aussi rapide.
Je pense vraiment qu'il faut arrêter de voir la sémantique d'un langage uniquement à travers une suite de caractère. Et la meilleur méthode pour écrire un code, n'est pas forcément la meilleur pour le relire.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je suis du même point de vue.
ocaml sans l'objet et sans le gadt, et le coté module illisible pour non-initié est un super langage simple, mais avec un lib pauvre.
ELM http://elm-lang.org/ est un nouveau langage qui veut reprendre les bonne pratique des nouvelles lib javascript mais vérifier correctement l'usage (react, DOM virtuel…). Il inclus le type sum. C'est un truc à regarder.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Je pense que Renaut veut dire que la propreté formelle d'un langage ne le rend pas forcément clair et concis. C'est mieux, mais on peut vivre sans.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Avec la lib de base de Ocaml tu ne fais pas grand chose. En dehors d'un "filtre unix", tu n'as rien sous la main (tout ce qui prend des fichiers en entré et qui produit une sortie). Tout ce qui est serveur ou interface graphique, est obsolète ou niveau bricolage dans ocaml.
Pour faire un compilateur ocaml est génial, pour du web ou une interface graphique, il faut tout refaire soi-même. c'est d'ailleurs pour ça que j'ai regardé golang.
Et si ocaml stagne, c'est Rust qui risque de lui prendre un peu de sa niche écologique restante.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Cela me rappelle ocaml qui est léger graphiquement en virant les "," et les "()" avec des mots clef simple comme "let" et "let in", et puis ils ont rajouté un tas de machin comme ".+", le truc le pire étant camlp4 et les notations à base de "<>" et autre "%". qui ressemble à du "modem line noise".
Un des trucs que j'aimais bien dans Lisaac, c'était sa syntaxe à mot clef. C'est à dire que l'on pouvait écrire des fonctions "à trou" genre func CreateUnObjet (string name) with (string comment). Dans les fonctions à grand nombre de paramètres, c'est plus lisible et moins lourd que les langages utilisant le nom du paramètres (ada, vhdl).
Un des trucs pourris mais finalement génial de ocaml, c'était l'absence d'espace de nom pour les type sum. Je pense que c'est génial, car il n'y a jamais aucune ambiguïté sur le mauvais usage d'un type. En cas d'usage de name space, celui-ci est souvent sous-entendu ce qui peut poser des problèmes pour retrouver le bon.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Il faut voir cela comme une tache à accomplir avec une quantité non négligeable de code déjà existante. Plus le cycle "mise en avant du problème - correction - test", est rapide plus les développeurs sont contents. Cela peut venir d'outils de check statique ou de vitesse d’exécution (compilation rapide, déploiement simple, lancement de teste en une seul ligne de commande standardisé, possibilité d'instrumentation, etc…)
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Le cerveau n'est pas fait pour la logique. Comprendre une suite de if avec un simple AND ou OR est facile, si le nombre de variable augmente, il est souvent bien plus lisible d'imbriquer les if ou d'utiliser un pattern matching ocaml.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
En tout cas, si vous faites un papier sur le langage, signalez-le dans : https://github.com/golang/go/wiki/ExperienceReports
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Go est un langage simple qui permet d'être productif bien plus que les autres.
Les generics peuvent aussi devenir anti-productif, et complexifie beaucoup les outils. Type sum, oui cela serait bien mais une méthode tagless final, avec transformation des package en module, cela serait peut être mieux. J'aimerais beaucoup des packages avec des paramètres.
Les langages à la pointe de la recherche sont loin d'être les langages de programmation de choix. Ce n'est pas Ocaml, haskell, prolog ou autre qui sont le plus utilisé. C'est les trucs bricolés comme javascript, php, voir java, c++ ou perl.
Un programmeur moyen est incapable d'utiliser un type gadt complexe.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Le système d'interface règle un bon paquet de problème.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je me demande si des ergonomes se sont penché sur les langages. J'imagine qu'il aimerait plutôt des dessins type UML simplifié pour décrire les objets, la preuve : on documente de cette façon. Mais je ne connais pas beaucoup de langages qui fonctionnent avec une parti graphique non anecdotique.
Je trouve aussi qu'il n'y a jamais de moyen pour forcer une architecture. Dans un gros projet, le plat de spaghetti arrive quand tout dépend de tout, alors qu'il faudrait définir quel ensemble de module ne doit dépendre de rien et quelle sont les groupes de modules indépendants. En gros, il faudrait pouvoir décrire la barrière conceptuelle qu'il y a entre un ensemble de classe/type à la manière des membres privés d'un objet. C'est souvent ce mélange à terme qui rend les micro-services à la mode : pouvoir séparer "violemment" le code.
"La première sécurité est la liberté"