Pour le debugger : en pharo le gestionnaire d'exceptions global lance le debugger. Pas besoin d'exécuter un bout de code explicitement en mode debug.
C'est au point qu'on peut écrire un test qui appelle une méthode qui n'existe pas, créer la méthode depuis le debugger qui apparait quand on lance les tests, continuer l'exécution, et voir le test runner passer au vert.
Inspecteur mémoire : une fenêtre qui te montre l'état d'un objet (contenu des variables d'instances) et qui permet d'interagir avec directement, au niveau d'abstraction des objets (on s'embête jamais avec la représentation en bits/octets/hexa des choses).
Modèle sémantique = en gros l'arbre abstrait : le programme est constitué de classes, contenant des méthodes, les méthodes contiennent des expressions… les instances d'une classe donnée ont telle et telle variables… quand on compile une méthode et qu'une variable n'est pas définie le compilateur va lancer une exception, que l'éditeur peut choper pour proposer à quels endroits on peut définir ladite variable, ou si par hasard ça ne serait pas une typo, etc. Chercher les appelants d'une méthode ne va pas te donner de faux positifs dans les commentaires, comme grep ferait. On peut chercher les redéfinitions d'une méthode dans les sous-classes, pas simplement trouver toutes les occurrences de /ma_methode(.*)/ dans la base de code. Vim devrait connaître tout cela pour pouvoir interagir avec un programme sans se limiter à juste de la manipulation de texte.
Les outils dont je parle n'existent que dans les IDE vraiment finement liés au langage de programmation. Hors les Smalltalks, Emacs est probablement le plus similaire dans l'approche de manipulation en direct du programme.
Si, c'est exactement pareil. Soit tu te cantonnes aux commandes vim de base, soit tu adoptes des plugins pour gérer tel langage ou tel outil annexe, et tu dois apprendre des commandes en plus. Si tu veux du réel support pour ton langage, tu verras qu'il faut quelque chose de complexe comme eclim : plein d'infrastructure comprenant entre autre un modèle sémantique du programme, un compilateur, une VM spécialisée pour les changements dynamiques de code, un debugger, un inspecteur mémoire, etc… Bref tu remplaces juste ctrl-espace clic-droit > menu > menu > menu > bordel c'est pas le bon > ah oui c'est là… par <esc>\;U&%&*%lkdjhfgs<enter>:!emacs
« langage de script » ça ne veut pas dire grand chose techniquement, à part sur l'usage généralement fait du langage en question… si c'est à bash et compagnie que tu penses, j'aimerais bien voir à quoi ressemble cet IDE potable :)
Smalltalk est un langage compilé et prédate QBasic de 7 ans. Beaucoup de choses ont d'abord été inventées en Lisp, de toute façon, donc la question n'est pas si telle ou telle fonctionnalité est originale, mais à quelle point elle est pratique dans sa réalisation, et intégrée dans les habitudes de développement.
Mais l'effort de développement pour retrouver une panoplie d'outils suffisemment complète hors de l'image est énorme. Shampoo est une réimplémentation complète du browser, en gros.
Pinaillage: Dart est fortement typé, autant que Ruby ou Smalltalk. Un objet donné en mémoire signifie toujours la même chose. Il est juste dynamiquement fortement typé, avec déclaration et vérification statique rendues optionnelle.
Un langage non typé, ou faiblement typé, c'est un langage où une même représentation en mémoire peut avoir plusieurs sémantiques comment on s'en sert (donc par exemple l'assembleur, ou le C à cause des casts). NB les casts en C ne sont pas les mêmes qu'en Java, qui est fortement et statiquement typé.
Clairement. Un arbre abstrait avec seulement 15 sortes de noeuds différents qui sont bien othogonaux entre eux, c'est bien plus sympa que 200 avec des contraintes bizarres.
Je suis juste passé sur le site, voir les vidéos de démo… et j'ai juste une petite suggestion, peut-être que c'est déjà fait mais j'ai pas vu :
Plutôt que d'animer d'un point A vers un point B avec une fonction linéaire, une transition qui accélère et ralentit progressivement doit être super simple à faire et ça rendrait les transitions beaucoup moins mécaniques (donc les démos plus flashy :)
Plutôt que de réinventer un langage de zéro, autant adopter Algol 68, qui est déjà spécifié proprement… il aurait suffit de remettre un compilo au gout du jour.
Enfin bon ce qui me frustre surtout c'est le manque d'inventivité. La plupart des langages qui sortent maintenant sont des resucées de ce qui existe déjà, un peu de ci, un peu de ça, et il n'y a que rarement une nouveauté réelle ou une approche intéressante d'un problème connu : les modules de Newspeak, les séquences en Clojure… éventuellement les goroutines, mais c'est pas bien différents de ce qu'il y a en Erlang…
Concernant Go, je pense que l'idée d'inventer un langage avec quelques principes forts pour voir ce que ça donne est intéressante. Par contre j'attendrai que ce langage apporte vraiment quelque choses de nouveau pour m'y intéresser réellement.
Je suis avec toi sur les performances des GC modernes, mais pourquoi en prendre un conservatif alors que puisque tu conçois le langage, tu pouvais en faire un parfait (il sait exactement ce qui est un pointeur ou pas) ?
Si, parce que si tu as 100 méthodes dans une superclasse A, et une redéfinition dans sa sous-classe B, alors la table de lookup de B contient 101 entrées dont 100 redondantes.
Qui permet de coder avec un style fonctionnel assez facilement. Évidemment c'est pas Haskell, mais avec les blocs (qui sont des fonctions anonymes) on retrouve le même genre d'itérateurs que les fold, map etc.
Il faudrait peut-être des stats sur l'activité du SVN… ou peut-être juste compter le nb de frameworks et leur étendue, et comparer au nombre de développeurs actifs :)
En l'état c'est les API, le code, et comment on s'en sert qu'il faut montrer. Quoique, si ton collègue est designer, les screenshots peuvent avoir des retombées positives pour le projet ;p
Trollisti^WSérieusement, le look OpenStep est certes démodé mais propre. Pas comme ce qu'on peut voir dans pas mal de thèmes alternatifs des toolkits plus communs…
Le problème de ssh user@remotehost commande c'est que la commande s'exécute dans un shell de base, sans ton environnement perso. En passant par bash -lic on peut avoir un environnement complet qui a ta config de ~/.bashrc et/ou ~/.bash_profile.
On vend le bouquin en conférence ou en ligne en impression à la demande, et le PDF est disponible gratuitement. La première version est sortile il y a un an, en on a déjà une traduction française faite par des membres de la communauté :)
[^] # Re: think IDE and OS rolled into one
Posté par Damien . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 3.0. Évalué à 3.
Pour le debugger : en pharo le gestionnaire d'exceptions global lance le debugger. Pas besoin d'exécuter un bout de code explicitement en mode debug.
C'est au point qu'on peut écrire un test qui appelle une méthode qui n'existe pas, créer la méthode depuis le debugger qui apparait quand on lance les tests, continuer l'exécution, et voir le test runner passer au vert.
Inspecteur mémoire : une fenêtre qui te montre l'état d'un objet (contenu des variables d'instances) et qui permet d'interagir avec directement, au niveau d'abstraction des objets (on s'embête jamais avec la représentation en bits/octets/hexa des choses).
Modèle sémantique = en gros l'arbre abstrait : le programme est constitué de classes, contenant des méthodes, les méthodes contiennent des expressions… les instances d'une classe donnée ont telle et telle variables… quand on compile une méthode et qu'une variable n'est pas définie le compilateur va lancer une exception, que l'éditeur peut choper pour proposer à quels endroits on peut définir ladite variable, ou si par hasard ça ne serait pas une typo, etc. Chercher les appelants d'une méthode ne va pas te donner de faux positifs dans les commentaires, comme grep ferait. On peut chercher les redéfinitions d'une méthode dans les sous-classes, pas simplement trouver toutes les occurrences de
/ma_methode(.*)/dans la base de code. Vim devrait connaître tout cela pour pouvoir interagir avec un programme sans se limiter à juste de la manipulation de texte.Les outils dont je parle n'existent que dans les IDE vraiment finement liés au langage de programmation. Hors les Smalltalks, Emacs est probablement le plus similaire dans l'approche de manipulation en direct du programme.
[^] # Re: think IDE and OS rolled into one
Posté par Damien . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 3.0. Évalué à 4.
Pas avec vim.
Si, c'est exactement pareil. Soit tu te cantonnes aux commandes vim de base, soit tu adoptes des plugins pour gérer tel langage ou tel outil annexe, et tu dois apprendre des commandes en plus. Si tu veux du réel support pour ton langage, tu verras qu'il faut quelque chose de complexe comme eclim : plein d'infrastructure comprenant entre autre un modèle sémantique du programme, un compilateur, une VM spécialisée pour les changements dynamiques de code, un debugger, un inspecteur mémoire, etc… Bref tu remplaces juste
ctrl-espace clic-droit > menu > menu > menu > bordel c'est pas le bon > ah oui c'est là…par<esc>\;U&%&*%lkdjhfgs<enter>:!emacs[^] # Re: Un phare isolé ?
Posté par Damien . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 3.0. Évalué à 3.
tous les langages de scripts avec un IDE potable
« langage de script » ça ne veut pas dire grand chose techniquement, à part sur l'usage généralement fait du langage en question… si c'est à bash et compagnie que tu penses, j'aimerais bien voir à quoi ressemble cet IDE potable :)
Smalltalk est un langage compilé et prédate QBasic de 7 ans. Beaucoup de choses ont d'abord été inventées en Lisp, de toute façon, donc la question n'est pas si telle ou telle fonctionnalité est originale, mais à quelle point elle est pratique dans sa réalisation, et intégrée dans les habitudes de développement.
[^] # Re: think IDE and OS rolled into one
Posté par Damien . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 3.0. Évalué à 3.
Il y a Shampoo aussi.
Mais l'effort de développement pour retrouver une panoplie d'outils suffisemment complète hors de l'image est énorme. Shampoo est une réimplémentation complète du browser, en gros.
[^] # Re: Prix et concurrence ?
Posté par Damien . En réponse à la dépêche Apertus Axiom. Évalué à 2.
La RED est à peu près deux fois plus chère, mais je sais pas si c'est comparable niveau fonctionnalités.
# Debugger?
Posté par Damien . En réponse à la dépêche Retour d'expérience sur Go. Évalué à 1.
Y'a-t-il un debugger pour Go? à quoi ressemble-t-il ?
[^] # Re: déçu aussi, mais confiant
Posté par Damien . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 3.
Pinaillage: Dart est fortement typé, autant que Ruby ou Smalltalk. Un objet donné en mémoire signifie toujours la même chose. Il est juste dynamiquement fortement typé, avec déclaration et vérification statique rendues optionnelle.
Un langage non typé, ou faiblement typé, c'est un langage où une même représentation en mémoire peut avoir plusieurs sémantiques comment on s'en sert (donc par exemple l'assembleur, ou le C à cause des casts). NB les casts en C ne sont pas les mêmes qu'en Java, qui est fortement et statiquement typé.
[^] # Re: GNOME Shell en Dart ?
Posté par Damien . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 2.
Il y a du JS dans le bureau de Mac OS X ? où ?
[^] # Re: IDE
Posté par Damien . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 3.
Clairement. Un arbre abstrait avec seulement 15 sortes de noeuds différents qui sont bien othogonaux entre eux, c'est bien plus sympa que 200 avec des contraintes bizarres.
[^] # Re: Rubber
Posté par Damien . En réponse à la dépêche LaTeXila 2.0 : environnement LaTeX intégré pour GNOME. Évalué à 2.
# Transitions linéraires
Posté par Damien . En réponse à la dépêche Videoporama disponible en version 0.8. Évalué à 4.
Plutôt que d'animer d'un point A vers un point B avec une fonction linéaire, une transition qui accélère et ralentit progressivement doit être super simple à faire et ça rendrait les transitions beaucoup moins mécaniques (donc les démos plus flashy :)
[^] # Re: Intéressant !
Posté par Damien . En réponse à la dépêche CAMP 0.7.0 : bibliothèque de réflexion en C++ sous LGPL. Évalué à 4.
# FUD! Bien sûr que si, Arc90 est dans les acknowledgments…
Posté par Damien . En réponse à la dépêche Quoi de neuf chez Apple ?. Évalué à 5.
Sisi : menu Help > Acknowledgments.
[^] # Re: On peut citer en plus
Posté par Damien . En réponse à la dépêche Petit tour des outils de visualisation libres. Évalué à 2.
Pas vraiment axé visu de graphes, plutôt scripting exploratoire pour visualiser des modèles ou des métriques.
[^] # Re: facilité et puissance
Posté par Damien . En réponse à la dépêche Le point sur les avancées de Google Go. Évalué à -1.
Plutôt que de réinventer un langage de zéro, autant adopter Algol 68, qui est déjà spécifié proprement… il aurait suffit de remettre un compilo au gout du jour.
Enfin bon ce qui me frustre surtout c'est le manque d'inventivité. La plupart des langages qui sortent maintenant sont des resucées de ce qui existe déjà, un peu de ci, un peu de ça, et il n'y a que rarement une nouveauté réelle ou une approche intéressante d'un problème connu : les modules de Newspeak, les séquences en Clojure… éventuellement les goroutines, mais c'est pas bien différents de ce qu'il y a en Erlang…
[^] # Re: facilité et puissance
Posté par Damien . En réponse à la dépêche Le point sur les avancées de Google Go. Évalué à 0.
Oui mais bon, autant choisir des principes forts qui n'avaient pas déjà été essayés en 1968…
http://www.cowlark.com/2009-11-15-go/
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Damien . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 1.
[^] # Re: ObjectiveC
Posté par Damien . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
Si, parce que si tu as 100 méthodes dans une superclasse A, et une redéfinition dans sa sous-classe B, alors la table de lookup de B contient 101 entrées dont 100 redondantes.
Le lookup récursif marche très bien et s'optimise avec les polymorphic inline caches. Cherche les papiers sur le compilateur de Self (http://selflanguage.org ), ou http://www.lirmm.fr/prm/language.html .
[^] # Re: Petite erreur dans le texte de la dépêche
Posté par Damien . En réponse à la dépêche Atelier Actux mardi 19/05/2009 : Ruby, un langage objet et (assez) fonctionnel. Évalué à 4.
[^] # Re: La non-nouveauté en matière de desktop linux de la semaine est :
Posté par Damien . En réponse à la dépêche Étoilé 0.4 de sortie. Évalué à 2.
[^] # Re: pour tous ceux qui pensent que gnustep est moche...
Posté par Damien . En réponse à la dépêche Étoilé 0.4 de sortie. Évalué à 3.
Trollisti^WSérieusement, le look OpenStep est certes démodé mais propre. Pas comme ce qu'on peut voir dans pas mal de thèmes alternatifs des toolkits plus communs…
[^] # Re: Marrant ca...
Posté par Damien . En réponse au message Commande distante avec ssh. Évalué à 2.
[^] # Re: sans le mode arriere plan
Posté par Damien . En réponse au message Équivalent de GNU screen pour X ?. Évalué à 1.
Ça marche pour toutes les fenêtres d'une application j'imagine, voire pour toutes les applications qui sont lancées dans le X distant ?
[^] # Re: Squeak by Example en Creative Commons Attribution-ShareAlike
Posté par Damien . En réponse au journal livre en licence libre. Évalué à 0.
# Squeak by Example en Creative Commons Attribution-ShareAlike
Posté par Damien . En réponse au journal livre en licence libre. Évalué à 0.
On vend le bouquin en conférence ou en ligne en impression à la demande, et le PDF est disponible gratuitement. La première version est sortile il y a un an, en on a déjà une traduction française faite par des membres de la communauté :)