Javascript comme langage par défaut pour GNOME

Posté par (page perso) . Édité par Christophe Guilloux, patrick_g, Florent Zara et baud123. Modéré par Florent Zara. Licence CC by-sa
Tags : aucun
49
6
fév.
2013
Gnome

Les développeurs GNOME se sont rassemblés pour proposer des solutions afin d'améliorer l' expérience des développeurs. Dans la suite des annonces sur GNOME 4.0 et la volonté de fournir un SDK stable et accessible, cette édition est centrée sur l'expérience des nouveaux développeurs d'application tierce.

La question centrale est : « Quel processus depuis l'ouverture de mon éditeur jusqu'à l'installation de mon application par des utilisateurs ? ». Opération séduction donc, pour GNOME qui veut devenir une plateforme plus attractive pour les développeurs d'applications.

Sommaire

Le souci de plaire aux développeurs n'est pas nouveau au sein du projet GNOME. Dès son origine, le développeur doit pouvoir écrire une application GNOME dans le langage de son choix. Ce fut un des objectifs de GObject puis de GObject introspection, un des fondements de la plateforme GNOME.

Aujourd'hui que les bases techniques sont là, c'est une approche globale qui est recherchée pour multiplier les applications GNOME. L'idée est donc de fournir une solution officielle et unifiée aux problématiques du développement d'application, sans exclusive.

Le Hackfest

L'événement s'est déroulé à Bruxelles, capitale de la Belgique et haut lieu du logiciel libre grâce notamment au FOSDEM. Une trentaine de développeurs se sont réunis, y compris des développeurs du noyau comme Greg Kroah-Hartman ou des trolleurs comme Lennart Poettering.

À l'instar de la conception de l'interface utilisateur, les développeurs GNOME ont commencé la réflexion par analyser l'État de l'art dans la concurrence : SDK iPhone, OS X, Firefox OS, Androïd et Windows.

Outils de développement

Une des premières questions est : avec quoi coder ? Le projet GNOME propose plusieurs IDE, principalement Anjuta et MonoDevelop pour les plus actifs. Mais Emacs, Vim ou même Gedit restent des choix répandus. Question restée ouverte. Des idées ont émergé comme livrer des jeux d'extensions pour Emacs ou vim intégrant Devhelp, glade et d'autres outils incontournables pour le developeur GNOME.

GtkParasite

Un deuxième aspect est le débuggage. C'est actuellement difficile de debugguer des interfaces en Gtk. Pourtant, des initiatives existent comme GtkParasite, un inspecteur à là Firebug. Ce genre d'outils gagnerait à être intégré et supporté dans la plateforme de développement. D'autres utilitaires de débuggages DBus, GObject, etc. gagneraient à avoir plus de visibilité.

Documentation

On ne peut pas se contenter de lire le code des autres. Le récent travail de fond sur http://developer.gnome.org/ va être poursuivit. il faut reconnaître la tâche considérable accomplie par des projets OPW pour documenter le développement d'application GNOME.

Outre les discussions, du code a été écrit durant l'événement. L'application de navigation dans la documentation − Devhelp − a commencé sa migration vers l'ergonomie GNOME 3. Portage vers gsettings, python3 et webkit2 et une tripotée de corrections de bugs. Le menu d'application est utilisé, mais la barre de menu de fenêtre persiste.

Devhelp 3.7.5

Plateforme et Javascript

Une décision importante a été prise par les membres de ce Hackfest : le choix du langage par défaut pour le développement d'application GNOME. Attention, il ne s'agit pas de réécrire les programmes existants dans un nouveau langage. Actuellement, le C est utilisé pour documenter la plateforme, car c'est la langue native des bibliothèques. Il faut présenter un langage de haut niveau pour le développement d'applications.

Pourquoi mettre en avant un langage ?

La question n'est pas nouvelle. Havoc PENNINGTON avait déjà abordé le sujet à l'époque de la sortie de la plateforme .NET. Le choix était plutôt Java, Mono ou C++ ? et Havoc était un peu seul à se poser cette question.

Voici quelques raisons qui ont poussé les développeurs GNOME à se poser cette question :

  • La majorités des applications sont écrites dans un langage de plus haut niveau : python, vala, javascript, perl, C#, etc. Peu sont écrites en C ou en C++.
  • La documentation de la plateforme est en C, de fait les documentations dans les langages de haut-niveaux sont en retard, alors que GObject introspection a supprimé le retard des passerelles.
  • Harmoniser la documentation de la plateforme autour d'un langage simple et accessible.
  • Aider les nouveaux développeurs à se lancer.
  • Faciliter le partage de code entre les développeurs.
  • Garantir un environnement pour le développement rapide : passerelles vers les bibliothèques, documentation, debuggers, etc.

Mettre en avant un langage n'est pas rejeter les autres, au contraire. Le but est justement que l'utilisation première des bibliothèques de la plateforme se fasse à travers des passerelles. Hors GObject Introspection est utilisé pour tout les langages. C'est donc un gain pour tous les langages de haut niveau que d'en avoir un mis en avant.

Quelles contraintes ce langage doit-il satisfaire ?

  • Paradigme objet, dynamique, de haut niveau.
  • Permettre le REPL : read-eval-print-loop.
  • Répandu hors de GNOME.
  • Intégrable facilement avec la plateforme GNOME, sans fournir de doublons standard.

Vala n'est donc pas choisit, cependant il a de beaux jours devant lui comme langage de choix pour écrire des bibliothèques. Python est également exclu car il fournit déjà une énorme bibliothèque standard, redondante en partie avec la plateforme GNOME.

C'est finalement Javascript qui a obtenu le plus large consensus. En voici quelques raisons :

  • Réponds aux critères ci-dessus.
  • Les développements récents en font un langage rapide et indépendant de la plateforme.
  • Très répandu, de plus en plus en dehors du web avec Windows 8.
  • Déjà fait ses preuves avec GNOME Shell et GNOME Document.

Concrètement, les nouvelles applications GNOME seront en javascript, à l'instar de GNOME Document. Les autres ne devraient pas migrer sauf avis du mainteneur. Ainsi GNOME Contact restera en Vala.

Les réactions n'ont pas manqué. Javascript est un langage à prototype, n'est-ce pas étrange pour utiliser GObject ? Les interprêteurs javascripts sont variés et incompatibles. Beaucoup de développeurs ont une mauvaise opinion de javascript, souvent justifiée. L'avenir confirmera si ce choix est judicieux. En tout cas, ce n'est pas la mode qui a dicté ce choix. Javascript est déjà utilisé intensivement par GNOME.

ECMAScript 6 − nom de code Harmony − devrait résoudre nombres de réticences. L'ajout de class, extends, super, des valeurs par défaut des arguments, des modules, les chaînes sur plusieurs lignes, etc. Les développeurs python devraient retrouver un peu de calme avec tout cela. Mais quand ? On avance l'horizon 2014… en attendant il y aura des mécontents !

Et Gtk+ ?

Le choix de javascript ne doit pas occulter les questions autour de Gtk+ lui-même. En vrac :

  • Fournir un widget adapté pour les nouvelles vues en grille de l'ergonomie GNOME 3. Étonnant que ça ne soit pas déjà fait…
  • Gestionnaire de scène pour les applications par étapes, avec différentes pages. Façon application téléphone. Actuellement, on utilise un notebook sans onglets pour basculer d'une vue à l'autre.
  • Alignement des widgets sur la ligne d'écriture, et non sur les limites. Très pratique pour aligner les champs et les étiquettes.

D'autres hacks dans les applications existantes montrent des limites dans Gtk+.

Conclusion

Ce hackfest est un tournant pour définir GNOME comme une plateforme. Les décisions importantes et l'augmentation du nombre de participants montrent un projet en bonne santé côté développeurs, mais les fruits ne sont pas encore visibles : GNOME 3 est toujours le parent pauvre sur Ubuntu, les utilisateurs de GNOME 3 sont encore peu nombreux, la communauté des développeurs occasionnels encore plus ! À confirmer donc !

  • # QML bis?

    Posté par . Évalué à  10 . Dernière modification : le 06/02/13 à 16:49

    C'est rigolo cela me fait legerement pense a ce qui se fait pour Qt/KDE et qui est en route depuis plusieurs annees avec le developpement de Plasma qui a donne naissance a QML integre par defaut dans Qt. QML utilise par KDE mais aussi par Canonical pour leur OS sur les telephone.
    J'ai pas trop l'impression que ce projet ait la moindre idee de la direction ou il va et ne fait que copier les idees des autres…

    Le plus amusant dans cette nouvelle c'est la partie Python, rejete car entre en concurrence avec Gnome pour certaines briques… Si ca c'est pas une raison bidon!

    • [^] # Re: QML bis?

      Posté par (page perso) . Évalué à  10 . Dernière modification : le 06/02/13 à 17:15

      rejete car entre en concurrence avec Gnome pour certaines briques… Si ca c'est pas une raison bidon!

      C'est sûr, un des gars a porté les bindings python pour le passage a GObject-introspection dit sûrement des conneries en disant que Javascript est une bonne décision !

      C'est clair que c'est une décision qu'on peut trouver complètement idiote. Javascript est un langage tout pourri. Les différents moteurs gjs ou seed déjà utilisé sous GNOME utilisent même des dialectes incompatibles entre eux. Javascript en tant que tel laisse l'impression d'être un gros hack. Et pourtant, dans cette histoire, la force de javascript, c'est sa pauvreté. En python, on peut effectivement hésiter entre utiliser les API intégrées de base dans le langage, ou utiliser les équivalents GObject, GLib.

      En javascript, le langage est tellement à poil de base, qu'en fournissant les API GObject, il n'y a pas 50 manières de coder un truc. C'est clair que le temps d'avoir quelque chose de vraiment mieux foutu, ça va prendre du temps, que le portage vers ECMAScript 6 va être long, mais en attendant, il sera possible de fournir un SDK pour GNOME, et abaisser le niveau requis pour commencer à contribuer. J'aurais aussi préféré python. Mais je comprends pourquoi Javascript a été choisi. L'avenir nous dira si cela aura été un choix judicieux.

      Quant au retard de GTK, la fusion de Clutter et GTK est prévue pour GTK 4. Cela permettra de mutualiser les ressources, et de faire passer GTK à un modèle scène/acteur comme celui de Clutter.

      • [^] # Re: QML bis?

        Posté par (page perso) . Évalué à  4 .

        Quant au retard de GTK, la fusion de Clutter et GTK est prévue pour GTK 4

        ce serait vraiment une avancée… parce que GtkClutterEmbed gnii…

        • [^] # Re: QML bis?

          Posté par . Évalué à  2 .

          Ça voudrait dire, à terme, déprécier g_signal_connect dans Gtk+ ?

          Si c'est le cas ça va être un sacré boulot. Autrement plus compliqué que de passer de Gtk2 > Gtk3 et pourtant ça traîne encore un peu les pâtes avec les projets "externes" à GNOME.

          En ce qui concerne le langage "par défaut" du projet, j'aurais aimé qu'ils orientent vers C/Vala/Python. Mais bon Javascript pourquoi pas.

          J'imagine que ce choix, va à l'avenir permettre à GNOME de proposer plus facilement leur "Market" où nous pourrons installer/déinstaller/mettre à jour nos GNOME Apps ?

          Si c'est le cas alors Javascript trouve ici un grand intérêt car indépendant de l'architecture cliente (ARM, x86 etc..), et sans les nombreux modules Python qui pourraient ne pas être installés sur la machine (bien que la constitution d'un SDK Python eût été envisageable aussi).

          Bref ça semble être le début d'un gros chantier, en espérant que ça donne au final un beau bâtiment :)

      • [^] # Re: QML bis?

        Posté par . Évalué à  9 .

        Donc en gros pour quelques trucs en commun Gnome prefere se passer de l'enorme bibliotheque de python? En tout cas dans les applis par defaut, pour se concentrer sur un truc qui n'a … a peu pres rien et re-ecrire tout ce qui est manquant?

        C'est un choix strategique, un peu bizarre je pense mais ils ont des couilles et du temps visiblement.

        • [^] # Re: QML bis?

          Posté par (page perso) . Évalué à  1 .

          Il ne se "passent pas" de l'énorme bibliothèque en python, Javascript devient juste le langage conseillé pour un nouveau projet. Mais tous les autres langages restent supportés, c'est juste qu'il y en a un mis en avant. Le but n'est pas de porter toutes les applications, mais si de nouvelles applications doivent être écrites, le js sera conseillé, c'est tout. C'était le seul moyen pour fournir un SDK: mettre un langage en avant.

        • [^] # Re: QML bis?

          Posté par . Évalué à  5 .

          Disons que la bibliothèque standard de Python et son écosystème de bibliothèques tierce-partie sont une distraction inutile quand il s'agit de programmer des applications avec le moins de fonctionnalités possible. IL fallait un langage lui-même sans qualités, Javascript donc, mais ç'aurait pu être l'assembleur ou le COBOL orienté objet.

          • [^] # Re: QML bis?

            Posté par . Évalué à  3 .

            Sans compter le fait que les bindings Python sont pas toujours très pythonnique et sont même redondantes parfois avec les piles incluses (PyQt a eu le même problème, l'API v2 a pas mal amélioré les choses par contre). Mettre Python en avant, aurait demandé de passer plus de temps à peaufiner l'API et n'aurait pas rempli le critère essentiel "abaisser le niveau du ticket d'entrée" dans GNOME.
            Aujourd'hui, GNOME a beaucoup de mal à recruter de nouveaux développeurs, il est plus simple de recruter des développeurs javascript que C, Python & cie, sans compter que javascript est déjà au coeur du Shell.

      • [^] # Re: QML bis?

        Posté par (page perso) . Évalué à  9 .

        En javascript, le langage est tellement à poil de base, qu'en fournissant les API GObject, il n'y a pas 50 manières de coder un truc.

        Je ne vais pas critiquer le choix de JS, vu que KDE l'a fait aussi, il doit bien avoir une raison qui n'est pas une critique.
        Mais tout de même, à ce jeu là, ils auraient pu choisir OCaml!
        (D'ailleurs, il y a un projet OCaml de générateur de code JS à partir de OCaml, donc finalement, ils ont peut-être choisi indirectement OCaml…)

        Et pour éviter les trolls:

        • oui, je sais "Batteries included", tout ça
        • non, je m'en fous de ses défauts, c'est un exemple. La recherche du langage qui n'a pas de bibliothèque standard, c'est un peu particulier tout de même!
        • d'abord, le Troll, ici, c'est moi!
        • [^] # Re: QML bis?

          Posté par (page perso) . Évalué à  10 .

          ils auraient pu choisir OCaml!

          Ou mieux encore , Guile, le langage d'extension officiel du projet GNU ! Utilisé par moultes logiciels prestigieux, apprécié par les developpeurs, c'etait pourtant le choix evident

    • [^] # Re: QML bis?

      Posté par (page perso) . Évalué à  3 .

      J'ai pas trop l'impression que ce projet ait la moindre idee de la direction ou il va et ne fait que copier les idees des autres…

      Lorsqu'il s'agit de critiquer de GNOME il faut dire l'exact inverse ("va très fortement dans un sens mais qui n'est pas le bon"). pareil pour critiquer systemd. (in "Stratégie du Troll", édition Linux fr, 2012)

      • [^] # Re: QML bis?

        Posté par (page perso) . Évalué à  6 .

        C'est peut-être une blague, mais c'est exactement le reproche fait à Gnome3 et ses versions successives: que les développeurs avaient une idée précise de la direction qu'ils voulaient prendre, et que les décisions ne prenaient absolument pas en compte les avis du noyau dur des utilisateurs.

        Donc, moi non plus, je ne dirais pas qu'ils ne savent pas où ils vont. Quant à dire qu'ils se sont inspirés de KDE et QML, peut-être, oui, ou alors est-ce des EFL?
        On pourrait chercher loin là-dedans: pour chaque fonction ou aspect de l'archi qui est similaire d'un bureau à l'autre, on qualifiera le second venu de projet qui n'a aucune idée de où il va et se contente de copier les autres.

        L'ensemble des bureaux libres est en perdition! Aaaargh!!

    • [^] # Re: QML bis?

      Posté par . Évalué à  10 . Dernière modification : le 06/02/13 à 18:23

      J'ai pas trop l'impression que ce projet ait la moindre idee de la direction ou il va et ne fait que copier les idees des autres…

      D'une part je vois pas en quoi c'est un mal d'essayer de prendre le meilleur de ce qui se fait ailleurs. Personne n'a dis aux développeurs de Qt qu'ils avaient tout pompé sur les EFL (edje en particulier) pour faire leurs interfaces déclaratives en json. D'autre part les interfaces déclaratives chez Gtk/Gnome ça date de 1998 avec glade (ça me semble assez tôt pour une interface déclarative). QML est arrivé en 2010 (c'était déjà plus dans l'air du temps).

      C'est peut être plus de Qt Quick qu'ils s'inspirent, mais qu'est ce que ça change ? Note tout de même que c'est bizarre d'un coté de refuser les brevets logiciels et de se dire pour le partage et de dénigrer la moindre inspiration.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: QML bis?

        Posté par . Évalué à  6 .

        D'autre part les interfaces déclaratives chez Gtk/Gnome ça date de 1998 avec glade (ça me semble assez tôt pour une interface déclarative). QML est arrivé en 2010 (c'était déjà plus dans l'air du temps).

        Oui enfin bon, bien avant l'arrivée de QML, QT designer existait et faisait déjà exactement comme Glade (et les fichiers .ui qu'il générait étaient des fichiers XML chargeables dynamiquement, comme avec Glade…)

  • # L'événement s'est déroulé à Bruxelles, capitale de la Belgique

    Posté par . Évalué à  0 .

    Capitale de l'Europe. C'est plus connu :)

  • # Vachement objectif...

    Posté par (page perso) . Évalué à  10 .

    ou des trolleurs comme Lennart PÖTRING.

    Déjà, ça s'écrit "Lennart Poettering", et le qualifier de trolleur est un peu limite. Décrié, contesté, mais il n'est pas plus trolleur que Linus.

  • # Widget gnome 3

    Posté par (page perso) . Évalué à  5 .

    Fournir un widget adapté pour les nouvelles vues en grille de l'ergonomie GNOME 3. Étonnant que ça ne soit pas déjà fait…

    ce n'est pas intégré à gtk+ , mais en attendant il y a libgd qui propose en gros les widgets gnome-documents (grille/liste, barre principale…)

    L'idée semble d'être sûr du design avant de le pousser dans gtk+

    http://git.gnome.org/browse/libgd/

  • # jet de séduction: échec critique

    Posté par (page perso) . Évalué à  10 .

    Opération séduction donc, pour GNOME qui veut devenir une plateforme plus attractive pour les développeurs d'applications

    J'aurais dis pour pour les webmasters.

    Retrouver du javascript partout, ça commence à me gonfler.

    Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

    • [^] # Re: jet de séduction: échec critique

      Posté par . Évalué à  2 .

      Je trouve que ça a autant de validité de dire "Retrouver du C partout, ça commence à me gonfler".

      Le langage ne reste qu'un outil. Certes ils respectent un ensemble de paradigmes qui le définissent mais …

      • Ce n'est pas parce que c'est l'outil de référence pour la plateforme Gnome que ça ne permet pas d'utiliser un autre outil.
      • Ce n'est pas parce que l'outil est utilisé dans un domaine précis, et mal utilisé souvent, que ça en fait un mauvais outil.
      • Ce n'est pas parce que l'outil n'est pas forcément parfait qu'il ne va pas s'améliorer dans le temps.

      Quand on voit la qualité de certains projets en Javascript, va leur dire qu'ils font du boulot de webmasters… a contrario quand tu vois du code Java en production sur des système critiques fait par des experts(c), je me dis qu'un webmaster débutant pourrait faire vachement mieux.

      • [^] # Re: jet de séduction: échec critique

        Posté par . Évalué à  9 .

        Javascript possède tout de même des problèmes intrinsèques à sa syntaxe, surtout au niveau de la portée lexicale, qui oblige parfois les « webmasters » à créer des fonctions anonymes juste pour définir un nouveau bloc syntaxique dans une boucle …

        De plus le langage en lui-même n'est pas « fait pour » dans le sens où il a été crée pour répondre au besoin de pouvoir construire rapidement des petits programme : des scripts. Personne ne veut utiliser Bash/Zsh pour coder des applications entières, bien que ce soit possible. Javascript a d'ailleurs dans toutes ses implémentations, une gestion un peu bancale des programmes avec des sources multiples …

        Il aurait été plus intelligent de mettre en avant un langage fait pour développer des « grosses » applications, comme Vala, C++ ou même OCaml, qui permettent par le typage de faire certains débugs, et en plus de cela permettre une intégration dans la GLib d'une facilité d'interaction entre un langage de script et un langage « dur ». Ceci étant, pour une petite appli, le code de départ de l'IDE en Vala suffit, et on peut tranquillement coder dans son langage de script préféré. Et pour les grosses applis, cela permet d'avoir un noyeau réutilisable (Vala/C) dans d'autres langages, et en plus d'intégrer des parties scriptables facilement (configurations, IA …) dans une application.

        • [^] # Re: jet de séduction: échec critique

          Posté par . Évalué à  2 .

          Ouais enfin au chapitre des langages qui ont été fait pour créer des "petits programmes", il y en a qui se tapent une belle carrière aujourd'hui…
          Qui sont remis en permanence en question pour des problèmes d'implémentations, qui sont inconsistants malgré des évolution/révisions de syntaxe régulières, et pourtant qui restent le choix numéro 1 pour de nombreux projets. Et pour les lacunes dont tu parles, ça va, il y a des work-arounds, suffit juste de respecter certaines règles de conduite. C'est un peu comme les exploits sur les format string en C, si tu respectes les règles de conduite, ça ne doit pas exister … (bon ok, exemple limite, ce n'est pas une lacune dans le langage mais plutot entre la chaise et le clavier, mais bon comme la portée des variables, quand on sait on passe au travers)

          Bref, ça reste quand même du troll de renier un langage, si il y en avait un de parfait, ça se saurait et ce débat n'existerait pas. (Quoi que y'a Rust :D)

          Concernant Javascript, qui peut dire aujourd'hui que ça ne va plus évoluer ? Que la norme ne fixera jamais les lacunes actuelles ? Et justement, en devenant le langage de référence dans de multiples projets (node, Windows, Gnome, FirefoxOS, ChromeOS, etc.), est-ce que ça ne va pas accélérer les choses ?! Pourquoi tant de pessimisme donc ?!!

          • [^] # Re: jet de séduction: échec critique

            Posté par . Évalué à  5 .

            Objectivement, utiliser un langage qui n'est pas fini, en espérant des corrections futures et commencer dès maintenant à coder avec … ce n'est pas une bonne idée non ?

            Autant promouvoir Vala, qui a le mérite d'être de haut niveau, avec une syntaxe agréable, un système souple de gestion de mémoire (à la main, compteur de référence et peut être un GC), et surtout la possibilité de compiler vers du C, rendant toute librairie accessible aux autres langages … (libgee par exemple)

          • [^] # Re: jet de séduction: échec critique

            Posté par (page perso) . Évalué à  5 .

            qui sont inconsistants malgré des évolution/révisions de syntaxe régulières

            c'est le propre du numérique d'être virtuel, ce serait plus dommageable que ces langages soient incohérents :/

            Que la norme ne fixera jamais les lacunes actuelles ?

            justement, la norme fixe les lacunes actuelles, elle pourrait les corriger si elle évoluait :-)

            (Quoi que y'a Rust :D)

            oui, REXX aussi si on va par là

            ~~~~> [ ]

        • [^] # Re: jet de séduction: échec critique

          Posté par . Évalué à  10 .

          javascript a au moins une qualité: des moteurs d'exécution libres optimisés à mort

      • [^] # Re: jet de séduction: échec critique

        Posté par . Évalué à  1 .

        T'as raison, la prochaine fois que je devrais couper des planche, j'utiliserai un ciseau à bois au lieu d'une scie.
        Et puis la voiture pour aller en cours, c'est trop classique, j'vais y aller en scooter 50cm3 (quand ce sera autorisé sur l'autoroute).

        Opera le fait depuis 10 ans.

        • [^] # Re: jet de séduction: échec critique

          Posté par . Évalué à  1 . Dernière modification : le 06/02/13 à 22:28

          Si encore il y avait des exemples comme quoi ça ne marche pas, elles iraient tes comparaisons … mais là, même pas.

          • [^] # Re: jet de séduction: échec critique

            Posté par . Évalué à  6 .

            Je n'ai pas dit que JS était inutilisable, ni qu'on ne peut pas couper de bois avec un ciseau à bois.
            En revanche, le but de mes comparaisons est de dier que JS n'est peut-être pas le langage le plus adapté dans ce cas, parmi ceux qui existent.

            Ce n'est pas parce que l'outil est utilisé dans un domaine précis, et mal utilisé souvent, que ça en fait un mauvais outil.

            Sauf qu'on a des outils ayant une exécution plus rapide, avec plus de bibliothèques dispos, et, je pense, plus conçus dans ce but.

            Ce n'est pas parce que l'outil n'est pas forcément parfait qu'il ne va pas s'améliorer dans le temps.

            Sauf qu'il vaut mieux utiliser un outil prévu pour la tache qu'on souhaite effectuer. Couper en 2 proprement une planche avec un ciseau à bois n'est pas le plus simple. Le JS n'est peut-être pas le meilleur langage pour faire un programme qui ne bouffe pas trop les ressources de la machine, et pour le faire facilement.

            J'ai surtout l'impression que le JS a été choisi pour son effet de mode.

            Opera le fait depuis 10 ans.

    • [^] # Re: jet de séduction: échec critique

      Posté par (page perso) . Évalué à  5 .

      Retrouver du javascript partout, ça commence à me gonfler.

      Moi, ça ne me gonfle pas. Juste que je ne comprends pas pourquoi se manger du JS à toutes les sauces, alors que le nom évoque clairement un langage fait pour scripter . Donc autant, je suis d'accord pour le web afin de scripter la page pour la rendre dynamique selon les interactions avec l’utilisateur. Autant pour le reste, je suis sceptique.
      Après, le fait que le Javascript ne connaisse pas la POO, c'est un autre débat.

      • [^] # Re: jet de séduction: échec critique

        Posté par . Évalué à  4 .

        Après, le fait que le Javascript ne connaisse pas la POO, c'est un autre débat.

        Il n'a pas de classe, c'est normal parce qu'il fait de l'objet par prototype.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: jet de séduction: échec critique

          Posté par (page perso) . Évalué à  3 .

          Il n'a pas de classe, c'est normal parce qu'il fait de l'objet par prototype.

          C'est ce qu'il m'a semblé lire par-ci, par-là. Mais j'avoue avoir du mal à saisir les concepts par rapport à la POO. Maintenant, si cela apporte un réel avantage alors, je m'incline.

          • [^] # Re: jet de séduction: échec critique

            Posté par (page perso) . Évalué à  7 .

            Je me trompe peut-être mais de ce que j'ai cru comprendre :
            - des objets modèles sont créés avec des tables de hachage,
            - des attributs et des fonctions sont mis dans ces tables,
            - l'instanciation se fait par copie de l'objet modèle,
            - l'héritage se fait par copie puis ajout.

            J'ai déjà travaillé comme ça en Lua et avec une biblio pour le gérer correctement, c'est pas si dégueux que ça.

            Du coup ça utilise beaucoup de duck typing : il n'y a pas de type car pas de classe, mais si ça a l'air d'être un type d'objet (mêmes fonctions et attributs dans la table) alors c'est que c'en est un.

      • [^] # Re: jet de séduction: échec critique

        Posté par . Évalué à  6 .

        le nom évoque clairement un langage fait pour scripter

        JavaScript est probablement le langage le plus mal nommé de la planète : rien à voir avec du Java, et encore moins pour faire des scripts en ligne de commande à la *sh.

        Et si au passage quelqu'un pouvait me donner la définition d'un langage "de script"…

        • [^] # Re: jet de séduction: échec critique

          Posté par (page perso) . Évalué à  10 .

          Ah mince, moi quand je vais au MacDonalds, j'y vais pour manger du canard.
          Je comprends, maintenant.

          Chippeur, arrête de chipper !

          • [^] # Re: jet de séduction: échec critique

            Posté par (page perso) . Évalué à  1 .

            leur vrai nom devrait être MacPicsou dans ce cas : t'en ressors avec un poids sur l'estomac, un allègement du porte-monnaie et la dalle dès la porte sortie… (et les frites sont trop salées). Pas pour rien que j'utilise plutôt le terme mac dalle (dalle = faim, que dalle = rien) et que je n'y mets les pieds qu'une fois tous les 10 ans… (contraint et forcé, voire à l'insu de mon plein gré vu qu'il n'y a que le dessert qui est consommable et le coke fourni, vu qu'on est en France).

          • [^] # Re: jet de séduction: échec critique

            Posté par (page perso) . Évalué à  3 .

            Pffff! Ignare!
            Par contre, ils n'ont toujours pas le dernier MacBook Air, et je commence à leur dire qu'ils portent bien mal leur nom!

        • [^] # Re: jet de séduction: échec critique

          Posté par (page perso) . Évalué à  2 .

          JavaScript est probablement le langage le plus mal nommé de la planète : rien à voir avec du Java, et encore moins pour faire des scripts en ligne de commande à la *sh.

          Raison de plus pour le renommer dans une prochaine version. Parce que j'ai arrête de compter le nombre de personne qui me parlent de Java en faisant référence au JS. Et ils sont nombreux.

          Et si au passage quelqu'un pouvait me donner la définition d'un langage "de script"…

          La simplicité de Bash.

    • [^] # Re: jet de séduction: échec critique

      Posté par . Évalué à  2 .

      Et d'après toi ceux sont tous des… webmasters (et toc !) qui font ces choix ? Ou ils sont tous tombé sur la tête ?

      Juste histoire que ton commentaire soit un minimum constructif (et mérite sa note).

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: jet de séduction: échec critique

      Posté par . Évalué à  10 .

      Ben ils ont pourtant bien expliqué leur stratégie: ils vont s'occuper de l'expérience des développeurs.

      Pour l’expérience des utilisateurs, c'est déjà fait, ils sont tous partis. Bientôt il n'y aura plus de développeurs non plus et le projet gnome aura atteint une forme de pureté absolue, sans interface ni utilisateurs ni développeurs.

      C'est assez zen comme approche en fait.

      • [^] # Re: jet de séduction: échec critique

        Posté par . Évalué à  4 .

        Bon les développeurs Gnome sont idiots. Mais qu'en est il de ceux de Qt et de Windows ?

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: jet de séduction: échec critique

          Posté par . Évalué à  10 .

          Je trolle, je trolle, mais faut pas croire que ça signifie que j'aie un niveau technique suffisant pour mépriser les développeurs gnome. Par contre, historiquement je crois qu'il n'y a aucun autre projet libre qui aie provoqué un tel enchainement de WTF.

          • Ça a commencé avec l’idée de démarrer de zéro un projet juste parce que la licence de KDE ne leur plaisait pas a l’époque (oui, je ne suis pas tout jeune…).

          • Développer tout en C pour une raison dont je ne me rappelle plus.

          • On va copier la base de registre de Windows.

          • Oh et puis non on va faire du .NET, à une époque ou Mono donne encore l'impression d’être un projet loin d’être mur et très en retard sur .NET.

          • On enlève tout ce qui dépasse sur l'interface graphique, moins l'utilisateur peut en faire mieux c'est.

          • Une interface (ou ce qui en reste) qui regarde fort du coté des écrans tactiles alors que pratiquement personne ne l'utilise sur ce type de matos.

          • Et maintenant javascript, qui on va dire n'a pas la réputation d’être un langage utilisé pour des softs complexes et de qualité.

          Les développeurs de Gnome sont sans doute très bons techniquement et plusieurs (ou tous?) de ces choix peuvent se défendre individuellement, mais pris tous ensemble on a une roadmap qui fait plus penser a un épisode de Tom et Jerry qu'a un long fleuve tranquille. Du coup ça a tendance a provoquer quelques sarcasmes.

          • [^] # Re: jet de séduction: échec critique

            Posté par (page perso) . Évalué à  8 .

            Je vais juste répondre à ton premier point: le fait que KDE s'appuie sur un framework non libre (Qt à l'époque) était quand même sacrément choquant pour un bureau libre, et tout le monde avait bien compris la motivation de la création du projet Gnome à cette époque.
            Absolument rien de WTF pour le coup.

            Chippeur, arrête de chipper !

            • [^] # Re: jet de séduction: échec critique

              Posté par . Évalué à  2 .

              KDE était le premier environnement de bureau Unix bien (le premier qui dit CDE va au coin). Une réimplémentation libre de Qt (ça avait déjà été fait avec Motif/Lesstif) ou bien un peu de lobbying chez Qt (ce qui a marché par la suite…) m'aurait semble plus pertinent a l’époque plutôt que de réinventer la roue pour des raisons idéologiques.

              • [^] # Re: jet de séduction: échec critique

                Posté par . Évalué à  4 .

                Faut quand même avouer que c'est ce genre de décisions qui amène la diversité dans le libre … c'est couillu, mais c'est cool pour l'utilisateur à la fin !

              • [^] # Re: jet de séduction: échec critique

                Posté par . Évalué à  5 . Dernière modification : le 07/02/13 à 11:03

                (le premier qui dit CDE va au coin)

                Mais c'était très bien CDE ! Tellement bien qu'en 1996 un fan de CDE crée XFCE… ;-)

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: jet de séduction: échec critique

                Posté par (page perso) . Évalué à  2 .

                Tu as raison, ça a certainement été l'occasion pour les fondateurs de Gnome de faire leur propre jouet, mais après tout, n'est-ce pas justement ce qui fait la richesse du libre ?

                Chippeur, arrête de chipper !

              • [^] # Re: jet de séduction: échec critique

                Posté par (page perso) . Évalué à  7 .

                Donc en fait, tu es contre l'existence même du projet GNOME ? Tout cela me semble nauséabond et me rappelle les heures les plus sombres de notre histoire™…

                ------------------------>[]

              • [^] # Re: jet de séduction: échec critique

                Posté par . Évalué à  9 .

                Linus et le projet GNU aurait pu se contenter de demander à IBM & co de libérer Unix.

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: jet de séduction: échec critique

              Posté par . Évalué à  1 .

              KDE n'était pas le seul. Au départ, Xfce se basait sur XForms, un toolkit non libre à l'époque.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: jet de séduction: échec critique

              Posté par . Évalué à  1 . Dernière modification : le 07/02/13 à 22:17

              Je vais juste répondre à ton premier point: le fait que KDE s'appuie sur un framework non libre (Qt à l'époque) était quand même sacrément choquant pour un bureau libre, et tout le monde avait bien compris la motivation de la création du projet Gnome à cette époque. Absolument rien de WTF pour le coup.

              Il fallait réellement écrire un autre desktop entier pour ça ? Se contenter d'écrire un toolkit (L)GPL avec une API compatible n'aurait-il pas évité de diviser la communauté (et les contributions) en 2 ?
              (bon d'un autre côté, c'est ce qui a permis à Trolltech de prospérer. QT n'en serait peut-être pas là si la boîte avait été tuée dans l'oeuf à cause d'un fork LGPL trop tôt…)

              • [^] # Re: jet de séduction: échec critique

                Posté par (page perso) . Évalué à  4 .

                Questions bêtes:

                • En écrivant une API compatible en LGPL, on ne se serait pas mis en position de faiblesse, à courir après le "modèle", sur lequel le projet n'aurait d'ailleurs eu aucun pouvoir d'influence, puisque n'étant pas utilisateur? Ou alors comme tu dis, ça aurait peut-être tué Trolltech bien trop tôt.
                • Si Gnome n'avait pas existé avec des bibliothèques concurrentes à Qt, est-ce que Qt aurait vraiment été libéré?

                Je peux aussi troller sur Gnome, mais faut pas exagérer: c'est un des projets qui ont marqué l'histoire du logiciel libre, et plutôt dans le bon sens!

                (Signé: un utilisateur de KDE qui adore toujours Xfce aussi, et qui se demande ce que Xfce et toutes les applis Gtk qu'il utilise seraient devenu si Gnome était mort jeune!)

              • [^] # Re: jet de séduction: échec critique

                Posté par . Évalué à  4 .

                Avoir un second bureau ça crée une concurrence plutôt saine je trouve.

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: jet de séduction: échec critique

            Posté par (page perso) . Évalué à  8 .

            Ça a commencé avec l’idée de démarrer de zéro un projet juste parce que la licence de KDE ne leur plaisait pas a l’époque (oui, je ne suis pas tout jeune…).

            Pas la licence de KDE, la licence de Qt, qui était proprio à l'époque.

            Développer tout en C pour une raison dont je ne me rappelle plus.

            Faux. Dès les premières versions de GNOME, tout un tas de langages étaient utilisés. GNOME a toujours été "langage-agnostic", c'est à dire que des applis de tous langages sont acceptés. Si des applications étaient en C, c'est parce que c'est le langage qu'ont choisi les développeurs desdites applications. Ç'aurait pu être un autre. En revanche, les bibliothèques sont en C, car la génération de bindings vers d'autres langages est plus facile à partir du C que du C++ (de ce que j'en ai entendu).

            On va copier la base de registre de Windows.

            GConf/Dconf n'est pas la base de registre. Ces sytèmes fournissent des valeurs par défaut pour les clés, documentent chaque clé, et servent en gros de base de configuration avancée et centralisée. En quoi est-ce mal ?

            Oh et puis non on va faire du .NET, à une époque ou Mono donne encore l'impression d’être un projet loin d’être mur et très en retard sur .NET.

            C'est Miguel de Icaza qui est parti sur Mono, et bien que co-fondateur de GNOME, il n'est plus actif dans la communauté GNOME depuis des années. GNOME a officiellement une application en mono, Tomboy. Les autres sont des applications pour GNOME (comme Banshee par exemple), ce qui est différent.

            On enlève tout ce qui dépasse sur l'interface graphique, moins l'utilisateur peut en faire mieux c'est.

            La configuration se découpe en 3 étages. Les paramètres les plus fréquemment modifiés sont accessibles dans l'interface de GNOME. Ceux un peu moins courants, ou pour lesquels il n'y a pas encore d'interface graphique sont dans gnome-tweak-tool. Enfin, tous ces paramètres, + les autres paramètres avancés sont dans dconf, accessible graphiquement avec dconf-editor et en ligne de commande avec gsettings.

            Une interface (ou ce qui en reste) qui regarde fort du coté des écrans tactiles alors que pratiquement personne ne l'utilise sur ce type de matos.

            Donc ta logique c'est que GNOME ne doit faire de tactile parce que les périphériques tactiles n'utilisent pas GNOME ? C'est imparable. C'est sûr que s'ils ne bossent pas pour être tactiles, ça va être dur d'être utilisé.

            Au passage, tu as quand même des technos prometteuses qui arrivent, comme Leap Motion, et toi ce que tu proposes, c'est de rester avec sa bonne vieille souris dans la main ? Il faut bien à un moment miser sur le futur, non ?

            Et maintenant javascript, qui on va dire n'a pas la réputation d’être un langage utilisé pour des softs complexes et de qualité.

            C'est à peu près le seul point sur lequel on est d'accord.

            • [^] # Re: jet de séduction: échec critique

              Posté par . Évalué à  6 .

              C'est à peu près le seul point sur lequel on est d'accord.

              En fait, je suis a peu près d'accord avec tous tes arguments (sauf pour gconf auquel je ne me suis jamais habitué). C'est juste que des fois on a l'impression que le projet gnome choisit systématiquement les solutions qui ont le plus gros potentiel trollogène.

              • [^] # Re: jet de séduction: échec critique

                Posté par (page perso) . Évalué à  5 .

                gnome choisit systématiquement les solutions qui ont le plus gros potentiel trollogène.

                Fortune !!

                C'est certainement la meilleure contribution à la communauté ! Déjà qu'on a perdu Java, Qt, etc. On ne trolle même plus sur GPLv3 vs GPLv2 vs BSD…

          • [^] # Re: jet de séduction: échec critique

            Posté par . Évalué à  9 .

            Tu as oublié Bonobo, le truc inspiré de CORBA, très gros succès !

          • [^] # Re: jet de séduction: échec critique

            Posté par . Évalué à  1 .

            Ça a commencé avec l’idée de démarrer de zéro un projet juste parce que la licence de KDE ne leur plaisait pas a l’époque

            Tout comme RMS a créé un pilote d'imprimante libre parce que la licence de celui qu'il utilisait ne lui plaisait pas. Et ça a donné le projet GNU, comme nous le savons tous.

            Bref, sans ce genre d'idée le libre n'en serait pas tout à fait au même point aujourd'hui, y compris KDE.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Lua

    Posté par (page perso) . Évalué à  10 .

    Pourquoi le langage Lua n'est pas utilisé pour ce type de cas, c'est un langage d’extension, simple, rapide et léger?
    J'ai l'impression qu'il reste cantonné aux jeux vidéos ainsi qu'a quelques projets (awesome).

    • [^] # Re: Lua

      Posté par . Évalué à  3 .

      Mediawiki … c'est en phase de test pour le codage des modèles.

    • [^] # Re: Lua

      Posté par (page perso) . Évalué à  4 .

      Je me posais un peu la même question, et je suppose qu'il n'a simplement pas été considéré comme suffisamment populaire. Non ?

      alf.life

    • [^] # Re: Lua

      Posté par (page perso) . Évalué à  4 .

      Parce que Javascript est un meilleur choix.

      • Les outils disponibles en Javascript sont nombreux.
      • Les gens compétents en Javascript sont de plus en plus nombreux.
      • La guerre des navigateurs permet d'avoir un choix d'interpréteur Javascript, dont certains sont très avancés (V8 de Google Chrome par exemple).
      • Microsoft a choisi d'utiliser Javascript pour le développement d'applications sur Windows 8.
      • Parce que for (var i = 0, len = canard.length; i < len; ++i) (function(j) { canard[j].click(function() { alert(j);}); })(i) c'est beau
      • Parce qu'il y a des évènements
      • Parce que c'est à la mode et que Gnome a besoin d'attirer des développeurs
      • [^] # Re: Lua

        Posté par . Évalué à  6 .

        La guerre des navigateurs permet d'avoir un choix d'interpréteur Javascript, dont certains sont très avancés (V8 de Google Chrome par exemple).

        Oui, c’est sûr, LuaJIT c’est tellement lent et mal conçu en comparaison de V8…
        Tout le reste de ton message laisse suggérer qu’il s’agit d’un post ironique, mais je voulais quand même rebondir là dessus :-)

      • [^] # Re: Lua

        Posté par . Évalué à  10 . Dernière modification : le 06/02/13 à 20:30

        Parce que for (var i = 0, len = canard.length; i < len; ++i) (function(j) { canard[j].click(function() { alert(j);}); })(i)

        Non. Le prochain qui me fait tout une boucle sur une seule ligne, je lui jette son code au visage !

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Lua

          Posté par (page perso) . Évalué à  3 .

          J'espère qu'il ne bosse pas sur un mainframe…

        • [^] # Re: Lua

          Posté par . Évalué à  9 .

          canard.map(function(e, i) { e.click(alert.bind(window, i)) });
          
          

          Plus joli, non ? (et sans doute plus efficace)

          • [^] # Re: Lua

            Posté par (page perso) . Évalué à  1 .

            Internet explorer 9 requis, mais oui. J'aurais pu utiliser uniquement JQuery aussi, mais c'était pour illustrer le langage, pas pour débattre sur la meilleure façon de coder un parcours itératif en Javascript.

        • [^] # Re: Lua

          Posté par . Évalué à  0 .

          Les boucles, ca fait vraiment old school pas tres 2013 tout ca :D

    • [^] # Re: Lua

      Posté par . Évalué à  0 .

      Je me posais aussi cette question concernant ruby.

      Et ce qui m'inquiète un peu avec le nouveau Ecmascript, c'est que l'on aura le droit à 2 paradigmes de programmation : Orienté Objet et par Prototype, les deux ont une complexité qui leur est propre. Les mélanger rendra les futurs programmes probablement moins maintenable.

      • [^] # Re: Lua

        Posté par . Évalué à  2 . Dernière modification : le 06/02/13 à 22:02

        JavaScript est un langage orienté objet, c'est la notion de classe qui sera intégrée dans la prochaine évolution du langage semble-t-il.

        • [^] # Re: Lua

          Posté par (page perso) . Évalué à  -5 .

          JavaScript ne propose pas la possibilité d'encapsuler, ce n'est donc pas un langage objet, ou orienté objet.

          • [^] # Re: Lua

            Posté par . Évalué à  7 .

            Mouarf.

            Il n'est pas nécessaire que le language fournisse un mécanisme de public/private pour faire de l'encapsulation. Tu peux parfaitement le faire par convention, comme par exemple préfixer tes attributes privés avec un underscore.

            Smalltalk par exemple n'a pas de mécanisme de méthodes privés, il n'empêche qu'il est considéré comme un des langages fondateurs de la POO. Python non plus, et pourtant n'importe quel Pythoniste peut te montrer à quel point il est bien plus orienté object que Java ou C++.
            L'encapsulation c'est plus une "bonne pratique" de développement qu'autre chose.

            Ensuite tu peux tout à fait faire de l'encapsulation en Javascript, il suffit de se sortir les doigts: http://javascript.crockford.com/private.html

            Comme quoi quand Crockford parle de: "the world's most misunderstood programming language", il a part tord, mais visiblement on pourrait aussi parler de "the world's most misunderstood programming concept" à propos de la POO…

            • [^] # Re: Lua

              Posté par (page perso) . Évalué à  5 . Dernière modification : le 07/02/13 à 08:05

              Ensuite tu peux tout à fait faire de l'encapsulation en Javascript, il suffit de se sortir les doigts: http://javascript.crockford.com/private.html

              C'est quand même assez limité lorsqu'on veut un peu optimiser les choses.
              Si j'osais, je dirais que c'est comme si on filait un pistolet à billes à un soldat.
              Par exemple, définir des fonctions dans le constructeur (le concept de membre privilégié dans le texte de ce bon vieux Douglas Crockford) est une mauvaise pratique car elle instancie une méthode par instance d'objet, au lieu de la définir dans le prototype.
              Pareil pour le concept de membres privés, lorsqu'on souhaite définir les fonctions dans prototype, ces fonctions ne peuvent naturellement plus accéder aux variables du scope du constructeur, donc pour mutualiser des données entre les fonctions du prototype, on est forcé de les déclarer dans l'objet ou dans son prototype (public).
              Cela dit, j'ai pleinement pris le parti de faire comme tu disais et d'assumer pleinement les manques du langage ; je fais du private par convention, dans la documentation, et tant pis pour ceux qui passent outre. Ca a quand même des effets assez horribles, moi je m'en fous, je fais du code métier, si quelqu'un utilise des membres privés de mon code, ça sera un collègue et on peut s'arranger, mais on utilise un framework javascript connu (extjs), et lorsqu'elle possède certains manques fonctionnels, on est très tenté d'aller hériter ou écraser une méthode privée au lieu d'attendre sagement une prochaine révision du framework. Oui, c'est mal, mais j'ai remarqué qu'on était loin d'être les seuls, du coup, je plains un peu Sencha pour gérer la réorganisation de son code privé au regard de sa clientèle qui paniquera le jour où plus rien ne marche à une révision mineure supérieur :) Du coup, on met de gros warnings dans le code les quelques fois où on est poussé à le faire.

              Chippeur, arrête de chipper !

              • [^] # Re: Lua

                Posté par (page perso) . Évalué à  2 .

                Quoi qu'il en soit il a raison de souligner la POO comme pratique ; à l'inverse on peut très facilement exploiter un langage permettant l'encapsulation… et blinder d'accesseurs pour chaque variable.

                Le code de gnome-documents, ce sont bien des objets. Et après tout glib-gobject, qui a de la valeur en dehors de gnome, s'appuie bien sur du C pour en tirer une logique objet. Certains langages peuvent simplement faciliter l'écriture, mais avant tout c'est au dév de faire le boulot de penser.

                • [^] # Re: Lua

                  Posté par (page perso) . Évalué à  2 .

                  Oui, je suis d'accord, mais je ne répondais pas vraiment à cela.

                  Chippeur, arrête de chipper !

              • [^] # Re: Lua

                Posté par . Évalué à  6 .

                C'est quand même assez limité lorsqu'on veut un peu optimiser les choses

                Effectivement sur des implémentations un peu naïves de javascript c'est pas forcément très performant. J'ai plus trop le temps de chercher le lien là, mais il me semble que maintenant certaines VM arrivent tout de même à optimizer ça pas mal.

                Et puis pour travailler sur une très grosse application Backbone.js en ce moment, pour être honnête quand il y a un problème de performance et que je sort le profiler, ce qui resort comme étant lent c'est principalement les accès au DOM, la seule fois ou Javascript lui même était en cause c'était de ma faute, je m'était bêtement retrouvé avec un algo en O(n!). Et même ça m'a pris un peu de temps pour m'en rendre compte car V8 faisait extrêmement bien (trop bien ?) son taf.

                on est très tenté d'aller hériter ou écraser une méthode privée au lieu d'attendre sagement une prochaine révision du framework. Oui, c'est mal

                Non ce n'est pas mal. Il m'arrive assez souvent de faire des choses similaires. Il faut simplement connaitre le bénéfice / risque et l'assumer. Ce qui signifie en général de ne le faire qu'en cas d'absolue nécessité.

            • [^] # Re: Lua

              Posté par . Évalué à  1 .

              L'encapsulation c'est plus une "bonne pratique" de développement qu'autre chose.

              Une vraie encapsulation, ça évite en théorie qu'un rigolo viole ta convention. Ce qui arrive 9 fois sur 10.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Lua

                Posté par . Évalué à  5 .

                Une vraie encapsulation, ça évite en théorie qu'un rigolo viole ta convention. Ce qui arrive 9 fois sur 10.

                Bof, dans beaucoup de langages avec "vrai" encapsulation, si tu veux tu peux la contourner, c'est juste un peu plus difficile qu'avec une convention de nommage..

                • [^] # Re: Lua

                  Posté par . Évalué à  -1 .

                  Bof, dans beaucoup de langages avec "vrai" encapsulation, si tu veux tu peux la contourner, c'est juste un peu plus difficile qu'avec une convention de nommage..

                  Mais avant de le faire, tu te pose des questions, l'intérêt est là.
                  Les conventions de nommages c'est dans la majorité des cas une mauvaise idée :
                  Dans le code de teeworlds par exemple, les membres d'une classe commencent par m_, les tableaux par a et les pointeurs par p :

                  /* src/game/gamecore.h */
                  class CTuningParams
                  {
                      static const char *m_apNames[];
                      /* ... */
                  }
                  
                  

                  D'une part c'est lourd, d'autre part l'information est dupliquée et sans grand intérêt. Enfin elle est incomplète : pour rester cohérent, il faudrait aussi préciser que m_apNames est un tableau de pointeurs sur une chaine chaine constante
                  …Ah mais attend un peu, la convention indique aussi qu'il faut mettre s_ quand l'attribut est static ! Compliqué à respecter, sans gain notable, c'est une mauvaise idée.

                  Autre exemple en Javascript :

                  var Personne = function(nom) {
                      this._nom = nom.toUpperCase();  /* Par convention '_nom' est privé */
                  }
                  
                  Personne.prototype = {
                      /* Par convention, le nom est seulement accessible en lecture */
                      get_nom: function() {
                          return this._nom;
                      }
                  }
                  
                  

                  C'est tellement facile de passer outre que si quelqu'un utilisant ton code veut changer le nom, il écrira sans trop ce poser de questions : jean._nom = 'Garcia';.

                  Aucune erreur, le code semble marcher, on passe à autre chose.
                  Sauf qu'ici, à titre d'exemple, le nom est mis en majuscule, ce qui n'est pas le cas en écrivant l'attribut directement. L'application est devenue incohérente (on pourrait imaginer des bugs plus sournois, que l'on détectera plus tard et qui nous feront perdre beaucoup de temps).
                  Si la visibilité de l'attribut _nom était vraiment restreinte, le développeur aurait eu une erreur et aurait analysé le pourquoi du comment, ce qui aurait au moins le mérite de le forcer à remettre en cause son approche.

                  • [^] # Re: Lua

                    Posté par (page perso) . Évalué à  5 .

                    Le but n'est pas d'empêcher le développeur de faire une connerie, mais juste de l'empêcher de se plaindre. En C aussi tu peux aler taper dans des membres privés si tu veux vraiment. En python c'est aussi au bon vouloir. Mais le gars qui tape dans des membres privés et se plaint que l'implémentation a changé et que ça lui pète son code, il se fait rire au nez, à juste raison.

                    • [^] # Re: Lua

                      Posté par (page perso) . Évalué à  6 .

                      Sauf qu'en javascript, c'est "sans filet", il ne suffit pas soi-même de faire attention à la documentation du code pour savoir que tel champ est privé (Extjs fonctionne uniquement avec la documentation, les propriétés privées ne sont pas nommées différemment des propriétés publiques et la doc est un outil primordial pour ce genre de d'information), si tu modifies ou copies le code d'un collègue qui a utilisé un champ privé d'un objet, rien ne te l'indique sauf à aller regarder la doc systématiquement pour chaque variable….
                      Bref, il ne faut pas se le cacher, l'absence de portée est un gros point faible du langage et les artifices pour les simuler sont un pansement sur une jambe de bois.

                      Chippeur, arrête de chipper !

                    • [^] # Re: Lua

                      Posté par . Évalué à  0 . Dernière modification : le 07/02/13 à 17:41

                      Totalement d'accord avec toi. Je souhaitais juste montrer que cette convention est juste un hack, dans le but de combler un manque de ce langage, je n'irais pas lui rire au nez, car cette notion de membre privé n'est pas réellement présente.

                      En C aussi tu peux aler taper dans des membres privés si tu veux vraiment.

                      Je suis curieux de savoir comment on fait un membre privé en C :)
                      Tu parles de faire un typedef sur une structure pour indiquer que l'on doit uniquement la manipuler avec des fonctions ?

                      • [^] # Re: Lua

                        Posté par (page perso) . Évalué à  4 .

                        Je suis curieux de savoir comment on fait un membre privé en C :)

                        Ce qui ressemblerait le plus à la notion de privé en C serait pour moi les déclarations static

                        Chippeur, arrête de chipper !

              • [^] # Re: Lua

                Posté par . Évalué à  2 .

                Oui mais ça c'est le problème du rigolo pas le mien.

                Si son code plante et qu'il me fait un rapport de bug avec une stack trace, je verrai rapidement qu'il utilise directement une API privée et que du coup mon support il peut se le carer ou je pense.

                Je développe principalement dans des langages dynamique sans notion de private (Python, Javascript) ou bien où elle est très facilement contournable (Ruby), et crois moi ton "9 fois sur 10" c'est absolument pas ce que je constate.

                Et tu vas faire quoi contre ton collègue qui n'en a rien à foutre et qui va aller directement passer la méthode en public dans le source ? Tu reste derrière lui à regarder au dessus de son épaule toute la journée pour l'en empêcher ?

                Ça me rappelle une citation:
                "We are all consenting adults here" - Guido

                • [^] # Re: Lua

                  Posté par . Évalué à  0 . Dernière modification : le 07/02/13 à 16:48

                  Si son code plante et qu'il me fait un rapport de bug avec une stack trace, je verrai rapidement qu'il utilise directement une API privée et que du coup mon support il peut se le carer ou je pense.

                  Et si le code ne plante pas, mais rend l'application incohérente ?
                  Si le langage était plus strict, il y aurait pas eu de rapport de bugs et le développeur aurait de suite compris qu'il utilisait une API privé.

                  Et tu vas faire quoi contre ton collègue qui n'en a rien à foutre et qui va aller directement passer la méthode en public dans le source ?

                  Rien, c'est judicieux vu que la méthode semble répondre à ses besoins. Si elle plante alors le développeur se remettra d'abord en cause vu que c'est lui qui a changé quelque chose, comme un adulte consentant.

                  • [^] # Re: Lua

                    Posté par . Évalué à  1 .

                    C'est moi ou tu pense vraiment que tous les autres développeurs sont des débiles profonds ?

                    Je n'ai jamais rencontré qui que ce soit qui utilisait une API privée sans s'en rendre compte.

                    • [^] # Re: Lua

                      Posté par . Évalué à  2 . Dernière modification : le 07/02/13 à 17:50

                      Moi si, à commencer par moi même lorsque je débutais, et encore aujourd'huis en Javascript, il m'est arrivé d'écrire un peu trop rapidement et paf, la méthode était en fait 'privée'. Je dois être bien con ! Mais j'assume :)

                      • [^] # Re: Lua

                        Posté par (page perso) . Évalué à  2 .

                        Avec une convention du langage qui indique que _xxx est réservé à un usage interne, tu ne peux pas l'utiliser "par erreur" (ou alors c'est que tu ne connais pas la convention, mais là c'est un problème de formation).

                        • [^] # Re: Lua

                          Posté par (page perso) . Évalué à  1 .

                          Et pourtant j'ai une équipe de devs de très mauvaise foi qui te soutiendrait le contraire :D

                          « si ça marche, c'est que j'ai le droit de le faire »

                          alf.life

                • [^] # Re: Lua

                  Posté par . Évalué à  3 .

                  Si son code plante et qu'il me fait un rapport de bug avec une stack trace, je verrai rapidement qu'il utilise directement une API privée et que du coup mon support il peut se le carer ou je pense.

                  Euh, ça dépend! Pour l'avoir vécu avec un client payant, ce qui s'est passée c'est que l'API privée est devenue publique..

                  Bon, le coté pénible c'est de trouver la source du problème: très perturbant quand tu as un rapport de bug mais que la partie publique n'a pas changée, après la solution c'est un problème commercial..

            • [^] # Re: Lua

              Posté par (page perso) . Évalué à  0 .

              Il n'est pas nécessaire que le language fournisse un mécanisme de public/private pour faire de l'encapsulation.

              Il n'est pas nécessaire qu'un langage fournisse un quelconque mécanisme pour faire de l'objet : tu fais sans soucis de la POO en C ou en assembleur.
              Quand on dit qu'un langage est objet, il me semble qu'on sous entend qu'il intègre les mécanismes de base de la POO. S'il ne les intègre pas, c'est qu'il n'est pas objet (ce qui n'en fait pas un langage de merde pour autant).

              • [^] # Re: Lua

                Posté par (page perso) . Évalué à  6 .

                tu fais sans soucis de la POO en C ou en assembleur.

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: Lua

                  Posté par . Évalué à  -3 .

                  tu fais sans soucis de la POO en C ou tu fais de la POO en assembleur.

  • # Choix discutable

    Posté par (page perso) . Évalué à  0 .

    Un langage qui ne propose même pas de tableau associatif peut-il être considéré comme un bon langage ?
    Je rappelle que pour faire un tableau associatif en Javascript, on fait un Objet. Et si on veut savoir combien il y a d'éléments dans ce tableau on doit les compter nous même. Voir http://www.xul.fr/ecmascript/associatif.php

    Bon, il y a bien les Maps qui arrivent avec EcmaScript 6 mais il en aura fallu du temps ! Cf https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Map et http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets&s=map

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Choix discutable

      Posté par . Évalué à  3 .

      Entièrement d'accord.
      Tout le monde sait que le langage C et le langage ASM ne sont pas de vrais langages, l'un n'ayant pas de tableau associatif dans sa lib standard, l'autre n'ayant même pas de lib standard!
      Quelle honte!

      Bon, d'un autre côté, mieux vaut lire ça que d'être aveugle… C'est pas comme si je suis fan de l'asm ou du C (je ne dirais pas tout le mal bien que je pense de JS non plus), mais les tableaux associatifs ne sont pas aussi vitaux que tu ne sembles le croire, de très, très nombreuses applications s'en passent avec bonheur.
      D'ailleurs, tant qu'a troller, un tableau normal, n'est-ce pas un tableau associatif, puisque l'on associe un index avec une donnée?

      • [^] # Re: Choix discutable

        Posté par (page perso) . Évalué à  3 . Dernière modification : le 07/02/13 à 13:08

        Tu mélanges "bon" et "vrai", et en plus avec des langages utilisé dans des contextes différents

        • [^] # Re: Choix discutable

          Posté par . Évalué à  3 .

          Le coup des contextes différents, c'est bien ce que je voulais utiliser, même si j'ai peut-être mal formulé.

          Les tableaux associatifs sont utiles, et sont la marque des bons langages dans un certain contexte. Pas dans tous.
          Le C est un bon langage dans l'embarqué, je crois? Alors que perl ne le sera pas forcément. Pourtant, C n'a pas les tableaux associatifs, alors que perl, si.

          Dire d'un langage qu'il est bon ou pas parce qu'il n'a pas telle ou telle fonctionnalité (qui, en l'occurrence, est une fonctionnalité implémentable, en plus) me semble franchement à côté de la plaque.

          En espérant que mon message soie plus clair.

      • [^] # Re: Choix discutable

        Posté par . Évalué à  5 .

        Oui, enfin là on parle d'un langage de "haut niveau"..
        Enfin soi-disant de haut niveau..

  • # Coquille

    Posté par . Évalué à  1 .

    "Hors GObject Introspection est utilisé pour tout les langages." -> "Or GObject Introspection est utilisé pour tout les langages."

    • [^] # Re: Coquille

      Posté par . Évalué à  1 .

      J'enlève une autre coquille de la même phrase qui devient :
      "Or GObject Introspection est utilisé pour tous les langages."

  • # troll

    Posté par (page perso) . Évalué à  4 .

    Beaucoup de développeurs ont une mauvaise opinion de javascript, souvent justifiée

    Y'a moyen d'avoir une explication sur cette phrase ? Car de mon point de vue c'est juste du troll. Ce que j'en vois c'est que "beaucoup de développeurs" n'ont aucune idée de ce qu'est javascript, la seule chose qu'ils en connaissent c'est un plugin jquery pour faire bouger un nyan cat derrière le curseur.

    • [^] # Re: troll

      Posté par (page perso) . Évalué à  2 .

      Héhé, moi aussi ça m'a fait tiquer cette petite attaque gratuite dans une dépêche dont le ton semblait jusque là plutôt neutre et factuel.

      Chippeur, arrête de chipper !

    • [^] # Re: troll

      Posté par . Évalué à  2 .

      Surtout que la plupart des manques soulevés dans les commentaires semblent comblés dans ECMAScript 6 :

      • let pour des variables avec une portée de bloc
      • Map pour remplacer l'usage d'un Object en tant que hash table
      • class, module, extends, etc pour la modularité du code et du sucre syntaxique pour le côté objet

      Et d'autres encore (Certaines présentées ici).

      Après on peut toujours craindre le temps pour que tout cela soit disponible dans une grande majorité des navigateurs, mais en ce qui concerne le sujet de cette dépêche, à savoir Gnome, il est tout à fait envisageable que cela soit intégré au plus vite. Il me semble même avoir déjà vu des let dans le code d'extensions du Shell.

      • [^] # Re: troll

        Posté par (page perso) . Évalué à  6 .

        T'as dû rater un paragraphe lors de ta lecture:

        ECMAScript 6 − nom de code Harmony − devrait résoudre nombres de réticences. L'ajout de class, extends, super, des valeurs par défaut des arguments, des modules, les chaînes sur plusieurs lignes, etc. Les développeurs python devraient retrouver un peu de calme avec tout cela. Mais quand ? On avance l'horizon 2014… en attendant il y aura des mécontents !

        • [^] # Re: troll

          Posté par . Évalué à  1 . Dernière modification : le 07/02/13 à 13:47

          Moi non, ceux qui continuent à soulever les problèmes sus-cités oui (avec un peu moins de mauvaise foi, j'avoue avoir zappé que l'article lui-même en parlait).

          Edit: Tu parlais de l'échéance en fait ? Alors je me suis mal exprimé, mais je voulais bien entendu dire au plus vite intégré dans Gnome après la sortie de la nouvelle version ECMAScript

    • [^] # Re: troll

      Posté par (page perso) . Évalué à  7 .

      Sans atteindre le niveau de PHP, javascript a des petites incongruités :

      https://www.youtube.com/watch?v=kXEgk1Hdze0

      :-)

  • # FirefoxOS

    Posté par (page perso) . Évalué à  7 .

    Moi je pense que GNOME devrait se rapprocher de FirefoxOS, vu que l'Avenir d'Internet, des bureaux, des smartphones passent pas les technos WEB.

    Bon sinon j'ai un uptime de plusieurs semaines avec HaikuOS sur un vieux laptop, ca tourne au poil, empreinte mémoire de l'OS autour de 300Mo, tout est fluide, ya pas de merdes en scripts. Bref, mon avenir perso je sais ou il va :)

    • [^] # Re: FirefoxOS

      Posté par . Évalué à  2 .

      Hum… pas de merde en script, ça implique que tu n'as ni perl, ni python d'installé? Ca m'intéresse assez dans ce cas.

      Bon, naturellement, je pense que tu exagères, vu que je suis persuadé (mais pas convaincu, notes bien) que tu as init, et question script… bref, sans shell (que ce soit bash, zsh ou csh ou… peu importe), je ne sais pas si un système peut tourner à l'heure actuelle.

      • [^] # Re: FirefoxOS

        Posté par (page perso) . Évalué à  3 .

        Évidement j'exagère, mais la grande majorité des apps sont en C++ et à l'usage du desktop change tout.

        • [^] # Re: FirefoxOS

          Posté par . Évalué à  3 .

          Bien sûr parce que c'est le langage qui fait la performance. D'où par exemple la lenteur de shinken (python) face à nagios (C).

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: FirefoxOS

            Posté par . Évalué à  1 . Dernière modification : le 07/02/13 à 14:02

            Le langage influe certainement sur la performance, mais au vu de certains codes source C que j'ai pu voir dans le libre, et la réplique que je me suis mangé quand j'ai osé suggérer d'améliorer la qualité du code et en soumettant un patch (en gros: pas de refactoring si ça n'apporte pas de fonctionnalité. Ca peut se défendre, en soi…) je ne peux qu'admettre que le développeur compte sûrement pour plus de la moitié des problèmes de performances.

            Genre, si un code C fait 3 fois la même opération d'affilée à cause d'un code dégueu et illisible, même si cette opération est 2 fois plus rapide qu'en Java (exemples, exemples, rien d'autre!) si le code java ne fais qu'une fois l'opération, le code java sera plus rapide.
            Ca marche aussi avec 2 et 1 ;)

            Pour le desktop, ce qui pose le plus problème, à mon avis, c'est plutôt les inter-dépendances qui permettent aux logiciels de faire le café. Et le constat que je fais de ce point de vue la, c'est que le moindre programme python installé sur ma machine à bien plus de dépendances que les autres. Pour perl, c'est moins pire. Il faut dire qu'en général, ça reste des choses qui ne font qu'une seule chose, en perl.
            Pour JS, j'en sais rien.

          • [^] # Re: FirefoxOS

            Posté par (page perso) . Évalué à  1 .

            Je suppose que tu fais de l'ironie sauf que Nagios a beau être en C la plupart des plugins sont en scripts donc il se peut très bien que shinken soit plus rapide car meilleur architecture que Nagios et ses plugins en scripts. Zabbix est lui très rapide.
            C'est pas tant le langage qui fait la différence que le fait de passer par une VM/interpréteur ou pas.

            • [^] # Re: FirefoxOS

              Posté par . Évalué à  2 .

              Je suppose que tu fais de l'ironie sauf

              En effet.

              Nagios a beau être en C la plupart des plugins sont en scripts

              Tu parle des sondes ? Ce n'est pas leur éventuelles lenteurs qui ralentissent nagios (pour être plus précis qui l'empêcherais de monter en charge).

              C'est pas tant le langage qui fait la différence que le fait de passer par une VM/interpréteur ou pas.

              Juste au dessus tu viens de dire que c'est l'architecture qui fait la différence (et ça je suis d'accord). Interpréter, JIT ou compiler vers une VM le code est un peu plus rapide (il gagne de quelques facteurs) et les performances qu'on arrive à produire actuellement tendent à fortement limiter cette différence. Par contre si tu code plus ou moins bien c'est carrément la complexité de ton programme qui va en pâtir et là tu peut l'écrire en assembleur ou le bruler directement sur CPU ce sera toujours lent.

              Ce qui fait que ton bureau est léger c'est probablement qu'il est plus simple. C'est peut être parce qu'il est mieux conçu et/ou qu'il fait moins de choses et/ou qu'il y a plus de simplicité grâce à un couplage plus fort. Mettre ça sur le dos du ou des langages c'est pas si évident à mon avis.

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: FirefoxOS

                Posté par (page perso) . Évalué à  6 .

                C'est pas si évident mais un programmeur mauvais ou moyen il fera toujours un app plus lente en JS qu'en C++, or le but du JS par défaut dans GNOME c'est justement d'attirer le dev moyen …
                Si le but est de descendre le niveau d'accès des dev à la plateforme GNOME au détriment des perfs et donc au détriment des machines un peu plus ancienne, perso je ne me reconnais plus du tout dans cet écosystème.

                • [^] # Re: FirefoxOS

                  Posté par . Évalué à  7 .

                  C'est pas si évident mais un programmeur mauvais ou moyen il fera toujours un app plus lente en JS qu'en C++, or le but du JS par défaut dans GNOME c'est justement d'attirer le dev moyen …

                  On retrouve la bonne vielle idée des bons et des mauvais programmeurs (généralement c'est à partir de là que je trouve la discussion inutile). D'un coté il y a les bons programmeurs qui maitrisent principalement l'assembleur et utilisent le C quand il faut coder vite et de l'autre il y a les nullos qui ne comprennent pas grand chose (ils n'ont même pas commencé à coder sur des machines 8bits en assembleur c'est dire !). Les premiers maitrisent l'informatique comme leur poche et de l'autre tout ce qu'ils connaissent d'un peu technique n'est que buzzword ou des acronymes qui servent à cacher la lourdeur de leur technologie.

                  Personnellement ce n'est pas mon avis. Tu peut avoir des personnes qui savent architecturer une appli sans pour autant très bien maitriser l'allocation mémoire et toutes les subtilités de synchronisation interprocessus et vis versa.

                  Rien ne t'interdit à toi ou aux autres bons/vrais programmeurs de contribuer aux appli toutes pourries pour les rendre meilleures ou d'en écrire d'autres en reprenant les idées de ses autres appli (rien ne t'oblige à les installer).

                  Enfin personnellement, pour une petite appli qui va se loger dans le systray pour m'indiquer un truc ou un autre de temps en temps, je préfère que ce soit écris dans un langage plutôt concis et plus maintenable ou plus facilement hackable qu'en C avec des risques de fuites mémoire entre autre.

                  Si le but est de descendre le niveau d'accès des dev à la plateforme GNOME au détriment des perfs et donc au détriment des machines un peu plus ancienne, perso je ne me reconnais plus du tout dans cet écosystème.

                  Comme je viens de le dire (et tu semble le concéder) c'est pas le langage le plus primordial dans la performance d'une application. Par contre oui ça rend le développement plus simple et ça c'est bien.

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: FirefoxOS

                    Posté par (page perso) . Évalué à  6 .

                    Enfin personnellement, pour une petite appli qui va se loger dans le systray pour m'indiquer un truc ou un autre de temps en temps, je préfère que ce soit écris dans un langage plutôt concis et plus maintenable ou plus facilement hackable qu'en C avec des risques de fuites mémoire entre autre.

                    Là je ne suis pas trop d'accord, j'ai encore le souvenir d'applets perl de notification réseau ou des mises à jour me bouffant 50Mo de RAM juste parce que c'était les seuls trucs en perl lancés. Pour un truc résident, je préfère un truc en C qui consomme peu de mémoire, et qu'on corrige les fuites.

                    • [^] # Re: FirefoxOS

                      Posté par (page perso) . Évalué à  2 .

                      Idem, une palanquée de soft en python marchouille sans vraiment planter. Au moins en C/C++ si ça merde ça plante ou ça leak mais dans les 2 cas c'est rapidement visible et corrigé.
                      Exemple les clients twitter en python qui rament tous, le seul qui me parait utilisable est Choqok qui bizarrement est en C++…

                      • [^] # Re: FirefoxOS

                        Posté par . Évalué à  2 .

                        Au moins en C/C++ si ça merde ça plante ou ça leak mais dans les 2 cas c'est rapidement visible et corrigé.

                        La mauvaise gestion des chaines ça se vois rapidement ?

                        Je ne cherche pas à lancer un troll entre langage, hein ? Je dis juste que l'idée de tout faire dans un langage donné parce que c'est soit disant plus performant n'est pas une bonne idée (et mon exemple n'était être pas super bien choisi).

                        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                        • [^] # Re: FirefoxOS

                          Posté par (page perso) . Évalué à  2 .

                          Je reste convaincu que promouvoir un langage par défaut comme Vala aurait été un meilleur choix pour la plateforme. Et rien n'empêche d'utiliser Python ou JS pour ceux qui le veulent.

                          • [^] # Re: FirefoxOS

                            Posté par (page perso) . Évalué à  3 .

                            Le gros soucis de Vala: c'est un langage nouveau, et spécifique à GObject. Du coup les gens qui veulent coder sur ta plateforme doivent apprendre un nouveau langage. Cela élève encore un peu plus la barrière à la contribution, et restreint encore un peu plus le nombre de gens intéressés.

                            • [^] # Re: FirefoxOS

                              Posté par (page perso) . Évalué à  6 .

                              Ouais bof. Vala ressemble pas mal à C# qui n'est pas tellement éloigné de Java et de C.

                              J'ai essayé un petit peu de programmer en Vala et ça ne m'a posé aucune difficulté, ce n'est pas un langage dépaysant du tout, on y retrouve vite ses marques. Le principale problème étant le manque de doc et des bugs du compilateur, mais en mettant plus d'effort dessus (au lieu de le disperser encore avec le JavaScript), ça aurait été très bien.

                              Bref, je ne suis pas sûr que le type qui pense que la marche est trop haute pour se mettre à Vala, trouvera la marche moins haute pour se mettre à l'API JavaScript de GNOME qu'il ne connait pas non plus.

                              • [^] # Re: FirefoxOS

                                Posté par (page perso) . Évalué à  2 .

                                Je suis assez d'accord, mais je me dis que le fait que ce soit interprété est peut-être considéré comme plus accessible et que ça joue aussi ? (En tout cas pour apprendre le langage/les libs, je trouve plus facile d'avoir un prompt où tu peux jouer en direct avec les exemples plutôt que d'avoir à recompiler à chaque fois)

                                En tout cas de terme de cohérence et de vision globale je trouve ça un peu bizarre de développer son propre langage d'un côté et de pas le promouvoir… Après ça se comprend parce que c'est du logiciel libre, qu'il y a différentes équipes et pas un grand chef, mais bon…

                                • [^] # Re: FirefoxOS

                                  Posté par (page perso) . Évalué à  5 .

                                  Je suis un peu déçu qu'ils n'aient pas plutôt décidé de mettre la paquet sur Vala, que j'ai trouvé agréable à utiliser. J'avoue que ça me donnait envie de développer pour GNOME (je suis plutôt KDE, et je n'ai pas envie de faire de C++). Tant pis :-)

                        • [^] # Re: FirefoxOS

                          Posté par . Évalué à  2 .

                          La mauvaise gestion des chaines ça se vois rapidement ?

                          Non. A moins d'avoir une tonne de test unitaire qui teste bien tout sous Valgrind (et la non c pas rapide du coup)…sinon ca plante aleatoirement n'importe ou et bonjour la galere pour trouver le vrai bug…Le C faut eviter tant qu'il y a pas besoin de performance, ou etre maso.

                          • [^] # Re: FirefoxOS

                            Posté par . Évalué à  0 .

                            Pour le C, disons qu'il faut toujours traiter le retour de fonctions comme scanf. Evidemment, comme il n'y pas de support des exceptions, soit le dev à confiance en lui et en l'utilisateur, soit il écrit un code assez lourd.

                            Ah, on peut aussi encapsuler, mais bon… faut aimer.

                            Pour le C++, en revanche, oui, ça se détecte facilement, à condition d'éviter d'utiliser l'héritage du C (et je suis un mauvais élève, j'aime toujours autant scanf/printf perso :s )

                            • [^] # Re: FirefoxOS

                              Posté par . Évalué à  0 .

                              Y pas que ça, les chaines de caractères dynamique de base tu as pas. Donc faut bien prévoir a l'avance que la taille allouée va être suffisante pour ce que tu veux faire. C'est un vrai casse tête.

                              Le JavaScript d'un autre cote, ca plante pas mais quand ca fait n'importe quoi bonjour pour debugger…Je hais les langages qui ne 'compilent pas' pour ca…le simple fait de compiler an -Wall -Wextra detecte beaucoup de typos, En JavaScript tintin…

                              • [^] # Re: FirefoxOS

                                Posté par . Évalué à  -1 .

                                Exact, il faut admettre que ce fichu 0 de fin de chaîne, couplé au fait que les tableaux commencent à l'index 0 n'est pas fait pour aider :D

                              • [^] # Re: FirefoxOS

                                Posté par . Évalué à  2 .

                                Le JavaScript d'un autre cote, ca plante pas mais quand ca fait n'importe quoi bonjour pour debugger…Je hais les langages qui ne 'compilent pas' pour ca…le simple fait de compiler an -Wall -Wextra detecte beaucoup de typos, En JavaScript tintin…

                                Puis un jour tu va découvrir les analyseurs statiques (comme lint) et tu va comprendre qu'un compilateur ça sert à compiler.

                                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                • [^] # Re: FirefoxOS

                                  Posté par . Évalué à  0 .

                                  Je suis intéressé par un nom, si tu en connais pour le C++ dont la licence soit à un prix abordable et qui tourne sous linux ET windows.
                                  J'ai déjà cherché, j'ai pas trouvé. Et tant que j'aurai pas trouvé, mon compilo C++ me servira aussi de vérificateur statique (oui, je sais, il faut aussi que je me mette au TDD).

                                  • [^] # Re: FirefoxOS

                                    Posté par . Évalué à  2 .

                                    Je ne les ai pas essayé, mais tu a regardé ceux-là ? http://doc.ubuntu-fr.org/analyseur_de_code_static#cc

                                    Sinon d'assez réputé, il y a PC-Lint et PVS-Studio mais il semble qu'ils ne fonctionnent que sous Windows…

                                    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                    • [^] # Re: FirefoxOS

                                      Posté par . Évalué à  2 .

                                      PC-Lint

                                      Il y a une version qui tourne aussi sous Unix (Flexelint), par contre je pense qu'on sort de l'abordable (freem pourra nous dire plus exactement ce qu'il entend par abordable, mais je pense qu'au dessus de $100 ca le fait plus).

                                    • [^] # Re: FirefoxOS

                                      Posté par . Évalué à  1 .

                                      Je ne les ai pas essayé, mais tu a regardé ceux-là ? http://doc.ubuntu-fr.org/analyseur_de_code_static#cc

                                      Merci pour le lien, il y en a 4 qui semblent intéressants.
                                      Après, ce lien montre tout le problème des wiki: on mélange les choux et les carottes sous l'appellation patate… analyseurs statiques: valgrind (huh?), CCCC (outil de métrique)… bref…

                                      Au niveau de ceux que j'ai essayés:

                                      • cppcheck : juste… inutile. Sort les même warnings que le compilateur, et refuse de fonctionner si on utilise des headers un peu complexe. Au revoir, STL…
                                      • flawfinder : se contente de vérifier quelles fonctions dangereuses ont été utilisées. Le seul avertissement que cet outil m'aie donné est que getenv(char const*) est dangereux car les variables système ne sont pas fiables. C'est une entrée utilisateur en même temps… bref, intéressant quant on cherche à prendre la main sur un code en langage C qui ne nous appartiens pas. Langage C, car ces fonctions dangereuses sont principalement C-style: manipulent des "char*".
                                      • CCCC : très bon outil pour identifier les endroits ou le code est complexe, et donc excellent outil pour savoir quelle zone refactorer.
                                      • valgrind : pas passé assez de temps avec pour comprendre comment il marche. C'est dans mes projets,

                                      Après, certains semblent intéressants:

                                      • saturn
                                      • calysto (qui semble avoir été écrit pour compenser des défauts de saturn)
                                      • Mozilla's Pork
                                      • Mozilla's Dehydra

                                      (freem pourra nous dire plus exactement ce qu'il entend par abordable, mais je pense qu'au dessus de $100 ca le fait plus).

                                      Effectivement, au delà de 100€ ça fait beaucoup, pour mes finances actuelles :)
                                      Je cherche un tel outil pour un but personnel pour le moment, et je ne suis pas spécialement riche. D'un autre côté, ce genre d'outils est plutôt dédié aux usages professionnels, à ce que j'ai pu voir, et les tarifs sont donc plutôt adéquats. Donc je me doute bien que je ne risque pas d'en trouver en fait, mais je me disais que, peut-être…

                                • [^] # Re: FirefoxOS

                                  Posté par . Évalué à  1 .

                                  Merci je connais aussi, y en aussi sur les langages qui se compile. Reste que ca prends un temps fou compare a une simple compil. Bref pas le truc que tu lances souvent.

                                  • [^] # Re: FirefoxOS

                                    Posté par . Évalué à  2 . Dernière modification : le 11/02/13 à 18:08

                                    Merci je connais aussi, y en aussi sur les langages qui se compile.

                                    Je n'ai pas dis le contraire, c'est toi qui expliquait que tu veux de l'analyse statique et que pour ça il te faut un compilateur.

                                    Reste que ca prends un temps fou compare a une simple compil. Bref pas le truc que tu lances souvent.

                                    C'est pas plus long que de faire des tests unitaires et de les lancer. C'est pas non plus plus long que de devoir corriger après que l'utilisateur ai découvert le bug. Ça permet de corriger des bugs en vrai (là où gcc te dit uniquement le minimum pour que ça compile (clang et icc sont meilleurs)). Si tu as besoin de moins de vérifications (puisque c'est ce que tu fais actuellement), il suffit de configurer ton outil pour tu verra que le temps d'analyse diminue. L'avantage c'est que tu peut avoir une analyse légère au cour de la journée et le soir tu lance l'analyse complète si ça prend tant de temps que ça.

                                    Bien sûr si tu veux dire que comme ce n'est pas techniquement obligatoire, tu (toi ou d'autres) manque de rigueur pour le lancer c'est autre chose, mais ça peut se lancer via un builder avant la compil'.

                                    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                    • [^] # Re: FirefoxOS

                                      Posté par . Évalué à  1 .

                                      Disons que j'ai un temps de compil avec -Wall -Wextra (et deux trois supress) de 30 seconds (avec gcc un peu moins avec llvm).

                                      L'analyse static sous Clang me prends largement plus de 5 minutes par contre. Et n'a pas detecte grand chose de plus (dont 90% de faux positif d'ailleurs). Bref une analyse static oui c'est bien, mais ca prends du temps, et il faut faire le tri. Bref depuis que j'ai corrige les bugs detectes en plus (2 3 sur 100k ligne de code en C) je m'en passe avec joie. (je ne le lance plus que par aquis de conscience avant 'mise en prod')

                                      Donc utiliser un langage de dev qui n'a que ca comme garde fou, c'est lourd.

                                      Et puis les test unitaires de toute facon il faut les faire, langage compile ou pas, analyse statique ou pas.

                                      • [^] # Re: FirefoxOS

                                        Posté par . Évalué à  1 .

                                        Hum, analyse statique sur clang? Tu peux m'en dire plus, ça m'intéresse ça.

                                        Pour le reste, en fait, l'avantage du compilateur, c'est que ça s'exécute pas si la syntaxe n'est pas correcte partout.
                                        Couplé à un typage fort (ce qui n'est pas le cas du C, d'ailleurs, vu qu'on peut caster ce qu'on veut en ce qu'on veut), ça permet d'éviter de très nombreux problèmes, c'est un fait.

                                        /me pense aller voir du côté de ADA un de ces 4

                                        • [^] # Re: FirefoxOS

                                          Posté par . Évalué à  2 . Dernière modification : le 12/02/13 à 12:30

                                          http://clang-analyzer.llvm.org/

                                          Tres facile a mettre en œuvre.

                                          Suivant le type de code il peut y avoir pas mal de faux positifs.
                                          Mais impossible a éviter (le code est pas censé savoir que tes données vont de base empêcher certains cas de se produire).
                                          Ou alors au prix de plus de code inutile.

                                          • [^] # Re: FirefoxOS

                                            Posté par . Évalué à  1 .

                                            Merci bien.

                                            Depuis le temps que je cherche un outil capable de me montrer les trucs pas catholiques que je fais parfois… tant pis pour les faux positifs, s'il y en a des vrais, ça donne toujours des indices, c'est l'important.

                                      • [^] # Re: FirefoxOS

                                        Posté par . Évalué à  2 .

                                        Donc utiliser un langage de dev qui n'a que ca comme garde fou, c'est lourd.

                                        T'es entrain de dire que le C a des gardes fou ? Pour de vrai ?

                                        Si l'idée c'est juste de vérifier la syntaxe, tu peut t'appuyer sur ton éditeur de texte ça suffit (ou presque).

                                         ~ % cat /tmp/tmp.836L5oU6UF.c
                                        #include "stdio.h"
                                        
                                        int main() {
                                           int array[] = { 1, 2, 3 };
                                           printf("foo = %d\n", array[5]);
                                           return 0;
                                        }
                                         ~ % gcc -Wall -Wextra -o /tmp/out /tmp/tmp.836L5oU6UF.c # ça marche pareil avec clang
                                         ~ % /tmp/out
                                        foo = 0
                                        
                                        

                                        Garde fou tu dis ?

                                        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                        • [^] # Re: FirefoxOS

                                          Posté par . Évalué à  1 .

                                          Le typage est un garde-fou, mais ça ne signifie pas qu'il soit suffisant ;) (surtout qu'en C, un p'tit cast, et le chien se transforme en chaise. Remarque, ça tiens chaud et c'est soyeux…)

                                        • [^] # Re: FirefoxOS

                                          Posté par . Évalué à  2 . Dernière modification : le 12/02/13 à 21:06

                                          1 warning generated.
                                          misc.c:348:25: warning: array index of '5' indexes past the end of an array (that contains 3 elements) [-Warray-bounds]
                                          printf("foo = %d\n", array[5]);
                                          ^ ~
                                          misc.c:347:4: note: array 'array' declared here
                                          int array[] = { 1, 2, 3 };
                                          ^

                                          clang -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers

                                          Non Clang ne fonctionne PAS pareil…

                                          • [^] # Re: FirefoxOS

                                            Posté par . Évalué à  2 .

                                            A quand le -Wfull ? (déjà que -Wall et -Wextra c'est pas top)

                                            Et donc tu utilise ça ou c'est ça qui te prend 5minutes et qui t’insupporte ?

                                            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                            • [^] # Re: FirefoxOS

                                              Posté par . Évalué à  1 .

                                              Les warning que tu vois ce sont des warning de compil et ca prends 30 secondes et me donne ca. L'analyse static m'aurait retourne la meme chose dans ce cas. Donc oui de maniere generale je n'utilise que les warning de compil en phase de dev, ca suffit pour eliminer un nombre deja bien consequant d'erreurs ou typos. (oui certaines typos habituelles sont prises en compte par certains flags de compil)
                                              Parce qu'en C par exemple x = 0,5; forcement c'est pas pareil que x = 0.5; et que ca bah je suis bien content que Clang le detecte a la compil si tu veux.

                                              L'analyse static c'est --analyse, ca prends bien 5 minutes par contre. (et ne me donne maintenant plus rien a par des faux positifs). Donc je le lance vraiment que quand j'ai que ca a foutre.

                                              Je maintiens qu'un langage qui a un compilateur permet de produire du code propre bien plus rapidement. Car un code qui compil sans aucun warning, c'est certes pas l'assurance que ca fait ce que tu veux, mais au moins que ca sera souvent plus facile a debugger. Et pour du C si ca passe Valgrind avec de bons tests unitaires, si ca crash ca sera vraiment trivial a corriger.

                                              • [^] # Re: FirefoxOS

                                                Posté par . Évalué à  2 .

                                                C'est vrai que clang est vraiment pas mal, mais on voit tout de même que c'est grâce à l'outil que tu a ce niveau de protection et pas grâce au langage. Il y a des langages qui protègent réellement et pour les quels un compilateurs te donne une foule d'info avant de te rendre un exécutable, mais C n'en fait pas parti. C'est parce que les développeurs ont eu beaucoup de problème que le C est aujourd'hui très bien outillé, mais bon clang en open source ça date de 2007 avant on avait juste gcc, qui fait bien moins d'analyse. D'ailleurs je viens de remarquer que mon clang ne fourni pas les info que tu dis. Je suis sous Debian stable et j'ai un clang 1.1, donc c'est encore plus récent (la version 1.0 de clang est sortie en 2009).

                                                Et pour du C si ca passe Valgrind avec de bons tests unitaires, si ca crash ca sera vraiment trivial a corriger.

                                                Je crois que tout code avec de bons tests unitaires est trivial à corriger.

                                                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                              • [^] # Re: FirefoxOS

                                                Posté par . Évalué à  2 . Dernière modification : le 13/02/13 à 09:59

                                                Je suis par contre surpris que personne n'ai parlé de golang (un langage qui a plu aux développeurs de langages dynamiques, tout en étant compilé et performant et avec une bibliothèque standard relativement petite).

                                                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: FirefoxOS

                    Posté par . Évalué à  2 .

                    On retrouve la bonne vielle idée des bons et des mauvais programmeurs

                    Sauf qu'il a dit qu'un mauvais ou moyen dev écrira une application plus performante en C++ qu'en JS, pas qu'un bon dev n'écrira pas une appli plus performante en JS que ce qu'il aurait pu faire en C++.

                    En gros, ce qu'il essaie de dire, c'est que le développeur qui n'est pas un guru créera une application plus rapide s'il code en C++ que s'il l'avait faite en JS.

                    Le problème, bien sûr, c'est qu'il ne la codera pas forcément aussi vite…

                    • [^] # Re: FirefoxOS

                      Posté par (page perso) . Évalué à  10 . Dernière modification : le 08/02/13 à 15:49

                      Le problème, bien sûr, c'est qu'il ne la codera pas forcément aussi vite…

                      Je ne suis pas convaincu. Ayant fait pendant des années du dev web, je te garanti que développer une application web complexe, demande des compétences dans de nombreuses technos comme JS, CSS, HTML, et coté serveur, un langage script comme PHP/Python/Ruby, + config serveur web et base de données.
                      Sans parler des lib comme HAML, coffeescript , sass, jquery, etc etc. parce que n'importe quel dev web sérieux n'utilise plus HTML, CSS, JS directement.
                      Au final développer une application native en Qt est beaucoup plus simple d'autant plus avec des outils comme QtCreator et QtDesigner.

                      Alors sans doute que le JS/GNOME n'est pas comparable à toute la stack nécessaire au dev web. L'avenir nous dira si c'est un bon choix. Je remarque cependant que l'API de OSX, est obligatoirement ObjectiveC, langage loin d'être accessible au commun des mortels, en tout cas pas ceux visé par l'API en JS, ce qui n'empêche pas OSX d'avoir un store énorme d'applications et d'autre part permet d'avoir un desktop fluide pas envahi de petites apps en scripts…

              • [^] # Re: FirefoxOS

                Posté par . Évalué à  0 .

                il y a plus de simplicité grâce à un couplage plus fort

                Moins fort, plutôt, non?
                Couplage plus fort, structure moins simple à faire évoluer sans tout péter… et devoir modifier en chaîne les dépendances.

                Je suis d'accord que l'archi est ce qui influe le plus, après… même si le langage non, je pense que le type de langage, compilé/VM/interprété, influe également.
                A noter aussi que certains langages ont une lib très riche. Le danger, pas forcément actuel de telles lib trop riches, c'est qu'elles risquent d'amener des dépendances inutiles.
                Cela dis, ce problème existe avec tout type de lib, pas que les lib standards.

                • [^] # Re: FirefoxOS

                  Posté par . Évalué à  3 .

                  il y a plus de simplicité grâce à un couplage plus fort

                  Moins fort, plutôt, non?
                  Couplage plus fort, structure moins simple à faire évoluer sans tout péter… et devoir modifier en chaîne les dépendances.

                  Non, non. On parle de performance et pour ça un couplage fort permet d'avoir d'améliorer les performances (plus de convention (donc moins de données échangées), chaque brique ne sait parler qu'avec une ensemble limité d'autres briques qui ne sont pas changeables).

                  Je suis d'accord que l'archi est ce qui influe le plus, après… même si le langage non, je pense que le type de langage, compilé/VM/interprété, influe également.

                  Pour du calcul pur, la différence est de très loin négligeable. Ça influence la vitesse de démarrage de ton appli, la vitesse des appels systèmes et tu es plus lents sur les protections que te donne ton langage (le typage, la protection de la mémoire etc).

                  A noter aussi que certains langages ont une lib très riche. Le danger, pas forcément actuel de telles lib trop riches, c'est qu'elles risquent d'amener des dépendances inutiles.

                  Ça tombe bien avec JS qui a une lib standard assez petite.

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: FirefoxOS

                    Posté par . Évalué à  0 .

                    Non, non. On parle de performance et pour ça un couplage fort permet d'avoir d'améliorer les performances (plus de convention (donc moins de données échangées), chaque brique ne sait parler qu'avec une ensemble limité d'autres briques qui ne sont pas changeables).

                    Merci, j'avais un doute sur le propos, d'où ma question. Je suis donc d'accord sur ce point.

                    Ça tombe bien avec JS qui a une lib standard assez petite.

                    Il semblerait. Mais de nos jours, pas mal de gens considèrent ça comme un défaut (pas moi, mais bon…).

                    A part ça, je parlais de façon générale.
                    Merci pour tes éclaircissements.

                • [^] # Re: FirefoxOS

                  Posté par . Évalué à  3 .

                  A noter aussi que certains langages ont une lib très riche. Le danger, pas forcément actuel de telles lib trop riches, c'est qu'elles risquent d'amener des dépendances inutiles.

                  Heu, vraiment n'importe quoi. Au contraire, plus la bibliothèque standard est fournie, moins on a besoin d'intégrer des bibliothèques tierce partie (et donc des dépendances supplémentaires).

                  • [^] # Re: FirefoxOS

                    Posté par . Évalué à  1 .

                    Alors laisses-moi reformuler, je me suis mal exprimé:

                    Si la lib standard est trop riche, la totalité de celle-ci sera toujours installée, alors que de parfois nombreuses parties ne seront pas utilisées.
                    J'imagine qu'il faut que j'étaye par un exemple, alors je vais prendre Java, qui, à ma connaissance, intègre un framework d'UI en standard (AWT).
                    Problème:
                    Depuis, ces outils ont évolué. Conséquence: d'autres frameworks sont apparus (SWING), et les logiciels les exploitent. Mais, du coup, le framework standard est toujours installé (standard, en même temps) mais plus utilisé.

                    C'est ce que j'appelle une dépendance, même si elle est cachée. La pauvreté de la lib standard de certains langages, tels que C++, permet d'éviter ce genre de problème: les gens utilisent leurs propres lib graphiques.

                    Bon, j'espère qu'on va pas trop m'accuser de troller, vu que j'oppose 2 langages, dont un que je ne maîtrise pas (Java). Donc si je me lourde sur le fait qu'une IHM soit standardisée dans Java qui soit obsolète, merci de corriger. (J'ai aussi tenté d'éviter les jugements de valeur :) )

                    Après, les deux approches ont leurs intérêts et leurs défauts, naturellement.

                    • [^] # Re: FirefoxOS

                      Posté par . Évalué à  3 .

                      J'imagine qu'il faut que j'étaye par un exemple, alors je vais prendre Java, qui, à ma connaissance, intègre un framework d'UI en standard (AWT).
                      Problème:
                      Depuis, ces outils ont évolué. Conséquence: d'autres frameworks sont apparus (SWING), et les logiciels les exploitent. Mais, du coup, le framework standard est toujours installé (standard, en même temps) mais plus utilisé.

                      Mauvais exemple : Swing repose en (grande) partie sur AWT

                      • [^] # Re: FirefoxOS

                        Posté par . Évalué à  1 .

                        Ah, oui, merci, souvenir erroné.
                        Etait-ce SWT alors ? (nom retrouvé via wikipedia. Il semble d'ailleurs qu'une réécriture pour l'usage de swing soit en cours -donc pas finie- ?)

                        Il me semble bien qu'on m'aie fait utiliser 2 toolkits dont l'un était standard et "vieillot" et l'autre non, mais permettait d'utiliser les layout… après, ça remonte à presque 2 ans, et je ne peux qu'admettre n'avoir pas réutilisé ces connaissances de façon personnelle, donc ça se perd et mes propos peuvent donc être complètement faux (c'est pour ça que je tente de ne pas faire de jugement de valeur, au passage, d'autant que ce n'est pas le sujet du tout).

  • # Merci Etienne

    Posté par . Évalué à  9 . Dernière modification : le 07/02/13 à 10:22

    Tout d'abord merci Etienne, tes dépêches sur Gnome sont toujours passionnantes !

    A titre personnel, je connais peu JS, même si j'essaie de m'y mettre, notamment en faisant quelques scripts shell avec NodeJs.

    Il y a quelques mois, il y avait eu une longue discussion sur le net, sur un blog anglophone, concernant le dev d'applications Gnome et mon commentaire avait été repris concernant l'environnement global de développement. (voir ici http://jewelfox.dreamwidth.org/33061.html)

    Aujourd'hui, je ne sais pas trop comment cela a évolué, je salue néanmoins cette décision de l'équipe Gnome, mais…

    • je trouve dommage que Gnome fasse du "faux" Js, tout du moins du Js que l'on est pas habitué à manipuler. Exemples :

    -- la librairie standard Js de Gnome n'a rien à voir avec la librairie standard que l'on trouve partout ailleurs. Truc tout con, et vraiment basique, l'objet "console" n'existe pas, il faut appeler la fonction globale "print". C'est tout bête, mais le développeur Js un peu "newbie" comme moi qui débarque avec la doc du MDN dans la tête, bne il est perdu.

    -- même remarque pour le "packaging", avec GJS la gestion des espaces de noms se fait avec "import" et l'organisation physique de fichiers dans des dossiers, mais pourquoi ne pas reprendre les principes de CommonJs, avec par exemple le mot clé "require", qui sont maintenant largement répandus et maîtrisés ?

    -- contrairement à @liberforce, je trouve justement dommage qu'il existe 50 manières de faire les choses (un peu moins en fait hein !). Rien que pour écrire une classe, ça change. Soit on fait du "vrai" Js :

    function MaClasse() {...}
    
    

    Soit on fait du "Gnome" :

    const MaClasse = new Lang.Class({...})
    
    

    Sauf que cette 2é méthode n'est pas documenté, qu'il faut lire le code de Gnome-shell pour comprendre qu'il y a des fonctions héritées comme "_init" pour le constructeur (d'après ce que j'ai compris du code), qu'il y a des champs plus ou moins implicites comme "Name" dont on ne sait pas vraiment à quoi ils servent, etc.

    • Il y a clairement un souci avec la doc qui est faite pour le C. Une approche certainement intéressante serait de reprendre les principes du MSDN avec des onglets par langage

    • Enfin, il y a un vrai souci d'environnement de développement, Anjuta est juste une souffrance pour du Js, et MonoDevelop ne le supporte pas, du moins la 3.0.3, ça marchait toujours pas, ou alors je suis une bille ce qui est toujours possible.

    Le monde Js évolue très vite, notamment grâce (ou à cause de) à l'explosion du JS côté serveur, de nouvelles API apparaissent. Ca n'engage bien sur que moi, mais je trouverais intelligent de la part de l'équipe Gnome de reprendre ces APIs à leur compte pour vraiment faciliter la vie des développeurs, après, tout ne sera bien sur pas possible, mais ce serait déjà un bon début.

    • [^] # Re: Merci Etienne

      Posté par . Évalué à  5 .

      Le monde Js évolue très vite, notamment grâce (ou à cause de) à l'explosion du JS côté serveur, de nouvelles API apparaissent. Ca n'engage bien sur que moi, mais je trouverais intelligent de la part de l'équipe Gnome de reprendre ces APIs à leur compte pour vraiment faciliter la vie des développeurs, après, tout ne sera bien sur pas possible, mais ce serait déjà un bon début.

      Ca c'est pas possible ou sinon cela va etre legerement en contradiction avec le pourquoi du non choix de python. Gnome veut son API a lui tout seul sans avoir rien a devoir aux autres…

      • [^] # Re: Merci Etienne

        Posté par . Évalué à  3 .

        Merci, c'est bien vu en effet, même si ça reste dommage et probablement en contradiction avec la volonté d'attirer des développeurs venant d'autres horizons.

    • [^] # Re: Merci Etienne

      Posté par (page perso) . Évalué à  2 .

      console, c'est l'objet « console firebug». A priori, GtkParasite pourrait fournir cet objet.

      Je trouve ça normal de ne pas mimer l'API des navigateurs pour construire des API riche. Surtout à un moment où les API web tendent vers une API client lourd : abstraction du HTML,etc. cf GWT, Vaadin, muntjac, etc.

      • [^] # Re: Merci Etienne

        Posté par (page perso) . Évalué à  3 .

        console devient quand même relativement courant voire standard, même dans les frameworks côté serveur, comme nodejs.

        Chippeur, arrête de chipper !

      • [^] # Re: Merci Etienne

        Posté par . Évalué à  3 .

        Construire une API Js "générique" (comprendre "pas forcément dédiée à un code dans un navigateur côté client"), c'est tout l'objet de CommonJs.

        Il se trouve que les principaux navigateurs ont adhéré à l'initiative CommonJs, et c'est pourquoi un code Js tourne à peu près correctement dans tous les navigateurs. Côté serveurs, c'est NodeJs qui tire tout le monde, lui aussi a adhéré à CommonJs. Bref, CommonJs c'est justement l'initiative d'unification pour avoir une API à tout faire en Js. Et Gnome aurait tout intérêt à se pencher sur la question, au moins pour les objets de base.

        Il restera bien entendu toujours des choses spécifiques à la plateforme, mais après tout dépend quel est vraiment le but d'avoir choisi Js (encore une fois, je soutiens ce choix).

        • Si c'est pour se simplifier la vie avec un langage dynamique, etc…aucun souci

        • Si c'est pour attirer des devs d'autres horizons (= venant du web), alors je ne crois pas du tout que leur dire

          tu vas faire du Js, mais pas vraiment du Js comme tu le connais, va falloir utiliser notre API, notre façon d'utiliser le langage, etc

        …soit le bonne façon de procéder. Ca va plus repousser les devs qu'autre chose. Ca me rappelle le J# de Microsoft, tout pareil.

  • # Une solution pour développer des applications Qt basées à 100% sur Javascript ?

    Posté par (page perso) . Évalué à  1 .

    Dans les précédents commentaires, j'ai cru comprendre que Qt permet lui aussi de faire des applications en Javascript.

    Cependant, d'après ce que j'ai lu, Qt Quick est utilisé pour « créer des interfaces utilisateur personnalisables et dynamiques avec des effets de transition fluides de manière déclarative » et non pas pour développer entièrement son application en Javascript.

    Je me trompe ? Est-ce qu'il existe d'autres projets pour faire des applications Qt basées à 100% sur Javascript ?

  • # javascript, ok.

    Posté par . Évalué à  1 .

    Mais pour coder dans quel environnement ?

    Genre QML ? Tu utilises javascript pour t'affranchir de certaines lourdeur, mais en contre partie tu te dois quand même d'apprendre la documentation, le framework de Qt ?

    Ou plutôt quelque chose dans le genre de FF OS ?

    Pour moi, il est clair, que si je dois apprendre gtk+, gocject ect pour faire une appli desktop en JS sous gnome, c'est juste no way.
    C'est le même sac de noeud, avec un emballage différent certes.

    bref, pour faire du desktop, je pense que les applications gtk gagnerait à utiliser un composant vue webkit pour gérer l'ui telle une pure page web, mais à améliorer le support type webservice par gnome pour opérer la liaison entre ui et système. Genre un serveur web démarré par défaut en local…
    Une UI portable partout, compatible partout, qui ne demande qu'à se voir adjoindre quelques specs de service système pour fournir une disponibilité parfaite quelque soit le sous système.

    • [^] # Re: javascript, ok.

      Posté par . Évalué à  4 .

      Le principe d'une application graphique c'est dessiner sur un écran … s'il faut avoir une gestion d'écran qui affiche une page web sur laquelle on dessine par la suite … c'est légèrement redondant non ?

      Surtout que HTML/CSS connait des limitations non négligeable au niveau de l'ui … Là où Gtk/Qt/Wx/etc … Se sont déjà penchés sur le problème et ont proposé des widgets, avec des layouts, un ensemble cohérent, que le développeur peut modifier sans tout avoir à recréer de zéro à chaque fois, et sans que les widgets « persos » ne soient dissonants dans l'interface.

      Ce n'est clairement pas le cas des applications de type « page web », dans lesquelles au contraire chaque site désire une identité visuelle propre, et donc crée à chaque fois, non pas une disposition différente, mais tous les « éléments de base » à nouveau, de manière à se démarquer.

      Regardes la différence entre coder une appli HTML/CSS, même avec un WYSIWYG, c'est pénible, et pas toujours portable (margin et padding pour ie), là où avec Glade tu fais un truc en deux minutes, que tu réutilises ensuite très simplement dans n'importe quel langage avec un binding gtk l'UI.

      • [^] # Re: javascript, ok.

        Posté par . Évalué à  2 . Dernière modification : le 08/02/13 à 12:32

        hello,

        c'est intéressant, en tout cas, moi, cela me fait réfléchir.

        C'est redondant, je ne sais pas bien. J'ai tendance à penser que ce trio est une abstraction du système de dessin sous jacent. Et qu'à ce titre ce n'est pas vraiment une redondance, ou en tout cas, pas plus redondant que d'avoir GTK et Qt pour faire des applications desktop.

        Le cas du bureau himself et de son rôle d'interface avec le sous système et les composants physiques de la machine, est une question à laquelle je n'ai pas d'idée car cela sort complètement de mon scope d’intérêts.

        Aujourd'hui ce que je veux c'est développer multi plate forme, simple et testable. Et il s'avère que j'ai trouvé le couplage html/js/css/webservices fort intéressant et fort simple à re déployer quelque soit le système cible.
        Bref, j'ai découvert le pattern mvvm, j'ai adoré.

        J'ai aussi d'autres considérations, comme, plus c'est bas niveau, plus il faut être qualifié, plus il faut payer. Plus les composants sont concentrés dans une seule entité, moins c'est simple à manipuler arriver à un certain degré de complexité.
        Et puis je tentes d'arriver à un véritable develop once run everywhere, qui finalement me parait plus que faisable dans cet environnement de développement et d’exécution.

        Il faut aussi prendre en considération un autre fait pas technique du tout pour le coup. Une technologie qui répond à ces besoins, devra nécessairement être portée par l'économie pour se voir injecter des fonds et donc développer des solutions et un haut niveau de qualité (Alors bon des fois sa foire, voir le cas d'IE… C'est la vie).
        Hors l'e-commerce, le développement des tablettes, des smartphones, des tv, des lunettes me font penser qu'à termes, c'est ce trio qui restera car de tous les points de vue c'est le plus populaire, grand public.

        GTK, je n'ai rien contre, mais voilà, à part quelques applications tels que GIMP, et malgré toute la bonne volonté des développeurs, aujourd'hui c'est une audience somme toute très relative.
        Alors ils peuvent si ils le souhaitent continuer en vent d'ouest, c'est un choix qui n'est guère critiquable et je leur souhaites même de réussir.

        Au sujet des layouts, widgets ect, comme tu le dis c'est bien développé dans ces environnements. Mais je pense cela concerne plus le bureau, que l'application.
        L'application consomme ces widgets, et le bureau doit fournir un moyen à l'application de consommer le widget.

        Ce qui effectivement est complètement différent des applications de type site internet avec charte graphique spécifique ect.
        On se contentera parfaitement d'une vue webkit après tout ;) Ainsi que d'un moyen de consommer les widgets.

        Ta dernière remarque me semble tendancieuse au plus haut point !
        Justifiée par l'expérience, mais ce n'est pas la faute des spécifications (enfin pas à ma connaissance) que l'implémentation foire.
        Tentons d'en rester aux spécifications, ce sont des rêves d'ingénieurs en cours d'implémentation qui ne demande qu'à être concrétisés.

        Au plaisir de te lire.

        • [^] # Re: javascript, ok.

          Posté par . Évalué à  4 .

          C'est redondant, je ne sais pas bien. J'ai tendance à penser que ce trio est une abstraction du système de dessin sous jacent. Et qu'à ce titre ce n'est pas vraiment une redondance, ou en tout cas, pas plus redondant que d'avoir GTK et Qt pour faire des applications desktop.

          Prenons le système le plus répandu: windows.
          Cas de l'application classique:
          Win32 <= Qt/GtK/Wx/MFC/WhatElse <= application
          Cas de l'application web:
          Win32 <= Qt/GtK/Wx/MFC/WhatElse <= HTML/CSS/JS <= application

          Je ne vois pas de redondance, juste une surcouche à l'utilité discutable.

          Bref, j'ai découvert le pattern mvvm, j'ai adoré.

          Ca, si je me plante pas, il s'agit d'un design pattern. Applicable aux applications classiques. (bien que j'aie du mal à comprendre la différence par rapport au mvc mais bon…)

          Au sujet des layouts, widgets ect, comme tu le dis c'est bien développé dans ces environnements. Mais je pense cela concerne plus le bureau, que l'application.
          L'application consomme ces widgets, et le bureau doit fournir un moyen à l'application de consommer le widget.

          Le problème ici, c'est si les environnements de bureau ont été créés, c'est pour que l'utilisateur ne soit pas perdu à chaque fois qu'il change d'application. Avec les sites web, c'est la jungle: chaque site réinvente la roue, marche plus ou moins bien en fonction du navigateur, nécessite que l'utilisateur apprenne à utiliser l'interface, et force l'utilisateur un peu soucieux de sa sécurité à ajouter une configuration précise pour chaque site différent.

          Tentons d'en rester aux spécifications, ce sont des rêves d'ingénieurs en cours d'implémentation qui ne demande qu'à être concrétisés.

          Le problème, c'est que la simplicité de créer une interface avec WYSIWIG n'est plus un rêve depuis longtemps, sauf avec HTML.
          HTML, c'est quand même plus primitif que Win32… Alors, c'est cool, ça veut dire qu'on peut tout réimplémenter à sa sauce… sauf qu'en fait, c'est pénible, parce qu'on à pas le choix.

        • [^] # Re: javascript, ok.

          Posté par . Évalué à  7 .

          Je me suis peut être un peu mal exprimé en utilisant redondant sans le définir. Ce que j'entendais c'est qu'une page web, c'est un tableau blanc sur lequel tu as des primitives de dessin (en gros). Et que pour X11, c'est un tableau blanc … sur lequel tu as des primitives de dessin. Certes, comme c'est plus bas niveau on a fait des surcouches qui permettent de faire les choses plus rapidement, de s'intéresser à la sémantique plus qu'au rendu au pixel etc … Comme une page web.

          Et je voudrais éclaircir mon passage sur « html / css » qui est, lui aussi, mal développé. Ce que je voulais dire c'est que la problématique l'une interface homme machine existe depuis relativement longtemps, et que ayant rencontré des problèmes, QT, GTK, Wx ont évolué pour répondre à des problématiques qui se posent encore avec les pages web actuelles …

          Par exemple, je veux faire une application avec deux colonnes … Et un pied de page en bas. Et bien en CSS, tu vas t'amuser, parce que la dernière fois que j'avais essayé, on ne pouvait pas forcer les deux blocs parallèles à avoir la même taille, sauf avec du JS … Ce qui rend moche dès que tu as un thème graphique un peu subtil (avec un fond par colonne). Et j'avais vu un tuto, expliquant qu'une grosse image de fond ferait l'affaire, pour faire croire que la colonne continuait ……..

          Pour toutes les applications qui demandent une interface un peu complexe, modulaire, un client « lourd » est préférable, à mon avis.

          • [^] # Re: javascript, ok.

            Posté par . Évalué à  1 . Dernière modification : le 18/02/13 à 13:49

            Au sujet de la redondance, je pense que pour faire simple, moi ça m'ennuie profondément de devoir passer le bac (at least) pour dessiner programmatiquement un carré à l'écran.

            HTML ce n'est pas seulement la sémantique, c'est aussi la simplicité et l'allocation aux erreurs. Ce que C ne sait, et ne saura jamais faire par nature (il est beaucoup trop proche du flux d'opérations pour en merder ne serait ce qu'une).

            Au sujet de mvvm, oui c'est un pattern, ce que je voulais dire c'est que ce pattern plus ces technos, je trouve que c'est mortel. Hors il à fais défaut extrêmement longtemps dans cet environnement, le DP.

            Par contre c'est tout à fait différent de mvc. Dans l'idée c'est très similaire, médiation de la vue et du modèle, mais l'implémentation et l'usage en sont tellement différents qu'ils ont leurs raisons d'être à chacun.

            Ah le coups des deux colonnes est tellement véridique. Mais on s'en affranchit tellement bien, avec un bon designer, un background ou une table.
            A l'inverse si il me vient à l'esprit de faire un deux colonnes qui fadeIn au chargement, je doute de ne jamais y arriver avec Qt ou dotnet.

            Finalement, et c'est déjà ce que je me disais l'autre jour après avoir posté, on mélange un peu le choux et les carottes dans notre échange ( c'est ma faute…).
            Car oui gnome kde lxde et tellement d'autres ont réfléchit à leurs affaires de bureaux virtuels tout intégrés.
            Mais tout ce savoir semble ne pas s'appliquer à ces nouveaux besoins qui pointent le bout de leurs nez chaque jour sur la toile :-/
            Et par ailleurs, je n'ai toujours pas envie de faire des années d'études pour faire un carnet de contact un peu sexy et multi plateforme.

            Et puis reste que rien n'empêche de conceptualiser le bureau comme une application à part entière…. en html. Au lieu de ces devs tellement compliqué que les variantes sont finalement bien peu nombreuse.

            Mais bon le plus important reste le passage sur les légumes ; )

            • [^] # Re: javascript, ok.

              Posté par . Évalué à  3 .

              Au sujet de mvvm, oui c'est un pattern, ce que je voulais dire c'est que ce pattern plus ces technos, je trouve que c'est mortel. Hors il à fais défaut extrêmement longtemps dans cet environnement, le DP.

              Tu entends quoi par « DP » ? Tu as des pointeurs sur le mvvm ? J'ai du mal à le différencier du mvc.

              Ah le coups des deux colonnes est tellement véridique. Mais on s'en affranchit tellement bien, avec un bon designer, un background ou une table.
              A l'inverse si il me vient à l'esprit de faire un deux colonnes qui fadeIn au chargement, je doute de ne jamais y arriver avec Qt ou dotnet.

              La différence à mon humble avis c'est que l'un est une question de présentation et d’expérience utilisateur (limiter la longueur des lignes etc) et l'autre est de la cosmétique. Mais ça n'est pas une fatalité :

              On devrait un jour pouvoir faire des colonne : http://www.css3.info/preview/multi-column-layout/
              Voir faire des machins encore plus sophistiqués : https://www.adobe.com/devnet/html5/articles/css3-regions.html
              Éventuellement même faire facilement des choses simples (mais que deviendras le boulot des designers ?!) : http://dev.w3.org/csswg/css3-grid-layout/

              Le web existe depuis 20 ans et on devrait dans pas trop trop longtemps commencer à pouvoir faire des choses de bases en CSS (mais faire clignoter du texte ça on sait faire depuis le début !), c'est tout de même assez frustrant.

              Et par ailleurs, je n'ai toujours pas envie de faire des années d'études pour faire un carnet de contact un peu sexy et multi plateforme.

              Sauf que, ce n'est plus vraiment le cas. Les toolkits graphiques sont passé à des interfaces déclaratives et ça rend les designes bien plus simple que tu semble croire. Il reste la partie programmatique mais pour ça tu utilise le binding que tu veux (paf QML + Js et c'est partie). L'avantage c'est que tu n'a pas les contraintes liée à HTTP (asynchronisme, le découpage client/serveur de l'application, etc).

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: javascript, ok.

                Posté par . Évalué à  1 .

                hello,

                je reprends par la fin :°)

                et je le coupe en 3

                Sauf que, ce n'est plus vraiment le cas. Les toolkits graphiques sont passé à des interfaces déclaratives et ça rend les designes bien plus simple que tu semble croire.

                Mon expérience de ces technos est très peu approfondie, un peu de .net, un peu de QT (c'était à l'arrivé de QML mais je n'en ai pas fais à ce moment là), un peu de glade, et après des trucs genre pango (pour les fonts si j'ai bon souvenir).
                Bref, oui il y à les tk, qui t'aides beaucoup, mais tu dois encore connecter les events.
                Par exemple en QT les signals, ont à priori, extrêmement simplifié le problème, sauf que je me suis battu avec à cause des spécificités de C / C++ eect. (les pointeurs tousssa, Oui j'ai un niveau de m*** en C).
                Et puis après il faut effectivement programmer les fonctionnalités. Rebolotte il faut se frotter à tout un tas de concepts qui pour moi sont un vrai problème.

                Il reste la partie programmatique mais pour ça tu utilise le binding que tu veux (paf QML + Js et c'est partie).

                Faudrait que je le testes pour de vrai. Mais je ne peux m’empêcher que cette solution est sous optimale par rapport à une refondation plus profonde comme a pu le faire des projets comme GO ou nodejs (langage que je manipules, mieux que le D, C, c# ect).

                L'avantage c'est que tu n'a pas les contraintes liée à HTTP (asynchronisme, le découpage client/serveur de l'application, etc).

                Moi je suis très content de ce découplage. Enfin, les technos actuelles purement à base de MVC sont à mon opinion pas bonne du tout.
                Mais avec le MVVM pour le client, le MVC pour le serveur tu peux arriver à rendre chacun de ces aspects indépendant, mais pas découplé. J'insiste la dessus, indépendant et non découplé.

                Après j'ai l'expérience d'une appli bureau réseau, grosse artillerie, .net Remoting.
                Bah je me suis bien amusé au début, après qu'est ce que j'ai ramé……. Je n'ai pas sentit le power to build, mais plutôt le power to debug.

                La différence à mon humble avis c'est que l'un est une question de présentation et d’expérience utilisateur (limiter la longueur des lignes etc) et l'autre est de la cosmétique.

                Oui probablement. Mais l'un dans l'autre, les toolkits avec tous les efforts qu'ils ont fait ne sont jamais parvenus à fournir un environnement de développement qui permette à l'industrie non informatique de personnaliser leurs applications bureaux.
                Là où le web ne travail qu'à cela depuis 20 ans.
                Je ne dis pas qu'ils ne sont pas capable sur le desktop, cela ne s'est pas produit.

                Et encore que s'attacher au problème de la beauté de l'ui n'est que le pendant du problème de la gestion multi plateforme.
                Dans les deux technos web et desktop le multi plateforme est possible.
                Dans les deux technos il y à des plus et des moins.
                Je considère que les moins du web sont plus attrayants, plus facile à affronter, que les moins du desktop.

                Même des technos comme GO ou nodejs qui sont pourtant toute fraîche et pensée pour aller à l'encontre de ces difficultés ne sont pas encore parvenus à une compatibilité sans défaut sur des concepts identiques.
                Pour diverses raisons, ce n'est pas tant la question ici.

                Tu entends quoi par « DP » ? Tu as des pointeurs sur le mvvm ? J'ai du mal à le différencier du mvc.

                Design pattern, pensais tu à autre chose ?

                Pour ce qui est de la différence entre mvvm et mvc, j'ai longtemps était dans le flou personnellement. Notamment parce qu'on présente mvvm comme une évolution de mvc cf http://en.wikipedia.org/wiki/MVVM
                Alors qu'à mon humble avis ils sont surtout complémentaires et c'est ainsi qu'il faudrait en parler.
                Je l'ai compris après avoir builder une application en utilisant knockout.
                Éventuellement une bonne vidéo de démo de MVVM à regarder est celle de meteor (recherhe google : meteor js screencast)

                bref, le model-view view-model n'intervient que pour synchroniser la vue par rapport au statut d'un modèle de vue (le modele et sa vue dans MVVM).
                Car c'est bien d'un modele de Vue dont on parle. Pas d'un modèle de donnée que l'on mets dans un sgbd.
                AMHA ce n'est pas un subset, ni une copie identique (penser REST), mais une ré interprétation (on formate, on tri, on prend deux services, on combine et paf un nouveau modèle de vue ect), et une spécialisation (le client de MVVM injecte son état dans son modèle).

                Ce client MVVM, discute avec un Controleur de MVC, qui encapsule en entrée / sortie son Modèle de sgbd.
                Sa Vue de MVC ne doit "que" formater la réponse en JS / XML / BIN / ce-qu'il-te-plait

                Le Contrôleur de MVC, aussi complexe que soit ces règles de gestion, est relativement binaire il répondra toujours succès ou échec. (Les autres trucs 302 404 de HTTP ect c'est pas vraiment son problème à MVC amha, enfin sauf si il décide de ré implémenter une partie de son serveur web lui même… c'est une histoire connue dont je ne parlerais pas)

                Le client MVVM peut dès lors consommer ces deux états afin de décider de l'affichage sur sa Vue.

                Là où sa devient vraiment beau, c'est à voir l'implémentation de meteor
                qui enregistre et applique immédiatement la modification sur son modèle de vue,
                envoie sa demande à son contrôleur de MVC côté serveur,
                plus tard lorsque le serveur répond, le client MVVM procède alors,
                soit à un commit local,
                soit un rollback, qui provoque alors une mise à jour de la vue.

                Le problème c'est que pour que cela fonctionne bien il faut un pont entre l'implémentation de MVC et MVVM afin de ne pas dupliquer certaines choses comme le routing par exemple.
                Il faut qu'il puisse partager des informations. Hors avec des bases en php, asp, java c'est compliqué à moins de passer par des sérialisations, mais alors sa réduit la liberté du développeur.

                des réflexions comme sa, à basher, corriger, discuter avec plaisir.

                a+

                • [^] # Re: javascript, ok.

                  Posté par . Évalué à  3 .

                  Bref, oui il y à les tk, qui t'aides beaucoup, mais tu dois encore connecter les events.

                  Et tu fais quoi en JS+HTML avec les évènements on_click etc ? Tout en JS marche par callback justement parce qu'il est pensé pour être connecté à des évènements. Je ne connais pas les framework js (et non je ne tiens pas à les connaître), mais en allant sur la page d'accueil de knockout, je vois ça :
                  Exemple knokout

                  Oui tu as le select qui n'est pas explicitement connecté (en fait du connecte des données et pas des évènements) mais tu as toujours une connexion sur un évènement pour le bouton. C'est des notions que tu as en QML par exemple.

                  Par exemple en QT les signals, ont à priori, extrêmement simplifié le problème, sauf que je me suis battu avec à cause des spécificités de C / C++ eect. (les pointeurs tousssa, Oui j'ai un niveau de m*** en C).

                  Comme je disais tu as un tas de bindings. Le fait qu'ils soient fait en langage natifs comme C ou C++ permet surtout de produire plus facilement ces bindings (et de ne pas être dépendant d'un runtime).

                  Faudrait que je le testes pour de vrai. Mais je ne peux m’empêcher que cette solution est sous optimale par rapport à une refondation plus profonde comme a pu le faire des projets comme GO ou nodejs

                  Node.js je sais pas (bien que j'ai une petite idée), mais go n'a rien pour les ui. Du coup je vois pas bien de quoi tu parle comme refonte.

                  Tu entends quoi par « DP » ? Tu as des pointeurs sur le mvvm ? J'ai du mal à le différencier du mvc.

                  Design pattern, pensais tu à autre chose ?

                  Non c'est juste que j'ai pas l'habitude de lire ce sigle.

                  Ce client MVVM, discute avec un Controleur de MVC, qui encapsule en entrée / sortie son Modèle de sgbd.
                  Sa Vue de MVC ne doit "que" formater la réponse en JS / XML / BIN / ce-qu'il-te-plait

                  Tu n'a pas l'impression d'avoir une lourdeur importante pour (entre autre) serialisé/déserialisé les données ?

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: javascript, ok.

            Posté par . Évalué à  2 .

            Par exemple, je veux faire une application avec deux colonnes … Et un pied de page en bas. Et bien en CSS, tu vas t'amuser, parce que la dernière fois que j'avais essayé, on ne pouvait pas forcer les deux blocs parallèles à avoir la même taille, sauf avec du JS … Ce qui rend moche dès que tu as un thème graphique un peu subtil (avec un fond par colonne). Et j'avais vu un tuto, expliquant qu'une grosse image de fond ferait l'affaire, pour faire croire que la colonne continuait ……..

            La dernière fois que tu as essayé doit remonter à très loin et ça devait être avec IE6…
            Cf. ce tuto pour voir comment faire ce que tu demandes

            • [^] # Re: javascript, ok.

              Posté par . Évalué à  2 .

              Et ça te donne pas la nausée de devoir jouer sur les padding, les margin etc pour arriver à ça ?

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # Javascript ? Et pourquoi pas plutôt ....

    Posté par . Évalué à  3 . Dernière modification : le 08/02/13 à 09:09

    Le brainfuck ? Le vrai langage des purs, des durs et des tatoués de la programmation ?

    Ou sa variante Ook!, utilisable par tout bon programmeur en manque de sommeil.

    C'est par où ?

    ----->[] VLAM !

  • # Javascript et les fichiers

    Posté par . Évalué à  0 .

    Il y a quelques années que je ne fais que des bricoles en Javascript, et j'utilise surtout Tcl/Tk dont le code est interprété sur tous Unix, Windows, MacOs,etc. sans le moindre changement.
    Je ne connais pas de moyen simple en JS pour accéder aux fichiers, et je ne sais pas même si on peut écrire dedans. Est-ce que les développeurs Gnome ont réglé ce problème, si oui où puis-je me documenter?

    • [^] # Re: Javascript et les fichiers

      Posté par (page perso) . Évalué à  5 .

      Pour Gnome, je ne sais pas, mais ce ne serait pas les premiers à implémenter une API de gestion des fichiers, node.js l'a déjà fait.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Javascript et les fichiers

        Posté par . Évalué à  2 .

        TiddlyWiki est un wiki qui tiens dans un unique fichier HTMl avec du JS dedans donc je pense qu'il y a des primitives pour écrire dans des fichiers (par contre les navigateurs hurlent à la mort quand ça arrive).

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Javascript et les fichiers

      Posté par (page perso) . Évalué à  2 .

      «Est-ce que les développeurs Gnome ont réglé ce problème, si oui où puis-je me documenter?»

      Je sais pas où trouver la doc pour l'utilisation des bindings Glib dans Javascript, mais je pense que l'idée c'est d'utiliser ça, et vu que la Glib a des fonctions permettant d'accéder aux fichier ça doit résoudre le problème.

      • [^] # Re: Javascript et les fichiers

        Posté par . Évalué à  3 .

        C'est bon pour la réutilisabilité, ça, que chaque projet invente son API d'accès au système de fichiers.

        • [^] # Re: Javascript et les fichiers

          Posté par . Évalué à  1 .

          Euh, la GLib le fournit pour chaque langage qui possède ses bindings … Aussi bien pour du C/C++ que du Javascript.

          Après pour certains langages c'est en concurrence avec la lib standard, mais pour d'autres, comme javascript, c'est au contraire une manière élégante de régler le problème, puisque porter une appli qui utilise déjà GLib/GIO devient un jeu d'enfant.

          • [^] # Re: Javascript et les fichiers

            Posté par . Évalué à  2 .

            Je ne parlais pas de la glib mais bien du fait que chaque projet Javascript devait inventer son API d'accès aux fichiers parce que le langage de base ne fournit rien.

  • # DBus dans le noyau

    Posté par (page perso) . Évalué à  3 .

    Ave,

    Pour info, la présence de Greg, développeur noyau, à ce Hackfest est dû à son projet d'implémenter DBus dans le noyau. En fait, l'objectif est de fournir un système IPC multi-cast & point à point fiable et performant. D'ou l'idée d'ajouter un nouveau type de socket à côté des traditionnels AF_UNIX, AF_STREAM et AF_DGRAM et à côté de AF_NETLINK : AF_BUS.

    Plus de détails : http://www.kroah.com/log/linux/af_bus.html

Suivre le flux des commentaires

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