[gull] langages et type systems

[Daniel Cordey]

On Tuesday 05 August 2008 18:40:47 Philippe Strauss wrote:

> Dure dure, à 30 et quelque, plus comme à 20-25 ans.. Merde suis déjà
> un vieux crouton.

Et que devrais-je dire... a... 51 :-)

> Objets et procédures: le fonctionnel apporte une troisième corde à ton
> arc pour organiser, construire,...

(digression)

Oui, je sais... j'ai pratique LISP pendant un moment et j'ai trouve tres 
amusant. Je suis bien consciens que les nouveaux langages comme ML, Haskell, 
etc. offrent bien plus de chose que LISP, mais cela m'a permit de me 
familisariser avec cette approche. Je ne concois pas un programme comme une 
entite mathematique. Sans doute cela est-il du aux types de problemes que j'ai 
eu a traite et que je traite encore. Les nombreuse situations que j'ai 
rencontrees impliquait souvent des processus asynchrones, des entrees 
multiples... mais, et c'est sans doute la la clef, les contours des problemes 
n'etaient jamais clairement definis a la base. Au lieu de cela, j'ai toujoyrs 
ete dans l'imperative necessite de concevoir des chose dont l'aspect le plus 
important etait le besoin d'evoluer en permanence. Ceci n'empeche pas 
l'application d'une approche fonctionnelle, mais explique peut-etre les raisons 
qui m'ont pousse a considerer avant tout le "probleme" plutot que l'algorithme.

En francais, on parle d'informatique alors qu'en anglais on parle de "computer 
science". Le mot "compute" a une connotation "calcul/algorithme (fonction)" 
alosr que l'ethymologie du mot informatique inclus information. J'ai donc plus 
une approche information/donnees ce qui me pousse a penser structures de donnees 
auxquelles j'applique des algorithmes. On peut faire evoluer tout probleme vers 
l'un ou l'autres des deux extremes (donnees par opposition a algorithme) et cela 
depend d'autres contraintes que les pures besoins algorithmiques ou des donnees. 
Je suis plutot tendance "j'applique des bouts d'algorithmes a la strcuture des 
donnees" que "je developpe des algorithmes au travers desquels je fais passe des 
donnees". C'est une sorte de tendance que j'ai developpe avec le temps et qui 
represente une sorte de compromis. J'ai aussi realise que j'avais pu utilise des 
langages et des techniques differents qui avaient evolues avec le temps; bien 
que les structures de donnees aient peu evolue. La POO permet de traiter les 
donnees comme des ensembles et j'ai toujours dans l'idee de me replonger dans le 
domaine de la tehorie des ensembles flous (fuzzy sets) afin de mieux definir 
formellement mes ensembles d'objets, mais ce sera sans doute un projet de 
"retraite" vu le temps a disposition...

Je pense aussi qu'un bon langage ne s'impose que s'il represente le meilleur 
compromis. Il n'y a donc pas un seul bon compromis pour tous les problemes, mais 
sans doute un ou deux bons compromis suivant le domaine d'application. Il y a 
plein de bon langages tres interssants qui ont ete developpes depuis les debuts 
de l'informatique. Certains sont, ou ont ete, tres repandus alors que d'autres 
sont restes confines a des domaines tres specifiques. D'autres sont meme restes 
des langages purement academiques.

L'important est sans doute de rester curieux en investiguant en permanence 
d'autres langages, et de se forcer a evoluer des que cela devient pertinent. 
Reconnaitre qu'un langage est plus adapte a un certain probleme necessite 
justement de garder les yeux ouverts, mais ce n'est pas toujours facile. Chaque 
langage peut tout faire, mais parfois cet entetement confine au ridicule...

Oui, merci Philippe de ce petit rappel concernant la programmation 
fonctionnelle. Je vais donc me forcer a lire, enfin, quelques articles ete 
exmemple au sujet d'OCAML :-)

> Langages académiques: je crois pas, en tout cas pas en lisant les les
> sources de soft ou librairie ocaml,
> genre spamoracle est assez magnifique. Oh tu peux eventuellement te
> dire que du code propre comme
> cela, l'auteur avait peut-être pas trop la pression des deadlines etc.

Tout langage permet de faire des choses propres (a part ***, *** et ***) de meme 
que tout langage permet de faire des horreurs (surtout ***, *** et ***).

> Perso c'est vraiment une démarche pragmatique: je m'intéresse au
> traitement du signal audio, C,

Je comprends :-)

> j'ai plus
> envie de me tapper du malloc 

Je m'etais fait des outils (en C, C++) extremenet puissant. Afin d'eviter les 
bus-error, les SIGSEGV et les memory-leaks. Tres facile a utiliser, a 
debugger... le top quoi... En programmation, c'est une absolue necessite !
Je reste stupefait de constater que jamais quoi que se soit d'identique n'ait 
jamais ete developpe. J'aimerais bien le mettre en GPL, mais je n'ai jamais eu 
le temps de le porter en 64 bits et cela reposait sur une dizaine d'autres 
librairies d'outils que j'avais developpe sous HP-UX. Je n'ai non plus jamais eu 
le temps de l'adapter a Linux... peut-etre un jour si j';ai de nouveau besoin de 
C de maniere intensive :-)

> et de la GUI en C,

Pourtant Motif c'etait sympa... 3500 fontions avec Xtoolkit... C'est un poil 
mieux avec Qt/GTK, mais ca reste assez lourd...

> C++ jamais accroché,

T'as de la chance :-)

> python et perl j'ai bcp apprécié l'expressivité,
> mais c'est très lent pour du traitement du signal.

Exact !

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

Comme tu le dis : bon compromis !!!
 
> 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é.

Ah, ca semble d eplus en plus interessant...

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

:-)

Bon WE a tous  (et toutes)

dc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20080808/18d4b4e6/attachment.htm>