[gull] langages et type systems

[Daniel Cordey]

On Monday 04 August 2008 23:19:16 Philippe Strauss wrote:

> Daniel, je suis grosso-modo d'accord sur tout ce que tu ecrits, néanmoins
> cela vaut la peine d'essayer un dérivé de la famille ML histoire de toucher
> a un "vrai" type system, au moins en tant que culture générale
> informatique.

Je suis toujours favorable a examiner d'autres langages et cela fait longtemps 
que je veux jeter un coup d'oeil a OCAML. Malheureusement, je n'ai plus le temps 
de m'octroyer ce luxe depuis plusieurs annees. Je me contente d'investiguer des 
technologies immediatement utilisables ou ne necessitant que 15 a 30 minutes de 
lecture (et encore la je me montre asez selectif). Je deplore cet etat de fait 
et je ne reve que de pouvoir investiguer quelques langages qui me semblent 
interessants.

> ML a été conçu pour écrire des "theroem prover", et presque
> accessoirement fait office de bon langage "general purpose" (surtout dans
> son incarnation ocaml qui n'est pas "pure"-ment fonctionel et qui a un bon
> système objet).

Bon, c'est l'eternel compromis entre objets et procedures :-) J'en suis arriver 
a la conclusion que la verite ne se trouve ni dans l'un, ni dans l'autre, mais 
entre les deux. J'ai beaucoup "objectise" mes travaux en C et je continue 
maintenant a le faire en Python. Neanmoins, il y a des problemes qui necessitent 
une approche procedurale, d'autres qui s'accomodent bien d'une approche objet et 
d'autres qui melangent les deux... Tout compte fait, Python convient assez bien 
a ces deux usages et je ne suis pas oblige de "choisir" mon camp en permanence. 

> Je crois a cause de ceci:
> http://en.wikibooks.org/wiki/Haskell/The_Curry-Howard_isomorphism?
> la notion de typage est poussée le plus loin possible dans les langages
> ML.

Oui, mais cela reste des langages academiques. S'il est vrais que l'on peut 
conceptualiser une partie de chaque probleme, on en arrive tres vite a la partie 
"camboui" qui necessite une approche beaucoup plus technologie-informatique. On 
a beau isoler un maximum de ces besoins dans des librairies/modules confines, on 
en est toujours reduit a devoir manipuler des accents, acceder a une base de 
donnee, packer des donnees, lire des fichiers de configurations, etc. Bien sur, 
avec du temps on peut tres bien envisager de tout conceptualiser et d'avoir une 
magnifique architecture logicielle. Malheureusement, l'evolution des besoins et 
tel que l'on n'arrive jamais a stabiliser l'ensemble. Les technologies deboulent 
en permanence XML, AJAX, CSS, etc. et il est impossible de tout interconnecte 
avec de merveilleux APIs... :-( 

Un temps, je pronais la definition d'un langage par type de probleme (je rejoins 
ML dans un certain sens), mais j'ai abandonne car cela implique un (trop) lourd 
apprentissage pour tout nouveau collaborateur.

> Concrètement, dans de la programmation de tout les jours, je n'en ai cure
> des theorem prover, par contre le "side effect" d'avoir sous le capot un
> type system très poussé, c'est que le compilateur te trouve passablement
> plus d'erreurs.

Oui. On retrouve aussi cet avantage lorsque l'on arrive a bien formaliser son 
probleme et a le realiser de maniere propre en OO avec un langage comme Python. 
Les message d'erreurs sont logiques et comprehensibles. Ils permettent de tres 
vite mettre le doigt sur des problemes de conception ou des manquements de dans 
les methodes etc. C'est assez pratiques d'avoir autre chose que SIGSEFV ou 
BUSERROR :-)

> Bref, tout ceci pour dire que l'utilisation du typage entre c, c++, python,
> probablement java et c# d'une part, et ML, haskell, ocaml d'autre part,
> c'est pas vraiment comparable, ce sont des choix de design, des buts
> initiaux bien différents.

Le probleme, a mon avis, reside plus d'en l'interfacage entre ces langages et... 
le monde informatique. De plus, les parties "conceptuelles" ou "moteurs 
d'inferences" sont en general bien confines et donc relativement facile a mettre 
au point, par contre... 99% du code va concerner l'interface utilisateur et le 
brassage des donnees dans la base SQL...  J'ai aussi abandonne l'idee d'utiliser 
2 langages dans une meme infrastructure; ca aussi c'est trop lourd a 
supporte.Trouver un bon programmeur dans un langage est "relativement" facile 
(j'exclu VB, C#, Access...), mais bon dans 2 langages...  ca devient 
problematique ! Raison pour laquelle j'ai adopte une sorte de compromis; 
compromis qui peut tres bien etre remis en question a tout moment...

> C'est regrétable d'ailleurs que la programmation fonctionelle ne fasse pas
> ou en quantité négligeable partie des cursus d'école d'ingénieurs,
> lorsque j'ai commencé à m'intéresser à ocaml je me demandais a
> quoi mes cours d'informatique avait servit.

Oui, et le probleme est que des ecoles ont aussi tendance a se reposer sur des 
outils de conception qui empeche l'acquisition de certains reflexes. Du coup, 
ceux qui sortent de ces ecoles ont besoin d'un grand temps d'adaptation a des 
domaines comme la gestion de widgets, les acces concurents a des fichiers ou de 
la memoire, etc. Je trouve qu'un bon exercice serait la realisation d'un 
"widget" pour une librairie comme Qt ou GTK... mais naturellement, quand l'ecole 
est polluee par une kyrielle de PC W*... aucune chance :-(

dc