[gull] langages et type systems

Wed Aug 6 02:14:39 CEST 2008

On Tue, Aug 05, 2008 at 08:08:21PM +0200, Laurent Franceschetti wrote:
> 
> 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é.

Hello Laurent,

ça me rappel le début et la guerre avec le compilateur.
Mais au début, c'est surtout une habitude de la prog impérative qui
brouille les cartes.

A mon avis, il faut attendre d'avoir un problème se resolvant joliment
par de la récursion et/ou parcours de graph ou d'arbre, et le faire
dans deux langages, ocaml et un langage impératif bien maitrisé, afin
de découvrir en douceur et aiguiser l'appétit.

La barrière de passage d'impératif à fonctionel, comme cadre de pensée,
est assez difficile, lorsque on cummule les années dans le paradigm
impératif. Autant abaisser la hauteur de la marche d'escalier avec
un problème particulièrement idouane pour le langage en question.

C'est en cela que je trouve dommage que les écoles ne passent pas
souvent en revue la prog fonctionnel: c'est tout aussi utile que
l'impératif+objet, mais une manière de penser un peu différente: autant
montrer les différentes manières de faire tôt dans l'apprentissage,
avant que les esprits ne considèrent la manière de procéder du CPU comme
la seule en vigueure.

> 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

;-) Héhé excelllent.
Python ça va, mais PHP et Perl dans le genre me pose un problème.
Enfin c'est plutôt si ça fait coincoin: c'est un animal.
si ça fait meuuh: c'est un animal
si ça fait oiiiinnn ouinnn: c'est un animal.

> 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

;-)

J'étais d'accord avec toi lorsque j'avais un pentium 90 et que le seul
langage me permettant d'utiliser correctement mon CPU pour mes besoins
était C.
Depuis, les perfs ont été multipliée par 20 à 40, donc pour l'audio,
plus trop important. Pour le reste: ça dépend :-)

La souplesse sur les types de données en ocaml? J'ai pas encore fait
autre chose, pour le moment, que le truc classique, noeud ou feuille
d'un arbre. Mais c'est tjr du même accabi: tu définis ton type à toi,
le compilo peu faire du typecheck dessus, et toi tu peux utiliser le
pattern matching sur la structure. C'est très balaise en fait.

J'ai jamais regretté des passages par pointeur et casting dans la fonction
etc. Oublié les pointeurs en fait.

Le seul truc que je regrette de C : pour du soft temps réél comme de l'audio,
il faut faire gaffe à la GC qui peut te bouffer quelques ms de temps de traitement
ici ou là.

Dans ce cas, la règle c'est d'allouer la mémoire avant la boucle de traitement audio,
et faire l'intérieur de la boucle en pur impératif.

Bon, en même temps je ne suis pas trop verreux de plus faire de malloc /
free à tire-larigot.

> 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.

je sais pas si c'est tant cela le but de caml. A mon avis c'est plus
l'héritage ML, un type system du genre "la pointe de la R&D du sujet",
et voire ce que cela donne dans la pratique.

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

j'ai vu passer des histoires d'introduction de "closures" dans java,
sauf erreur le projet s'appèle "clojures".

Les types générique et le templating ala C++: les types polymorphes en
caml font que le problème est mieux gérer en *ML.

les higher order function: en java, c'est la m..., du hack tout au plus
pour faire qque chose d'impraticable.

Bah, il ne faut pas cacher les désavantages: communauté pas bien
grandes, moins de bindings sur des libs (notamment d'I/O sur tout et
n'importe quoi, comme perl et python), 5 différents build systems
pour tes projets mais pas vraiment de standards, arguments à la ligne
de commande du compilo parfois finaud, compliqués.

Maaaaaaaaaiis ça en vaut la peine.

fibonacci:

let rec fib n =
    if n <= 1 then 1
    else fib (n - 1) + fib ( n - 2) ;;

ou

let rec fib n = match n with 
    0 -> 0 
    | 1 -> 1 
    | _ -> fib (n - 1) + fib (n - 2) ;; 

aplus.

-- 
Philippe Strauss
http://philou.ch