Discussion :

[Uther]

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.

Si on faisait une machine virtuelle de type bytecode, il faudrait qu'elle ait accès aux mêmes API que javascript, il serait complètement idiot d'autoriser tout et n'importe quoi.
Pas de problèmes de sécurité à ce niveau.

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.

Théoriquement oui, mais les machine virtuelles sont un peut plus évoluées que ça.

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...

- Certes mais c'est tout aussi valable pour un interpréteur Javascript, qu'une VM qui ferait tourner du Bytecode. C'est même pire dans le cas de Javascript, car il est bien plus complexe et offre donc une plus grande surface d'attaque.
- La plupart des VM vérifient la validité du bytecode quelles exécutent, ce qui limite encore plus les risques.

[psykokarl]

Il se trouve que tout programme est équivalent à une composition de ces instructions de base. Ce n'est pas théorique et la complexité d'une VM ne change rien à cette réalité. A moins de vouloir faire de la virtualisation...

Le bytecode ne sert pas à générer du code difficile à lire pour le plaisir. C'est un code qui permet de générer de l'assembleur, voir du code machine avec un minimum d'opération. En l’occurrence le bytecode JavaScript permettrait de générer des appels à l'API avec un minimum d'opération.

Arrêtes moi si je me trompe mais si il y a contrôle, n'est ce pas avant la génération du bytecode et non au moment de l’interprétation de celui ci ?
Il me semble que cela fait ainsi pour des raisons de vélocité à l’exécution.

Si tu sous entendais par API celui l'OS. L'API JavaScript étant un ensemble d'applications sur un sous ensemble des fonctions de l'API de l'OS. Taper directement dans l'API de l'OS permet plus de choses, en bien comme en mal..

Si tu sous entendais par API celui JavaScript, on reste dans du JavaScript haut niveau avec ses petites boites. C'est du byte code pour faire joli.
Si tu entendais par bytecode JavaScript une forme de code plus compact et facile à parser. Il n'y a pas besoin modifier le langage. Il suffit générer du js bien écrit du point de vue machine. C'est probablement ce que fera Dart dans un premier temps.

Mes derniers posts répondaient à l'idée que les navigateurs puissent exécuter un langage bas niveau.
Peux tu me définir plus précisément ce que tu entends pas surface d'attaque de javascript ?

[Uther]

Je vais me baser sur Java qui est le cas de VM que je connais le mieux, je suppose qu'il en est de même pour les autres.

Le bytecode ne sert pas à générer du code difficile à lire pour le plaisir. C'est un code qui permet de générer de l'assembleur, voir du code machine avec un minimum d'opération. En l’occurrence le bytecode JavaScript permettrait de générer des appels à l'API avec un minimum d'opération.

Le but du bytecode est d'avoir une base simple et commune sur laquelle l'analyse lexiqale et syntaxique on déjà été faite(ou du moins en grande partie) et qui soit utilisable sur n'importe quelle architecture.

Il n'y a aucun lien direct avec le code binaire généré. A la base le byte code était d'ailleurs seulement interprété et le JIT(qui est arrivé après) est bien plus complexe que ce que tu sous-entends.

Arrêtes moi si je me trompe mais si il y a contrôle, n'est ce pas avant la génération du bytecode et non au moment de l’interprétation de celui ci ?
Il me semble que cela fait ainsi pour des raisons de vélocité à l’exécution.

Non, il y a aussi un contrôle très rapide de la validité du bytecode fait juste avant l’exécution par la JVM pour éviter l’exécution de bytecode invalide ou dangereux.

Si tu sous entendais par API celui l'OS. L'API JavaScript étant un ensemble d'applications sur un sous ensemble des fonctions de l'API de l'OS. Taper directement dans l'API de l'OS permet plus de choses, en bien comme en mal..

Non, taper dans toutes les API de l'OS est juste totalement inenvisageable, ou alors sa signifie revoir toute la politique de sécurité et on sort totalement du cadre du script.
A ce niveau la l'ActiveX ou la NPAPI, sont plus adapté et existent déjà.

Si tu entendais par bytecode JavaScript une forme de code plus compact et facile à parser. Il n'y a pas besoin modifier le langage. Il suffit générer du js bien écrit du point de vue machine. C'est probablement ce que fera Dart dans un premier temps.

En effet c'était mon idée, ça permettrait de programmer dans le langage que l'on souhaite qui serait compilé en un bytecode commun bien plus performant que le javascript même bien formé, vu qu'une grosse partie du travail (analyse lexicale, syntaxique, optimisations, ...) de interpréteur est déjà fait lors de la compilation.

La course des navigateurs à actuels à l’interpréteur le plus rapide à certes permis des progrès énormes, mais JavaScript n'étant, à la base, pas conçu pour son usage actuel, ça reste une course d'unijambistes.

Mes derniers posts répondaient à l'idée que les navigateurs puissent exécuter un langage bas niveau.

Ca c'est déjà possible via des technologies comme ActiveX, NaCl, NPAPI, ...

[TropMDR]

Le Javascript haut niveau peut être assimilé à un ensemble de fonctions mis à disposition par le navigateur.[...]
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.

J'ai l'impression que tu mélanges tout et n'importe quoi... Effectivement, il suffit d'un faible nombre d'instruction (bon là il te manque une conditionnelle je pense) pour obtenir un langage qui est dit "turing complet". Turing complet veut dire que l'ont peut "calculer" tout ce que n'importe quel autre programme peut calculer. C'est une notion théorique de calculabilité. Cela n'a RIEN à voir avec "on peut faire ce que l'ont veut de la machine", et heureusement. Je te signale au passage que le javascript (que tu appelles "haut niveau") est évidement turing complet.
Le danger arrive à partir du moment où l'ont peut accéder au système d'exploitation (en faisant un appel système donc), au quel cas on peut accéder aux fichiers, ouvrir des connections avec le monde extérieur, etc etc. Avoir du bytecode n'implique pas du tout d'avoir accès à ça. Je te rappelle que les applications java ou flash sont distribuées sous forme de bytecode. Ca ne veut pas dire que tu leur offres un accès illimité à ta machine, et heureusement !

D'ailleurs, ta distinction entre "ensemble de fonction" et "ensemble d'instruction" est purement arbitraire. Les fonctions javascript "haut niveau" ont le droit de modifier un état global du système (les variables, le DOM, le flot de controle, etc). Rien n'empêche de voir les instructions "bas niveau" du byte code comme des fonctions, qui font exactement la même chose. Read et write sont des accès aux variables, AND, OR, etc, des fonctions, et GOTO un appel de fonction pour aller ailleurs dans le code (modification du flot de controle). Il n'y a aucune véritable différence.

C'est un code qui permet de générer de l'assembleur, voir du code machine avec un minimum d'opération.

Machine virtuelle n'implique pas nécessairement de compilo JIT. Les machines virtuelles java n'ont, pendant très longtemps, pas contenu de JIT. Le bytecode a simplement comme avantage par rapport à un programme structuré d'être beaucoup plus facilement et rapidement interprétable, tout simplement parce que la structure de donnée est beaucoup plus simple (moralement, on a un tableau d'instructions consécutives en mémoire plutôt qu'avoir une structure d'arbre complexe). Le fait que maintenant il y ait des JITeurs est juste une évolutions technologiques, pas la raison d'être initiales des bytecodes et machines virtuelles.

Arrêtes moi si je me trompe mais si il y a contrôle, n'est ce pas avant la génération du bytecode et non au moment de l’interprétation de celui ci ?

Bien sûr que si il peut très bien y avoir controle sur le bytecode lui même. Par exemple dans la machine virtuelle java.

Et sinon, pour les histoires de bytecodes dans les navigateurs, voilà une intéressante discussion sur le sujet:

http://www.aminutewithbrendan.com/pages/20101122

[ludochm]

Hello,

J'ai lu plusieurs fois sur ce sujet que le javascript n'a pas été conçu pour faire ce à quoi on l'emploie actuellement.

Et j'aimerais qu'on éclaire un peu ma lanterne, vu qu'à mon sens il a été créé pour manipuler le contenu des pages web et les rendre dynamiques ; il me semble que c'est encore son utilisation première.

Merci

[TropMDR]

J'ai lu plusieurs fois sur ce sujet que le javascript n'a pas été conçu pour faire ce à quoi on l'emploie actuellement.

Et j'aimerais qu'on éclaire un peu ma lanterne, vu qu'à mon sens il a été créé pour manipuler le contenu des pages web et les rendre dynamiques ; il me semble que c'est encore son utilisation première.

Il a été conçu pour afficher l'heure ou faire clignoter une phrase. Il est utilisé pour écrire des client mail (gmail et autres), des jeux (canvas rider, etc), des traitement de texte (google documents), etc, etc.

Alors oui, ce sont dans les deux cas des "pages dynamiques". Mais disons que l'échele n'est pas vraiment la même !

[psykokarl]

Non, il y a aussi un contrôle de la validité du bytecode fait avant l’exécution par la JVM pour éviter l’exécution de bytecode invalide.

Contrôle au niveau syntaxique je veux bien. Au niveau sémantique c'est possible aussi mais c'est encore plus lourd. A mon avis les perfs ne sont pas au rendez vous.

Non, taper dans toutes les API de l'OS est juste totalement inenvisageable, ou alors sa signifie revoir toute la politique de sécurité et on sort totalement du cadre du script.
A ce niveau la l'ActiveX ou la NPAPI, sont plus adapté et existent déjà.

Je n'ai pas dit le contraire. C'est d'ailleurs à NaCl auquel je pensais quand on a commencé à parler d'un navigateur interpretant/compilant un langage plus bas niveau.

J'ai l'impression que tu mélanges tout et n'importe quoi... Effectivement, il suffit d'un faible nombre d'instruction (bon là il te manque une conditionnelle je pense) pour obtenir un langage qui est dit "turing complet". Turing complet veut dire que l'ont peut "calculer" tout ce que n'importe quel autre programme peut calculer. C'est une notion théorique de calculabilité. Cela n'a RIEN à voir avec "on peut faire ce que l'ont veut de la machine", et heureusement.

Je précise alors...
La différence entre fonction et instruction est en effet arbitraire. Afin de lever les malentendus j'entendais par fonction un ensemble d'instruction de bases, c'est à dire qu'on ne peut pas décomposer en élément plus simple.
Maintenant si on isole les fonctionnalités que permettent le système sous forme de composants (graphique, son, gestion fichiers, etc...). Ces composants devront être piloté en passant par un canal de communication. On peut considérer une fonction comme un protocole de communication qui permet d’écrire/lire sur ce canal.
Une manière plus brute ou plus bas niveau serait d'envoyer un flux d'instructions de bases plutôt que passer par des fonctions. Dans ce cas la sécurité fournie par les fonctions deviennent caduques. Limiter les instructions ne sert à rien si on peut envoyer ces instructions de bases sur le canal ou faire l'équivalent par composition de fonction.

C'est ce que j'entends par "faire ce que l'on veut".

Bien entendu il n'est pas question d'activer un son ou d'ouvrir une connexion si seul le canal graphique est accessible.

Le danger arrive à partir du moment où l'ont peut accéder au système d'exploitation (en faisant un appel système donc), au quel cas on peut accéder aux fichiers, ouvrir des connections avec le monde extérieur, etc etc. Avoir du bytecode n'implique pas du tout d'avoir accès à ça. Je te rappelle que les applications java ou flash sont distribuées sous forme de bytecode. Ca ne veut pas dire que tu leur offres un accès illimité à ta machine, et heureusement !

Bloquer totalement l’accès à une ressource est simple. C'est permettre l’accès et contrôler que l'on ne fasse pas n'importe quoi avec qui est compliqué.

Une application flash ou java est conçue et présenté pour fonctionner d'une façon précise dans un domaine précis: un calculatrice, un jeux ou un traitement texte. Cette application est garantie conforme à sa description par une communauté d'utilisateur ou par l'équipe de développement. Si la garantie n'est pas satisfaisante on peut ne pas lancer l'appli.
Au niveau du navigateur c'est différent. Le code est exécuté à la volé sans garantie sur son fonctionnement (et me parlez pas d'option de désactivation de script ou de liste de confiance, ce n'est pas le sujet...).
Il me semble qu'avec java on peut:
- charger une image postmoderne toto.jpeg.
- renommer ce fichier en toto.dll
- charger la dll toto.dll
- s'amuser avec les fonctions à dispositions qui elles ne sont pas contrôlées le moins du monde.
Bien sur c'est un exemple très schématique.

[TropMDR]

Bon là je suis perdu.

Je pense que tu confonds les instructions d'une machine virtuelle avec les instructions d'un processeur, et tu que tu penses que sous prétexte que les premières sont "bas niveau", elles sont équivalentes aux secondes.

Allez, j'ai plein de boulot, donc je vais procrastiner en te donnant un exemple montrant pourquoi ça n'a rien à voir: imaginons le design suivant d'une machine virtuelle:

Un tableau d'instructions, un tableau mémoire (chaque case contient un mot de 8 bits), et 8 variables numérotées de V0 à V7,
Imaginons maintenant les instructions suivantes
imed num: ecrit num dans V0
mv var1 var2: copie l'information de la variable var1 à la variable var2
jmp: saute à l'adresse contenue dans V0
jmpif: saute à l'adresse contenue dans V0 si V1 est non nul
and, or, xor: met dans V0 le and, or, xor logique de V1 et V2
read: mets dans V1 le contenu de la case du tableau mémoire dont le numéro est contenu dans V0 si le numéro de la case est valide, ne fait rien sinon
write: mets dans la case du tableau mémoire dont le numéro est contenu dans V0 le contenu de V1, si le numéro de la case est valide, ne fait rien sinon

Et maintenant l'exécution de la machine virtuelle consiste à lire la première instruction dans le tableau d'instruction, et à l'exécuter, puis à passer à la suivante si un saut n'a pas été effectué. Si la dernière instruction est atteinte, ou si un saut est effectué à une instruction qui n'existe pas (en dehors du tableau), l'exécution s'arrête et le contenu de la mémoire est imprimée sur la sortie standard.

tu vois, on a un design extrêmement bas niveau (mais je pense turing complet). Pourtant, il n'est pas possible d'aller ouvrir des fichiers, d'ouvrir des connexions, etc.

Et pour revenir au cas de java: oui, en java il est possible d'ouvrir des fichiers etc. Mais quand on télécharge une applet java, elle est exécuté dans une machine virtuelle spéciale, équipée d'un "bac à sable", qui empêche ces instructions de s'exécuter.
Et le controle du bytecode java n'est pas purement "syntaxique". Tu aurais pu au moins suivre le lien que j'ai donné qui explique que l'algorithme vérifie bien plus que ça.

Après les histoires d'envoyer des flux d'instructions bas niveau, je n'ai rien compris, donc je ne peux pas trop réagir.

[Uther]

Contrôle au niveau syntaxique je veux bien. Au niveau sémantique c'est possible aussi mais c'est encore plus lourd. A mon avis les perfs ne sont pas au rendez vous.

Le controle syntaxique est sémantique du code source est fait au moment de la complition java->bytecode. Le contrôle de la JVM, s'assure juste que le bytecode exécute est valide, ce qui ne devrait se produire que si le bytecode a été modifié manuellement après compilation.

La différence entre fonction et instruction est en effet arbitraire. Afin de lever les malentendus j'entendais par fonction un ensemble d'instruction de bases, c'est à dire qu'on ne peut pas décomposer en élément plus simple.
Maintenant si on isole les fonctionnalités que permettent le système sous forme de composants (graphique, son, gestion fichiers, etc...). Ces composants devront être piloté en passant par un canal de communication. On peut considérer une fonction comme un protocole de communication qui permet d’écrire/lire sur ce canal.
Une manière plus brute ou plus bas niveau serait d'envoyer un flux d'instructions de bases plutôt que passer par des fonctions. Dans ce cas la sécurité fournie par les fonctions deviennent caduques. Limiter les instructions ne sert à rien si on peut envoyer ces instructions de bases sur le canal ou faire l'équivalent par composition de fonction.

C'est ce que j'entends par "faire ce que l'on veut".

Bien entendu il n'est pas question d'activer un son ou d'ouvrir une connexion si seul le canal graphique est accessible.

Il y a un gros mélange de tous les termes alors quelque définition informatiques de base:

- API : Si je te comprends bien ce que tu appelle fonction est en fait une API(Application Programming Interface), c'est a dire un ensemble de fonction que le programmeur peut appeler pour accéder au ressources du système.

- Haut et bas niveau : Un langage bas niveau est un langage entièrement dépendant de l'architecture du processeur, bref de l'assembleur.
Tous les autre langages sont officiellement des langages de haut niveau, même le C (malgré quelques petit défauts de portabilité).
il est vrai que ces termes sont souvent mal utilisés

- Interprété vs Natif : Les langages interprétés(ou compilés en bytecode) tout comme les langage compilés en natif sont tous les deux "Turing complete" comme tu le sous-entendait et peuvent donc tous les deux faire n'importe quoi dans la limite des droits qui leur sont alloués.

Même les langages compilé en natif ne peuvent pas agir librement en dehors de l'espace mémoire qui leur est réservé (du moins sur tous les processeur qui ont une MMU, c'est a dire tous les processeur grand public depuis 25 ans). S'il veulent aller au delà, il faut qu'ils passent par des API du système qui peuvent heureusement être limité.

La vraie limitation est donc au niveau des API disponible : un langage interprété avec accès à toute les ressource est infiniment plus dangereux qu'un langage de bas niveau natif sans aucun droits.

Au niveau du navigateur c'est différent. Le code est exécuté à la volé sans garantie sur son fonctionnement (et me parlez pas d'option de désactivation de script ou de liste de confiance, ce n'est pas le sujet...).
Il me semble qu'avec java on peut:
- charger une image postmoderne toto.jpeg.
- renommer ce fichier en toto.dll
- charger la dll toto.dll
- s'amuser avec les fonctions à dispositions qui elles ne sont pas contrôlées le moins du monde.
Bien sur c'est un exemple très schématique.

Surtout faux. Quand le java est utilisé pour les applet, les API auquelle il a accès sont justement limitées
On ne peut pas charger des DLL en Java sans que l'utilisateur ait a confirmer une fenêtre d'avertissement grave de sécurité.

[psykokarl]

Je pense que tu confonds les instructions d'une machine virtuelle avec les instructions d'un processeur, et tu que tu penses que sous prétexte que les premières sont "bas niveau", elles sont équivalentes aux secondes.

Non je ne confonds pas les deux, ne serait que parce que les instructions d'un processeur dépend de l'architecture de celui ci à contrario des instructions d'une VM java qui sont sensées être portable.

En fait, je crois que vous pensez bytecode JVM quand je pense assembleur/code machine. Il y a donc méprise sur ce que l'on appelle code bas niveau.
Si vous reportez à la définition que j'ai donné de JavaScript haut niveau, vous auriez vu que la solution "bytecode java" entrait dans cette définition. De mon point de vue le bytecode java n'est pas bas niveau. Si j'en crois la définition que vous m'en faites, c'est un code facile à parser, sans le paradigme objet mais il continue de faire appel à des fonctions très évolué.
Mes remarques sur l'inutilité des restrictions d'instructions et la sécurité portaient sur le JavaScript bas niveau.

Enfin bon ça m'aura permis d'avoir une initiation au fonctionnement d'une VM java gratuite. C'est toujours bon à prendre.

Du coups plus grand chose à ajouter si ce n'est le problème de verbosité que poserait la compilation du code JavaScript. Problème en partie solvable en utilisant les opcodes correspondant aux instructions.

Il y a un gros mélange de tous les termes alors quelque définition informatiques de base:

- Non je ne faisais pas référence à une API mais a une fonction qui peut éventuellement faire partie d'une API mais pas obligatoirement.
- Il n'y a pas à ma connaissance de classification officielle langage haut niveau et bas niveau. J'ai tendance à penser que l'on est en bas niveau quand on ce préoccupe de problème propre à la machine: "spécificité de l'archi, allocation mémoire, typage des données". Le haut niveau consiste à se concentrer sur le ce que fait concrètement le programme: "calculer un prix, afficher une image".

Surtout faux. Quand le java est utilisé pour les applet, les API auquelle il a accès sont justement limitées
On ne peut pas charger des DLL en Java sans que l'utilisateur ait a confirmer une fenêtre d'avertissement grave de sécurité.

Je m'attendais à ce type de réponse et comme je l'ai dit ce n'est pas le sujet.
En effet, c'est surtout une question de limitation de modalité d’accès. Pour le haut niveau il suffit de limiter au niveau des fonctions proposé par l'API. Pour le bas niveau c'est plus compliqué et c'est pour cela que les solution en cours trainent.
On est (enfin surtout vous) surtout passer d'une discussion sur Dart et l'évolution du JavaScript à une discussion sur java avec lequel je ne travaille pas.
Je ne vais pas m'autoquoter. Je suis resté général et je ne modifie rien de ce que j'ai avancé hormis le fait que le bytecode est fait pour faciliter la compilation (ce qui reste factuellement vrai).
Merci pour mes notions d'informatiques, elles vont bien...

Pour le reste je suis d'accord avec tout ce que tu viens de dire.

[TropMDR]

Juste pour aider à la clarification, lorsque tu parles de "javascript bas niveau", tout le monde comprend "byte code", et personne ne comprend "langage machine" ou "assembleur". Parce que quand on veut parler de langage machine, bah on dit langage machine, puisque ça n'a rien à voir avec le javascript, ou un quelconque "langage pour le web", et qu'en plus il n'y en a qu'un seul par architecture ! Alors que des bytes codes, justement, on peut en avoir plein. (Effectivement, NaCl permet de faire tourner du code natif dans un navigateur, mais c'est encore autre chose)

Bon pour le reste, ça demeure assez confus (en particulier la partie sur la compilation de javascript et des opcodes correspondants aux instructions) :-\

Pour revenir à Dart, vu les réactions, la probabilité qu'il se retrouve en natif dans les différents navigateurs ainsi que dans les différents téléphone portables me semble infime. Mais cela ne veut pas dire qu'il est bon à enterrer: il peut toujours être compilé vers javascript, et les évolutions de ecmascript rendent de telles compilations à chaque fois un peu plus simple, en faisant progresser l'aspect "assembleur du web" de javascript. Et il peut aussi servir de source d'idées pour l'évolution de javascript (même si CoffeeScript existait déjà pour ça).

[psykokarl]

Bon pour le reste, ça demeure assez confus (en particulier la partie sur la compilation de javascript et des opcodes correspondants aux instructions) :-\
.

Je veux dire qu'un programme sous forme "bytecode java" prend plus de place que le source de base. Ça fait donc un gros gros volume à envoyer sur le réseau.
Un opcode est un identifiant numérique correspondant à une opération élémentaire.

[TropMDR]

Je veux dire qu'un programme sous forme "bytecode java" prend plus de place que le source de base. Ça fait donc un gros gros volume à envoyer sur le réseau.

Euh, source de cette information ? Parce que ça me parait assez peu évident sur les tests que j'ai hein...

Un opcode est un identifiant numérique correspondant à une opération élémentaire.

Oui, je sais ce qu'est un opcode. Mais vu qu'un bytecode est évidement transmis sous forme binaire et non textuelle, je ne vois toujours pas le rapport avec le schmilblick.

Bref, passons

[psykokarl]

J'en suis réduit à faire de l'autoquote...

Juste pour aider à la clarification, lorsque tu parles de "javascript bas niveau", tout le monde comprend "byte code", et personne ne comprend "langage machine" ou "assembleur".

Quand je parle de JavaScript bas niveau je parle de JavaScript sans les méthodes de classes qui cachent la complexité.

En fait, je crois que vous pensez bytecode JVM quand je pense assembleur/code machine. Il y a donc méprise sur ce que l'on appelle code bas niveau.

L'assembleur et le code machine sont des code bas niveau. Le bytecode java ne l'est pas. C'est pour ça qu'il est "sur". Ce qui est dangereux est géré par les API ou la VM.

Oui, je sais ce qu'est un opcode. Mais vu qu'un bytecode est évidement transmis sous forme binaire et non textuelle, je ne vois toujours pas le rapport avec le schmilblick.

On parle de langage Dart ou Javascript. Il s'agit bien évidement de texte. ..

Euh, source de cette information ? Parce que ça me parait assez peu évident sur les tests que j'ai hein...

A mon avis tu dépenses trop d'énergie à tenter de prouver que t'as raison.
Tu commences par mener la discussion sur le terrain de java qui t'es plus familier. La tu me parles d'applet la ou on parle de script. Tu fais mines de ne pas comprendre et tu déformes mes propos.
T'essaies de triompher parce dans un binaire on peut coder un entier avec un grand nombre de décimal sur quelques octet ?

Enfin bref, comme tu dis passons...

[Uther]

L'assembleur et le code machine sont des code bas niveau. Le bytecode java ne l'est pas. C'est pour ça qu'il est "sur". Ce qui est dangereux est géré par les API ou la VM.

C'est là ou on n'est pas d'accord. On n'est plus a l'époque de DOS ou les programmes natifs peuvent accéder à tout et n'importe quoi. Les programme natifs sont limités à leur espace mémoire et ils doivent passer par les API système pour accéder aux ressources.

On parle de langage Dart ou Javascript. Il s'agit bien évidement de texte...

On était en train de parler de la possibilité d'utiliser un bytecode commun à la place de Dart, et qui dit bytecode dit binaire. Il y a certes des représentations textuelles mais elle ne sont généralement utilisées qu'a des fins didactiques.

[psykokarl]

C'est là ou on n'est pas d'accord. On n'est plus a l'époque de DOS ou les programmes natifs peuvent accéder à tout et n'importe quoi. Les programme natifs sont limités à leur espace mémoire et ils doivent passer par les API système pour accéder aux ressources.

Les programmes natifs accèdent aux fonctions des API à l'aide de pointeurs. Ces pointeurs peuvent designer l'emplacement mémoire d'une fonction d'une API ou de n'importe quoi d'autre. C'est toujours vrai et ça le sera toujours. Tout le monde ne marche pas dans les clous, passer par les API n'est pas obligatoire.
Si le bytecode ne permet pas de faire cela. Je ne peux pas le considérer comme un langage bas niveau.

On était en train de parler de la possibilité d'utiliser un bytecode commun à la place de Dart, et qui dit bytecode dit binaire. Il y a certes des représentations textuelles mais elle ne sont généralement utilisées qu'a des fins didactiques.

Soit. Pour ma part je parlais de script pas d'applet. Parler de la VM java n'avait pour moi d'autre intérêt que savoir si on pouvait s’inspirer de cette techno pour contrôler le comportement d'un JavaScript bas niveau. Il semblerait que non. D'autres techno le peuvent...
Pour le reste je ne suis pas fan des applets pour diverses raisons.

[Uther]

Les programmes natifs accèdent aux fonctions des API à l'aide de pointeurs. Ces pointeurs peuvent designer l'emplacement mémoire d'une fonction d'une API ou de n'importe quoi d'autre. C'est toujours vrai et ça le sera toujours.
Tout le monde ne marche pas dans les clous, passer par les API n'est pas obligatoire.

Certes mais si c'est un emplacement mémoire auquel l'OS ne leur a pas permis d'accéder, l'accès sera refusé(et le programme probablement planté). Seuls les "drivers" peuvent se permettre d'accéder directement aux ressources.

Si le bytecode ne permet pas de faire cela. Je ne peux pas le considérer comme un langage bas niveau.

Je n'ai jamais prétendu que le bytecode était de bas niveau. Bien au contraire, son but est généralement de s'abstraire autant que possible de l'architecture sous-jacente.

Le problème c'est que l'on parle en parallèle de deux alternatives possibles à Dart qui n'ont rien a voir si ce n'est qu'elle ne posent pas selon moi de problèmes de sécurité particulier si elles ne sont pas gérées idiotement :
- l’exécution d'un langage bas niveau (ce que NaCl fait déjà très bien)
- l'utilisation d'un bytecode commun (un peu à la java mais mieux intégré)

[psykokarl]

Certes mais si c'est un emplacement mémoire auquel l'OS ne leur a pas permis d'accéder, l'accès sera refusé(et le programme probablement planté). Seuls les "drivers" peuvent se permettre d'accéder directement aux ressources.

Ah je n'ai pas dit que c'était simple . Pour la petite histoire j'essaie de faire fonctionner un drivers NDIS. J'en chie...

Le problème c'est que l'on parle en parallèle de deux alternatives possibles à Dart qui n'ont rien a voir si ce n'est qu'elle ne posent pas selon moi de problèmes de sécurité particulier si elles ne sont pas gérées idiotement :
- l’exécution d'un langage bas niveau (ce que NaCl fait déjà très bien)
- l'utilisation d'un bytecode commun (un peu à la java mais mieux intégré)

En y repensant chacune d'elle fait plus solution pour déploiement d'application lourde que script pour dynamiser une page. Au final les possibilités d'évolution à ce niveau sont très limité si on ne veut pas réinventer le web dans la foulé.
Plus que le nouveau langage, la popularité Dart va dépendre de son API qui devra être pensé pour booster la créativité. Donc une archi très permissive mais pas trop..

[ernestrenan]

Quelques propos trolliminaires :
J'aime bien le javascript, je trouve qu'il fait bien son boulot et que la notation json rend le code très clair.
J'aime pas les langages typés.
J'aime pas les ;
Je pense qu'on peut pas faire mieux que le c et que a peu près tout est mieux que le c (et réciproquement).

Bon maintenant c'est cool qu'un nouveau langage sorte mais je pense que google comme bien souvent se plante dans sa stratégie : ils sortent un langage non pas en réponse à un besoin mais dans le but d'en créer un. Et d'ailleurs on le voit bien aux exemples de code sur le site aucune spécificité, une espèce de mélange de tous les grands langages connus.

La j'ai vraiment l'impression que les ingénieurs débarquent en disant "hey regardez les mecs on a réussi à créer notre propre langage de programmation, maintenant on va tous l'utiliser". Donc sans plus d'informations sur l'apport de dart par rapport à un combo (qui a fait ses preuves) : script serveur + js c'est non pour moi.

[psykokarl]

La j'ai vraiment l'impression que les ingénieurs débarquent en disant "hey regardez les mecs on a réussi à créer notre propre langage de programmation, maintenant on va tous l'utiliser". Donc sans plus d'informations sur l'apport de dart par rapport à un combo (qui a fait ses preuves) : script serveur + js c'est non pour moi.

Il y a une stratégie marketing évidente derrière. Google cherche ni plus ni moins que le quasi monopole technologique dans le domaine de l'informatique.
Seulement ils ont d'avantage une approche de "techos" qu'une approche de commercial. Au lieu de nous inonder de pub qui vantent les qualités d'un produit médiocre, il compte sur le fait que nous nous dirigeront spontanément vers le meilleurs produit.

Le fait qu'ils aient leur propre langage leur assure la main mise technologique dessus. Ils pourront le faire évoluer bien plus vite qu'un langage gérée par une communauté hétérogène aux besoins différents.

Ils ont une approche qui me plait mais dont je me méfie. J'aime mon indépendance...