JS++ : du JavaScript étendu avec les classes, les types, etc.

JS++ : du JavaScript étendu avec les classes, les types, etc.
grâce à ce langage de programmation pour applications Web et mobiles

Pièce jointe 212045

JS++ ou JavaScript++ est un langage de programmation pour construire des applications Web et mobiles. Il étend le langage JavaScript en apportant une gestion des types, des classes et d'autres fonctionnalités.

En principe, si vous connaissez bien le JavaScript, vous n'aurez aucun souci avec JS++. Il vous suffit d'intégrer dans votre code les « extensions » que vous désirez.

Par exemple, le typage est garanti à deux niveaux : la compilation et l'exécution. Une variable déclarée comme int représentera toujours un entier. Ce qui n'était pas nécessairement vrai jusqu'alors. Fort heureusement, ce typage est optionnel. Ce qui signifie que vous pouvez faire évoluer votre code au fur et à mesure en faisant coexister les déclarations JavaScript standards et les types de JS++.

Le langage est multiplateforme, il peut s'exécuter dans le navigateur et sur le serveur.

Ce langage gère notamment :

• les types tels que bool, string, external, byte, int, unsigned short, float, Arrays, etc. ;
• les modifiers comme final, static, etc. ;
• les classes ;
• les imports ;
• les modules ;
• le drag & drop ;
• et bien d'autres choses.

En fait, le compilateur Onux JS++ unifie les types dans un seul type connu comme le type externe unifié. La vérification des erreurs au moment de la compilation fait de JS++ un langage semblable à Java (ce n'est qu'un exemple).

Il est à noter que JS++ n'est pas open source et n'est pas entièrement gratuit. La bibliothèque standard l'est, rassurons-nous, mais les extensions ne le sont pas toutes. Je pense aux outils de cartographies et de graphiques.

Serions-nous en train de parler d'un rival à TypeScript ? Pour ça, il faudrait suivre un peu plus les spécifications ES6. Il faut savoir que JS++ est plus vieux et évolue selon (parfois du moins) les retours utilisateurs. Il y a cependant des différences au niveau des instructions de compilation qui rendraient JS++ plus simple d'utilisation. Le débat est ouvert. Que ce soit vis-à-vis de TypeScript ou bien d'autres technologies.


:fleche: Téléchargement
:fleche: Documentation

Source : Le blog officiel

Et vous ?

:fleche: Que pensez-vous de JS++ ?


http://www.developpez.com/template/kit/kitinfo.png Rendez-vous sur nos forums des bibliothèques et frameworks JavaScript !

Encore un nouveau surensemble Js qui tend à retransformer le langage initial. Exactement ce que je reprochais dans le topic sur les langages détestés.

J'ai l'impression que c'est une tentative foireuse de faire de Js une espèce de C++... Le modèle objet de Js (par prototype me semble), c'est pas sensé offrir des possibilités différentes à celles du modèle Java traditionnel ? Pourquoi revenir en arrière ?


Je suis confus, je ne comprends pas l'intérêt de cette librairie.

Bin tous le monde veux faire du JS, mais sans se faire chier a apprendre à l'utilisé, sois disant trpo mal foutu et trop compliqué (alors que c'est un des langage les plus simple...), donc on se retrouve avec tous ces pseudo langage...

Citation:

---

Envoyé par goldbergg

Bin tous le monde veux faire du JS, mais sans se faire chier a apprendre à l'utilisé, sois disant trpo mal foutu et trop compliqué (alors que c'est un des langage les plus simple...), donc on se retrouve avec tous ces pseudo langage...

---

On peut sérieusement douter de l’intérêt de ce langage par rapport à TypeScript par exemple, mais OUI JS est mal foutu et pas adapté aux applications modernes (dans sa version actuelle)

Même si je trouve que le JS a des fonctionnalités intéressantes sa syntaxe me rebute, surtout quand il s'agit de classe et d'objet. Je serai heureux de faire du JS (ou du dart) avec la souplesse qu'offre un langage objet et j'attends de pied ferme les implémentations d'ECMA 6

Citation:

---

Envoyé par LeBressaud

On peut sérieusement douter de l’intérêt de ce langage par rapport à TypeScript par exemple, mais OUI JS est mal foutu et pas adapté aux applications modernes (dans sa version actuelle)

---

Personnellement, je pense qu'il suffirait juste d'arrêter d'utiliser JS pour ce quoi il n'est pas fait : ça sert à rendre les pages web dynamiques (gros raccourcis), et rien d'autre. Le reste, c'est comme taper sur un clou avec le manche d'un tournevis : oui, ça marche mal, ça tord le clou et ça ne l'enfonce qu'à moitié ; mais ce n'est pas le tournevis qui est pourri, c'est simplement que pour les clous, il faut un marteau.
Typescript et toutes les surcouches et frameworks du genre, malgré leurs qualités, sont juste des renforts du manche du tournevis pour que l'on puisse taper avec sur les clous, mais ça ne vaut toujours pas un bon vieux marteau.

Citation:

---

Typescript et toutes les surcouches et frameworks du genre, malgré leurs qualités, sont juste des renforts du manche du tournevis pour que l'on puisse taper avec sur les clous, mais ça ne vaut toujours pas un bon vieux marteau.

---

L'image est tout à fait pertinente.
On peut espérer que le langage Javascript évolue vraiment vers une syntaxe plus conventionnelle pour le programmeur objet. D'ailleurs, c'est déjà ce qui est en train de se passer avec la nouvelle norme Ecmascript 6 (ES6); cf. cette page. Cette norme introduit notamment les classes et l'héritage via les mots clés class et extends, ainsi que les expressions lambda.
Je pense qu'on va finir par arriver à un vrai langage objet, plus adapté aux besoins des applications complexes d'aujourd'hui (d'ailleurs avant, on ne parlais même pas d'"applications javascript"). C'est une question de patience. En attendant, TypeScript est tout de même une alternative intéressante, je trouve...

Je ne sais pas trop quoi penser de ce nouveau sur-ensemble de JavaScript dans la mesure où il n'est même pas Open Source et n'est pas totalement gratuit.
Ce langage me semble très jeune, sans réelle communauté ou sponsor.
Le système de typage me semble assez basique et loin de TypeScript par exemple qui offre des concepts d'union de types, d'intersection de types et divers mécanismes pour gérer le polymorphisme et la généricité sans sacrifier au contrôle des types.
Je viens de parcourir la documentation technique, et je ne vois pas de valeur ajoutée au langage de Microsoft. S'il y a des gens qui programment avec JS++, ça m'intéresse de connaître leurs motivations et leurs retours d'expérience.

Je fais régulièrement du angluarjs, j'aime bien ce framework et il m'a un peu réconcillié avec JS. C'est bien propre comme code, relativement clean à suivre, même si l'infrastrucutre à mettre en place pour suivre les plugins (npm, bower, grunt) est assez chiante. Mais par pitié. Laissez javascript crever au fond d'un égout, ce truc est tout sauf un language. Si vous voulez un language typé, faites autre chose que du JS. Si vous voulez faire de la programmation en dehors du browser, faites autre chose que du javascript.

Le JS dans le browser, ça n'a pas de prix. Pour toute le reste, il y a les autres languages.

http://www.commitstrip.com/wp-conten...-650-final.jpg

Citation:

---

Envoyé par LeBressaud

On peut sérieusement douter de l’intérêt de ce langage par rapport à TypeScript par exemple, mais OUI JS est mal foutu et pas adapté aux applications modernes (dans sa version actuelle)

---

Se qui est mal foutu sa n'est pas le langage (qui est d'une grande simplicité une fois qu'on a un minimum cherché à le comprendre et qui permet de faire de vrais WebApp sans soucis), mais la mentalité des devs qui veulent faire de la POO par Class avec un langage qui n'est pas fait pour sa...
Et que sa soit avec le future mot clés Class ou via les surcouche à la TS, de toute façon il n'y aura jamais de vrais Class comme en C++ ou en C#/Java, juste de la simulation pour faire plaisir a ceux qui sont largué des que la notion class est absente.

Si vous êtes largué avec un langage comme le JS, qu’est-ce que sa va être le jour ou vous allez devoir pondre du code dans des language à la con comme le PL/SQl ou encore l'ASM

Tout a fait d'accord @goldbergg.
Moi j'si toujours du mal a comprendre le raisonnement des ceux qui haissent le Javascript.
J'ai plus l'impression que cette haine vient plus du fait qu'ils ne comprennent pas comment ce language fonctionne et cherche toujours a le comparer avec un autre language (C, C++, Java, Php, etc...).
Personnellement je ne developpe pas de la meme maniere en Php et/ou Java qu'en Javascript et je n'essaie pas de trouver des similitudes.
Jusqu'a present, je n'ai rencontre aucune personne ayant un bon niveau en Javascript qui me dit: "le JS c'est nul"

Je vois beaucoup de jugements personnels sur ce fil. Et aussi des affirmations qui sont simplement fausses.
Ceux qui veulent absolument parler de programmation objet avec JS doivent se rappeler que le paradigme de ce langage, ce n’est pas les classes, c’est les prototypes. C’est ça et seulement ça qui fait toute la différence, et qui donne l’impression à ceux qui ne connaissent pas suffisamment que le langage est mal foutu.

Pour le débat entre classes et prototypes, voir la conversation L’opérateur new : bonne ou mauvaise pratique ?

C'est triste que le seul argument des défenseurs du javascript soit "Si vous n'aimez pas Javascript c'est que vous ne le connaissez pas."

Pour en revenir au sujet, je rejoins l'avis déjà exprimé : je ne vois pas bien l'intérêt par rapport à Typescript, et Typescript a l'avantage d'être open source. Quelqu'un a-t-il un retour d'expérience sur JS++?

Non ce qui est triste c'est qu'on continue à enseigner qu'il n'y a qu'une seule façon de faire de la POO c'est d'utiliser la notion de classe.

C'est tout de même mal heureux que plus de 80% des développeurs soient persuadé que pour faire de la programmation-objet il faille en passer par des langages qui ne connaissent que la notion de classe et d'instance et pas la notion d'objet. Un comble. Alors on invente des patterns singleton et plein de trucs pour pallier les manques de ces langages qui s'étant contraints à la classe et instance n'ont d'autre choix que de bricoler des théories monstrueuses et des patterns appris comme si c'était la seule approche.

Alors lorsqu'un langage apparait avec des notions natives dans le langage qui ne nécessitent plus tout ce barda le développeur comme s'il était devenu incapable d'ouvrir son esprit dit que la chose est mal foutue, absurde, etc.

Il est étonnant de voir que dans des langages suffisamment bien pensés pour ne pas avoir besoin constructions capilotractées se voient critiqué du manque de ces constructions.

Bref on enseigne à 99,99% des développeurs que la seule façon de faire de l'objet c'est classe/interface/instance. Et on crie haut et fort que c'est la seule bonne façon de faire. Et pour le prouver on ajoute si tout le monde ou presque le dit c'est que c'est vrai.

Heureusement que les anciens ne se sont pas contentés de rester sur les langages procéduraux qui à l'époque représentaient la majorité de l'enseignement.

Mais je suis confiant, car quelque soit le langage même le plus strict quant à sa vision de la théorie ont voit toujours apparaitre des gens qui cherche à faire mieux à faire différemment.

Quant au critique qui dit que EcmaScript est un langage qui n'est pas adapté au besoin d'aujourd'hui je leur réponds qu'il est tellement inadapté que EcmaScript se voit intégré dans de plus en plus de solutions. Qu’il a fini par quitter le domaine du web où il est né pour se répandre partout! Il est sûr que son inadaptation en a fait un candidat prisé.

Tout cela me rappelle d'autres guerres de chapelle. X25 et IP un très structuré fortement normalisé avec des tonnes de capacités normalisées l'autre simple souple et facile à mettre en oeuvre et se contentant de normaliser le minimum.
SOAP et Rest un structuré normalisé fortement documenté outillé, etc. l'autre simple léger se contentant de normaliser le minimum.
Compilé/Interprété là encore la compilation apporte rigueur structure, etc. et l'interprétation souplesse, etc.

Et je constate aujourd'hui que SOAP est utilisé et que Rest aussi. Que les concepts de X25 sont présents chez tous les opérateurs réseau (même si X25 lui-même est marginal) et qu’IP est largement répandu. Quant à la Compilation/Interprétation je constate que les deux sont présent que beaucoup de langage compilé embarque des notions venues de l'interprétation et que l'interprété utilise de plus en plus de notions de compilation au point que pour certain on ne sait plus trop où les situé.

Je pense que la programmation à base de classe est un outil formidable et qu'elle a de très beaux jours devant elle. Mais qu'il y a une place tout aussi grande dans énormément de domaines où cette approche montre ses limites.

Quant à JavaScript il n'est pas parfait comme tous les langages, mais les reproches à lui faire ne sont surement pas ceux que l'on peut voir dans la majorité des posts sur les forums.

Souvent quand je lis les questions sur le forum je pense à quelqu'un qui utiliserait les mots japonais pour écrire comme en français. C’est sur que c'est mal foutu le japonais lorsqu'on veut écrire sa phrase comme en français. Mais lorsqu'on utilise les notions du japonais étrangement c'est limpide.

A+JYT

Content de voir autant de gens défendre la POO par prototypes, ça fait plaisir à voir un peu d'ouverture d'esprit par rapport aux modèles dits "conventionnels".

Beaucoup essaient de transformer JavaScript en Java depuis la naissance du langage, d'où son nom bâtard. Pour la petite histoire, Brendan Eich a ajouté tardivement dans la phase de conception du langage les constructeurs et l'opérateur new, à la demande de Netscape. Netscape travaillait avec Sun à l'époque et pour des raisons marketing, ils voulaient faire coïncider la syntaxe malgré le fait que les deux langages avaient des différences fondamentales (voir http://speakingjs.com/es5/ch04.html).

Cette pression pour faire ramener le langage dans la zone de confort de la majorité des devs (c'est à dire la programmation OOP classique enseignée dans les écoles) est toujours présente aujourd'hui. Le dernier cas le plus représentatif est l'ajout du mot-clé "class" en ES6 qui a été vivement critiqué par de nombreux experts, et dont le seul intérêt est d'ajouter du sucre syntaxique pour attirer plus de développeurs quitte à les tromper sur l'implémentation interne.

J'aimerais beaucoup voir non pas un JS++ mais un JS--, dépouillé de tous ses éléments dépréciés et focalisé sur ses meilleurs aspects avec la vision originale, dans la lignée de Self et Scheme. WebAssembly est peut-être la voie de sortie pour en finir avec ce langage chimère : si TypeScript et consors viennent à compiler en WASM, il pourrait en être de même avec un Mocha ou un LiveScript.

Pareil recentrer JS sur ses fondamentaux quitte à autoriser dans le navigateur l'exécution de bytecode, ASM, ou autre, produit par d'autres langages.

Au départ la balise script permettait d'exécuter d'autre langage. En 1995 j'exécutais du TCL dans le navigateur. IE y avait ajouté VBScript

Alors pourquoi pas un WASM pour tous les langages qui veulent produire du compilé, du type, etc.
Ce ne serait pas un pb de compatibilité avec l'existant je ne vois pas de restriction à ne proposer que WASM dans le navigateur. l'interprète EcmaScript pouvant très bien être un code WASM comme un autre.

Quant à EcmaScript je vote moi aussi pour la suppression des sucres en tout genre et des deprecated.

Enfin le dernier point qui pour moi est aussi grandement améliorable et qui n'a rien avoir avec le langage, mais que bien trop souvent on confond, c'est le binding DOM avec le langage.
Je pense que l'API DOM n'est pas cool. Pour preuve la liste interminable de lib qui cherche à améliorer cette interaction. Une API plus HTML et moins XML serait appréciable, moins verbeuse, plus intuitive.

A+JYT

Là, c'est drôle : on me répond au message où je me plains que l'argument des défenseurs de Javascript est d'accuser ses détracteurs de ne pas comprendre Javascript par :

Citation:

---

Envoyé par sekaijin

Non ce qui est triste c'est qu'on continue à enseigner qu'il n'y a qu'une seule façon de faire de la POO c'est d'utiliser la notion de classe.

C'est tout de même mal heureux que plus de 80% des développeurs soient persuadé que pour faire de la programmation-objet il faille en passer par des langages qui ne connaissent que la notion de classe et d'instance et pas la notion d'objet. Un comble. Alors on invente des patterns singleton et plein de trucs pour pallier les manques de ces langages qui s'étant contraints à la classe et instance n'ont d'autre choix que de bricoler des théories monstrueuses et des patterns appris comme si c'était la seule approche.

---

Désolé Sekaijin si je parais agressif contre toi, ce n'est ni dirigé contre toi ni supposé être une agression.

Mais c'est une illustration parfaite du problème. A chaque fois que JS est critiqué, on entend la même chose : "Vous n'aimez pas Javascript parce que vous ne comprenez pas les prototypes." Argument très malheureux car :
- il ignore les développeurs qui comprennent parfaitement ce système... et le détestent,
- il ignore les développeurs qui n'aiment pas Javascript pour d'autres raisons,
- c'est une attaque ad hominem.

Javascript mérite mieux. Par exemple, on peut vanter sa concision, la facilité qu'il y a à traiter les fonctions comme des variables, son support universel, la qualité des moteurs Javascript, son écosystème, etc. La liste des raisons d'aimer Javascript est longue, très longue. L'une quelconque de ces raisons serait un bon argument. Un meilleur argument serait des cas d'étude où Javascript a fait des merveilles.

Mais non, à chaque fois c'est "vous comprenez pas les prototypes". Au point que quand j'envoie un message qui ne critique pas Javascript (relisez le) on me répond devinez quoi?

Donner de mauvais arguments pour une thèse est une vieille technique de rhétorique pour la démolir. Ici, cet argument en faveur de JS est bien plus nocif que n'importe quelle critique. Pire, comme il est agressif, il attire l'attention et noie les information pourtant utiles dans les mêmes messages. Le message de sylvain vers l'article traitant de new vs Object.create est bien plus utile, mais ce qui précède ne donne pas envie de lire l'article. (Oui, je l'ai lu quand même.)

Si je peux me permettre de jouer les psychologues de comptoir (ou dans ce cas, de forum), c'est un vieux problème quand on critique le langage de programmation préféré d'un développeur. La réponse est souvent 90% émotionnelle et seulement 10% rationnelle. Par exemple, ici, mon message était neutre vis à vis du langage lui-même. Pourtant, ses lecteurs ont immédiatement cru que je déteste Javascript.

Bon, c'est le cas, mais ce n'est pas une raison.

@BugFactory: que je sache, le message de sekaijin n'était pas dirigé contre toi non plus. Pas la peine de s'énerver pour si peu ;)

Ce n'est pas un secret qu'il y a un problème avec l'enseignement de JavaScript :
- il est boudé dans les écoles
- le net est bourré de ressources médiocres ou obsolètes du style w3schools ou toutjavascript
- c'est un langage utilisé par beaucoup d'amateurs en continuité de HTML et CSS
- beaucoup de devs sont dépendants de leurs bibliothèques/frameworks
- c'est un langage très permissif avec lequel il est très facile de faire n'importe quoi (mais aussi de belles choses heureusement)

Par expérience, que ce soit dans mon boulot, dans mon entourage ou sur ces forums, je ne peux que constater les dégâts: la majorité code en JS avec très peu de connaissances sur ce langage. En ce sens, les prototypes sont en quelque sorte à la frontière entre les bons et les mauvais développeurs JS. Je m'en sers souvent pour trier rapidement les candidats lors des entretiens. Et voilà le résultat: sur cinq candidats, deux n'ont aucune idée de ce dont je parle, deux autres font vaguement le lien avec la prog objet, et un seul sait me donner une définition satisfaisante telle que "l'objet auquel un autre objet hérite des propriétés". Tous ont mis JavaScript sur leur CV mais un seul connaissait à peu près ce mécanisme de base du langage.

Donc je comprends la réaction de sekaijin, qui a sans doute entendu comme moi un bon paquet de fois que "JavaScript c'est nul y'a pô de classes". C'est une raison suffisante pour écarter d'office une bonne partie des détracteurs. Après, s'il y en a qui comprennent parfaitement tous ces concepts et critiquent quand même la POO prototypée par rapport à la POO classique, ça m'intéresse d'entendre les arguments parce que je n'en ai jamais trouvé jusqu'ici.

Effectivement je ne critiquais personne.

Je réagissais juste aux propos en général. pas spécialement ceux de ce post.
A+JYT

Assez d'accord avec Mouke et goldbergg...

Aujourd'hui y a plein de développeur Objet, c'est la mode... alors on attends de JavaScript qu'il soit Orienté Objet pour faire pareil.

Malheureusement, c'est un peu comme si on concevait tout une archi pour un e-commerce et qu'on s'en servait finalement comme un intranet... à l'image du marteau et du clou...

JavaScript a ses avantages et inconvénients, et faut juste les connaitre : https://davidwalsh.name/javascript-o...deconstruction

Attention au vocabulaire employé qui risque d'en froisser certains : JavaScript est bien orienté objet. Classes et prototypes sont deux représentations tout à fait valides de la prog orientée objet.

Aussi j'ai l'impression que la prog objet c'était plutôt à la mode il y a 5 ans, et qu'aujourd'hui c'est la prog fonctionnelle et réactive qui est sur le devant de la scène. J'entends beaucoup parler de Haskell, OCaml, Scala, Kotlin, Clojure etc... Et dans le monde du JS plus particulièrement, de React, Om, Rx...

Citation:

---

Attention au vocabulaire employé qui risque d'en froisser certains : JavaScript est bien orienté objet. Classes et prototypes sont deux représentations tout à fait valides de la prog orientée objet.

---

Certes orienté objet, mais pas comme on l'entend aujourd'hui.

Au fond, c'est effectivement du pur objet. Mais pas un orienté objet conventionnel. Le problème étant qu'on se fatigue à vouloir le transformer à tout prix. Pourquoi pas utiliser cette énergie à créer de nouveau language ? non ?

La programmation événementielle semble avoir le vent en poupe. (souvent confondu avec la programmation réactive)
dans les années 90 il y avait reactiveC et reactiveC++ deux langage réactifs au syntaxe proche de C ou C++

Citation:

---

Envoyé par wikipedia

Les paradigmes de la liste sont regroupés par grandes familles.

Types de programmation impérative (et dérivés)
Programmation impérative, paradigme originel et le plus courant
Programmation structurée, visant à structurer les programmes impératifs pour en supprimer les instructions goto
Programmation procédurale, à comparer à la programmation fonctionnelle
Types de programmation orientée objet (et dérivés)
Programmation orientée objet, consistant en la définition et l’assemblage de briques logicielles appelées objets (comme en Smalltalk)
Programmation orientée prototype, qui simplifie et rend plus flexible la programmation orientée objet
Programmation orientée classe, à comparer à la Programmation orientée prototype (dans le contexte de la programmation orientée objet)
Programmation orientée composant
Types de programmation déclarative (et dérivés)
Programmation déclarative, consistant à déclarer les données du problème, puis à demander au programme de le résoudre
Programmation descriptive, à l'expressivité réduite, qui permet de décrire des structures de données (par exemple, HTML, XML ou LaTeX)
Programmation fonctionnelle, avec laquelle un programme est une fonction au sens mathématique du terme
Programmation logique, consistant à exprimer les problèmes et les algorithmes sous forme de prédicats (comme en Prolog)
Programmation par contraintes, à comparer à la programmation logique
Autres types
Programmation événementielle, consistant à répondre à des événements
Programmation séquentielle
Programmation interruptible, à comparer à la programmation événementielle
Programmation concurrente, où l’on tient compte de l’exécution en parallèle de plusieurs piles sémantiques
Programmation orientée aspect (comme en AspectJ)
Programmation par contrat, dans lequel le déroulement des traitements est régi par des règles (comme en Eiffel)
Programmation chimique, où les programmes sont vus comme des solutions chimiques abstraites. Les données sont des molécules dont les réactions chimiques représentent les opérations.
Programmation orientée agent, souvent basée sur la programmation orientée objet, qui simplifie le développement d’agents logiciels
Programmation orientée concept
Programmation orientée pile (comme en Forth)
Programmation orientée principes
Programmation orientée flux de données, souvent utilisée pour les solutions de communication client/serveur, elle permet d'abstraire les différents plateformes en se concentrant sur l'échange et le traitement des données. Elle est généralement représentée sous forme de diagrammes ou de graphes (voir Diagramme de flux de données) (comme dans un Tableur)
Programmation non-déterministe
Programmation orientée sujet
Programmation réactive
Programmation synchrone
Programmation par annotations (comme en langage Flare)
Programmation par attributs (comme avec les annotations Java, pré-traitées par la classe XDoclet, ou avec les attributs C#)
Programmation sur flux, à comparer à la Programmation sur événement
Programmation par messages, à comparer à la programmation impérative
Programmation orientée processus, pour la programmation parallèle
Programmation récursive, à comparer à la programmation itérative
Programmation réflexive
Programmation scalaire, à comparer à la programmation par tableaux
Programmation au niveau valeur, à comparer à la programmation au niveau fonction

---

il manque dans cette liste les langages à acteurs qui ressemble au agent mais qui vont plus loin dans les concept de décisions.
les approche génétiques qui considèrent les éléments d'un programme comme l'expression d'un gène.
etc.
J'oubliais l'approche chorégraphique. Utilisé dans certains langage spécialisé en robotique par exemple.
Urbi est un langage qui offre ces approche:

Citation:

---

Programmation parallèle et événementielle
Programmation par prototypes
Syntaxe proche du C++
Architecture de composants

---

Bref il y a de la place pour beaucoup
A+JYT

Avec l'avènement de l'ES5 et l'ES6 le besoin en lib tierce est de moins en moins présent la preuve il n'y a plus besoin de jQuery pour faire une sélection poussée d'objets du DOM du genre $('#truc .machin') on passe à document.querySelectorAll('#truc .machin') bon OK on ne peut pas faire de multiple assignation avec une sous fonction contrairement à jQuery mais moins j'utilise jQuery moins je fait consommer d'électricité, oui je fait du bon code pas simplement pour mon propre égo mais aussi pour la planète ça vous surprend ?:mrgreen:
et les autres sur-couches vous me demander ? quel est l'intérêt d'augmenter la consommation électrique de 70% pour satisfaire l'égo démesuré de développeurs mal luné ?:aie:

Là encore je sens la grosse confusion entre le langage et sa norme Ecma et l'implantation dans le navigateur et sa norme W3C

Le langage évolue mais il ne remplacera jamais les frameworks pas plus que les frameworks ne redéfinissent le langage. Les frameworks sont là pour mettre en place des cadres de travail, des façon d'utiliser le langage. Les lib comme JQuery ne modifient pas le langage elles l'utilisent.

Quant aux Sélecteurs cela n'a rien à voir avec le langage. il s'agit d'un fonction du DOM. leur définition est donnée par la norme sous la forme IDL et sont implémentée dans divers langages. JS n'est qu'un de ses langage parmi d'autres.

Quant à la séparation rien de plus simple pour la voir en oeuvre. ActionScript implémente le langage dans flash sans la partie DOM du W3C. Nashorn implémente le langage dans la JVM sans le DOM etc.

Si des lib comme JQuery son née c'est qu'elle réponde à un besoin. Que des développeur l'utilise à tord et à travers est un fait. mais c'est vrais dans toutes les technos de l'informations.

A+JYT