[gull] langages et type systems

Laurent Franceschetti laurent at franceschetti.net
Tue Aug 5 20:08:21 CEST 2008


Philippe Strauss a écrit: 

> Perso c'est vraiment une démarche pragmatique: je m'intéresse 
> au traitement du signal audio, C, j'ai plus envie de me 
> tapper du malloc et de la GUI en C, C++ jamais accroché, 
> python et perl j'ai bcp apprécié l'expressivité, mais c'est 
> très lent pour du traitement du signal.
> Ocaml génère du code, grosso-modo entre 10 et 25% plus lent 
> que C, alors voilà un compromis qui me convient:
> langage avec forte expressivité mais économe en CPU.
> 
> Tu retrouves, dans les structures de données d'ocaml, le même 
> plaisir qu'avec Python, et l'apport du pattern matching pour 
> traiter des types de données "custom", notamment en arbre ou 
> graph, ben c'est difficile de faire sans après y avoir touché.
> 
> A déconseiller fortement donc ;-) (c'est peut être pour qu'il 
> se se démocratise pas des masses: bcp de personnes se disent 
> "merde, si j'y touche j'y reste crocher, faisons comme si 
> cela n'existait pas". Je me souviens m'être dit cela un jour).
> 

Ca donne envie. Quoique j'ai été rebuté par le côté très formel qui m'a
donné un peu de mal de tête. Mais peut-être que je ne me suis pas assez
appliqué.

J'ai aussi une idée sur les types, qui est: * ca dépend * (comme disait
toujours notre prof de droit à l'EPFL).

Je suis un peu mitigé à propos du côté agnostique de python (qui confond
fonction et structure: si ca vole, marche et fait coincoin comme un canard
alors c'est un canard); ce qui me paraît un peu dangereux, car si on ne fait
pas attention on risque de faire rouler un tracteur sur l'autoroute et
accrocher une remorque agricole à une Ferrari.

... et de l'autre je trouve assez frustrant qu'un é accent aigu soit perçu
de 36 façons différentes selon les types (voir les joies d'ASCII, Unicode,
les collations SQL, etc.). Or le concept de é accent aigu, il n'y en a qu'un
(le reste est une question d'implémentation, sans vouloir pour autant
minimiser les problèmes concrets que ça pose). Devoir faire des Cast à
droite et à gauche dans tous les sens, ça peut être précis, mais c'est aussi
générateur d'erreurs et surtout ça prend du temps à déboguer.

Ce qui me paraît un problème philosophique: qu'est-ce qu'on considère
différent et qu'est-ce qu'on considère semblable. La réponse dépend des
besoins. Penser que les "gens sérieux" doivent forcément faire la différence
me paraît aussi abusif que de dire qu'il ne faut jamais en faire. Comme
disait Lao-Tseu, tout est dans le tao (la voie du milieu).


Par exemple, je trouve assez commode d'avoir un passage de paramètre non
typé à une procédure, qui se charge ensuite de regarder dedans (à condition
que ce soit formellement possible) et décide ce qu'il faut faire selon qu'il
s'agit d'un entier, réel, null (eh oui 2+null, des fois ça m'arrange que ça
fasse 2, spécialement avec des bases de données financières). A mon avis
c'est plus élégant formellement que la surcharge, car tout est regroupé dans
le corps de la procédure. Mais il existe des cas où la surcharge s'applique,
à mon avis lorsqu'il s'agit d'un "homonyme", c'est-à-dire lorsque deux
procédures/fonctions ont le même nom, mais font en réalité deux choses
complètement différentes.

Ce qui nous amène un peu plus loin, conceptuellement, à la notion
d'automatisation: les conversions implicites sont des automatismes. Tant que
les automatismes donnent un résultat prévisible et réplicable pour nos
besoins, nous sommes contents. Dès qu'ils amènent des résultats
imprévisibles et au pire font vilainement crasher un avion (regardez
http://www.youtube.com/watch?v=faB5bIdksi8&feature=related pour voir ce que
je veux dire!), alors nous avons besoin d'être plus formels. Je comprends
parfaitement le besoin ressenti par les programmeurs en Ocaml, notamment
pour des automates critiques, où l'erreur n'est pas permise.

... Mais il est également possible qu'il y ait en OCaml des concepts qui
pourraient faire progresser les autres langages? Je serais intéressé.






More information about the gull mailing list