Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?

Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 08:47. Modéré par Xavier Teyssier. Licence CC By‑SA.

Étiquettes :

oct.

2011

Google a publié une première version, dite « preview release », de son nouveau langage de programmation : Dart. Google espère que ce langage va remplacer JavaScript comme langage de référence dans les navigateurs.

Un mémo interne qui a fuité nous informe des intentions de Google. Les ingénieurs de Google, et tout particulièrement l’équipe travaillant sur V8, considèrent que le JavaScript est une impasse : il serait trop lent, très mal adapté pour des développements de grande taille et souffrirait d’erreurs de jeunesse irréparables. Google a donc décidé de proposer son propre langage, Dart, dont la première version vient tout juste de sortir.

Pour le moment, les programmes écrits en Dart peuvent être compilés en JavaScript pour tourner dans les navigateurs. D’ici peu, Chrome devrait être en mesure d’exécuter directement du code en Dart, étape nécessaire pour des performances accrues. Les plans de Google sont ensuite de proposer son moteur aux développeurs des autres navigateurs, mais il semble peu probable dans l’immédiat que ceux‐ci acceptent.

Dart se distingue de JavaScript par :

le typage statique optionnel ;
les classes et interfaces (par opposition aux prototypes du JS) ;
l’obligation d’utiliser les « ; » pour séparer les instructions ;
une bibliothèque standard plus riche ;
la possibilité d’être outillé plus facilement (meilleure prise en charge pour l’IDE et outils de ré‐usinage par exemple).

Pour autant, Dart a reçu un accueil très froid de la part des développeurs. Par exemple, Brendan Eich, le créateur de JavaScript, considère qu’il est plus simple et plus efficace de faire évoluer le JavaScript que de développer un nouveau langage.

Pour ma part, je trouve l’annonce de Dart très décevante. Google a visiblement développé un langage qui correspond à ses besoins (permettre de développer des applications comme GMail ou Google Maps), et en a perdu de vue le plus important : convaincre les autres navigateurs d’accepter Dart. Nombreuses sont les tentatives pour proposer une alternative sérieuse au JS dans les navigateurs, mais aucune n’a encore réussi, faute d’une prise en charge efficace dans plusieurs navigateurs.

La syntaxe est très décevante : elle est fortement inspirée de Java et C#, et paraîtra rebutante aux développeurs habitués à celle des langages dynamiques comme Ruby, Python ou encore… JavaScript ! Ça me paraît absurde qu’un langage sortant en 2011, impose encore la présence de « ; » pour séparer les instructions se trouvant sur des lignes séparées.

Le typage statique optionnel est probablement une bonne chose pour le développement d’applications avec une équipe composée de nombreux développeurs, mais cela ne concerne qu’une minorité des développeurs actuels de JavaScript. Et surtout, cela ne justifie absolument pas de créer un nouveau langage : il aurait été possible d’intégrer cela dans une future version de JavaScript.

Les classes sont la bienvenue. Elles correspondent bien mieux aux habitudes des développeurs que les prototypes. Mais CoffeeScript propose cela depuis longtemps, et avec une syntaxe bien plus réussie.

Même chose pour la bibliothèque standard : ça existe déjà et cela pourrait être facilement intégré dans JavaScript.

La question des performances reste en suspens. Pour le moment, il n’y a pas d’améliorations par rapport à du JavaScript, pour la simple raison que le seul moyen d’exécuter du code Dart, est de compiler en JavaScript. Quand Chrome sera capable d’exécuter nativement du code Dart, cela pourrait changer la donne (en tout cas, c’est ce que pensent les développeurs de V8).

Pour autant, tout n’est pas négatif. Il est par exemple intéressant de voir que Google propose un modèle d’Actors dans Dart : Isolate. Mais je doute fort que cela suffise pour imposer Dart comme langage dans les navigateurs.

Aller plus loin

L’annonce de Dart par Google (414 clics)
Le site officiel de Dart (844 clics)
Dart, le Visual Basic du Web ? (292 clics)
Javascript Nowhere (223 clics)

# Mode vendredi

Posté par Maclag le 11 octobre 2011 à 08:55. Évalué à 6.

En voilà un article qui va susciter de nombreuses réactions toutes plus pertinentes les-unes que les-autres!

Et vous, c'est quoi pour vous le meilleur langage pour remplacer JS?
- [^] # Re: Mode vendredi
  
  Posté par ʭ ☯ le 11 octobre 2011 à 09:09. Évalué à -3.
  
  C'est quoi JS? Parce que de toute manière, Dart ne va pas remplacer JScript...
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
  - [^] # Re: Mode vendredi
    
    Posté par Gui13 (site web personnel) le 11 octobre 2011 à 09:23. Évalué à 10.
    
    Franchement, quitte à remplacer JavaScript, je choisirais Python ou Ruby, qui sont plus concis et plus faciles à appréhender.
    
    On pourrait les modifier pour les rendre moins sensibles à l'indentation et comme des implémentations existent avec du JIT, les perfs seraient très sympathique!
    - [^] # Re: Mode vendredi
      
      Posté par collinm (site web personnel) le 11 octobre 2011 à 10:00. Évalué à 2.
      
      niveau lisibilité c'est pas toujours ça...
      
      www.solutions-norenda.com
    - [^] # Re: Mode vendredi
      
      Posté par barmic le 11 octobre 2011 à 10:04. Évalué à 5.
      
      Au lieu de prendre des montres comme eux, moi je serais plutôt allé vers lua. Simple à implémenté, pas mauvais d'un point de vu perf, simple à utiliser.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Mode vendredi
        
        Posté par Guillaume Denry (site web personnel) le 11 octobre 2011 à 10:32. Évalué à 2.
        
        Lua c'est comme JavaScript : paye ta ré-écriture du paradigme objet, héritage, etc.
        Et puis pour gérer de gros projets en équipe....
      - [^] # Re: Mode vendredi
        
        Posté par drakmaniso le 11 octobre 2011 à 14:02. Évalué à 8.
        
        J'adore Lua, parmi les langages modernes je trouve que c'est l'un des plus élégants. Mais je ne pense pas que ce soit un bon choix pour le web, car il souffre du même handicap que son aïeul, Forth. Il a tendance à amplifier le talent des développeurs: un bon programmeur va faire des merveilles, mais un médiocre (en Lua, s'entend) va probablement pondre une bouillie infâme. Et étant donné le niveau d'un certain nombre de dévs web, on court à la catastrophe…
        
        Par contre, amha Lua aurait été un choix parfait pour les environnements de bureau, en lieu et place de Javascript.
    - [^] # Re: Mode vendredi
      
      Posté par banks_the_megalith (site web personnel) le 11 octobre 2011 à 10:13. Évalué à 3.
      
      Contrairement à Python, Ruby n'est pas sensible à l'indentation...
      - [^] # Re: Mode vendredi
        
        Posté par zebra3 le 11 octobre 2011 à 11:19. Évalué à 1.
        
        En quoi serait-ce un défaut ?
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Mode vendredi
        
        Posté par Tom le 11 octobre 2011 à 11:33. Évalué à 3.
        
        Il répondait à
        
        [...] On pourrait les modifier pour les rendre moins sensibles à l'indentation [...]
        
        [^] # Re: Mode vendredi
        
        Posté par barmic le 11 octobre 2011 à 11:44. Évalué à 5.
        
        Pour le web c'est un défaut. Quand tu fait beaucoup de javascript il est utile d'avoir des outils pour réduire la taille des fichiers pour les envoyer (suppressions des commentaires, retrait des retour à la ligne 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: Mode vendredi
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 octobre 2011 à 11:54. Évalué à 3.
        
        man gzip… Compresser des documents en les obfusquant est une connerie, depuis on a inventé des algorithmes de compression
        
        [^] # Re: Mode vendredi
        
        Posté par oinkoink_daotter le 11 octobre 2011 à 11:58. Évalué à 3.
        
        Ou pas, puisque c'est fait (ptet que google s'est posé la question avant d'obfuscer son javascript). Le gzip pour compresser les documents, c'est déjà fait par les serveurs web (pour peu que les deux pairs soient capables de l’interpréter) au moment du téléchargement du fichier.
        
        [^] # Re: Mode vendredi
        
        Posté par Etienne Bagnoud (site web personnel) le 11 octobre 2011 à 12:25. Évalué à 4.
        
        Je suis pas certain, ça devient opaque pour l'être humain, mais le parser javascript ne verra pas de différence, donc l'impacte sur les performances est nul. Avec la compression tu as le temps de décompression qui s'ajoute. Même si c'est minime, ce n'est pas forcément négligeable.
        
        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
        
        [^] # Re: Mode vendredi
        
        Posté par Jean B le 11 octobre 2011 à 13:07. Évalué à 10.
        
        Sur le principe je suis tout à fait d'accord avec toi, cependant un petit exemple:
        
        jquery-1.6.4.js.gz -> 67K
        
        jquery-1.6.4.min.js.gz -> 31K
        
        Bref, c'est naze mais efficace.
        
        [^] # Re: Mode vendredi
        
        Posté par barmic le 11 octobre 2011 à 13:37. Évalué à 0.
        
        Ils seront heureux les utilisateurs de téléphones Android de voir leur batteries s'épuiser à décompresser du gzip. Minifier n'a aucun impact sur les performance coté utilisateur.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mode vendredi
        
        Posté par CrEv (site web personnel) le 11 octobre 2011 à 13:50. Évalué à 10.
        
        Merci de montrer ta totale non connaissance du problème.
        
        Compresser des documents en les obfusquant
        
        Le but n'est pas de les obusquer mais de les rendre beaucoup, beaucoup moins verbeux
        
        depuis on a inventé des algorithmes de compression
        
        Et ça fait belle lurette que et les serveurs et les navigateurs savent le lire / écrire
        
        J'ai fait récemment quelques tests de js (compilation et compression). Voici les résultats :
        
        version initiale : 1,2Mo
        
        GZIP : 0,44
        
        compilée : 0,6
        
        compilée + GZIP : 0,225
        
        Ho mince, si je compile en plus de gzip je suis deux fois plus petit. Cool non ?
        Et contrairement au commentaire plus bas, surtout sur un mobile avec une connexion pas spécialement efficace, il vaut mieux laisser le navigateur décompresser tout en ayant un faible transfert que le contraire.
        
        [^] # Re: Mode vendredi
        
        Posté par tyoup le 12 octobre 2011 à 08:07. Évalué à 2.
        
        Oui et quand on a un mobile, un fichier js qui pèse 1,2Mo devient une arme de crime...
        Ok... JeSors
        
        [^] # Re: Mode vendredi
        
        Posté par zebra3 le 11 octobre 2011 à 11:59. Évalué à 3.
        
        SPDY a justement été conçu pour pallier à ce problème, et même HTTP peut utiliser la compression via gzip.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Mode vendredi
        
        Posté par Jonathan Marchand le 11 octobre 2011 à 13:19. Évalué à 4.
        
        SPDY a justement été conçu pour pallier à ce problème, et même HTTP peut utiliser la compression via gzip.
        
        [^] # Re: Mode vendredi
        
        Posté par Grunt le 11 octobre 2011 à 13:35. Évalué à 0.
        
        Suicide, tu veux?
        
        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
- [^] # Re: Mode vendredi
  
  Posté par Grunt le 11 octobre 2011 à 10:38. Évalué à 9.
  
  Et vous, c'est quoi pour vous le meilleur langage pour remplacer JS?
  
  C'est rien. Et si on peut virer JS ça serait chouette. Que le Web redevienne un gopher un peu évolué, pas un espèce de bloat dégueulasse.
  
  À mort le Web 2.0, vivent Internet et tout ses protocoles.
  
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
  - [^] # Re: Mode vendredi
    
    Posté par Guillaume Denry (site web personnel) le 11 octobre 2011 à 10:41. Évalué à 9.
    
    Tu rêves. Les gens ont goûté à l'utilisation d'applications sans installation, ils ne reviendront jamais en arrière.
    - [^] # Re: Mode vendredi
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 octobre 2011 à 10:53. Évalué à 9.
      
      Porte nawak. Les gens en question sont les mêmes qui installent du natif à tire-larigot sur leurs ordiphones.
      - [^] # Re: Mode vendredi
        
        Posté par Guillaume Denry (site web personnel) le 11 octobre 2011 à 11:00. Évalué à 6.
        
        Je t'ai pertinenté car c'est un aspect que je n'ai effectivement pas pris en compte dans ma réflexion et j'ai écris trop vite.
      - [^] # Re: Mode vendredi
        
        Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 11 octobre 2011 à 13:29. Évalué à 4.
        
        Mais ne va t'on pas se retrouver à attendre à nouveau qu'on développe des clients natifs Linux proprios, en retard sur les autres et mal supportés ?
        
        C'est une description caricaturale, certes, mais quand je vois la Mozilla et compagnie redoubler d'efforts pour permettre de faire des applis web lisibles dans ~~Safari iOS~~ n'importe quel navigateur moderne et de s'affranchir des stores, c'est peut-être que quelque part, le Web 2.0 a du bon, tout bloaté qu'il soit.
        
        [^] # Re: Mode vendredi
        
        Posté par lasher le 11 octobre 2011 à 14:41. Évalué à 5.
        
        Puisqu'on en est à corriger les fautes...
        On dit « Mais ne va-t-on pas ». On rajoute le « t » (et ses potes les traits d'union) pour des raisons phonétique de liaison. Alors que je n'ai toujours pas compris quelle était la logique derrière l'apostrophe.
        
        [^] # Re: Mode vendredi
        
        Posté par bilboa le 12 octobre 2011 à 00:13. Évalué à 3.
        
        C'est clair que ca à l'avantage d'avoir enfin du vrai "write once, run everywhere".
        Du tel à l'ordi, peut importe l'OS. Finalement, les applis web c'est pas si mal, parce-que java & co ca à pas trop réussi.
    - [^] # Re: Mode vendredi
      
      Posté par Grunt le 11 octobre 2011 à 11:27. Évalué à 9.
      
      T'as jamais vu un Windows se lancer chez un user moyen, avec la trayicon remplie de trucs, et le bureau et le menu démarrer plein de raccourcis?
      
      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
      - [^] # Re: Mode vendredi
        
        Posté par zebra3 le 11 octobre 2011 à 12:01. Évalué à 10.
        
        À leur décharge, c'est déjà le cas la première fois qu'ils démarrent l'ordinateur, avec toutes les saloperies préinstallées par le constructeur...
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Mode vendredi
        
        Posté par Jux (site web personnel) le 11 octobre 2011 à 13:12. Évalué à 6.
        
        C'est même le cas sur Android maintenant. J'ai acheté un nouveau téléphone HTC récemment et j'ai 10 applications "HTC foo", "HTC bar" qui font tout et n'importe quoi mais qui ne vont pas faire long feu.
        
        [^] # Re: Mode vendredi
        
        Posté par Raphaël G. (site web personnel) le 11 octobre 2011 à 21:36. Évalué à 1.
        
        C'est même pire sur certains autres, après une mise à jour de ma rom j'ai retrouvé des applications de foot installées sur mon xperia arc...
        (ne jamais hésiter à remplacer la rom de votre opérateur par la générique, il cesse d'être une brique volante après)
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 11 octobre 2011 à 11:25. Évalué à 10.
    
    Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Mode vendredi
      
      Posté par __o le 12 octobre 2011 à 13:25. Évalué à 3.
      
      Si tout ton PC rame parce qu'un processus part dans une boucle infinie, change de kernel.
- [^] # Re: Mode vendredi
  
  Posté par devnewton 🍺 (site web personnel) le 11 octobre 2011 à 10:46. Évalué à 2.
  
  Dart est un nième clone de Java. Je ne comprends pas pourquoi ils n'ont pas réutilisé Groovy ou Beanshell...
  
  Ils auraient aussi pu prendre Google Go pour être plus innovant.
  
  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: Mode vendredi
    
    Posté par CrEv (site web personnel) le 11 octobre 2011 à 10:56. Évalué à 4.
    
    Oué, sauf que Google Go est volontairement axé sur du bas niveau, un remplaçant à C plus qu'autre chose.
    Et donc en aucun cas un bon langage de script pour un navigateur.
    
    Ils n'auraient pas été innovant ils auraient été con.
    - [^] # Re: Mode vendredi
      
      Posté par Elfir3 le 11 octobre 2011 à 11:14. Évalué à 4.
      
      J'ai toujours eu du mal à comprendre le problème que ça poserait d'utiliser le même langage et en se passant juste des lib les plus pas niveau (ou en modifiant leur comportement). Ça éviterait d'avoir à réapprendre la syntaxe à chaque coup.
      
      Bref, quelqu'un peut m'éclairer ?
    - [^] # Re: Mode vendredi
      
      Posté par devnewton 🍺 (site web personnel) le 11 octobre 2011 à 12:04. Évalué à 4.
      
      C'est quoi un bon langage de script?
      
      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: Mode vendredi
        
        Posté par CrEv (site web personnel) le 11 octobre 2011 à 13:51. Évalué à 1.
        
        C'est déjà pas Go, qui est en langage compilé (même s'il existe des gruges)
        
        Et surtout c'est pas un langage bas niveau, absolument pas (on parle quand même de web là)
        
        [^] # Re: Mode vendredi
        
        Posté par devnewton 🍺 (site web personnel) le 11 octobre 2011 à 14:42. Évalué à 2.
        
        C'est déjà pas Go, qui est en langage compilé (même s'il existe des gruges)
        
        Et qu'est-ce qui empêche d'écrire un interpréteur?
        
        Et surtout c'est pas un langage bas niveau, absolument pas (on parle quand même de web là)
        
        Quelle friture de haut niveau est-ce qu'il manque par rapport à Dart?
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: Mode vendredi
        
        Posté par El Titi le 11 octobre 2011 à 15:18. Évalué à 5.
        
        Un langage de script où y'a pas marqué Java dans le nom
        (DLFP subculture inside)
# C'est Dart-y, mon kiki ! \o/

Posté par windu.2b le 11 octobre 2011 à 09:08. Évalué à 10.

Une nouvelle guerre des navigateurs se prépare, avec ses benchmarks foireux, ses trolls, ses anti et pro-machin, ses flamewares... Et IE qui sera toujours à la traine. j'en salive d'avance ! :popcorn:
# Besoin du support de tous ?

Posté par papy88140 le 11 octobre 2011 à 09:18. Évalué à 10.

Bonjour,

j'aimerais revenir sur le passage
" Google a visiblement développé un langage qui correspond à ses besoins (permettre de développer des applications comme GMail ou Google Maps), et en a perdu de vue le plus important : convaincre les autres navigateurs d’accepter Dart."

Si je me souviens bien, à l'époque ou Internet Explorer était le principal navigateur,
Microsoft n'a jamais consulté qui que ce soit pour inclure à sa charrette des fonctions
spécifiques, des tas de bidules non standard et tout le monde faisait des sites
"optimisés internet explorer".

Le navigateur de Google est en train de gagner du terrain.

Peut-être que s'il a suffisamment de poids, Google pourra se passer d'accord et lancer
son langage.
- [^] # Re: Besoin du support de tous ?
  
  Posté par goulou le 11 octobre 2011 à 09:45. Évalué à 4.
  
  Peut-être que s'il a suffisamment de poids, Google pourra se passer d'accord et lancer
  son langage.
  
  On a bien vu ce que ça a donné avec Microsoft et Internet Explorer... Je pense qu'il n'y a pas grand monde qui puisse souhaiter la même chose avec Google et Chrome!
  - [^] # Re: Besoin du support de tous ?
    
    Posté par zebra3 le 11 octobre 2011 à 11:22. Évalué à 2.
    
    Alors il faut que la concurrence entre dans le processus de développement et proposent quelque chose de mieux, au lieu de juste se plaindre.
    
    Ce n'est pas souhaitable, mais personne ne peut empêcher Google de développer ce qu'il veut dans son coin.
    
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: Besoin du support de tous ?
      
      Posté par bilboa le 12 octobre 2011 à 00:16. Évalué à 2.
      
      Comme l'inférence pour les types en javascript? Ah tiens on me suggère que Mozilla le fait mais que c'est contraire à la strategie Dart de Google, qui serait apparement l'un des multiples missiles utilisés pour tenter d'imposer son naviguateur pour ses services web et avoir un bon petit monopoly du net entier, rien de moins.
  - [^] # Re: Besoin du support de tous ?
    
    Posté par lasher le 11 octobre 2011 à 14:48. Évalué à 4.
    
    Oui, comme par exemple XmlHttpRequest. Quelle plaie, fouyaya... (et là, Grunt arrive et approuve au premier degré mon second. :P)
- [^] # Re: Besoin du support de tous ?
  
  Posté par zerchauve le 11 octobre 2011 à 10:15. Évalué à 3.
  
  Microsoft a aussi developpé des choses qui sont devenues des standards (+ ou -). Au hasard, le xmlHttpRequest.
  Tout n'est pas mauvais dans les guerres de navigateurs.
  - [^] # Re: Besoin du support de tous ?
    
    Posté par Elfir3 le 11 octobre 2011 à 11:24. Évalué à 6.
    
    Mouais... Si ce n'est que le "standard" de Microsoft à changé à chaque version d'IE jusqu'à la 7, et était incompatible avec les autres browser ...
    - [^] # Re: Besoin du support de tous ?
      
      Posté par zerchauve le 11 octobre 2011 à 13:51. Évalué à -1.
      
      je ne considère pas que "faire des choses dans son coin" nuit réellement aux standards.
      Ce qui nuit, ce sont les adoptions partielles ou erronées de ce qui est standardisé.
- [^] # Re: Besoin du support de tous ?
  
  Posté par imr le 11 octobre 2011 à 11:39. Évalué à 5.
  
  Peut-être que s'il a suffisamment de poids, Google pourra se passer d'accord et lancer son langage.
  
  Lis bien le document, dès le début et tout le long, ils parlent de leur langage dans le cadre d'un web ouvert à contrario des autres plateformes (et ils citent iOS) qu'ils qualifient d'encroached c'est à dire qui empiètent sur le web, qui gagnent du terrain sur lui.
  Le cadre de leur travail selon ce document, c'est que la plateforme, c'est le web, pas l'OS ou le device ou le navigateur. Leur plan c'est de le garder ouvert et de dériver leurs profits de l'usage du web pas de leur controle d'une partie de celui ci. Dans ce cadre, ils ont besoin des autres.
- [^] # Re: Besoin du support de tous ?
  
  Posté par isildur37 le 11 octobre 2011 à 13:34. Évalué à 1.
  
  Si Dart et plus simple à coder / plus rapide que JS, ça risque de prendre le dessus rapidement... Étant développeur Java/Ruby/PHP/Scala, j'évite au maximum de produire du JS à la mano, car ça a de grandes chances de ne pas passer correctement sur tel ou tel navigateur...
  Il y a des framework de haut niveau qui font cela très bien, et mes respects à ceux qui se sont amusé à produire un code JS qui marche partout...
  
  Et avis purement personnel, je trouve que le code JS est assez peu lisible et peu explicite, avec une gestion d'exception foireuse. Beaucoup codent mal en JS, notamment dans les PME qui ont des sites mal faits...
  - [^] # Re: Besoin du support de tous ?
    
    Posté par __o le 12 octobre 2011 à 13:34. Évalué à 1.
    
    Pour infos, jQuery c'est toujours du Javascript hein :)
# Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?

Posté par mr_spoke le 11 octobre 2011 à 09:24. Évalué à 10.

Ça me paraît absurde qu’un langage sortant en 2011, impose encore la présence de « ; » pour séparer les instructions se trouvant sur des lignes séparées.

L'intérêt qu'on peut y voir, c'est d'éviter les lignes à rallonge qui, en Ruby ou en Python, ne peuvent être coupées qu'en terminant la ligne par « \ ». Et ça évite les ambiguïtés.
- [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
  
  Posté par windu.2b le 11 octobre 2011 à 09:30. Évalué à 10.
  
  Autre intérêt : lorsqu'on minimise le code (pour des raisons d'obfuscation ou des gains de taille), il faut forcément un séparateur clair, autre que le retour à la ligne (qui n'est d'ailleurs pas le même selon l'OS).
  - [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
    
    Posté par CrEv (site web personnel) le 11 octobre 2011 à 09:42. Évalué à 5.
    Le fait qu'il y ait besoin d'un séparateur dans ce cas (plusieurs instructions par ligne) ne devrait pas forcément le rendre obligatoire lorsque les instructions sont sur des lignes différentes.
    
    Après, il faut bien voir qu'il y a aussi deux types de minifiers :
    - le premier, tout basique, ne fait que minifier (remplacer des variables locales, tout mettre sur une ligne - ou plusieurs grandes -, virer les commentaires)
    - les autres, font de la réelle analyse syntaxique, et sont en fait capable de régénérer le code. Les ';' ne sont plus un problème car n'interviennent qu'au moment de la sérialisation. On arrive (par exemple avec closure compiler de Google) a avoir des compilateurs javascript, qui réalisent beaucoup plus de choses qu'un minifier basique, entre autre de l'inline de méthodes.
- [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
  
  Posté par Édouard Siha le 11 octobre 2011 à 09:33. Évalué à 10.
  
  Mensonge, au sein de parenthèses, en Python, tu n'es pas obligé de mettre un « \ » pour couper une ligne.
  - [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
    
    Posté par __o le 12 octobre 2011 à 13:36. Évalué à 2.
    Et pour chainer des méthodes ? comme
```
$('body').find('.foo')
    .addClass('bar')
    .map(...)
    ....
```
- [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
  
  Posté par banks_the_megalith (site web personnel) le 11 octobre 2011 à 10:30. Évalué à 6.
  
  L'intérêt qu'on peut y voir, c'est d'éviter les lignes à rallonge qui, en Ruby ou en Python, ne peuvent être coupées qu'en terminant la ligne par « \ »
  
  Je ne comprends pas vraiment l'argument : avec Dart, si tu mets un «;», c'est que tu as deux instructions de part et d'autre du délimiteur, auquel cas ça équivaut à aller à la ligne en ruby (ou mettre un «;» d'ailleurs...).
  Une ligne à rallonge coupée par un «\» ne constitue qu'une seul instruction, à mon avis t'auras la même chose avec Dart.
- [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
  
  Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 10:41. Évalué à 5.
  En Ruby, il n'y a pas besoin de mettre de \ pour découper une instruction sur plusieurs lignes. On coupe généralement après une virgule. Exemple tiré du code source de LinuxFr.org :
```
  news.paragraphs.create :wiki_body     => body,
                         :second_part   => second_part,
                         :already_split => true   
```
  Mais en fait, on peut couper tant que chaque ligne ne forme pas une instruction qui pourrait être valide.
  - [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
    
    Posté par Troy McClure (site web personnel) le 11 octobre 2011 à 12:54. Évalué à 6.
    Et sur ce genre de code:
```
plop = 1+2
       +3+4
```
    ça donne quoi comme valeur finale dans plop, 3 ou 10 ? je dis ça parce que je me suis fait avoir recemment après un copier coller, avec un langage qui n'impose pas le ';' à la fin des lignes et j'ai perdu quelques heures avec ça
    - [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
      
      Posté par Jean B le 11 octobre 2011 à 13:12. Évalué à 5.
      Dans ce cas précis plop vaut 3, par contre dans ce cas:
      
      plop = 1+2+ 3+4
      
      plop vaut 7
      - [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
        
        Posté par goulou le 11 octobre 2011 à 14:14. Évalué à 7.
        
        C'est là tout le problème selon moi des langages qui laissent la porte ouverte à ce genre de subtilité : en lisant le code rapidement, on laisse passer des erreurs à cause d'un simple signe mal placé...
        
        Et dans le cas ou plop vaut 3, rassurez moi, il y a une erreur de syntaxe à la ligne suivante ou ça passe comme une lettre à la poste??
        
        [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
        
        Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 14:23. Évalué à 2.
        
        Ça passe comme une lettre à la poste. Le premier plus est collé au nombre et est alors interprété comme le signe du nombre.
        
        [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
        
        Posté par manawy (site web personnel) le 11 octobre 2011 à 15:23. Évalué à 1.
        
        Et on peut aussi utiliser les parenthèses pour être sur, en python c'est obligatoire
        
        plop = ( 1 + 2 + 3 + 4 )
        
        [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
        
        Posté par gUI (Mastodon) le 11 octobre 2011 à 22:23. Évalué à 6.
        
        Moi je suis pour que les langages autorisent tout, et pour pendre les codeurs qui font n'importe quoi avec.
        
        C'est pas parce qu'il est possible d'écrire des horreurs que le langage n'est pas bon.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
- [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
  
  Posté par Michaël (site web personnel) le 11 octobre 2011 à 13:06. Évalué à 2.
  
  Ça me paraît absurde qu’un langage sortant en 2011, impose encore la présence de « ; » pour séparer les instructions se trouvant sur des lignes séparées.
  
  L'intérêt qu'on peut y voir, c'est d'éviter les lignes à rallonge qui, en Ruby ou en Python, ne peuvent être coupées qu'en terminant la ligne par « \ ». Et ça évite les ambiguïtés.
  
  À mon avis l'intérêt est surtout que ça simplifie l'analyse syntaxique: avant d'être éxécuté le programme va être analysé syntaxiquement et gagner du temps sur ce côté là rendra porbablement l'ensemble plus réactif. C'est probablement un bon choix pour un langage utilisé dans un contexte intéractif. Dans les langages sophistiqués (comme OCaml), le temps de compilation est très long!
  - [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
    
    Posté par Jux (site web personnel) le 11 octobre 2011 à 13:14. Évalué à 10.
    
    La compilation Ocaml est probablement très longue parce que même le compilateur doit s'y reprendre à plusieurs fois avant de comprendre la syntaxe.
    - [^] # Re:JavaScript—Dartva‐t‐ilremplacer JavaScript comme langage dans lesnavigateurs ?
      
      Posté par Juke (site web personnel) le 11 octobre 2011 à 18:25. Évalué à 8.
      
      La compilation Ocaml est probablement très longue
      
      et quand y'a du bruit c'est encore pire
  - [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
    
    Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 14:30. Évalué à 7.
    
    Non, l'analyse syntaxique est généralement très rapide. Ce qui prend du temps à la compilation est tout ce qui vient après, une fois que l'on a l'AST. En particulier, essayer d'optimiser le codé généré est très souvent le plus long.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 11 octobre 2011 à 16:23. Évalué à 2.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
        
        Posté par barmic le 11 octobre 2011 à 18:09. Évalué à 2.
        
        C'était d'ailleurs, si je me souviens bien, un des objectifs de pascal.
        
        Si je ne me trompe c'était plutôt un projet qui avait eu lieux dans l'écosystème "pascal".
        
        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— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
      
      Posté par Michaël (site web personnel) le 11 octobre 2011 à 18:54. Évalué à 2.
      Dans un langage imaginaire si les instructions
      
      sont données il faut savoir si il s'agit de la fonction print avec quatre arguments ou bien deux appels de fonctions. C'est à dire qu'une fois l'analyse lexicale faite le découpage en phrases va devoir tenir compte des règles d'associavité du langage pour arriver à l'AST, ce qui est forcément plus long que si le programme contient la marque de fin des phrases!
      Pour prendre des cas extrèmes, on peut coder un assembleur qui travaille en temps et espace constant sur chaque phrase (sans labels!) alors que pour un langage plus complexe, on va avoir besoin d'une pile: on parle de complexités différentes.
- [^] # Re: JavaScript— Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?
  
  Posté par spider-mario le 11 octobre 2011 à 19:36. Évalué à 1.
  Lua n’a aucun séparateur d’instruction.
  
  Le code suivant est valide :
```
a = 1 b = 2
```
  a vaut alors 1 et b vaut 2.
# Moi, tellement mieux

Posté par Julien Gilbert le 11 octobre 2011 à 09:28. Évalué à 10.

"Par exemple, Brendan Eich, le créateur de JavaScript, considère qu’il est plus simple et plus efficace de faire évoluer le JavaScript que de développer un nouveau langage." Non ? Vraiment ? Et l'avis de quelqu'un d'un peu plus objectif ca donne quoi ?

Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
- [^] # Re: Moi, tellement mieux
  
  Posté par Maclag le 11 octobre 2011 à 09:39. Évalué à 10.
  
  J'ai ouï dire que Steve Ballmer estime que C# et .Net seraient 'achement plus adaptés que Javascript.
  - [^] # Re: Moi, tellement mieux
    
    Posté par Fabimaru (site web personnel) le 11 octobre 2011 à 11:15. Évalué à 3.
    
    Foutaise! Il y a déjà vbscript pour votre navigateur préféré (je parle du "E" bleu sur lequel on clique pour aller sur Internet).
    
    PS: quelle bouse ce vbscript, je ne souhaite à personne d'avoir à en faire
- [^] # Re: Moi, tellement mieux
  
  Posté par Olivier Faurax (site web personnel) le 11 octobre 2011 à 10:32. Évalué à 6.
  
  Ça me rappelle la fois où on prenait comme référence sur webm l'avis d'un développeur x264....
  - [^] # Re: Moi, tellement mieux
    
    Posté par Phlogistique le 12 octobre 2011 à 06:41. Évalué à 3.
    
    Un développeur d'x264 n'est pas un développeur d'H.264. Ça fait toute la différence.
    - [^] # Re: Moi, tellement mieux
      
      Posté par zebra3 le 12 octobre 2011 à 09:17. Évalué à 4.
      
      Il y a quand même de fortes chances qu'il va forcément prêcher pour sa paroisse.
      
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: Moi, tellement mieux
        
        Posté par Moonz le 12 octobre 2011 à 18:43. Évalué à 5.
        
        Sauf que c’est aussi celui qui a implémenté Web.M dans ffmpeg, donc c’est quoi sa paroisse ?
        
        [^] # Re: Moi, tellement mieux
        
        Posté par zebra3 le 13 octobre 2011 à 10:48. Évalué à 2.
        
        C'est ffmpeg, donc l'implémentation de Google est forcément moins bien :-)
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: Moi, tellement mieux
      
      Posté par gasche le 12 octobre 2011 à 11:22. Évalué à 5.
      
      Un développeur d'x264 n'est pas un développeur d'H.264. Ça fait toute la différence.
      
      Tu as tout à fait raison. C'est une des rares personnes compétentes dans le domaine à s'être exprimé sur le sujet, et on le critique parce qu'il développe un logiciel libre pour gérer un format concurrent.
      
      C'est facile de rejeter une critique en dénonçant la partialité. Il n'empêche que ses avis étaient argumentés et techniquement justifiés, et que les gens n'ont à opposer qu'un maigre "oui mais Google ils savent ce qu'ils font, c'est forcément génial leur truc".
      
      Donnez-moi un lien vers un développer également compétent et qu'on soupçonne d'être biaisés dans une autre direction (par exemple un développeur pour du software WebM). Je serai ravi de lire ses contres-arguments. En attendant, les gens qui ont des arguments techniques sont convaincants.
      - [^] # Re: Moi, tellement mieux
        
        Posté par zebra3 le 13 octobre 2011 à 10:49. Évalué à 1.
        
        les gens n'ont à opposer qu'un maigre "oui mais Google ils savent ce qu'ils font, c'est forcément génial leur truc".
        
        En même temps, je n'ai pas souvenir d'un truc qui n'a pas fonctionné chez Google (au sens technique du terme).
        
        Leur réputation de bons ingénieurs n'est pas usurpée.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: Moi, tellement mieux
    
    Posté par reno le 12 octobre 2011 à 10:03. Évalué à 7.
    
    Ça me rappelle la fois où on prenait comme référence sur webm l'avis d'un développeur x264...
    
    Hum, hum, c'est un raccourci très rapide: un développeur d'un codec vidéo sera beaucoup plus apte qu'un quidam moyen a faire une analyse technique d'un codec.
    Maintenant son analyse sera t'elle biaisée par la compétition entre les codec?
    Et bien ça dépend du gars et de la situation..
    
    Pour un développeur "pur open-source" on pourrait espérer que, n'ayant pas d'intérêt financier dans la comparaison, il reste neutre,
    pour ce développeur x264 il faut être rester prudent car leur projet est aussi intégrer dans des produits vendus.
    - [^] # Re: Moi, tellement mieux
      
      Posté par barmic le 12 octobre 2011 à 10:31. Évalué à 3.
      
      Quand on te dis que ton travail n'a pas d'avenir et qu'il va dans le mur, que tu sois développeur Open Source, libre ou pas ça donne pas forcément envie d’encenser l'alternative créé par ce même « critiqueur ».
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Moi, tellement mieux
      
      Posté par lasher le 12 octobre 2011 à 15:08. Évalué à 3.
      
      Maintenant son analyse sera t'elle biaisée par la compétition entre les codec?
      
      sera-t-elle
      
      Signé : le nazi de l'orthographe.
# Puisque nous ne sommes pas vendredi...

Posté par gnotule le 11 octobre 2011 à 09:48. Évalué à 7.

Et pourquoi pas Parrot ?
- [^] # Re: Puisque nous ne sommes pas vendredi...
  
  Posté par jigso le 11 octobre 2011 à 10:21. Évalué à 5.
  
  Ouais, direct l'assembleur dans le navigateur, y'a qu'ça d'vrai !
  Et enfin le web reviendra aux mains des hommes, des vrais, des barbus/bière/pizzas !
  - [^] # Re: Puisque nous ne sommes pas vendredi...
    
    Posté par Elfir3 le 11 octobre 2011 à 11:30. Évalué à 3.
    
    Si tu tiens autant à ce que ce soit réservé à l'élite, autant le faire en whitespace..
- [^] # Re: Puisque nous ne sommes pas vendredi...
  
  Posté par gasche le 11 octobre 2011 à 14:52. Évalué à 1.
  
  Ils essaient d'obtenir quelque chose de performant. C'est contradictoire avec certains de leurs choix techniques (le typage qui ne donne aucune garantie), mais quand même prendre Parrot ce serait se tirer dans le pied.
  - [^] # Re: Puisque nous ne sommes pas vendredi...
    
    Posté par Sytoka Modon (site web personnel) le 11 octobre 2011 à 17:36. Évalué à 2.
    
    Si Parrot bénéficiait des ressources humaines mises sur le Java ou le JavaScript, c'est clair qu'il irait plus vite ;-)
- [^] # Re: Puisque nous ne sommes pas vendredi...
  
  Posté par barmic le 11 octobre 2011 à 18:16. Évalué à 2.
  
  La proposition m'a parrut humoristique au début, mais à la réflexion. Actuellement on utilise des minifieur pour balancer au client quelque chose le plus petit possible. Si on laisse le minimum de travail au niveau du client (il prend du code et il l'exécute dans un bac à sable), on doit nettement gagner en performance.
  
  Je pense que les VM (JVM, parrot, .Net, etc) ont une carte à jouer dans le domain avec forte isolation entre l'espace mémoire où s'exécute le code reçu et celui des programmes natifs.
  
  Là où il y a un vrai problème c'est pour l'adoption. Tu peut difficilement avoir d'étape transitoires pour passer de l'un à l'autre (et surtout elle reporte les possibilités d'étape transitoires sur le client et pas sur le serveur).
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Puisque nous ne sommes pas vendredi...
    
    Posté par CrEv (site web personnel) le 11 octobre 2011 à 18:19. Évalué à 3.
    
    Je comprend pas bien.
    
    Je pense que les VM ont une carte à jouer dans le domain
    
    Le javascript, aujourd'hui, est déjà exécuté dans des VM. Non ?
    - [^] # Re: Puisque nous ne sommes pas vendredi...
      
      Posté par barmic le 11 octobre 2011 à 18:42. Évalué à 1.
      Oui, mais le bycode est caché. Donc des étapes fastidieuses sont répétées inlassablement (analyse syntaxique, lexicale, compilation vers le bytecode) là où du bytecode limiterai la charge au client. On a aussi des fichiers qui sont du coup plus lourd (ils gardent des identifiants ASCII).
      
      Le petit plus c'est qu'il apporte au développeur une grande liberté dans le langage utilisé :
      
      parro : perl et les langages parro
      
      JVM : Java, groovy, scala
      
      .Net : C#, VBScript, J# (c'est mort ou pas déjà ?)
      
      C'est un peu comme le fait de prendre un langage et de lui faire cracher du HTML pour l'envoyer au client, sauf que là c'est du bytecode.
      
      C'est aussi quelque chose qui se fait pour les CSS avec des outils comme lesscss, blueprint ou autre.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Puisque nous ne sommes pas vendredi...
    
    Posté par BohwaZ (site web personnel, Mastodon) le 11 octobre 2011 à 19:05. Évalué à 4.
    
    En fait ce que tu décris c'est Flash, du code (ActionScript, basé sur... Javascript) compilé et exécuté par une VM (Flash player), non ?
    
    (C'est pas un troll hein.)
    
    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# IDE

Posté par barmic le 11 octobre 2011 à 10:01. Évalué à 10.

La syntaxe est très décevante : elle est fortement inspirée de Java et C#, et paraîtra rebutante aux développeurs habitués à celle des langages dynamiques comme Ruby, Python ou encore… JavaScript ! Ça me paraît absurde qu’un langage sortant en 2011, impose encore la présence de « ; » pour séparer les instructions se trouvant sur des lignes séparées.

Ils cherchent à créer un langage avec un bon support par des IDE et pour cela ils s'inspirent des deux langages qui ont probablement le meilleur support par des IDE (Eclipse, Netbean, InteliJ, VS, …). Quel bande d'idiots !

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: IDE
  
  Posté par Jux (site web personnel) le 11 octobre 2011 à 10:26. Évalué à 9.
  
  Même chose pour la syntaxe d'ailleurs. Le but est de séduire les développeurs d'applications "lourdes" (en terme de lignes de code), qui sont encore souvent développées avec Java/C++/C# sur le desktop ou Java/Google Web Toolkit sur le net. Donc c'est assez logique d'avoir une syntaxe approchante.
  
  De toute manière, les remarques sur la syntaxe rebutante sont purement subjectives. Je ne vois d'ailleurs pas trop en quoi la syntaxe de Javascript est proche de celle de Python (elle est plutôt proche du C pour moi mais bon). Bref, ils ont pris une syntaxe compréhensible par un gros nombre de personne (je ne connais pas beaucoup de développeurs qui n'ont jamais fait soit du C#, soit du Java), ce qui semble plutôt malin si on veut une bonne acceptation du langage.
- [^] # Re: IDE
  
  Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 10:54. Évalué à 10.
  
  Si Java et C# ont une très bonne intégration avec les IDE, c'est grâce au typage statique, la présence de classes, l'absence/faible utilisation de metaprogramming... mais pas la syntaxe.
  - [^] # Re: IDE
    
    Posté par barmic le 11 octobre 2011 à 11:51. Évalué à 4.
    
    Je pense que plus la syntaxe est simple plus l'implémentation d'un IDE complexe est simple.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: IDE
      
      Posté par Damien (site web personnel) le 11 octobre 2011 à 13:11. Évalué à 3.
      
      Clairement. Un arbre abstrait avec seulement 15 sortes de noeuds différents qui sont bien othogonaux entre eux, c'est bien plus sympa que 200 avec des contraintes bizarres.
      - [^] # Re: IDE
        
        Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 14:38. Évalué à 5. Dernière modification le 11 octobre 2011 à 14:39.
        
        En général, oui, mais parfois ça peut être intéressant d'avoir un peu plus de nœuds différents pour avoir un comportement plus proche de celui auquel s'attend les développeurs (principe de moindre surprise).
        
        Et pour Dart, je suis loin d'être convaincu que sa syntaxe soit si simple que ça.
        
        À titre d'exemple, voici deux lignes prises au hasard (ou pas) :
        
        public static <T extends Comparable<? super T>> List<T> sort(List<T> list) {
        
        portToPlayer.then((SendPort port) => port.call({ "action" : MessageIds.SETUP, "args" : [player] }));
        
        [^] # Re: IDE
        
        Posté par 2PetitsVerres le 11 octobre 2011 à 14:44. Évalué à 0.
        
        La première ligne, c'est du C++ ?
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
        
        [^] # Re: IDE
        
        Posté par Buf (Mastodon) le 11 octobre 2011 à 15:21. Évalué à 5.
        
        ça ressemble beaucoup plus à du Java qu'à du C++
        
        [^] # Re: IDE
        
        Posté par Fabimaru (site web personnel) le 11 octobre 2011 à 15:28. Évalué à 3.
        
        Java.
        (ou alors du C++ avec des #define, mais là faudrait vraiment être maso)
        
        [^] # Re: IDE
        
        Posté par cpc6128 (site web personnel) le 11 octobre 2011 à 15:36. Évalué à 1.
        
        Du java avec des types génériques : http://fr.wikibooks.org/wiki/Programmation_Java/Types_g%C3%A9n%C3%A9riques
        C'est sûr que ce n'est l'exemple le plus concis...
        
        [^] # Re: IDE
        
        Posté par khivapia le 11 octobre 2011 à 16:07. Évalué à 2.
        
        Non, en C++ le public est toujours suivi d'un : Idem avec le mot-clef extend qui n'est pas du C++. C'est donc plutôt du java.
        
        [^] # Re: IDE
        
        Posté par totof2000 le 11 octobre 2011 à 16:42. Évalué à 0.
        
        Euh ... attends .... Je me sens mal ... ;BUUUUURP !!!! BUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURP !!!
        
        Dis, tu pourrais éviter de nous mettre ce genre de truc après le repas, c'est immonde.
        
        [^] # Re: IDE
        
        Posté par cpc6128 (site web personnel) le 11 octobre 2011 à 17:00. Évalué à 1.
        
        C'est pourtant simple :)
        
        sort est une méthode qui prend en entrée une liste d'objets T et retourne une liste d'objets T mais T doit implémenter l'interface Comparable.
        
        Bah quoi ?
        
        [^] # Re: IDE
        
        Posté par tyoup le 11 octobre 2011 à 22:17. Évalué à 0.
        
        Certains préfèrent l'inférence des types
        
        [^] # Re: IDE
        
        Posté par barmic le 11 octobre 2011 à 18:27. Évalué à 4.
        
        C'est marrant parce que personnellement autant la première ligne je la comprend bien.
        
        L'autre je ne sais pas par ou commencer à la lire et le coup des ({"mot1" : mot2, "mot3" : [mot4]}) ne me semble pas plus lisible que ça. Plus concis c'est sûr, très probablement plus fun. Plus simple, j'ai vraiment un gros doute.
        
        Je pense que de la même manière que notre langue impacte notre manière de penser les langages que l'on utilise impacte notre manière de réfléchir et notre approche des problèmes algorithmique.
        
        Dit plus simplement : c'est une question d'habitude.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: IDE
    
    Posté par Ontologia (site web personnel) le 12 octobre 2011 à 12:42. Évalué à 6.
    
    Les classes sont une régresséion par rapport au prototype, dire que c'est mieux parce que "ça correspond aux habitudes des programmeurs", je trouve ça grave comme réflexe.
    Mais bon...
    
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
    - [^] # Re: IDE
      
      Posté par CrEv (site web personnel) le 12 octobre 2011 à 16:34. Évalué à 6.
      
      Les classes sont une régresséion par rapport au prototype
      
      En quoi ?
      
      (note : c'est une vrai question, pour que tu expliques)
      - [^] # Re: IDE
        
        Posté par Ontologia (site web personnel) le 12 octobre 2011 à 16:50. Évalué à 5.
        
        Une classe n'est pas vivante en soit, il faut l'instancier.
        Un prototype est vivant, il se clone.
        
        Dans les langages objets à prototype, tu n'as que la notion d'objet qui existe. C'est un pattern singleton en lui même (que l'on s'évertue à reproduire en classe de façon crade).
        De plus, comme il n'existe que la notion d'objet, l'héritage se fait au niveau de l'objet, pas de la classe. Par conséquent, l'héritage est dynamique.
        
        Note : le proto en JS est extrêmement mal implémenté.
        Mais ça permet aussi de charger des méthodes à chaud, comme en JS, vu que l'objet "mère" est vivant.
        
        Ca permet aussi une vraie séparation physique en mémoire des proto, et donc une séparation physique de l'héritage.
        En classe, B hérite A, tu instancie B, B est une concaténation de A et B.
        En prototype, A est vivant, B aussi, et le mécanisme d'héritage permet d'appeler le père, qui est un objet vivant à part entière.
        Cela permet ainsi de définir des arbres d'héritages complexes, du genre héritage diamant.
        
        Ah, autre chose :
        Dans le cadre de l'héritage multiple en proto : l'arbre de recherche se fait en profondeur, pas en largeur.
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: IDE
        
        Posté par barmic le 13 octobre 2011 à 08:35. Évalué à 1.
        
        Excuse moi mais je n'arrive pas à voir l'intérêt ou l'avantage.
        
        Une classe n'est pas vivante en soit, il faut l'instancier.
        Un prototype est vivant, il se clone.
        
        Dans les langages Objet "pur" une classe est un objet comme un autre. Donc tu peut la cloner si tu veut (reste à en trouver l'intérêt).
        
        Mais ça permet aussi de charger des méthodes à chaud, comme en JS, vu que l'objet "mère" est vivant.
        
        Ce n'est pas une spécificité des prototypes.
        
        Ça permet aussi une vraie séparation physique en mémoire des proto, et donc une séparation physique de l'héritage.
        En classe, B hérite A, tu instancie B, B est une concaténation de A et B.
        En prototype, A est vivant, B aussi, et le mécanisme d'héritage permet d'appeler le père, qui est un objet vivant à part entière.
        
        Ça me fait penser à scala qui permet d'ajouter de l'héritage à l'instanciation, mais c'est moins puissant.
        
        Tu présente des choses puissantes, mais j'ai du mal à voir les cas d'utilisation. J'ai l'impression que c'est un paradigme qui manque de langages.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE
        
        Posté par Ontologia (site web personnel) le 13 octobre 2011 à 11:06. Évalué à 3.
        
        Dans les langages Objet "pur" une classe est un objet comme un autre. Donc tu peut la cloner si tu veut (reste à en trouver l'intérêt).
        
        Oui mais tu as toujours une séparation entre le modèle formel qui n'a aucune existence physique, et la réalité, l'instance.
        Là est le problème, même pour les langages à superclasses.
        
        Ce n'est pas une spécificité des prototypes. [chargement méthode à chaud]
        
        Oui mais le problème d'une classe, c'est qu'elle embarque tout son héritage avec elle même, donc si tu modifie une classe plus haut dans l'arbre d'héritage, l'ajout de méthodes que tu vas faire dans la superclasse ne l'atteint pas. Ou alors c'est une affreuse bidouille.
        
        Tu présente des choses puissantes, mais j'ai du mal à voir les cas d'utilisation. J'ai l'impression que c'est un paradigme qui manque de langages.
        
        C'est difficile parce que tu n'as pas l'habitude de penser avec ces nouveaux concepts. Moi même au début j'ai eu du mal.
        Le concept de l'héritage diamant dynamique est impossible à faire en classe. Ce type d'héritage te permet de définir une grammaire formelle, avec l'héritage statique, et de définir ton arbre syntaxique avec l'héritage dynamique.
        (Xor dans le schéma, c'est l'héritage dynamique)
        
        C'est pas parce que tu ne vois pas d'applications qu'elles n'existent pas. Si tu avais l'habitude de programmer en procédural, tu ne verrais surement pas l'intérêt de l'objet à classe...
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: IDE
        
        Posté par sifu le 13 octobre 2011 à 13:35. Évalué à 1.
        
        J'aimerais bien un exemple de la vraie vie ... genre des voitures et des vélos !
        
        [^] # Re: IDE
        
        Posté par barmic le 13 octobre 2011 à 13:36. Évalué à 2.
        
        C'est difficile parce que tu n'as pas l'habitude de penser avec ces nouveaux concepts. Moi même au début j'ai eu du mal.
        
        Comme toujours. C'était pareil avec NoSQL par exemple, il me faut un peu de temps pour voir les utilisation intéressantes.
        
        C'est pas parce que tu ne vois pas d'applications qu'elles n'existent pas. Si tu avais l'habitude de programmer en procédural, tu ne verrais surement pas l'intérêt de l'objet à classe...
        
        Non j'ai pas du bien m'exprimer. Wikipedia recence 4 langages qui implémentente ce paradygme, dont Javascript et Actionscript, qui sont assez particulier dans leur utilisation, lisaac qui semble à moitié mort et self détenu par Oracle. Je pense que c'est un frein à l'utilisation de ce paradygme et donc nuis à son utilisation.
        
        Je pense que s'il existait un langage de script qui l'implémente pas trop mal avec quelque binding simples, ça aiderais à le faire connaître et à ce qu'il ne soit pas vu comme un frein.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE
        
        Posté par Larry Cow le 13 octobre 2011 à 14:12. Évalué à 5.
        
        Paradigme, l'exception qui confirme la règle "tous les mots savants comportent au moins un Y". ;)
        
        [^] # Re: IDE
        
        Posté par barmic le 13 octobre 2011 à 16:40. Évalué à 2.
        
        Rah ! Je ne me suis pas relus ! Même moi ça me fais mal aux yeux …
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE
        
        Posté par Ontologia (site web personnel) le 13 octobre 2011 à 16:46. Évalué à 2.
        
        Comme toujours. C'était pareil avec NoSQL par exemple, il me faut un peu de temps pour voir les utilisation intéressantes.
        
        Oui voilà, bon exemple, NoSQL, je me disais "keskecequecetruc ?" et puis tu intègre et tu commences à voir où le rationnel est bien et où le NoSQL est intéressant :-)
        
        Un langage qui marche pas trop mal en prototype c'est IO :
        http://iolanguage.com/
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: IDE
        
        Posté par jiyuu le 13 octobre 2011 à 17:18. Évalué à 1.
        
        N'oublions pas Lua qui est aussi un langage à prototype.
        
        [^] # Re: IDE
        
        Posté par tyoup le 15 octobre 2011 à 13:55. Évalué à 0.
        
        Le concept de l'héritage diamant dynamique est impossible à faire en classe.
        Il suffit d'hériter de java.util.HashMap :-) et tu as ton héritage dynamique.
- [^] # Re: IDE
  
  Posté par Moonz le 11 octobre 2011 à 13:45. Évalué à 5.
  
  D’un autre côté, j’ai tendance à dire que Java/C# ont un bon support des IDE parce qu’ils ont besoin d’un IDE pour être vaguement utilisables, contrairement à Python/Ruby/whatever.
  - [^] # Re: IDE
    
    Posté par devnewton 🍺 (site web personnel) le 11 octobre 2011 à 14:55. Évalué à 3.
    
    Ca ressemble à une excuse foireuse "mon langage est tellement puissant que tu n'as pas besoin d'IDE et de debugger, ce n'est ABSOLUMENT pas parce que c'est super dur à développer".
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: IDE
      
      Posté par Larry Cow le 11 octobre 2011 à 15:59. Évalué à 4.
      
      Ben, c'est super dur aussi d'écrire un IDE pour C++ ou Java (en tous cas, moi je sais pas faire). Sauf que les développeurs sont vachement plus encouragés à s'y coller.
      - [^] # Re: IDE
        
        Posté par devnewton 🍺 (site web personnel) le 11 octobre 2011 à 16:04. Évalué à 2.
        
        Pourtant beaucoup de devs C++ n'utilisent que leur vi et leur couteau.
        
        Je me souviens aussi qu'aux débuts de Java, on le vendait comme si simple que seul un éditeur de texte est suffisant pour commencer.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: IDE
        
        Posté par zebra3 le 11 octobre 2011 à 17:06. Évalué à 2.
        
        Pourtant beaucoup de devs C++ n'utilisent que leur vi et leur couteau.
        
        Tu insinues que les dev C++ en ont une petite ?
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: IDE
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 octobre 2011 à 17:37. Évalué à 1.
        
        Non, qu'ils sont impuissants, je crois.
        
        [^] # Re: IDE
        
        Posté par lasher le 12 octobre 2011 à 00:08. Évalué à 4.
        
        Je crois qu'il insinue que les devs C++ ont un vi. Grand ou petit, il ne dit rien dessus.
        
        [^] # Re: IDE
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 12 octobre 2011 à 11:03. Évalué à 3.
        
        Eh bien, s'ils ont besoin de du miracle bleu Vi, c'est qu'ils sont impuissants non ?
  - [^] # Re: IDE
    
    Posté par barmic le 11 octobre 2011 à 17:41. Évalué à 3.
    
    C'est vrai que le refactoring c'est utile que quand on fait un gros projet avec un minimum de contraintes ?
    
    Un prêté pour un rendu.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Encore un langage de "haut"-niveau interprété par le navigateur?!

Posté par GTof le 11 octobre 2011 à 10:12. Évalué à 10.

Remplacer JavaScript, pourquoi pas. Même si Fabrice Bellard arrive a en faire des merveilles, JS est quand même pas l'option la plus adaptée pour les performances. Mais pourquoi diable un nouveau langage "haut"-niveau? Surtout que rien ne force à développer en JS pour tourner sur le navigateur, les langages qui se compilent en JS sont légion. J'aurais plutôt vu une approche à la Mono/.NET avec un langage très bas niveau qui s'exécute rapidement sur le navigateur et une flopée de langages intercompatibles qui se compilent dedans. Car non l'analyse lexicale et syntaxique n'a pas à être fait à la volé par le navigateur par le navigateur et encore moins la vérification de types!

Pourquoi pas le support du bytecode LLVM dans les navigateur? Ce serait possible?
- [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
  
  Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 10:45. Évalué à 6.
  
  Pourquoi pas le support du bytecode LLVM dans les navigateur? Ce serait possible?
  
  Oui, ça serait possible. Il faut regarder du coté de NaCl (Native Client). Mais ça pose beaucoup de problème, notamment de portabilité et de sécurité.
- [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
  
  Posté par gnotule le 11 octobre 2011 à 10:55. Évalué à 3.
  
  cf. ma remarque sur Parrot (ce n'était pas une blague). Du coup chacun peut utiliser son langage préféré et qui plus est le code généré est obstrumachinchose.
  - [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
    
    Posté par jigso le 12 octobre 2011 à 01:31. Évalué à 1.
    
    D'autant plus que les scripts sont inclus dans le navigateur via <script type="text/javascript"
    Qu'est-ce qui empêcherait de mettre type="text/parrot" pour les barbus, type="text/java" pour les frappadingues, type="text/basic" pour les nostalgiques, etc...
    
    Certes il faudrait faire un binding entre les objets du dom et les langages, mais on pourrait tout à fait imaginer un système de plugin de compilateur/interpréteur... Bon ça serait le bordel dès qu'on navigateur implémente un langage que les autres n'implémentent pas, mais le système est extensible.
- [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
  
  Posté par gasche le 11 octobre 2011 à 14:51. Évalué à 2.
  
  Le problème technique principal de LLVM c'est qu'il n'est pas portable (le bytecode produit dépend de l'architecture prise en compte par le compilateur en amont, et on ne génère pas le même bytecode vers des architectures différentes); de plus, sa sémantique est assez mal spécifiée, repose beaucoup sur les spécificités de C (forcément la force de travail autour de LLVM vient de Clang aujourd'hui).
  
  Ça n'empêche pas Brendan Eich de faire de la pub pour emscripten, l'évaluateur de bytecode LLVM codé en Javascript, mais aujourd'hui LLVM directement n'est pas une solution très viable pour cet usage (pour lequel il n'a pas été prévu).
  - [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
    
    Posté par Jux (site web personnel) le 11 octobre 2011 à 16:08. Évalué à 2.
    
    Apparement, l'équipe de NativeClient de Google travaille sur un bytecode intermédiaire qui permette justement de résoudre ce problème :
    http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
    
    Ceci dit, NativeClient fonctionne déjà sur x86/amd64/arm, ce qui représente une grosse partie des architectures utilisées aujourd'hui. Et puis si ils ont réussi à porter sur 3 architectures, y'a pas de raison que ça ne soit pas portable ailleurs.
    - [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
      
      Posté par gasche le 11 octobre 2011 à 16:34. Évalué à 4.
      
      Ceci dit, NativeClient fonctionne déjà sur x86/amd64/arm, ce qui représente une grosse partie des architectures utilisées aujourd'hui. Et puis si ils ont réussi à porter sur 3 architectures, y'a pas de raison que ça ne soit pas portable ailleurs.
      
      D'après ton document, la méthode utilisée par PNaCL pour obtenir cette portabilité est de viser l'intersection des choses supportées par ces trois architectures : que des adresses 32 bits, little-endian, un modèle mémoire ultra-rigide (sequential consistency), etc.
      
      Ça limite donc intrinsèquement sa portabilité : si demain l'architecture Quvz devient populaire et ne respecte pas ses présupposés, elle ne pourra pas utiliser (sans une couche d'émulation) les bitcodes LLVM générés pour PNaCL.
      
      Par ailleurs (mais ce n'est pas lié à ma remarque d'ordre général sur LLVM), le problème de NaCL c'est qu'il y a une interface très large et très lourde entre le processus NativeClient et le browser; elle dépend du fonctionnement de Chrome et n'est donc pas si portable que ça vers les autres browsers. Brendan Eich ne veut pas entendre parler de leur Pepper API et c'est donc un peu mort pour l'intégration dans Mozilla (et ce n'est pas seulement une question politique, le choix technique peut se comprendre, même s'ils pourraient faire des efforts pour essayer de faire changer ces aspects-là; ils ne sont pas intéressés).
- [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
  
  Posté par tyoup le 11 octobre 2011 à 23:11. Évalué à 1.
  
  Débugger de l'assembleur dans son navigateur va être sympa... Remplacer un langage de haut niveau par une vm bas niveau, je n'y crois pas trop. Par contre l'idée de les faire cohabiter est plutôt séduisante, ça ouvre le champ des possibilités.
  - [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
    
    Posté par __o le 12 octobre 2011 à 14:01. Évalué à 1.
    
    On débug très bien de l'assembleur dans gdb, alors pourquoi pas dans firebug ? Il faut juste que le programme embarque des informations de débug qui puisse faire correspondre un fichier sources et un numéro de ligne à une instruction. Biensûr certain pourront supprimer les informations de débug en prod pour que le programme reste léger en taille.
- [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
  
  Posté par tyoup le 12 octobre 2011 à 20:30. Évalué à 1.
  
  Tiens un truc rigolo auquel je viens de penser... Comment ça va se passer si le bytecode change de version (ok, c'est sûr, ça va pas arriver souvent...) ? Comment vont suivre les différents navigateurs ? Comment va-t-on servir les vieux navigateurs ? Votre avis m'intéresse.
  - [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
    
    Posté par barmic le 13 octobre 2011 à 08:38. Évalué à 3.
    
    Java a 16 ans et n'a, je crois, pas changé de bytecode (bien pour ça qu'il est à la version 1.7, non ?). C'est nettement plus stable que HTML/CSS/javascript.
    Tu peut toujours mettre le numéro de version dans le type mime.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
      
      Posté par djano le 08 novembre 2011 à 23:30. Évalué à 2.
      
      Euh le bytecode a changé. Quand je compile un programme compilé avec Java 5 il ne fonctionne pas avec un Java < 1.5 .
      Je suppose que tu voulais dire que le bytecode a une compatibilité ascendante?
      - [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
        
        Posté par windu.2b le 09 novembre 2011 à 08:51. Évalué à 2.
        
        Et je crois que, justement, il y a eu une cassure dans la compatibilité entre les versions 1.0 -> 1.1 ou 1.1 -> 1.2 (je sais plus) de Java...
        
        [^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
        
        Posté par djano le 13 novembre 2011 à 04:02. Évalué à 2.
        
        Ah bon? Bah, c’était la préhistoire :)
        Je suis arrivé a la programmation lorsque Java 1.4 était la.
        
        Mais certains projets Apache on la fâcheuse manie d'absolument vouloir compiler leur code avec Java 1.2 ou mois. Y a-t-il vraiment encore des gens qui compilent du code avec Java 1.2 ou moins et qui ont besoin que leur libs soient compilées avec cette même version?
# Ça pue…

Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 octobre 2011 à 10:22. Évalué à 8.
Je ne sais pas ce que vous en pensez, mais moi il y a un détail qui m'inquiète beaucoup :

Pour ma part, je trouve l’annonce de Dart très décevante. Google a visiblement développé un langage qui correspond à ses besoins (permettre de développer des applications comme GMail ou Google Maps), et en a perdu de vue le plus important : convaincre les autres navigateurs d’accepter Dart.

Vous souvient-il des débuts du Web et des extensions spécifiques incompatibles ? On en souffre encore aujourd'hui, avec des trucs comme Flash. Et après que Mozilla soit passé pour rétablir une situation plus ouverte, voici que Google a :
1. lancé et imposé de façon assez convaincante son navigateur, navigateur qui fait déjà quelques trucs bizarre (genre utiliser un cache DNS perso, voire interroger des serveurs de résolution spécifique…) ;
2. lancé et commencé à utiliser de leur côté un nouveau protocole SPDY ;
3. envisage de remplacer JavaScript pour leur usage personnel.
- [^] # Re: Ça pue…
  
  Posté par Jux (site web personnel) le 11 octobre 2011 à 10:34. Évalué à 10.
  
  Sauf que, contrairement à Flash et ActiveX, Dart et SPDY sont ont tous les deux une spec disponible. L'implémentation de Dart fournie par Google est également libre. Chromium est libre également. Je ne vois d'ailleurs pas en quoi Chrome ajoute une "extension spécifique incompatible".
  
  Bref, je ne vois rien d'inquiétant là-dedans. Il y a d'autres choses qui peuvent être inquiétantes chez Google, mais ça n'est pas du côté de leurs développement techniques.
  - [^] # Re: Ça pue…
    
    Posté par bilboa le 12 octobre 2011 à 00:21. Évalué à -1.
    
    Les specs de flash sont ouvertes depuis belle lurette.
    Les dévs techniques de Google permettent d'avoir la main mise sur le marché. Ils sont juste beaucoup plus fourbes que Microsoft.
    - [^] # Re: Ça pue…
      
      Posté par Jux (site web personnel) le 12 octobre 2011 à 00:43. Évalué à 6.
      
      Jusqu'en 2008, il était interdit d'utiliser les specs Flash pour écrire un programme qui lit les SWF ( http://en.wikipedia.org/wiki/SWF ). Flash remonte à bien plus longtemps que ça. Donc non, c'est pas exactement comparable avec un projet Open Source dès le départ.
- [^] # Re: Ça pue…
  
  Posté par CrEv (site web personnel) le 11 octobre 2011 à 10:54. Évalué à 7.
  
  lancé et commencé à utiliser de leur côté un nouveau protocole SPDY ;
  
  C'est vrai, on devrait donc plutôt attendre une évolution de HTTP. Heu, elle est où ? Elle arrive quand ?
  
  envisage de remplacer JavaScript pour leur usage personnel.
  
  Pas que, mais aussi de le remplacer pour l'usage de toutes les application se trouvant dans un navigateur.
  
  En gros, la question derrière : que propose-tu de ton côté ? La différence avec Google c'est que quand ils ont besoin de faire avancer les choses ils le font. Evidemment le but premier et de répondre à leurs besoin. Tu trouves ça anormal ?
  Ha oui, par contre, contrairement à d'autres boites, ils le font de manière ouverte. Moche, non ?
  
  Et sinon, je commence à voir des outils qui parlent SPDY (autre que Google).
  
  Et sinon, il faut aussi voir ce qu'ils ont fait de la vidéo/audio sous jabber.
  
  Le problème c'est que certains standards sont tellement ancrés qu'il ne se passe rien, qu'ils ne correspondent plus exactement aux besoins actuels, qu'on aimerait bien les améliorer mais à chaque fois que quelqu'un y touche c'est juste qu'un gros vilain !
  
  Et après que Mozilla soit passé pour rétablir une situation plus ouverte
  
  Heu, mozilla ils ont fait quoi pour de vrai pour flash ?
  - [^] # Re: Ça pue…
    
    Posté par Grunt le 11 octobre 2011 à 11:53. Évalué à 10.
    
    Pour SPDY et Dart, Google se fout largement de la gueule du monde.
    
    Ils ont largement contribué, par leur développement et leurs rachats, au fait de transformer le Web en pile TCP/IP à la con pour faire n'importe quoi (Youtube c'est Google, Gmail c'est Google, Etherpad c'est Google, + les "groupes Google" dont beaucoup d'utilisateurs ignorent que c'est plus ancien que le Web, les newsgroups..)
    
    Et maintenant ils se plaignent que javascript et HTTP sont trop lents, trop vieux, pas adaptés, et faut remplacer?
    
    Ok, très bien Google. Vous n'avez juste qu'à proposer, sur Youtube, un vrai protocole de diffusion de vidéo (genre RTSP, MMS..), à intégrer dans votre navigateur une association avec un lecteur de vidéo (un vrai lecteur de vidéo, pas un navigateur), à mettre votre propre lecteur vidéo dans ChromeOS. Et beaucoup de monde sera ravi de suivre le mouvement. Ça existe sur les smartphones, pourquoi pas les fixes? (pour l'anecdote, le client Youtube sous Android semble utiliser UDP pour récupérer les vidéos). Je serais le premier à me réjouir sur une "vidéo Youtube" se présentait sous la forme d'un lien mms:// suivi de la longue litanie habituelle de commentaires.
    
    Pareil pour Gmail: vous trouvez les navigateurs trop lents pour faire du mail? Ben continuez à proposer les accès SMTP/IMAP/POP, et remplacez l'interface Web de Gmail par un client mail. Un client Google qui marche que pour Gmail, si ça vous sied. Mais un vrai client mail, pas un navigateur. Ça existe sur les smartphone, pourquoi pas les fixes?
    
    Les chouineries ça va 5 minutes, on ne peut pas contribuer à bloater le Web et se plaindre qu'il rame.
    
    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
    - [^] # Re: Ça pue…
      
      Posté par NanoTech le 12 octobre 2011 à 00:21. Évalué à 9.
      
      Plusieurs technologies pour la même chose (JavaScript, NaCl, Dart), c'est que le Web est en train de montrer des signes de vieillesse. Si Dart s'impose, il est bien certain que les navigateurs devront supporter à la fois JavaScript et Dart, pour cause de rétro-compatibilité.
      
      Au final avec WebGL, les Canevas, Native Client, AJAX, DOM, CSSv3, le Web a perdu sa valeur initiale de simplicité et universalité, s'opposant aux réseaux fermés et lourds de l'époque.
      
      C'est devenu difficile de surfer sur le Web avec une machine aussi "vieille" qu'un Core 2 Duo disposant d'un système d'exploitation CentOS 5.x de 2007 (pourtant encore supporté) et d'une connexion 512 Kbits/sec.
      
      Est-il temps de revenir au Web 1.0 ?
  - [^] # Re: Ça pue…
    
    Posté par Prae le 11 octobre 2011 à 20:25. Évalué à -2.
    
    Heu, mozilla ils ont fait quoi pour de vrai pour flash ?
    
    Ils ont embauchés 3 pauvres gars qui font du HTML5 dans leurs coins.
    
    Bon, pendant ce temps, t'as les mecs de Google/Chrome qui te font une vidéo en 3D avec interaction qui est juste à pleurer de beauté ( http://www.ro.me/ )
    
    (Et je parle pas des extensions -moz bien à eux... j'ai l'impression de revoir les débuts des gue-guerres IE/Netscape avec leurs propres syntaxes HTML/JS ...)
    - [^] # Re: Ça pue…
      
      Posté par spider-mario le 11 octobre 2011 à 23:56. Évalué à 3.
      (Et je parle pas des extensions -moz bien à eux... j'ai l'impression de revoir les débuts des gue-guerres IE/Netscape avec leurs propres syntaxes HTML/JS ...)
      
      http://www.w3.org/TR/css3-syntax/
      
      Although proprietary extensions should be avoided in general, there are situations (experiments, implementations of W3C drafts that have not yet reached Candidate Recommendation, […] etc.) where it is convenient to add some nonstandard, i.e., proprietary identifiers to a CSS style sheet.
      
      A proprietary name should have a prefix […].
      
      Some examples (and the companies/organizations that created them):
      
      -moz-box-sizing, -moz-border-radius (The Mozilla Organization)
      
      -wap-accesskey (The WAP Forum)
      
      _xyz-dwiw (hypothetical)
  - [^] # Re: Ça pue…
    
    Posté par NanoTech le 16 octobre 2011 à 15:21. Évalué à 2.
    
    Plutôt que de créer un nouveau langage, on peut optimiser le langage existant.
    D'ailleurs, Google a déjà fait pas mal de boulot de ce côté là, avec les "classes implicites", la compilation de JavaScript en code natif et un ramasse-miettes générationnel.
    En plus, pour l'optimisation d'espace mémoire des tableaux, on a déjà les "tableaux typés".
    
    http://code.google.com/intl/fr/apis/v8/design.html
    
    Je n'arrive pas à retrouver l'article, mais j'avais vu un article montrant que pour un calcul brut comme la multiplication de matrice, V8 était seulement 3 fois plus lent que le C++. Ce n'est pas garanti que l'on puisse faire beaucoup mieux avec Draft.
    
    Si on rajoutait l'inférence statique de type, il serait possible d'obtenir des performances assez proche du code natif pour un programmeur un peu expérimenté écrivant du code se prêtant à ces optimisations. Ça me paraît plus facile que de développer en parallèle une version Draft et une version JavaScript de la même application.
    
    Après, là où il y a encore énormément de boulot, que ce soit en JavaScript ou Draft, c'est au niveau du Document Object Model et canevas, mais là, les performances dépendent plus du moteur HTML/CSS que du JavaScript lui-même.
    - [^] # Re: Ça pue…
      
      Posté par NanoTech le 16 octobre 2011 à 15:22. Évalué à 0.
      
      s/Draft/Dart/g
      
      Désolé.
- [^] # Re: Ça pue…
  
  Posté par Emmanuel C le 11 octobre 2011 à 17:04. Évalué à 4.
  
  Pour infos, en lisant la FAQ de SPDY :
  
  Q: Is SPDY a replacement for HTTP?
  
  A: No. SPDY replaces some parts of HTTP, but mostly augments it. At the highest level of the application layer, the request-response protocol remains the same. SPDY still uses HTTP methods, headers, and other semantics. But SPDY overrides other parts of the protocol, such as connection management and data transfer formats.
  
  En comme on est sur linuxfr :
  
  Q : SPDY est-il un remplacement de HTTP ?
  
  R : Non. SPDY remplace certaines parties de HTTP, mais ne fait principalement que l'augmenter. Au plus haut niveau de la couche application, le protocole de requête-réponse reste le même. SPDY utilise toujours les méthodes HTTP, ses entêtes, et sa sémantique. Mais SPDY supplante d'autres aspects du protocole, comme la gestion des connexions et les formats de transfert de données.
  
  Bref, on a affaire à un nouveau protocole qui porte clairement un nom différent de HTTP, qu'on ne peut pas confondre, mais qui s'inspire de ce qui marche déjà.
  - [^] # Re: Ça pue…
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 octobre 2011 à 17:38. Évalué à 0.
    
    Franchement, j'adore cette explication. SPDY est-il un remplacement de HTTP, donc ? Non, pas du tout, il remplace HTTP. Sans commentaire.
    - [^] # Re: Ça pue…
      
      Posté par Emmanuel C le 11 octobre 2011 à 18:13. Évalué à 2.
      
      C'était juste pour préciser que ce n'était pas un nouveau protocole qui venait de nul part et sans intégration dans l'existant, mais plutôt une réflexion sur une possible évolution de HTTP...
- [^] # Re: Ça pue…
  
  Posté par 태 (site web personnel) le 11 octobre 2011 à 18:21. Évalué à 3.
  
  Je partage cette peur, j'ajoute https://plus.google.com/not-supported/?ref=/ qui dit "Your browser is no longer supported." quand on n'utilise ni chromium ni firefox. Google est prêt à fermer le web.
  - [^] # Re: Ça pue…
    
    Posté par Sytoka Modon (site web personnel) le 11 octobre 2011 à 18:33. Évalué à 4.
    
    Eh bien fermons la porte à Google !
# Commentaire supprimé

Posté par Anonyme le 11 octobre 2011 à 10:25. Évalué à 10.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: GNOME Shell en Dart ?
  
  Posté par GEDsismik (site web personnel) le 11 octobre 2011 à 10:49. Évalué à 2.
  
  Ce qui est marrant, c'est qu'il y a quelques années, js était fortement déconseillé et décrié. Et maintenant, avec de l'ajax et tout le toutim, tout le monde y revient :S
  - [^] # Re: GNOME Shell en Dart ?
    
    Posté par Jux (site web personnel) le 11 octobre 2011 à 11:14. Évalué à 6.
    
    J'ai l'impression que ce qui est à la mode, c'est surtout les applications dans le navigateur. JS est aujourd'hui le seul moyen d'en développer et donc on est bien obligé de passer par là. Mais je n'ai pas franchement l'impression que JS en tant que tel est très populaire. Dès qu'on cherche à faire de la POO, il faut tout gérer soi-même et ça devient vite bordélique.
    
    Vu la soit-disante popularité de JS sur le web (mais de nouveau, c'est pas tant le langage que la plateforme qui est populaire), on essaie de récupérer les développeurs dans d'autres domaines.
  - [^] # Re: GNOME Shell en Dart ?
    
    Posté par cpc6128 (site web personnel) le 11 octobre 2011 à 14:30. Évalué à -1.
    
    C'est là que Google est fort.
    On utilise de plus en plus javascript car le web devient omniprésent grâce (~~à cause de~~) aux smartphones et les interfaces utilisant CSS et Javascript (Gnome 3 par exemple).
    C'est aujourd'hui qu'il faut proposer un nouveau langage et l'imposer. Google peut le faire avec la Chrome qui arrive en force et Android.
  - [^] # Re: GNOME Shell en Dart ?
    
    Posté par Prae le 11 octobre 2011 à 20:28. Évalué à 4.
    
    Ola Ged !
    
    Le problème avec JS c'est qu'au début, tout le monde l'utilisait pour faire de la merdasse en barre (aaahh Geocities et ses sites en JS ou DHTML...)
    Maintenant, les mecs font cela clean et beau. (niveau code c'est clean et ca déborde pas; et on l'utilise pour faire des trucs utiles et/ou beau)
    C'est là toute la différence. Donc les gens en sont revenus (moi le premier)
- [^] # Re: GNOME Shell en Dart ?
  
  Posté par Damien (site web personnel) le 11 octobre 2011 à 13:13. Évalué à 2.
  
  Il y a du JS dans le bureau de Mac OS X ? où ?
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 12 octobre 2011 à 09:32. Évalué à 2.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# Quelles erreurs

Posté par Kyoku57 (site web personnel) le 11 octobre 2011 à 10:54. Évalué à 5.

Je lis :

souffrirait d’erreurs de jeunesse irréparables

Lesquelles ?

PS : Ce n'est pas un troll, j'utilise Javascript de manière "superficielle" et j'aimerais vraiment savoir ce qui bloque les développeurs très expérimentés avec ce langage.
- [^] # Re: Quelles erreurs
  
  Posté par CrEv (site web personnel) le 11 octobre 2011 à 10:58. Évalué à 4.
  
  la gestion du scope par exemple
  le modèle objet intéressant mais loin d'être parfais
  la parallélisation
  - [^] # Re: Quelles erreurs
    
    Posté par Guillaume Denry (site web personnel) le 11 octobre 2011 à 11:02. Évalué à 4.
    
    Les scopes en JavaScript c'est quelque chose de difficile à prendre en main mais c'est assez puissant. Tu leur reproches quoi exactement ?
    - [^] # Re: Quelles erreurs
      
      Posté par CrEv (site web personnel) le 11 octobre 2011 à 11:06. Évalué à 3.
      
      Que c'est chiant à utiliser dans la majorité des cas. Il faut se trimbaler des binds en permanence, etc.
      Evidemment une fois que tu as vraiment compris tu peux t'en servir pour faire des trucs tordus (= puissant quoi) mais pour la majorité des cas c'est une contraire plus qu'autre chose et ça montre surtout un modèle objet perfectible.
      - [^] # Re: Quelles erreurs
        
        Posté par Guillaume Denry (site web personnel) le 11 octobre 2011 à 11:11. Évalué à 2.
        
        Et tu imagines quoi comme fonctionnement alternatif ? C'est une vraie question, j'ai probablement trop le nez dedans mais j'ai énormément de mal à voir comment on pourrait se passer de cela sans changer fondamentalement le fonctionnement de JavaScript.
        
        [^] # Re: Quelles erreurs
        
        Posté par CrEv (site web personnel) le 11 octobre 2011 à 11:14. Évalué à 5.
        
        En changeant fondamentalement le fonctionnement de JavaScript.
        
        Tu vois, tu avais la réponse ;-)
        
        Le problème est un problème de design de javascript (à mon avis) et c'est bien pour ça qu'on parle
        
        d’erreurs de jeunesse irréparables
    - [^] # Re: Quelles erreurs
      
      Posté par Moonz le 11 octobre 2011 à 13:51. Évalué à 3.
      
      Que le mot clé "var" ne soit pas là par défaut, ça suffit à en faire un truc moisi et ignoble à éviter à tout prix.
- [^] # Re: Quelles erreurs
  
  Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 12:27. Évalué à 10.
  J'ai utilisé le conditionnel car je ne suis pas sûr qu'il y ait vraiment des erreurs dans JS qui puissent être réparées. Mais voici quelques erreurs de jeunesse :
  - l'absence de classe (les prototypes sont très déroutants) ;
  - problème avec this : setTimeout(foo.bar, 10) -> la méthode bar va être appelée avec this == window et pas foo comme on pourrait l'espérer ;
  - pollution de l'espace global : si on oublie de déclarer une variable avec var, elle devient une variable globale, alors qu'il serait préférable d'en faire une variable locale ;
  - l'opérateur == n'est pas transitif et fait appel à la coercition, ce qui conduit à de nombreux WTF! ;
  - il est trop difficile de parcourir les attributs d'un objet ;
  - il est difficile d'écrire des chaînes de caractères de plusieurs lignes en incluant des variables dedans (des templates).
  Mais, pour ma part, j'ai trouvé une solution à ces problèmes qui me convient bien : CoffeeScript.
  - [^] # Re: Quelles erreurs
    
    Posté par Kyoku57 (site web personnel) le 11 octobre 2011 à 13:19. Évalué à 2.
    
    Merci pour ces références. Effectivement, je comprends mieux la rogne :)
  - [^] # Re: Quelles erreurs
    
    Posté par 2PetitsVerres le 11 octobre 2011 à 14:43. Évalué à 9.
    
    Je n'ai pas fait beaucoup de javascript dans ma vie, mais autant je suis d'accord avec toi pour tous les derniers points, autant pour le premier, je ne suis pas vraiment d'accord. Enfin, je comprend le les prototypes sont très déroutants, mais c'est intéressant quand même. C'est un autre type de langage objet, mais j'ai l'impression que ce serait comme dire "C, c'est pas bien parce que ce n'est pas objet" ou "erlang, ce serait mieux si c'était de l'impératif et pas du fonctionnel". Non ?
    
    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
  - [^] # Re: Quelles erreurs
    
    Posté par pasScott pasForstall le 12 octobre 2011 à 07:19. Évalué à 0.
    
    Rajoutes aussi "pas de scope limite aux blocks", ce qui peut faire des blagues sympa avec des closures dans une for loop.
    
    C'est pas la fin du monde, mais ca fait facilement perdre une apres midi, plus 1h00 le lendemain au cafe en testant les collegues.
    
    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# Quelles sont les erreurs irréparables de JS réparées par Dart ?

Posté par dinomasque le 11 octobre 2011 à 10:55. Évalué à 6.

Parceque si le seul problème de JS c'est le manue de ";" à la fin des lignes, ça fait un peu léger comme "problème irréparable".

BeOS le faisait il y a 20 ans !
- [^] # Re: Quelles sont les erreurs irréparables de JS réparées par Dart ?
  
  Posté par zebra3 le 11 octobre 2011 à 11:26. Évalué à 8.
  
  Le nom est trop proche de Java, ça fait lourd.
  
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: Quelles sont les erreurs irréparables de JS réparées par Dart ?
    
    Posté par Fabimaru (site web personnel) le 11 octobre 2011 à 15:32. Évalué à 4.
    
    Je propose un autre nom pour Dart: "Javajavascript". Ca fera encore plus sérieux.
- [^] # Re: Quelles sont les erreurs irréparables de JS réparées par Dart ?
  
  Posté par Prae le 11 octobre 2011 à 20:32. Évalué à 3.
  
  Surtout que l'auteur (de la news) donne comme exemple un langage où l'indentation est obligatoire... ca fait encore plus sérieux...
- [^] # Re: Quelles sont les erreurs irréparables de JS réparées par Dart ?
  
  Posté par bilboa le 12 octobre 2011 à 00:23. Évalué à 3.
  
  Not Invented Here. <= erreur de jeunesse irréparable.
# Un changement intéressant aussi: des vrais entier

Posté par reno le 11 octobre 2011 à 11:16. Évalué à 5.

Si je ne me trompes pas en JavaScript, tout les nombres sont des flottants ce qui conduit parfois a des comportements très bizarre (genre x+1 est égal à x), zlors que Dart a des entiers type 'big int' et des flottants sur 64 bit.

Je ne sais pas si en pratique c'est vraiment un problème pour les programmeurs JavaScript, mais cela me parait beaucoup plus sain comme comportement..
- [^] # Re: Un changement intéressant aussi: des vrais entier
  
  Posté par reno le 11 octobre 2011 à 11:17. Évalué à 6.
  
  Et beaucoup plus important comme changement que le ';'!
- [^] # Re: Un changement intéressant aussi: des vrais entier
  
  Posté par 태 (site web personnel) le 11 octobre 2011 à 18:42. Évalué à 2.
  
  Les nombres de javascript sont des double, non ? On se retrouve plus vite à avoir x+1 < x avec des entiers 32 bits que x+1 == x (ou n'importe quelle aberration) avec les pseudo-entiers javascripts. C'est sur que ça ne vaut pas les big int, mais bon...
# Python

Posté par tuxicoman (site web personnel) le 11 octobre 2011 à 11:20. Évalué à 3.

C'est quoi le problème avec python comme langage de script?
- [^] # Re: Python
  
  Posté par reno le 11 octobre 2011 à 11:34. Évalué à 5.
  
  Par rapport à Dart: ne supporte pas le typage optionel (bon je sais il y a Cython), multi-threadé vs mono-threadé (a la Erlang) ce qui doit ralentir la VM.
  Par rapport à Javascript: pas implémenter par les navigateurs!
- [^] # Re: Python
  
  Posté par totof2000 le 11 octobre 2011 à 12:39. Évalué à 4.
  
  C'est un langage tout pourri qui nous a envahi suffisamment pour passer à autre chose ?
  
  Un manque de cohérence dans le langage (la plus grosse incohérence à mon avis est la nécessité de se répéter lorsqu'on écrit la moindre fonction, le moindre objet, tout en ayant du duck typing).
  
  Pour moi Ruby et Ada sont plus cohérents.
  - [^] # Re: Python
    
    Posté par reno le 11 octobre 2011 à 13:42. Évalué à 6.
    
    Je trouve amusant de soutenir Ada lors d'une critique sur la nécessité de se répéter: il me semble qu'Ada n'a pas l'inférence de type locale, non?
    - [^] # Re: Python
      
      Posté par Sytoka Modon (site web personnel) le 11 octobre 2011 à 14:13. Évalué à 4.
      
      Ada oblige à faire des fichiers d'en tête (comme C) assez pénible à force. En fortran, ces fichiers sont générés automatiquement (.mod) et c'est bien plus pratique.
    - [^] # Re: Python
      
      Posté par totof2000 le 11 octobre 2011 à 16:27. Évalué à 4.
      
      ADA nécessite de tout spécifier, et est très tatillon sur les types que tu utilises. Le langage est cohérent dans le sens ou il a été concu pour que le plus d'erreurs soient remontées à la compilation et le moins possible à l'exécution, et là ça a un sens de se répéter, parce que le but est de bien savoir ce que tu fais.
      
      Siu python était plus strict sur le typage par exemple (et sur d'autres choses), je le trouverais déjà plus cohérent, et ça me gènerait moins.
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 11 octobre 2011 à 14:08. Évalué à 0.
    
    Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Python
      
      Posté par totof2000 le 11 octobre 2011 à 16:31. Évalué à 2.
      
      Je ne comprends pas ton analogie et ce que tu reproches à ADA.
- [^] # Re: Python
  
  Posté par nud le 12 octobre 2011 à 11:34. Évalué à 4.
  
  Je suis pas certain que dans le contexte de code intégré dans du XML/HTML, la syntaxe du python, qui dépend des espaces, soit la plus adaptée.
  - [^] # Re: Python
    
    Posté par wilk le 12 octobre 2011 à 13:02. Évalué à 2.
    
    C'est l'intégration de code (dans du xml) tout court qui n'est pas aisée ! De fait, dès que le code dépasse 2 lignes généralement il est dans un fichier à part. Au pire il est dans les balises script et il a plutôt intérêt à être correctement indenté, que ce soit indispensable ou non.
# Commentaire supprimé

Posté par Anonyme le 11 octobre 2011 à 11:40. Évalué à 2.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: au point ou on en est
  
  Posté par Grunt le 11 octobre 2011 à 12:03. Évalué à 10.
  
  Et puis, les applis Web pourraient stocker des fichiers en local, des paramètres de réglage. Les gens lanceraient leur navigateur depuis le BIOS, le navigateur reconnaitrait le hardware et chargerait les pilotes, puis l'utilisateur se connecterait avec son compte sur le navigateur.
  
  Ensuite, depuis le navigateur, on pourrait installer des tas d'applications Web. Elles pourraient stocker des fichiers, accéder au réseau, garder des paramètres en mémoire, modifier certains paramètres du navigateur..
  
  C'est tellement génial que je me demande pourquoi personne ne l'a inventé.
  
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
  - [^] # Re: au point ou on en est
    
    Posté par Bruno Michel (site web personnel) le 11 octobre 2011 à 12:32. Évalué à 4.
    
    on pourrait installer des tas d'applications Web.
    
    Le principal avantage des applications Web est justement qu'il n'y a pas besoin de les installer / mettre à jour. Du coup, les développeurs peuvent corriger très rapidement les bugs, ajouter des fonctionnalités et ne pas avoir à gérer des anciennes versions.
    
    C'est tellement génial que je me demande pourquoi personne ne l'a inventé.
    
    Ça existe : Chrome OS, JoliCloud, etc.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 11 octobre 2011 à 12:36. Évalué à 1.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: au point ou on en est
        
        Posté par Guillaume Denry (site web personnel) le 11 octobre 2011 à 14:45. Évalué à 2.
        
        Je crois qu'il ne parlait pas des bugs du browser, mais des applis web.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 11 octobre 2011 à 15:55. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: au point ou on en est
        
        Posté par NanoTech le 12 octobre 2011 à 20:48. Évalué à 1.
        
        Sans compter que grâce aux mises à jour des applications Web, on se rend compte tous les mois que:
        1) L'interface utilisateur a changé. Il faut la réapprendre. Parfois elle devient toute pourrie.
        2) Ton navigateur n'est plus supporté.
        3) Faut activer une nouvelle bouse^Wfeature comme "local storage" ou WebGL.
        4) Ça bouffe encore plus de bande passante.
        5) Il faut réécrire tous tes scripts qui extrayaient tant bien que mal les données utiles du service.
        6) Des nouveaux bogues sont implémentés.
        
        [^] # Re: au point ou on en est
        
        Posté par CrEv (site web personnel) le 12 octobre 2011 à 21:02. Évalué à 5.
        
        C'est vrai, lorsqu'on a une application "lourde" on a jamais les cas suivant lors d'une mise à jour :
        
        1) L'interface utilisateur a changé. Il faut la réapprendre. Parfois elle devient toute pourrie.
        2) Ton système n'est plus supporté (version de dépendance, des interpréteurs, langages, lib, etc)
        3) Faut dépendre d'une nouvelle bouse^W feature comme la carte graphique pour accélérer l'affichage ou gconf.
        4) Ca bouffe encore plus de cpu/ram/hdd
        5) Il faut réécrire tous tes scripts qui extrayaient tant bien que mal les données utiles du logiciel planquées dans un format fermé et non interopérable. Les anciennes sauvegardes ne fonctionnent plus non plus.
        6) Des nouveaux bogues sont implémentés.
        
        [^] # Re: au point ou on en est
        
        Posté par NanoTech le 12 octobre 2011 à 21:55. Évalué à 2.
        
        La grosse différence c'est que pour les applications "lourdes", on a le choix de rester à l'ancienne version ou de passer à la nouvelle.
        
        Surtout pour le logiciel libre pour lequel on peut continuer à recompiler et modifier selon ses goûts l'ancienne version.
        
        [^] # Re: au point ou on en est
        
        Posté par CrEv (site web personnel) le 12 octobre 2011 à 22:59. Évalué à 2.
        
        pfiou, c'est vrai, j'ai oublié un point :
        Ca arrive aussi d'avoir des clients lourds qui nécessite une version spécifique d'un composant, d'un serveur auquel il se connecte, etc. En fait, rien ne change vraiment entre client lourd / léger, tout est toujours affaire de politique, volonté et décisions
        
        [^] # Re: au point ou on en est
        
        Posté par barmic le 13 octobre 2011 à 08:43. Évalué à 2.
        
        Parfois elle devient toute pourrie.
        
        Merci pour cette bonne fois affichée. C'est vrai que c'est bien connu, dans le monde du web contrairement à ailleurs, l'interface est toujours mieux à vent.
        
        5) Il faut réécrire tous tes scripts qui extrayaient tant bien que mal les données utiles du service.
        
        Ouai sauf que l'on parle d'application web et pas de sites web tout simples fait sur le pouce. Donc en principe si ce besoin existe il existe une API webservice pour faire ça et il y a une palanquée de tests de non régression pour assuré la continuité de ceux-ci.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: au point ou on en est
        
        Posté par zebra3 le 13 octobre 2011 à 10:52. Évalué à 3.
        
        Merci pour cette bonne fois affichée. C'est vrai que c'est bien connu, dans le monde du web contrairement à ailleurs, l'interface est toujours mieux à vent.
        
        Non non, dans tous les domaines l'interface était bien mieux à vent.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: au point ou on en est
      
      Posté par barmic le 11 octobre 2011 à 14:22. Évalué à 7.
      
      Le principal avantage des applications Web est justement qu'il n'y a pas besoin de les installer / mettre à jour. Du coup, les développeurs peuvent corriger très rapidement les bugs, ajouter des fonctionnalités et ne pas avoir à gérer des anciennes versions.
      
      Comme quoi c'est bien foutu java web start.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: au point ou on en est
        
        Posté par Raphaël G. (site web personnel) le 11 octobre 2011 à 22:10. Évalué à -2.
        
        C'est si bien foutu que ça permet à des gens comme dell d'embarquer dans des .jar des librairies binaires en .so/dll !!!
        
        Arrêtez sérieusement avec java web start, c'est au même niveau que Flash, une bouse infâme a éradiquer !
        
        A noter que je ne tiendrais pas ce discours si java n'avais pas été :
        javaçapuecestpaslibre
        Et à présent :
        javacestdenouveaupluslibreettuvasteprendreunprocès
        
        [^] # Re: au point ou on en est
        
        Posté par barmic le 12 octobre 2011 à 10:26. Évalué à 3.
        
        C'est si bien foutu que ça permet à des gens comme dell d'embarquer dans des .jar des librairies binaires en .so/dll !!!
        
        Java c'est mal parce que tu peu faire du natif ?
        
        Arrêtez sérieusement avec java web start, c'est au même niveau que Flash, une bouse infâme a éradiquer !
        
        Tu as raison, il n'existe pas de JVM libre, on a aucun documentation du langage, dès qu'on est sur autre chose que du x86 ça ne marche pas …
        
        A noter que je ne tiendrais pas ce discours si java n'avais pas été :
        javaçapuecestpaslibre
        Et à présent :
        javacestdenouveaupluslibreettuvasteprendreunprocès
        
        :) il est mignon. C'est l'usage du langage Java avec un runtime complètement différent des spec qui a était attaqué. Ça ne rend pas Oracle plus gentil, c'est juste que ça n'a pas de rapport avec le cas d'utilisation. Tu aurais était plus crédible en parlant des conditions d'usage du TCK (Technology Compatibility Kit), mais pour ça il aurait probablement fallu que tu sache de quoi tu parle :) ⸮
        
        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 le 11 octobre 2011 à 12:34. Évalué à 2.
    
    Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: au point ou on en est
    
    Posté par totof2000 le 11 octobre 2011 à 12:40. Évalué à 6.
    
    Ca s'appelle EMACS.
# déçu aussi, mais confiant

Posté par manatlan (site web personnel) le 11 octobre 2011 à 11:41. Évalué à 3.

J'attendais beaucoup ... et j'ai également été un peu déçu, hier soir.
Je m'attendais à qqchose de plus révolutionnaire, genre un "go" language ...
Et on se retrouve avec du classique de chez classique. C'est certain que ça pourrait grandement facilité le développement côté client, pour les personnes allergiques aux JS et provenant du monde c#/java. De ce point de vue là : ça ne peut être qu'un "plus". L'adoption sera grandement facilité.
L'idée du typage optionnel est excellente.
J'ai bien peur que ça prenne ... Si les apis suivent (et là google est généralement au top), et qu'une vm soit dispo rapido, ça pourrait prendre ailleurs (que juste dans le navigateur)
- [^] # Re: déçu aussi, mais confiant
  
  Posté par devnewton 🍺 (site web personnel) le 11 octobre 2011 à 12:09. Évalué à 2.
  
  L'idée du typage optionnel est excellente.
  
  Je n'ai jamais compris l'intérêt du non typage...
  
  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: déçu aussi, mais confiant
    
    Posté par totof2000 le 11 octobre 2011 à 12:40. Évalué à 10.
    
    Pauvre type !!!
  - [^] # Re: déçu aussi, mais confiant
    
    Posté par Michaël (site web personnel) le 11 octobre 2011 à 12:50. Évalué à 3.
    Je n'ai jamais compris l'intérêt du non typage...
    
    Un langage faiblement ou pas typé permet une forme de polymorphisme n'existant pas en tant que telle dans les autres langages: une fonction peut adapter son comportement à la structure de son argument.
    
    Des exemples typiques de langages faiblement typés permettant ce type de polymorphism sont Scheme (ou Lisp) et Perl, qui définissent des types simples (nombres, chaînes de caractères) et de types complexes (listes, dictionnaires) permettant de représenter des structures de données complexes: mais à la différence d'un langage fortement typé comme Caml, le langage range dans un même panier les listes de nombres, de caractères, les listes mixtes, etc.
    
    En pratique cela permet:
    1. La création de procédures de sérialisation et déserialisation particulièrement simples, ce point est modérément intéressant parceque de nombreux langages offrent des outils adaptés réalisant ces opérations.
    2. Coder une information de plusieurs façons différentes.
      Par exemple, imaginons un mail user agent codé en Scheme dont la procédure de tri des messages admet un paramètre qui peut être:
      
      une liste de paires mot-clef, dossier et le sujet de chaque message est comparé successivement aux mot-clef et en cas de succès, le message est déplacé dans le dossier correspondant.
      
      une structure plus complexe permettant de filtrer selon plusieurs en-têtes;
      
      une fonction quelconque prenant un message et renvoyant le dossier où il doit être placé. Dans un point de vue d'un langage objet objet, on a ici une classe trieur de message et trois constructeurs: la différence avec ce point de vue est qu'ici la bureaucratie est laissée au programmeur et l'utilisateur qui configure le tri de ses mails est confronté à une solution qui s'adapte à son niveau en programmation.
    3. Le non typage permet aussi d'écrire des procédures à nombre d'arguments variables ou avec des arguments optionnels, ce qui nécessite souvent dans les langages typés des mécanismes particuliers (on a souvent une syntaxe spéciale pour les arguments optionnels, par exemple).
    Mon goût personnel pour programmer va cependant aux langages fortement typés, mais pour un langage de configuration ou d'extension, un langage pas très typé (comme Scheme) me paraît un choix intéressant.
    - [^] # Re: déçu aussi, mais confiant
      
      Posté par Damien (site web personnel) le 11 octobre 2011 à 13:25. Évalué à 3.
      
      Pinaillage: Dart est fortement typé, autant que Ruby ou Smalltalk. Un objet donné en mémoire signifie toujours la même chose. Il est juste dynamiquement fortement typé, avec déclaration et vérification statique rendues optionnelle.
      
      Un langage non typé, ou faiblement typé, c'est un langage où une même représentation en mémoire peut avoir plusieurs sémantiques comment on s'en sert (donc par exemple l'assembleur, ou le C à cause des casts). NB les casts en C ne sont pas les mêmes qu'en Java, qui est fortement et statiquement typé.
    - [^] # Re: déçu aussi, mais confiant
      
      Posté par Kyoku57 (site web personnel) le 11 octobre 2011 à 13:27. Évalué à 2.
      
      Alors au risque de passez pour une quiche (remarquez pour un lorrain), j'ai cru comprendre que la notion de typage fort, typage faible ne voulait rien dire du tout.
      
      Soit le typage est dynamique (python, javascript, ...), soit le typage est statique (C, C++, Java, ...).
      
      Du coup, qu'appelons nous typage fort ou faible pour un langage donné ? Je partirais du principe que c'est au programmeur d'avoir la liberté de bien nommer ses variables pour ne pas avoir à "deviner" son type via l'IDE ou un fichier de définition. Mais bon, je peux me tromper aussi.
      - [^] # Re: déçu aussi, mais confiant
        
        Posté par Kyoku57 (site web personnel) le 11 octobre 2011 à 13:31. Évalué à -1.
        
        J'ai eu ma réponse. Merci :D
      - [^] # Re: déçu aussi, mais confiant
        
        Posté par Moonz le 11 octobre 2011 à 14:00. Évalué à 6.
        
        Un typage faible c’est quand les conversions se font implicitement.
        
        5 + "5", en Python, te donne une erreur : typage fort
        5 + "5", en PHP, te renvoie 55 : typage faible
        
        [^] # Re: déçu aussi, mais confiant
        
        Posté par Kyoku57 (site web personnel) le 11 octobre 2011 à 14:17. Évalué à 0.
        
        Oki, merci d'avoir éclairer le tunnel de mon incompréhension abyssale :D
        
        [^] # Re: exemples de typages
        
        Posté par rogo le 11 octobre 2011 à 16:58. Évalué à 1.
        
        5 + "5", en PHP, te renvoie 55 : typage faible
        
        Erreur ! L'opérateur + est un opérateur d'addition en PHP tandis que la concaténation est marquée par . (syntaxe reprise de Perl).
        
        $ php -r 'echo (5 + "5");' 10
        
        Par contre, c'est vrai pour le JS : l'opérateur + dépend du contexte, donc 5 + "5" donne bien "55".
        
        Sur le fond, c'est du typage faible et dynamique pour ces deux langages.
        
        [^] # Re: déçu aussi, mais confiant
        
        Posté par qstone le 12 octobre 2011 à 15:04. Évalué à 6.
        
        Aaah, alors Java c'est du typage faible !
        
        Long nb=5;
        log.info(nb+"5"); // affiche 55
    - [^] # Re: déçu aussi, mais confiant
      
      Posté par gasche le 11 octobre 2011 à 16:20. Évalué à 3.
      Je ne suis pas convaincu par ton argumentation, dans les sens où tes trois points me semblent faux.
      
      La facilité de la sérialisation dépend avant tout d'un choix d'implémentation du langage, celui de trimballer ou pas de l'information de typage au runtime. Les langages objets ont tendance à le faire (entre autres parce parce que leurs systèmes de typage souvent incorrects ne suffisent pas et il faut parfois un garde-fou dynamique), les langages fonctionnels ne le font souvent pas par défaut (on peut l'encoder par dessus, cf. Data.Typeable en Haskell). Les langages qui ont cette information sont favorisés, qu'ils soient statiquement typés ou non.
      
      Un type algébrique à la ML (ou une hiérarchie de classe si tu veux du lourd) permet(tent) de représenter un valeur qui peut avoir plusieurs formes différentes. Si tu veux cacher cette conversion (mot-clé -> truc-paramètre-de-filtrage), tu peux utiliser des conversions implicites; ce n'est en rien incompatible avec le typage statique (cf. les implicites de Scala).
      
      Je ne vois pas en quoi la présence ou non de typage statique change le statut des arguments optionnels. Une fonction précise combien d'arguments elle attend, éventuellement des valeurs par défaut pour ses arguments, et c'est la sémantique opérationnelle (à l'exécution) qui précise ce qui se passe si un argument n'est pas fourni. Le typage statique ne pose aucun problème. Il peut par contre parfois être un peu utile, quand on utilise des formes de surcharge basées sur le typage : par exemple si la fonction attend un entier, une chaîne de caractères et un objet, on peut l'appeler en passant seulement l'entier et l'objet, et le typeur comprend que c'est la chaîne de caractères qui n'a pas été renseignée. Je ne dis pas que c'est une bonne idée, mais qu'à priori le typage "aide" les arguments optionnels plus qu'il ne les gêne.
      
      Pour les fonctions à nombre d'argument multiple, on peut en fait typer ça correctement (après la façon de typer dépend de la façon dont la fonction utilise ses arguments), mais le fait est que ça ne fait pas partie de la plupart des langages de programmation typé. C'est bien le seul point de ton argumentaire qui me semble recevable, sachant que par ailleurs je n'aime pas trop les fonctions à nombre d'argument multiple et je pense qu'il y a souvent moyen de faire mieux et plus propre en s'en passant (si le langage est suffisamment expressif).
      
      Ceci dit je ne suis pas fondamentalement contre l'utilisation de Scheme/Racket/Guile comme langage de configuration (si on pouvait éviter Elisp par contre, qui n'est de loin pas le Lisp le plus réussi). C'est juste que je ne vois pas d'argument conseillant, dans l'absolu, d'éviter les langages ayant du typage statique.
      - [^] # Re: déçu aussi, mais confiant
        
        Posté par Michaël (site web personnel) le 11 octobre 2011 à 18:43. Évalué à 2.
        
        La facilité de la sérialisation dépend avant tout d'un choix d'implémentation du langage, celui de trimballer ou pas de l'information de typage au runtime. […]
        
        Ce que je voulais dire, c'est que dans les langages que j'ai cités, la sérialisation est facile à implémenter dans les termes du langage et n'a pas besoin d'être prise en charge directement par le langage.
        
        Pour les deux autres points, je ne voualais pas tant pointer des différences d'expressivité dans les familles de langages que les moyens mêmes de cette expressivité: par exemple dans le langage OCaml, les arguments optionnels sont un concept du langage et ont une notation syntaxique spéciale tandis qu'en Perl ou Scheme les arguments optionnels son un concept d'implémentation: c'est la fonction appellée qui va explicitement examiner la forme de son argument pour déterminer si des arguments optionnels sont là ou pas.
  - [^] # Re: déçu aussi, mais confiant
    
    Posté par reno le 11 octobre 2011 à 13:33. Évalué à 2.
    
    Historiquement parlant le typage dynamique (ce qui est très différence du "non typage") avait le gros avantage de faire du code plus court et plus lisible: pas besoin de répéter le type partout dans les déclarations de variable, ni de dupliquer du code pour la surcharge de fonctions.
    
    Bon cet avantage a été quasiment annuler par 2 choses:
    1- l'inférence de type ce qui permet d'éviter de déclarer le type des variables dans beaucoup de cas
    2- les templates/generic qui permettent d'écrire une fonction qui sera appliqué a plusieurs types.
    
    Ceci dit je trouve qu'en C++, les templates c'est plus pénible a lire qu'une fonction équivalente dans un langage a typage dynamique à cause de la syntaxe lourde, j'ignore s'il existe un langage statiquement typé avec une syntaxe agréable pour les templates/generic mais si c'est possible alors je ne vois effectivement plus d'intérêt pour les langages à typage dynamique..
    - [^] # Re: déçu aussi, mais confiant
      
      Posté par ecyrbe le 11 octobre 2011 à 14:30. Évalué à 5.
      Le langage D?
      
      Typage statique.
      
      Garbage collector
      
      Templates lisibles
      
      mixins
      
      etc
      - [^] # Re: déçu aussi, mais confiant
        
        Posté par reno le 11 octobre 2011 à 16:03. Évalué à 1.
        
        Dans le etc, tu oublie quand même: implémentations pas forcément matures, syntaxe pas mal mais pas terrible par rapport à Scala.
        
        Mais oui, D2 me paraît pas intéressant.
        
        [^] # Re: déçu aussi, mais confiant
        
        Posté par jiyuu le 11 octobre 2011 à 18:44. Évalué à 3.
        
        Mais oui, D2 me paraît pas intéressant.
        
        Je crois que tu as un mot.
        
        [^] # Re: déçu aussi, mais confiant
        
        Posté par reno le 11 octobre 2011 à 22:24. Évalué à 2.
        
        Oups: D2 me paraît pas^Wassez intéressant.
    - [^] # Re: déçu aussi, mais confiant
      
      Posté par gasche le 11 octobre 2011 à 14:46. Évalué à 2.
      
      Qu'entends-tu par "historiquement" ? Le langage ML original a été développé dans les années 70. Il existait des langages dynamiques à l'époque (Lisp et Forth au moins), mais je pense que l'inférence de types est tout aussi "historique", d'autant qu'elle s'appuie sur de la recherche qui a été effectuée (dans un autre cadre) dans les années 50.
      - [^] # Re: déçu aussi, mais confiant
        
        Posté par reno le 11 octobre 2011 à 15:59. Évalué à 2.
        
        Le langage ML original a été développé dans les années 70.
        
        Et a été très peu utilisé..
        Je parlais de l'histoire vu par les langage "populaire", je te l'accorde c'est une vision très différente par rapport à l'histoire vu par les chercheurs.
    - [^] # Re: déçu aussi, mais confiant
      
      Posté par psychoslave__ (site web personnel) le 11 octobre 2011 à 16:45. Évalué à 2.
      
      OCaml ?
      
      http://queue.acm.org/detail.cfm?id=2038036
# A chacun son langage

Posté par Sytoka Modon (site web personnel) le 11 octobre 2011 à 14:16. Évalué à 2.

Allez hop, je me lance !

Pourquoi pas se baser sur la machine Erlang qui a le bon gout d'avoir des variables immutables (pas de programmation en variable globale) et est parfaitement bien conçu pour gérer un grand nombre de thread parallèle. C'est parfais pour de l'IHM graphique !
- [^] # Re: A chacun son langage
  
  Posté par gasche le 11 octobre 2011 à 14:42. Évalué à 2.
  
  Ils veulent quelque chose de performant, donc je ne suis pas convaincu que la VM Erlang soit un bon choix technique. Elle scale bien, gère bien la distribution, mais pour les performances brutes c'est ça, quitte à prendre une machine virtuelle Hotspot fait nettement mieux. Ceci dit, le design actuel de Dart n'est pas non plus très adapté à la performance...
- [^] # Re: A chacun son langage
  
  Posté par lasher le 11 octobre 2011 à 15:09. Évalué à 4.
  
  Mmmh, par définition, une bibliothèque graphique doit maintenir un état de ce qui est affiché. Comment tu fais pour ne redessiner qu'une partie de l'écran si tu n'as que du single assignment ? Plus exactement, je sais que c'est possible, mais je me demande quelles seraient les performances dans ce cas. Faire un serveur web en Erlang est parfaitement sensé (presque tout est « write once, read many »). Pour une interface graphique avec un paradigme événementiel, je suis moins certain.
  - [^] # Re: A chacun son langage
    
    Posté par devnewton 🍺 (site web personnel) le 11 octobre 2011 à 16:10. Évalué à 1.
    
    NewDrawList = OldDrawList ++ { circle, { pos, 3.25, 4.6 }, { radius, 10.0 } }
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: A chacun son langage
    
    Posté par Sytoka Modon (site web personnel) le 11 octobre 2011 à 17:44. Évalué à 2.
    
    Un serveur web de nos jours est souvent lié à une base de données.
    
    Pourquoi l'affichage ne jouerais pas le rôle d'une base de données ? De type ajout retrait d'information dans un arbre XML avec rendu CSS ;-)
- [^] # Re: A chacun son langage
  
  Posté par Jean B le 11 octobre 2011 à 16:11. Évalué à 3.
  
  s/immutables/immuables/
# CoffeeScript

Posté par Dorian le 11 octobre 2011 à 18:58. Évalué à 7.

J'approuve le journal sur le fait que CoffeeScript est la solution idéale :
- Il a tout ce que les devs demandent à Javascript
- Il est retro-compatible avec Javascript (par compilation)

« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
- [^] # Re: CoffeeScript
  
  Posté par gasche le 12 octobre 2011 à 11:30. Évalué à 5.
  
  CoffeeScript a un défaut impardonnable, l'absence de mot-clé "let" ou "var" pour une définition de variable locale, qui fait qu'il ne permet pas de masquer localement des variables existantes. Ça force un programmeur travaillant dans un bloc à être conscient de toutes les variables déjà présent dans le contexte, ce qui pose des problèmes de maintenabilité; par exemple, il est risqué par exemple de copier/coller un bout de code qui change des variables, on risque en le déplaçant de changer la sémantique de l'ensemble du programme et donc d'introduire des bugs.
  
  Le reste des changements sont raisonnables, c'est principalement du sucre syntaxique par dessus JS (donc sans aucune influence sur la sémantique des programmes). Ils auraient dû se cantonner à du sucre, au lieu de jouer avec la sémantique. Même si c'est un problème qui n'est pas toujours gênant en pratique (si on se force à éviter les portées imbriquées), ça reste un problème fondamental pour un langage de programmation, un peu du même genre que choisir la liaison dynamique plutôt que lexicale par erreur. J'espérais que ce genre d'erreur était derrière nous.
  - [^] # Re: CoffeeScript
    
    Posté par Dorian le 12 octobre 2011 à 12:32. Évalué à 3.
    
    Premier résultat sur Google : http://jashkenas.github.com/coffee-script/#lexical_scope
    
    If you'd like to create top-level variables for other scripts to use, attach them as properties on window, or on the exports object in CommonJS. The existential operator (covered below), gives you a reliable way to figure out where to add them; if you're targeting both CommonJS and the browser: exports ? this
    
    Si ce n'est pas de ça que tu parles, alors un exemple vaut mieux qu'un long discours ;).
    
    « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
    - [^] # Re: CoffeeScript
      
      Posté par gasche le 12 octobre 2011 à 13:41. Évalué à 7.
      Attention, je parle de la définition de variable locale, et non pas de variable toplevel comme le discute ta citation.
      
      Un exemple : voici un bout de code Javascript utilisant let (donc pas portable mais passons, je choisis juste let pour avoir une portée classique)
      
      [...] if (x > y) { let z = 12.7 * x + y; do_something(z); } [...]
      
      Je peux placer ce bout de code à n'importe quel endroit de mon code qui connaît x, y et do_something, sans me soucier du reste, et ça va marcher exactement comme je l'entends.
      
      Maintenant si j'essaie de faire pareil en Coffeescript
      
      [...]
      if (x > y)
      z = 12.7 * x + y;
      do_something(z);
      [...]
      
      Ce code ne fait la même chose que si z n'existe pas déjà.
      
      En effet
      
      z = "foo"
      if (x > y)
      z = 12.7 * x + y;
      do_something(z)
      # z ne vaut plus "foo" !
      
      Je n'ai pas moyen de dire (à part en encapsulant dans une fonction, ce qui est exactement ce que Coffeescript fait pour éviter les soucis de syntaxe de JavaScript; donc il faudrait refaire ça par dessus pour avoir une portée correcte) que je veux choisir un nouveau z qui n'affecte pas ce qui existe déjà.
      
      Ça veut dire que si je veux déplacer un bout de code qui fait ça, et que je veux le mettre là, il faut que je renomme dans ce bout de code toutes les occurences de z vers un autre truc genre z1. Ça augmente l'effort de maintenance et c'est un bug qui ne demande qu'à arriver : on oublie de renommer l'un des z et on est mort... Bref, l'impossibilité de "masquer" des noms existants en déclarant une nouvelle variable locale est très gênante (d'ailleurs Erlang a aussi ce défaut, mais c'est un autre débat).
      
      La réponse des auteurs de CoffeeScript est "oui mais ça pose problème que si tu as plusieurs niveaux de variables locales, donc plusieurs blocs imbriqués, et les blocs imbriqués c'est mal de toute façon". Je pense pour ma part que si un langage ne se comporte pas bien au niveau des définitions de variable locale, ça posera forcément problème à un moment où à un autre, même si les concepteurs aimeraient bien que tout le monde programme de la façon qui les arrange. Je n'ai pas envie d'utiliser un langage qui n'apporte pas cette garantie de base : ça fait des années qu'on sait comment gérer les variables locales de façon robuste (portée lexicale avec lieurs explicites), mais les concepteurs de langages continuent à ignorer ça et faire n'importe quoi.
    - [^] # Re: CoffeeScript
      
      Posté par gasche le 12 octobre 2011 à 13:45. Évalué à 7.
      Attention, je parle de la définition de variable locale, et non pas de variable toplevel comme le discute ta citation.
      
      Un exemple : voici un bout de code Javascript utilisant let (donc pas portable mais passons, je choisis juste let pour avoir une portée classique, ici var marche aussi)
      
      [...] if (x > y) { let z = 12.7 * x + y; do_something(z); } [...]
      
      Je peux placer ce bout de code à n'importe quel endroit de mon code qui connaît x, y et do_something, sans me soucier du reste, et ça va marcher exactement comme je l'entends.
      
      Maintenant si j'essaie de faire pareil en Coffeescript
      
      [...] if (x > y) z = 12.7 * x + y; do_something(z); [...]
      
      Ce code ne fait la même chose que si z n'existe pas déjà dans le contexte.
      
      En effet, si mon contexte est :
      
      z = "foo" # le bloc ici bar(z)
      
      Ça casse:
      
      z = "foo" if (x > y) z = 12.7 * x + y; do_something(z) bar(z) # z ne vaut plus "foo" !
      
      Je n'ai pas moyen de dire (à part en encapsulant dans une fonction, ce qui est exactement ce que Coffeescript fait pour éviter les soucis de syntaxe de JavaScript; donc il faudrait refaire ça par dessus pour avoir une portée correcte) que je veux choisir un nouveau z qui n'affecte pas ce qui existe déjà.
      
      Ça veut dire que si je veux déplacer un bout de code qui fait ça, et que je veux le mettre là, il faut que je renomme dans ce bout de code toutes les occurences de z vers un autre truc genre z1. Ça augmente l'effort de maintenance et c'est un bug qui ne demande qu'à arriver : on oublie de renommer l'un des z et on est mort... Bref, l'impossibilité de "masquer" des noms existants en déclarant une nouvelle variable locale est très gênante (d'ailleurs Erlang a aussi ce défaut, mais c'est un autre débat).
      
      La réponse des auteurs de CoffeeScript est "oui mais ça pose problème que si tu as plusieurs niveaux de variables locales, donc plusieurs blocs imbriqués, et les blocs imbriqués c'est mal de toute façon". Je pense pour ma part que si un langage ne se comporte pas bien au niveau des définitions de variable locale, ça posera forcément problème à un moment où à un autre, même si les concepteurs aimeraient bien que tout le monde programme de la façon qui les arrange. Je n'ai pas envie d'utiliser un langage qui n'apporte pas cette garantie de base : ça fait des années qu'on sait comment gérer les variables locales de façon robuste (portée lexicale avec lieurs explicites), mais les concepteurs de langages continuent à ignorer ça et faire n'importe quoi.
  - [^] # Re: CoffeeScript
    
    Posté par Moonz le 12 octobre 2011 à 19:19. Évalué à -1.
    
    Au contraire, en CoffeeScript, par défaut, toutes les variables sont “var”, c’est même un des énormes avantages par rapport à Javascript :
    
    x=5
    
    se traduit automatiquement par
    
    var x = 5;
    - [^] # Re: CoffeeScript
      
      Posté par Dorian le 13 octobre 2011 à 03:05. Évalué à 3.
      
      Sauf si elle est déjà déclarée justement (et pas dans une fonction)
      
      « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
# Petite erreur

Posté par Rolland le 11 octobre 2011 à 19:37. Évalué à 0.

Dart se distingue de JavaScript par :
* […]
* l’obligation d’utiliser les « ; » pour séparer les instructions ;

C'est aussi le cas du JavaScript, il me semble.
- [^] # Re: Petite erreur
  
  Posté par Rolland le 11 octobre 2011 à 19:54. Évalué à 0.
  
  Ah mouais, en fait, il n'est pas obligatoire si les instructions ne sont pas sur la même ligne, mais bon...
# ClusterHTML

Posté par Prae le 11 octobre 2011 à 20:42. Évalué à 5.

Avoir une grosse évolution du HTML/CSS/JS est peut-être une bonne solution. Maintenant on a des applis web qui te bouffe 100% de ton quadri-proc. J'ai l'impression que beaucoup oublie qu'une appli qui n'affiche que du texte/images et qui rame sur une machine surpuissante, y'a bien un petit soucis quelque part, non ?

Les deux plus gros soucis du net à l'heure actuelle sont :
- les différences d'output (display) pour un rendu : vous étonnez pas que des sites comme Apple foutent des images pour des présentations alors qu'ils ont que 3 lignes de texte.
- les performances : 100% de CPU sur un quadri, c'est juste pas normal pour si peu. (et même si tu joues une simple vidéo en SD)
- [^] # Re: ClusterHTML
  
  Posté par Grunt le 12 octobre 2011 à 11:31. Évalué à 10.
  
  les différences d'output (display) pour un rendu
  
  D'un autre côté, le Web n'a pas pour fonction de sortir un rendu identique au pixel près (pour ça, mieux vaut faire une image, en effet). Il y a, il doit y avoir une partie de la maîtrise du rendu final qui est décidée par l'agent-utilisateur et la façon dont il est configuré. Pour des raisons de goût personnel, d'accessibilité, d'interaction avec d'autres logiciels..
  
  Je ne comprends pas pourquoi c'est si difficile à comprendre. On ne demande pas au site d'envoyer une image, on lui demande d'envoyer un titre, des sous-titres..
  
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Encore le type Null...

Posté par Ontologia (site web personnel) le 11 octobre 2011 à 20:58. Évalué à 9.
C'est consternant qu'en 2011 on conçoive encore des langage intégrant le type Null...
Antony Hoare, célèbre scientifique qui l'a conçu en 1965, l'a appellé "My Billion-Dollar mistake" estimant à plusieurs milliards de dollars, sans doute quelques dizaines, le coût provoqué durant 40 ans par le Null Reference.

Un bon langage, est un langage sans type Null. Pour avoir codé sans, c'est vraiment génial.

En OCaML (de même qu'en Haskell), où il n'existe pas, on doit gérer ses propriétés sans type Null comme ceci :
```
class toto = object
 val mutable unePropriete = (None  : string option)
 method getProp = match unePropriete with
 | Some(str) -> str
end
```
Ici, on ne gère pas le "Null" ici appelé None.
Le compilateur le détecte impitoyablement :
```
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
None
class toto :
  object val mutable unePropriete : string option method getProp : string end
```
Dans le fond, pourquoi garde t-on le type Null ?
A mon sens pour deux raisons :
- Le poids des habitudes
- Et surtout la fainéantise : c'est bien plus difficile, même en intégrant le option de Ocaml, qui simplifie beaucoup de choses, de concevoir son code en ayant à l'esprit que TOUTE ses valeur doivent être assignés avec quelques chose de propre.

Ainsi on se traine ce boulet, qui continue à faire des dégâts !

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- [^] # Re: Encore le type Null...
  
  Posté par Guillaume Denry (site web personnel) le 11 octobre 2011 à 22:05. Évalué à 3.
  
  Mince alors, j'ai beau relire ton commentaire, je ne comprends absolument rien.
  Tu parles du "type" Null ou de la valeur Null ?
  En quoi est-ce un soucis d'avoir ce type/valeur ?
  - [^] # Re: Encore le type Null...
    
    Posté par gasche le 12 octobre 2011 à 11:38. Évalué à 3.
    
    Il parle bien de la valeur NULL, et il l'argumentation sur pourquoi c'est un soucis est donné au début de son post : Tony Hoare a déclaré que son invention était sa "Billion-dollar mistake". Plus d'explications par exemple sur programmer stackexchange (lien trouvé en googlant "NULL Billion-dollar mistake").
    
    (Merveille des notes LinuxFR : je ne comprends pas pourquoi son commentaire, qui est argumenté et apporte du contenu, est masqué, alors que ta question, qui est légitime mais qui n'est pas follement trépidante en elle-même, est à 6. À choisir je préférerais que ce soit l'inverse.)
    - [^] # Re: Encore le type Null...
      
      Posté par Guillaume Denry (site web personnel) le 12 octobre 2011 à 12:04. Évalué à 2.
      
      Avec un exemple dans un langage plus commun et je pense que tout le monde aurait compris.
      En tout cas merci pour le lien (oui je sais, j'aurais pu le trouver moi-même), il est clair et m'a permis de comprendre les implications de l'utilisation de NULL.
      Bon maintenant, il va falloir convaincre toute mon équipe qu'il ne faut plus utiliser NULL ^^
      - [^] # Re: Encore le type Null...
        
        Posté par Ontologia (site web personnel) le 12 octobre 2011 à 12:39. Évalué à 2.
        
        Heureux que cela t'ait sensibilisé :-)
        Désolé pour le langage le plus "commun", OCaML est le langage le moins inconnu qui possède cette propriété.
        Eh oui, les langages ne comportant pas de type/valeur Null sont extrêmement rares. C'est quelque chose de très difficile à gérer au niveau du compilateur.
        OCaML et Haskell ont une grosse infra derrière, avec une base mathématique théorique de très haut niveau (Théorie du lambda calcul de type), c'est pas à la portée du premier implémenteur de compilateur venu.
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: Encore le type Null...
        
        Posté par Guillaume Denry (site web personnel) le 12 octobre 2011 à 13:08. Évalué à 2.
        
        Est-ce qu'on peut dissocier la non utilisation de Null d'une gestion d'exceptions ? Je connais des allergiques aux exceptions (pourquoi ? je n'ai jamais réussi à avoir d'explication convaincantes) et j'ai l'impression qu'on peut avoir l'un sans l'autre.
        
        [^] # Re: Encore le type Null...
        
        Posté par Ontologia (site web personnel) le 12 octobre 2011 à 13:33. Évalué à 2.
        
        Tout à fait, OCaML possède un mécanisme d'exceptions qui n'a que très peu de différence avec celui de Javouille, mis à part que les exceptions ne sont pas des types, mais ça n'a rien à voir.
        Et effectivement, quand tu tombes sur cas None, tu puex souvent être amenés à emmètre une exception, c'est d'ailleurs là que tu tu poses des questions intelligentes sur la gestion de celle-ci, parce qu'elles peuvent se multiplier très vite..
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: Encore le type Null...
        
        Posté par reno le 12 octobre 2011 à 13:58. Évalué à 2.
        
        Est-ce qu'on peut dissocier la non utilisation de Null d'une gestion d'exceptions ?
        
        Oui: si tu as des types "non-nullable" et que tu essaye de leur affecter un type "nullable" alors tu as une erreur de compilation.
        Pour convertir un types "nullables", en "non-nullable", il y a des langages qui fournissent le moyen de faire ça sans exception:
        Exemple si une variable toto est de de type 'Toto?' (le point d'interrogation indiquant que ce type est nullable) alors
        IfNotNull (toto) {
        ici toto est considéré de type 'Toto' pas 'Toto?'
        }
        
        Je connais des allergiques aux exceptions (pourquoi ? je n'ai jamais réussi à avoir d'explication convaincantes)
        
        Parce que ça complique la lecture de code car les exceptions peuvent te faire sauter 'n'importe où' aisément, ce qui complique les choses,
        si tu lis l'Anglais va voir ici: http://www.d-programming-language.org/exception-safe.html
        pour une bonne exposition du problème créer par les exceptions et des moyens possible de le contourner.
        
        [^] # Re: Encore le type Null...
        
        Posté par barmic le 12 octobre 2011 à 16:09. Évalué à 4.
        
        Parce que ça complique la lecture de code car les exceptions peuvent te faire sauter 'n'importe où' aisément, ce qui complique les choses,
        
        Personnellement, j'ai tendance à écrire l'algorithme sans gestion d'erreur puis à l'encadrer. Par exemple ce qui s'écrit ainsi en C :
        
        int fd = open(/* ... */); if (-1 == fd) { // error } int size = read(fd, /* ... */); if (-1 == size) { // error }
        
        s’écrirais dans un langage objet (je me prend pas la tête avec l'API de Java ou du C++) :
        
        try { int fd = open(/* ... */); int size = read(fd, /* ... */); } catch (FileException ex) { // error }
        
        Du coup le block try est clair (même s'il ajoute un niveau d'indentation). Le problème c'est que ça réduis la granularité de celui-ci mais c'est relativement rare d'avoir besoin d'une granularité très fine dans la gestion d'erreur.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 12 octobre 2011 à 15:23. Évalué à 3.
        
        OCaML et Haskell ont une grosse infra derrière, avec une base mathématique théorique de très haut niveau (Théorie du lambda calcul de type), c'est pas à la portée du premier implémenteur de compilateur venu.
        
        Euh... Si. J'exagère un peu hein, mais un mec qui fait un vrai compilo pour compiler du code vraiment efficace se doit de piger ce qu'est le lambda calcul. Bref.
        
        [^] # Re: Encore le type Null...
        
        Posté par Ontologia (site web personnel) le 12 octobre 2011 à 15:27. Évalué à 2.
        
        Mais tu reconnaitra surement que la plupart des types qui s'amusent à faire un langage n'y connaissent pas grand chose : il y a encore une opposition certaine entre les professeurs Nimbus qui font des trucs "qui servent à rien", et les Ingénieurs "qui sont à peine capable de faire un intranet en Java".
        Ca donne des dizaines de variations de java qu'on trouve tous les jours sur Github, google-code, etc....
        Et cela au plus haut niveau : Dart en est un exemple vivant !
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 12 octobre 2011 à 15:53. Évalué à 2.
        
        Hum. Java est rempli de lambda calcul pour la sûreté des types au niveau des classes. Google compte parmi ses employés des mecs très, très forts en compilation. Tu as pris pile-poil le mauvais exemple, vu que Dart est très clairement une resucée de Java. :-)
        
        [^] # Re: Encore le type Null...
        
        Posté par gasche le 12 octobre 2011 à 16:54. Évalué à -1.
        
        Non, je ne pense pas que Java ait été conçu avec un modèle théorique en tête. Je ne sais pas à quoi tu fais référence en disant qu'il est "rempli de lambda-calcul". L'impression que j'ai est plutôt que les ingénieurs qui ont conçu Java n'étaient pas forcément très au courant de la recherche dans le domaine, mais ont surtout retiré les fonctionnalités les plus complexes de C++ pour faire un langage simplifié.
        
        Ensuite, dans les versions récentes de Java, l'importance pratique du langage a motivé des spécialistes de la théorie des types à se pencher sur la question des génériques notamment. C'est là que sont apparus des modèles formels de sous-ensembles de Java, basés sur la recherche faite indépendamment sur la théorie des langages objets. Mais ça ne veut pas dire que Java dans son ensemble ait été conçu par des gens connaissant la théorie.
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 12 octobre 2011 à 18:33. Évalué à 4.
        
        Non, je ne pense pas que Java ait été conçu avec un modèle théorique en tête. Je ne sais pas à quoi tu fais référence en disant qu'il est "rempli de lambda-calcul".
        
        Ben Java est type-safe, et ça passe par du lambda calcul si tu veux le faire correctement. Tu peux avoir toutes les impressions que tu veux, ça reste vrai. Dire que Java n'a pas de modèle théorique en tête, c'est tout simplement ne pas être au courant de comment Java a été conçu. Java est un des premiers langages « grand public » qui a tenté d'intégrer le parallélisme et la concurrence dès le départ. Du point de vue théorique, ça passe par un modèle de concurrence ainsi qu'un modèle mémoire (il est démontrable que le premier modèle mémoire est cassé, et le deuxième modèle, introduit en 2005-2006, bien que bien meilleur, reste contesté, avec des papiers qui démontrent que certaines propriétés demandées par le modèles sont invérifiables).
        
        L'impression que j'ai est plutôt que les ingénieurs qui ont conçu Java n'étaient pas forcément très au courant de la recherche dans le domaine, mais ont surtout retiré les fonctionnalités les plus complexes de C++ pour faire un langage simplifié.
        
        L'un n'empêche pas l'autre. Cependant la JVM est parfaitement spécifiée, et la traduction de code Java vers le bytecode itou.
        
        Ensuite, dans les versions récentes de Java, l'importance pratique du langage a motivé des spécialistes de la théorie des types à se pencher sur la question des génériques notamment.
        
        Définis « récentes ». La théorie des types, etc., appliquée aux types / classes de Java ça fait un moment (je dirais au moins 10 ans) que c'est intégré à l'implémentation de référence. Exemple, le bouquin de B. Pierce, Types and Programming Languages, est sorti en 2002, et propose déjà un « mini-java » typesafe en guise d'exercice…
        
        Une simple recherche google avec les mots-clef « lambda calculus type safety java » renvoient vers le bouquin de Pierce, puis vers des rapports techniques sur la possibilité de compiler Java vers du lambda calcul typé (rapport datant de 1998).
        
        C'est là que sont apparus des modèles formels de sous-ensembles de Java, basés sur la recherche faite indépendamment sur la théorie des langages objets. Mais ça ne veut pas dire que Java dans son ensemble ait été conçu par des gens connaissant la théorie.
        
        Les mecs qui ont conçu Java n'étaient certes pas des dieux de la compilation et de la théorie des langages, mais une rapide recherche sur J.Gosling (l'un des papas de Java avec Bill Joy) montre que sa thèse de 1983 s'intitule The Algebraic Manipulation of Constraints. Bref, pas un p'tit joueur non plus.
        
        [^] # Re: Encore le type Null...
        
        Posté par gasche le 12 octobre 2011 à 19:24. Évalué à 2.
        
        Ben Java est type-safe, et ça passe par du lambda calcul si tu veux le faire correctement. Tu peux avoir toutes les impressions que tu veux, ça reste vrai.
        
        Qu'est-ce que tu veux dire au juste ? En tout cas ce qu'on essaie de prouver d'habitude sur les lambda-calculs typés, à savoir que la réduction / le calcul préserve le typage, est faux pour Java. En effet, les tableaux sont covariants (un tableau de Foo peut être considéré comme un tableau de Object par exemple) ce qui casse la sûreté du typage.
        
        C'est aussi le cas dans Dart, mais dans Dart les gens disent "on sait que c'est cassé". Dans Java, il n'y a rien dans les spécifications des premières versions du langage qui permette de penser qu'ils le savaient.
        
        L'erreur a été rapidement pointée du doigt par les chercheurs qui font des systèmes de typage, cf. ce vieil article, section "Java Arrays".
        
        J'ai du mal à croire que Java "était plein de lambda-calcul pour faire les preuves"; si preuves il y a eu, elles étaient fausses.
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 12 octobre 2011 à 20:20. Évalué à 3.
        
        Tiré de l'abstract du papier que tu pointes, première phrase :
        
        Java offers the real possibility that most programs can be written in a type-safe language
        
        [^] # Re: Encore le type Null...
        
        Posté par gasche le 13 octobre 2011 à 10:54. Évalué à 5.
        
        Le terme "type-safe" peut désigner plusieurs choses. Un langage comme Python est "type-safe" dans le sens où avant chaque opération, on effectue un test dynamique pour vérifier que l'opérande a bien la forme attendue. Ça évite les erreurs de langages moins méfiants comme C qui segfault rapidement si les types ne correspondent pas (ce que le système de typage, en plus, ne sait pas vérifier, en raison entre autres de l'habitude de transporter tout ce qui doit être générique dans un void *).
        
        Bien que le système de typage statique de Java soit incorrect, le langage est dynamiquement type-safe grâce au test dynamique qui est effectué à chaque écriture dans un tableau.
        
        Comme je l'ai déjà dit, je doute que les concepteurs de Java se soient posé la question de la sûreté du typage statique, sinon ils auraient repéré ce problème et, à défaut de le corriger (ce qui n'est pas évident), l'auraient mentionné clairement dans les premières spécifications du langage. Ce n'est pourtant pas le cas dans la "Oak language specification" (version 0.2, la seule que j'ai trouvé facilement sur Internet). Il faut attendre 96, la première "Java language specification", écrite en grande par Guy Steele qui n'a pas participé au design de Java. Cette spécification discute le problème de l'assignement non statiquement sûr dans un tableau en détail, mais elle dit en même temps:
        
        The following conversions are called the widening reference conversions:
        [...]
        From any array type SC[] to any array type TC[], provided that SC and TC
        are reference types and there is a widening conversion from SC to TC .
        [...]
        Such conversions never require a special action at run time and therefore never
        throw an exception at run time. They consist simply in regarding a reference as
        having some other type in a manner that can be proved correct at compile time.
        
        La spécification dit que la covariance des tableaux est "prouvée correcte statiquement". Au mieux c'est une formation ambiguë (ils veulent dire "on sait que c'est faux mais, sachant qu'il y a le test dynamique, plus tard, c'est quand même pas trop grave") qu'une personne attentive à l'aspect théorique de la chose aurait évitée, au pire c'est une erreur.
        
        Après on pourrait dire qu'ils ont effectivement fait une étude théorique et juste laissé passer une erreur dans une preuve. Ça arrive. Mais ça ne colle pas avec la réalité historique qui est que les chercheurs en langages de programmation connaissaient à l'époque déjà très bien le problème. La question du sous-typage est apparue au milieu des années 80, est devenu un sujet chaud et a été très étudiée jusqu'au début des années 90. Le langage Quest de Cardelli contient des types paramétriques (donc sensiblement plus avancé que Java à l'époque), du sous-typage, et des variables modifiables; il discute clairement des problèmes liés à la mutabilité et précise explicitement que les tableaux sont invariants. La spécification de Quest a été publiée en 1994, mais la recherche sur laquelle elle se base date des années 80 (tous les articles cités ont été publiés avant 1990). Si les concepteurs de Java étaient au courant, comme tu le prétends, de la recherche théorique dans le domaine qui les concerne directement, ils auraient certainement été au courant et il me semble fort curieux qu'ils n'en aient donné aucun signe.
        
        Bien sûr, il est difficile pour moi de prouver que James Gosling ne connaissait pas telle ou telle chose, puisque le fait qu'il n'en parle pas ne nous permet pas de savoir s'il le connaissait ou pas. Puisque tu sembles persuadé que Java a été conçu dès le départ avec un modèle théorique "rempli de lambda-calcul", peut-être as-tu eu accès à des documents sur l'histoire de Java qui en parlent ? Je serais très intéressé par ces sources qui, comme je l'ai dit, iraient à l'encontre de mon intuition propre. Le fait qu'il ait écrit une thèse dans un domaine qui à priori n'a rien à voir avec les langages de programmation¹ ne signifie pas grand chose (et par ailleurs si tu as pu mettre la main sur le manuscript de la thèse, je suis intéressé, parce que moi je n'ai rien trouvé).
        
        ¹: même s'il faut faire attention : son directeur de thèse faisait de l'IA et l'IA, au moins à ses débuts, était très liée à la conception de langages de programmation. Les gens qui faisaient de l'IA s'intéressaient cependant beaucoup plus aux aspects dynamiques des langages (programmation logique, backtracking, systèmes multi-agents, modèles d'acteurs...) qu'aux aspect statique (lambda-calcul typé). Lisp est clairement un produit de la recherche en IA, mais Fortran vient des calculs scientifiques, C de la programmation système et ML des assistants à la preuve formelle.
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 13 octobre 2011 à 19:30. Évalué à 3.
        
        Pour commencer, je tiens à préciser que je me suis absolument pas un expert en lambda calcul ni en théorie des types/sûreté des types.
        
        Le terme "type-safe" peut désigner plusieurs choses.
        
        D’après mon prof de l’époque (ça commence à faire quelques années maintenant, donc si j'ai commis une imprécision, c'est ma faute, pas la sienne),
        
        La sûreté des types garantit qu'un programme ne peut jamais être dans un état indéterminé (eg un état "bloqué" ou rendre une valeur incorrecte que le type ne devrait pas permettre) à l’exécution.
        
        Donc, que celle-ci soit garantie à l’exécution ou à la compilation importe peu : un langage est type-safe s'il garantit cette propriété.
        
        Un langage comme Python est "type-safe" dans le sens où avant chaque opération, on effectue un test dynamique pour vérifier que l'opérande a bien la forme attendue. Ça évite les erreurs de langages moins méfiants comme C qui segfault rapidement si les types ne correspondent pas (ce que le système de typage, en plus, ne sait pas vérifier, en raison entre autres de l'habitude de transporter tout ce qui doit être générique dans un void *).
        
        Tout à fait. En ce qui concerne Java, il existe une sûreté des types à "deux niveaux" :
        
        Statique : tant que je reste dans le cadre des types non primitifs (instanciations de classes, donc tout ce qui peut se passer par référence), alors le transtypage n'est autorisé que s'il se passe d'une instance de classe particulière vers une instance plus générique, autorisé par une relation d’héritage (Object étant un ancêtre commun à toutes les classes) [1]. Oui, cela signifie bien que si j’écris quelque chose du genre :
        
        public class Test { static void toto(Object o) { String s = (String) o; System.out.println(s); } public static void main(String[] args) { Integer i = new Integer(1); String s = "toto"; toto(s); toto(i); } }
        
        Le compilateur me laissera faire.
        
        Dynamique : le fait qu'on puisse transtyper d'un type "générique" vers un type plus précis mais appartenant à une autre sous-branche dans l'arbre d’héritage que celui d'origine fait que le runtime doit pouvoir attraper ce genre d'erreurs de type. Oui, cela a un coût. En même temps, en OCaml, le coût est dans le fait que pour pouvoir utiliser une fonction, il faut que je gère explicitement l’intégralité des types gérés par cette fonction. Faire le produit cartésien des types, c'est pas rigolo tous les jours si je suis cense gerer beaucoup de types dans ma fonction (c'est d'ailleurs pour ça que CDuce a été créé -- enfin, en partie : cf. les papiers dispos sur le site de CDuce à propos du sous-typage sémantique).
        
        Bien que le système de typage statique de Java soit incorrect, le langage est dynamiquement type-safe grâce au test dynamique qui est effectué à chaque écriture dans un tableau.
        
        Exactement. Tu dis que le typage statique est incorrect. Je ne suis pas d'accord. Il est conçu ainsi, ça ne le rend pas incorrect. A moins que lorsque tu parles "d'incorrect", tu ne veuille dire "laisse passer des comportements incorrects", auquel cas, oui, pourquoi pas, mais c'est connu, et "rattrapé" par le comportement du runtime.
        
        Bien sûr, il est difficile pour moi de prouver que James Gosling ne connaissait pas telle ou telle chose, puisque le fait qu'il n'en parle pas ne nous permet pas de savoir s'il le connaissait ou pas. Puisque tu sembles persuadé que Java a été conçu dès le départ avec un modèle théorique "rempli de lambda-calcul", peut-être as-tu eu accès à des documents sur l'histoire de Java qui en parlent ?
        
        Je n'ai jamais parlé de type-safety totalement statique. Je réagissais principalement au fait qu'Ontologia semblait considérer Java et Dart comme des langages/plate-formes qui n'avait pris aucune considération théorique en compte, ce qui est faux. Bien qu'il soit bien entendu surtout considéré pour une évaluation statique (surtout auprès des gens qui font dans la prog fonctionnelle j'ai l'impression), le lambda calcul n'est pas oblige d’être cantonne a une évaluation statique. Je me trompe ?
        
        Concernant la thèse de Gosling : j'ai simplement repris l'info depuis Wikipedia. Maintenant, la manipulation algebrique de contraintes, c'est peut-être (sans doute) pas lie a la sûreté des types, mais c'est clairement applicable a la compilation !
        
        [1] Evidemment, passer par la réflexivité et l'introspection permet de casser la sûreté des types en Java, mais c'est consciemment que le programmeur utilise ces outils.
        
        [^] # Re: Encore le type Null...
        
        Posté par gasche le 13 octobre 2011 à 19:51. Évalué à 3.
        
        A moins que lorsque tu parles "d'incorrect", tu ne veuille dire "laisse passer des comportements incorrects", auquel cas, oui, pourquoi pas, mais c'est connu
        
        C'est connu... depuis quand ? J'ai l'impression que c'est une erreur de conception qui leur a échappé, et dont ils ne se sont rendu compte qu'ensuite (par exemple dans l'intervalle de temps entre la spécification du langage Oak et l'écriture de la spécification de Java).
        
        le lambda calcul n'est pas oblige d’être cantonne a une évaluation statique. Je me trompe ?
        
        Non, tu ne te trompes pas; d'ailleurs c'est ce que fait l'article sur la "traduction de Java vers un lambda-calcul typé" dont tu parlais, il rajoute des tests dynamiques pour compenser la sémantique cassée du système de typage statique (et ses difficultés à modéliser la récursion ouverte en conservant le sous-typage, qu'on sait maintenant résoudre).
        
        Cependant, une idée de base du typage est de refléter la sémantique du langage. Une relation de sous-typage était que si S est sous-type de T, alors toute valeur de type S peut être considérée comme une valeur de type T. Dans la théorie, c'est l'idée sémantique derrière le sous-typage, donc très important. Dans la pratique, c'est le principe de substitution de Liskov (LSP), énoncé en 1987 (donc avant la conception du langage Java) et donc connu, on l'espère, des concepteurs de Java. Or, la relation de sous-typage qui est présente dans Java viole ce principe de substitution, puisque S[] peut être sous-type de T[] sans qu'un tableau de type S[] puisse être utilisé de la même façon qu'un tableau de type T. C'est bête, et ça ressemble assez à une erreur de conception, non ?
        
        Si ce test qui tue les performances et qui contrarie tout le monde est là, c'est sans doute parce que les gens n'ont pas vu le problème au départ et ont cru que c'était correct, parce qu'ils ne connaissaient pas le modèle théorique derrière. C'est une hypothèse (que j'ai déjà formulée dans mon post qui s'est fait descendre en flamme) crédible puisque le problème n'est pas mentionné dans les premières spécifications du langage.
        
        Le rasoir d'Ockham me suggère que cette explication est plus plausible que l'hypothèse selon laquelle James Gosling, qui est en fait un gro pgm des systèmes de types qui cache bien son jeu, s'est amusé à cacher les failles sémantiques dans son système pendant plusieurs années (jusqu'à qu'un chercheur indépendant les pointes du doigt), à définir une relation de typage non-standard violant le LSP, pour le plaisir de rajouter un test de typage dynamique à chaque accès dans un tableau et de donner l'opportunité aux chercheurs en typage de se torturer pour trouver une manière raisonnable d'étendre le langage de façon sensée par la suite (... ce qu'ils n'ont pas tout à fait réussi, si on en croit les avis sur les génériques Java).
        
        Encore une fois, je serais très intéressé par toute source confirmant que les concepteurs de Java ont pensé au modèle théorique de leur système de typage pendant la conception du langage (c'est à dire entre grosso-modo 1991, premières mentions de Oak, et 1994, arrivée de Guy Steele à Sun pour bosser sur la spec. du langage déjà conçu).
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 14 octobre 2011 à 21:05. Évalué à 3.
        
        Alors, pour info, je suis en train de regarder une vidéo où Gosling présente les origines de Java. Avant de faire des études, il a programmé et écrit (ou maintenu) plusieurs langages. Entre autres il a maintenu une implémentation de Simula.
        
        Sa thèse décrit comment considérer l'expression d'un programme sous forme algébrique (repris d'un de ses slides : « Code-as-algebra is awesome! »,: il a bossé sur les Arbres syntaxiques abstraits (AST)) [1]
        
        Gosling décrit Java comme étant une tentative d'obtenir un langage avec un « "scripting" feel », sans perdre trop en termes de performance. [2] Il parle ensuite d'introduire le loup dans la bergerie, en gardant une syntaxe à-la-C, mais en introduisant les bonnes idées d'autres langages (Lisp,Smalltalk,Simula,etc.). [3]
        
        Il dit que Java (et la JVM) est quasiment un copier-coller de Simula. [4]
        
        À propos des types : les types primitifs ont été uniquement introduits à cause des performances (pouvoir faire a = b + c en une instruction de la JVM). Malheureusement il ne parle pas des types mis à part ça.
        
        [1] 07:30
        [2] 26:30
        [3] 27:00
        [4] 42:00
        [5] 46:00
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 14 octobre 2011 à 21:07. Évalué à 3.
        
        Oups, j'ai oublié de donner le lien (trouvé sur Wikipedia) : http://www.infoq.com/presentations/gosling-jvm-lang-summit-keynote
        
        [^] # Re: Encore le type Null...
        
        Posté par gasche le 14 octobre 2011 à 22:48. Évalué à 2.
        
        Merci pour la référence. Si ça t'intéresse j'ai trouvé les slides ici. Sur les slides, nulle mention du typage effectivement (à part implicitement dans le fait qu'Algol et Simula étaient statiquement typés), donc rien de concluant d'un point de vue "théorie du typage¹" (sans parler du lambda-calcul).
        
        Par ailleurs, j'ai essayé de trouver ce qu'il entend par "code as algebra", sans succès (chercher ça sur Google ne donne que des liens vers des retranscriptions de cette présentation), à croire que sa thèse et son idée clé ont complètement disparu de la surface du web.
        
        ¹: pour une perspective historique : Algol 68 avait des conversions implicites entre type très (trop) élaborées, et Simula a introduit la notion d'héritage et de sous-typage (mais les tableaux étaient, semble-t-il, invariants). Algol était extrêmement novateur dans le sens où c'est un des premiers, voire le premier, langage(s) avec un système de typage fort et clairement défini. La théorie est cependant venue après, au début des années 70, avec les travaux de Scott en particulier; les langages inspirés d'Algol (Algol 68, Pascal) n'ont pas respecté cette idée formelle du typage (ce n'est pas ce qui intéressait leurs créateurs, je pense), et Simula était à nouveau basé sur une idée informelle du typage, sans théorie bien précise derrière (ce n'est pas vraiment une critique, une grande partie des nouvelles constructions de langages de programmation ont été introduites d'abord, et bien typées seulement dans un second temps). Pour une présentation détaillée des fondements théoriques et de l'influence du langage Algol, cf. l'introduction de "Algol-like languages", un livre sur l'aspect théorique par des chercheurs en langages de programmation.
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 15 octobre 2011 à 03:22. Évalué à 3.
        
        Ben visiblement il y a des confs/workshops concernant le sujet: Algebraic methodology and software technology.
        
        De plus je sais que presque tous les programmes peuvent être exprimés sous forme algébrique (l'algèbre étant définie en fonction du langage). Par exemple XQuery et les autres langages FLWR ont une algèbre bien définie pour exprimer des requêtes (là encore, ce sont des vestiges de mes cours datant d'il y a quelques années — en l'occurrence, de données semi-structurées & XML).
        
        Ce fichier PDF montre comment les AST sont utilisés pour l'analyse de programmes, du point de vue de l'analyse du flot de données (dataflow analysis). Ce genre de trucs remonte à loin, mais en gros si je peux toucher à un graphe, je peux du coup toucher à la théorie des groupes, et donc je peux d
        définir des relations algébriques entre diverses parties de mon graphe/AST. De façon générale, n'importe quelle relation algébrique peut être représentée sous forme d'arbre. Donc forcément, un AST peut être « traduit » en relation algébrique.
        
        [^] # Re: Encore le type Null...
        
        Posté par gasche le 15 octobre 2011 à 09:47. Évalué à 1.
        
        C'est très confus tout ça, et ça n'a pas l'air lié du tout ni à Java, ni à la thèse de Gosling (ou plutôt, comme on ne sait rien de son travail de thèse, il est impossible de dire si ça a un rapport ou pas). Le mot "algèbre" est utilisé pour dire beaucoup de choses et deux domaines informatiques qui s'y réfèrent n'ont pas nécessairement de lien. J'aurais aimé retrouver quelque part le mot d'ordre "code as algebra" que Gosling a l'air de trouver si important et suggestif, mais rien de s'y réfère.
        
        Dans ton premier lien on trouve beaucoup de preuve, un peu de "spécification", et des "process algebra", bref des calculs formels utilisés en concurrence par exemple.
        
        La question de XQery est encore différente, si je comprends bien (je ne connais pas XQuery) il s'agit plus d'algèbre au sens de d'un ensemble d'opération ayant une sémantique bien définie qui permet de construire des objets (requêtes). Sur les BDD classiques on parle de "relational algebra".
        
        Enfin, la partie sur la Dataflow analysis me semble ne pas avoir spécialement grand chose avec de l'algèbre (enfin on peut trouver de l'algèbre partout, et modéliser beaucoup de chose comme des structures algébriques).
        (Par ailleurs le fait de manipuler un AST ou, même, une forme intermédiaire utilisée dans un compilateur, n'indique en rien qu'on s'intéresse au lambda-calcul, au typage, et aux modèles théoriques de celui-ci.)
        
        Il y a d'autres courants de l'informatique théorique qui se réclament de l'algèbre ou y sont lié sans faire du bruit à ce sujet. Les questions de résolution de contrainte ont effectivement souvent une saveur un peu algébrique (il s'agit de manipulation formelle d'expressions syntaxiques qui ont un modèle sémantique). On parle aussi d'une algebra of programming au sujet des gens qui isolent des combinateurs expressifs pour la programmation fonctionelle : Squiggol, Lenses&Bananas, etc. Troisième exemple tiré du chapeau, on dit que Tony Hoare retravaille sur les sémantiques par pré-postcondition avec une approche plus algébrique.
        
        Rien de tout cela, cependant, ne semble lié à la conception de Java.
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 15 octobre 2011 à 18:43. Évalué à 2.
        
        À ce niveau je n'essaie même plus de chercher un rapport avec les types; juste quel est le rapport entre algèbre et programmes. Et j'ai clairement souvenir avoir vu en cours qu'il y avait une correspondance entre théorie des groupes et théorie des graphes d'une part (donc que l'algèbre peut être utilisée sur des graphes représentant du code par exemple), et qu'une formule algébrique peut être représentée sous forme d'arbre d'autre part — et donc on peut manipuler un AST et lui faire subir tout un tas d'outrages^Wde transformations qui restent équivalentes au programme initial.
        
        C'est cool de me donner de la lecture cependant. :-)
        
        [^] # Re: Encore le type Null...
        
        Posté par Ontologia (site web personnel) le 13 octobre 2011 à 11:35. Évalué à 3.
        
        Pour avoir suivi pas mal de discussions entre D. Colnet (papa de SmartEiffel) et B. Sonntag (papa de Lisaac) qui sont évidemment tout à fait solide sur le lambda calcul et la sureté de type vu que c'est leur domaine de recherche, il ressort plusieurs choses :
        - On ne sait pas faire de type-safe propre avec de l'objet, parce qu'algébriquement ça cadre mal (pour les détails faut leur demander, j'aurai beaucoup de mal à l'expliquer) avec la notion d'instance ou de clonage.
        - Java est bourré de trous dans l'implem des génériques
        - Java est un langage qui accepte le cast. Or, désolé, mais le cast, c'est tout sauf type-safe.
        - Java possède le type Null, qui est par essence pas type-safe
        - Java est covariant, et malheureusement, ce n'est pas type-safe non plus. Si tu veux vraiment l'être, il faut être invariant, car, à moins d'une analyse de flot très profonde sur une fermeture transitive totale du code, tu ne peux pas avoir l'assurance que tu n'auras pas de problèmes. Or, Java, c'est de la compilation séparée. Sans compter l'introspection, où tu ne peux rien savoir.
        Regarde le modèle objet de OCaML, là c'est simple, c'est invariant. L'héritage est réduit à sa plus simple expression de ne pas recopier le code, mais lorsqu'il s'agit de mettre B là où il attend A, même si B hérite de A, le compilateur te jette tout de suite !
        
        Bref, Java est un peu type-safe. Les NullPointerException et les ClassCastExceptions quotidiens sont là pour le prouver.
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: Encore le type Null...
        
        Posté par gasche le 13 octobre 2011 à 11:55. Évalué à 1.
        
        Regarde le modèle objet de OCaML, là c'est simple, c'est invariant. L'héritage est réduit à sa plus simple expression de ne pas recopier le code, mais lorsqu'il s'agit de mettre B là où il attend A, même si B hérite de A, le compilateur te jette tout de suite !
        
        Non, c'est faux, on peut utiliser une forme de convertibilité en OCaml (et les types paramétrés peuvent porter une indication de variance sur chacun de leurs paramètres, qui est inférée selon leur définition quand c'est possible). La théorie est un peu différente, et surtout il faut demander la coercion vers A explicitement (on écrit (foo :> ty) ou (foo : t1 :> t2)), mais c'est tout à fait possible.
        
        type t = < data : int > let (li : t list) = [] let obj = object method data = 4 method foo = () end (* val obj : < data : int; foo : unit > *) let test = (obj :> t) :: li (* val test : t list = [<obj>] *) type empty = < > let test2 = (test :> empty list) (* val test2 : empty list *)
        
        [^] # Re: Encore le type Null...
        
        Posté par Ontologia (site web personnel) le 13 octobre 2011 à 16:52. Évalué à 2.
        
        Oui mais dans la pratique, ça marche pour des cas très limités comme celui que tu présentes, mais tu te fais très vite jeter par le compilateur si tu as l'habitude de raisonner comme dans les langages objets classiques.
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: Encore le type Null...
        
        Posté par gasche le 12 octobre 2011 à 16:51. Évalué à 8.
        
        la plupart des types qui s'amusent à faire un langage n'y connaissent pas grand chose [...] Dart en est un exemple vivant !
        
        Ce que tu dis est à la fois incorrect et irrespectueux. Il suffit de lire la documentation sur Dart pour se rendre compte qu'une partie au moins de ses concepteurs connaît la théorie des langages de programmation, en particulier la théorie des types. Par exemple, ils mentionnent que Dart supporte la F-bounded quantification, qui est une fonctionnalité des systèmes de types objets avec abstraction de type et sous-typage.
        
        Le fait d'avoir choisi, ensuite, de ne pas suivre les conseils de cette approche théorie et de mettre en place un système non statiquement sûr intentionnellement est une autre question. Je pense qu'ils ont tort, mais ça ne justifie pas de les prendre de haut.
    - [^] # Re: Encore le type Null...
      
      Posté par barmic le 12 octobre 2011 à 13:45. Évalué à 2.
      
      J'ai un peu de mal à comprendre. L'exemple donné sur stackexchange est intéressant, mais je ne vois pas comment faire pour chaque cas d'usage.
      
      Si on vérifier qu'une variable a bien était initialisée et que pour diverses raison on ne peux pas l'initialiser au départ. C'est le genre de cas où donner une valeur par défaut risque de poser des problème car c'est une valeur acceptable (elle peut être plus tard initialisée avec cette même valeur). Du coup je ne voie pas d'autre manière que de trimballer un booléen avec, mais c'est absolument pas agréable (boost a quelque chose qui s'en rapproche : optional).
      
      C'est une vrai question, je pense que je ne comprends pas tout.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Encore le type Null...
        
        Posté par gasche le 12 octobre 2011 à 13:55. Évalué à 7.
        
        Une solution qui marche plutôt bien, mentionnée par Ontologia, est d'utiliser un type somme comme l'ont entre autres OCaml, SML, Haskell, Typed Racket, et comme on peut vaguement encoder dans un langage objet (mais c'est bof agréable, sauf en Scala), c'est-à-dire un type dont les valeurs peuvent être de plusieurs formes selon les cas:
        
        type 'a option = | None | Some of 'a
        
        Pour tout type 'a, une valeur de type 'a option est soit None, soit Some v où v est de type 'a. Par exemple None et Some 3 sont de type int option. C'est un type, en gros, qui "ajoute une valeur par défaut" à n'importe quel type. Tu peux donc représenter une variable de type t qui peut être observée initialisée comme une référence mutable vers du t option : elle est mise à None au départ, et quand tu l'initialises tu mets Some truc. Toute partie du programme qui veut accéder à cette variable doit distinguer les deux cas possibles:
        
        match !la_variable with | None -> do_something "damn, pas encore initialisée !" | Some valeur -> do_something_else valeur
        
        Pour être agréable à utiliser, il faut une bibliothèque standard qui sait bien gérer les types options (Maybe en Haskell, Option en Scala il me semble). Les monades sont une abstraction qui permet de s'en servir en cachant la possibilité d'erreur (en gros on s'en sert comme si tout était défini, et si un des trucs n'est pas défini, le résultat du calcul est rendu indéfini).
        
        Bref, il faut un langage un peu riche pour que cette méthode soit vraiment agréable, mais c'est une bonne façon de sortir l'aspect "contient une valeur par défaut" des types de base : on a des types de base bien définis sans valeur par défaut, et seulement là où on en a besoin on utilise des valeurs de type option; en plus l'optionnalité est précisée dans les types donc on ne peut pas l'oublier (comme on oublie que quelque chose peut être NULL).
        
        [^] # Re: Encore le type Null...
        
        Posté par ziliss le 12 octobre 2011 à 14:59. Évalué à 2.
        
        En fait, si j'ai bien compris, le problème ne vient pas de la valeur NULL, puisque dans vos exemples vous utilisez un None qui a la même fonction que NULL.
        
        Le problème est que le langage/compilateur ne force pas le programmeur à écrire des tests qui tiennent compte de toutes les valeurs possibles d'une variable. Ce que je comprends tout à fait, car tester certaines valeurs ne sert à rien s'il a été convenu que ces valeurs étaient interdites. (Et que tout le monde s'y tient, ce qui est souvent le cas)
        
        D'après ce que je vois, la solution c'est de créer des types de variables "personnalisées" qui n'acceptent que des valeurs bien définies. Ainsi pour des variables référençant un certain type d'objets, on pourrait avoir des variables qui acceptent un NULL et d'autres qui n'en acceptent pas, voir des variables qui acceptent plusieurs sortes de NULL suivant la raison : (NULL_NOT_INITIALIZED, NULL_NOT_FOUND, NULL_REMOVED, etc)
        
        Du coup je me demande s'il serait aussi possible de faire la même chose avec des entiers où les valeurs 0 et -1 (ou des valeurs négatives) ont souvent une signification particulière. Serait-il possible de les interdire ou d'avoir différentes sortes de "NULL" là aussi ?
        
        Je sais pas si j'ai bien compris la discussion, mais ça me paraît intéressant.
        
        [^] # Re: Encore le type Null...
        
        Posté par barmic le 12 octobre 2011 à 15:17. Évalué à 2.
        
        Du coup je me demande s'il serait aussi possible de faire la même chose avec des entiers où les valeurs 0 et -1 (ou des valeurs négatives) ont souvent une signification particulière. Serait-il possible de les interdire ou d'avoir différentes sortes de "NULL" là aussi ?
        
        Je pense que oui dans les langages fonctionnels. Tu crée un type NULL qui contient les valeurs particulières et un type Non-NULL qui contient le reste et enfin un type qui est l'assemblage des deux. Je me trompe messieurs les développeurs fonctionnels (je n'ai jamais touché à ça donc c'est une façon de pensé nouvelle pour moi) ?
        
        Ada permet aussi de créer des types d'entiers contenant uniquement un sous ensemble de N.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Encore le type Null...
        
        Posté par Ontologia (site web personnel) le 12 octobre 2011 à 15:45. Évalué à 4.
        
        Alors deux choses :
        
        En ce qui me concerne, je pense, comme Anthony Hoare, que le type Null ne doit pas exister dans le langage. Point. Foin de NULL_NOT_INITIALIZED, NULL_NOT_FOUND, NULL_REMOVED. Si tu veux gérer ce genre de cas, tu créés un type Somme :
        type probleme = | NULL_NOT_INITIALIZED | NULL_NOT_FOUND | NULL_REMOVED
        
        Les contraintes strictes sur les types est un sujet très intéressants et peu défriché. En fait tu l'as à haut niveau en OCaML/haskell, et à bas niveau avec des langage comme Esterel, etc... En OCaML/haskell, tu peux faire du type somme, du polymorphisme, bref des types algébriques assez poussé. En Esterel, tu peux mettre des contraintes sur tes entiers, mais Esterel, c'est fait pour du circuit logique (des processeurs quoi).
        
        Bref, ya pa encore de langage qui le gère sur toute la longueur du problème.
        
        En C++ avec les templates, tu peux faire pas mal de choses. Le gros problème de C++, c'est que la sémantique étant catastrophiquement bloatware, et que (donc) le compilateur étant basé sur de la compilation séparé, il est absolument impossible de faire une analyse de flot sur la totalité de ton code pour exporter les contraintes de tes types.
        En d'autres terme, le gros problème de C++/Template c'est que le compilo va checker ce qu'il peut checker avec les valeurs en dures qu'il trouve dans le code.
        S'il n'en trouve pas, ton code est pas testé, et ça plante au runtime, comme les autres.
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: Encore le type Null...
        
        Posté par lasher le 12 octobre 2011 à 16:05. Évalué à 2.
        
        Sauf que ça fait un moment que les bons compilos C/C++ font de l'optimisation inter-procédurale, et peuvent donc générer des « pseudo » fichiers objets qui contiennent des infos pertinentes pour faire de l'optim au moment de l'édition des liens. Alors certes, parfois ça mène au compilateur qui t'explique que y'a beaucoup trop de choses à analyser, et du coup il s'arrête ou bien il continue en faisant de la compilation uniquement par module. Mais l'IPC est censée être utilisée uniquement pour ce qui en vaut la peine (noyau de calcul très utilisé à plusieurs endroits d'un code, bibliothèque de code optimisée aux petits oignons, etc.).
        
        De plus en ce qui concerne les templates, à cause de la façon dont ils fonctionnent en C++, s'il s'agit d'un template de classe, alors de toute manière il est forcément inclus en entier dans le fichier qui l'utilise et le compilateur a donc toutes les informations nécessaires pour optimiser à fond.
        
        [^] # Re: Encore le type Null...
        
        Posté par barmic le 12 octobre 2011 à 15:12. Évalué à 2.
        
        J'ai l'impression que ce qui impact le plus la robustesse c'est l'obligation de gérer le cas Null plus que son interdiction.
        Je pense que boost::optional n'est pas si mal que ça dans son usage (il faudrait que je teste comment il réagi en cas d'erreur).
        
        En tout cas je te remercie beaucoup pour ton explication aussi claire que précise.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Encore le type Null...
        
        Posté par Ontologia (site web personnel) le 12 octobre 2011 à 15:22. Évalué à 4.
        
        J'ajoute juste que ce pattern est spécifiquement intéressant lorsque le compilateur est capable de détecter l'exhaustivité des cas.
        
        Scala possède ce pattern, mais le compilateur n'étant pas capable de vérifier l'exhaustivité des cas, même simple, c'est là totalement inutile, car on va remplacer un Null Pointer Exception par un cas non géré, un Match Failure.
        Le programme plante, ça revient exactement au même.
        
        L'intérêt des langages comme OCaML/Haskell, c'est leur capacité à vérifier à la compilation l'exhaustivité des cas. Et c'est très difficile à faire.
        
        Cela implique que la transformation "sémantique" qu'on a fait avec le type Null*, en y impliquant une contrainte à la déclaration, est détecté à la compilation partout dans le code où la valeur risque d'être utilisé.
        C'est là que réside la puissance du concept !
        
        *Dans les langages objets, le type Null est un en même temps un type et une valeur, puisqu'elle représente le "rien". Rien est en même temps une chose et son instance, marrant non ?
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Javascript must die

Posté par Pierre Tramonson le 12 octobre 2011 à 10:41. Évalué à 3.

La syntaxe est très décevante [...] Ça me paraît absurde qu’un langage sortant en 2011, impose encore la présence de « ; » pour séparer les instructions se trouvant sur des lignes séparées.

Et la lisibilité du code elle pue ? Je veux bien vous voir maintenir du code développé par un développeur n'en ayant rien à battre et fan de Perl.

Le typage statique optionnel [...]

C'est juste que ça rend possible le débuggage et facilite l'intégration dans un IDE un peu évolué. Par exemple cela peut aider pour du refactoring.

Les classes sont la bienvenue. [...]

A la place Javascript propose ... heu rien.

Même chose pour la bibliothèque standard : ça existe déjà et cela pourrait être facilement intégré dans JavaScript.

Non ça n'existe pas en Javascript. On se retrouve à utiliser des bibliothèques récupérées sur Internet (en jonglant avec les incompatibilités) pour tenter de pallier aux manques du langage.
Il y a pléthore de fonctionnalités qui devraient être en standard.

La question des performances reste en suspens.

Sur ce point il sera difficile de faire pire que Javascript.

Javascript souffre des mêmes défauts que PHP de mon point de vue, et tout ce qui peut conduire à la disparition de Javascript a ma bénédiction.
- [^] # Re: Javascript must die
  
  Posté par gasche le 12 octobre 2011 à 11:43. Évalué à 6.
  
  Le typage statique optionnel
  C'est juste que ça rend possible le débuggage et facilite l'intégration dans un IDE un peu évolué. Par exemple cela peut aider pour du refactoring.
  
  C'est une idée reçue convaincante, mais en pratique les premiers IDE évolués à proposer ce genre de chose étaient des environnement de développement pour Smalltalk et Lisp. Il est absolument faux de dire que le debug n'est "pas possible" dans un langage sans typage statique, et à ma connaissance Lisp et Smalltalk restent toujours inégalés dans ce domaine.
  
  (Exemple qui m'a toujours fait rêver : avec les exceptions resumable de Lisp, quand un programme lance une exception qui n'est pas rattrapée il se fige, le programmeur peut inspecter le problème (explorer les valeurs etc.), corriger le code, et revenir au point du programme qui avait lancé l'exception, le tout sans arrêter le programme.)
  
  Ce qui rend le débuggage difficile, ce sont les langages qui avec type erasure, où l'information de typage n'est pas conservée à l'exécution. Tous les langages qui font ça sont des langages typés statiquement (même si beaucoup de langages typés statiquement ne le font pas); ceci dit, ça a des avantages en performance, donc c'est un compromis à faire.
  
  L'idée selon laquelle le typage est nécessaire pour les IDE, le refactoring et le debug est historiquement fausse.
  - [^] # Re: Javascript must die
    
    Posté par Michaël (site web personnel) le 13 octobre 2011 à 07:11. Évalué à 2.
    
    (Exemple qui m'a toujours fait rêver : avec les exceptions resumable de Lisp, quand un programme lance une exception qui n'est pas rattrapée il se fige, le programmeur peut inspecter le problème (explorer les valeurs etc.), corriger le code, et revenir au point du programme qui avait lancé l'exception, le tout sans arrêter le programme.)
    
    Par curiosité, il sait aussi remonter le temps du programme? (Comme le debugger de OCaml.)
    - [^] # Re: Javascript must die
      
      Posté par gasche le 13 octobre 2011 à 09:00. Évalué à 2.
      
      Je parle là de l'exécution "normale" d'un programme, pas du debugger. Je doute que "remonter le temps" soit possible sans un gros surcoût. Par contre, le programmeur peut mettre en place lui-même des "points de sauvegarde" en capturant des continuations aux endroits où il veut pouvoir revenir.
# Présentation de DART à Sophia-Antipolis le 20 octobre

Posté par jcr83 le 12 octobre 2011 à 11:05. Évalué à 1.

Dans le cadre de la conférence Riviera DEV, organisée par le RivieraJUG,
Florian Loitsch, membre de la Dart team lead, présentera le langage :
Dart, a new programming language for structured web programming.

Plus d'infos sur http://rivieradev.fr/ .

Suivre le flux des commentaires

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