samedi 1 août 2009

Langages simples

Y en a mare de ces langages qui évoluent tous le temps. Où s'est perdu le bon sens et la raison ?

Au début, il y avait le C, avec ses pointeurs, ses types primitifs, ses structures et son pré-processeur. Puis est arrivé les pointeurs sur les fonctions et les unions. Bien plus tard, le C++ avec l'héritage unique, suivit de l'héritage multiple, l'héritage virtuel, les pointeurs de méthodes, la surchage des opérateurs, les références, les constantes, les exceptions, le Run-Time Type Information et enfin les templates et les casts sémantiques.

C'est trop compliqué ! Inventons un langage simple : Java.

Ce dernier a été vendu comme cela. Plus simple que C++. Vous vous rendez-compte, Madame, il n'y a PAS d'héritage multiple, mais des interfaces ; PAS de surcharge des opérateurs, d'un coté les types primitifs, de l'autre les objets. Puis sont venu les inners classes, les classes locales à une méthode et les variables finales, les classes anonymes, l'introspection. Plus tard, de nouvelles syntaxes pour les boucles, les types génériques, l'auto-boxing et les annotations. La suite annonce la programmation par aspect avec cinquante mots clefs nouveaux et les closures. Stop ! C'est trop compliqué.

Il faut repartir avec des langages plus simples. Python par exemple, langage objet simple avec des boucles riches. Puis est venu l'uni-code, les arguments optionnels explicites, les annotations pour les fonctions, les paramètres et les returns ; plusieurs types de divisions ; une plus grande rigueur dans les comparaisons ; les variables non locales, etc.

Et encore, et encore, et encore. Pourquoi est-il impossible de rester avec des idées simples ? Pourquoi faut-il toujours ajouter plus de syntaxe, de plus de paradigmes, de plus de subtilité ? Pour occuper les ingénieurs en charge du langage ? Virez les !

De plus, on multiplie les langages à maitriser : SQL, HSQL, XML, XSL, SOAP, Javascript, HTML, perl, shell, etc. Voir le mélange des genres, tel langage est traduit en tel autre. Allez déverminer le résultat...

Prenons simplement Java, langage simple par naissance. Le tableau suivant reprend quelques extraits de syntaxe. Comptez le nombre de ligne dont vous avez parfaitement compris le sens, et dont vous savez parfaitement utiliser les concepts sous-jacents. Enlevez un tiers, car c'est toujours plus compliqué que ce que vous ne croyez. Un article par ligne ne suffirait pas. Divisez le résultat par deux. Quel est votre note sur 20 ? Prétendez-vous maintenant que vous connaissez Java ?

Comment un débutant peut-il appréhender cette complexité ? Qui s'interroge encore des causes de dysfonctionnement, de bugs multiples généralement stupides ? La faute à qui ? Aux chercheurs qui nous offrent toujours plus ? Au chef de projet qui souhaitent des petites mains, à peine formées, devant produire immédiatement du code de qualité ?

Et encore, je n'évoque même pas les librairies standards plus riches et plus nombreuses chaque jour. Tellement riche que les concepteurs du langage ne les connaissent même pas. Allez jeter un œil dans les sources des librairies d'un langage. Vous trouverez inévitablement un code qui reprend à la main le code présent dans une autre partie. Inflation quand tu nous tiens.

« Il y existe deux manières de concevoir un logiciel. La première, c’est de le faire si simple qu’il est évident qu’il ne présente aucun problème. La seconde, c’est de le faire si compliqué qu’il ne présente aucun problème évident. La première méthode est de loin la plus complexe. » - C.A.R. Hoare

Parce qu'y'en a marre de la médiocrité, des développeurs en batteries et de la disparition des bons produits simples et naturels.

Jean-Pierre Troll

jp.troll@gmail.com




1 class Foo {...}
2 class Foo {…}
3 class Foo {…}
4 class Foo {…}
5 List
6 List
7 List
8 class Goo extends Foo {…}
9 class Goo extends Foo {…}
10 class Goo extends Foo {…}
11 static T goo(List ts) {…}
12 T goo(T t1, T t2) {…}
13 public void foo(int i, String... strings) {…}
14 foo(7,new String[] {"One String","Two Strings"});
15 foo(A.this);
16 a.super();
17 class A { static class B {} };
18 void goo()
{
class C extend A.B {}
}
19 void goo(final int a) {…}
20 new Thread(new Runnable(){...}) ;
21 public enum E { A,B,C,D }
22 import static java.util.Collections.*;
23 assert first != null : "bad first name";
24 Annotation Processing Tools
25 Doclet
26 throw x.fillInStackTrace()
27 @Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Documented
public @interface A { }
28 volatile double d;
29 final class A { }
30 static {…}
31 try {…} catch (…) {…} finally {…}
32 finally() {…}
33 int hashCode() {…}
34 boolean equals(Object x) {…}
35 class A
{
Object goo() {…}
}
class B extends A
{
Integer goo() {…}
}
36 void g(Integer x) {…}
void h() { g(3) ; }
37 class A
{
void f(Object x) {…}
void f(Integer x) {…}
void f(int x) {…}
void g() { f(3); }
}
38 @Override
@PostConstruct
@PreDestroy
void f() {…}
39 class A
{
static final int a;
static
{ a=3 ;
}
}
40 for (String a:cont) { … }

2 commentaires:

  1. Je te conseille la lecture de cet excellent bouquin :

    http://www.codersatwork.com/

    les citations devraient te réjouir, surtout celles de Joe Armstrong

    RépondreSupprimer
  2. Pas d'accord sur ce billet.

    Et la citation de Hoare est un argument fallacieux de cette thèse. Il parle des logiciels, pas des langages. Là est tout le problème : les langages (trop) simples amènent à du code dilué, boursouflé... complexe. A l'image d'un programme qui serait écrit en brainfuck (qui porte bien son nom), langage qui est en fait proche du plus simple qu'on puisse imaginer.

    Une idée s'exprime simplement en peu de mots. Encore faut-il que le langage employé soit suffisamment riche. C'est vrai pour la langue française, c'est aussi vrai pour les langages informatique.

    La difficulté et le temps d'apprentissage sont effectivement mulipliés, mais il suffit de confier du travail demandant des compétences à des gens compétents, c'est-à-dire avec une base et une volonté. Sans avoir la science infuse, il suffit d'évoluer. Par exemple en cherchant à comprendre et en assimilant les idées du code écrit plus haut...

    RépondreSupprimer