Le projet Pharo est fier d’annoncer la sortie de Pharo 3.0 — un langage dynamique et son environnement de développement immersif. Pharo est un projet libre distribué sous licence MIT.
Pharo consiste en un langage objet inspiré de Smalltalk extrêmement bien conçu et un environnement de développement intégré innovant. L'environnement de développement permet, entre autres, l'implémentation du programme, ainsi que l'inspection et la modification des objets durant l'exécution.
Après 1 an de développement, Pharo 3.0 introduit de nombreuses nouveautés, détaillées dans l'annonce officielle et dans la liste des changements, dont :
- Le nouveau compilateur modulaire Opal est maintenant le compilateur par défaut ;
- Le canvas de dessin vectoriel Athens est intégré et il gère l'affichage avec Cairo sur toutes les plateformes ;
- Beaucoup d'outils ont été réécrits avec Spec, un nouveau framework de conception d'interfaces graphiques ;
- 2 nouveaux outils pour les développeurs ont été intégrés (Versionner et Kommiter) ;
- Le nouveau mécanisme de paquetage (RPackage) a été amélioré et est maintenant complètement intégré au système ;
- Le debugger a été complètement réécrit pour séparer la logique de l'interface ; l'inspecteur d'objet propose maintenant de multiples vues pour chaque objet et le navigateur de code gère les labels, facilite la recherche et intègre de nombreuses autres améliorations ;
- La couche graphique (Morphic) a été largement nettoyée et le thème visuel a été rénové.
Voilà les points les plus importants, mais les détails sont eux aussi importants. 2364 bugs ont été corrigés pour Pharo 3 (à comparer aux 1727 bugs corrigés pour Pharo 2).
En parallèle, un nouveau site web a été développé grâce aux technologies Amber (un équivalent allégé de Pharo dans le navigateur web) et Marina (un prototype de CMS qui tourne sous Pharo côté serveur et sous Amber côté client).
Aller plus loin
- Site officiel de Pharo (671 clics)
- Captures d'écrans (791 clics)
- Annonce de la sortie de Pharo 3.0 (45 clics)
- Liste des changements (47 clics)
- Nouveau thème sombre (beta) (96 clics)
# Inspiré de Smalltalk?
Posté par reno . Évalué à 7.
Je croyais que c'était une implémentation de Smalltalk et que c'était un ensemble de librairies..
Quelles sont les différences entre les langages?
[^] # Re: Inspiré de Smalltalk?
Posté par cozo . Évalué à -1.
Pharo is a modern open-source development environment for the classic Smalltalk-80 programming language.
[^] # Re: Inspiré de Smalltalk?
Posté par Damien Cassou . Évalué à 10.
Effectivement, on peut voir Pharo comme une implémentation du standard Smalltalk avec son environnement de développement et ses bibliothèques de code. Cependant, nous avons décidé d'arrêter de dire ça car le standard Smalltalk n'évolue plus alors qu'on améliore Pharo en permanence.
Ça signifie qu'on s'autorise à ne pas être compatible avec le standard. Par exemple, Pharo possède la notion de trait (un mécanisme d'héritage multiple de méthodes) alors que le standard ne le prévoit pas. De même, dans la prochaine version de Pharo, on n'utilisera plus de chaînes de caractères pour déclarer les variables d'instances car on utilisera à la place les Slots (un mécanisme beaucoup plus poussé qui permet d'avoir différents types de variables d'instances avec des comportements différents). Là encore, on s'éloigne du standard Smalltalk. Enfin, le standard définit une API qu'on s'autorise à remplacer petit à petit par une autre plus moderne.
Pour toutes ces raisons, on parle maintenant de Smalltalk-inspired et plus d'implémentation de Smalltalk.
# Un phare isolé ?
Posté par potate . Évalué à 10. Dernière modification le 07 mai 2014 à 01:01.
J'ai eu à utiliser Pharo (à l'université, très peu, pour 4h de TP si je me souviens bien).
L'environnement semble isolé du système dans lequel il s'exécute : on a un bureau (on peut définir le fond d'écran, wouhou!), un gestionnaire de fenêtres, un éditeur/debugger pour le code, un système de gestion de versions et surement d'autres trucs. Je ne veux froisser personne, mais cela m'a laissé une impression étrange, comme si les gens derrière Pharo répugnaient à mettre les pieds en dehors de leur environnement.
Ça m'a choqué, d'autant plus que la personne qui m'a présenté Smalltalk durant ce TP avait un discours plein de mépris pour les autres langages.
Donc, y a-t-il un moyen pour avoir des vrais fenêtres, de lancer des programme sans l'environnement entier ?
[^] # Re: Un phare isolé ?
Posté par Damien Cassou . Évalué à 7.
Tu as tout a fait raison. Pharo est un héritier de Smalltalk dont la tradition a toujours été de fournir un environnement englobant. Je ne connais pas bien l'histoire, mais je suppose que ça vient de la vision d'Alan Kay autour du Dynabook et de l'OLPC qui devaient être utilisés par les enfants. L'interface de Squeak (projet duquel Pharo provient suite à un fork) devait fournir un environnement complet pour l'éducation : manipulation d'objets divers, dessin, programmation…
De nos jours, nous sommes nombreux à penser que ça n'est plus forcément très raisonnable et certains travaillent à une nouvelle couche graphique (appelée Mars) qui permettrait d'utiliser les widgets natifs et les fenêtres du système hôte.
Il est tout à fait possible de déployer une application graphique, console ou web dans une version restreinte de Pharo. Pour les applications graphiques desktop, il est possible d'utiliser XUL par exemple (grâce au framework Phobos).
[^] # Re: Un phare isolé ?
Posté par fstephany . Évalué à 5.
C'est le principal reproche que je fais à Pharo. Les mainteneurs en sont conscient et cette release apporte un support de la CLI qui est acceptable (la version 2 introduisait pas mal de choses).
C'est maintenant vraiment plus simple d'utiliser Pharo sur un serveur headless en production.
Reste plus qu'à pousser l'intégration avec Git pour rendre tout ça plus digeste dès qu'un projet ne contient pas que du code mais des assets externes :)
[^] # Re: Un phare isolé ?
Posté par Damien Cassou . Évalué à 1. Dernière modification le 07 mai 2014 à 11:19.
Un avantage de contrôler l'ensemble de l'environnement est de pouvoir faire des choses comme ça : https://www.youtube.com/watch?v=uKhXLOu_DBU
[^] # Re: Un phare isolé ?
Posté par freem . Évalué à 5.
Je n'ai pas écouté la vidéo, suis au boulot, mais je n'ai rien vu de transcendant.
Pourrais-tu être plus explicite sur la fonctionnalité que tu pointes?
[^] # Re: Un phare isolé ?
Posté par Fernandes Hilaire (site web personnel) . Évalué à 1.
Le truc transcendant c'est Live programming (je ne sais pas comment traduire ça).
Par exemple mettre au point son code depuis le debugger:
https://www.youtube.com/watch?v=UkyBk965ASw
Pour les curieux, d'autres démonstrations:
https://www.youtube.com/playlist?list=PLD1E0C749CACF458A
[^] # Re: Un phare isolé ?
Posté par freem . Évalué à 0.
Ahhhhh ouai, en fait, le truc que j'utilisais déjà quand je tapais mes 1ères lignes de code avec QBasic!
Il était d'ailleurs même possible de modifier le code en cours de déboguage, voire d'insérer ponctuellement du code en milieu d'exécution.
Mais bon, je pense que tous les langages de scripts avec un IDE potable le permettent, non?
D'ailleurs, je ne sais pas le faire avec gdb pour les langages compilés, mais je ne suis pas sûr que ce soit une limite du débogueur, juste de l'utilisateur—moi—pour le coup ( je sais qu'il est possible de modifier le contenu d'une variable et de fixer la prochaine instruction à exécuter, je ne sais juste pas s'il est possible d'insérer du code en cours d'exécution. Ça me semble complexe, mais pas infaisable. Peut-être que LLDB en sera capable, même si GDB ne l'est pas? A voir. ).
Bon, allez, je t'accorde ça: comparé à QB, pharo n'est pas fermé, ni produit par MS, et peut gérer des fenêtre graphiques. Je ne maîtrise pas suffisamment les langages de scripts plus modernes, mais je ne doute pas qu'ils aient aussi ces caractéristiques tout en permettant l'insertion/l'altération de code en live.
[^] # Re: Un phare isolé ?
Posté par Damien (site web personnel) . É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: Un phare isolé ?
Posté par freem . Évalué à 0.
Je cite wikipédia: "En informatique, un script est un programme en langage interprété (voir Langage de script)."
Donc, un langage de script est un langage interprété.
Si tu veux vendre un langage ayant une fonctionnalité que tout le monde la possède déjà, je ne parviens pas à imaginer que l'on puisse considérer ça comme un avantage sur les autres.
Et les habitudes de dev, d'une part, ça varie vachement entre utilisateurs d'un langage, et d'autre part ça dépend des utilisateurs, pas du langage.
Pour finir, le fait qu'un langage soit plus vieux qu'un autre ne me semble pas un argument pertinent pour dire qu'il est meilleur. Par exemple, le langage C ne me semble pas meilleur que C++, pourtant il est plus vieux et plus répandu.
Objectivement, l'âge du capitaine n'a rien a voir avec le fait qu'il soit ou pas un bon capitaine.
[^] # Re: Un phare isolé ?
Posté par barmic . Évalué à 4.
Le C peut être interprété c'est un langage de script ? Pareil pour haskel ou scala. Python est généralement compilé en bytecode python, mais certains le compile en natif et des fois on l'interprète c'est quoi ? Si on prend le source et qu'on fait du JIT c'est interprété ? Les templates C++ c'est un langage interprété ?
Interprété ou non c'est une manière d'utiliser un langage et pas une caractéristique du langage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un phare isolé ?
Posté par freem . Évalué à -2.
Je serai curieux de voir un binaire issu d'un programme bash?
[^] # Re: Un phare isolé ?
Posté par barmic . Évalué à 4.
Ce n'est pas parce que le compilateur ou l'interpréteur n'existe pas ou que l'on ne sait pas le faire aujourd'hui que ça change grand chose au langage. Qu'est ce qui a fondamentalement changé en javascript entre sa création et aujourd'hui ? En python ?… Si demain j'écris un compilateur pour R qu'est-ce qu'il adviendra de ce langage ? Ça changera quoi pour les utilisateurs du langage ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un phare isolé ?
Posté par djano . Évalué à 2.
En Java il y a le hot code replace pour réécrire du code en train d’être débogué.
Depuis le débogueur de l'IDE Eclipse, il est même possible d’exécuter du code simple (limitation de la syntaxe) et d'avoir des effets de bords pour aider au débogage.
[^] # Re: Un phare isolé ?
Posté par Alex . Évalué à 3.
c'est vrai que sous pharo, c'est fortement bien intégré, mais sauf mauvaise interpretation de ma part, c'est un concept (repl read/eval/print/loop)qui il me semble provient des langages fonctionnels et que l'on retrouve dans tout les langages modernes ( pry pour ruby, un truc en beanshell pour java, etc…)
# think IDE and OS rolled into one
Posté par freem . Évalué à 7. Dernière modification le 07 mai 2014 à 12:34.
Ça, franchement, c'est plutôt un truc qui me fait peur pas qui m'attire…
Mon éditeur de texte est un outil. Mon compilateur en est un autre. De même pour mon gestionnaire de fenêtres, mon débogueur, etc.
Le fait que ce soient des outils distincts, souvent exploitables en ligne de commande, me permet de les utiliser pour de multiples usages et de configurer mon "environnement de bureau" à ma sauce, parce qu'aucun dev ne saura jamais ce dont j'ai besoin actuellement, et encore moins demain.
Ça permets aussi de remplacer n'importe quel outil par un autre plus adapté sans devoir changer la totalité de mes habitudes.
Et accessoirement, ça me donne l'impression qu'il faut encore rajouter une surcouche… comme si les systèmes modernes n'en avaient pas déjà trop?
Enfin, j'ai peut-être mal compris, et il est peut-être possible d'utiliser ce langage en dehors de l'environnement limité par l'imagination de ses dev ( ce n'est pas une insulte, tout le monde à une imagination limitée, c'est pourquoi je trouve la philosophie UNIX très intéressante, elle bride moins les utilisateurs que la philosophie tout en un, même si la contrepartie est un temps d'apprentissage pour la maîtrise supérieur. Comme tout outil puissant et flexible, en fait. )
[^] # Re: think IDE and OS rolled into one
Posté par xcomcmdr . Évalué à 2. Dernière modification le 07 mai 2014 à 13:10.
Un IDE, c'est plus qu'un éditeur de texte + débogeur + compilateur.
Ton éditeur de texte, il fait de l'analyse statique sur ton code ? Il te propose des outils de refactoring (renommage, extraire une interface, …) ?
Il peut te faire une Code Map ?
Bref, ce qui ne comprennent pas la philosophie UNIX sont condamnés à la répéter !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: think IDE and OS rolled into one
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Avec Vim, c'est tout à fait possible. Il faut utiliser des scripts Python qui vont appeler l'outil /ad hoc/, tel que LLVM.
http://clang.llvm.org/docs/ClangFormat.html
Il me semble que ce lien est une présentation du bousin: http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons
Quand aux Code Map, je n'ai pas compris l'intérêt, à part de rendre les choses encore plus confuses.
[^] # Re: think IDE and OS rolled into one
Posté par freem . Évalué à 1.
Mon éditeur de texte ne fait pas tout ça, dans la configuration que je lui ai faite. Et je ne veux pas.
Par contre, j'ai d'autres outils, des scripts et petits gadgets, qui eux, me permettent de le faire.
En fait, mon IDE, c'est mon système complet, alors que toi, tes outils réinventent sans cesse la roue. Combien as-tu de gestionnaires de fenêtre qui tournent au total sur ton système quand tu programme?
Le WM du système, probablement celui de ton navigateur internet, celui de ton IDE, tu utilises peut-être un outil d'administration de BDD séparé?
Du coup:
Répéter la philosophie UNIX, ce n'est pas juste utiliser des outils non interactifs ( y a pas que grep dans la vie ), au fait.
Je considère, par exemple, que mpd+mpc ( rien à voir avec la programmation, je sais ) respectent très bien cette philosophie, pourtant c'est interactif, et je ne vois aucun défaut à leur approche. A part que, du coup, on à un vaste choix de clients, du coup il faut choisir lequel correspond le mieux à son propre besoin… choisir, ça prend du temps, avec un lecteur classique c'est plus facile, il n'y a que les skin à choisir… ( et on se tape un lecteur de musique qui affiche de la visualisation dont on à pas besoin… ok, c'est une option opt-out, mais bon… ça reste discutablement utile à 90% des usages. )
Pour conclure, je dirais que la philosophie UNIX est très proche de la philosophie objet: chaque composant fait une chose et la fait bien, possède une interface claire, à un couplage le plus faible possible avec les autres.
Je ne répète pas UNIX, je pense objet.
[^] # Re: think IDE and OS rolled into one
Posté par Damien (site web personnel) . É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: think IDE and OS rolled into one
Posté par freem . Évalué à 0.
Désolé, mais je n'ai pas l'impression qu'il me manque énormément de choses dans le vim de base, que ce soit pour mes projets C++, pour les documents LaTeX que je gribouille ou pour les scripts bash que je bricole.
Le débogueur, comme je l'ai dis, ce n'est à mon avis pas le boulot de l'éditeur de texte, et taper "!cg" ( pour rappeler la dernière invocation de cgdb ) dans un terminal ne me pose aucun problème.
Pour le reste, je ne suis pas sûr…
Par inspecteur mémoire, tu parles bien de valgrind?
Personnellement, dans ma phase de développement, je m'arrange déjà pour que ça marche. Une fois que c'est le cas, je m'occupe d'optimiser ce qui coûte trop cher. Pour ce qui est des memory leaks, j'avoue avoir plutôt confiance dans les smart pointers du C++ et la RAII.
Quant au modèle sémantique, je ne comprend absolument pas de quoi tu parles? L'auto-complétion? Si je voulais un truc riche, j'utiliserais ctag, mais… en fait, je n'en ai pas besoin: il me suffit d'inclure un header local pour avoir accès aux mots qui y sont inclus. Je n'ai pas besoin de plus en la matière.
Je me trompe peut-être, et je serai heureux de découvrir ces outils dont tu parles. Si ça se trouve, j'en trouverais un utile.
[^] # Re: think IDE and OS rolled into one
Posté par Damien (site web personnel) . É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 Cassou . Évalué à 4.
C'est une bonne remarque. Pour le moment, Pharo reste monolithique : soit tu prends tout (langage et outils) soit rien. Cependant, nous travaillons à la séparation des deux, notamment avec le projet Coral que l'on relance. On manque de bras, toute aide est la bienvenue.
[^] # Re: think IDE and OS rolled into one
Posté par Damien (site web personnel) . É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: think IDE and OS rolled into one
Posté par Fernandes Hilaire (site web personnel) . Évalué à -1.
C'est normal d'avoir peur, les changements de paradigme sont difficiles car ils font transiter dans un état instable où les repères ont changé.
[^] # Re: think IDE and OS rolled into one
Posté par freem . Évalué à 1.
Mouai.
Changer de paradigme est un truc qui m'effraie tellement que je suis passé en moins de 5 ans de windows à Debian, puis de l'usage d'un DE monolithique à un ensemble d'applications sélectionnées par mes soins, des gestionnaires de fenêtre en pile à ceux pavant, et enfin de l'usage d'IDE monolithiques à l'utilisation des outils que me propose mon système*.
Chaque fois, j'ai eu l'impression de maîtriser de plus en plus mon environnement, et chaque fois, j'ai "gagné un niveau" comme on dirait dans chez les joueurs de rpg.
Le changement ne me fait pas peur, par contre, avant de changer, je pèse le pour et le contre. Changer pour changer… non merci.
*: et ma roadmap inclue d'aller voir du côté des bsd et/ou de gentoo
[^] # Re: think IDE and OS rolled into one
Posté par Alex . Évalué à 4.
Je pense que tu as une mauvaise vision de pharo, ce n'est pas un ide, mais "juste" un nouvel environnement, tu peux très bien changer l'éditeur, tu as une ligne de commande, un langage de script (smalltalk), ton outil de gestion de source, etc…
La différence (et là où je rejoint ta critique) est, AMHA, que sous linux on a une plus grande variété d'outils, et plus matures. Néanmoins il y a certains des outils de pharo que je voudrai bien retrouver pour d'autres langages, comme le classbrowser ou l'outil de recherche de méthode
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.