Journal Quelques langages de programmation pour GNOME

Posté par swilmet le 14 décembre 2013 à 19:56. Licence CC By‑SA.

Étiquettes :

déc.

2013

Sommaire

Le langage C
Python
Vala

C, Python, Vala, C++, C#, JavaScript, Java, Perl, GOB, Genie et sûrement d'autres. Autant de langages possibles pour écrire une application pour GNOME. Voyons voir ce que le C, Python et Vala ont dans le ventre !

Le langage C

Le langage C peut être vu comme un langage assez primitif. Mais c'est sans compter les nombreuses bibliothèques de GNOME : GObject, GLib, GTK+, et bien d'autres (écrites elles-mêmes en C).

GObject, le cœur de GNOME, offre un système dynamique de types, permettant de faire de l'orienté objets avec de l'héritage, des interfaces, et tout ce qui s'en suit. La gestion de la mémoire se fait avec un compteur, quand celui-ci tombe à 0, l'objet est détruit. Un objet peut envoyer et recevoir différents signaux, permettant d'exécuter des fonctions callback quand le signal est envoyé. Un objet peut avoir aussi des propriétés, qui sont comme des attributs, mais permettent en plus de recevoir un signal quand la valeur est modifiée.

Ce système de signaux permet de faire de la programmation évènementielle, ce qui est indispensable pour une application avec interface graphique, pour réagir aux différentes actions de l'utilisateur.

Une autre bibliothèque fondatrice de GNOME est la GLib. La GLib offre un système de threads couplé à une Main Event Loop. Les évènements concernant une application sont ajoutés à la Main Event Loop, et leur traitement peuvent être lancés dans différents threads. Les threads peuvent communiquer de manière asynchrone. Mais la GLib est bien plus que cela, c'est aussi une boite à outils pour les développeurs, offrant de nombreuses fonctionnalités de haut niveau, ainsi que la manipulation de structures de données de base telles que des listes chaînées, des arbres ou des tables de hachage.

Bref, c'est du costaud.

Petit bémol : pour utiliser GObject en C, il faut un peu de code de remplissage (boilerplate), notamment certaines macros. Il existe des outils pour générer ce code de remplissage, donc au final ce n'est pas si embêtant que cela. Mais ça peut faire peur quand on ne connait pas. L'idéal serait d'avoir un IDE gérant le boilerplate facilement, notamment renommer une classe, tout en gardant une bonne indentation du code en suivant les conventions de GNOME (certains outils existent, mais renommer une classe reste quand même fastidieux).

Un autre désavantage du C en général : la gestion manuelle de la mémoire, bien sûr.

Je vois par contre de nombreux avantages :

C'est un langage à typage statique, l'étape de compilation permet d'éviter plein d'erreurs triviales, qu'il serait parfois difficile de trouver à l'exécution (par exemple du code qui est exécuté quand le disque dur est plein). Pour la maintenabilité du code, c'est important.
C'est aussi un langage à typage explicite : le type est visible dans le code. Le type d'une variable est une forme d'auto-documentation.
Les nombreux outils pour le C : gdb, valgrind, éditeurs de texte, …
Une bonne « greppabilité » du code. Par exemple gtk_widget_show() contient le namespace (gtk), le nom de la classe (widget), et le nom de la méthode (show). Dans un langage orienté objets, c'est généralement object.show(). Si on recherche dans le code seulement « show », on se retrouvera surement avec de faux positifs. Avec grep, en C, on peut aussi se retrouver avec de faux positifs, mais tant qu'on ne crée pas de script automatisant une tâche, ça ne pose pas de problème. Sinon, un IDE peut utiliser la libclang pour avoir une connaissance parfaite du code. Pour C++, Java ou autre, il faut d'office passer par ce genre d'outil, grep ne suffit pas. D'autre part, le fait d'avoir le namespace et le nom de la classe est aussi une forme d'auto-documentation.
Lorsqu'on développe une application, il arrive un jour qu'on ait envie de rendre notre code réutilisable. Si c'est du C, il est plus facile de créer une bibliothèque qui soit utilisable par plein d'autres langages (voir paragraphe suivant).

Python

Grâce à GObject-introspection, les bibliothèques basées sur GObject sont disponibles pour d'autres langages tels que Python et JavaScript. Quand GObject-introspection n'existait pas, des bindings devaient être créés et maintenus, comme par exemple PyGTK pour permettre d'utiliser GTK+ en Python. Maintenant, cela se fait de manière automatique.

Par contre, il n'est pas possible d'écrire une bibliothèque en Python et de l'utiliser en C (avec GObject-introspection en tout cas).

Si on me demandait mon avis (ça tombe bien, je suis en train d'écrire ce journal), je dirais que Python ne devrait être utilisé que pour des scripts, des plugins ou petites applications, qui ne dépassent pas les 1000 lignes de code, disons. Pour un logiciel plus gros, il faut écrire plein de tests unitaires pour assurer une bonne maintenabilité. Les tests unitaires ne règlent néanmoins pas le problème de la moins bonne auto-documentation du code.

Autre chose, en C, pour savoir si on utilise des fonctions obsolètes de GTK+ (exemple pris de manière tout à fait non-fortuite), une simple compilation suffit. En Python, c'est à l'exécution que les warnings apparaissent (un pythoneux peut peut-être éclairer ma lanterne ici, existe-t-il un outil pour avoir ce genre de warnings automatiquement ? Et pour faire un recherche intelligente dans le code, si on cherche les appels à une certaine fonction par exemple ?).

Vala

C'est un langage créé pour faciliter l'usage de GObject. Les spécificités de GObject sont intégrées directement dans la syntaxe du langage, qui est assez proche du C#. Le compilateur valac transforme le code Vala en langage C, pour être ensuite compilé avec GCC, Clang, ou autre.

Vala est un bon langage pour débuter dans GNOME, je dirais. Pour les développeurs plus expérimentés, ça convient bien aussi pour une petite application. Mais quand on en fait une utilisation plus poussée, Vala montre ses limites :

quelques bugs du compilateur ;
pour débugger, le print-debugging est plus pratique que de lancer un débuggeur sur le code C généré. Pour avoir une backtrace lors d'un crash, il faut donc faire la traduction inverse C -> Vala.

La toolchain n'est donc pas très bonne.

Ceci dit, Vala a l'avantage de pouvoir créer une bibliothèque basée sur GObject-introspection, puisque le code est transformé en C. Il est donc tout à fait possible d'utiliser en C ou en Python du code qui est écrit en Vala. Mais l'utilisation d'une bibliothèque Vala en C n'est parfois pas très naturelle (par exemple la libgee).

Voilà les raisons pour lesquelles je préfère le C, actuellement. C'est un langage d'un peu plus bas niveaux, mais cela donne une impression de bien maitriser ce que l'on fait. Un peu comme un utilisateur de Gentoo, il a une impression de bien maitriser sa distrib, puisqu'il a une meilleure connaissance de ce qui est installé sur son système. Mais bon, c'est assez subjectif.

# Et Javascript dans tout ça ?

Posté par remjg le 14 décembre 2013 à 21:11. Évalué à 8.

On a beaucoup parlé dernièrement de Javascript pour développer des applications GNOME. Le choix avait surpris étant donné que Vala semblait la solution d'avenir… Qu'en est-il maintenant ?
- [^] # Re: Et Javascript dans tout ça ?
  
  Posté par swilmet le 14 décembre 2013 à 21:22. Évalué à 4.
  
  Je ne connais vraiment pas bien JavaScript, mais de ce que j'ai pu en voir, il n'y a pas eu beaucoup de changements depuis que ce langage a été élu « le langage de GNOME » (pour les applications, pas pour les bibliothèques).
  
  Et par exemple la libpeas, la bibliothèque pour gérer des plugins dans une application, a retiré récemment le support pour JavaScript, car c'était buggé depuis un moment, sans aucun rapport de bug. Donc on peut supposer que personne n'écrivait de plugin en JavaScript, pour une application basée sur libpeas (notamment gedit et totem). Évidemment GNOME Shell a toujours ses extensions en JavaScript, mais ce n'est pas basé sur libpeas.
  - [^] # Re: Et Javascript dans tout ça ?
    
    Posté par swilmet le 14 décembre 2013 à 22:12. Évalué à 3.
    
    Je parle bien des changements autours de JavaScript dans GNOME. Il y a certainement eu des changements dans JS, mais en-dehors de GNOME.
    
    Suite à la hackfest juste avant le FOSDEM en février 2013, les développeurs d'Anjuta (l'IDE de GNOME) ont travaillé dans le but de fournir un profil JavaScript à Anjuta. Je ne sais pas où ça en est actuellement. De mon côté, j'essaye de migrer certaines fonctionnalités de gedit vers GtkSourceView, avec comme but de pouvoir créer facilement des éditeurs de texte spécialisés (ou des IDE complets) basé sur GtkSourceView, sans réimplémenter les fonctionnalités de gedit ou Anjuta. Ça a commencé avec la recherche et remplacement pour le début de mon GSoC cet été. Et je continue maintenant avec le chargement et la sauvegarde de fichiers (contrairement à ce qu'on pourrait croire, ce n'est pas si simple).
    - [^] # Re: Et Javascript dans tout ça ?
      
      Posté par remjg le 15 décembre 2013 à 14:06. Évalué à 1.
      
      Merci pour les explications et encore bravo pour ton excellent travail (j'utilise Latexila tous les jours, alors rien que pour ça je te dois une fière chandelle !).
# Troll spotted

Posté par cfx le 15 décembre 2013 à 09:46. Évalué à -8.

Un autre désavantage du C en général : la gestion manuelle de la mémoire, bien sûr.

Lire ça en (presque) 2014, ça me fait un peu de peine…
- [^] # Re: Troll spotted
  
  Posté par j_m le 15 décembre 2013 à 11:29. Évalué à 10.
  
  Un autre désavantage du C en général : la gestion manuelle de la mémoire, bien sûr.
  
  Lire ça en (presque) 2014, ça me fait un peu de peine…
  
  Le langage a beaucoup évolué ses derniers temps ? Il ne faut plus faire de malloc ni de free ?
  - [^] # Re: Troll spotted
    
    Posté par cfx le 15 décembre 2013 à 16:15. Évalué à -8.
    
    Bien sûr que si, mais ce n'est pas là ou je voulais en venir.
    
    Même si, je le reconnais volontiers, c'est un peu pénible de gérer manuellement la mémoire, je préfère de loin ça au fait de compter sur un ramasse miette dont - loi de Murphy oblige - on découvrira les lacunes le mauvais jour.
    - [^] # Re: Troll spotted
      
      Posté par anaseto (site web personnel) le 15 décembre 2013 à 16:46. Évalué à 10. Dernière modification le 15 décembre 2013 à 16:46.
      
      La question qu'on peut se poser : est-ce que les ramasses-miettes d'aujourd'hui en moyenne ont plus de lacunes que les programmeurs qui font leur gestion mémoire à la main?
      
      Une autre question : est-ce que dans toutes les applications ces éventuelles lacunes ont une importance, ou alors seulement pour certaines applications spécifiques ?
      
      Comme je pense pas que ces questions (et il y en a sans doute d'autres) aient une réponse binaire, c'est normal que les deux types de gestion-mémoire existent, et du coup il n'y en a pas un universellement meilleur que l'autre.
      - [^] # Re: Troll spotted
        
        Posté par anaseto (site web personnel) le 15 décembre 2013 à 16:57. Évalué à 3.
        
        Comme je pense pas que ces questions (et il y en a sans doute d'autres) aient une réponse binaire …
        
        Bah, en fait, telles que je les ai posées, un peu ;)
        
        Disons que les problématiques soulevées par ces questions n'ont pas de solution binaire… bon, je sens que je vais pas y arriver sans y mettre des quantificateurs, mais on se comprend.
      - [^] # Re: Troll spotted
        
        Posté par cfx le 15 décembre 2013 à 18:14. Évalué à 1.
        
        Je suis assez d'accord avec toi : les éventuelles lacunes des ramasse miettes n'ont pas forcément d'importance.
        
        Si tu écrits une petite application qui manipule quelques méga de mémoire pendant quelques minutes/heures, le ramasse miettes sera amplement suffisant.
        
        Par contre, si ton application stocke quelques giga de données en mémoire, ou encore qu'elle tourne pendant des semaines, là c'est un peu plus risqué de se reposer sur une gestion automatique de la mémoire (ou en tout cas, cela demande plus de réflexion).
        
        [^] # Re: Troll spotted
        
        Posté par groumly le 17 décembre 2013 à 08:04. Évalué à 10.
        
        Justement, non, c'est tout le contraire.
        Le probleme des gc, c'est la latence, meme un gc concurrent finit par forcer une pause, et ca freeze tout.
        Selon le contexte et la duree de la pause, c'est un probleme ou pas. Une pause de qq ms sur un serveur, c'est pas vraiment un pb. Dans une ui, c'en est un.
        Une pause de qq secondes sur un serveur, ca devient un probleme.
        Sorti de ca, les gc sont plutot tout benef:
        - pas de fuites, sorti des bugs de programmations, evidemments
        - vachement moins de boulot pour le developeur
        - gc veut generalement dire heap compaction, et ca, tu l'aimes quand ton process il dure longtemps: pas de fragmentation, et tes allocations reviennent grosso modo a deplacer un pointeur de la taille de l'allocation
        
        Au final, une appli a courte duree de vie a tout interet a ne pas utiliser de gc: pas de fragmentation de la hea, les potentielles fuites sont pas un gros probleme, et tu te tapes pas de pauses.
        A l'inverse, une appli qui vit tres longtemps a tout interet a compresser sa heap regulierement et les fuites sur le long terme peuvent etre un probleme.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Troll spotted
        
        Posté par Lizzie Crowdagger (site web personnel) le 17 décembre 2013 à 11:25. Évalué à 6.
        
        Question bête (j'avoue que je connais pas spécialement le fonctionnement des garbage collectors) : il n'y a pas moyen de forcer le «nettoyage» (ouais, je maîtrise vraiment pas les termes) du GC à un moment précis, histoire d'être un peu tranquille par la suite (par exemple, dans un lecteur de musique, lancer le GC entre deux morceaux vu qu'il y a de toute façon un blanc, afin d'éviter qu'il se déclenche au milieu du morceau suivant) ?
        
        [^] # Re: Troll spotted
        
        Posté par groumly le 17 décembre 2013 à 16:43. Évalué à 3.
        
        Tu peux, mais ca changera pas grand chose au problème de latence.
        Au contraire, ca va l'aggraver: ta heap va grossir beaucoup plus si tu collectes moins souvent (enfin… a priori, ca va dépendre pas mal de ton pattern d'allocation), et donc tu vas passer encore plus de temps a collecter. Si la pause était un problème avec la latence précédente, y'a pas de raisons que ca soit moins un problème si t'augmentes la taille de a collecter.
        Le gc ideal, c'est un gc qui collecte peu mais super souvent (mais pas trop non plus).
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    - [^] # Re: Troll spotted
      
      Posté par Antoine le 15 décembre 2013 à 17:28. Évalué à 5.
      
      je préfère de loin ça au fait de compter sur un ramasse miette dont - loi de Murphy oblige - on découvrira les lacunes le mauvais jour.
      
      Et les lacunes du programmeur qui utilise malloc() à qui mieux mieux, on les découvre le bon jour ?
      - [^] # Re: Troll spotted
        
        Posté par cfx le 15 décembre 2013 à 18:02. Évalué à 2.
        
        En un mot : Valgrind.
        
        Et pour avoir été confronté à quelques reprises à des problèmes de ramasse miettes feignant en Java, je trouve bien plus simple de gérer la mémoire à la main et d'intégrer Valgrind à mes tests que de chercher pourquoi le ramasse miette n'a pas libéré de la mémoire qui aurait pu l'être.
        
        [^] # Re: Troll spotted
        
        Posté par Antoine le 15 décembre 2013 à 20:28. Évalué à 5.
        
        Par curiosité, tu utilises cette méthode sur des applications de quelle taille ? (KLOC)
        
        [^] # Re: Troll spotted
        
        Posté par Maxime (site web personnel) le 16 décembre 2013 à 11:03. Évalué à 3.
        
        Python repose surtout sur la technique de comptage de références pour gérer la mémoire. J'ai moins de soucis de programmes consommant trop de mémoire en Python qu'en Java.
        
        [^] # Re: Troll spotted
        
        Posté par groumly le 17 décembre 2013 à 08:07. Évalué à 5.
        
        Un gc feignant en java? C'est une premiere :)
        
        Tu peux decrire un peu plus ce que tu veux dire par gc feignant?
        Mon petit doigt me dit c'est que tu retenais des references a des objets qui etaient joignables, et le gc t'as evite qq erreurs de segmentations ;-)
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
- [^] # Re: Troll spotted
  
  Posté par swilmet le 15 décembre 2013 à 11:38. Évalué à 0.
  
  Quel langage faut-il utiliser, alors ? Pour garder la plupart des avantages du C que j'ai cité, je vois Java et C#. Mais le support pour GNOME est moins bon. Quoi que, il y a eu un GSoC cette année pour GObject-introspection pour la JVM, donc on peut espérer avoir un bon support. C# a sorti une deuxième beta récemment pour GTK+ 3, donc ils sont un peu à la traine.
  
  Dans tous les cas, le C restera le langage de choix pour les bibliothèques.
# Val(hal)a

Posté par saltimbanque (site web personnel) le 15 décembre 2013 à 11:32. Évalué à 7.

Vala est un bon langage pour débuter dans GNOME, je dirais

On compte quand même plusieurs projets d'envergure en vala. Donc geary, et à première vue même leur implémentation IMAP est en vala.
- [^] # Re: Val(hal)a
  
  Posté par swilmet le 15 décembre 2013 à 11:50. Évalué à 2.
  
  Oui chez Yorba ils aiment bien Vala. Et dans les nouvelles applications GNOME, il y en a quelques unes en Vala aussi, dont Clocks (mais Clocks est une petite application, contrairement à Shotwell ou Geary).
  
  Donc Vala est aussi utilisé dans des grosses applications, mais peut-être qu'ils s'en mordront les doigts plus tard (si Vala n'est plus bien maintenu dans le futur, par exemple… d'ailleurs ces derniers temps il y a beaucoup moins de changements par rapport à il y a quelques années). Ou au contraire, peut-être qu'en choisissant Vala ils ont fait un excellent choix, si le compilateur s'améliore (basé sur LLVM par exemple), et que la toolchain en général s'améliore aussi.
  - [^] # Re: Val(hal)a
    
    Posté par ckyl le 15 décembre 2013 à 13:38. Évalué à 9. Dernière modification le 15 décembre 2013 à 13:40.
    
    Donc Vala est aussi utilisé dans des grosses applications, mais peut-être qu'ils s'en mordront les doigts plus tard
    
    Vu que certaines parties du bureau Linux semblent condamnées à rester au stade du CADT et que geary fait parti de ce cirque est ce vraiment important ?
    
    Il faudrait avant dépasser l'étape du proof-of-concept qui ne fait rien tout en réussissant à la fois à avoir l'une de ses trois fonctionnalités qui dépend de gmail (dans ce cas pourquoi l'utiliser ?), et à crasher en permanence. Mais d'ici là une nouvelle réécriture de 0 d'un client mail sans aucune fonctionnalité aura eu lieu…
    - [^] # Re: Val(hal)a
      
      Posté par swilmet le 15 décembre 2013 à 14:09. Évalué à 2.
      
      Oui, je trouve aussi un peu dommage de réinventer la roue à chaque fois. D'un autre côté, Geary a une interface fort différente de Evolution ou Thunderbird je pense. C'est bien aussi d'avoir le choix du client mail qu'on utilise, pour que ça convienne le mieux à nos besoins et préférences. Mais c'est un peu bête que Geary n'utilise pas Evolution Data Server (EDS).
      
      C'est pour ça qu'il est plus intéressant de contribuer à un projet existant plutôt que de commencer un projet dans son coin, qui la plupart du temps n'aboutit pas à grand chose. En contribuant à un projet existant, on profite aussi de l'expérience des autres développeurs. Un article intéressant à lire à ce sujet : Working on Free Software.
      - [^] # Re: Val(hal)a
        
        Posté par saltimbanque (site web personnel) le 15 décembre 2013 à 19:03. Évalué à 4.
        
        J'aurai adoré qu'ils contribuent à ça : https://www.guadec.org/session/evolution-as-email-service-for-the-gnome-desktop/.
        
        Mais je sais qu'ils ont regardé le code de EDS avant de choisir de bâtir depuis zéro. Je pense que ça représente un certain investissement en temps et que ce n'est pas pour rien hélas.
        
        Quand à se baser carrément sur evolution, là je pense que ce n'était pas du tout faisable. Ils ne visent pas la même chose. Tout comme Shotwell est très bien, mais ne correspond pas forcément à tout le monde.
        
        Récemment, Red Hat a parlé de mettre du monde sur Evolution pour le moderniser un peu, mais en visant vraiment spécifiquement l'entreprise (et pour pallier à la mort de Thunderbird plus que pour le fun).
        
        [^] # Re: Val(hal)a
        
        Posté par saltimbanque (site web personnel) le 15 décembre 2013 à 19:13. Évalué à 3.
        
        ah, à propos du NIH, je retrouve l'une des explications de Jim Nelson, à partir de
        “You Should Improve Thunderbird / Evolution / (my favorite email app)”
        
        [^] # Re: Val(hal)a
        
        Posté par ckyl le 15 décembre 2013 à 20:00. Évalué à 10. Dernière modification le 15 décembre 2013 à 20:02.
        
        Merci pour le lien. Malheureusement l'explication est clairement NIH ou CADT:
        
        What steered us away from this approach was our criteria for conversations over threading, fast search, and a lightweight UI and backend.
        
        Une simple critère d'UI mérite clairement de jeter 10 ans de dev et toutes les features qui vont avec pour répartir à 0:
        
        Le fast-search génial, sauf que part defaut ca marche uniquement sur les deux dernières semaines. Quand tu le fais bosser sur toute la mbox il meurt.
        
        C'est lightweight par ce que ca fait rien. On en reparle dans 10 ans quand il saura faire quelque chose
        
        The suggestion was flatly rebuffed: use an extension. For us, that’s an unsatisfying answer.
        
        Clair que ca vaut le coup de tout jeter par ce qu'on aime pas n'être qu'une extension. Si c'était pas possible techniquement, il manque l'argumentation.
        
        Evolution is 900,000 lines of code, and includes many features we did not want to take on. Its fifteen years of development also bring with it what Federico Mena Quintero succinctly calls “technical debt”.
        
        Il vaut mieux des features en trop ou aucune ? C'est sur aussi qu'en réécrivant tout les deux ans ont à pas de technical debt, mais on a un produit de merde jamais fini aussi.
        
        In comparison, Geary stands at 30,000 lines of code today.
        
        Après 3 ans super génial ! Sauf que ça fait rien. Ça sait même pas afficher tous les messages d'une mailbox, choisir la langue du dictionnaire, faire un filtre, un raccourci clavier.
        
        Bref les enfants ne faites pas ça…
        
        [^] # Re: Val(hal)a
        
        Posté par zebra3 le 16 décembre 2013 à 10:24. Évalué à 4.
        
        Une simple critère d'UI mérite clairement de jeter 10 ans de dev et toutes les features qui vont avec pour répartir à 0:
        
        Je suis d'accord, sauf que s'il faut tout jeter juste pour refaire l'UI, c'est qu'il y avait un problème à la base : le backend et le frontend devraient être clairement dissociés, et il semble que c'est le cas pour Evolution (avec le composant EDS).
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Val(hal)a
        
        Posté par swilmet le 16 décembre 2013 à 11:37. Évalué à 1.
        
        Evolution a l'air d'avoir quand même beaucoup d'éléments réutilisables, dont EDS qui sert à gérer le carnet d'adresses et le calendrier. Il y a aussi Camel pour gérer plein de choses en rapport avec les mails, comme les objets MIME, le protocole IMAP, etc.
        
        Les développeurs de Yorba ont quand même sans doute raison sur un point, c'est que ces librairies sont assez vielles. Il n'y a pas que le code qui est ancien, il y a aussi l'API. Pour le code, c'est plus facile de le moderniser, tandis que pour l'API, ils sont un peu coincés. Il y a sans doute moyen de créer une API plus moderne, basée sur GIO notamment. Ils pourraient évidemment casser l'API, sortir une nouvelle version majeure, etc, mais ça demande beaucoup d'efforts, avec pour risque d'amener des régressions.
        
        Mais de là à recommencer from scratch une toute nouvelle implémentation, il faut vraiment le vouloir.
        
        [^] # Re: Val(hal)a
        
        Posté par saltimbanque (site web personnel) le 16 décembre 2013 à 12:21. Évalué à 5.
        
        Camel.Imap : "I should really add more detail here, but I just don't care - I barely understand the code either"
        
        [^] # Re: Val(hal)a
        
        Posté par saltimbanque (site web personnel) le 16 décembre 2013 à 12:23. Évalué à 5.
        
        Et dans la série documentation merveilleuse
        
        [^] # Re: Val(hal)a
        
        Posté par Antoine le 15 décembre 2013 à 20:33. Évalué à 8.
        
        Réutiliser EDS, ce n'est pas la même chose qu'améliorer Evolution. Enfin, j'imagine qu'on peut réutiliser EDS depuis autre chose qu'Evolution…
        
        Par ailleurs, l'argument de la dette technique n'a pas grand sens quand tu appelles une bibliothèque : si j'appelle une API de la glibc, je me fiche que l'implémentation sous-jacente soit pleine de vieux chemins bizarres (tant que ça marche correctement).
        
        Bref on continue le vieux feuilleton des développeurs Gnome qui sont infichus de construire sur l'existant et préfèrent tout casser à intervalles réguliers.
        
        [^] # Re: Val(hal)a
        
        Posté par swilmet le 15 décembre 2013 à 21:42. Évalué à 2.
        
        Sans parler de Music, Photo, et d'autres noms pas pratique à chercher dans un moteur de recherche. Au lieu d'améliorer Rhythmbox ou Banshee (pour la musique); eog (Eye of GNOME), Shotwell ou encore gthumb (pour visionner des images).
        
        J'aime bien les technologies de GNOME, en tant que programmeur. Mais il y a plein de choses pour lesquelles je ne suis pas d'accord dans les directions que prend GNOME. Heureusement, ça n'impacte pas le petit monde des éditeurs de texte et GtkSourceView.
# Organisation d'un projet écrit en C ?

Posté par Taurre le 15 décembre 2013 à 15:01. Évalué à 2. Dernière modification le 15 décembre 2013 à 15:01.

Salut,

Merci pour cette petite dépêche.
J'aurais une question étant donné que l'utilisation du C est plébiscitée : comment organiser correctement un projet ? Je veux dire, la quantité d'objets à allouer peut vite devenir assez importante (et, en conséquence, la quantité de pointeurs) ce qui rend la gestion assez fastidieuse, notamment lorsqu'il s'agit de gérer les relations entre ceux-ci.

Sinon, le lien pointant vers le dépôt git du projet GNOME ne fonctionne pas (celui amenant au fichier gtksourcesearchcontext.h), il produit une erreur 403.
- [^] # Re: Organisation d'un projet écrit en C ?
  
  Posté par swilmet le 15 décembre 2013 à 15:22. Évalué à 1.
  
  Le lien fonctionne bien ici.
  
  Pour l'organisation d'un projet en C pour GNOME, le mieux est d'analyser l'architecture d'un logiciel existant (gedit par exemple), et de s'en inspirer. Généralement on crée une sous-classe de GtkApplication pour la gestion générale de l'application, surtout au démarrage et à l'arrêt. On peut avoir quelques singletons par-ci par-là pour stocker certaines données, sous forme de fichier XML par exemple. Quand l'instance du singleton est créée, les données sont extraites et stockées dans des structures de données (en mémoire), et quand l'application quitte, les données sont sauvegardées. Ce n'est qu'un exemple bien sûr, il peut y avoir d'autres classes interagissant avec une base de données, etc. Il y a aussi généralement une sous-classe de GtkApplicationWindow, qui permet de coller les différents composants de la fenêtre principale ensemble. On peut imaginer une classe SidePanel, avec une instance stockée dans un attribut de la fenêtre principale.
  
  Toutes les bonnes pratiques de l'orienté objets s'appliquent. Certains n'aiment pas les singletons, donc rien n'empêche d'utiliser d'autres design patterns. Il vaut mieux faire attention à ne pas créer des « God Classes », qui en savent un peu trop. Et éviter si possible trop de dépendances entre les différentes classes. La sous-classe de GtkApplicationWindow aura sans doute des attributs vers beaucoup d'autres classes, mais la dépendance ne va que dans un sens.
  
  Enfin, pour apprendre GObject, il y a beaucoup d'explications dans la documentation officielle. La partie « I. Concepts » est très importante. Mais ça peut être assez difficile à comprendre au début. Il y a quelques livres sur GLib/GObject/GTK+, mais aucun n'est vraiment récent. C'est un reproche que je fais aux développeurs de GTK+, il faudrait qu'un des développeurs mette à jour un des livres…
  
  Pour finir, j'ai écris récemment une page getting started pour gedit, ça peut toujours être utile pour d'autres projets. Mais comme je l'ai dit dans un commentaire plus haut, il vaut mieux contribuer à un projet existant.
  - [^] # Re: Organisation d'un projet écrit en C ?
    
    Posté par swilmet le 15 décembre 2013 à 15:46. Évalué à 1.
    
    Pour moi la chronologie logique d'apprentissage est GLib -> GObject -> GIO -> GTK+. Le livre Foundations of GTK+ Development commence direct par GTK+ et n'apprend que très tard comment créer une sous-classe d'un widget existant (ce qui est très utile dès le début, pour éviter de se retrouver avec des variables globales de plus en plus grosses, ce qui est à éviter à tout prix).
    
    Par contre, le livre The Official GNOME 2 Developer's Guide a une chronologie logique, mais se fait un peu vieux, surtout pour les derniers chapitres, mais aussi pour GObject, il y a moins de boilerplate aujourd'hui, et on peut espérer d'autres simplifications dans le futur (GProperty notamment).
  - [^] # Re: Organisation d'un projet écrit en C ?
    
    Posté par Taurre le 19 décembre 2013 à 09:55. Évalué à 2.
    
    Merci pour vos réponses, je vais regarder tout cela de plus près. ;)
# Python & GObject-Introspection

Posté par jon le 15 décembre 2013 à 15:15. Évalué à 10.
Je suis mainteneur d'un projet qui utilise PyGObject (Python 3 + GObject-Introspection) et je suis pour le moment moyennement satisfait.

PyGObject a encore pas mal de défauts je trouve qui rende son utilisation pas forcément facile :
- manque de doc : la plupart du temps, il faut lire l'API C du module qu'on veut utiliser et essayer de deviner comment l'utiliser en Python. http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/index.html est intéressant mais pas suffisant, j'ai une todo-list longue comme le bras de trucs que je voudrais rajouter dedans, mais j'ai jamais pris le temps de le faire (ça c'est ma faute).
  Du coup, pour les fonctionnalités de base, c'est assez facile, mais dès qu'on sort de l'ordinaire, ça devient parfois compliqué, surtout que …
- le wrapper n'est pas complet : PyGObject introduit une espèce de couche intermédiaire en Python (les "overrides") qui masque l'API C en proposant une API Python "plus agréable", comme par exemple récupérer le résultat d'un appel de fonction comme résultat de la fonction Python, et non comme un pointeur à passer à la fonction. Sauf que ces "overrides" sont fait à la main, au cas par cas, et que quand on tombe dans un cas où il n'existe pas, c'est pas joli à voir. J'ai plus d'exemple en tête, mais il faut créer des objets GVariant avec les types qui vont bien, les passer en paramètres à la fonction et récupérer le résultat dedans après…
  Il y a aussi des bugs dans les bibliothèques qui fournissent les informations d'introspection, qui font ben qu'il faut attendre la prochaine version pour avoir un truc utilisable. Les mainteneurs sont assez ouverts pour rajouter un override qui va bien, sauf que …
- c'est le bordel dans les versions de PyGObject : si on veut pas se taper le boilerplate ci-dessus, on est obligé de cibler une version super-récente de PyGObject … qui n'est pas disponible de partout : Debian testing a 11 versions de retard par exemple (Debian stable n'en parlons pas), j'avais des utilisateurs sous Gentoo qui étais obligé d'unmasker python-gobject je crois et d'autres problèmes sous Archlinux. J'ai des warnings quand je lance mon application, si je fixe mon warning ça ne marche pas avec des anciennes versions de PyGObject (j'ai dû annuler mon commit).
  Au final, on se retrouve soit à ajouter du boilerplate vraiment dégeulasse et temporaire pour pallier au manque de PyGObject, soit on vise que des versions super-récentes de la bibliothèque, soit on ne fait pas (en ce moment, je fais juste pas :/ )
- les performances. PyGObject et PyGtk (l'ancien wrapper statique) sont le jour et la nuit niveau performance ; sur des exemples simples (ajouter des éléments dans un Gtk.ListStore par exemple), on a des temps multipliés par 4 en utilisant PyGObject. Les mainteneurs sont au courant qu'il y a des problèmes de performance, et il y a eu plusieurs modifications dans ce sens, mais c'est pas encore assez suffisant :/
- la stabilité : je sais pas si ça vient exactement de PyGObject dans ce cas là, mais j'ai eu plusieurs Segmentation Fault depuis qu'on est passé à Python 3 + PyGObject, inreproduisible, ça arrive juste comme ça. Par mauvaise conscience, j'accuserais quand même PyGobject, sans vraiment pouvoir le montrer…
Au delà de ça, je trouve la techno super intéressante, et c'est un point de passage obligé dès qu'on cible Python 3, mais à l'usage c'est pas forcément très agréable…
- [^] # Re: Python & GObject-Introspection
  
  Posté par swilmet le 15 décembre 2013 à 15:31. Évalué à 0.
  
  Merci pour ton retour d'expérience plus détaillé. Pour la documentation, où il faut se référer à l'API C et deviner la traduction dans le langage de plus haut niveau, il y a plus ou moins le même problème pour Vala. La solution est de lire le fichier vapi (qui décrit l'interface entre C et Vala).
- [^] # Re: Python & GObject-Introspection
  
  Posté par Albert_ le 15 décembre 2013 à 23:36. Évalué à 10.
  
  Euh franchement rien n'a change en 10 ans quoi. C'est toujours le bordel pour trouver la moindre info sur python et gnome!
  
  Bon je ne suis pas du tout masochiste donc je regarde et je vous admire mais moi je repars faire du python avec Qt.
# C vs Python pour des applis Gnome

Posté par Maxime (site web personnel) le 16 décembre 2013 à 11:27. Évalué à 10.

En 2006, j'ai écris une petite appli en C/Gtk+ pour Gnome. Cette appli a été abandonnée faute de temps et motivation (mais toujours présente dans les dépôts officiels Ubuntu). J'avais commencé à ajouter de nouvelles fonctionnalités mais faire une interface graphique en C (enfin, juste la partie logique, heureusement il y a glade), c'est juste fou. La moindre fonctionnalité prend un temps fou, j'ai laissé tomber.

Depuis, j'ai eu le temps d'apprendre le Python. Ok le Python n'est pas parfait, mais on peut diviser le nombre de lignes de code par 10 comparé au C, gagner en clarté et éviter ainsi un paquet de bugs. Alors ouais, on catch moins d'erreurs avant exécution qu'avec un langage compilé, ok. Mais il existe quand même des outils pour vérifier l'absence d'erreur de syntaxe et des outils pour la qualité du code qui va nous aider à repérer des trucs louches.

Bref, mon avis est que le C c'est super pour les applis qui ont besoin de performance, qui font des choses simples mais proprement, etc. Mais quand il s'agit de faire des applis de taille moyenne pour Gnome (c'est le thème du journal), alors le Python est excellent. Il va permettre de coder plus vite et d'ajouter plus de fonctionnalités et en terme de bugs et maintenabilité, son code plus concis et plus clair est un atout. Dans tous les cas, t'es obligé de tester correctement ton appli. C'est pas ta compilation qui va te permettre de détecter des erreurs d'algo.

Je pense que pour dire « Python ne devrait être utilisé que pour des scripts, des plugins ou petites applications, qui ne dépassent pas les 1000 lignes de code, disons. », il faut vraiment avoir un manque d'expérience en Python.
- [^] # Re: C vs Python pour des applis Gnome
  
  Posté par swilmet le 16 décembre 2013 à 11:53. Évalué à 4.
  
  C'est tout le débat entre les langages à typage statique et dynamique. Je suis tout à fait conscient que Python est utilisé pour des gros, voir très gros, logiciels. Mais je ne suis pas convaincu.
  
  Quand on écrit from scratch un nouveau programme, et qu'on est le seul développeur, forcément on a une bonne connaissance du code (mais ça ne va plus de même quelques mois ou années plus tard). Mais quand on doit plonger dans du code Python qu'on ne connait pas, j'en ai l'expérience, je trouve ça horrible. Quand on voit le prototype d'une fonction, on ne sait même pas de quel type sont les arguments ! (bon, j'ai entendu qu'il était possible de définir le type, dans ce cas-là, mais combien de développeurs le font ?) Il faut trouver les appels de la fonction en question, voir quelles variables sont passées en arguments, pour espérer savoir de quel type sont les variables. Avec un peu de malchance, il faut recommencer le processus (trouver l'appel de la seconde fonction, etc).
  
  Autre exemple, quand on veut faire du refactoring, renommer une méthode, une classe, etc. J'ai donné l'exemple dans le journal de la méthode « show ». Vas-y pour trouver tous les appels de la méthode show dans un code volumineux… Avec une bonne greppabilité du code, et une compilation pour détecter les erreurs, aucun soucis.
  
  Et je suis loin d'être le seul à penser ce genre de choses. Bien sur ça ne fait pas très plaisir à entendre quand on est convaincu par les langages dynamique (pour des gros programmes), et qu'on y a travaillé de cette façon pendant plusieurs années… J'aimerais pourtant avoir tord, mais j'aimerais qu'on m'explique comment on procède dans les deux situations que je viens de décrire.
  - [^] # Re: C vs Python pour des applis Gnome
    
    Posté par dave_null (site web personnel) le 16 décembre 2013 à 12:36. Évalué à 1.
    
    En fait tu veux un langage avec du typage statique. Est-ce que quelque chose comme TypeScript répondrait à tes besoins ?
    - [^] # Re: C vs Python pour des applis Gnome
      
      Posté par swilmet le 16 décembre 2013 à 13:43. Évalué à 1.
      
      Intéressant, en effet.
      
      TypeScript is designed for development of large applications
      
      Ça confirme mon point de vue.
      
      Quoi qu'on en pense, Microsoft est assez bon dans les langages de programmation. Je n'irais pas à dire que Visual Basic est bien, il faut quand même pas exagérer. Mais C# et .NET ont l'air bien foutu. Et des initiatives comme TypeScript est une bonne idée aussi je trouve.
      - [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Maxime (site web personnel) le 16 décembre 2013 à 14:03. Évalué à 2.
        
        Je n'ai jamais essayé mais tu devrais aussi regarder : http://www.mypy-lang.org/
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par swilmet le 16 décembre 2013 à 14:21. Évalué à -1.
        
        TypeScript (pour JavaScript) et mypy (pour Python) démontrent bien que des gens sont intéressés par le typage statique, tout en bénéficiant de fonctionnalités de haut niveau.
        
        Mes questions posées dans le journal ainsi que dans ce thread restent toujours sans réponse… J'ai pu aussi remarquer quelques moinssages du journal. Ce qui prouve sans doute que certains ne sont pas d'accord (alors que marquer un journal comme « inutile » est différent de marquer son désaccord).
        
        Comme dirait je ne sais plus qui, « On a toujours tord d'avoir raison trop tôt. »
        
        On en reparle dans 20 ans :-) ?
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Maxime (site web personnel) le 16 décembre 2013 à 14:33. Évalué à 3.
        
        Je suis moi-même intéressé par le typage statique. Cela faciliterait la vérification, l'optimisation et l'outillage. Comme je l'ai dit, ce langage n'est pas parfait. Mais il est souple, il a une syntaxe épurée et claire, et il permet de développer rapidement. Ce qui en fait un langage de choix pour développer une appli pour un environnement de bureau. Je pense que ses défauts sont dépassés par ses avantages face à du C pour ce cas précis d'utilisation.
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par swilmet le 16 décembre 2013 à 14:54. Évalué à -3.
        
        Le style épuré du Python vient principalement du fait que ce n'est pas un langage à typage explicite. Étant donné que le type d'une variable est une forme d'auto-documentation, je ne vois pas où est l'avantage.
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par barmic le 17 décembre 2013 à 11:04. Évalué à 2.
        
        Le go a une syntaxe épurée avec un typage statique.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par LeBouquetin (site web personnel, Mastodon) le 17 décembre 2013 à 08:45. Évalué à 2.
        
        Je suis moi-même intéressé par le typage statique. Cela faciliterait la vérification, l'optimisation et l'outillage. Comme je l'ai dit, ce langage n'est pas parfait. Mais il est souple, il a une syntaxe épurée et claire, et il permet de développer rapidement. Ce qui en fait un langage de choix pour développer une appli pour un environnement de bureau
        
        Je me suis mis à QT il y a quelques temps. Avec python. A la base je fais plus du dév client/serveur, web, api, etc. Bah pour découvrir l'API QT en codant en python… comment dire… tu sais que ça existe, mais tu n'as aucun moyen de trouver seul. Par opposition, tu dév en C++ avec QT, tu utilises le bon IDE et tu te régales à découvrir ton framework, son api et à développer. J'ai développé quelques temps en C# pour faire des applis avec interface graphique en environnement Windows, c'était vraiment agréable de coder.
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Maxime (site web personnel) le 17 décembre 2013 à 10:25. Évalué à 3.
        
        Je fais en ce moment beaucoup de PyQt, et j'ai déjà fait du Qt en C++ il y a quelques années. Je travaille avec la doc sous la main et puis voilà. Mon IDE (vim + des mods pour Python) me complète une partie des fonctions mais c'est vrai que c'est incomplet. En tout cas, une fois que tu connais l'API de Qt, ce problème disparaît.
        
        Au passage, je préfère écrire en PyQt :
        
        mon_bouton.clicked.connect(self.mon_slot)
        
        que l'équivalent C++ (en espérant ne pas me tromper, sa syntaxe n'est pas aussi évidente et je n'ai pas fait de Qt en C++ depuis un moment) :
        
        connect(mon_bouton, SIGNAL(clicked()), this, SLOT(mon_slot()));
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par LeBouquetin (site web personnel, Mastodon) le 17 décembre 2013 à 10:37. Évalué à 4.
        
        Je suis totalement d'accord sur la lisibilité du code et sur le fait qu'une fois que tu connais ça marche bien.
        
        Le problème que je vois, c'est qu'avec des API très riches, l'auto-complétion proposée avec des langages fortement typés est sans égal en terme de confort, notamment lorsque des méthodes proposent différentes signatures.
        
        J'apprécie python - j'en fais beaucoup, mais j'en reconnais aussi certaines limites.
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par barmic le 17 décembre 2013 à 11:09. Évalué à 8.
        
        python est fortement typé. C'est vraiment le fait que le typage soit résolu au runtime (le duck-typing) qui bloque ce genre de fonctionnalités.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par barmic le 17 décembre 2013 à 11:07. Évalué à 2.
        
        La différence ne viens pas du typage, mais de la possibilité de réflexion 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: C vs Python pour des applis Gnome
        
        Posté par barmic le 17 décembre 2013 à 11:01. Évalué à 7.
        
        J'ai pu aussi remarquer quelques moinssages du journal. Ce qui prouve sans doute que certains ne sont pas d'accord (alors que marquer un journal comme « inutile » est différent de marquer son désaccord).
        
        Un gros troll sur les langages dans le quel tu pose ta vérité comme si c'était une vérité absolue, un journal qui dans le titre parle de gnome, mais qui finalement ne contient rien de très intéressant ni de très neuf à ce sujet, d'ailleurs un journal qui parle finalement très peu de Gnome pour surtout laisser place à du gros troll de bas étage (aucune des critiques que tu formule n'est liée à Gnome, tu laisse juste tes goûts parler),… moi ça ne m'étonne pas qu'il y ai du moinssage.
        
        Comme dirait je ne sais plus qui, « On a toujours tord d'avoir raison trop tôt. »
        
        Tu sais que l'intelligence est la chose la mieux réparties sur Terre ?
        
        Ton journal conforte surtout mon idée. On ne choisi pas un langage pour Gnome, on choisi un langage tout court.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par swilmet le 16 décembre 2013 à 14:25. Évalué à 1.
        
        Au lieu de fixer un langage qui n'est pas bien conçu dès le départ (pour des grosses applications), c'est plus intéressant de créer un nouveau langage. Rust est un excellent exemple, puisque le compilateur fait plus de vérifications que pour le C.
      - [^] # Re: C vs Python pour des applis Gnome
        
        Posté par lendemain le 16 décembre 2013 à 19:29. Évalué à 2.
        
        Tant qu'a continuer dans la suggestion de langages et si ton cadre de choix dépasse GTK tu peux regarder racket.
        
        Il possède un sous langage typé.
        
        Il possède des contrats (ce qui permet aussi d'indiquer le type des arguments de fonctions en tant que signature).
        
        Il est construit autour de la porté léxical ce qui devrai facilité le refactoring sur les noms et la grepabilité.
        
        Il possède des macros ce qui devrai te dispensé d'avoir un EDI déglutissant des kilo de lignes de code squelette GUI.
        
        Il possède un framework de GUI avec un système de programmation objet (probablement comparable à celui de ruby).
        
        Il possède une véritable REPL ce qui est plutôt un sine qva none pour du prototypage rapide.
        
        Les mauvais points (du moins ceux que j'ai rencontrés):
        
        Les différentes composantes typage/contrats/class ne fonctionne pas parfaitement ensemble et doivent être cloisoné (principalement avec le typage).
        
        La documentation est trés compléte mais pas vraiment orienté tutoriel.
        
        Si tu compte mieux comprendre le langage/vm et ses méchanismes primaires tu vas devoir lire les publications scientifiques, pas de blog bien présenté et simple.
        
        Il y a des chances que les librairies utilisable te semble limité.
        
        Langage large donc apprentissage long mais formateur (j'ai le sentiment que les autres langage dynamique ne sont en fait que des sous ensemble de racket).
        
        Pas d'exemple de gros projets écrit en racket autre que le langage lui même.
        
        Manque d'outils typiquement un graph des modules et de leurs utilisations, pas d'outils de refactoring.
        
        Comme je fais pour savoir si j'ai des fuites mémoire? (visualvm pour java par exemple)
        
        Pour finir si le point qui te rebute le plus c'est la syntaxe lisp, alors je te conseille de faire un effort et si tu persévère tu auras du mal a revenir à une syntaxe 'traditionelle'.
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Lizzie Crowdagger (site web personnel) le 16 décembre 2013 à 21:10. Évalué à 2.
        
        Par contre y'a pas de bindings Gtk+, je crois ? :/
        
        Pour faire des applis GNOME si on aime les parenthèses, ça doit par contre être possible avec Clojure vu qu'il y a des bindings Java (j'avais testé vite fait un Hello World Gtk, ça marchait, mais j'ai pas regardé plus en détail (je trouvais pas non plus le code hyper élégant, mais bon (ah et le problème de la syntaxe Lisp c'est qu'après t'as un peu trop tendance à imbriquer des parenthèses))).
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par anaseto (site web personnel) le 16 décembre 2013 à 21:14. Évalué à 1.
        
        J'ai appris racket pendant une-deux semaines les dernières vacances d'été, et j'ai trouvé que c'était vraiment une agréable surprise.
        
        La documentation est trés compléte mais pas vraiment orienté tutoriel.
        
        Ce n'est pas du tutoriel à la perl ou ruby, c'est sûr, mais c'est loin d'être juste d'être une documentation du type api des fonctions. Et le langage de documentation scribble est vraiment génial, produit une doc bien cross-reférencée, agréable à lire, et franchement, c'est la partie de racket qui m'a plut le plus par rapport à d'autres langages (pour dire, j'ai appris avec le guide officiel, puis en jetant des coups d'œils au manuel de référence en suivant les liens sans ressentir le besoin de tutoriels pour débutants non officiels).
        
        Les différentes composantes typage/contrats/class ne fonctionne pas parfaitement ensemble et doivent être cloisoné (principalement avec le typage).
        
        Sur ce point, je confirme, en tant que débutant avec le langage j'ai essayé d'utiliser un peu typed-racket mais j'ai pas très bien compris comment s'engenceaient les choses (et pour le coup j'ai trouvé que la doc était un peu plus froide que pour le reste).
        
        Langage large donc apprentissage long mais formateur (j'ai le sentiment que les autres langage dynamique ne sont en fait que des sous ensemble de racket).
        
        C'est vrai qu'il y a beaucoup de choses, mais le langage est très uniforme, j'ai pas eu l'impression qu'il soit spécialement long à apprendre. Le plus dur ça a été de comprendre les macros (j'en avais jamais fait avant), et j'ai lu la doc sur les contrats mais je ne les ais pas utilisés. Bon, il me resterait sans doute encore pas mal de choses en plus à apprendre ;) mais bon, depuis j'en ai plus vraiment fait par manque de temps.
  - [^] # Re: C vs Python pour des applis Gnome
    
    Posté par Lizzie Crowdagger (site web personnel) le 16 décembre 2013 à 15:44. Évalué à 5.
    Mouais…
    
    Je trouve que dire « le typage dynamique, ça marche pas pour les gros projets », c'est quand même un peu simpliste, il me semble qu'il y a quand même quelques contre-exemples. Cela dit, pour le refactoring, je suis d'accord que typage dynamique + orienté objet ça rend les trucs un peu compliqué, puisqu'effectivement quand tu vois x.show () tu sais pas si c'est un appel à la méthode qu'il faut renommer ou à une autre méthode show () qui doit continuer à s'appeler show (), elle.
    
    Par ailleurs, je suis pas sûre que C/Gobject soit vraiment un très bon exemple de typage statique. Dans du code C/Gobject, il y a beaucoup de casts qui se contentent de vérifier que t'as un pointeur, ou encore des fonctions qui prennent ou qui renvoient du void * (enfin, du GPointer), et pour tout ce qui est objet les vraies vérifications de type (par exemple, vérifier que GtkWindow hérite de GtkWidget et que tu peux donc effectivement appeler gtk_widget_truc) elles se font en fait en dynamique. Un petit exemple (tiré d'un "Hello World" Gtk+) :
```
gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
                     GTK_SIGNAL_FUNC (gtk_widget_destroy),
                 GTK_OBJECT (window));
```
    Là en fait la seule vraie vérification statique de typage, c'est que "clicked" est bien un char *, par contre tu peux compiler sans que button ou window ne soient des GtkObject, et avec gtk_widget_destroy qui n'ait pas du tout la bonne signature (je pense quand même que ça vérifie que c'est un pointeur sur fonction).
    
    Donc le typage statique, pourquoi pas, mais dans ce cas il faut un autre langage que le C…
    - [^] # Re: C vs Python pour des applis Gnome
      
      Posté par swilmet le 16 décembre 2013 à 16:06. Évalué à 1.
      
      Entièrement d'accord. Il parait que GObject en C++ vérifie plus de choses à la compilation.
      
      (l'exemple est assez ancien, GtkObject et GtkSignal n'existent plus depuis un bon bout de temps, mais les principes restent valides)
      
      On peut espérer dans le futur avoir des plugins pour GCC ou Clang pour faire ce genre de vérifications. Et un développeur a justement commencé ce boulot récemment pour Clang.
      - [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Lizzie Crowdagger (site web personnel) le 16 décembre 2013 à 20:55. Évalué à 2.
        
        (l'exemple est assez ancien, GtkObject et GtkSignal n'existent plus depuis un bon bout de temps, mais les principes restent valides)
        
        Ah oui tiens, je me disais que c'était un peu bizarre, mais j'ai pas pensé à vérifier de quand datait cet exemple :)
        
        On peut espérer dans le futur avoir des plugins pour GCC ou Clang pour faire ce genre de vérifications. Et un développeur a justement commencé ce boulot récemment pour Clang.
        
        Je savais pas, c'est intéressant comme projet (mais du coup, est-ce que ça ne revient quand même un peu à ce que tu disais là : http://linuxfr.org/nodes/100669/comments/1507561 ? :) D'ailleurs, pour l'instant il n'y a pas de bindings et Rust est encore en développement, mais je me dis qu'à terme ça pourrait être plutôt intéressant comme alternative pour du dev Gtk+)
      - [^] # Re: C vs Python pour des applis Gnome
        
        Posté par saltimbanque (site web personnel) le 18 décembre 2013 à 12:12. Évalué à 2.
        
        gtk_signal_connect_object (GTK_OBJECT (button), "clicked", GTK_SIGNAL_FUNC (gtk_widget_destroy), GTK_OBJECT (window));
        
        Fort heureusement, si tu te trompes sur les objets, à l’exécution, ça te dira "Invalid cast from Window to Button"
        
        C'est donc surtout chiant pour le typage des fonctions. On peut parfois éviter le cast mais c'est vrai que ça revient un peu au même, une fonction void obscure_func (GObject* button, void* data) n'aide pas des masses.
  - [^] # Re: C vs Python pour des applis Gnome
    
    Posté par Antoine le 16 décembre 2013 à 19:01. Évalué à 4.
    
    Quand on voit le prototype d'une fonction, on ne sait même pas de quel type sont les arguments !
    
    Si la fonction n'est pas documentée, en effet. On peut penser que si la fonction n'est pas documentée, elle ne fait pas partie d'une API publique :-)
    
    Autre exemple, quand on veut faire du refactoring, renommer une méthode, une classe, etc. J'ai donné l'exemple dans le journal de la méthode « show ». Vas-y pour trouver tous les appels de la méthode show dans un code volumineux… Avec une bonne greppabilité du code, et une compilation pour détecter les erreurs, aucun soucis.
    
    Les tests unitaires remplissent la fonction de la phase de compilation, de ce point de vue (tout en allant beaucoup plus loin car les tests ne se limitent pas à vérifier que les types conviennent).
    
    Quant à la "greppabilité" du code, c'est plus une question de style objet (namespaces imbriqués, avec des noms souvent réutilisés) vs. style procédural (tout à plat, avec des noms très distinctifs). On peut très bien n'utiliser que des fonctions globales en Python.
    
    Ceci dit si tu penses que C est mieux pour lire du code existant, je te suggère de lire, au hasard, le code d'OpenSSL :-)
    - [^] # Re: C vs Python pour des applis Gnome
      
      Posté par Lizzie Crowdagger (site web personnel) le 16 décembre 2013 à 20:50. Évalué à 4.
      
      Les tests unitaires remplissent la fonction de la phase de compilation, de ce point de vue (tout en allant beaucoup plus loin car les tests ne se limitent pas à vérifier que les types conviennent).
      
      Mouais, je pense que c'est bien, les tests unitaires, mais c'est un peu optimiste de penser qu'il y en a systématiquement et qu'ils couvrent tous les bouts du code :) (Surtout que pour les applis graphiques qui demandent une interaction avec l'utilisateur, je trouve pas évident de faire des tests unitaires)
      
      Quant à la "greppabilité" du code, c'est plus une question de style objet (namespaces imbriqués, avec des noms souvent réutilisés) vs. style procédural (tout à plat, avec des noms très distinctifs). On peut très bien n'utiliser que des fonctions globales en Python.
      
      C'est pas juste une question de style objet et de greppabilité : en Java t'as aussi de l'objet, mais si tu refactores une méthode, t'as la compilation qui va t'envoyer bouler s'il y a un endroit où tu n'as pas modifié l'appel (et, j'imagine, des IDE qui permettent de faire ça automatiquement). C'est la combinaison "objet" et "dynamique" qui rend ça embêtant, parce que si t'oublies un appel dans une fonction obscure qui ne se lance pas tout le temps, tu (ou un utilisateur) ne t'en rendras compte qu'à l'exécution. (Cela dit, oui on peut éviter l'objet en python)
      
      Cela dit, autant je pense qu'un typage statique permet de détecter pas mal d'erreurs à la compilation, autant avec un typage dynamique, certes ça plante à l'exécution, mais en général c'est des erreurs où on voit assez trivialement d'où ça vient (puisqu'il y a quand même une vérification des types, et que tu vas avoir une erreur du genre "Grrrr, tu me donnes une chaine de caractères alors que je veux un entier"). Je trouve ça moins pénible à débugger qu'en C quand t'as un pointeur sur un tableau qui n'est pas la bonne taille, et que ça ne vérifie ni à la compilation, ni à l'exécution, mais que tu te retrouves avec une segfault ou des données bizarres à un autre endroit du code.
      - [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Antoine le 17 décembre 2013 à 01:29. Évalué à 3.
        
        Mouais, je pense que c'est bien, les tests unitaires, mais c'est un peu optimiste de penser qu'il y en a systématiquement et qu'ils couvrent tous les bouts du code :)
        
        Ben oui, mais c'est aussi très optimiste de penser que le typage statique va attraper toutes les erreurs de programmation… Or la gamme d'erreurs attrapées par les tests n'est limitée que par la patience du programmeur (qui est extensible), tandis que la gamme d'erreurs attrapées par le typage statique est bornée par la définition du langage (qui n'est pas extensible).
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par LeBouquetin (site web personnel, Mastodon) le 17 décembre 2013 à 08:53. Évalué à 5.
        
        Tu parles comme s'il n'était pas possible de faire des tests unitaires sur des langages typés statiquement…
        
        Le problème avec les langages dynamiques, c'est que ce que tu sais à la conception - le type d'objet que tu manipules à un instant donné (par exemple quand tu définis la signature d'une nouvelle méthode) n'est pas capitalisé pour la personne qui va reprendre / maintenir / faire évoluer ton code. Avec un langage typé statiquement, si tu ne fais pas volontairement des trucs "crades", tu capitalises forcément d'un intervenant à l'autre sur le code.
        
        Dans les langages qu'on juge souvent moches, il y a PHP ; par rapport à ses origines, PHP a désormais un typage dans les signatures de méthodes… ce n'est probablement pas pour rien. Sur des projets d'envergure, tu es vraiment serein quand tu codes avec un typage statique : ce n'est peut-être pas plus rapide à développer, mais tu n'as pas les fesses qui font bravo à chaque refactoring : tu sais ce que tu casses et ce que tu ne casses pas.
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Antoine le 17 décembre 2013 à 12:41. Évalué à 3.
        
        Tu parles comme s'il n'était pas possible de faire des tests unitaires sur des langages typés statiquement…
        
        La question d'origine n'est pas de savoir si on sait faire des tests unitaires avec du typage statique, mais si le typage dynamique pose des problèmes de qualité de code.
        
        Avec un langage typé statiquement, si tu ne fais pas volontairement des trucs "crades", tu capitalises forcément d'un intervenant à l'autre sur le code.
        
        Oui, c'est vrai. Ceci dit, c'est "toutes choses égales par ailleurs". En pratique, le choix entre un langage dynamique X, et le même langage X mais avec typage statique, n'existe pas. Tu as le choix entre Python et C, ou Ruby et Rust, etc. Pas entre Python et "un Python typé statiquement avec une puissante inférence de type".
        
        Dans les langages qu'on juge souvent moches, il y a PHP ; par rapport à ses origines, PHP a désormais un typage dans les signatures de méthodes… ce n'est probablement pas pour rien
        
        Personnellement, j'éviterais de prendre PHP en référence, hein.
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par LeBouquetin (site web personnel, Mastodon) le 17 décembre 2013 à 13:10. Évalué à 2.
        
        Dans les langages qu'on juge souvent moches, il y a PHP ; par rapport à ses origines, PHP a désormais un typage dans les signatures de méthodes… ce n'est probablement pas pour rien Personnellement, j'éviterais de prendre PHP en référence, hein.
        
        C'est toi qui voit. PHP n'est pas un langage de programmation aussi avancé que python, mais PHP est tout de même utilisé par des milliers de développeurs, que ce soit sur des projets type "Kévin bidouille dans son garage" ou pour des très très gros projets. C'est par ailleurs un langage qui semble en partie guidé par un certain pragmatisme, et si le typage statique a été ajouté, c'est peut-être parce que cela a des avantages.
        
        Pour le reste, je suis d'accord avec toi.
  - [^] # Re: C vs Python pour des applis Gnome
    
    Posté par flan (site web personnel) le 16 décembre 2013 à 20:56. Évalué à 3.
    Bof, si tu en es réduit à utiliser le type des arguments comme toute documentation d'une fonction, c'est que le code est mal fichu et c'est plus dangereux qu'autre chose.
    Personnellement, je me plonge régulièrement dans du code Python d'autres personnes, et j'ai rarement du mal à comprendre, bien au contraire.
    
    Une bonne documentation est importante, quelque soit le langage…
    
    Python offre un truc bien sympa pour ça, d'ailleurs : les doctests
    Petit exemple de Python 3 :
```
def ma_fonction(argument1: int=default_value1, argument2: str=default_value2) -> float:
      """[documentation de ma_fonction]
      >>> ma_fonction(1, 'toto'):
      1.
      >>> ma_fonction(10):
      -5.
      """
      [...code...]
```
    Le code suivant >>> sert à la fois d'exemple et de « test unitaire ». Au moins, tu es sûr que les exemples sont fonctionnels :)
    - [^] # Re: C vs Python pour des applis Gnome
      
      Posté par LeBouquetin (site web personnel, Mastodon) le 17 décembre 2013 à 08:56. Évalué à 6.
      Bof, si tu en es réduit à utiliser le type des arguments comme toute documentation d'une fonction, c'est que le code est mal fichu et c'est plus dangereux qu'autre chose.
      
      C'est de la langue de bois, ça : dire que le typage des données correspond à de la documentation ne signifie à aucun moment que c'est la seule documentation.
      
      PArailleurs, l'exempleque tu donnes, c'est le truc qui me dérange souvent quand je fais du python : les exemples donnés dans la doc ne sont pas exhaustifs, et bien entendu tu tombes toujours dans le cas "non documenté".
      - [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Antoine le 17 décembre 2013 à 12:46. Évalué à 3.
        
        PArailleurs, l'exempleque tu donnes, c'est le truc qui me dérange souvent quand je fais du python : les exemples donnés dans la doc ne sont pas exhaustifs, et bien entendu tu tombes toujours dans le cas "non documenté".
        
        Donc, en gros, quand tu tombes sur une documentation incomplète, c'est la faute du langage de programmation ? On est en plein dans la mauvaise foi, là.
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par LeBouquetin (site web personnel, Mastodon) le 17 décembre 2013 à 13:05. Évalué à 1.
        
        Il me semble que cette méthode de documentation est prônée par les aficionados de python (et dans les guide-lines ?), je me trompe ? (si oui, alors ok, mea culpa)
        
        [^] # Re: C vs Python pour des applis Gnome
        
        Posté par Antoine le 17 décembre 2013 à 17:44. Évalué à 3.
        
        Ce n'est pas censé remplacer une documentation classique, c'est juste un complément. La PEP 257 (Docstring Conventions) ne mentionne même pas les doctests. En faire ou non, c'est plus une question de goût et de choix personnel.
# détecter les fonctions obsolètes

Posté par Pol' uX (site web personnel) le 17 décembre 2013 à 12:08. Évalué à 2. Dernière modification le 17 décembre 2013 à 12:08.

un pythoneux peut peut-être éclairer ma lanterne ici, existe-t-il un outil pour avoir ce genre de warnings automatiquement ?

Je pense qu'un pythoneux répondrait « l'outil s'appelle: faire des tests, systématiquement ».

Adhérer à l'April, ça vous tente ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.