IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Dart Discussion :

Dart : Google prépare un nouveau langage de programmation structuré pour le Web


Sujet :

Dart

  1. #101
    Membre confirmé
    Profil pro
    C Embarqué / C++ Qt
    Inscrit en
    Janvier 2010
    Messages
    231
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : C Embarqué / C++ Qt

    Informations forums :
    Inscription : Janvier 2010
    Messages : 231
    Points : 648
    Points
    648
    Par défaut
    Le soucis : la compatibilité.

    Un énième activex, xul, ou encore Flash qui n'est pas portable parce que nécessite une installation. Ceux qui auront Chrome, cool pour eux, mais foutu pour les autres.

    Désolé, je n'adhère pas.

    Je préfère prêcher pour une évolution de JS et pour former correctement les développeurs qui l'utilisent souvent n'importe comment sans avoir pris la peine d'essayer d'en comprendre les subtilités.
    - Pour notre projet Web, il faut utiliser Dart pour le côté client, c'est super !
    - Et c'est compatible avec IE ? Tu sais, le navigateur utilisé par 40% des internautes dans le monde.
    - Non.
    - Bon ben c'est non alors. Retourne à ton JavaScript !
    Dart s'exécute soit une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript compatible avec Chrome, Safari 5+ et Firefox 4+ (d'autres navigateurs suivront).

    Donc pas de problème de compatibilité

  2. #102
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 309
    Points : 928
    Points
    928
    Par défaut
    Je ne suis pas sûr que le but soit de "tuer javascript", ce qui me semblerait un poil trop ambitieux, vu la quantité de code existant dans ce langage. C'est plus d'apporter une alternative crédible et mieux pensé à ce langage, mais aussi je pense de fournir un laboratoire d'idées qui pourront, si elles s'avèrent bonnes à l'usage, éventuellement être intégrées dans les futures évolution de js.

    La question qui se pose maintenant est de savoir si Dart offre suffisamment d'avantage comparé à js pour ne serait-ce qu'intéresser les programmeurs (avoir le tampon Google ne suffit pas forcément à rendre un langage intéressant, voir Go).

    Le peu que j'ai vu ne m'a pas vraiment fait l'effet d'un truc révolutionnaire. Effectivement, le scoping est lexicale et non dynamique, mais la nouvelle version de javascript en mode strict le permet déjà.

    Peut être que le modèle objet aura l'air plus familier aux habitués de Java et confrères. En revanche je n'ai pas eu l'impression que le langage vienne directement avec des capacités d'exploration du DOM supérieur à celles de JS, qui auraient pu rendre des bibliothèque tels que jquery plus ou moins inutiles, et entrainer de gros gains de performances. Bien sûr, il y a des sucres syntaxiques "amusant" comme les seteurs et geteurs.

    Enfin, le système de type optionnel me parait assez peu intéressant. Dans l'idée, ça me semble bien de laisser les gens qui le veulent hacker en dynamique (même si je reste personnellement convaincu qu'un langage fortement typé n'est pas un problème pour le prototypage, ce n'est pas l'avis de la majorité, et la majorité a, dans une certaine mesure, forcément raison). Mais je n'arrive pour l'instant pas à percevoir l'intérêt d'ajouter des types. De ce que j'ai lu, ça rajoute l'emmerdement du typage explicite, à savoir la verbosité (qui, faut-il le rappeler, n'est pas un mal obligatoire des systèmes de types, l'inférence, ça existe), sans apporter masse des avantages, à savoir une capture statiques d'un certaine classe d'erreurs, des gains de performances et la "documentation" nécessairement à jour. Ici, les types ne sont "vérifiés" qu'à run time, et rien n'empêche moralement d'écrire n'importe quoi (donc exit la "doc à jour"). En plus ils expliquent que les vérifications de type en question sont trop lourdes pour être effectuées à runtime, donc il faut le faire uniquement en mode développement, et les désactiver en prod.

    En gros, leur système de type optionnel me semble être tout au plus un forme très pauvre de contrat dynamique (je rappelle que les contrats permettent d'exprimer des propriétés nettement plus intéressantes, telle que "un entier pair" ou "une fonction qui attend un flottant x et retourne un flottant y telle que y * y ~ x"). Peut être que de "vrais" typeurs feront leur apparition, mais j'ai la triste impression qu'ils ont fait le design du "système de type optionnel" sans vraiment regardé ce qui se faisait ailleurs (les travaux sur le typage de scheme, les liketypes, etc etc). Tout cela m'a l'air très très "naïf".

    Toujours dans le domaine du système de type, je n'ai (pour l'instant) rien vu sur les "types natifs", un peu comme ce qui apparait en javascript, qui permet d'allouer des tableaux de données consécutives. Il semblerait donc que Dart se retrouve être encore moins adapté que js comme cible pour un backend de compilateur.

    Mais bon, je n'ai pas encore eu le temps de lire toute la spec du langage, donc tout ce que je dis là est sur mes premières impressions, pas sur une étude profonde de la bête !

  3. #103
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 309
    Points : 928
    Points
    928
    Par défaut
    J'ajouterai que je viens de voir

    Dart code is always single threaded. There is no shared-state concurrency in Dart. Concurrency is supported via actor-like entities called isolates.
    An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (10.14.4). No state is ever shared between isolates. Isolates are created by spawning (10.11).
    dans la doc, ce qui est plutôt bon signe !

  4. #104
    Membre éprouvé
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    657
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2010
    Messages : 657
    Points : 1 240
    Points
    1 240
    Par défaut
    Je ne suis pas sûr que le but soit de "tuer javascript", ce qui me semblerait un poil trop ambitieux, vu la quantité de code existant dans ce langage.
    On peut tout à fait faire coexister 2 langages au sein d'une page ( IE avec VB et Jscript par exemple ) , dont ce n'est absolument pas un problème.
    Le problème de javascript est que c'est un standard que la plupart des développeurs détestent ,car il n'est pas multiparadigme et n'a absolument pas été pensé pour ce qu'on lui fait faire aujourd'hui.
    DART peut fonctionner si les applications DART sont plus faciles à développer que des applications javascripts. Les solutions les plus simples pour le développeur sont toujours les meilleurs. Javascript est complexe car c'est un langage dont le CORE ne répond pas aux soucis du développement moderne.

  5. #105
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 653
    Points : 3 773
    Points
    3 773
    Par défaut
    Citation Envoyé par Bestel74 Voir le message
    Dart s'exécute soit une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript compatible avec Chrome, Safari 5+ et Firefox 4+ (d'autres navigateurs suivront).

    Donc pas de problème de compatibilité
    Le compilateur en question est-il déjà présent sur les navigateurs cibles ? Si oui, alors mea culpa (même si pas d'IE pour l'instant est rédhibitoire). Si non, on peut reprendre mon petit dialogue en y ajoutant d'autres navigateurs, et le résultat sera le même.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  6. #106
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 309
    Points : 928
    Points
    928
    Par défaut
    Citation Envoyé par air-dex Voir le message
    Le compilateur en question est-il déjà présent sur les navigateurs cibles ? Si oui, alors mea culpa (même si pas d'IE pour l'instant est rédhibitoire). Si non, on peut reprendre mon petit dialogue en y ajoutant d'autres navigateurs, et le résultat sera le même.
    Présent *sur* les navigateurs ?? Mais rien à voir.. On écrit du code en Dart, on le compile vers javascript, et c'est ce code javascript qui est envoyé au client. Qui ne voit (pour l'instant) jamais le code Dart.

  7. #107
    Membre éprouvé
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    657
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2010
    Messages : 657
    Points : 1 240
    Points
    1 240

  8. #108
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Sympa ce truc, ça a l'air de contenir pas mal de bonnes choses... Mais Traceur et Dart ne sont pas le même langage ; si j'ai bien compris Traceur se veut la prochaine génération de Javascript (plus précisément c'est un compilateur de ce "futur javascript" vers l'actuel)

  9. #109
    Membre éprouvé
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    657
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2010
    Messages : 657
    Points : 1 240
    Points
    1 240
    Par défaut
    En fait traceur peut faire une compil vers javascript "offline" à priori ( sans mettre un lien vers le compilateur ) comme DART.
    je vais faire mon relou , mais pour moi un vrai paradigme de classes ( classes , interfaces et classes abstraites ) est indispensable dans javascript.
    Et ce n'est pas parce qu'on se débrouille sans jusqu'a présent que cela ne pourrait pas faciliter le dev.
    les modules , les traits , les structs et les proxies , c'est bien mais moins urgent.
    On verra se que DART donne , à google de construire des APP et une bonne lib autours, ce qui manque à GO je pense.
    Bon développement à tous.

  10. #110
    Invité
    Invité(e)
    Par défaut
    Dart s'exécute soit une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript
    mais si on cree avec dart pour retranscrire en javascript autant l'ecrire directement en javascript

  11. #111
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Citation Envoyé par mekal Voir le message
    mais si on cree avec dart pour retranscrire en javascript autant l'ecrire directement en javascript
    Ah bon ? Je vais reprendre ton analogie à un autre niveau : si on crée avec C++ pour retranscrire en assembleur, autant l'écrire directement en assembleur...
    Et maintenant, tu es toujours du même avis ?

    Ca me fait penser à l'article de Scott Hanselman selon lequel Javascript serait en train de devenir l'assembleur du web...

  12. #112
    Membre chevronné
    Avatar de gwinyam
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mai 2006
    Messages
    1 162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2006
    Messages : 1 162
    Points : 2 015
    Points
    2 015
    Par défaut
    Citation Envoyé par camus3 Voir le message
    je vais faire mon relou , mais pour moi un vrai paradigme de classes ( classes , interfaces et classes abstraites ) est indispensable dans javascript.
    Et ce n'est pas parce qu'on se débrouille sans jusqu'a présent que cela ne pourrait pas faciliter le dev.
    Cela va à l'inverse exact de la philosophie objet de JS (prototypes). A mon avis, tu peux simplement oublier cette idée.
    Comparez la qualité et le prix du matériel de bricolage ou de maison avant d'acheter : MatosMaison
    Le bouton ne masse pas les pieds, mais ça aide la communauté.

  13. #113
    LLB
    LLB est déconnecté
    Membre expérimenté
    Inscrit en
    Mars 2002
    Messages
    967
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 967
    Points : 1 410
    Points
    1 410
    Par défaut
    Citation Envoyé par TropMDR Voir le message
    Le peu que j'ai vu ne m'a pas vraiment fait l'effet d'un truc révolutionnaire. Effectivement, le scoping est lexicale et non dynamique, mais la nouvelle version de javascript en mode strict le permet déjà.
    Oui. Le langage n'a rien de révolutionnaire. C'est toujours risqué de faire un langage innovant ; Google n'a pas voulu prendre de risque supplémentaire : réussir à populariser une alternative à Javascript est déjà un grand défi. Le langage me semble facile à prendre un main, je n'ai pas vu de grande surprise dans les specs. Ce sera plus facile pour les développeurs de l'utiliser que si c'était un langage type Haskell, Lisp ou autre.

    Citation Envoyé par TropMDR Voir le message
    Enfin, le système de type optionnel me parait assez peu intéressant. Dans l'idée, ça me semble bien de laisser les gens qui le veulent hacker en dynamique (même si je reste personnellement convaincu qu'un langage fortement typé n'est pas un problème pour le prototypage, ce n'est pas l'avis de la majorité, et la majorité a, dans une certaine mesure, forcément raison). Mais je n'arrive pour l'instant pas à percevoir l'intérêt d'ajouter des types. De ce que j'ai lu, ça rajoute l'emmerdement du typage explicite, à savoir la verbosité (qui, faut-il le rappeler, n'est pas un mal obligatoire des systèmes de types, l'inférence, ça existe)
    Si on reprend les objectifs de Dart, on y trouve :
    1) Offrir de meilleures performances
    2) Faciliter l'utilisation d'outils (IDE, refactoring...)

    Pour ces deux points, le typage explicite apporte énormément.

    Dans la course aux performances, les navigateurs sont passés de l'interprétation pure au bytecode puis au JIT. Récemment, ils ont essayé de faire de l'inférence de type pour générer du code meilleur, mais ca reste limité. Avoir de l'information de type statique aide à la génération de code.

    Je trouve que le typage optionnel est un très bon compromis. D'un côté, les utilisateurs de Dart (venant donc de Javascript) pourront continuer à avoir du typage dynamique s'ils le souhaitent. Leur imposer du typage statique serait vu comme une régression (tout n'est pas typage statiquement). De l'autre, cela permet d'ajouter l'information de type par endroits, de facon très simple.

    Le 2e point est tout aussi important : difficile de faire du refactoring, de fournir de la complétion de code sur quelque chose qui est entièrement dynamique comme Javascript. Google prépare un IDE, qui en tirera forcément partie. De cette facon, les développeurs seront incités à typer leur code, lorsque c'est possible.

    Enfin, cela apporte de la sûreté : le code est vérifié à la compilation. Comme exécution et compilation sont mélangées, la différence ne sera pas aussi nette qu'en C, mais les erreurs seront signalées plus tôt qu'avec Javascript. Je suppose qu'il y aura un moyen de vérifier le code aussi (en dehors du navigateur).

    Ce qui me gêne pour ma part, c'est la présence de null (qui est une valeur possible pour tous les types). La Billion Dollar Mistake a déjà fait suffisamment de mal...

  14. #114
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    309
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 309
    Points : 928
    Points
    928
    Par défaut
    Citation Envoyé par LLB Voir le message
    Ce sera plus facile pour les développeurs de l'utiliser que si c'était un langage type Haskell, Lisp ou autre.
    [...]
    Je trouve que le typage optionnel est un très bon compromis.
    Si tu penses que j'ai suggéré qu'ils auraient du produire un langage à la Haskell, c'est que je me suis très mal exprimé. Il est clair que je suis un aficionados du typage, et que je pense qu'un typage fort et statique est une excellente chose, et que le typage est une aide bien plus qu'un poids ou une contrainte.
    Ceci étant dit, je suis aussi un brin réaliste et pragmatique, et je me rends bien compte que beaucoup de programmeurs ne partagent pas mon point de vue, et aiment les langages dynamiques. Ils offrent une flexibilités et une concision que les langages typés "main stream" n'ont pas, et une facilité de premier accès qu'aucun langage typé n'a. Il me semble donc que l'approche du typage optionnelle est excellente. C'est, si l'on veut, un moyen de montrer la lumière aux utilisateurs de langages dynamiques :p Ca permet d'apporter progressivement et sans douleur la puissance du typage (que ce soit pour les IDE, la vitesse d'exécution, la "programmation guidée par le typage", la détection d'erreur, le refactoring, que sais-je encore) au monde du dynamique.

    Ma critique n'était donc pas sur l'idée de faire du typage optionnel, mais bien sur la réalisation de cette idée dans le cas de Dart.
    [WARNING]C'est mon coté "académique frustré" qui va s'exprimer à partir de maintenant[/WARNING]
    Le typage optionnel n'est pas une idée nouvelle, et de très nombreux travaux ont été fait sur le sujet. Par exemple ceux de Matthias Felleisen et son équipe sur Typed Scheme, qui permet de faire cohabiter du Scheme typé et non typé (et de typer des idioms de scheme à première vu extremement "dynamiques), mais aussi par exemple un papier à POPL l'an dernier sur les like types. Mais il y en a plein d'autres, sur les plugable types, etc etc etc.

    Et là pour Dart, qu'est ce qu'on a comme design ? En gros, quelqu'un s'est dit "ce serait bien d'avoir des types optionnels". Donc ils ont mis des types, et ils sont optionnels. Et la solution trouvée pour faire coexister le monde typé et le monde non typé ? C'est facile, en fait les types ne servent à rien \o/ Ils sont tout simplement effacé dans la sémantique du langage. Tu peux mettre n'importe quoi, ça ne change rien. Moralité, un design simpliste à mourir, qui ne poussera pas grand monde à utiliser des types ! On a l'impression d'avoir juste un java où on aurait viré les types, et où on aurait le droit de les remettre, mais où ça ne servirait à rien.

    Je sais que le monde de la recherche académique a du mal à produire des solutions viables, des produits finis, etc. Mais quand même, quand on se lance dans le design d'un nouveau langage, regarder un minimum ce qui s'est fait dans le monde de la recherche dans les 20 dernières années, ce serait pas mal J'ai clairement eu la même frustration avec Go. Là, c'est un tout petit peu moins mauvais, mais on reste quand même sur un design de langage vieux de 10 ans (java). C'est un peu triste :–\

  15. #115
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2005
    Messages
    262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2005
    Messages : 262
    Points : 665
    Points
    665
    Par défaut
    Citation Envoyé par tomlev Voir le message
    Ca me fait penser à l'article de Scott Hanselman selon lequel Javascript serait en train de devenir l'assembleur du web...
    Alors ça c'est vraiment pas bête.

    On a pas vraiment besoin d'un remplaçant de javascript (Dans le sens langage supporté par la plupart des navigateurs) avec des avantages et inconvénients par rapport au javascript actuel. Ce nouveau langage ne pourrait pas faire que des heureux : certains le voudraient facile, d'autre strictement typé, d'autres voudraient un langage fonctionnel, d'autres voudraient les templates...

    Pourquoi les développeurs devraient-ils se limiter à un langage pour le développement côté client ? Pourquoi les navigateurs devraient perdre du temps à exécuter un langage de haut niveau, objet, plus ou moins rigoureusement typé ?

    Ce qu'il faudrait c'est que les navigateurs exécutent un langage de bas niveau, genre assembleur, ou même un byte code.

    Les développeurs auraient ensuite tout un tas de langages existant et futurs compilant vers ce langage.

    Comme l'explique l'article, cette théorie est déjà pas mal appliquée en se servant du javascript comme langage intermédiaire. Les défauts de celui-ci ne sont alors plus que ses piètres performances.

    Dart a peut être un avenir comme langage compilé vers javascript. Mais dans les navigateurs, il risque de se retrouver dans la situation de flash/applet java/silverlight : un support plus ou moins répandu.

    Le remplaçant de javascript ne devrait donc pas être un langage "trop cool" à développer, mais un truc bas niveau, simple (Peu d'instructions), performant à l'exécution et facile à implémenter dans les navigateurs.

  16. #116
    Membre confirmé
    Profil pro
    Inscrit en
    Mars 2011
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2011
    Messages : 240
    Points : 636
    Points
    636
    Par défaut
    Citation Envoyé par rt15 Voir le message
    Ce qu'il faudrait c'est que les navigateurs exécutent un langage de bas niveau, genre assembleur, ou même un byte code.

    Les développeurs auraient ensuite tout un tas de langages existant et futurs compilant vers ce langage.
    Cette idée est déjà largement rependue. Reste des problèmes de sécurité difficile à régler. Exécuter du code bas niveau développé par je ne sais qui à chaque chargement de page peut avoir des conséquences fâcheuses pour la stabilité du système. Autant télécharger et double cliquer sur tout les virus possible et prier à chaque fois pour que ton os fonctionne normalement.

  17. #117
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Citation Envoyé par psykokarl Voir le message
    Cette idée est déjà largement rependue. Reste des problèmes de sécurité difficile à régler. Exécuter du code bas niveau développé par je ne sais qui à chaque chargement de page peut avoir des conséquences fâcheuses pour la stabilité du système.
    Code bas niveau ne signifie pas forcément du code machine qui s'exécute directement sur le processeur... Ca peut être du code qui cible une machine virtuelle dans le navigateur, avec un jeu d'instructions restreint qui ne laisse pas de possibilité d'accéder directement au système hôte

  18. #118
    Membre confirmé
    Profil pro
    Inscrit en
    Mars 2011
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2011
    Messages : 240
    Points : 636
    Points
    636
    Par défaut
    Citation Envoyé par tomlev Voir le message
    Code bas niveau ne signifie pas forcément du code machine qui s'exécute directement sur le processeur... Ca peut être du code qui cible une machine virtuelle dans le navigateur, avec un jeu d'instructions restreint qui ne laisse pas de possibilité d'accéder directement au système hôte
    L’accès se fera tout simplement de manière indirecte en exploitant les failles du navigateur et du système hôte. C'est précisément la recherche anticipée de ces failles qui fait que cela prend du temps.

  19. #119
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Citation Envoyé par psykokarl Voir le message
    L’accès se fera tout simplement de manière indirecte en exploitant les failles du navigateur et du système hôte. C'est précisément la recherche anticipée de ces failles qui fait que cela prend du temps.
    Le problème se pose déjà avec Javascript, donc rien de nouveau sous le soleil... Avec une machine virtuelle bien conçu le risque ne sera pas plus important que maintenant

  20. #120
    Membre confirmé
    Profil pro
    Inscrit en
    Mars 2011
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2011
    Messages : 240
    Points : 636
    Points
    636
    Par défaut
    Schématiquement...

    Le Javascript haut niveau peut être assimilé à un ensemble de fonctions mis à disposition par le navigateur. Il «suffit» donc de s'assurer que les fonctions fonctionnent conforment aux specs. Cela revient à contrôler les sorties en fonction des entrées et de s'assurer tout se comporte normalement dans la boite.

    Avec le Javascript bas niveau, il n'y a plus cette notion boite. Restreindre les instructions n'a pas de sens. Il me semble qu'il n'en faut que quatre (goto, read, write, NAND/NOR) pour faire absolument ce que l'on veut. Si on en enlève ne serait ce qu'une de ces instructions, on ne peut plus rien faire.
    Ce qu'il faut c'est contrôler si la donnée manipulée par chaque instruction reste bien dans un domaine défini. C'est la que ça se corse...

    La philosophie de la machine virtuelle est : «si ça doit planter ça plantera, le système sera épargné». Le problème est qu'un code malveillant bien conçu ne plante pas à moins que ce soit précisément ce qui est cherché. Une machine virtuelle, même bien conçue, posera d'avantage de problème de sécurité. Il ne faut pas oublier qu'une appli destiné à une machine virtuelle est contrôlée par une communauté ou sera garantie fonctionner d'une façon précise par son concepteur. Ça ne sera pas le cas d'un bout de code pris au hasard sur le web...

Discussions similaires

  1. [OpenSource][C++] Eplith: Un nouveau langage de programmation
    Par Quent42340 dans le forum Mon programme
    Réponses: 2
    Dernier message: 02/06/2012, 23h32
  2. Réponses: 130
    Dernier message: 04/02/2011, 11h11
  3. Choix d'un nouveau langage de programmation
    Par ProgVal dans le forum Langages de programmation
    Réponses: 9
    Dernier message: 09/01/2010, 16h20
  4. Comment rajouter un nouveau langage de programmation ?
    Par Acropole dans le forum Eclipse
    Réponses: 2
    Dernier message: 12/11/2009, 16h40
  5. Nouveau langage de programmation : le langage G
    Par G-FACTION dans le forum Autres langages
    Réponses: 10
    Dernier message: 19/07/2009, 20h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo