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.
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.
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 !
Aller plus loin
- Retours de l'événement sur le wiki de GNOME (173 clics)
- ECMAScript 6 (213 clics)
# QML bis?
Posté par Albert_ . Évalué à 10. Dernière modification le 06 février 2013 à 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 liberforce (site web personnel) . Évalué à 10. Dernière modification le 06 février 2013 à 17:15.
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 saltimbanque (site web personnel) . Évalué à 4.
ce serait vraiment une avancée… parce que GtkClutterEmbed gnii…
[^] # Re: QML bis?
Posté par david.g . É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 Albert_ . É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 liberforce (site web personnel) . É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 Antoine . É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 GeneralZod . É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 Maclag . Évalué à 9.
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:
[^] # Re: QML bis?
Posté par Troy McClure (site web personnel) . Évalué à 10.
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 saltimbanque (site web personnel) . Évalué à 3.
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 Maclag . É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 barmic . Évalué à 10. Dernière modification le 06 février 2013 à 18:23.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: QML bis?
Posté par karteum59 . Évalué à 6.
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 Gabin II . Évalué à 0.
Capitale de l'Europe. C'est plus connu :)
[^] # Re: L'événement s'est déroulé à Bruxelles, capitale de la Belgique
Posté par Frédéric Blanc . Évalué à -1.
C'est important de préciser, car ça aurait pu être ce Bruxelles, celui-ci ou celui-là, voire ce quatrième-là (bon, d'accord, vu que les 3 premiers sont situés en pays anglophones, c'est plus Brussels que Bruxelles, mais le dernier est bien un homonyme de la capitale belge, tout comme ce dernier Bruxelles --- pas très habité, je l'admets, mais peut être un jour sera-t'il aussi capitale de quelque chose :-)).
[^] # Re: L'événement s'est déroulé à Bruxelles, capitale de la Belgique
Posté par Anonyme . Évalué à 10.
Seulement
la capitalele siège de la plupart des institutions de l'EuropeUnion Européenne.La nuance est on ne peut plus importante pour l'anti-UE pro-Europe que je suis.
# Vachement objectif...
Posté par liberforce (site web personnel) . Évalué à 10.
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.
[^] # Re: Vachement objectif...
Posté par Arthur Geek (site web personnel) . Évalué à 8.
Qui n'est pas plus trolleur que RMS, qui n'est pas plus trolleur que Nadine MORANO, etc.
Prochainement, je vous proposerai peut-être un commentaire constructif.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Vachement objectif...
Posté par patate . Évalué à 4.
En l’occurrence c'est Poettering, y'a quelques mots et noms en allemand où oe ne correspond pas a un Umlaut (par exemple Goethe).
[^] # Re: Vachement objectif...
Posté par Neije . Évalué à -1.
c'est pas sérieux ? non en Allemange Goethe = Göthe … Mais pour les noms très utilisé dans les langues étrangères, on le voit plutôt avec un e pour faciliter la vie. Mais si tu tapes Göthe tout le web allemand va te parler de l'écrivain …
http://de.wiktionary.org/wiki/Goethe
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
[^] # Re: Vachement objectif...
Posté par patate . Évalué à 2.
Si si, il y a bien les deux. Tu peux par exemple jeter un œil là:
http://de.wikipedia.org/wiki/Goethe_%28Begriffskl%C3%A4rung%29
Certains s’écrivent avec un Umlaut, d'autres avec oe. Et google convertit automatiquement les voyelles suivies de e en voyelles avec Umlaut.
Il y a par exemple un paquet de Goethestraße dans les villes allemandes, jamais écrites avec ö.
[^] # Re: Vachement objectif...
Posté par BAud (site web personnel) . Évalué à 2.
j'avais tiqué à relecture, mais l'avait justement pris pour de l'humour et laissé :) bon, pour la peine, j'ai corrigé en prenant comme référence wikipedia et un commentaire ci-dessous.
# Widget gnome 3
Posté par saltimbanque (site web personnel) . Évalué à 5.
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 devnewton 🍺 (site web personnel) . Évalué à 10.
J'aurais dis pour pour les webmasters.
Retrouver du javascript partout, ça commence à me gonfler.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: jet de séduction: échec critique
Posté par Badeu . É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 …
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 Aluminium95 . É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 Badeu . É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 Aluminium95 . É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 BAud (site web personnel) . Évalué à 5.
c'est le propre du numérique d'être virtuel, ce serait plus dommageable que ces langages soient incohérents :/
justement, la norme fixe les lacunes actuelles, elle pourrait les corriger si elle évoluait :-)
oui, REXX aussi si on va par là
~~~~> [ ]
[^] # Re: jet de séduction: échec critique
Posté par coïn . É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 devnewton 🍺 (site web personnel) . Évalué à 6.
Par rapport à Python ou Ruby, c'est pertinent. Maintenant il y a plein de langages cools qui mettent une bonne fessée aux meilleurs moteurs javascript: D, ocaml, go, freepascal, haskell, java…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: jet de séduction: échec critique
Posté par sifu . Évalué à 2.
Pour Python, PyPy semble générer beaucoup d'espoir.
[^] # Re: jet de séduction: échec critique
Posté par romu . Évalué à 1.
D'ailleurs, à ma connaissance GJS est basé sur SpiderMonkey, le moteur "ancienne" génération de Mozilla. Y-a-t-il volonté de passer sur IonMonkey, le nouveau ?
[^] # Re: jet de séduction: échec critique
Posté par YBoy360 (site web personnel) . Évalué à 1.
Dart …
[^] # Re: jet de séduction: échec critique
Posté par spider-mario . Évalué à 2.
N’oublions pas LuaJIT.
[^] # Re: jet de séduction: échec critique
Posté par Astaoth . É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).
Emacs le fait depuis 30 ans.
[^] # Re: jet de séduction: échec critique
Posté par Badeu . Évalué à 1. Dernière modification le 06 février 2013 à 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 Astaoth . É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.
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.
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.
Emacs le fait depuis 30 ans.
[^] # Re: jet de séduction: échec critique
Posté par Atem18 (site web personnel) . Évalué à 5.
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 barmic . Évalué à 4.
Il n'a pas de classe, c'est normal parce qu'il fait de l'objet par prototype.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par Atem18 (site web personnel) . Évalué à 3.
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 Kekun (site web personnel, Mastodon) . É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 jigso . É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 Guillaume Denry (site web personnel) . Évalué à 10.
Ah mince, moi quand je vais au MacDonalds, j'y vais pour manger du canard.
Je comprends, maintenant.
[^] # Re: jet de séduction: échec critique
Posté par BAud (site web personnel) . É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 Maclag . É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 Atem18 (site web personnel) . Évalué à 2.
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.
La simplicité de Bash.
[^] # Re: jet de séduction: échec critique
Posté par xcomcmdr . Évalué à 6.
Une "simplicité" toute relative.
"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 Atem18 (site web personnel) . Évalué à 2.
C'est ce que je sous-entendais en fait. Mais comme je me suis dis qu'on était Vendredi… ;)
[^] # Re: jet de séduction: échec critique
Posté par barmic . É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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par patate . É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 barmic . Évalué à 4.
Bon les développeurs Gnome sont idiots. Mais qu'en est il de ceux de Qt et de Windows ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par patate . É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 Guillaume Denry (site web personnel) . É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.
[^] # Re: jet de séduction: échec critique
Posté par patate . É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 Badeu . É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 xcomcmdr . Évalué à 5. Dernière modification le 07 février 2013 à 11:03.
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 Guillaume Denry (site web personnel) . É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 ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: jet de séduction: échec critique
Posté par barmic . Évalué à 9.
Linus et le projet GNU aurait pu se contenter de demander à IBM & co de libérer Unix.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par xcomcmdr . É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 karteum59 . Évalué à 1. Dernière modification le 07 février 2013 à 22:17.
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 Maclag . Évalué à 4.
Questions bêtes:
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 barmic . Évalué à 4.
Avoir un second bureau ça crée une concurrence plutôt saine je trouve.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jet de séduction: échec critique
Posté par liberforce (site web personnel) . Évalué à 8.
Pas la licence de KDE, la licence de Qt, qui était proprio à l'époque.
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).
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 ?
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.
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.
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 ?
C'est à peu près le seul point sur lequel on est d'accord.
[^] # Re: jet de séduction: échec critique
Posté par patate . Évalué à 6.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: jet de séduction: échec critique
Posté par rewind (Mastodon) . É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 zebra3 . Évalué à 1.
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 weeber (site web personnel) . É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 Thomas Douillard . Évalué à 3.
Mediawiki … c'est en phase de test pour le codage des modèles.
[^] # Re: Lua
Posté par Kioob (site web personnel) . É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 dave_null (site web personnel) . Évalué à 4.
Parce que Javascript est un meilleur choix.
[^] # Re: Lua
Posté par neil . Évalué à 6.
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 xcomcmdr . Évalué à 10. Dernière modification le 06 février 2013 à 20:30.
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 Kekun (site web personnel, Mastodon) . Évalué à 3.
J'espère qu'il ne bosse pas sur un mainframe…
[^] # Re: Lua
Posté par jigso . Évalué à 9.
Plus joli, non ? (et sans doute plus efficace)
[^] # Re: Lua
Posté par dave_null (site web personnel) . É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 Xavier Maillard . Évalué à 0.
Les boucles, ca fait vraiment old school pas tres 2013 tout ca :D
[^] # Re: Lua
Posté par needs . É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 Tom . Évalué à 2. Dernière modification le 06 février 2013 à 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 LupusMic (site web personnel, Mastodon) . É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 Jean B . É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 Guillaume Denry (site web personnel) . Évalué à 5. Dernière modification le 07 février 2013 à 08:05.
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.
[^] # Re: Lua
Posté par saltimbanque (site web personnel) . É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 Guillaume Denry (site web personnel) . Évalué à 2.
Oui, je suis d'accord, mais je ne répondais pas vraiment à cela.
[^] # Re: Lua
Posté par Jean B . Évalué à 6.
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.
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 xcomcmdr . Évalué à 1.
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 reno . Évalué à 5.
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 needs . Évalué à -1.
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 paraet les pointeurs parp: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_apNamesest 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 :
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 liberforce (site web personnel) . É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 Guillaume Denry (site web personnel) . É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.
[^] # Re: Lua
Posté par needs . Évalué à 0. Dernière modification le 07 février 2013 à 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.
Je suis curieux de savoir comment on fait un membre privé en C :)
Tu parles de faire un
typedefsur une structure pour indiquer que l'on doit uniquement la manipuler avec des fonctions ?[^] # Re: Lua
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Ce qui ressemblerait le plus à la notion de privé en C serait pour moi les déclarations static
[^] # Re: Lua
Posté par Jean B . É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 needs . Évalué à 0. Dernière modification le 07 février 2013 à 16:48.
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é.
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 Jean B . É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 needs . Évalué à 2. Dernière modification le 07 février 2013 à 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 lolop (site web personnel) . É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).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Lua
Posté par Kioob (site web personnel) . É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 reno . Évalué à 3.
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 Toufou (site web personnel) . Évalué à 0.
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 claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Lua
Posté par tyoup . Évalué à -3.
tu fais sans soucis de la POO en C
ou tu fais de la POO en assembleur.# Choix discutable
Posté par Infernal Quack (site web personnel) . É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 freem . É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
malbien 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 lolop (site web personnel) . Évalué à 3. Dernière modification le 07 février 2013 à 13:08.
Tu mélanges "bon" et "vrai", et en plus avec des langages utilisé dans des contextes différents…
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Choix discutable
Posté par freem . É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 reno . Évalué à 5.
Oui, enfin là on parle d'un langage de "haut niveau"..
Enfin soi-disant de haut niveau..
# Coquille
Posté par romu . Évalué à 1.
"Hors GObject Introspection est utilisé pour tout les langages." -> "Or GObject Introspection est utilisé pour tout les langages."
[^] # Re: Coquille
Posté par romu . É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 CrEv (site web personnel) . Évalué à 4.
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 Guillaume Denry (site web personnel) . É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.
[^] # Re: troll
Posté par Tom . Évalué à 2.
Surtout que la plupart des manques soulevés dans les commentaires semblent comblés dans ECMAScript 6 :
letpour des variables avec une portée de blocMappour remplacer l'usage d'unObjecten tant que hash tableclass,module,extends, etc pour la modularité du code et du sucre syntaxique pour le côté objetEt 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
letdans le code d'extensions du Shell.[^] # Re: troll
Posté par lolop (site web personnel) . Évalué à 6.
T'as dû rater un paragraphe lors de ta lecture:
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: troll
Posté par Tom . Évalué à 1. Dernière modification le 07 février 2013 à 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 saltimbanque (site web personnel) . Évalué à 2.
GJS le gère déjà, mais pour Seed je ne crois pas
[^] # Re: troll
Posté par Tom . Évalué à 1.
Effectivement, rien à ce sujet dans la documentation de Seed.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
# FirefoxOS
Posté par fredix . É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 freem . É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 fredix . É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 barmic . É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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par freem . Évalué à 1. Dernière modification le 07 février 2013 à 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 fredix . É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 barmic . Évalué à 2.
En effet.
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).
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par fredix . É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 barmic . Évalué à 7.
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.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par liberforce (site web personnel) . Évalué à 6.
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 fredix . É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 barmic . Évalué à 2.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par fredix . É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 liberforce (site web personnel) . É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 Dr BG . É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 Lizzie Crowdagger (site web personnel) . É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 Dr BG . É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 :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FirefoxOS
Posté par freem . É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 )
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FirefoxOS
Posté par freem . É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 barmic . Évalué à 2.
Puis un jour tu va découvrir les analyseurs statiques (comme lint) et tu va comprendre qu'un compilateur ça sert à compiler.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par freem . É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 barmic . É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…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par Littleboy . Évalué à 2.
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 freem . Évalué à 1.
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:
Après, certains semblent intéressants:
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…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FirefoxOS
Posté par barmic . Évalué à 2. Dernière modification le 11 février 2013 à 18:08.
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.
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'.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FirefoxOS
Posté par freem . É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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 12 février 2013 à 12:30.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FirefoxOS
Posté par freem . É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 barmic . Évalué à 2.
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).
Garde fou tu dis ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par freem . É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…)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 12 février 2013 à 21:06.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FirefoxOS
Posté par barmic . É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 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FirefoxOS
Posté par barmic . É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).
Je crois que tout code avec de bons tests unitaires est trivial à corriger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par barmic . Évalué à 2. Dernière modification le 13 février 2013 à 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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par freem . Évalué à 2.
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 fredix . Évalué à 10. Dernière modification le 08 février 2013 à 15:49.
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 freem . Évalué à 0.
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 barmic . Évalué à 3.
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).
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 tombe bien avec JS qui a une lib standard assez petite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FirefoxOS
Posté par freem . Évalué à 0.
Merci, j'avais un doute sur le propos, d'où ma question. Je suis donc d'accord sur ce point.
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 Antoine . Évalué à 3.
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 freem . É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 windu.2b . Évalué à 3.
Mauvais exemple : Swing repose en (grande) partie sur AWT
[^] # Re: FirefoxOS
Posté par freem . É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 romu . Évalué à 9. Dernière modification le 07 février 2013 à 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…
-- 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 :
Soit on fait du "Gnome" :
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 Albert_ . É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 romu . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci Etienne
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
console devient quand même relativement courant voire standard, même dans les frameworks côté serveur, comme nodejs.
[^] # Re: Merci Etienne
Posté par romu . É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
…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 Stéphane Klein (site web personnel) . É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 ?
[^] # Re: Une solution pour développer des applications Qt basées à 100% sur Javascript ?
Posté par romu . Évalué à 4.
Je crois que certaines applis sont codées entièrement en Qml sur le Nokia N9. Et ce sera surement pareil sur l'OS Sailfish de Jolla.
[^] # Re: Une solution pour développer des applications Qt basées à 100% sur Javascript ?
Posté par claudex . Évalué à 5.
Attention à ne pas confondre Qt Quick et QML, QML est un langage déclaratif utilisé par Qt Quick pour l'interface graphique mais tu peux faire bien plus, il existe par exemple un système de build basé sur QML.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# javascript, ok.
Posté par maboiteaspam . É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 Aluminium95 . É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 maboiteaspam . Évalué à 2. Dernière modification le 08 février 2013 à 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 freem . Évalué à 4.
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.
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…)
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.
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 Aluminium95 . É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 maboiteaspam . Évalué à 1. Dernière modification le 18 février 2013 à 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 barmic . Évalué à 3.
Tu entends quoi par « DP » ? Tu as des pointeurs sur le mvvm ? J'ai du mal à le différencier du mvc.
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.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: javascript, ok.
Posté par maboiteaspam . Évalué à 1.
hello,
je reprends par la fin :°)
et je le coupe en 3
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.
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).
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.
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.
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 barmic . Évalué à 3.
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 :
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.
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).
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.
Non c'est juste que j'ai pas l'habitude de lire ce sigle.
Tu n'a pas l'impression d'avoir une lourdeur importante pour (entre autre) serialisé/déserialisé les données ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: javascript, ok.
Posté par windu.2b . Évalué à 2.
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 barmic . Évalué à 2.
Et ça te donne pas la nausée de devoir jouer sur les padding, les margin etc pour arriver à ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Javascript ? Et pourquoi pas plutôt ....
Posté par Swirly . Évalué à 3. Dernière modification le 08 février 2013 à 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 IvanPropez . É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 claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Javascript et les fichiers
Posté par barmic . É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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Javascript et les fichiers
Posté par Lizzie Crowdagger (site web personnel) . É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 Antoine . É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 Aluminium95 . É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 Antoine . É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.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: DBus dans le noyau
Posté par liberforce (site web personnel) . Évalué à 2.
Cela fait un moment que des gens tentent de l'intégrer, Rodrigo Moya avait blogué plein de choses sur ses tentatives d'intégration de DBus au kernel:
http://blogs.gnome.org/rodrigo/tag/dbus/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.