Journal Deux nouvelles pour Qt

Posté par neil le 16 avril 2013 à 07:32. Licence CC By‑SA.

Étiquettes :

avr.

2013

Ce journal a été promu en dépêche : Nouveau moteur JavaScript pour Qt et Qt 5.1 en alpha.

Nouveau moteur JavaScript

Après avoir changé de moteur JavaScript lors du passage à QML 2.0 (inclu dans Qt 5.0), Digia, la société derrière Qt, annonce vouloir effectuer un nouveau changement de moteur ! Pour rappel, QML est le langage privilégié pour le futur de Qt, et mêle un aspect déclaratif pour la définition d‘interface graphiques, à un aspect impératif sous forme de code JavaScript. Pour l’instant, Qt se base sur le moteur V8, dévelopé par Google, et dont la vélocité a été la raison principale de son incorporation à Qt.

Mais ce moteur est trop orienté navigateur, et rend complexe la définition d’objets en Qt. Ceux-ci devant être accessibles depuis QML, JavaScript, et C++ (sous forme d’objet QObject). De plus l’utilisation de V8 pose différents problèmes, notamment pour le support d’iOS et WinRT (QML ayant vocation à unifier les interfaces graphiques mobile et desktop). Pour l’instant Qt maintient sa propre branche patché de V8 dans son arbre. Le nouveau projet, commencé du temps de Nokia, fonctionne et porte le nom de v4vm, mais les performances actuelles sont franchement décevantes (trois fois plus lents que l’ancien moteur QML 1.0).

Qt 5.1 en alpha

Digia a aussi annoncé la version beta de Qt 5.1. Cette nouvelle version apporte son lot de nouveautés, en particulier en complétant la bibliothèque QML pour la définition d’interfaces graphiques. En effect, les interfaces à base de widgets ne sont pas disponibles en QML, et les utilisateurs devaient jusqu’alors re-créer leur propres composants graphiques en se basant sur les quelques éléments disponibles. Il est aussi possible de créer ses propres éléments QML à partir de zéro, soit en les peignant d’abord dans un QPainter, ce qui implique une perte de performance lors de la copie des bitmaps vers OpenGL, soit en définissant ses propres scènes OpenGL, un travail plus que fastidieux.

Avec Qt 5.1, on voit apparaître les Controls QtQuick qui regroupent tous les éléments standard d’une interface graphique habituelle : boutons, labels, barre de menu, barre de progrès, tabs, et un début de composants de texte. Tout ça reste bien moins puissant que l’expérience accumulés dans les widgets standards (le module Qt Widgets), et ceux-ci sont loins d’être dépréciés dans Qt.

Une nouvelle avancé de Qt 5.1 est le support d’Android. Histoire que les fonctionnalités tactiles de QML servent enfin à quelque chose.

On peut aussi noter la sortie de Qt 5.0.2, uniquement des corrections de bugs. Notamment celui empêchant d’utiliser Qt/MinGW sous Windows XP.

# Nouveau moteur JavaScript

Posté par Gof (site web personnel) le 16 avril 2013 à 08:44. Évalué à 10.

V8 […] dont la vélocité a été la raison principale de son incorporation à Qt.

Pas vraiment… Avant V8, JavascriptCore (de webkit) était utilisé. Les deux moteurs ont de bonnes performances. Mais JavascriptCore ne maintiens pas d'API public et sa raison d'être est en temps que moteur pour webkit. V8 par contre dispose d'une API stable et est conçus pour être embqué dans différents projets. Mettre à jour JavascriptCore dans QtScript représente un travail considérable puisque les API changes completement entre chaque version. V8 était donc vu comme plus facile à maintenir.

Mais ce moteur est trop orienté navigateur

Pas vraiment orienté navigateur, il est utilisé par d'autre projets, notamment Node.js.
Par contre, il est orienté ECMAScript standard, et donc n'est pas optimisé pour les extensions QML.
# Les fonctionnalites tactiles...

Posté par Renaud Casenave-Péré le 16 avril 2013 à 09:06. Évalué à 3.

Une nouvelle avancé de Qt 5.1 est le support d’Android. Histoire que les fonctionnalités tactiles de QML servent enfin à quelque chose.

Les fonctionnalites tactiles se portent tres bien, merci pour elles. Elles sont deja mises a contribution dans maemo, meego, sailfish, blackberry…

Il n'y a pas qu'android (ni ios) dans la vie telephonique.
- [^] # Re: Les fonctionnalites tactiles...
  
  Posté par Frédéric COIFFIER le 16 avril 2013 à 09:16. Évalué à 4.
  
  Il n'y a pas que sur les téléphones qu'il y a des écrans tactiles…
  - [^] # Re: Les fonctionnalites tactiles...
    
    Posté par Renaud Casenave-Péré le 16 avril 2013 à 10:02. Évalué à 3.
    
    C'est exact, tu as raison.
    
    Il y en a aussi sur les distributeurs de billet sncf. Hein Kerro ?
    - [^] # Re: Les fonctionnalites tactiles...
      
      Posté par JoeltheLion (site web personnel) le 16 avril 2013 à 10:17. Évalué à 10.
      
      Est-ce qu'on peut vraiment parler d'écran tactile quand il faut un marteau pour que l'écran détecte une pression?
      - [^] # Re: Les fonctionnalites tactiles...
        
        Posté par Nicolas Boulay (site web personnel) le 16 avril 2013 à 12:08. Évalué à 10.
        
        Ecran ductile ?
        
        "La première sécurité est la liberté"
    - [^] # Re: Les fonctionnalites tactiles...
      
      Posté par oao le 16 avril 2013 à 20:11. Évalué à 3.
      
      C'est lui qui a fait ces écrans ? Connait-il la signification du mot parallaxe ? J'en ai marre de devoir plier mes jambes pour appuyer au bon endroit.
- [^] # Re: Les fonctionnalites tactiles...
  
  Posté par groumly le 18 avril 2013 à 04:48. Évalué à 3.
  
  Effectivement, ya aussi les 12 (douze) utlisateurs des autres plateformes, pour lesquelles se battent les 19 autres frameworks.
  
  Il n'en restera qu'un seul! Fois douze, evidemment.
  
  Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Transformé en dépêche

Posté par Nÿco (site web personnel) le 16 avril 2013 à 11:26. Évalué à 6.

Merci opur ce journal, je l'ai transformé en dépêche :
http://linuxfr.org/redaction/news/nouveau-moteur-javascript-pour-qt-et-qt-5-1-en-alpha
C'est encore en rédaction collaborative, vous pouvez y contribuer. Merci d'avance.
- [^] # Re: Transformé en dépêche
  
  Posté par Nÿco (site web personnel) le 17 avril 2013 à 19:04. Évalué à 2.
  
  On peut pousser en modération ?
# Petite question ...

Posté par totof2000 le 16 avril 2013 à 12:56. Évalué à 6.

Pour rappel, QML est le langage privilégié pour le futur de Qt, et mêle un aspect déclaratif pour la définition d‘interface graphiques, à un aspect impératif sous forme de code JavaScript.

Quel est l'intéret d'utiliser le Javascript pour ça ? Non pas que je doute des perfs de celui-ci vu les progrès réalisés ces derniers temps, mais l'aspect objet de JAvascript est assez rudimentaire, sans compter le côté moins rigoureux de celui-ci par rapport à un langage comme Java ou C++. N'est-ce pas un peu dangereux ?
- [^] # Re: Petite question ...
  
  Posté par Frédéric COIFFIER le 16 avril 2013 à 14:47. Évalué à 2.
  
  Ici, le JavaScript est utilisé en complément du C++ : on peut développer des applications en pure C++, pure QML et C++/QML.
  Je pense qu'il a été choisi de fait qu'il est accessible, répandu et utilisé par de très nombreux développeurs (et il y avait déjà un moteur Javascript pour le moteur Webkit déjà intégré à Qt).
- [^] # Re: Petite question ...
  
  Posté par devnewton 🍺 (site web personnel) le 16 avril 2013 à 14:55. Évalué à 6.
  
  Quel est l'intéret d'utiliser le Javascript pour ça ?
  
  C'est la mode.
  
  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: Petite question ...
    
    Posté par Guillaume Denry (site web personnel) le 16 avril 2013 à 14:57. Évalué à 4.
    
    A mon avis, elle est bien partie pour durer, cette "mode".
- [^] # Re: Petite question ...
  
  Posté par Laurent J (site web personnel, Mastodon) le 16 avril 2013 à 15:24. Évalué à 3.
  
  mais l'aspect objet de JAvascript est assez rudimentaire, sans compter le côté moins rigoureux de celui-ci par rapport à un langage comme Java ou C++
  
  L'aspect "rudimentaire" de Javascript n'est pas un problème. Dans les navigateurs, les objets que tu manipules dans une page web (les éléments DOM etc), sont des objets mappés sur des objets C++.
  
  Je ne vois pas en quoi utiliser JS est gênant. Surtout que le but ici, si j'ai bien compris, c'est de proposer un environnement de développement pour l'UI, plus simple que C++. Donc il faut un langage plus simple, moins complexe que C++. Et pour moi JS est idéal. Tu fais de l'objet sans t'embêter avec la gestion de pointeurs, de template ou de je ne sais quoi d'autres.
  
  Si JS ne te convient pas, tu as la possibilité de rester en C++..
  - [^] # Re: Petite question ...
    
    Posté par Guillaume Denry (site web personnel) le 16 avril 2013 à 15:31. Évalué à 7.
    
    Justement, autant j'entends bien l'argument de la haute utilisation de JavaScript dans le monde de la programmation d'aujourd'hui pour expliquer pourquoi il a été choisit, mais pour autant, le décrire comme langage "idéal" comme tu le fais, quand on connait tous les problèmes dont souffre le langage…. et de plus, là, on ne parle justement pas du web, mais d'applications natives.
    Il n'y a pas que C++ et JavaScript, il y a tout un large spectre de langages entre deux :)
    - [^] # Re: Petite question ...
      
      Posté par Laurent J (site web personnel, Mastodon) le 16 avril 2013 à 15:43. Évalué à 2.
      
      quand on connait tous les problèmes dont souffre le langage
      
      Quels problèmes exactement ? Tu parles du JS des années 90 ?
      
      Le langage possède tout un tas de fonctionnalités modernes (closure, generator …).
      
      là, on ne parle justement pas du web, mais d'applications natives.
      
      Oui, et ? Ça fait 10 ans que je fais des applications desktop en JS (XulRunner), avec du code manipulant des composants binaires (XPCOM, jsctypes …), je ne vois pas vraiment de souci… Ça apporte énormément de souplesse.
      - [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 16 avril 2013 à 15:59. Évalué à 3.
        
        Je vais te faire l'inventaire des problèmes connus de JavaScript, tu vas me répondre point par point et ça va durer toute l'après-midi ?
        
        Voici un petit exemple pioché au hasard :
        
        http://c2.com/cgi/wiki?JavaScriptFlaws
        
        J'ajouterais par exemple le problème du scope (private/public/protected) qui peut être rebricolé mais sous certaines conditions souvent incompatibles avec l'optimisation du programme. (va faire des variables privées lorsque tu utilises .prototype pour modulariser ton code en fonctions…)
        
        Ou alors, l'utilisation compliquée des "==" et "===" qui fait que tout le monde recommande maintenant d'utiliser uniquement "==="… super !
        
        Je suis vache et pourtant j'aime ce langage, j'aime les objets Json, le fait de pouvoir manipuler absolument n'importe quoi comme on veut, ce qui le rend extrêmement souple.
        Mais je ne suis pas forcément objectif.
        
        [^] # Re: Petite question ...
        
        Posté par Laurent J (site web personnel, Mastodon) le 16 avril 2013 à 16:26. Évalué à 3. Dernière modification le 16 avril 2013 à 16:28.
        
        tu vas me répondre point par point et ça va durer toute l'après-midi ?
        
        Ah ba je peux :-) Mais bon j'ai pas tout mon temps non plus. Bon là je le fais, parce que le gars il connait juste le javascript "web" de papa, et pas le "vrai" javascript moderne (comme bon nombre de dev d'ailleurs).
        
        No Built-In Array Iterator
        
        Faux. forEach, map, every, some etc... Et ça fait en plus partie de Ecmascript 5 (es5), implémenté partout à priori.
        
        No Libraries
        
        plus ou moins Faux. CommonJS, RequireJS et autre systèmes de modules, ça existent ;-) … Et Ecmascript 6 apporte un système de module natif si je ne me trompe pas.
        
        No good way of controlling for/in access to properties
        
        Faux. l'objet Object contient un certain nombre de méthodes pour définir des propriétés énumérables, en lecture seule ou pas (defineProperties) etc.. Là aussi, de l'es5.
        
        typeOf null == "object"
        
        pas testé.
        
        Variables are global unless declared local.
        
        Oui. Sauf si on utilise le mot clé let (Ecmascript 6) plutôt que var. Implémenté depuis des années dans SpiderMonkey (utilisable pour les extensions)
        
        Octal integer literals
        
        oui c'est pas cool en effet
        
        Tu en as d'autres ? :-)
        
        PS: pas mal de truc Es6 sont implémentés depuis pas mal de temps dans SpiderMonkey.
        
        Bref, la bible, c'est ici [https://developer.mozilla.org/en-US/docs/JavaScript/Reference]
        
        [^] # Re: Petite question ...
        
        Posté par neil le 17 avril 2013 à 18:26. Évalué à 3.
        
        Le problème c’est wat (la vidéo met aussi Ruby dans le même pannier).
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 16 avril 2013 à 16:55. Évalué à 3.
        
        Ou alors, l'utilisation compliquée des "==" et "===" qui fait que tout le monde recommande maintenant d'utiliser uniquement "==="… super !
        
        Oué enfin ça c'est surtout parce que les "développeurs" ne veulent pas apprendre.
        Pourtant, par exemple, en Java les gens se sont bien fait à .equals sur une String. Et tout le monde ne s'est pas mis à faire du .equals partout (de toute façon ça ne fonctionnerait pas).
        
        Ben là c'est pareil, il suffit d'apprendre un peu, c'est franchement pas compliqué. === teste l'égalité de type.
        
        Genre 0 == "0" mais 0 !== "0"
        
        Si encore tu m'avais dit le problème de ce qui est vrai et ce qui est faux. Genre tester des valeurs, en prenant en compte undefined et null.
        
        Mais bon, l'un des problèmes actuellement à javascript (bien que j'ai l'impression que ça change) est simplement qu'une bonne partie des développeurs javascript n'ont pas appris le langage, ne l'apprennent pas et ne cherchent pas à l'apprendre. Au plus ils apprennent un peu de jquery. Récemment j'ai lu des articles, où le gens jouent aux experts jQuery, mais ne savent finalement même pas utiliser le javascript. Genre écrire un .style.color='red' devient compliqué, et ne parlons même pas des évènements…
        
        [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 16 avril 2013 à 17:05. Évalué à 3.
        
        Oué enfin ça c'est surtout parce que les "développeurs" ne veulent pas apprendre.
        
        J'ai plutôt l'impression que comme c'est plutôt facile pour certains développeurs de confondre, pour du travail d'équipe, ça peut devenir infernal de permettre d'utiliser "==" et "===".
        Surtout qu'en javascript, comme le typage est rock'n'roll, tu ne sais jamais vraiment ce que tu manipules, sauf avec une doc bien costaude (que je recommande à chaque fois aux gens : blindez la doc javascript et les commentaires à mort, c'est ess-en-tiel).
        Y'a des fois, en utilisant le code d'un autre tu as franchement des doutes quand tu utilises "===" ou bien "==".
        
        Il y a également un phénomène que je vois de plus en plus : les gens se crispent pas mal sur jslint, certains l'activent au max, et du coup, on a plus le droit d'utiliser "==" par exemple, ou bien si on déclare pas ses var au tout début de la fonction, c'est la fin des haricots. Ce truc là permet d'avoir de bonnes règles mais transforment certains développeurs en nazis :)
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 16 avril 2013 à 17:30. Évalué à 3.
        
        Pour ce genre de problème, j'ai vraiment apprécié travailler avec les Closure Tools. Une fois le code annoté, franchement c'est bien typé. Certains trouverons ça lourd, mais c'est justement l'assurance d'avoir un code qui fait ce que tu lui demande, de ne pas avoir d'ambiguïté de type, et en plus d'avoir un code performant (qui se compile, et non se minifie, avec suppression du code mort, inlining, etc).
        
        comme c'est plutôt facile pour certains développeurs de confondre
        
        Oué mais c'est ça que j'ai du mal à comprendre. Comment certains développeurs peuvent ne pas apprendre / comprendre ?
        
        En gros, la règle de base c'est que si tu compares à undefined, null, "", 0; true, false tu dois utiliser === (sinon le résultat n'est pas certain). Et le reste du temps non. Sauf si tu veux, volontairement, faire la différence entre 42 et "42". C'est quand même pas bien dur.
        Que certains aient, initialement, du mal avec les scope, les "bind", call, apply, je veux bien. Mais ça doit rester limité et après quelques temps le problème doit disparaître.
        
        Ce truc là permet d'avoir de bonnes règles mais transforment certains développeurs en nazis :)
        
        Et ben voilà ! C'est malin ça. Moi qui croyais que c'était Gnome…
        
        Par contre, suivre de vrai guidelines est plutôt bien. Dans celles que je préfère, celles de Google (encore) : Javascript Guidelines
        
        Il y a aussi celles-ci : nodeguide
        
        Mais surtout (slides 12 et 13 de bonnes pratiques node.js) :
        
        On n'écrit pas
        
        var mongoose = require('mongoose'), Schema = mongoose.Schema, async = require('async'); var Check = new Schema({ name : String , type : String , url : String , interval : { type : Number, default: 60000 } });
        
        mais
        
        var mongoose = require('mongoose'); var Schema = mongoose.Schema; var async = require('async'); var Check = new Schema({ name : String, type : String, url : String, interval : { type : Number, default: 60000 }
        
        [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 16 avril 2013 à 18:07. Évalué à 3.
        
        L'exemple de code que tu pastes est symptomatique de la confusion des recommandations en matière de bonnes pratiques. Douglas Crockford (via Jslint) préconise justement de n'utiliser qu'un seul var :)
        Mais je suis d'accord, je préfère plusieurs var, beaucoup plus pratique.
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 17 avril 2013 à 10:56. Évalué à 3.
        
        Pourtant, par exemple, en Java les gens se sont bien fait à .equals sur une String.
        
        Sauf qu'en java, == et .equals sont bien définie, il n'y a pas de conversions implicites, pas de "si c'est un objet on fait ça, sinon blabla".
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 17 avril 2013 à 11:08. Évalué à 1.
        
        Et alors ?
        
        == et === sont bien définies en javascript aussi. On fait bien la différence entre = et == alors pourquoi pas entre == et === ?
        Si === s'appelait equals ça ne changerait rien au fait que si les développeurs n'apprennent pas la différence alors ils l'utiliseront mal.
        
        [^] # Re: Petite question ...
        
        Posté par barmic le 17 avril 2013 à 11:21. Évalué à 6.
        
        Quand je lis :
        
        En gros, la règle de base c'est que si tu compares à undefined, null, "", 0, true, false tu dois utiliser === (sinon le résultat n'est pas certain).
        
        D'une part, je comprends pas pourquoi ces valeurs en particulier (à la rigueur si on retire true ça commence à avoir du sens, mais sinon je ne comprends pas).
        D'autre part un résultat « pas certain », ça ne me donne pas envie du tout d'en découvrir plus sur le langage.
        
        PHP aussi a ce genre de problème avec les comparaisons. Les gens qui ont permis des conversion implicites dans les comparaisons doivent être satanistes pour en vouloir autant aux autres développeurs.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 17 avril 2013 à 11:40. Évalué à 5.
        
        "Explicit is better than implicit."
        
        -- The Zen of Python
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 17 avril 2013 à 12:02. Évalué à 1.
        
        « Convention over configuration »
        
        — Plein de bonnes choses, telles Rails
        
        « There's more than one way to do it »
        
        — Perl
        
        « Excplicit is better than implicit » est une des raisons pour lesquelles je trouve python inélégant et fait que je n'y accroche pas du tout contrairement à ruby, javascript, perl, go
        
        [^] # Re: Petite question ...
        
        Posté par totof2000 le 17 avril 2013 à 12:56. Évalué à 1.
        
        « Excplicit is better than implicit » est une des raisons pour lesquelles je trouve python inélégant et fait que je n'y accroche pas du tout contrairement à ruby, javascript, perl, go
        
        Surtout que Python n'applique pas pleinement ce principe (rien de plus implicite qu'une tabulation pour définir les blocs de code).
        
        [^] # Re: Petite question ...
        
        Posté par oao le 17 avril 2013 à 18:30. Évalué à 2.
        
        Non, ce n'est pas implicite du tout, tu le vois bien dans ton code qu'il y a une tabulation. Cette histoire d'indentation, c'est juste une petite spécificité insignifiante du langage, certains n'aiment pas, d'autres si, mais on fond OSEF.
        
        [^] # Re: Petite question ...
        
        Posté par totof2000 le 18 avril 2013 à 11:41. Évalué à 2.
        
        Non, ce n'est pas implicite du tout
        
        Si c'est implicite.
        
        tu le vois bien dans ton code qu'il y a une tabulation
        
        Pas toujours (en fonction de l'éditeur). Les autres langages mettent un begin/end EXPLICITE pour signifier le début/fin de bloc. Non pas que je n'aime pas que l'on force la tabulation (c'est un des détails qui m'a fait m'intéressser à Pythn et qui m'a fait l'aprécier au début), mais ça ne suffit pas.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 11:56. Évalué à 3.
        
        Si tu ne vois pas les tabulations c'est que ton éditeur est réglé pour que la tabulation fasse la taille de 0 caractère. Donc là c'est toi qu'il faut blâmer, pas quelqu'un d'autre.
        
        La tabulation apporte un décalage horizontal. Et oui c'est visible.
        
        [^] # Re: Petite question ...
        
        Posté par daeldir le 18 avril 2013 à 12:39. Évalué à 3.
        
        Ou alors, c'est que tes tabulations font huit caractères, que tu utilises quatre espaces en python pour une indentation, et que ton code est indenté deux fois avec des espaces sur une ligne, puis une fois avec une tabulation sur la ligne suivante. Si ça arrive, tu ne le vois pas.
        
        def buggy(a): if a == 5: print("ok") else: print("nope")
        $ python3 test.py File "test.py", line 9 print("nope") ^ TabError: inconsistent use of tabs and spaces in indentation
        
        Ici, j'utilise des indentations de deux espaces et une tabulation de quatre caractères (les tabulations sont rendues comme ça sur LinuxFR), mais quoi qu'il en soit, le fait est : quand le code est indenté, on ne sait pas forcément si c'est une tabulation ou des espaces (moi, j'aime bien Python, mais je me fais avoir à chaque fois que je passe sur un éditeur de texte que j'ai pas configuré…).
        
        … Aussi, comme LinuxFR rend les tabulations sous forme d'espaces (haha!), voilà une version avec les « charactères invisibles » affichée :
        
        « ⋅ » : Espace « –––– » : Tabulation « ¬ » : Retour à la ligne
        def buggy(a):¬ ⋅⋅if a == 5:¬ ⋅⋅⋅⋅print("ok")¬ ⋅⋅else:¬ ––––print("nope")¬
        
        [^] # Re: Petite question ...
        
        Posté par oao le 19 avril 2013 à 00:42. Évalué à 3.
        
        C'est très fortement déconseillé de mélanger tabulations et espaces, et interdit en python 3. Erreur de jeunesse réglée. Si tu veux régler le problème en python 2, règle ton éditeur pour qu'il t'affiche → pour une tabulation en début de ligne, et · pour un espace. Ou vérifie ton code avec Pylint ou autre, ce qui est d'ailleurs très bien dans le cas général. Mais c'est vraiment du chipotage pour une erreur qui n'arrivait que très peu souvent, qui ne passe quasiment jamais le parsing et qui est maintenant corrigée.
        
        Pour revenir au sujet, un comportement implicite est un comportement prédéfini, sans que tu ne l'ai définit toi-même. C'est l'opposé de magique. Quand en php tu as 0=="0", c'est une conversion de type implicite. Quand en Caml tu écrit f x y, c'est certes différent de la syntaxe habituelle f(x, y), mais ce n'est pas implicite du tout, juste différent de ce que tu vois d'habitude. En python tu sais très bien où commence et où fini ton bloc, ce n'est pas implicite. Ton argument d'un éditeur qui n'affiche pas les tabulations est idiot ; c'est comme dire que les blocs sont implicites en C car un éditeur pourrait ne pas t'afficher les accolades. Bref Python a des défauts, mais là ce n'est qu'un point de détail, mais très visible, donc certains restent bêtement coincés dessus.
        
        [^] # Re: Petite question ...
        
        Posté par totof2000 le 19 avril 2013 à 02:23. Évalué à 2.
        
        Ton argument d'un éditeur qui n'affiche pas les tabulations est idiot ; c'est comme dire que les blocs sont implicites en C car un éditeur pourrait ne pas t'afficher les accolades.
        
        N'importe quoi : par défaut une tabulation, ça ne se voit pas plus que 4 espaces devant un caractère. Une accolade, c'est un caractère que l'on peut difficilement confondre avec un autre, et begin/end est on ne peut plus explicite, bien plus qu'une tabulation.
        
        Bref Python a des défauts, mais là ce n'est qu'un point de détail, mais très visible, donc certains restent bêtement coincés dessus.
        
        S'il n'y avait que ça : la deuxième incohérence c'est le duck typing : pour u langage pronant l'explicite, c'est pas très clean. Alors on rend le langage lourd et inénégant avec ce prétendu "explicite", mais de l'autre côté, on n'explicite pas le type des variables. Quitte à fair de l'explicite, je préfère coder en Ada, et je ne plaisante pas : là au moins c'est assez cohérent.
        
        [^] # Re: Petite question ...
        
        Posté par daeldir le 19 avril 2013 à 10:01. Évalué à 3.
        
        Un peu de remise en contexte pour mon commentaire :
        
        CrEv :
        
        Si tu ne vois pas les tabulations c'est que ton éditeur est réglé pour que la tabulation fasse la taille de 0 caractère. Donc là c'est toi qu'il faut blâmer, pas quelqu'un d'autre.
        
        Moi (Daeldir) :
        
        (moi, j'aime bien Python, mais je me fais avoir à chaque fois que je passe sur un éditeur de texte que j'ai pas configuré…)
        
        Toi (oao) :
        
        Si tu veux régler le problème en python 2, règle ton éditeur pour qu'il t'affiche → pour une tabulation en début de ligne, et · pour un espace.
        
        En gros, je répondais qu'on pouvait ne pas voir les tabulations, sans pour autant avoir réglé la taille des tabulations à 0 caractères. Quand je passe sur l'ordinateur d'un collègue ou d'un ami, et que je doit coder un peu, le problème peut se poser. Et je vais pas changer la configuration des éditeurs d'une autre personne.
        
        Concernant le reste du débat, implicite/explicite, je n'en parle pas. Seulement, l'argument de CrEv m'a fait réagir, parce qu'il part du principe que c'est notre configuration qui est à blâmer, alors que justement, c'est avec une configuration par défaut que le problème va le plus souvent se poser.
        
        Mon éditeur est réglé pour gérer correctement le Python, et j'utilise Tab pour insérer les espace. Quand je dois changer d'éditeur, je me fais avoir au moins une fois. Python se plaint, puis je prend la peine soit de configurer l'éditeur si c'est possible, soit d'user la touche espace un peu plus que la normale (va configurer le notepad de Windows :-°).
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 17 avril 2013 à 11:57. Évalué à 5.
        
        En gros, la règle de base c'est que si tu compares à undefined, null, "", 0, true, false tu dois utiliser === (sinon le résultat n'est pas certain).
        
        D'une part, je comprends pas pourquoi ces valeurs en particulier
        
        Parce qu'il y a conversion implicite de type.
        
        var _ = function(a, b) { console.log(str(a) + (a == b ? " == " : " != ") + str(b)); console.log(str(a) + (a === b ? " === " : " !== ") + str(b)); }; var str = function(a) { if (a === null) { return "null"; } else if (a === undefined) { return "undefined"; } else if (typeof a == "string") { return '"' + a + '"'; } else if (typeof a == "boolean") { return a ? "true" : "false"; } return a; }; _(0, "0"); _(undefined, null); _(0, false); _("", false); _(1, true);
        
        Le résultat donne :
        
        0 == "0" 0 !== "0" undefined == null undefined !== null 0 == false 0 !== false "" == false "" !== false 1 == true 1 !== true
        
        Donc si tu veux tester précisément si ta variable est non initialisée / inexistante ou null tu ne peux pas utiliser ==. Si tu veux tester si tu as une chaine vide ou rien, tu ne peux pas utiliser ==.
        
        Le « pas certain » ne pose en fait pas vraiment de problème, il faut juste comprendre ce qui est vrai et ce qui est faux. Parfois c'est simple, il n'y a qu'un booléen (ou une expression) qui puisse être vrai ou fausse. Parfois c'est un peu plus complexe que ça. C'est comme == / equals en java (enfin le problème n'est pas le même, mais le fait de tester deux choses différentes, mais pas tout le temps)
        
        Les gens qui ont permis des conversion implicites dans les comparaisons doivent être satanistes pour en vouloir autant aux autres développeurs.
        
        Non. Il faut bien voir aussi que ce qui est traité en javascript est, initialement, essentiellement textuel. Par exemple, si je te demande de saisir un entier dans un champ d'une page web, je vais recevoir une chaine de caractère. De la sorte, traiter 0 et "0" de la même manière a du sens puisque initialement tu ne peux pas faire la différence. Cette souplesse a des avantages, et des inconvénients. Il faut juste l'apprendre et l'utiliser à bon escient. Comme toute spécificité d'un langage.
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 17 avril 2013 à 12:07. Évalué à 3.
        
        C'est comme == / equals en java
        
        Sauf qu'en Java et dans la plupart des langages, on se renseigne une fois et ça suffit. En javascript, j'ai beau avoir rencontré 100 fois le problème, je dois toujours me replonger dans la doc pour être sûr.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 17 avril 2013 à 12:24. Évalué à 2.
        
        Pourtant le problème n'a pas changé entre temps hein. Et la réponse non plus puisque c'est tout ce qui est lié à la notion de faux.
        
        Et d'ailleurs tout cela permet d'écrire des trucs sympa, comme les double not :
        
        var plop = function(bla) { if (!!bla) { doSomethingWith(bla); } };
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 17 avril 2013 à 14:04. Évalué à 2.
        
        C++ le mal faisait il y a 10 ans.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par oao le 17 avril 2013 à 18:36. Évalué à 3.
        
        C'est équivalent à
        
        if(bla): pass
        
        en Python, via l'appel de __nonzero__ ou de __bool__ ?
        
        [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 17 avril 2013 à 22:49. Évalué à 2.
        
        Oui, "!!" est sympa lorsqu'on souhaite vraiment manipuler des booléens, mais tu n'as pas choisi un très bon exemple d'utilisation, puisque "if (!!bla)" est équivalent à "if (bla)" :)
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 00:16. Évalué à 2.
        
        Oui, j'ai écris un peu trop vite l'exemple.
        Le but est bien de traiter !!bla comme un booléen.
        
        [^] # Re: Petite question ...
        
        Posté par daeldir le 18 avril 2013 à 08:10. Évalué à 1.
        
        Un petit moyen simple de comprendre/retenir :
        
        == teste une équivalence (42 et "42" sont équivalents en Javascript), === teste une égalité.
        
        Autre astuce : un = en plus signifie plus d'égalité demandée (C'est égal ? Oui, mais… c'est égal ?).
        
        Moi, ça me semble pas compliqué à comprendre… Après, je ne vais pas défendre ce choix (Pourquoi pas un == qui teste l'égalité, et un <=> qui teste l'équivalence ? Ou un = qui teste l'égalité, et un := ou <- pour l'assignation ?). Le typage implicite du Javascript peut poser d'autres problèmes ("a" + 2 + 5 === "a25", mais 2 + 5 + "a" == "7a"), et en soit, Javascript est plein de bizarreries (voir wat cité dans un autre commentaire, mais aussi wtfjs).
        
        [^] # Re: Petite question ...
        
        Posté par lolop (site web personnel) le 18 avril 2013 à 08:47. Évalué à 5.
        
        ("a" + 2 + 5 === "a25", mais 2 + 5 + "a" == "7a")
        
        Je ne suis pas développeur JavaScript, mais si on considère un transtypage automatique d'entier vers chaîne et une évaluation de gauche à droite des opérateurs arithmétiques de même niveau, ça paraît cohérent.
        
        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
        
        [^] # Re: Petite question ...
        
        Posté par daeldir le 18 avril 2013 à 12:10. Évalué à 2.
        
        Oh oui, c'est cohérent… Ça n'empêche pas de se faire avoir sur des versions plus complexes de ce genre d'opération ! (J'ai beau le savoir, je me fait encore avoir, parfois… Je trouve vite d'où ça vient, mais ça m'arrive plus souvent que de confondre == et ===)
        
        [^] # Re: Petite question ...
        
        Posté par barmic le 18 avril 2013 à 09:43. Évalué à 2.
        
        Le « pas certain » ne pose en fait pas vraiment de problème, il faut juste comprendre ce qui est vrai et ce qui est faux.
        
        Je ne sais pas si ton exemple est incomplet ou pas, mais il semble juste que == fait une comparaison avec transtypage alors que ===, non. Je en vois pas ce qu'il y a d'incertain. À part si ça viens de la gestion du undefined.
        
        Parfois c'est simple, il n'y a qu'un booléen (ou une expression) qui puisse être vrai ou fausse. Parfois c'est un peu plus complexe que ça. C'est comme == / equals en java (enfin le problème n'est pas le même, mais le fait de tester deux choses différentes, mais pas tout le temps).
        
        En Java tu dois savoir que tu manipule des références et ce qu'est la programmation orientée objet. C'est peut être compliqué mais c'est 2 des notions importantes du langage dont tout découle de manière assez cohérente.
        
        Non. Il faut bien voir aussi que ce qui est traité en javascript est, initialement, essentiellement textuel. Par exemple, si je te demande de saisir un entier dans un champ d'une page web, je vais recevoir une chaine de caractère. De la sorte, traiter 0 et "0" de la même manière a du sens puisque initialement tu ne peux pas faire la différence. Cette souplesse a des avantages, et des inconvénients. Il faut juste l'apprendre et l'utiliser à bon escient. Comme toute spécificité d'un langage.
        
        C'est une fausse excuse. Le shell aussi ne traite que des chaines de caractères et il s'en sort de manière trivial. Il faut avoir une gestion du typage en rapport avec ce que tu traite et ce que tu veux donner comme possibilité.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Petite question ...
        
        Posté par groumly le 18 avril 2013 à 05:18. Évalué à 4.
        
        La difference c'est que java est coherent.
        
        == est herite du c, et fait exactement la meme chose: est ce que les pointeurs sont egaux, un simple test numerique
        
        equals vit dans le monde objet. C'est une methode sur un objet. 2.equals("la bite a jojo") ne marche pas (remarque, je sais meme pas avec cet autoboxing a la con….). Dns l'autre sens c'etait vrai jusqu'a ce que cet auto boxing a la con vienne mettre le bordel. Null.equals("oula oula oulala") va te peter a la gueule (logiquement). De meme, equals n'est pas un mot cle du langage, juste une methode, qui, il se trouve, est declaree sur Object, donc disponible partout.
        
        Javascript d'une part change la semantique de == par rapport au c (desole, mais non 0 == "0" n'a aucune bonne raison de retourner true), mais rajoute un operateur qui y ressemble beuacoup. C'est quoi ===? Vraiment egal, pour de vrai?
        Quand au double not plus bas, c'est quoi? Vraiment pas egal du tout, meme pas un peu?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 18 avril 2013 à 08:11. Évalué à 2.
        
        Quand au double not plus bas, c'est quoi? Vraiment pas egal du tout, meme pas un peu?
        
        Tu touches du doigt les petits problèmes de cohérence dont je parlais au début.
        
        "!" inverse la conversion booléenne d'une valeur.
        "!!val" est à comprendre comme "!" de "!val" , donc inverse l'inversion; c'est un raccourci syntaxique pour transformer n'importe quelle valeur dans son "équivalent booléen".
        Mais c'est sûr qu'on pourrait s'attendre à "vraiment pas égal du tout", après avoir vu le "==="….
        
        [^] # Re: Petite question ...
        
        Posté par groumly le 18 avril 2013 à 09:23. Évalué à 2.
        
        donc not(not(something) n'est pas forcement egal a something?
        Ben c'est du propre dis donc.
        
        Cela dit, j'ai rien contre javascript, pour ce que j'en connais (peu, mais j'ai bouffe des kilos d'ActionScript 3) ca me parait un langage plutot pratique dans son cas d'usage et le cote prototype est plutot pas mal du tout. Niveau coherence c'est un gros bordel par contre…
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 09:29. Évalué à 1.
        
        donc not(not(something) n'est pas forcement egal a something?
        Ben c'est du propre dis donc.
        
        Ben oui, et c'est le cas dans beaucoup de langages.
        Dans beaucoup on définit ce qui a une valeur de faux.
        Mais une valeur de faux n'est pas forcément "false" pour autant.
        
        Donc en javascript 0, "", null, undefined ont tous une valeur de faux.
        Donc ! donne vrai
        Donc !! donne faux <- le bool false
        
        Donc on peut ensuite tester des égalités (strictes) dessus.
        Mon exemple était en effet très mal choisi.
        En général, on va transformer un argument en booléen (pour savoir si une valeur non fausse a été envoyée). Et ensuite on va tester ce booléén, pour un booléen, réellement. Sans se soucier de savoir si la valeur était fausse, si c'était non renseigné, etc.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 09:35. Évalué à 1.
        
        desole, mais non 0 == "0" n'a aucune bonne raison de retourner true
        
        Ben faut croire que ça l'est pour des gens qui créent des langages pourtant.
        Et dans un contexte orienté texte, il y a une bonne raison de le faire.
        On peut trouver ça bien ou pas, mais c'est pas un oubli, c'est volontaire ça. Donc oui il y a une bonne raison de retourner true.
        
        En général === ça veut dire strictement égal. C'est à dire égalité de valeur (0 et "0") sont égaux si on prend juste leur valeur) et égalité de type (number vs string)
        
        (et d'ailleurs javascript n'est pas le seul langage avec un ===)
        
        Le double not c'est, justement, une double négation. C'est !(!bla).
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 18 avril 2013 à 09:42. Évalué à 3.
        
        Ben faut croire que ça l'est pour des gens qui créent des langages pourtant.
        
        Il faut croire que non vu le succès des langages qui compilent vers du javascript. Si javascript était un bon langage, on n'aurait pas besoin de faire ça.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 18 avril 2013 à 09:45. Évalué à 1.
        
        Il faut croire que non vu le succès des langages qui compilent vers du javascript.
        
        Tu triches un peu, par exemple, le but principal de emscripten est de supporter l'existant, pas de se mettre à écrire from scratch des programmes en C dans le but de les compiler en JavaScript. (à ma connaissance, en tout cas)
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 18 avril 2013 à 09:50. Évalué à 5.
        
        Je pensais surtout à Darts, Typescript, gwt, Pyjs, Coffescript…
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 09:51. Évalué à 3.
        
        Faut voir…
        
        Dart ? Principalement pour un problème de performance et d'optimisation
        TypeScript ? En effet, là c'est beaucoup relatif au typage
        CoffeeScript ? En gros il voudrait du ruby dans les navigateurs
        
        Maintenant si beaucoup de dev arrivaient à penser autrement que par classe (prototype) et autrement que à travers jQuery ça aiderait pas mal.
        
        Je ne dis pas que le javascript est bien fait, loin de là. Il y a pas mal de casseroles qui trainent. Il y a des incohérences, des choses étranges. Des choses que je n'aime pas du tout. Et je me suis planté, comme tout le monde, sur des égalité undefined / null par exemple. Mais c'est loin d'être insurmontable. Tous les langages ont des trucs étranges. Mais j'ai surtout l'impression que beaucoup de monde fait du javascript à contre coeur, parce qu'ils sont obligés (oué enfin, vous êtes obligé à rien…) et qu'ils ne font pas du tout l'effort de chercher à apprendre.
        Tu le dis toi même : j'ai rencontré le problème 100 fois et je m'en souviens toujours pas. Tu cherches vraiment à t'en souvenir ?
        
        Donc bon, oui il y a des choses bien naze en js. Mais == / === n'est qu'une spécificité d'un langage, beaucoup plus simple, par exemple, que la gestion des pointeurs, la gestion de la mémoire, etc.
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 18 avril 2013 à 09:57. Évalué à 2.
        
        On ne peut pas faire:
        
        <script type="text/${mon langage préféré}">
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 10:03. Évalué à 2.
        
        faut voir. Tu peux faire text/javascript, text/vbscript, text/dart, text/ruby
        
        (bon, de tête, les noms sont peut-être pas exactes)
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 18 avril 2013 à 10:26. Évalué à 2.
        
        Oui enfin, ça ne marche que chez moins de 0.01% des utilisateurs…
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 11:24. Évalué à 2.
        
        Et quand bien même. Tu n'as qu'à le compiler en js alors, il est où le problème ?
        En fait, même le js se compile en js (et je parle pas asm.js). C'est d'ailleurs la solution pour avoir des perfs meilleurs avec une lisibilité correcte (et donc sans passer par des intermédiaires type dart, coffee ou autre)
        
        Et sinon, ben il te reste à aider les développeurs de browser pour supporter d'autres langages.
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 18 avril 2013 à 11:49. Évalué à 1.
        
        Tu n'as qu'à le compiler en js alors, il est où le problème ?
        
        On a un langage mauvais et lent.
        
        Pour ne pas l'utiliser, on s'en sert comme d'un assembleur.
        
        Le résultat est toujours mauvais et lent.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 11:55. Évalué à 3.
        
        On a un langage mauvais et lent
        
        Ha oui, pour faire tourner un jeu 3D dans un navigateur c'est lent.
        Heu…
        C'est vraiment le problème ça ?
        Pour faire ce qu'on lui demande initialement, il n'y a pas tant de problème de perf que ça (les problèmes de perfs se résolvent souvent par un meilleur usage de http par exemple)
        
        Mais le côté mauvais, moi je dirais un peu comme java, avec son modèle objet qui casse franchement pas trois pates à un canard…
        
        Pour ne pas l'utiliser, on s'en sert comme d'un assembleur.
        
        Ca c'est récent tout de même… Et pour faire du jeux vidéo oui. Mais pour beaucoup de choses c'est loin d'être nécessaire.
        
        Quand je parle de compiler, c'est js vers js, pas js vers asm.js
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 18 avril 2013 à 12:02. Évalué à 1.
        
        C'est vraiment le problème ça ?
        
        Oui! Malheureusement le oueb est la plateforme de jeu casual d'aujourd'hui et [mode nostradamus] sera la plateforme de jeu de jeu tout court de demain [/mode nostradamus].
        
        Je le regrette, mais je vois mal l'industrie s'orienter vers autre chose.
        
        Mais le côté mauvais, moi je dirais un peu comme java, avec son modèle objet qui casse franchement pas trois pates à un canard…
        
        Sauf que côté serveur ou desktop, tu as le choix des armes. Si tu n'aimes pas java, tu n'es pas forcé de l'utiliser ou de t'en servir comme assembleur.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 12:26. Évalué à 2.
        
        C'est vraiment le problème ça ?
        
        Oui!
        
        Ben je vois toujours pas le problème. On ne te demande pas de faire des jeux en js, on compile simplement ton jeu en js. Idem si tu fais du flash, du java, du c++ (faut bien le compiler), du .Net ou autre. Et dans ce cas, le fait que js pose problème à certains à cause de == et === c'est vraiment le dernier des soucis puisque tu ne l'utilises pas directement.
        
        Sauf que côté serveur ou desktop, tu as le choix des armes. Si tu n'aimes pas java, tu n'es pas forcé de l'utiliser ou de t'en servir comme assembleur.
        
        Non, c'est vrai. En fait tu utilise le bytecode de la jvm comme assembleur.
        Tu n'exécutes pas de java, du compile du java en bytecode et tu l'utilises. Et d'ailleurs c'est la même chose avec groovy ou scala.
        
        Ben là faut juste dire que le bytecode c'est asm.js. Et dans ce cas, faire du java, groovy ou scala et l'exécuter sur une jvm c'est comme faire du javascript, du coffeescript, du dart et l'exécuter sur un moteur js.
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 18 avril 2013 à 12:49. Évalué à 3.
        
        Ben je vois toujours pas le problème
        
        La performance, l'occupation mémoire et la debuggabilité.
        
        Non, c'est vrai. En fait tu utilise le bytecode de la jvm comme assembleur.
        
        Ben non, si je fais du python, c'est l'un des interpréteurs python, si je fais du Go ou du C, c'est du natif. Bref on a le choix, donc l'argument c'est pareil en java ne tient pas puisqu'on n'est pas obligé d'en faire.
        
        Sur le web, on est forcé de passer par un langage unique. S'il est mauvais, il pourrit toute la chaîne.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 18 avril 2013 à 12:00. Évalué à 5.
        
        On a un langage mauvais et lent.
        
        C'est bien, ça fait vachement avancer le débat ça.
        
        [^] # Re: Petite question ...
        
        Posté par devnewton 🍺 (site web personnel) le 18 avril 2013 à 12:05. Évalué à 1.
        
        Je ne vois pas l'intérêt de nier les défauts de javascript.
        
        J'utilise quotidiennement java, python et c++. Ca ne me viendrait pas à l'idée de nier que des problèmes comme la bloat attitude, l'absence de typage ou la lenteur de compilation.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Petite question ...
        
        Posté par CrEv (site web personnel) le 18 avril 2013 à 12:28. Évalué à 1.
        
        Je ne vois pas l'intérêt de nier les défauts de javascript.
        
        C'est pas une histoire de nier, c'est juste que tu ne fais rien avancer en disant "c'est mauvais".
        
        Java aussi est mauvais et lent (enfin moins lent aujourd'hui c'est vrai). Ha tiens, comme js.
        
        Ok, C++ est rapide (pas à compiler). Mais mauvais.
        
        Bon, avec tout ça on a vraiment bien avancé, non ?
  - [^] # Re: Petite question ...
    
    Posté par totof2000 le 16 avril 2013 à 15:33. Évalué à 3.
    
    Je ne vois pas en quoi utiliser JS est gênant.
    
    Ca peut être gênant lorsqu'on travaille sur des projets assez conséquents, pour peu qu'on manque un peu de rigueur (comme en PHP ou en Perl par exemple). J'ai peur de voir sur les desktops les mêmes horreurs que celles que l'on voit sur les sites www.
    
    le but ici, si j'ai bien compris, c'est de proposer un environnement de développement pour l'UI, plus simple que C++. Donc il faut un langage plus simple, moins complexe que C++. Et pour moi JS est idéal. Tu fais de l'objet sans t'embêter avec la gestion de pointeurs, de template ou de je ne sais quoi d'autres.
    
    On perd l'encapsulation qui peut poser problème.
    - [^] # Re: Petite question ...
      
      Posté par Laurent J (site web personnel, Mastodon) le 16 avril 2013 à 15:47. Évalué à 2.
      
      pour peu qu'on manque un peu de rigueur
      
      C'est aussi très facile de faire des trucs crad en C++ ou en python…
      
      J'ai peur de voir sur les desktops les mêmes horreurs que celles que l'on voit sur les sites www.
      
      Ce n'est pas le même contexte, pas le même environnement, pas les mêmes possibilités. Bref, pas les même API… Tu as déjà codé en JS dans des sandbox, en dehors du web, par exemple avec NodeJS, PhantomJS (ou SlimerJS :-)) etc.. ?
      - [^] # Re: Petite question ...
        
        Posté par totof2000 le 16 avril 2013 à 16:17. Évalué à 2.
        
        C'est aussi très facile de faire des trucs crad en C++ ou en python…
        
        Certainement mais un des points forts de l'encapsulation est de pouvoir gérer ta saleté dans ton coin, et de ne pas permettre aux autres de mettre le nez dans celle-ci (et vice-versa) en obligeant à passer par des interfaces.
        
        Ce n'est pas le même contexte, pas le même environnement, pas les mêmes possibilités. Bref, pas les même API…
        
        Ce n'est pas un problème d'API mais un problème de langage. Est-ce qu'il y aurait une version de Javascript qui intègre l'encapsulation de manière native par exemple ?
        
        Tu as déjà codé en JS dans des sandbox, en dehors du web, par exemple avec NodeJS, PhantomJS (ou SlimerJS :-)) etc.. ?
        
        Non, et je réitère ma question ci-dessus.
        
        [^] # Re: Petite question ...
        
        Posté par Laurent J (site web personnel, Mastodon) le 16 avril 2013 à 16:37. Évalué à 3.
        
        Est-ce qu'il y aurait une version de Javascript qui intègre l'encapsulation de manière native par exemple ?
        
        Oui, les versions récentes des moteurs JS qui implémentent Ecmascript 5, grâce à certaines méthodes de Object, avec lesquels tu peux indiquer si une propriété est "visible", en lecture seules, "enumerable" etc…
        
        Et sinon y a moyen de cacher la saleté de manière plus classique en jouant avec les scopes (exemple ).
        
        Si on comprend et maitrise la "philosophie" objet de JS, y a moyen de faire pas mal de chose.
        
        [^] # Re: Petite question ...
        
        Posté par Guillaume Denry (site web personnel) le 16 avril 2013 à 16:49. Évalué à 2.
        
        Et sinon y a moyen de cacher la saleté de manière plus classique en jouant avec les scopes (exemple ).
        
        Justement, je n'ai jamais réussi à faire vraiment des membres privés de façon très souple en JavaScript.
        Dès qu'on souhaite utiliser "prototype" pour optimiser les choses (ne plus déclarer les fonctions dans le constructeur), on est un peu eu car tout ce qui est dans prototype est publique.
        
        Si tu as une solution (avec le javascript des navigateurs), ça m'intéresse…
    - [^] # Re: Petite question ...
      
      Posté par CrEv (site web personnel) le 16 avril 2013 à 16:32. Évalué à 2.
      
      Je ne vois pas en quoi utiliser JS est gênant.
      
      Ca peut être gênant lorsqu'on travaille sur des projets assez conséquents, pour peu qu'on manque un peu de rigueur
      
      Ha oué. Enfin là c'est pareil partout, si tu écris du code de merde ça restera du code de merde, quel qu'en soit le langage.
      - [^] # Re: Petite question ...
        
        Posté par totof2000 le 16 avril 2013 à 17:17. Évalué à 9.
        
        Disons que certains langages permettent plus facilement le n'importe quoi que d'autres, et certais langages te laissent ton n'importe quoi à toi et empêche les autres d'y mettre le nez (et vice-versa).
        
        Sinon, pour prendre une autre extrême, il est bien plus difficile de faire n'importe quoi en Ada par exemple qu'en JS ou en Perl … ( mais je suis d'accord sur le fait que la rigueuer Ada n'est pas indispensable pour tous les projets).
  - [^] # Re: Petite question ...
    
    Posté par devnewton 🍺 (site web personnel) le 16 avril 2013 à 15:48. Évalué à 0.
    
    Je ne vois pas en quoi utiliser JS est gênant. Surtout que le but ici, si j'ai bien compris, c'est de proposer un environnement de développement pour l'UI, plus simple que C++.
    
    Deux mauvais langages ensembles, ça ne fait un bon langage.
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: Petite question ...
  
  Posté par oao le 16 avril 2013 à 20:13. Évalué à 8. Dernière modification le 16 avril 2013 à 20:14.
  
  Ce n'est pas un problème. On va coder dans un langage tiers, qui va être compilé en asmjs, qui va être compilé puis exécuté dans la machine virtuel, et qui va pouvoir interagir avec ton application. C'est plus simple comme ça.
# Un nouveau moteur JS - good news

Posté par Laurent J (site web personnel, Mastodon) le 16 avril 2013 à 15:37. Évalué à 7.

Sympa qu'il y ait un nouveau moteur JS pour le standard EcmasScript.

Bonne chance toutefois pour qu'ils rattrapent les perfs de V8 ou de SpiderMonkey, c'est loin d'être simple.
(les deux ont maintenant des perfs quasi équivalentes, depuis quelques jours avec Baseline dans SpiderMonkey ).

Baseline arrive un peu tard pour Qt. Dommage parce que SpiderMonkey a l'avantage sur V8 d'avoir une partie d'Ecmascript 6 implémenté :-)