21 réponses à ce sujet

[Bussiere]

Light table est un IDE avec des concepts tres prometteurs :
Visualisation en temps réel du resultat du code, positionnement des fenetres modulables a volonté.
Et en plus l'interface pete et fait cyberpunk.
Bref une presentation du concept :
http://www.developpe...ement-du-futur/

Tout ca pour dire qu'il est dispo en pré alpha et que c'est prometteur.
Il est prevus a la base pour clojure et python mais sera extensible a d'autres langages.
Ha oui il est open source.

Et la pré alpha est disponible ici :
http://app.kodowa.com/playground

Et bah j'aime ce que je vois.
La j'ai l'impression d'etre dans le futur quand je vois ce truc.

C'est peut etre un coup dans l'eau mais ca peut etre interessant.

[JakeGrafton]

Petite précision, le core de LightTable sera open source une fois le produit lancé et non open-source dès maintenant. Ce qui fait une grande différence en termes de timeline. Sauf négociations de dessous de table, ca signifie que le portage vers d'autres langages que Clojure et Python ne pourra commencer qu'à partir du lancement.

La beta est prévue pour la fin de l'année, la release au printemps 2013. J'ose pas imaginer la puissance de feu qu'aurait un tel projet s'il était réellement open-source...

Modifié par JakeGrafton, 29 June 2012 - 07:10.

[Bussiere]

Petite précision, le core de LightTable sera open source une fois le produit lancé et non open-source dès maintenant. Ce qui fait une grande différence en termes de timeline. Sauf négociations de dessous de table, ca signifie que le portage vers d'autres langages que Clojure et Python ne pourra commencer qu'à partir du lancement.

La beta est prévue pour la fin de l'année, la release au printemps 2013. J'ose pas imaginer la puissance de feu qu'aurait un tel projet s'il était réellement open-source...

Oui pardon c'est une des critiques apporté au projet pourquoi pas un dev open source tout le long, et un depot git ?
Sinon jarvis en open source total pour python :
http://madlag.github.com/jarvis/

[Ben]

La beta est prévue pour la fin de l'année, la release au printemps 2013. J'ose pas imaginer la puissance de feu qu'aurait un tel projet s'il était réellement open-source...

Qu'est ce qui empeche d'en lancer un autre open source ?

[GloP]

Qu'est ce qui empeche d'en lancer un autre open source ?

Le talent.

J'ose pas imaginer la puissance de feu qu'aurait un tel projet s'il était réellement open-source...

Oui, il y a qu'a voir eclipse, meilleurs IDE au monde...

lol

Ils ont raison, ils ont autre chose a foutre que gérer les pleureuse professionnelles et autres commit de merde avec tout le temps perdu a gérer toute une communauté de bras casses qui s'invente codeur autour d'un projet pareil. Quand c'est fini, ils peuvent balancer le truc, c'est très bien comme idée ca.

Modifié par GloP, 30 June 2012 - 04:06.

[Donjohn]

Oui, il y a qu'a voir eclipse, meilleurs IDE au monde...

Haha ouais mais faire ça en java aussi...

[Ivru]

Je préfère les trolls à histerion. Ils sont plus subtiles.

[AnA-l]

Sans vouloir defendre Java, stun dev web qui troll la hein

[Trevidos]

Euh, j'ai pas compris ce qu'il y a de révolutionnaire. Je dois etre con, mais tout ca existe dans Eclipse (qui est passé en 4.2 release) en plus smart.
Putain, de l'aide contextuelle, de l'auto-completion, du positionnement de fenêtre, modification en live de code avec résultat a l'écran durant un débogage, y'a que sous visual C# que ca ne se fait pas encore...

[Histrion]

AMHA le problème d'Eclipse c'est pas Java, c'est Swing. Quand c'est bien optimisé Java ça dépote. Mais Swing est très complexe, et n'a pas été pensé pour être particulièrement optimisé (et c'est normal, ce n'est pas son but).

Dans une autre mesure le problème d'Eclipse ce sont ses (trop nombreux) plugins. J'ai toujours préféré NetBeans pour cette raison.

Pour recentrer sur l'IDE qui est proposé, je dirais qu'en tant qu'utilisateur quotidien et permanent d'un IDE je valide toutes les idées qui peuvent éloigner l'abtraction du "fichier" vers l' "unité de compilation" ou même de manière encore plus fine vers ce qui structure le code (pattern, fonction, entrées communes/ sorties communes, etc. il y a plein d'approches possibles).

Par contre je ne crois pas trop à l'exécution en continu du code (le debugging au fil du code). C'est dans la suite de la notion de TDD : si j'ai mon test codé avant ma méthode, alors pourquoi ne pas passer le test à la volée au fur et à mesure que je code ma méthode. Réponse : parce que le TDD c'est un cas très très limité de développement (même en considérant qu'on peut créer des mocks et ne pas prendre en compte BDD, applications tierces, services externes, etc.). Je connais en fait très peu de monde, même chez les gens sensibilisés, qui code vraiment en TDD.

[ZGoblin]

AMHA le problème d'Eclipse c'est pas Java, c'est Swing.

Sauf que Eclipse est développé en SWT, et cette bibliothèque est vraiment réactive car elle utilise les composants natifs. Le problème d'Eclipse c'est Eclipse lui-même et sa lourdeur.

Modifié par ZGoblin, 02 July 2012 - 14:53.

[AnA-l]

Putain, de l'aide contextuelle, de l'auto-completion, du positionnement de fenêtre, modification en live de code avec résultat a l'écran durant un débogage, y'a que sous visual C# que ca ne se fait pas encore...

Quand on connait pas trop trop, on se tait un peu peu.

[Histrion]

Sauf que Eclipse est développé en SWT, et cette bibliothèque est vraiment réactive car elle utilise les composants natifs. Le problème d'Eclipse c'est Eclipse lui-même et sa lourdeur.

Ah bah tu vois là tu m'apprends quelque chose. J'étais persuadé que seul Swing pouvait rendre des IHM aussi peu réactives.

[Trevidos]

Quand on connait pas trop trop, on se tait un peu peu.

Ah bon.Ok, explique moi comment je fais une édition durant le débogage sur mes projets. Je suis super intéressé par ça, je vais gagner un temps fou au lieu de recompiler ma DLL à faire de l'édition temps réel. Elle est linkée et lancée avec un soft externe cette DLL (si ca a une influence quelconque sur l'outil).

Pour Eclipse, je suis plus au courant car nous l'utilisons depuis 2005 comme plateforme IDE et comme plateforme de développement (RPC) pour notre gamme logiciel.

[AnA-l]

Euh, l'edit and continue. C'est une feature de base. Les conditions, c'est que ca marche moyen en 64 bits, mais sinon, ca marche aussi sur du code natif, et tu peux toujours t'attacher sur un soft externe, via le menu debug, si t'as les symboles de ta dll, il les chargera et te laissera trifouiller dedans.

Il existe meme des technos comme ca, qui te permettent de recompiler et changer tes dll native, a la volée : http://runtimecompil...e-now-live.html
(Mais ca, j'ai pas encore eu le temps de jouer avec)

Modifié par AnA-l, 02 July 2012 - 20:14.

[Twin]

Ah bah tu vois là tu m'apprends quelque chose. J'étais persuadé que seul Swing pouvait rendre des IHM aussi peu réactives.

Marrant, on te montre que tu ne connais vraiment pas le domaine et tu continues à déblatérer des conneries sur Swing comme si tu étais un expert.

[GloP]

On a quand meme conclu que le probleme d'Eclipse, c'etait Eclipse. CQFD. (Et je maintiens qu'ils font bien de pas open sourcer le truc avant d'avoir fini pour eviter la meme destinee). A la base, ca me ferait pas rire vu que c'est l'IDE standard pour faire du Java a Amazon. Mais comme je pouvais vraiment plus supporter cette daube je me suis payé ma license perso de IntelliJ, et comme maintenant j'ai un IDE que me mets pas de mauvaise humeur des le matin, je ris. JE RIS!

Modifié par GloP, 03 July 2012 - 07:44.

[Patryn]

FORTRAN & LISP ftw

[Histrion]

Marrant, on te montre que tu ne connais vraiment pas le domaine et tu continues à déblatérer des conneries sur Swing comme si tu étais un expert.

Free bashing. Je ne connais pas plus que ça Swing mais je suis plutôt dans mon métier sur tout ce qui est perfs et optimisations. Et Swing c'est pas le bon outil pour avoir des IHM réactives, c'est ce que j'en ai vu (ce qui n'en fait pas un mauvais outil pour d'autres choses).

Maintenant Eclipse / Swing & co. ça m'en touche l'une sans faire bouger l'autre. Et pour re-recentrer sur Light Table, en gardant l'aspect perfs à l'esprit, au delà de l'ergonomie et de la modélisation du cycle de dév, ce que j'attends de mon IDE qu'il soit très très réactif. Un retour sur ce point Bussière ?

[Bussiere]

Maintenant Eclipse / Swing & co. ça m'en touche l'une sans faire bouger l'autre. Et pour re-recentrer sur Light Table, en gardant l'aspect perfs à l'esprit, au delà de l'ergonomie et de la modélisation du cycle de dév, ce que j'attends de mon IDE qu'il soit très très réactif. Un retour sur ce point Bussière ?

La version bac a sable est méga limité mais oui ca bouge vite avec un pc qui n'est pas un foudre de guerre et eclipse a coté en plus.

[ZGoblin]

Free bashing. Je ne connais pas plus que ça Swing mais je suis plutôt dans mon métier sur tout ce qui est perfs et optimisations. Et Swing c'est pas le bon outil pour avoir des IHM réactives, c'est ce que j'en ai vu (ce qui n'en fait pas un mauvais outil pour d'autres choses).

Encore super faux car l'IDE le plus réactif que j'ai jamais vu : intelliJ est développé en Swing.

Swing, quand on l'utilise bien c'est super réactif, mais plus des 2/3 des softs swing sont mal codés, ce qui provoque cette impression de lenteur.

On a quand meme conclu que le probleme d'Eclipse, c'etait Eclipse. CQFD. (Et je maintiens qu'ils font bien de pas open sourcer le truc avant d'avoir fini pour eviter la meme destinee).

Ton argument est un peu bidon car Eclipse est développé par des grosses boites comme IBM. Si c'est Open Source, c'est avant tout pour faciliter le développement entre différentes boites.

Modifié par ZGoblin, 03 July 2012 - 12:38.

[Histrion]

Il faut séparer l'interface des process sous-jacents. Dans IntelliJ (que je vois régulièrement tourner sur les postes des collègues) les process sont rapides (autocomplétion, refactoring notamment) mais l'IHM n'est pas plus réactive qu'Eclipse. C'est à dire plutôt lente et avec des latences. Par contre on est d'accord que dans Eclipse, en plus de ça, le reste aussi est lent (30 secondes de freeze régulièrement pour autocompléter des méthodes de l'API Swing justement, bug qui a l'air connu).