Tout d'abord merci d'avoir regardé de près le Lisaac.
L'absence de Break ou de Return ou d'exception ont été un choix délicat :
1) Ce sont des ruptures de contexte, donc des "goto" cachés. La garantie de linéarité
du code est quelque chose d'important au niveau génie logiciel.
(Il aide aussi à l'analyse de flot et la recherche de preuve sur le code)
2) Lorsque nous avons un langage ayant la programmation par contrat, cette linéarité
est aussi importante : nous garantissons l'exécution des pré, du code, puis des posts
sans se poser de question d'interruption. Il s'est avéré qu'il était bien agréable de ne pas
avoir besoin d'analyser tout le code d'un fonction pour ajouter une action à la fin de
celle-ci.
C'est le choix de Bertrand Meyer, multe fois argumenté dans son livre et directement mise en oeuvre dans son langage Eiffel.
3) la sortie par break ou par return dans une imbrication importante de code est un signe
d'un code mal fragmenté (découpage insuffisant en fonctions). Cette absence incite le
programmeur à fragmenter plus son code pour le rendre plus lisible.
J'ai comme vous beaucoup programmé avec la possibilité de return ou de break,
mais après une période de sevrage (En Eiffel, puis en Lisaac), j'apprécie cette absence...
4) Le choix d'un langage minimaliste : ce qui n'est pas indispensable n'est pas ajouté.
C'est un choix de goût, ou plutôt de philosophie. Le Lisaac a une grammaire plus petite
que SmallTalk et n'a rien à voir avec celle de Java ou C#...
Nous ajoutons que si cela est indispensable ! Plus le langage est petit et uniforme dans sa
façon de penser, moins il est difficile à comprendre ou à apprendre...
Evidemment, pour être d'accord avec cela, il ne faut pas avoir la philosophie suivante :
"Un langage est facile a comprendre ou apprendre si il ressemble à ce que je connais !"
(Qui est la philosophie de Java ou C# avec leurs syntaxes proche du C.)
Ici, ma philosophie fonctionne mieux si on considère que la personne ne connais rien.
(c'est dans cette même idée que SmallTalk, avec Squeak, est considéré comme un langage destiné aux enfants)
Pour les exceptions, la programmation par contrat recouvre en partie, et de manière plus
élégante, l'utilisation des exceptions.
Mais, je te l'accord, ce n'est qu'en partie...
L'utilisation des Blocks à évaluation retardé ou "closure" (introduit en Lisp) recouvre encore une autre partie de l'utilisation des exceptions.
Il reste peut être encore des trous dans notre approche, qu'il va falloir analyser avec
beaucoup de précaution pour ne pas faire redondance et ne pas inclure une brique qui
va à l'encontre du génie logiciel.
L'approche des exceptions en Java n'est clairement pas la bonne, et nous avons l'air
d'être d'accord sur ce point, il faut donc y réfléchir... (pourquoi voir plutôt vers ADA)
Ce sont des débats assez délicats comme : "langage typé vs langage non typé" ou encore
le choix d'avoir une syntaxe drastique sur les majuscules et minuscules...
Cela reste des choses argumentables , mais c'est aussi des trous sans fin à discussions philosophique. Nous avons une philosophie bien précise autour du Lisaac, nous essayons
de nous en tenir pour réaliser un langage racé de qualité dans sa catégorie, et non un
langage four tout n'ayant plus d'âme. :-)
[^] # Re: Les trous de lIsaac
Posté par sonntag . En réponse au journal Des langages de haut niveau. Évalué à 2.
L'absence de Break ou de Return ou d'exception ont été un choix délicat :
1) Ce sont des ruptures de contexte, donc des "goto" cachés. La garantie de linéarité
du code est quelque chose d'important au niveau génie logiciel.
(Il aide aussi à l'analyse de flot et la recherche de preuve sur le code)
2) Lorsque nous avons un langage ayant la programmation par contrat, cette linéarité
est aussi importante : nous garantissons l'exécution des pré, du code, puis des posts
sans se poser de question d'interruption. Il s'est avéré qu'il était bien agréable de ne pas
avoir besoin d'analyser tout le code d'un fonction pour ajouter une action à la fin de
celle-ci.
C'est le choix de Bertrand Meyer, multe fois argumenté dans son livre et directement mise en oeuvre dans son langage Eiffel.
3) la sortie par break ou par return dans une imbrication importante de code est un signe
d'un code mal fragmenté (découpage insuffisant en fonctions). Cette absence incite le
programmeur à fragmenter plus son code pour le rendre plus lisible.
J'ai comme vous beaucoup programmé avec la possibilité de return ou de break,
mais après une période de sevrage (En Eiffel, puis en Lisaac), j'apprécie cette absence...
4) Le choix d'un langage minimaliste : ce qui n'est pas indispensable n'est pas ajouté.
C'est un choix de goût, ou plutôt de philosophie. Le Lisaac a une grammaire plus petite
que SmallTalk et n'a rien à voir avec celle de Java ou C#...
Nous ajoutons que si cela est indispensable ! Plus le langage est petit et uniforme dans sa
façon de penser, moins il est difficile à comprendre ou à apprendre...
Evidemment, pour être d'accord avec cela, il ne faut pas avoir la philosophie suivante :
"Un langage est facile a comprendre ou apprendre si il ressemble à ce que je connais !"
(Qui est la philosophie de Java ou C# avec leurs syntaxes proche du C.)
Ici, ma philosophie fonctionne mieux si on considère que la personne ne connais rien.
(c'est dans cette même idée que SmallTalk, avec Squeak, est considéré comme un langage destiné aux enfants)
Pour les exceptions, la programmation par contrat recouvre en partie, et de manière plus
élégante, l'utilisation des exceptions.
Mais, je te l'accord, ce n'est qu'en partie...
L'utilisation des Blocks à évaluation retardé ou "closure" (introduit en Lisp) recouvre encore une autre partie de l'utilisation des exceptions.
Il reste peut être encore des trous dans notre approche, qu'il va falloir analyser avec
beaucoup de précaution pour ne pas faire redondance et ne pas inclure une brique qui
va à l'encontre du génie logiciel.
L'approche des exceptions en Java n'est clairement pas la bonne, et nous avons l'air
d'être d'accord sur ce point, il faut donc y réfléchir... (pourquoi voir plutôt vers ADA)
Ce sont des débats assez délicats comme : "langage typé vs langage non typé" ou encore
le choix d'avoir une syntaxe drastique sur les majuscules et minuscules...
Cela reste des choses argumentables , mais c'est aussi des trous sans fin à discussions philosophique. Nous avons une philosophie bien précise autour du Lisaac, nous essayons
de nous en tenir pour réaliser un langage racé de qualité dans sa catégorie, et non un
langage four tout n'ayant plus d'âme. :-)