[F] [mOved] Mon langage est mieux que le tien - Page 15

Et il était devenu d'une lourdeur impressionnante. Il a fait partie des modules qui ont pourri l'expérience de navigation web sur des vieilles machines.

Ah parce que tu crois que le javascript de nos jours c'est mieux ?

J'ai revendu mon McBook Air (Core 2 Duo 1.83 GHz) il y a déjà une année parce que surfer sur le web, sur à peu près tout sauf yAronet, consommait trop de batterie et cassait complètement l'intérêt d'un tél laptop (passé de 7~8h à 4h d'autonomie en 2.5 ans, et le problème de ne venait pas de la batterie…).

Au moins le Flash ça se désactivait et tu pouvais surfer tranquille, là avec le javascript tu ne peux rien faire à part AdBlock Plus -- et même. Surfer sur le web (lire du texte je le rappelle) est une des choses les plus exigeantes qu'on demande à une machine de nos jours. Si ce n'est pas un problème…

Pas de soucis là-dessus Brunni, on est complètement d'accord ! Je met le Javascript dans le même panier.

Flash -> ActionScript -> ECMAScript quand même.
J'aimerai une solution plus fraîche, en particulier adaptée avec l'air du temps, et non des briques posées sur des briques posées sur des briques où la notion de standard n'existe plus.

Si c'était si simple, ça aurait déjà été fait…
Faut bien comprendre les enjeux du truc: Derrière chaque fonctionnalité moisie de JavaScript, il y a une bonne fonctionnalité qui se cache, et tu peux souvent pas garder l'un sans garder l'autre.
Et à cause de ça, trouver/concevoir un langage qui remplacerait efficacement JavaScript, c'est sacrément difficile.

Zeph (./419) :
./414 : je ne vois vraiment pas l'intérêt d'abandonner le seul langage de script implémenté dans tous les browsers principaux, d'autant plus qu'il est suffisamment simple pour pouvoir servir de langage cible à tous les gens qui veulent un remplacement pour des raisons de syntaxe ou de performance, etc (CoffeeScript, TypeScript, asm.js, etc...)

On est d'accord, la seule raison de faire du JS est que c'est le seul langage qui soit dispo

Je me demande ce que donnent les différents langages qui compilent vers du JS quand on est confronté aux problèmes de typage (genre my_array[1] != my_array["1"]).

flanker (./426) :
On est d'accord, la seule raison de faire du JS est que c'est le seul langage qui soit dispo

<script language=text/vbscript></script>

./426 : en l'occurrence my_array[1] === my_array["1"] pour n'importe quel my_array (ou my_object) ^^

Mais les différents langages en question s'en sortent très bien, le comportement de JS n'ayant rien d'aléatoire ou de vaudou ils savent très bien convertir n'importe quel code typé pour avoir le résultat attendu.

Zeph (./428) :
./426 : en l'occurrence my_array[1] === my_array["1"] pour n'importe quel my_array (ou my_object) ^^

C'est ça qui me gêne, justement : deux clefs différentes sont en fait la même. Le JS est intrinsèquement faiblement typée, et on finit toujours par y être confronté indirectement même quand on essaie d'utiliser uniquement === à la place de ==.

Ben non, en l'occurrence c'est simplement que Object est une structure qui n'accepte que des strings comme clé, c'est sa définition. N'importe quelle surcouche typée se basera là-dessus et n'utilisera Object que dans ce cas (ce qui n'empêche par ailleurs pas qu'utiliser n'importe quoi d'autre, comme par exemple des nombres, soit quand même défini par le standard).

GoldenCrystal (./425) :
Derrière chaque fonctionnalité moisie de JavaScript, il y a une bonne fonctionnalité qui se cache, et tu peux souvent pas garder l'un sans garder l'autre.

Je ne dis pas que tout JS est à jeter. On peut démarrer un nouveau langage sur des bases déjà éprouvées et efficaces.

<mode=Flanker>Avez-vous essayé le PythonScript ?</mode>

Je propose de HaskellScript ou le RubyScript

Voir le VHDLScript ou le VerilogScript

Meowcate (./431) :
Je ne dis pas que tout JS est à jeter. On peut démarrer un nouveau langage sur des bases déjà éprouvées et efficaces.

En théorie oui, en pratique on ne mettra jamais tout les acteurs principaux d'accord. Chacun avance sa/ses solutions personnelles avec leur avantage/inconvénients :
- asm.js pour Mozilla
- Dart et (p)NaCl pour Google
- TypeScript pour Microsoft
- "Le web c'est has been les apps c'est mieux" pour Apple.

Brunni (./422) :
J'ai revendu mon McBook Air (Core 2 Duo 1.83 GHz) il y a déjà une année parce que surfer sur le web, sur à peu près tout sauf yAronet, consommait trop de batterie et cassait complètement l'intérêt d'un tél laptop (passé de 7~8h à 4h d'autonomie en 2.5 ans, et le problème de ne venait pas de la batterie…).
Au moins le Flash ça se désactivait et tu pouvais surfer tranquille, là avec le javascript tu ne peux rien faire à part AdBlock Plus -- et même. Surfer sur le web (lire du texte je le rappelle) est une des choses les plus exigeantes qu'on demande à une machine de nos jours. Si ce n'est pas un problème…

Mon bon vieux laptop Core 2 Duo 1GHz fonctionne encore bien ... mais si je désactive flashblock+adblock+ghostery, qu'est ce que ça rame

(./434 > ) Mettre tout le monde d'accord, c'est même pas ça le vrai problème, à mon sens…
Mais à commencer par les exemples que tu donnes :
• asm.js c'est un gros hack vraiment pas très beau, qui n'aurait jamais du voir le jour. Il y a peu de chances que ça devienne populaire un jour vu la tronche du code que le navigateur doit exécuter.
• NaCl est hors compétition à mon sens, ne visant clairement pas à remplacer le Web "classique". Google est plus là pour pousser Dart à priori
• Dart est un projet intéressant au premier abord, je n'ai pas creusé outre mesure donc j'aurais du mal à critiquer. Du peu que j'en ait vu, le langage semble avoir peu de défauts, mais au niveau de l'environnement, cela semble devenir déjà bien trop compliqué… (Ex: Contrainte d'avoir une fonction main… Est-ce vraiment utile/indispensable en développement web ?)
• TypeScript c'est JavaScript++… Si c'est pas assez clair, je le reformule autrement: c'est du JavaScript avec plus de fonctionnalités (notamment certaines de ES6), et du typage "statique", mais ça reste du JavaScript. En dehors de ça, ça me semble être un des plus prometteurs, c'est celui qui s'éloigne le moins de la réalité. (PS: à l'heure actuelle, la réalité, c'est JavaScript)
• La soi disant approche de Apple… "lol". Sérieusement, c'est hors contexte. Oui, Apple préfèrera que tu développes une app native (et je pense qu'ils ont raison), mais c'est pas dans le contexte du web, juste le contexte de iOS (De fait, la position de Apple c'est plutôt que JavaScript, ça leur va pour le moment…)
J'en ajoute un dans la liste, pas soutenu par un "gros" du milieu, comme ça en plus je pense qu'on aura fait le tour:
• CoffeeScript. À chaque fois que je regarde ce langage, j'ai l'impression que c'est une vaste plaisanterie. La syntaxe est abominable et on dirait l'enfant batard de Visual Basic et JavaScript. Oui je commence direct sur le méchant, mais le fond de ma pensée, c'est que c'est pas la peine de s'emmerder à remplacer JavaScript si c'est pour mettre ça à la place. (Celui-là, avec une syntaxe meilleure, ça aurait peut-être pu être un bon truc)

---

(./431 > )
Après, ce que j'aimerais réussir à faire comprendre, c'est qu'il faut regarder le grand schéma ("the big picture") et arrêter de se focaliser sur les détails de "ça c'est bien", "ça c'est pas bien". Je remarque ça quotidiennement, mais peu se posent réellement la question de savoir "ce qui va se passer ailleurs si on change à un truc ici".
En fait, aujourd'hui, les technologies employées s’emboîtent très bien les unes avec les autres, mais l'équilibre est en réalité très fragile…

Par exemple, la nature informe du JavaScript fait qu'il est facile de caser un petit bout de script au milieu d'une page pour ajouter une fonctionnalité. Et oui, document.write(), c'est le mal, et on fait bien mieux aujourd'hui, mais c'est pas pour autant qu'insérer du JavaScript n'importe où dans une page perd son utilité.
=> Que se passe-t-il si on met à la place un langage qui nécessite une vraie structure, comme Dart ? On interdit certainement rien, mais on perd beaucoup en flexibilité: L'intérêt principal de pouvoir caser des petits bouts de script partout, aujourd'hui, est que le navigateur est obligé d'exécuter des scripts dans l'ordre, et si on fait ça correctement, ça permet d'afficher la page avant qu'elle soit entièrement chargée.
Typiquement, on gagnerait sans doute bien plus à autoriser une vraie gestion de dépendances entre scripts, implémentée dans le navigateur, ce qui permettrait un bon chargement asynchrone. (En pratique, le chargement asynchrone qui existe actuellement, est rarement utilisable)

Par exemple, le fait que JavaScript fonctionne par prototype, permet de modifier facilement la structure de ses objets, et d'étendre n'importe quel "type" d'objet, y compris ceux du navigateur. L'extension des objets du navigateur est un sujet discutable, mais grâce à cela, on peut implémenter des "polyfill", et autres patches pour navigateurs incompatibles.
=> Quelle serait la façon équivalente de faire avec un langage typé par classes d'objet ?
Le C# a une solution pour "rajouter" des méthodes à un type d'objet: les méthodes d'extension. C'est assez proprement exécuté, et personnellement j'adore cette fonctionnalité. Maintenant, ça marche très bien en C#, mais mis dans le contexte du Web, c'est une démarche vraiment lourde.
Un langage objet tel que C++/C#/Java va proposer des classes fortement typées. Un mécanisme pour étendre une classe pré-existante serait de procéder par héritage, et de fournir par un moyen x ou y une fonction de construction au code qui aurait besoin d'instancier ses objets. (Genre avec un conteneur IoC… Ça devient sacrément lourd là !) Et quid des objets qui auraient déjà été créés avant ? Ils vont garder le même type, c'est pas cool.

Dernier exemple, pour la route. JavaScript est un langage à typage dynamique, du coup on sait jamais sur quoi on travaille.
=> Oui, c'est vrai, mais comme JavaScript est un langage à prototypes, il est difficile (et on peut approximer cela à "impossible") de pouvoir garantir une quelconque notion de type: En dehors des types primitifs, les "types" n'existent pas. Du coup pour avoir un vrai typage, il faudrait se séparer de certaines notions de prototypage d'objets. Mais si on se retrouve avec un langage objet à typage statique, on tombe dans la lourdeur du code. (Toujours passer par des classes) Et de surcroît, ça se minifiera vraiment beaucoup moins bien que du JS…

Y'a honnêtement qu'un seul truc que je pense qu'on aurait pu se débarasser (genre dans une version "pure" de JavaScript) de façon honnête, c'est les conversions automatiques sur l'opérateur == qui le rendent non transitif (ben voyons).
Mais en toute honnêteté, il faudrait aussi revoir les conversions automatiques sur les autres opérateurs… Du coup que considérerait-on comme vrai ou faux dans le langage, sachant qu'on ne peut garantir le typage ? Là je pense que ça coincerait

---

Au final, je pense que si on voulait un vrai truc sérieux, il faudrait revoir la copie globale et faire fi du trio HTML+CSS+JS en intégralité dès lors que l'on parlerait d'applications. Et là, même si j'ai quelques idées sur le sujet, tel que je le vois, ça devient franchement compliqué.

(Après bien sûr, on peut rajouter à tout ça le problème des intérêts divergents des différents navigateurs Web… Mais il faudrait d'abord traverser tous les obstacles techniques et conceptuels… )

http://www.nomorejavascript.com/
Avoue GC, c'est toi

(en lien avec Flanker, tu remarqueras qu'ils ne tapent pas sur Python, cqfd )

Ben nan j'aurais jamais fait un site pareil moi… J'ai clairement affiché ma position je pense: Même si JavaScript "c'est nul", on peut pas le remplacer (NB: C'est pas aussi tranché que ça mais comme on dirait que par moment vous lisez tous mes posts à l'envers, je fais dans le simple )
Et surtout je supporte pas la syntaxe à base de "def" machin truc, et leurs exemples me font peur.*
D'ailleurs le but de mon post au dessus c'est clairement d'expliquer qu'un nouveau langage, c'est clairement pas la solution… (Je pense sérieusement que c'est une des pires choses qu'on puisse faire à ce niveau)


* cf cette partie:

What if it was like this?
button_clicked '#button'(:hide => "#paragraph")

C'est juste horrible. Ou alors c'est moi qui comprends pas ?

(c'est horrible)

Oui, tout à fait.

Ils feraient mieux de faire un langage comme le C++, mais avec une syntaxe potable et intuitive.

(Mais le javascript existe déjà… #troll#)
(Sinon il y a le C# #pastroll#)

saloupiau
(ah, cross-edit ^^)

GoldenCrystal (./439) :
Même si JavaScript "c'est nul", on peut pas le remplacer (NB: C'est pas aussi tranché que ça mais comme on dirait que par moment vous lisez tous mes posts à l'envers, je fais dans le simple )

C'est sûr, on n'a pas le choix

./443 > Sans déconner en fait, le JavaScript est suffisemment flexible (je dirais "mou") pour que tu puisses y implémenter pas mal d'équivalent de trucs qui se font en C++, en dehors de la rigueur, quoi
Par exemple, pour un équivalent assez proche des template, tu pourrais utiliser eval() () ou de manière moins gore, des closure (mais du coup c'est plus autant équivalent).
Pour l'héritage, le JavaScript fait de l'héritage par prototype, mais ça ne t’empêche pas de mettre un place un semblant de système de classes. (C'est assez courant en fait)
Pour la surcharge de méthodes, tu peux l'implémenter toi même au sein de ton code en vérifiant les paramètres qui t'ont été passés… (J'ai pas dit que c'était facile !)
Pour les champs privés dans les objets, il suffit de déclarer des variables dans le constructeur et de déclarer les getter sur l'objet plutôt que le prototype, mais c'est vrai que ça reste moins flexible que C++… (Surtout carrément plus gourmand en mémoire/perfs)
Tu peux déclarer sur les objets des propriétés avec getter/setter, donc dans les fait, implémenter des propriétés en lecture seule…
Les fonctions sont des objets, donc tu peux faire le même genre de choses qu'avec des pointeurs de fonction.
Les structures de contrôle sont les mêmes que C++, excepté qu'il manque le goto

etc.

Oh oui, c'est ça qui est bien avec JS, c'est que la roue a été réinventée des dizaines de fois. Bon, elle n'est jamais totalement ronde, mais c'est un détail.

Un peu comme s'il manquait une vraie bibliothèque standard, quoi

Ouais mais c'est un langage de script, car il fallait un langage de script, et ça impose des contraintes !
Pour le coup le coup d'absence d'une vrai bibliothèque standard, je crois que c'était voulu, mais pour un langage de script c'est pas si déconnant ^^

GoldenCrystal (./442) :
(Sinon il y a le C# #pastroll#)

Tiens, je viens de lire la page WP de C#, ça a l'air pas mal ^^

Par contre, quand je lis des phrases comme le support de la covariance et de la contravariance pour les interfaces et les délégués génériques. à laquelle je ne comprends pas un mot, je me dis que c'est encore un langage pas fait pour moi

En fait, c'est juste un truc pour dire que si ton Tabouret est un Siège, alors une Liste de Tabourets est aussi une Liste de Sièges (Covariance), ou si tu demandes une Liste de Siège, on peut aussi te donner une Liste de Tabourets (Contravariance). Les termes sont effrayants au premier abord, mais c'est plutôt intuitif et tu as rarement besoin de te poser la question. (J'avoue que moi même je me rappelle jamais lequel des termes fonctionne dans quel sens )

La page sur le "nojavascript" est quand meme bourre d'erreur et d'imprecision..

Le fait qu'il y ai des {} et ; rends le language plus simple a parser, moins verbeux (les begin/end sont du domaine du pascal ou de l'ada, qui veux programmer dans ces languages??)

Ne pas utiliser de return pour dire ce qu'on veux renvoyer est une heresie sans nom.. (et quid du passage de parametres dans leur truc? A moins que tout soit global en fait..

dans leur pseudo exemple

def ma_fonction
 a * b
end

hum et si je fait

def ma_fonction
 a * b
 a + c
end

qu'est-ce qui est retourne?

La syntaxe pour jquery est lourde, mais je persiste a penser que c'est de la faute a jquery, que les choses aurais pu etre faites plus simplement, et que ce n'est pas un probleme du JavaScript lui meme.

Ensuite sur "We were heading in the right direction with Ruby on Rails."

Il ne se trompe pas un peu de techno? Ruby n'a jamais ete execute cote client, tant mieux, mais il n'ont jamais ete confronte a l'installation de RoR ca se vois... On a jamais ete dans la bonne direction avec ce bousin..
Quand a node,js.. C'est je pense la pire choses que des scripteux en javascript ai pu inventer, mais c'est une autre histoire.

J'oubliait

We basically have been reliant on very few to come up with libraries and platforms like node.js, instead of building them ourselves.

En gros ils aiment reinventer la roue quoi vu qu'ils ne veulent pas "dependre" d'autre pour leur fournir un framework (aussi bon ou mauvais soit-il ce n'est pas la question)