Discussion :

[mangobango]

Ba, comme je l'ai dit précédemment, un langage sa s’apprend

Il faudrait justement commencer par là...

Mais revenons à nos moutons. Oui, pour moi il faut toujours de nouveaux outils parce qu'il y a de nouveaux modes de pensées, de nouveaux problèmes... après ça prend ou ça prend pas. Parfois sans raison à part 'pas le choix', ça prend.

Effectivement un nouveau langage doit se différencier un minimum pour justifier sa création.

Mais conférer au commun des opérateurs des comportements parfaitement ésotériques, c'est vicieux. Il y a un truc pour ça, c'est la surcharge d'opérateurs. Mais Brendan Eich devait être en plein rebiffage d'adulescent à l'époque et plutôt que s'habiller en gothique il a pondu un Brainfuck à sa sauce. Je crois bien qu'il n'y a rien des spécificités de JS qui le justifient, surtout au regard des milliers de lignes de transpilateurs pondus pour ne plus avoir à écrire du JS ^^ (à part les ASM qui a réussit à en avoir autant?).

Pour l'histoire du bytecode, V8 ou Spidermonkey, (ou...) génèrent et déboguent déjà du bytecode. A 14 ans, ça se comprend de ne pas voir la machinerie sous-jacente. Si de mon langage favori je peux générer du bytecode et le donner à manger à un navigateur... tout bénef!

Zut, j'avais dit que je ne trollait JS que le vendredi...

Daniel

[LSMetag]

je connais pas les motivations du gars mais je pense qu'il a voulu jouer sur le fait que javascript est mal vu c'est plus un sketch qu'autre chose.

pour en revenir au sujet qui dit qu' un bon langage semble etre un langage qui permet la création de framework efficaces vu le nombre de framework en js javascrpt semble etre the langage

Peut-être n'utilisait-il pas EcmaScript 6 ou alors une vieille version pas fiable de NodeJS. Enfin on s'en moque.
Pour les Frameworks, JS, dans l'absolu est efficace et difficilement contournable. Mais les Frameworks sont là aussi à mon avis pour faciliter son utilisation qui finalement demande une certaine expertise.

La différence de logique est telle que j'ai du mal à imaginer un développeur confirmé Java/C# être également confirmé en JS tellement le mode de fonctionnement, au delà du prototypage, sont différents.
C'est là où les 10 ans d'expérience se révèlent utiles.

[LSMetag]

Peut-être qu'un langage neurologique ou génétique pourrait permettre de pousser les IA au délà de ce qu'elles peuvent faire jusqu'à présent. On a des algorithmes d'apprentissages, mais pourquoi ne pourrions-nous pas créer des langages avec primitives d'apprentissages, pour améliorer de façon exponentielles les IA ?

Une sorte de langage Haut Niveau pour les IA.

Je vous vois venir : Skynet ^^

[AS_PTT]

je suis sceptique sur l'aspect logique de la question. En quoi est il nécessaire de choisir entre langage et biblio. La question est biaisé

[Pascaltech]

ne fait pas de remarque trop futuriste. Faudrait bien garder la possibilité de faire faire la même chose mais de deux façon différentes au minimum.

Parlons du passé alors.

[Invité]

C'est un vaste débat, avoir un nouveau langage, bien. Mais pourquoi? Qu'est-ce qu'il apporte de plus que le reste? Je pense par exemple à Rust, Go... Pourquoi devrait-on s'y intéresser? Est-ce que mettre de tels langages sur son CV peut apporter quelque chose? Après, plutôt que de créer un langage nouveau, pourquoi ne pas spécialiser un déjà existant? Je trouve ça mieux.

Le Delphi a étendu le Pascal
Le C++ a étendu le C
NodeJS : du Javascript à un autre niveau
...

[Matthieu Vergne]

Point de vue perso : un langage te donne des briques de base, une biblio te donne des assemblages de briques prêts à être réutilisés. Si pour faire une fonctionnalité, tu vois que peu importe comment tu assembles ces briques données, tu n'arrives pas à avoir un assemblage satisfaisant, alors tu as une bonne raison de faire un nouveau langage (i.e. de nouvelles briques), ou tout au moins de faire évoluer le langage existant. Ce qui permet de choisir entre le nouveau et l'évolution, c'est à quel point les nouvelles briques sont en accord avec les objectifs initiaux du langage : coule de source = évolution, perspective différente = nouveau langage.

Raisonnement généralisable à la conception matérielle, au bâtiment, etc..

[maske]

plutôt que de créer un langage nouveau, pourquoi ne pas spécialiser un déjà existant?

C'est une manière classique d'implémenter un DSL. Ça reste un nouveau langage, et ce même sans syntaxe concrète. La raison, c'est ce que Matthieu Vergne résume en deux mots mieux que moi dans mon post au début du thread : une perspective différente. On ne peut pas prendre un langage comme Java et le "spécialiser" : la communauté Java n'en veut pas forcément de cette nouvelle perspective, donc inconcevable de l'intégrer au langage. Donc nouveau langage (GPL ou DSL).

Depuis le début du sujet tout le monde nous bassine avec javascript et des détails techniques sans importance, alors que le point important sur la question c'est cette notion de perspective, cette idée d'aborder un problème sous un autre angle - que ça soit un problème déjà adressé ou non.

Il faut prendre un peu de recul, ou spécifier la question. Par exemple si la question c'est «Est-il nécessaire de créer de nouveaux langages de programmation ?», on ne parle pas forcément d'un «gros» langage adopté par des millions d'utilisateurs. On ne parle pas forcément d'un langage permettant de tout faire - en fait assez marginalement, beaucoup de nouveaux langages sont des langage dédiés. Alors pourquoi développer un langage dédié par exemple ? Une bonne référence est «When and How to Develop Domain-Specific Languages» disponible ici http://people.cis.ksu.edu/~schmidt/5...es/WhenDSL.pdf. Alors après oui, chacun "pense que..."...

[LSMetag]

C'est une manière classique d'implémenter un DSL. Ça reste un nouveau langage, et ce même sans syntaxe concrète. La raison, c'est ce que Matthieu Vergne résume en deux mots mieux que moi dans mon post au début du thread : une perspective différente. On ne peut pas prendre un langage comme Java et le "spécialiser" : la communauté Java n'en veut pas forcément de cette nouvelle perspective, donc inconcevable de l'intégrer au langage. Donc nouveau langage (GPL ou DSL).

Depuis le début du sujet tout le monde nous bassine avec javascript et des détails techniques sans importance, alors que le point important sur la question c'est cette notion de perspective, cette idée d'aborder un problème sous un autre angle - que ça soit un problème déjà adressé ou non.

Il faut prendre un peu de recul, ou spécifier la question. Par exemple si la question c'est «Est-il nécessaire de créer de nouveaux langages de programmation ?», on ne parle pas forcément d'un «gros» langage adopté par des millions d'utilisateurs. On ne parle pas forcément d'un langage permettant de tout faire - en fait assez marginalement, beaucoup de nouveaux langages sont des langage dédiés. Alors pourquoi développer un langage dédié par exemple ? Une bonne référence est «When and How to Develop Domain-Specific Languages» disponible ici http://people.cis.ksu.edu/~schmidt/5...es/WhenDSL.pdf. Alors après oui, chacun "pense que..."...

Après ça je voudrais changer mon vote. C'est possible ?

[hbomb]

j'ai répondu "autres" car je pense qu'il faut continuer à développer de nouveaux langages ET de nouvelles bibliothèques pour l'existant
Par ailleurs, je suis assez d'accord avec les réponses de maske.

il faut voir l'utilisation qu'on fait du nouveau langage ou des nouvelles libs. Si c'est sur un outil de grande ampleur codé dans un langage "ancien", il vaut mieux avoir de nouvelles libs pour ce langage que de devoir reprendre de zéro l'outil. Les coûts de la réécriture ne seraient pas intéressants pour une entreprise qui préfèrera rester avec son outil actuel.

un nouveau langage peut apporter de nouvelles choses qui n'existaient pas dans d'autres langages (ou qui améliorent performance/qualité...) et les libs permettent de palier à moindre coût les "absences" d'un langage. On ne peut pas abandonner les "anciens" langages pour les nouveaux et réécrire à chaque fois tout le code des outils.

il peut être intéressant sur de micro-projets "d'essayer" de nouveaux langages qui répondent aux besoins du projet à condition que cela s'intègre avec le système d'information déjà en place.

Après le risque peut venir de la profusion des langages pour tous les outils d'une entreprise. si chaque outil utilise un langage différent parce que c'est nouveau/à la mode on perdra en qualités (du code et de l'outil), maintenabilité et performances.

[Mouke]

Je pense qu'il parle de TypeScript, CoffeScript ect ... plutot que de Node.js

Exactement, merci.
Non je ne maitrise pas le Js du tout, effectivement, mais force est de constater que les grosses lib' et frameworks se basent sur des surensembles du langage, et non le langage initial. Avec de grosses modifications de syntaxes et tout.
Je prends souvent contre exemple sur Symfony ou Spring : quand on les utilise, on ne modifie pas en profondeur la syntaxe de PHP ou Java. Voilà mon idée de base.

[goldbergg]

Point de vue perso : un langage te donne des briques de base, une biblio te donne des assemblages de briques prêts à être réutilisés. Si pour faire une fonctionnalité, tu vois que peu importe comment tu assembles ces briques données, tu n'arrives pas à avoir un assemblage satisfaisant, alors tu as une bonne raison de faire un nouveau langage (i.e. de nouvelles briques), ou tout au moins de faire évoluer le langage existant. Ce qui permet de choisir entre le nouveau et l'évolution, c'est à quel point les nouvelles briques sont en accord avec les objectifs initiaux du langage : coule de source = évolution, perspective différente = nouveau langage.

Raisonnement généralisable à la conception matérielle, au bâtiment, etc..

coule de source = évolution
perspective différente = nouveau langage ou nouveau compilo.

Un langage peux ne pas répondre à un besoin a cause de la nature de son mode de compilation, mais en changeant justement son mode de compilation il peut s'adapter à de nouveaux besoin.
Ex: C#, qui de base est un langage managé, or depuis peux on peut aussi le compilé en code natif, en perdant bien évidement certain concepts tel que la réflexion, au profit des avantage des langage natif (rapidité, légèreté, etc...)

Je crois bien qu'il n'y a rien des spécificités de JS qui le justifient, surtout au regard des milliers de lignes de transpilateurs pondus pour ne plus avoir à écrire du JS ^^

Ben vue que c'est un peut le sujet "Pourquoi créer un nouveau langage ?", on peut se poser la question pourquoi le JS a été créé?

À la base le JS n'a certainement pas été conçu pour faire du MVC (ou MvvM), ni pour faire des jeux où je ne sais trop quoi qui est possible aujourd'hui, mais principalement pour faire du DOM.
Or dans le DOM il n'y a aucune notion de type, que sa soit via les TextNode, les innerHTML ou les "value" des champ input, tout est en string.

Je ne vois dans les conversions implicites uniquement une simplicité qui facilitait grandement la création du script, surtout pour les débutants qui aurait rapidement été paumé avec les conversion de type.
Donc, vu le besoin initial (un langage simple pour manipuler les pages HTML), je trouve que c'est parfaitement justifié de ne pas avoir imposé les conversion de type explicite!
Et cerise sur le gâteau, pour les besoins plus stricts le "===" a été implémenté ainsi que différente fonctionnalité de conversion de type, tout le monde y trouve son compte.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<html>
    <head></head>
    <body>
        Annee naissance : <input type="string" id="AnneeNaissance" />
        <button onclick="CheckDate();">valider</button>
        <script>
            function CheckDate(){
                //Syntaxe de base du JS qui simplie la vie
                {
                    var val = document.getElementById("AnneeNaissance").value; 
                    var limite = (2016 - 18);//number
                    console.log(typeof(val));//string
                    if (val && val <= limite)//Les check et conversions se font à la volée
                    {
                        console.info("Bienvenue dans la zone interdite !");
                    }
                    else
                    {
                        console.error(":(");
                    }
                }
                //Syntaxe plus strict
                {
                    var val = document.getElementById("AnneeNaissance").value; 
                    if (val === undefined || val === null || val === "") return;
                    var valParse = parseInt(val, 10);
                    if (isNaN(valParse)) return;
                    var limite = (2016 - 18);//number               
                    console.log(typeof(valParse));//number
                    if (valParse <= limite)
                    {
                        console.info("Bienvenue dans la zone interdite !");
                    }
                    else
                    {
                        console.error(":(");
                    }
                }
            }

        </script>
    </body>
</html>

Dans un cadre ou l'on faisait que du DOM, la première syntaxe est quand même plus sympa tout en restant cohérente, surtout pour les gros formulaire.

[maske]

coule de source = évolution
perspective différente = nouveau langage ou nouveau compilo.

Nouveau compilateur = nouvelle implémentation. Pour changer les «perspectives» du langage, il faut en changer les concepts - ou en ajouter. Si ça apporte des nouveaux concepts, alors le langage est nouveau. On pourra parler d'extension ou de nouveau langage (après c'est du marketing).

Un langage peux ne pas répondre à un besoin a cause de la nature de son mode de compilation, mais en changeant justement son mode de compilation il peut s'adapter à de nouveaux besoin.
Ex: C#, qui de base est un langage managé, or depuis peux on peut aussi le compilé en code natif, en perdant bien évidement certain concepts tel que la réflexion, au profit des avantage des langage natif (rapidité, légèreté, etc...)

Implémentation.

[Matthieu Vergne]

Je suis aussi d'accord que changer le compilo ne change rien au langage en lui-même, c'est de l'ordre de son implémentation. En l'occurrence, si tu prends un programme écris dans un langage, si tu changes le compilo, le programme n'en reste pas moins strictement le même. Si a contrario tu en viens à devoir changer le langage (e.g. si tu perds la réflexion, et donc que les fonctionnalités initiales de réflexion ne sont plus compilables) alors tu as changé le langage en même temps que le compilo, mais c'est le changement du langage qui rend le programme inopérant. Le compilo ne fait que suivre les specs du langage (s'il est bien fait). Si tu as un langage mais que ton compilo ne prend pas les concepts que le langage est censé te fournir, alors ton compilo est à côté de la plaque.

Par contre je suis d'accord que la qualité du compilo intervient sur les performances du programme, et donc dans une certaine mesure sur le côté satisfaisant que j’énonçai. Pour reprendre le parallèle avec les briques : le langage te donne la forme des briques (conception), le compilo te donne la qualité des briques (implémentation), la biblio t'offre des assemblages de briques (utilisation prédéfinie).

[imperio]

Il m'a fallu un bon moment pour comprendre que cette "actualité" n'était pas un troll. C'est juste incroyable que des gens puissent se poser une question pareille ! C'est un peu comme si on se demandait "Doit-on arrêter le progrès ?". Si un nouveau langage émerge, qu"il soit révolutionnaire ou non, il apportera forcément quelque chose de nouveau (pas forcément utile), comme une fonctionnalité ou juste une façon de faire différente. Si dans l'immédiat c'est inutile ou alors sans intérêt, il se peut que ça ait des répercussions sur un langage qui émergerait plus tard qui reprendrait des idées ou qui justement ne ferait pas les mêmes erreurs.

En bref et en simple. Un langage mal fait pourra avoir toutes les libs (quelle que soit leur qualité) du monde, ça ne changera pas le fait que le langage est mal fait. Faire de bonnes libs par dessus c'est juste appliquer du scotch. Repartir sur de bonnes bases est bien souvent une meilleure idée quand c'est possible.

Bref, sujet/actu troll pour moi.

[goldbergg]

J'ai l'impression qu'on ne parle pas de la même chose, les framework et les langage sont deux chose différente.
Basiquement, un compilateur sert à convertir un langage source (par exemple le C++) vers un langage cible qui est généralement de plus bas niveaux (par exemple le langage machine).
Dans mon exemple avec le C# on à :
C# => IL
et
C# => Langage machine

Si on écrie un compilo qui permet de convertir un langage A vers un langage B puis un second compilo qui convertie le même langage A vers un langage C qui est radicalement différent du langage B
On a un bien un même langage A qui n'a pas changé (et la je parle bien de la spec, pas d'un code déjà écrie ou des apis utilisé) et qui peut répondre a une "perspective différente".
Par contre les framework autour du langage A ne seront pas forcement les même en fonction du compilo qu'on utilise.

Pour l'exemple que j'ai donnée avec le C#, la réflexion ne fait pas partie du langage, mais du framework .NET qui l'accompagne et c'est se framework qui bouge en fonction de la compilation vers le CLR ou vers le Natif, dans tous les cas le C# reste du C#, mais il ne répond plus aux même besoin, on à bien la fameuse perspective différente. (c'est d'ailleurs l'un objectif de Roslyn)

Prenons l'exemple inverse dans un monde ou Java/C# et autre langage managé n'existe pas.
Je fait du C++, mais malheureusement pour moi j'ai un besoins de faire de la réflexions à un niveaux ou le C++ ne le permet pas.
j'ai deux solutions:
-Créé un nouveaux langage que je nommerais Java ou C# par exemple.
-Rester sur le même langage que j'aime bien et créé un nouveaux compilo qui me générera du code managé, bien évidement mon nouveaux compilo sera accompagné d'une VM et surtout d'un framework pour pouvoir faire de nouvelle chose, mais en aucun cas le langage n'aura changé.

Bon après je suis bien contient que ce genre de logique ne peut s’appliquer à tous les langages.

[maske]

Basiquement, un compilateur sert à convertir un langage source (par exemple le C++) vers un langage cible qui est généralement de plus bas niveaux (par exemple le langage machine).

On est d'accords. Mais le langage est spécifié avant, ensuite on implémente les outils qui permettent de l'utiliser (parseurs, compilateurs, etc.). Pas l'inverse.

Si on écrie un compilo qui permet de convertir un langage A vers un langage B puis un second compilo qui convertie le même langage A vers un langage C qui est radicalement différent du langage B

Oui mais soit tu as déjà des langages A, B et C et un code existant, et pour des raisons techniques tu crée un pipeline de compilation pour arriver vers C et là on est hors sujet : tu n'as pas crée de langage, tu as juste écrit un traducteur sous forme de compilateur. Soit tu as besoin d'une nouvelle perspective, et tu la rend accessible via un nouveau langage A ! Pas C ! L'abstraction est au niveau le plus haut, et c'est ce que je reproche à la majorité des intervenants de la discussion, qui se situent directement très bas au niveau syntaxe. Tu es dans le mauvais sens : ta nouvelle perspective est dans A et c'est pour ça que tu crée A au dessus de B lui même au dessus de C.

On a un bien un même langage A qui n'a pas changé (et la je parle bien de la spec, pas d'un code déjà écrie ou des apis utilisé) et qui peut répondre a une "perspective différente".
Par contre les framework autour du langage A ne seront pas forcement les même en fonction du compilo qu'on utilise.

Non, A est nouveau. B et C n'ont pas changé. Les frameworks viennent ensuite, je ne comprend pas le rapport...

Pour l'exemple que j'ai donnée avec le C#, la réflexion ne fait pas partie du langage, mais du framework .NET qui l'accompagne et c'est se framework qui bouge en fonction de la compilation vers le CLR ou vers le Natif, dans tous les cas le C# reste du C#, mais il ne répond plus aux même besoin, on à bien la fameuse perspective différente. (c'est d'ailleurs l'un objectif de Roslyn)

Je ne connais pas C#, mais la réflexivité ne serait pas au niveau langage ? C'est à dire qu'à moins d'avoir le framework, je n'aurais pas accès à la classe d'un objet par exemple (objet.class ?) ?

Prenons l'exemple inverse dans un monde ou Java/C# et autre langage managé n'existe pas.
Je fait du C++, mais malheureusement pour moi j'ai un besoins de faire de la réflexions à un niveaux ou le C++ ne le permet pas.
j'ai deux solutions:
-Créé un nouveaux langage que je nommerais Java ou C# par exemple.
-Rester sur le même langage que j'aime bien et créé un nouveaux compilo qui me générera du code managé, bien évidement mon nouveaux compilo sera accompagné d'une VM et surtout d'un framework pour pouvoir faire de nouvelle chose, mais en aucun cas le langage n'aura changé.

Pardon pour mon ignorance, qu'est-ce qu'un langage managé ?

Je ne comprend pas la seconde solution. Si tu étends un langage en modifiant son compilateur, ça veut dire que t'as un nouveau langage in fine. D'ailleurs, je ne comprend pas comment tu ferais sans abstractions spécifiques pour adresser de nouveaux problèmes, ça veut juste dire que tu aurais exactement le même langage, mais qui ferait autre chose ?

Troisième solution : le DSL.
Quatrième solution : la bibliothèque. Vous aurez compris que je ne suis pas fan de cette dernière solution mais il est évident que selon le cas l'extension par bibliothèque peut très bien être la meilleure solution.

Bon après je suis bien contient que ce genre de logique ne peut s’appliquer à tous les langages.

À priori si, il existe des extensions pour à peu près tous les langages.

[mangobango]

Ben vue que c'est un peut le sujet "Pourquoi créer un nouveau langage ?", on peut se poser la question pourquoi le JS a été créé?

À la base le JS n'a certainement pas été conçu pour faire du MVC (ou MvvM), ni pour faire des jeux où je ne sais trop quoi qui est possible aujourd'hui, mais principalement pour faire du DOM.
Or dans le DOM il n'y a aucune notion de type, que sa soit via les TextNode, les innerHTML ou les "value" des champ input, tout est en string.

Je ne vois dans les conversions implicites uniquement une simplicité qui facilitait grandement la création du script, surtout pour les débutants qui aurait rapidement été paumé avec les conversion de type.
Donc, vu le besoin initial (un langage simple pour manipuler les pages HTML), je trouve que c'est parfaitement justifié de ne pas avoir imposé les conversion de type explicite!
Et cerise sur le gâteau, pour les besoins plus stricts le "===" a été implémenté ainsi que différente fonctionnalité de conversion de type, tout le monde y trouve son compte.

Vu le point de départ, effectivement on peut comprendre les idiosyncrasies de JS. Après, il a mis bien du temps pour commencer à évoluer et je pense que ça n'a pas arrangé son image. Mais c'est arrivé à d'autres aussi (C++03...). Et d'autres ont évolué, comme Python, mais la moitié de la communauté n'a pas voulu suivre (pour N raisons), même si j'ai l'impression que ça se tasse.

Je ne connais pas C#, mais la réflexivité ne serait pas au niveau langage ? C'est à dire qu'à moins d'avoir le framework, je n'aurais pas accès à la classe d'un objet par exemple (objet.class ?) ?

Il y a des frameworks qui rajoutent une certaine forme de réflexivité à des langages n'en ayant pas. Je pense à Qt (C++) qui va utiliser le Meta Object Compiler pour inclure dans toute classe dérivant de QObject (corrigez-moi si c'est faux) de quoi inspecter et appeler des méthodes. C'est un peu sale à manipuler (en tout cas en Qt 4) parce que ça repose sur de QStrings pour pouvoir nommer la méthode à appeler. Est-ce qu'on a accès à au contructeur? Je ne sais pas (à priori si, je viens de regarder la doc QMetaObject et QMetaMethod). Mais recevant un pointeur sur un QObject, je peux appeler une méthode de la classe dérivée dont le pointeur est l'instance.

Est-ce le même genre de réflexivité qui est implémentée par .Net ?

Daniel

[ouattara_kounadi]

Tant que le "nouveau langage" résout des problèmes rencontrés dans d'autres langages alors on peut le créer je crois...

[LapinGarou]

Peut etre (surement) qu un jour la programmation se fera en langage naturel avec toutes ces innovations dans les langages et technologies