JavaScript : la risée des langages de programmation ?

Citation:

---

Envoyé par Orwel

Quelque explication, s'il vous plaît. Pour moi, le C est un langage fortement typé (1 variable / 1 type) avec la possibilité d'interprété les données avec un typage dynamique (1 donnée / plein de variable avec des types différents).

La variable indique l'interprétation de la donnée, mais avec la magie du C on peut attribuer moult variable sur une même donnée.

Le typage faible c'est une variable qui peut bouffer n'importe quoi et faire n'importe quoi sans se plaindre. Ce qui est parfait pour des scripts.

Les WAT sont une forme de critique du langage, mais tournée avec humour. Si on accepte la critique, elle peut aider à progresser; mais il ne fait jamais la dénigrer purement comme cela est présenté dans l'article.

---

« 1 variable / 1 type », ça n'est pas du typage fort, c'est du typage statique. La « force » d'un typage consiste à définir si les conversions types sont implicites ou pas.

C pour moi, est un langage statique à typage faible, parce qu'il autorise les conversion implicites (sans cast) de void* vers n'importe quel type de pointeur, et les entiers vers les enums. Ça n'est pas un défaut, mais un choix de conception.

Python est un langage à typage fort, parce que

Code:

---

"1" + 2

---

lancera une exception parce que le langage se refuse à trancher si le résultat doit être 3 ou "12". Le programmeur devra explicitement convertir vers l'un ou l'autre des types avant d'appeler l'opérateur +. Python a, en outre, un typage dynamique, parce qu'une variable peut se voir affecter des valeurs de types différents pendant sa durée de vie.

Je te rejoins sur l'interêt du typage dynamique pour les langages de scripts. Là où j'ai du mal, c'est quand on a à la fois du typage dynamique avec du typage faible (Javascript et ses conversions silencieuses).

Citation:

---

Envoyé par Orwel

Quelque explication, s'il vous plaît. Pour moi, le C est un langage fortement typé (1 variable / 1 type) avec la possibilité d'interprété les données avec un typage dynamique (1 donnée / plein de variable avec des types différents).

---

Non, non et non.
Le typage est statique.
Le type est défini et vérifié à la compilation.

Si ensuite le langage fourni des opérateurs de coercition et défini des règles de conversions implicite ça ne change rien au fait que le type est statique. Tu n’auras pas une erreur à l’exécution si tu veux multiplier un entier par une structure, ça va claquer lors de la compilation. En cela, le typage est statique.

Pour l’histoire du typage fort/faible, comme je l’ai dit dans mon précédent message c’est sujet à interprétation. Pas de définition très claire, pas de séparation binaire.
Mais pour le côté faiblement typé je peux citer :
- tu peux mélanger les entiers et les flottants dans une expression arithmétique (impossible en Haskell, qui est très fortement typé, sans conversion explicite).
- ce genre de code est valide (les compilo‘ gentil émettent un avertissement, mais ça reste du C valide) :

Code:

---

1 2 3 4 5 6

int main(void) { double d = 0.0; int* p = &d; return 0; }

---

Mais d‘un point de vue global, je suis d’accord que l‘on considère généralement que le C est fortement typé.
Après, comme fort/faible sont des notions relative tout dépend avec qui tu compares. C a un typage faible comparé à Haskell, mais fort comparé à Javascript.

Je me suis toujours trouvé plus à l'aise à faire du JavaScript ou du python qu'a travailler avec un langage fortement typé comme java. Pour faire un parallèle (à la con) j'ai l'impression de faire une peinture au numéro avec Java, quand avec du JavaScript t'a une feuille blanche avec une grande liberté : Avec la peinture au numéro tu risque pas de faire une grosse merde mais c'est limité, avec la feuille blanche tu peux faire une grosse merde mais t'as plus de liberté.

Pour revenir au sujet, je pense qu'on peux se moquer de tout les langages et que ça ne sert à rien du tout... Chaque langage à ces particularités, ces qualités et ces défauts, la pluralité est toujours une bonne chose.

Citation:

---

Envoyé par Golgotha

Je me suis toujours trouvé plus à l'aise à faire du JavaScript ou du python qu'a travailler avec un langage fortement typé comme java.

---

Python est fortement typé, pas de différence avec Java à ce niveau là.
La différence est que Python (et Javascript) a un typage dynamique et que Java a un typage statique.
Elle est là la différence qui te rends plus à l’aise avec l’un qu‘avec l‘autre.
Par sur la différence typage faible/fort, sinon tu aurais aussi l‘impression de faire de la peinture au numéro avec Python, ce qui ne semble pas être le cas.

J’ai l’impression que beaucoup de gens mélange les notions de typage statique/dynamique avec les notions de typage faible/fort…

Citation:

---

Envoyé par grim7reaper

Python est fortement typé, pas de différence avec Java à ce niveau là.
La différence est que Python (et Javascript) a un typage dynamique et que Java a un typage statique.
Elle est là la différence qui te rends plus à l’aise avec l’un qu‘avec l‘autre.
Par sur la différence typage faible/fort, sinon tu aurais aussi l‘impression de faire de la peinture au numéro avec Python, ce qui ne semble pas être le cas.

J’ai l’impression que beaucoup de gens mélange les notions de typage statique/dynamique avec les notions de typage faible/fort…

---

Mélange ou n'ont pas le courage de faire un cours sur le typage ^^

Globalement c'est le coté langage de script qui me plait. Java (ou un autre langage comme java) avec un typage static et une compilation (de toute façon ça va ensemble...) ça rends le développement chiant, mais plus cadré ça je suis d'accord.

Citation:

---

Envoyé par Golgotha

Java (ou un autre langage comme java) avec un typage static et une compilation (de toute façon ça va ensemble...) ça rends le développement chiant

---

Tout à fait d‘accord.
C’est vrai que quand je développe en Java, ça me manque d‘avoir un interpréteur interactif genre bpython (pour Python) ou pry (pour Ruby) pour tester rapidement des petits bouts de code (la flemme de créer une classe & cie juste pour tester une méthode ou 3 lignes de code).
Heureusement, avec Jython et Jruby, bah je peux récupérer cette avantage de l‘interpréteur interactif pour tester rapidement des petits bouts de Java. Très pratique :)

Citation:

---

Envoyé par camus3

javascript a des classes , pas au sens java mais ce sont des classes quand même , smalltalk ( dont java s'inspire ) n'a pas non plus de classes à la java.

une "classe" en Javascript c'est une fonction qui a un prototype auquel on assigne des membres.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

var MaClasse = function(){ // constructeur this.prop = "ma propriété" }   MaClasse.prototype.doSomething = function(){ // un membre }   // héritage   var MaSousClass = function(){ MaClass.apply(this); // "super" }   MaSousClass.prototype = new MaClass;

---

---

J'adore ce post. Il résume à lui tout seul le sujet. Le particularisme de la notion objet de Javascript est-il risible ?

Citation:

---

Envoyé par Schouss

J'adore ce post. Il résume à lui tout seul le sujet. Le particularisme de la notion objet de Javascript est-il risible ?

---

En l'occurence, il s'agit de classe et non d'objet. De plus comme dit précédemment, on ne peut pas parler de classe en javascript mais plutôt de prototype !

La notion d'objet comme répondant à un prototype ne me semble pas risible juste différente de la notion d'objet comme instance d'une classe. D'ailleurs un typeof sur un objet prototypé "MaClasse" ou "MaSousClasse" (comme défini ci-dessus) répondra "object" !

Parler de typage fort/faible ou de notion de classe est un faux débat, car ce n'est pas ce qui pose problème en javascript.

Par exemple, en LUA pas de classes non plus, la notion de prototypage existe sous la forme de metatables, et là aussi ça peut dérouter quand on a appris l'OO via Java/C++.

Mais c'est un faux problème, comme si un dev Java hurlais à l'héresie car Ruby n'implémente pas de notion d'interface (ou inversement un dev Ruby qui râle car y'a pas de notion de module en java ou que tout n'est pas objet...).

C'est une spécificité du langage, et pour le coup la notion de prototype est très puissante et très lisible une fois qu'on a fait l'effort de comprendre comment ça fonctionne.

Pour la notion de type faible ou fort, voir du coté d'actionscript, l'ECMA d'adobe qui permet de faire du typage fort.
Si le problème de javascript c'était son typage, alors tout le monde ferait de l'actionscript, non? :P
Pour avoir fait de l'actionscript et du javascript, je peux dire que le problème de javascript n'est pas son typage faible, mais véritablement:

- Des API destructurées (developpé par "acoup"), imbitables (pourquoi tout le monde utilise jQuery?); et notamment cette fameuse classe "Date" qui résume à elle seule tout ce qu'il ne faut pas faire!
- Un nom et une écriture proche de C/Java qui ne facilite pas l'impression dans la tete des gens que javascript != java
- Des notions fonctionnelles arrivée après coup. Je veux dire, les structures tels que for et while n'ont rien à faire en javascript!

Code:

---

1 2 3 4

//Exemple de for(var i = 0; i < x; i++) { } // en pur fonctionnel si la notion de range avait été intégré au langage: (0..x).by(1).each(function(i) {})

---

Du coup, le coté fonctionnel étant arrivé plus tard, on se retrouve avec des trucs aberrants en terme de syntaxe pour un langage fonctionnel; le plus remarquable étant le mot clé "function", bien trop long dés qu'on fait du pur fonctionnel (notamment inliné).

Personnelement, je préfére travailler d'ailleurs sous coffeescript. On gagne beaucoup en souplesse de syntaxe (mais les API reste les mêmes...)

Javascript n'est pas un mauvais langage en soit, il est comme tout le web en fait: un gros oignon avec des couches un peu incohérentes sur les bords...

Et puis il y a des trucs cool: tout est objet!:

Code:

---

1 2 3 4 5 6

Number.prototype.times = function(callback) { for(var i = 0; i < this; i++) callback(i); }   5..times(function(i) { console.log("hello developpez! x"+i); });

---

On peut définir des property sur les objets aussi, c'est sympa. Je pense que les prochaines version d'ECMA devrait améliorer largement le langage, comme pour PHP qui était mauvais jusqu'à la version 5.

Mais, comme trollé precedemment, à mes yeux, ça reste un HLM hein :P

Citation:

---

Envoyé par anykeyh

Si le problème de javascript c'était son typage, alors tout le monde ferait de l'actionscript, non? :P

---

Argument invalide.
C‘est rarement la meilleure technologie qui gagne…
Certaines techno’ sont devenues des standards de fait (car à l‘époque il n’y avait rien d‘autres ou pas mieux en face).
Le temps faisant son effet, maintenant il y a une inertie énorme pour changer les choses.

Donc non, l’argument « si c’est utilisé c‘est que c’est bien » n‘est pas valide.

Citation:

---

Envoyé par anykeyh

Du coup, le coté fonctionnel étant arrivé plus tard, on se retrouve avec des trucs aberrants en terme de syntaxe pour un langage fonctionnel

---

Ça tombe bien, JS n‘est pas un langage fonctionnel.
Qu’il offre 2-3 fonctionnalités et/ou sucre syntaxique pour adopter un style fonctionnel ne suffisent pas à en faire un langage fonctionnel.
Un langage multi-paradigme permettant d‘écrire dans un style fonctionnel oui, un langage fonctionnel non.

Heu, c'est quoi un "WAT"? :roll:

Il faut avouer que c'est un langage étrange par rapport aux autres langages courremment utilisé, le fait qu'il ne fonctionne pas en objet mais en prototype est à lui seul déroutant(à moins qu'il y en ai qui utilisent Self :?).

Citation:

---

Envoyé par ZJP972

Heu, c'est quoi un "WAT"? :roll:

---

Un WAT est une phénomène étrange d'un langage (pas forcément Javascript) où "wat" (pour "what" = "quoi" en anglais) serait la première expression qui sortirais de ta bouche en l'observant.

Citation:

---

Envoyé par s4mk1ng

Il faut avouer que c'est un langage étrange

---

Il est possible de recréer la majorité des particularités du javascript avec tout autre langage même objet.

Un "objet" javascript est une Map de String vers d'autres objets
Une fonction est un "executable" isolé à qui il peux lui être donné un contexte. J'entends par "executable", quelquechose de similaire au Runnable de Java.
L'opérateur "new" est une copie simple du prototype donné avec l'application de la fonction à l'origine du prototype sur la copie.

implicites, il faut pas s'attendre à quelque chose de logique. Ce type d'opération sont à éviter, il en est de même pour tout langage dans les priorités des opérateurs, si on utilise pas les parenthèses, on laisse le parseur faire l'évaluation lui même des groupes, * et / ayant une priorité plus grande sur - et +...

Par exemple par rapport à ce qui a été dit

"1" + "2" = "12"
car le plus est un opérateur de concaténation pour les chaînes

"1" - "2" = -1
car le moins est un opérateur pour les nombres, l'analyseur convertit "1" en 1 et "2" en 2. Ce qui est assez logique.

Par contre ce qui l'est moins, c'est d'avoir ce type de séquence dans son code, preuve qu'il y a surtout un problème dans la maîtrise du langage.

Bref, on peut faire dire n'importe quoi en zoomant sur des faux problèmes d'écriture qui ne concernent pas vraiment un développement "normal".

:zoubi:

Le problème des langages faiblement typé : souvent tu ne sais pas comment ta variable sera traitée, et tu passes ton temps à faire des conversions pour éviter les ambiguités.

Je n'avais jamais entendu parler de ces "WAT" mais ce que la vidéo me donne à penser c'est que ceux qui en font sont apparemment encore plus débiles que ce qu'ils essaient de mettre en évidence! En tout cas, rien de constructif. Plus ça va et plus je me dit qu'il y a des gens qui s'ennuient vraiment dans la vie.

En voyant la vidéo et en entendant les rires des gens j'ai surtout l'impression qu'ils n'avaient rien compris à ce qu'est la programmation objet ou le typage fort. Alors on va éviter de leur parler en plus de la surcharge des opérateurs...

Bref, pour apporter ma petite pierre à l'édifice, je peux témoigner que dans un langage de preuve formelle (dont je tairai le nom parce qu'il ne mérite pas d'être conspué de la sorte), il m'a été possible il y a une dizaine d'année de prouver que 0=1 et par conséquence de prouver n'importe quoi. Cela dit, je l'ai fait exprès et en exploitant malicieusement un problème connu qui a sans doute été corrigé depuis.

Citation:

---

Envoyé par TNT89

(Cela dit, ils ont aussi de bonnes lacunes en Mathématiques et en précision des formats flottants... cf "negative zero equal but not equal" et "magic increasing number"...)

---

Petit retour là-dessus parce que là encore, on charge JavaScript peut-être à tort...

Déjà, concernant le magic increasing number, ça n'a rien de spécifique à JavaScript, voir : The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic.

Concernant les zéros signés, je ne crois pas (sauf erreur de ma part, je suis prudent désormais) que ce soit non plus spécifique, mais que -0 soit égal à +0 ne me semble pas choquant, en rechanche que 1/0 et 1/-0 ne soient pas égaux, est logique vu que 1/0 vaut Infinity et 1/-0 vaut -Infinity donc à moins de considérer que les nombres forment une structure circulaire, heureusement que deux valeurs diamétralement opposées ne soient pas égales ! :aie:

Citation:

---

Envoyé par grim7reaper

Argument invalide.
C‘est rarement la meilleure technologie qui gagne…
Certaines techno’ sont devenues des standards de fait (car à l‘époque il n’y avait rien d‘autres ou pas mieux en face).
Le temps faisant son effet, maintenant il y a une inertie énorme pour changer les choses.
.....

---

<troll>
La preuve Android
</troll>

Citation:

---

Envoyé par Bovino

Petit retour là-dessus parce que là encore, on charge JavaScript peut-être à tort...

---

Non, c'est pour cela que j'ai ecrit "Cela dit, ils (Les auteurs) ont aussi de bonnes lacunes en Mathématiques et en précision des formats flottants" parce que c'est effectivement commun a tous les langages basés sur le double IEEE-754 pour l'une et un gros problème de mathématiques de ne pas savoir que lim 1/x -> Inf quand x->0+.

Ce genre d'articles à trolls est lassant. On pourrait dire de n'importe langage qu'il est "la risée" à partir du moment où il ne plaît pas à au moins un programmeur qui l'expose ainsi publiquement sur le net. C'est bien simple pour moi : AUCUN langage n'est meilleur que l'autre car cela dépend de si nombreux facteurs, à commencer par la nature d'un projet par exemple.

Citation:

---

Ce genre d'articles à trolls est lassant. On pourrait dire de n'importe langage qu'il est "la risée" à partir du moment où il ne plaît pas à au moins un programmeur qui l'expose ainsi publiquement sur le net. C'est bien simple pour moi : AUCUN langage n'est meilleur que l'autre car cela dépend de si nombreux facteurs, à commencer par la nature d'un projet par exemple.

---

La seule raison pour laquelle les programmeurs codent en javascript est parce qu'ils n'ont pas le choix.

C'est une chose unique dans l'histoire de l'informatique qu'un langage de haut niveau soit "non négociable".

Donc forcément , il est extrêmement critiqué. Et il n'évoluera que très peu pour ne pas casser la compatibilité avec d'anciens scripts.

Ben tout dépend le point de vue, il y en a qui par exemple passent du temps à chercher des défauts à un langage et n'avancent pas (terme suggéré = "masturbation mentale") et puis d'autres qui codent dans ce langage, ont appris à contourner les défauts, à maîtriser certains aspects, et réussissent à produire des projets qui rapportent de l'argent.

Prenons par exemple un site Web à forte affluence qui a misé à fond sur AJAX (et par conséquent sur du Javascript). Pensez-vous que ses concepteurs passent du temps à se prendre la tête sur "oui mais en Javascript on a ce défaut, et bla bla bla..."?

c'est symptomatique d'une faineantise generalisée que de toujours vouloir retrouver les concepts de son langage dans d'autres.(j'ai fait pareil..)
Mais,
le c n'est pas du c++, ni du java, ni du javascript. les concepts ne sont pas les memes.
il faut arreter de croire qu'on peut apprendre javascript en 2 jours juste en appliquant quelques paralleles avec son langage d'origine. il est beaucoup plus profond et puissant que ca.
le prototypage de js remplace la notion de classes . c'est pas le meme mot, pas non plus le meme concept, il faut analyser et apprendre les specificites de ce langage avant de croire le maitriser ou le critiquer.
c'est pas non plus une raison de cracher sur le typage fort.
chaque langage a une raison d'exister. ne fut-ce que parce que son createur voulait le créer et l'a fait.
respectez au moins ca. eux l'ont fait, et vous.?
Si un langage ne vous plait pas, inventez mieux.

Le problème de Javascript n'a jamais été le fait qu'il n'y a pas de classe. Cette question, c'est un membre du forum qui l'a posée, mais ça n'apparait ni dans le WAT, ni dans wtfjs...

Et puis si énormément de projets (sites, ou APIs) se base sur JQuery et si des grands éditeurs comme Microsoft, Google ou Mozilla, cherchent à le remplacer, c'est qu'il y a un vrai problème avec ce langage

Oui, le Javascript a été fait selon la vision de son créateur et il n'en sera pas autrement.
Oui ce n'est pas un langage objet mais un langage de prototypage.
Oui, il peut être très puissant quand maîtrisé. Il suffit de voir ceux qui arrivent à programmer des Diablo-Like avec ou encore WebGL. Il est également très performant et l'absence de compilation peut être avantageuse pour certains.

Mais n'empêche que si on ne connaît pas toutes ses subtilités (par exemple au niveau des conversions implicites), il reste très difficile à appréhender et à débugguer (fonctionnalité qui ne fait rien et message d'erreur souvent sans rapport avec l'erreur dans la console), et excessivement énervant. Surtout quand les navigateurs n'utilisent pas tous la même implémentation de celui-ci.

Si le Javascript est si intuitif aux dires de certains, pourquoi tous ces frameworks (mootools, jquery, dojo,...) ? De ce que je connais, il s'agit du langage possédant le plus de Frameworks à ce jour. Et contrairement par exemple à PHP, Java ou .NET, la plupart de ces Frameworks sont là pour modifier et simplifier le langage, pas pour mettre en place des design patterns.

A l'école, est-ce qu'on nous enseigne le Javascript et ses paradigmes ? Mouais, 2 TP d'une heure sur du DOM... En 7 ans d'études (IUT et FAC confondus (et 2 Master de 2 sections différentes dont 1 Multimédia) !!!
Par contre on va passer 6 mois à faire de l'ADA, du PovRay ou du Scilab...

Quand je vois des SSII qui demandent des juniors avec FORTE EXPERIENCE en Javascript, ça me fait doucement rigoler. A mon avis, pour maîtriser un minimum Javascript, il faut passer au moins 1 an à ne faire que ça ! Et je sens qu'il faut au moins 5 ans d'expérience professionnelle pour réussir à accumuler 1 an de Javascript, et encore...

Le langage a des défauts voire des malfaçons ? Sans doute. Mais je pense qu'une bonne partie de ceux qui en parlent ou se moquent sont ignorants. Je suis moi même ignorant (en 3 ans d'expérience pro, j'ai dû accumuler 1 mois de Javascript, tout simplement parce qu'on essaie de l'utiliser le moins possible).

Bref, Javascript est pour le moment le seul langage client pour le web, pouvant s'interfacer à un serveur. Il est performant, sûrement bien fait pour qui le maîtrise, mais reste difficile d'approche et fait peur aux développeurs d'aujourd'hui tel l'assembleur. Il demande des compétences qui ne nous sont pas enseignées correctement.
Des Frameworks sont nés pour le rendre plus accessible, mieux organisé, au détriment des performances.
Maintenant, une première alternative au javascript émerge enfin : le Dart. Pour la plupart des navigateurs (pour le moment), on perdra en performances, par contre sous ceux supportant la VM native, elles seront supérieures au JS.

Je suis en train d'utiliser Dart pour mon projet personnel actuel et il est appréciable d'avoir enfin le choix !

Citation:

---

Envoyé par Farid63

si énormément de projets (sites, ou APIs) se base sur JQuery et si des grands éditeurs comme Microsoft, Google ou Mozilla, cherchent à le remplacer, c'est qu'il y a un vrai problème avec ce langage

---

De la même manière, on pourrait aussi dire que si des grands éditeurs s'investissent tant dans HTML5 et ses API JavaScript, ce n'est peut-être pas pour le remplacer... Et si beaucoup de projets se basent sur jQuery, c'est effectivement parce que jQuery permet de simplifier le code que l'on écrit (pas celui qui est réellement exécuté...) mais aussi parce que de nombreux développeurs Web ne connaissent pas JavaScript ! Quand on voit des projets utiliser jQuery uniquement pour remplacer la notation document.getElementById() (j'exagère à peine...), ça en dit long sur les compétences...

Citation:

---

Envoyé par LSMetag

Oui ce n'est pas un langage objet mais un langage de prototypage.

---

Bien sûr que si JavaScript est un langage objet ! On ne cesse de le répéter : la programmation objet ne se limite pas à la POO par classes !
En JavaScript, tout est objet justement.

Citation:

---

Envoyé par Bovino

Bien sûr que si JavaScript est un langage objet ! On ne cesse de le répéter : la programmation objet ne se limite pas à la POO par classes !
En JavaScript, tout est objet justement.

---

Mea culpa. Je me suis mal exprimé.
Je voulais dire Programmation Orientée Objet et Programmation Orientée Prototype qui reste de l'orienté objet, mais pas comme on a l'habitude d'utiliser (pas de classes,...). Ca reste malgré tout une philosophie différente.

Bonjour,
je ne retiens de cette vidéo que les rires "pitoyables" d'ados crédules buvant les paroles d'un adulte qui joue de leur fascination.

Dans la vrai vie, il ne viendrait à personne( quoique!!) de faire l'addition de 3kg de charbon et de 10l de Fuel.

[]+[] n'est jamais qu'une écriture de [].join('') qui renvoie bien une chaine vide, mais c'est moins marrant pour le coup.

Le langage essaie d'interpréter au mieux les inepties des faiseurs de code.

Ne jamais oublier, et ce quelque soit le langage, un programme ne fait que ce que le développeur lui demande, pas forcément ce qu'il veux.

La responsabilité d'un développeur doit être de vérifier les données avant leur utilisation/manipulation et là "notre ami" ['G']+['a']+['r']+['y'] n'est pas très performant.

No<body> is perfect!

Et pourquoi un langage doit-il fonctionner exactement de la même manière que les autres ?

Chaque langage possède ses avantages et ses inconvénients, ainsi que ses incohérences ... et c'est normal !

Après lorsque l'on maitrise bien un langage x ou y .. le résultat sera le même. ( pour des langages compatibles avec le produit final souhaité ).

Bref .. aucun langage n'est nul .. et aucun n'est parfait, le tout et d'utiliser le ou les bons pour arriver à un produit fini efficace et qui colle avec la demande.

Si Javascript ne vous plait pas, il suffit de vous mettre au CoffeScript qui a le même objectif, mais sans les côtés bizarres. Be positive :)

Faut juste abandonner les brackets.

Citation:

---

Envoyé par Farid63

Le problème de Javascript n'a jamais été le fait qu'il n'y a pas de classe. Cette question, c'est un membre du forum qui l'a posée, mais ça n'apparait ni dans le WAT, ni dans wtfjs...

Et puis si énormément de projets (sites, ou APIs) se base sur JQuery et si des grands éditeurs comme Microsoft, Google ou Mozilla, cherchent à le remplacer, c'est qu'il y a un vrai problème avec ce langage

---

Je comprends pas....

jQuery est une librairie JavaScript : ou est le problème ??

Donc, toi tu va faire du C/C++/C#/java from scratch ? bon courage hein, essaye de faire un programme sans importer une seule librairie.

Celons ta logique, si on est obligé d'importer math.h dans un programme C c'est que le langage C à donc un vrai problème ? 8O

Franchement je ne suis pas du tout d'accord avec ta logique. Les libs sont des briques à utiliser pour ne pas ré-inventer la roue et elles existent dans tous les langages.

Citation:

---

Envoyé par Golgotha

Celons ta logique, si on est obligé d'importer math.h dans un programme C c'est que le langage C à donc un vrai problème ? 8O

---

*Selon

Sinon, ta comparaison est spécieuse.
math.h fait partie de la bibliothèque standard du C. Et la bibliothèque standard fait partie de la définition du langage.
En revanche, je ne pense pas que JQuery fasse partie de la bibliothèque standard fournie avec JS.

Citation:

---

Envoyé par grim7reaper

- tu peux mélanger les entiers et les flottants dans une expression arithmétique (impossible en Haskell, qui est très fortement typé, sans conversion explicite).

---

Si on peut, comme le montre cette session GHCi

Code:

---

1 2 3 4 5 6 7

GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> 2 * 3.0 - 1 / 2 5.5

---

Le système d'inférence d'Haskell est suffisament intelligent pour correctement déterminer le type de l'expression:

Code:

---

1 2 3

Prelude> :t 2 * 3.0 - 1 / 2 -- affiche le type d'une expression 2 * 3.0 - 1 / 2 :: Fractional a => a

---

Cette expression pourra être 'convertie' selon le context d'utilisation en Float ou en Double par exemple

Citation:

---

Envoyé par grim7reaper

*Selon

Sinon, ta comparaison est spécieuse.
math.h fait partie de la bibliothèque standard du C. Et la bibliothèque standard fait partie de la définition du langage.
En revanche, je ne pense pas que JQuery fasse partie de la bibliothèque standard fournie avec JS.

---

rooooooooo... non mais.... donc si jQuery était une lib 'standar' là ça serait bon ? :roll:

là c'est limite de la mauvaise fois :mrgreen: dit tout de suite que tu veux me mettre en colère :aie:

Citation:

---

Envoyé par Yo Eight

Si on peut, comme le montre cette session GHCi

---

Non, on ne peut pas. Ton exemple met juste en lumière l'inférence de type de Haskell.

Tous les nombres de ton exemple sont considérés comme des flottants (grâce au système d‘inférence de type, comme tu le mentionnes), donc ça passe.
Mais comme je l'ai dit, tu ne peux pas multiplier un entier et un flottant. Comme le montre l'exemple suivant :
Je déclare un nombre, son type inféré est Int.
Je le multiplie par un flottant => Erreur.

Code:

---

1 2 3 4 5 6 7 8 9 10

Prelude> let i = 42 Prelude> i * 3.14   <interactive>:3:5: No instance for (Fractional Integer) arising from the literal `3.14' Possible fix: add an instance declaration for (Fractional Integer) In the second argument of `(*)', namely `3.14' In the expression: i * 3.14 In an equation for `it': it = i * 3.14

---

Citation:

---

Envoyé par Golgotha

rooooooooo... non mais.... donc si jQuery était une lib 'standar' là ça serait bon ? :roll:

---

Ha mais je ne rentre pas dans ce débat moi, je ne suis pas Farid63.
Je remarque juste que ton exemple est spécieux. Point.
On ne peut pas considérer que c’est la même chose d’utiliser une bibliothèque standard qui fait partie de la définition du langage et d‘utiliser une bibliothèque externe.
C’est tout ce que je veux dire, je ne porte pas jugement sur si c’est bien ou pas d’utiliser JQuery.

@grim7reaper

Ça sera ma dernière intervention pour éviter de sortir du contexte du thread.

Peut-être alors que c'est juste un problème de vocabulaire. Ce que j'ai mis en gras dans ta précédente intervention peut-être mal interprété. Car ce que j'ai écris dans la session GHCi est ce qu'une majorité de personne identifie comme une expression arithmétique. Et on voit très bien que l'on peut mélanger les entiers et les doubles.

Code:

---

1 2 3 4

Prelude> let i = 42 :: Float Prelude> i * 3.14 131.88

---

Je ne pense pas que ton angle d'attaque soit le bon avec les nombres.

De plus ce code compile correctement en dehors de GHCi (heureusement d'ailleurs)

Code:

---

1 2 3 4

main = let i = 42 in print (i * 3.14)

---

Code:

---

1 2 3 4 5 6

[yoeight@gikoo ~]$ ghc toto.hs [1 of 1] Compiling Main ( toto.hs, toto.o ) Linking toto ... [yoeight@gikoo ~]$ ./toto 131.88

---

GHCi ne se comporte pas exactement comme la compilation de GHC pour des raisons pratiques

J‘arrête le HS aussi après ce message.

Citation:

---

Envoyé par Yo Eight

@grim7reaper

Ça sera ma dernière intervention pour éviter de sortir du contexte du thread.

Peut-être alors que c'est juste un problème de vocabulaire. Ce que j'ai mis en gras dans ta précédente intervention peut-être mal interprété. Car ce que j'ai écris dans la session GHCi est ce qu'une majorité de personne identifie comme une expression arithmétique. Et on voit très bien que l'on peut mélanger les entiers et les doubles.

---

Non, dans ton exemple du message précédent, tu mélanges des Num et un Float, il n'y a pas d‘entier. À aucun moment.

Citation:

---

Envoyé par Yo Eight

Code:

---

1 2 3 4

Prelude> let i = 42 :: Float Prelude> i * 3.14 131.88

---

Je ne pense pas que ton angle d'attaque soit le bon avec les nombres

---

Je donne juste un exemple qui démontre ce que je dis. Bien sûr que si tu types explicitement en Float, bah tu peux multiplier avec un autre Float. Grande découverte…

Mais oui, tu as raison, c‘est très certainement un problème de vocabulaire.
Ce que j’appelle entier c’est quelque chose qui est typé entier, pas juste une constante qui ressemble à un entier.
Ce que j‘appelle un flottant c‘est quelque choses qui est typé flottant, pas quelque chose qui peut être un flottant sans décimales.

42 ce n’est rien pour moi, juste un nombre. Pas plus d’info. Pour Haskell aussi d’ailleurs :

Code:

---

1 2	Prelude> :t 42 42 :: Num a => a

---

Ni flottant, ni entier. Un nombre. Point.

Après, selon l‘utilisation un type plus précis va être inféré si nécessaire.

Par contre, une fois les expressions typées, un entier ne pourra pas être multiplié par un flottant en Haskell. C‘est une garantie (sauf conversion explicite).
Par exemple, avec le code suivant ne compilera pas (car length renvoie un Int) :

Code:

---

1 2 3

main :: IO () main = let i = length [1..42] in print(i * 3.14)

---

Il faudra faire la conversion à la main, ou utiliser genericLength qui renvoie un Num qui pourra être inféré en Float.

Citation:

---

Envoyé par Golgotha

Je comprends pas....

jQuery est une librairie JavaScript : ou est le problème ??

Donc, toi tu va faire du C/C++/C#/java from scratch ? bon courage hein, essaye de faire un programme sans importer une seule librairie.

Celons ta logique, si on est obligé d'importer math.h dans un programme C c'est que le langage C à donc un vrai problème ? 8O

Franchement je ne suis pas du tout d'accord avec ta logique. Les libs sont des briques à utiliser pour ne pas ré-inventer la roue et elles existent dans tous les langages.

---

Je n'ai jamais dit qu'utiliser JQuery est une mauvaise chose au contraire, je l'utilise très souvent quand je dois faire du JS un peu complexe et multiplateforme.

Et comme le dit grim7reaper, on ne peut pas comparer JQuery avec math.h en C, mais plutôt comme Struts en Java par exemple (Désolé pas d'exemple en C).

Enfaite ce sont plutôt les autres exemples que j'ai donné (Dart, TypeScript) qui me font dire que certains veulent remplacer le JS et JQuery n'entre pas dans ce cas.

Citation:

---

En revanche, je ne pense pas que JQuery fasse partie de la bibliothèque standard fournie avec JS

---

Il n'y a pas de lib standard dans Javascript. Le DOM est une API , comme NodeJS a son API qui n'a rien à voir avec le DOM.

JQuery existe principalement parce que tout les navigateurs n'implémentent pas le DOM de la même manière , les anti-jquery oublient complètement cet aspect.

Citation:

---

Envoyé par Voïvode

Suis-je le seul à être choqué que JavaScript n'ait pas de classes ? :mrgreen:

Edit : Et pour reprendre l'excellente formulation de Schouss plus loin dans cette discussion…

---

Javascript est un langage orientée prototype, paradigme qui est plus étendue que la programmation orientée objet "avec classe". Celle-ci est tout fait modélisable avec Javascript, c'est simplement un cas particulier d'un concept plus général. Si il faut être choqué, c'est pas l'étendue des possibilités que ce type de language offre.