Light Table : l’environnement de développement du futur

Light Table : l’environnement de développement du futur
Un développeur présente un nouveau concept d’IDE


Chris Granger, un ancien gestionnaire de programme pour Microsoft vient de dévoiler dans un billet de blog un nouveau concept d’environnement de développement.

Le projet Light Table est une surface de développement et de simulation d’application qui élimine tous les outils et fonctionnalités encombrants dans les IDE actuels.

« Malgré le changement radical à la simplification des interfaces logicielles, le monde des outils de développement continue à réduire notre espace de travail avec de nouvelles fonctions dans chaque version » écrit Granger « Nous sommes coincés dans un monde de fichiers et d’organisation forcée. Pourquoi devons-nous rechercher un peu partout les choses dont nous avons besoin pour coder ? Pourquoi tout est juste du texte statique ».

Partant de ce constat, Granger propose une nouvelle plateforme de développement fondée sur les principes suivants :

- Le développeur ne devra jamais avoir à chercher la documentation : en passant juste le curseur au-dessus d’une fonction, l’aide s’affichera automatiquement à droite. Cela implique que le développeur n’aura plus jamais à se soucier des choses comme l’ordre des arguments.

http://rdonfack.developpez.com/images/lighttable1.JPG

Le développeur devra être capable de faire toutes ses recherches d’aide sur place.

http://rdonfack.developpez.com/images/lighttable2.JPG

- Les éditeurs peuvent être partout et tout montrer, pas seulement le texte : le principe ici est de pouvoir intégrer par exemple un jeu de course sur la surface de travail, ensuite être capable de lui poser des questions et voir l’environnement y répondre.

http://rdonfack.developpez.com/images/lighttable3.JPG

- Les changements doivent produire des résultats instantanés : par exemple, lors de la saisie de (+ 3 4) le code est évalué et le résultat est affiché instantanément sans autre action.

http://rdonfack.developpez.com/images/lighttable4.JPG

L’évaluation et la visualisation des résultats en temps réel créent un débogueur permettant de corriger les bugs et avoir un aperçu rapide du fonctionnement de son programme.

http://rdonfack.developpez.com/images/lighttable5.JPG

- Ecriture du code avec un mode lumière : ce mode permettra à Light Table d’afficher les fonctions utilisées à l’intérieur de celle que le développeur est en train d’écrire, ainsi que leur code source sur le côté.

http://rdonfack.developpez.com/images/lighttable6.JPG

- Les fichiers ne sont pas la meilleure représentation du code, juste une sérialisation pratique :

« Un peu avant de quitter l’équipe Visual Studio, je suis arrivé à la conclusion que les fenêtres ne sont pas une abstraction de ce que nous faisons. D’autres ingénieurs ont des grandes tables ou ils peuvent disperser plusieurs outils. Une table à dessin est une meilleure abstraction pour nous. Nous ne devons pas nous limiter à un mode où la plus petite unité mobile est le fichier » conclut Granger.

[ame="http://vimeo.com/40281991"]Light Table[/ame]

Un nouveau concept d’IDE assez intéressant qui permettra au développeur de se concentrer uniquement sur son code avec des gains en temps importants.




Source : Blog Chris Granger


Et vous ?

:fleche: Que pensez-vous de ce nouveau concept d'IDE ?

J'ai rien compris mais ça a l'air trop puissant !!

Pourquoi ça ressemble à un xterm unix ?

Bret Victor a présenter au CUSEC une vidéo qui s'appelle "Inventing on Principle" qui reprend les mêmes principes que ci dessus.
[ame="http://vimeo.com/36579366"]video[/ame]

La plupart de ces fonctionnalités me laissent froid. Soit ça existe déjà, soit ça me parait difficile à mettre en œuvre en dehors de cas particuliers.

Mouai, ça peut aller pour des gros projets, mais pas pour des gros. Je travail sur un projet avec 1,5M de lignes de codes, s'il n'est pas divisé en plusieurs fichiers, je vous raconte pas la galère pour m'y retrouver dedans

Pour le Lisp, ça à l'air génial. Ça remplacera sûrement Emacs :D

Citation:

---

Envoyé par Veler

Mouai, ça peut aller pour des gros projets, mais pas pour des gros. Je travail sur un projet avec 1,5M de lignes de codes, s'il n'est pas divisé en plusieurs fichiers, je vous raconte pas la galère pour m'y retrouver dedans

---

je ne pense pas qu'il ait quelque chose contre les fichiers en tant que tels et qu'il veuille mettre des millions de ligne de code dans un seul fichier, mais plutôt que ce qui est afficher dans un éditeur ne doit pas être forcement le contenu d'un fichier. Par exemple si on édite le ficher d'entête d'une classe en C++ pourquoi devrait-on avoir à ouvrir soit-même le fichier d'implémentation? Ou encore pourquoi devrions avoir tout le code complet de cinq classes alors que seule une méthode de chacune d'elle nous intéresse. Alors évidemment de simples fichiers dont les noms sont choisis par le programmeur ne feront peut-être pas l'affaire.

Personnellement, je n'aime pas les environnement qui ne me laisse pas décidé où je sauve le texte de mon code source, mais je peux comprendre son point de vue et le potentiel de sa recherche. En outre, on accepte une certaine opacité lorsqu'on utilise un tableur ou un traitement de texte, alors au fond pourquoi pas pour du code source.

Citation:

---

Envoyé par Cal67

Pour le Lisp, ça à l'air génial. Ça remplacera sûrement Emacs :D

---

Un superbe outil pédagogique en effet! :D

Citation:

---

Envoyé par Veler

Mouai, ça peut aller pour des gros projets, mais pas pour des gros. Je travail sur un projet avec 1,5M de lignes de codes, s'il n'est pas divisé en plusieurs fichiers, je vous raconte pas la galère pour m'y retrouver dedans

---

Je ne suis pas d'accord. Justement le truc se concentre sur l'affichage d'une fonction à la fois, avec plusieurs fenêtres librement organisées. Je ne crois vraiment pas que la taille du projet influe sur la pertinence de cette approche : que tu aies 1k ou 100k fonctions, quelle différence ?

Citation:

---

Envoyé par ptah35

Personnellement, je n'aime pas les environnement qui ne me laisse pas décidé où je sauve le texte de mon code source

---

C'est également mon cas mais c'est justement parce que nous ne visualisons qu'un seul fichier à la fois. Donc nous aimons pouvoir organiser ceux-ci de façon à créer une cohérence entre l'organisation spatiale et l'organisation logique. Je pense que l'approche dévoilée ici a un certain potentiel. En revanche elle est encore perfectible : par exemple, il est ici très facile d'ouvrir dans d'autres panneaux les fonctions appelées mais il manque à mon avis, entre autres, un accès rapide aux fonctions appelantes ou à des fonctions connexes, ayant un lien avec la première.

Bref, j'étais très sceptique au début mais je suis assez conquis, je trouve cette recherche très intéressante.

Ah deux ou trois trucs près c'est pas loin d'un développement LISP sous Emacs.

Citation:

---

Envoyé par Camille_B

Ah deux ou trois trucs près c'est pas loin d'un développement LISP sous Emacs.

---

C'est du Clojure dans l'exemple, donc bien un dialecte LISP:)

Effectivement, je pense que cet outil va se poser en tant que concurrent d'Emacs. À voir s'il va s'imposer dans les autres domaines...

Citation:

---

Envoyé par Hinault Romaric

Le développeur ne devra jamais avoir à chercher la documentation

---

Pas nouveau. Eclipse (par exemple) le fait déjà très bien avec la Javadoc

Citation:

---

Envoyé par Hinault Romaric

Les éditeurs peuvent être n’ importe où et montrer quoi se soit, pas seulement le texte

---

Pratique pour tester un truc. À voir pour le reste

Citation:

---

Envoyé par Hinault Romaric

Les changements doivent produire des résultats instantanés

---

Emacs le fait déjà bien avec la possibilité d'avoir le code que l'on tape dans une fenêtre et les résultats dans l'autre (+ la commande à coucher dehors pour avoir la seconde fenêtre :aie:). Je le faisais quand j'apprenais le Scheme. Reprendre les sorties des 2 écrans, tout bien arranger et c'est bon, on a un "waouh!"

Citation:

---

Envoyé par Hinault Romaric

Ecriture du code avec un mode lumière

---

Oh la jolie expression bien marketing ! J'aimerais bien voir ça avec du code propriétaire. :aie:

Citation:

---

Envoyé par Hinault Romaric

:fleche: Que pensez-vous de ce nouveau concept d'IDE ?

---

Ca me fait penser à une "révolution" Apple que des concepts déjà bien implantés qui sont bien relookés pour pouvoir faire des jolis "waouh!".

Mouais ...

Pour l'aide, comme cela a déjà été dit la plupart des IDE le font déjà (du moins pour Java, PHP et C).

Pour l'interprétation directe de l'opération ultime 3+4 je ne vois pas l'intérêt à partir du moment où dans le code on travaille souvent (du moins pour ma part) avec des variables et que l'ide ne semble pas interpréter les expressions avec variables (cf. ligne du dessus dans le code exemple)...

Quant à la fonctionnalité "J'affiche le code d'une fonction fille dans une micro fenêtre à côté" il faut espérer que la fonction fille ne soit pas trop grosse ou complexe ... en plus je suis quasi sûr que cela existe en eclipse mais que personne ne l'utilise parce que c'est illisible.

bref: Au niveau de l'interface on se croirait revenu à l'époque de gwbasic et les fonctionnalités présentées me laissent aussi froid qu'un haagen dazs perdu dans le grand nord.

Certaines choses me laissent doucement indifférente, d'autre me font bondir de ma chaise...

Citation:

---

Pourquoi tout est juste le texte basique ?

---

Car c'est le format le plus générique et le plus portable qui soit, cf philosophie UNIX.

Citation:

---

Les changements doivent produire des résultats instantanés

---

Quid d'une boucle infinie, stackOverflow et autre joyeusetés, voir un algo tout simplement long ? Même si le système est bien géré et ne plante pas, le résultat ne sera jamais instantané.

Citation:

---

afficher les fonctions utilisées à l’intérieure de celle que le développeur est en train d’écrire, ainsi que leur code source sur le côté

---

La chose la plus ignoble qui soit. Le meilleur moyen de coder en fonction de l'implémentation et non en fonction de l'abstraction...

Au final, toutes ces idées sont très sympa d'un point de vue pédagogique, mais inutilisable je pense en production. Comme cela a déjà été dit, cela tient plus de la philosophie MAC à mettre des effets whaou un peu partout qui ne sont pas toujours très utils.

Je demande à voir.

Certaines fonctionnalités ont l'air puissantes, mais comme d'habitude, il faut attendre de voir ce qu'elles donnent une fois l'éditeur en place...

Sinon quid de l'OS ? Ca ressemble pas à une console windows :aie:

Je suis sceptique quant à la possibilité d'un tel éditeur.
Ca ressemble à un netbeans/eclipse je trouve, et j'ai donc du mal à voir comment utiliser ça pour plusieurs langages ?
Netbeans/Eclipse le font très bien pour JAVA, Visual Studio le fait très bien pour C#.
Bref c'est très spécifique selon le langage.
Et pour un langage web, il intègre un serveur ? sous forme de... module !?

L'idée de la doc intégré (laquelle ? la doc officielle ? pourrais-je y voir la doc de boost, wxWidget, Qt, ..... ?), du debuger intégré en instantané, du ... c'est bien, mais est-ce fonctionnel ? réalisable ? ne s'agirait-il pas d'une usine ? du coup l'idée du light est erroné.

Ca a l'air plutôt intéressant, ceux qui ont fait des commentaires négatifs, vous ne pensez pas qu'il faut essayer avant de dire "ça marchera jamais" ?

je ne suis pas convaincu...
ca doit etre bien dans des cas particulers...

pour le web dev par exemple : Ctrl+s, alt+tab, F5... on a le resultat en live en une demie seconde ! (trop fort)
=> on peut "voir la reaction" du "vrai" navigateur et non la reaction d'un simulateur...

Whaaa la révolution graphique ! il à enlever les bordures des fenêtres ...

Plus sérieusement la seule vraie innovation que j'aimerais voir , serait la prévisu en live de ce que donne un code avec les modifications comme sur la capture #5. le tout de manière transparente même sur des langages compilé. Ça serait vraiment un plus , plutôt que de compiler , balancer sur la cible , exécuter , voir que ça va pas, modifier , recompiler ...

[troll je me suis arrêter à visual 2008]

En même temps y vient de Microsoft, quand à l'époque on comparais Visual à ses alternatives , en terme de fonctionnalité/convivialité, y'avais pas photos :P

[/troll

Concernant la previsu en live, c'est deja possible. cela dépend de ce que vous codez, en fait. Sous Eclipse/Netbeans, il est tout a fait possible d''updater" le code de votre programme a la volée, pour peu que celui-ci tourne en mode debug...

Bon, ça pose soucis quand le code en question est du code d'initialisation :) mais cela reste possible.

Sinon, en version payant, on a toujours Jrebel...

Teo

La prévisu en live pourrait être pratique, malheureusement, je pense que certaines fonctionnalités de ce type ne sont faisables que pour des langages basés sur une vm ou un interpréteur.

Pour le reste, il n'a pas fait qu'enlever les bordures des fenêtres, mais également passer en plein écran. Chose que l'on fait habituellement pour gagner de la place, et quand je vois la quantité astronomique qui est gâchée... Je pleure.
Peut-être qu'avec du code source appartenant à un VRAI programme on pourrait se rendre compte un peu plus des "avantages" offerts.

Quand au fait de voir le code la fonction que l'on appelle, effectivement, c'est assez bête au moment du dev. Cela dis, d'avoir quelques lignes de code de la fonction appelante ou appelée peut s'avérer pratique en debug. Cela dis... Les éditeurs actuels sont capables d'avoir plusieurs fenêtres de code.

Sinon, je pense comme tout le monde: la plupart des trucs dont il parle existent dans les IDE standards, seuls les éditeurs de texte brut ne les offrent pas ^^
Mais excepté les débutants qui se voient imposer ces outils, ceux qui s'en servent savent configurer leur environnement pour équivaloir un IDE, et donc, peuvent aussi afficher la doc ;)


En tout cas, je ne vois pas spécialement de nouveautés révolutionnaires. Ah si, j'ai l'impression que c'est fait pour coder sur une tablette... ou sur w8 :D
Dois-je vraiment aller plus loin? XD

La fonctionnalité de visualisation du flux d'information en temps réel est révolutionnaire. Comme l'analyse syntaxique en temps réel a permis d'obtenir du code qui compile tout le temps ou presque (un des apports les plus importants des IDE), cette nouvelle fonctionnalité pourrait déboucher sur du code qui fonctionne dès la première fois.

Le problème, ça va être de réussir à le faire marcher dans tous les cas et pour les systèmes vraiment complexes. Dans un programme Java un peu évolué, où on utilise différents serveurs d'applications, frameworks et bibliothèques, le nombre d'indirections entre le main() du serveur d'application et le code applicatif peut facilement s'élever une trentaine. Difficile de tout faire apparaitre, et si on le fait, difficile de s'y retrouver dans cette masse d'informations. Et avec des frameworks qui suivent le principe de Hollywood, comme les frameworks d'injection de dépendance (Spring, Guice...), difficile de déterminer ce qu'il est pertinent de faire apparaitre.

Mais si on y arrive, ça peut potentiellement décupler la productivité et la qualité du code.

Citation:

---

La fonctionnalité de visualisation du flux d'information en temps réel est révolutionnaire.

---

Je n'en suis pas si sûr. Dans beaucoup de cas, ce n'est simplement pas possible. Car dépend d'un certains nombre d'objet instancier et modifier au file du programme.
D'ailleurs, je ne sais pas vous, mais je n'ai pas une bête de course au travail. Si je fais un développement sur une une fonction grondement en ressources, je préfère autant ne pas lancer le débogueur et coder avec mon éditeur et mon cerveau.
Je ne parle même pas des évaluation de code qui réalise des ajouts en base.(ou suppression)

J'apprécie par contre l'affichage par fonction et non par classe. Bien que cela pose un problème pour les commentaires type javadoc qui se trouve avant une fonction ou pour les variables de classe.

La production des résultats instantanés c'est un peu comme des "tests en ligne" non?
Si c'est le cas c'est que l'exemple choisi est trop simpliste, car dans des cas vraiment pratiques, on a très souvent un "setup" à effectuer pour remplir des préconditions de la fonction à tester. Où va t'on écrire le code du "setup" dans ce cas? et après il faudrait également écrire un code pour "teardown" afin de redonner à l’environnement son état "stable".
Je reste un peu sceptique..

La plupart des fonctionnalités existent dans les IDE actuels, certes, mais la façon de les mettre en place est assez intéressante. Visual Studio, Eclipse & cie sont des logiciels très puissants, mais on ne peut pas dire que les devs se soient foulés niveau ergonomie... Je pense qu'on a grandement besoin d'IDE différentes !

Citation:

---

Envoyé par kolodz

Je n'en suis pas si sûr. Dans beaucoup de cas, ce n'est simplement pas possible. Car dépend d'un certains nombre d'objet instancier et modifier au file du programme.
D'ailleurs, je ne sais pas vous, mais je n'ai pas une bête de course au travail. Si je fais un développement sur une une fonction grondement en ressources, je préfère autant ne pas lancer le débogueur et coder avec mon éditeur et mon cerveau.
Je ne parle même pas des évaluation de code qui réalise des ajouts en base.(ou suppression)

J'apprécie par contre l'affichage par fonction et non par classe. Bien que cela pose un problème pour les commentaires type javadoc qui se trouve avant une fonction ou pour les variables de classe.

---

Tu vois les choses à trop court terme. Bon, normalement un développeur devrait avoir une bête de course, justement. Mais même si ce n'est pas le cas, c'est une question de 2 ou 3 ans pour que des machines d'entrée de gamme soient capables de faire tourner ce genre de fonctionnalité sans aucun problème.

Citation:

---

Envoyé par kolodz

Je n'en suis pas si sûr. Dans beaucoup de cas, ce n'est simplement pas possible. Car dépend d'un certains nombre d'objet instancier et modifier au file du programme.
D'ailleurs, je ne sais pas vous, mais je n'ai pas une bête de course au travail. Si je fais un développement sur une une fonction grondement en ressources, je préfère autant ne pas lancer le débogueur et coder avec mon éditeur et mon cerveau.
Je ne parle même pas des évaluation de code qui réalise des ajouts en base.(ou suppression)

J'apprécie par contre l'affichage par fonction et non par classe. Bien que cela pose un problème pour les commentaires type javadoc qui se trouve avant une fonction ou pour les variables de classe.

---

On dirait que le language de l'exemple n'est pas choisi au hasard: l'outil semble marqué par la philosophie des languages fonctionnels.

Citation:

---

Envoyé par Traroth2

Tu vois les choses à trop court terme. Bon, normalement un développeur devrait avoir une bête de course, justement. Mais même si ce n'est pas le cas, c'est une question de 2 ou 3 ans pour que des machines d'entrée de gamme soient capables de faire tourner ce genre de fonctionnalité sans aucun problème.

---

Ha que j'aimerais bien. :P
Seulement ce que je constate quand je demande à mes collègues et où je suis passé c'est qu'une entreprise sera prête à mettre des dépenses folles pour équiper les commerciaux de la dernière tablette à la mode, alors que les développeurs se font incendier quand ils demandent ce qu'ils foutent sous un windows XP avec un bi-proc 1.4Gh et 2Go de ram. :cry:

Citation:

---

Envoyé par Bousk

Ha que j'aimerais bien. :P
Seulement ce que je constate quand je demande à mes collègues et où je suis passé c'est qu'une entreprise sera prête à mettre des dépenses folles pour équiper les commerciaux de la dernière tablette à la mode, alors que les développeurs se font incendier quand ils demandent ce qu'ils foutent sous un windows XP avec un bi-proc 1.4Gh et 2Go de ram. :cry:

---

Que veux-tu, certaines entreprises adorent jeter l'argent par la fenêtre. Et je parle davantage des dévs sous-équipés que des commerciaux qui jouent au flamby.
Un PC pour développeur ça se change tous les deux ans au max et sans trop lésiner sur la dépense. Et on garde des exemplaires des trois précédentes générations pour les tests de performance et stabilité.

Citation:

---

Envoyé par DonQuiche

(.../...) Un PC pour développeur ça se change tous les deux ans au max et sans trop lésiner sur la dépense. Et on garde des exemplaires des trois précédentes générations pour les tests de performance et stabilité.

---

Réponse d'ingénieur : ça dépend. Par exemple, ici, je fais du cobol sous un terminal. Avant, j'ai fait du VB sur machines virtuelles. Dans les deux cas, mon PC de bureau n'est pas vraiment une limitation, il peut être une brouette - l'important, c'était les serveurs. Par contre, mon ex-collègue qui ne rebootait jamais parceque sa brouette mettait 4 heures à charger le projet java sous eclipse, lui, il avait des raisons légitimes de gueuler pour avoir une machine plus puissante(il est resté 11 mois sans rebooter. Authentique. Avec sa nouvelle machine, il n'avait plus besoin que de 30 minutes pour charger le projet).

C'est moi ou sa ressemble fort à sublime texte 2 ?

L'avenir de la programmation est une programmation fondée sur «multieditor» (http://softconstructors.com/en/techn...alprogramming/). Non Light-Table. 8-)