Entreprises et Smalltalk

From OFSET Wiki

Je vous propose, pour ceux que ça interesse, de lister ici les problématiques que l'on pourrait discuter.

• Quels critères de sélection d'un nouveau langage?
• Smalltalk a-t-il des réponses à ces critères?
• Quels vecteurs de l'évangelisation?
• ...

Une piste serait peut etre de mettre en évidence en quoi Smalltalk est le seul vrai langage orienté objet (une tentative ici), et de compléter la démonstration en montrant l'intérêt de l'OO pour les entreprises.

Voir également un argumentaire interessant sur la longévité des choix technologiques.

Voir également la liste des Entreprises utilisant Smalltalk.

---

[edit] Argument pour utiliser Smalltalk et pas Java

Des entreprises qui font des développements Java m'ont dit que les meilleurs développeurs sont ceux qui ont eu une formation Smalltalk!!! Car Smalltalk permet de comprendre les concepts.

Smalltalk est un langage à la fois simple et puissant. De sorte qu'il est facile à apprendre/enseigner et à utiliser. On focalise sur les concepts et le problème à résoudre. Une explication "neuro-science" a été donnée dans le papier "Why Java Isn’t Smalltalk: An Aesthetic Observation"

En résumé, le cerveau humain est capable de manipuler un petit nombre (7-8 de mémoire) d'idées en "parallèle". Au delà il "swap". Le problème est que le "swap" n'est pas fiable. Il y a des pertes avec la restitution du contexte "swappé". Quand on a un langage compliqué comme Java ou C# tout développeur même expert doit aller régulièrement vérifier des éléments de langage. Du coup, ils swappent et perdent de vue des éléments du problème...

Voici des exemples auxquels rares "javaistes" savent répondre vite et correctement :

• Une facile: Soit B une sous-classe de A. Et b une instance de B. b

instanceOf A donne true ou false ? On ne trouve la réponse dans aucune bibliothèque/code/javadoc. Il faut aller voir dans un bouquin/document présentant le langage. On apprend alors que la réponse est "true" bien que b n'est pas instance de A !

• Une plus tordue: Le lookup de méthode dans Java est-il static ou dynamique. Souvent on entend que c'est dynamique. Mais, c'est faux. D'abord, toutes les méthodes static et private sont en lookup static. En plus, même pour les autres, le lookup s'appuie en partie sur le type des variables!!! Voici un exemple :

public class A {
	public void hello(){
		System.out.println("hello");
	}

	public void goodBye(){
		System.out.println("goodBye");
	}
}

public class B extends A {}

public class Main {
	public void overloaded(A a){
		a.hello();
	}

	public void overloaded(B b){
		b.goodBye();
	}

	public static void main(String args[]){
 		A y = new B();
		Main x = new Main();
		x.overloaded(y);
	}
}

Quel est le résultat de ce programme ? On est en droit de croire que c'est "goodBye" car y référence une instance de B. Mais non !!! Le résultat réellement obtenu est "hello". Déroutant non ??? Faites tourner le code si vous n'êtes pas encore convaincu. La raison est que Java utilise le type des arguments pour différencier à la compilation les méthodes surchargées.

Vous donnez ce code à n'importe quel programmeur Java, il ne pourra pas vous répondre sans prendre un certain temps pour réfléchir et vous n'êtes même pas sûr. Ca montre que le langage rend le travail du développeur plus compliqué... Et de l'enseignant (c'est mon cas) qui doit expliquer cela à ses étudiants qui se trouvent vite largués.

Je ne parle pas des trente six façons de faire la même chose en Java : par exemple les itérations (boucles for "classiques", enumerate, iterator, et enfin "foreach"). Le langage a une conception tordue/limitée. Du coup, Sun a besoin de le "patcher" à chaque version. Et pour ne pas perdre la comptabilité, tout est conservé. Ca donne un gros blob...

Noury