[Squeak-fr] Distribution de DrGeoII sous licence LGPL

[Bernard Notarianni]

On 6/17/06, Hilaire Fernandes <hilaire at ext.cri74.org> wrote:
[...]
>
> De cette expérience, j'en retire que programmer dans un environnement
> Smalltalk vous change la vision que vous pouvez avoir sur la
> programmation. j'ai pratiqué quelque autres langages, surtout C++ mais
> aussi un peu Python, Java.
> Avec Smalltalk, on change de plan conceptuel, non que les choses soient
> plus difficiles, mais simplement la vision de ce que doit être le
> langage et son environnement de développement sont totalement
> différentes. Ce qui explique que tu te sens destabiliser.
> Une fois que l'on maitrise les deux approches, la traditionnel (que tu
> décris très bien par: on écrit le source, on compile, et on regarde ce
> que ça donne...) et celle de Smalltalk (que j'ai envie d'appeler celle
> des petits pas), la 2e apparaît de loin comme très supérieure.
>
> De la première approche j'en ai été gavée pendant des années. La
> deuxième je la pratique depuis peu, mais j'ai découverts que cette
> dernière me permettait d'aller beaucoup plus vite, d'avoir une approche
> du développement plus en continuité, moins brutale dans les transitions
> entre les moments forts du développement: edition de code, compilaiton,
> test, déboguage. Avec Smalltalk le passage d'un de ces moments à l'autre
> se fait par epsilon alors que dans l'autre approche c'est à coup de
> rupture brutale, mentalement destabilisante et stressante pour le
> programmeur.
>

Hilaire,

Comme Gilles, je trouve que tu décrit trés bien la différence
d'experience utilisateur que l'on peux rencontrer entre Smalltalk et
les langages/environnements plus "courrant".

Kent Beck expliquait d'ailleurs trés bien l'utilisation que l'on peux
faire du workspace pour essayer un truc, pour faire un  bout de code
réutilisable sous la forme d'une méthode dans une classe. Cela permet
d'avoir une trés grande proximité avec les objets et de mieux les
"faconner". Il me semble que c'est d'ailleurs aussi ce type de
sensation que Stephane enseigne dans son livre pour apprendre la
programmation avec les Robots.

http://www.xprogramming.com/Practices/PracDoInInspector.htm
http://www.xprogramming.com/Practices/PracDoWorkspace.htm
http://www.xprogramming.com/Practices/PracDoInObject.htm

Beck a ensuite introduit une étape suplémentaire qui est le test unitaire.

http://www.xprogramming.com/Practices/PracUnitTest.html

Le micro cycle de dévelopement devient alors:

- j'explore quelques minutes dans le workspace pour imaginer un nouvel
objet (je joue avec les robots)
- quand je vois mieux ce que je veux faire avec cet objet, j'en fait
un test unitaire (SUnit) pour figer l'interface avec laquelle je
souhaite manipuler l'objet (lui parler?)
- je code la methode qui fait passer le test
- je suis content et fier de ce que je fait car je vois le succés sous
forme de "barre verte" :-)
- je recommence

Ce cycle ne doit pas prendre plus de 10 minutes, généralement il en
prend moins de 5.


<pub>C'est ce type de programmation que nous vous invitons à explorer
en groupe dans le Dojo Smalltalk ;-) </pub>


Beck a ensuite transplanter son idée de TDD en Java en introduisant
JUnit. Ce qui est interessant, c'est que l'on peux retrouver en Java
ce cycle court, mais sans la premiere étape exploratoire dans le
workspace. Néanmoins, il est possible d'utiliser du code JUnit pour
dialoguer avec le code de manière qui peux ressembler de trés trés
loin à ce qu'on ressent en Smalltalk dans le workspace.

Il est probable qu'avec le temps, Java (et les autres) va introduire
des outils qui permettront de plus en plus de ressentir cette
proximité avec les objets... au prix de quelles lourdeurs? au bout de
combien d'années? l'avenir nous le dira.

Personnellement, je préfère aller  directement à la cible: Smalltalk. ;-)