Quels sont les langages de programmation que vous détestez le plus en 2019 ? Pourquoi ? Partagez vos avis

**Sodium** · 25/05/2019, 20h38

Envoyé par Lcf.vs

Déjà rien que par ton exemple, tu illustres à quel point tu ne sais juste pas utiliser les constructeurs primitifs... Depuis quand on utilise un new, pour créer une String ?

Quand on veut être compris par les gens de ce forum qui ne connaissent pas toutes les "subtilités" de JavaScript, qui rappelons-le, est un langage qui n'a pas d'objets car c'est un langage de script qui utilise des prototypes

**air-dex** · 26/05/2019, 01h03

On parle beaucoup de JavaScript, mais perso j'ai envie de voter pour ses petits copains HTML et CSS, surtout le second. Alors oui ce ne sont pas de purs langages de programmation, mais ils pourrissent bien la vie eux aussi. La montée en puissance de JavaScript leur aura permis de se faire une grosse place dans la conception d'interfaces. Pour des pages Web je veux bien parce que c'est la tradition, mais pour des applications ce sont justes deux purges. Le couple se fait rouler dessus par tous les langages de description d'interface de France et de Navarre (à commencer par QML), mais c'est tranquillement en train de s'imposer pour faire des interfaces dans le sillage de JS qui ramène ses "copains de HTML 5".

**foetus** · 26/05/2019, 07h18

Envoyé par air-dex

Le couple se fait rouler dessus par tous les langages de description d'interface de France et de Navarre (à commencer par QML)

C'est vrai

... à part le fait que le couple HTML+CSS+JavaScript est + ou - [très] optimisé et le nombre d'outils de développement est énorme (<- c'est la même chose que JavaScript et c'est pour cela que @Sodium en est malade

)

Parce que lorsque tu vois que dans la documentation QML le nombre de fois qu'on te dit "à ne pas faire, flingue les performances" (par exemple, appel d'une méthode pure JavaScript, inclusion de sources).
Ensuite QML est quand même bien chelou : à quoi sert les états, les transitions concrètement ?

(et en plus la dernière fois que j'y ai touché, Qt Creator ne savait pas les gérer)
Et enfin quel avenir de QML ?

c'est un language qui a 10 ans, qui devenait devenir le moteur 2D de Qt mais rien aux dernières nouvelles.

Et le gros avantage de QML c'est son interaction avec le C++. Apparemment, coder le pont QML <-> C++ c'est chaud

(je me suis arrêté avant).
Mais tu ne feras pas croire que le couple QML+C++ est plus simple que le couple HTML+CSS+JavaScript

Invité · 26/05/2019, 09h19

Envoyé par Sodium

Quand on veut être compris par les gens de ce forum qui ne connaissent pas toutes les "subtilités" de JavaScript, qui rappelons-le, est un langage qui n'a pas d'objets car c'est un langage de script qui utilise des prototypes

En relisant vos échanges, je crois juste que tu n'as pas compris son propos. Il n'a pas dit que JS n'utilisait pas d'objets mais que "la mécanique" qui se cache derrière le mot objet est très différente en JS. Ça, je crois que c'est indéniable et c'est pour ça qu'on ne peut pas vraiment dire que JS est un langage objet "classique", sous-entendu basé sur les classes.
Je n'ai pas une grande expérience du développement et suis encore en formation, mais j'ai passé les trois derniers mois à découvrir JS et à travailler avec. Jusqu'ici, je pratiquais beaucoup le C, Java et PHP. Je crois même pouvoir dire que j'avais une aversion pour JS. Mais en prenant le temps de m'y mettre sérieusement, en potassant un peu le sujet et en faisant preuve d'ouverture d'esprit, j'ai appris à l'apprécier et je dois dire que j'ai beaucoup plus de plaisir à travailler avec JS qu'avec PHP pour le scripting et en tant que langage serveur.

Enfin bref, tout ça pour dire que JS ne peut pas être considéré comme un langage objet conventionnel. Et ce n'est pas le "sucre syntaxique" apporté par ES6 qui change quoi que ce soit.

**Sodium** · 26/05/2019, 09h31

Envoyé par MadiPoupou

En relisant vos échanges, je crois juste que tu n'as pas compris son propos. Il n'a pas dit que JS n'utilisait pas d'objets mais que "la mécanique" qui se cache derrière le mot objet est très différente en JS.

Relis ses interventions, il dit texto "JavaScript n'est pas un langage objet car il utilise des prototypes et pas des objets". C'est comme si je disais "La voiture électrique n'est pas un véhicule parce qu'elle utilise de l'électricité et pas de l'essence". Ben non, électricité et essence on s'en fout, c'est juste la façon dont on fait avancer le truc. Classes et prototypes c'est la même chose.

Envoyé par MadiPoupou

Ça, je crois que c'est indéniable et c'est pour ça qu'on ne peut pas vraiment dire que JS est un langage objet "classique", sous-entendu basé sur les classes.

Ben oui si tu veux... sauf qu'encore une fois ça n'a aucun rapport le débat POO vs Non-POO.

**Paleo** · 26/05/2019, 10h22

Envoyé par Pyramidev

Tu veux dire le retour au Java.
async et await viennent de C# 5.0.
Ils existent aussi en Python depuis Python 3.5.
Ils existent aussi dans d'autres langages. Je ne vais pas tous les citer.
En C++, on ne les a pas encore, mais on aura co_return et co_await en C++20.

Merci pour la mise au point. J'ignorais pour C#, la version 5 date de 2012 et de bonnes API asynchrones existent. Puisque async/await vient de ce langage, c'est un excellent point pour Microsoft. On peut aussi citer Dart et (il me semble car je ne pratique pas) Go qui fournissent un support utilisable.

Sur Python en revanche c'est plus discutable, car si le mécanisme existe effectivement, les API sont quant à elles synchrones alors on continue en pratique à faire des threads. Ce sera probablement la même chose pour C++.

Sur Rust il est un peu tôt pour juger. Java, PHP, C ne proposent rien d'approchant.

Async/await sans des API asynchrones est utile marginalement. Pour ma part, mon langage principal est JavaScript/TypeScript, mais je code également au besoin en Python, C++, PHP et Java et la programmation asynchrone me manque dans ces quatre langages.

Même si le support de async/await par JavaScript est récent, ses API étaient déjà toutes asynchrones et facilement convertibles pour cette fonctionnalité, ce qui fait que depuis quelques années, dans ce langage, la programmation backend (sur le frontend il y en a moins besoin) a changé radicalement.

Envoyé par Sodium

Mais nooooooooooooooooooon, à part ça JavaScript n'est pas du tout orienté objet

Après il faut s'entendre sur ce qu'on appelle la POO.

Envoyé par Sodium

On pourrait débattre longtemps d'à quel point tel ou tel langage est orienté objet ou non et incite à travailler en 100% objet comme smaltalk, mais à partir du moment où il permet de créer et d'utiliser des objets (et maintenant des classes avec héritage dans le cas de JS) et surtout quand toutes ses primitives héritent d'un objet et peuvent être étendues grâce à celui, affirmer qu'il n'est pas orienté objet est un non-sens. D'ailleurs, quand on fait quelque chose comme myString.charat(), la primitive string est temporairement transformée en objet afin d'utiliser les méthodes de celui-ci.

Il y a au moins deux grandes écoles de programmation. La POO focalisée sur des objets d'un côté, la programmation fonctionnelle articulée autour des closures de l'autre. JavaScript permet de marier les deux.

Dans la POO, on peut à nouveau séparer celle "classique" centrée sur les classes, de celle à prototypes centrée sur les objets. Le plus souvent, lorsqu'un programmeur parle de POO, il ne parle que de la première, ce qui engendre des malentendus. Et pour ces deux branches, là encore, JavaScript permet de faire les deux.

JavaScript est un langage influencé par plusieurs écoles, il n'est le meilleur dans aucune mais offre en retour une grande liberté au programmeur.

Le résultat est qu'il est agaçant d'entendre que JavaScript serait (juste) un langage orienté objets. C'est réducteur. Il permet de faire de la POO à classes, mais ce n'est que l'une de ses spécialités, qui plus est récente (avant c'était possible mais désagréable par manque de syntaxe adaptée).

Invité · 26/05/2019, 10h34

Envoyé par Sodium

Relis ses interventions, il dit texto "JavaScript n'est pas un langage objet car il utilise des prototypes et pas des objets". C'est comme si je disais "La voiture électrique n'est pas un véhicule parce qu'elle utilise de l'électricité et pas de l'essence". Ben non, électricité et essence on s'en fout, c'est juste la façon dont on fait avancer le truc. Classes et prototypes c'est la même chose.

Ben oui si tu veux... sauf qu'encore une fois ça n'a aucun rapport le débat POO vs Non-POO.

Je comprends ton point de vue, mais je trouve simplement qu'il mérite d'être un peu nuancé.
Selon moi, une voiture électrique est une voiture, mais une fois que tu ouvres le capot, il n'y a plus rien qui soit comparable avec une voiture à explosion.
On est développeur, notre devoir c'est aussi de savoir comment ça marche au delà de la simple appellation. Oui, JS est un langage qui utilise des objets, mais nous, on ne doit pas se contenter du mot "objet" pour travailler avec un langage de programmation.
Enfin c'est ma conception et peut-être qu'elle n'est pas bonne. Mais si on veut acquérir une certaine expertise, je crois que nous ne pouvons pas nous contenter de dire que classe et prototype, c'est pareil. Ça me paraît trop léger. Mais, encore une fois, ce n'est que mon opinion et nous ne sommes pas obligés d'avoir la même. Cela dit, oui, tu as raison, JS est basé sur des objets et si on ne regarde pas derrière, cette définition peut suffire.

Sinon, pour revenir sur ce qui peut poser problème à JS dans de tels sondages, pour moi c'est assez clair: dans la vie d'un développeur, il est rare qu'un langage soit la seule alternative. Pour faire du développement front, c'est le cas. On te dit JS, et puis c'est tout. L'être humaine n'aime pas qu'on le force à faire quelque chose s'il n'a pas décidé de le faire et, instinctivement, on va chercher à justifier notre aversion naturelle pour ce qui nous est imposé.

**Sodium** · 26/05/2019, 11h01

Envoyé par MadiPoupou

je crois que nous ne pouvons pas nous contenter de dire que classe et prototype, c'est pareil. Ça me paraît trop léger.

Je ne disais pas que les classes et les prototypes sont la même chose, je disais que c'était la même chose que l'analogie que pour les voitures. Les prototypes et classes n'ont rien à faire dans le débat POO ou pas POO, si l'on ne comprend pas ça on n'a pas compris les concepts de base.

Invité · 26/05/2019, 11h08

Envoyé par Sodium

Je ne disais pas que les classes et les prototypes sont la même chose, je disais que c'était la même chose que l'analogie que pour les voitures. Les prototypes et classes n'ont rien à faire dans le débat POO ou pas POO, si l'on ne comprend pas ça on n'a pas compris les concepts de base.

Si tu veux reprendre l'analogie sur les voitures, alors ok. Mais toi tu ne dois pas être juste un conducteur et te contenter de monter dans la voiture, la démarrer et aller au marché avec ta femme et tes enfants. C'est ton client qui fait ça.
Toi tu es développeur et donc le mécanicien.Si tu commences à traiter une voiture électrique comme une voiture à moteur à explosion, tu vas avoir un problème assez rapidement.
Si tu as besoin de t'en convaincre, je t'invite à ce qu'on fasse un concours: je change l'embrayage d'une Renault Zoe pendant que tu changes celui d'une Clio. Le premier qui a terminé a gagné.

**Sodium** · 26/05/2019, 11h23

Ben oui je suis d'accord... mais encore une fois on s'en fout de tout le fond qui va derrière. Je répondais juste à celuii qui clamait haut et fort que "JavaScript c'est pas un langage objet parce que ça utilise pas des classes et t'es trop con de penser le contraire olol" alors qu'il citait lui-même des sources démontrant qu'il avait tort. Enfin plus exactement il a dit "JavaScript utilise des prototypes et pas des objets", mais je vais espérer pour lui que c'était un simple lapsus, d'un autre côté il n'a jamais corrigé son message donc j'ai un doute. C'est juste sur ce point-là que je répondais moi, pas sur la question de la différence entre classes et prototypes, si l'on est mieux que l'autre, etc.

**blbird** · 26/05/2019, 12h00

Envoyé par Sodium

Bla bla habituel

Le JS est un langage de POO sur les concepts de 1975 : des objets, avec des méthodes et des propriétés. Il n'y a pas beaucoup de langages non POO avec cette définition au final.

Mais avec l'évolution de la POO, surtout au début des années 2000, où l'on y inclut aussi maintenant les classes (POO classique), l'encapsulation, l'héritage et le polymorphisme. Mais le JS est très différent (pas d'encapsulation, pas de classe, pas d'héritage classique, orienté prototype), même s'il possède toujours des objets.

Tu continues post après post à comparer des bananes et des fraises, critiquant le fait que ce ne soit pas la même chose, simplement parce que tout les deux sont aussi communément nommés fruits.

Tu passes ton temps à vomir des technologies (SQL, JS, d'autre peut-être?) sans jamais les comprendre correctement. Une fois posté que tu n'aimes pas suffirait pourtant, mais non, il faut continuer, même quand les autres ont démontrés que le problème n'était pas la techno en question, mais ton incapacité à t'y intéresser ou à la comprendre.

**Jamatronic** · 26/05/2019, 12h58

blbird : tu as écrit "Javascript n'est pas un langage objet" puis cité des sources affirmant (à juste titre) le contraire.

Au lieu de juste reconnaître que tu t'es trompé sur ce point, tu préfères faire semblant d'avoir dit autre chose de plus subtil, afin de faire passer Sodium pour plus bête qu'il ne l'est.

Mais cela ne trompe personne.

Javascrit est un fourre-tout monstrueux, réellement multiparadigme, très utilisé et assez intéressant... mais c'est aussi un langage qu'on peut avoir en horreur. Si tu tiens à le défendre, il faut éviter la mauvaise foi, hein.

**Eredin** · 26/05/2019, 15h18

Envoyé par MadiPoupou

Je crois même pouvoir dire que j'avais une aversion pour JS. Mais en prenant le temps de m'y mettre sérieusement, en potassant un peu le sujet et en faisant preuve d'ouverture d'esprit, j'ai appris à l'apprécier et je dois dire que j'ai beaucoup plus de plaisir à travailler avec JS qu'avec PHP pour le scripting et en tant que langage serveur.

C'est le cas de bon nombre de personnes qui décident d'apprendre sérieusement ce langage et l'écosystème qui l'entoure, en faisant table rase de ce qu'ils connaissent déjà.

Ce qui dessert JavaScript (mis à part les erreurs de conception de base), et fait aussi sa force, c'est que ce langage évolue à une vitesse incroyable. Le truc, c'est qu'en faisant quelques recherches, on se rend compte que beaucoup de tutoriels sur le JS sont complètement dépassés (je peux me tromper, mais j'ai l'impression que c'est encore plus vrai dans la communauté francophone), sans même compter les innombrables cours produits par des amateurs qui sont à la ramasse et amènent d'avantage de confusion.

Pour ceux qui voudrait débuter dans le JS moderne, je recommande fortement la série You don't know JS de Kyle Simpson (à lire de bout en bout) (et JavaScript Allongé de Reg Braithwaite, mais ça c'est bonus

), et de ne consulter aucune ressource antérieure à 2016, ou non validé par des experts reconnus dans ce langage. Il faut aussi comprendre que JavaScript n'est plus un simple langage, mais un langage + un écosystème. En 2019, développer en JavaScript, c'est utiliser une panoplie d'outils : babel, webpack, ESLint, node.js, flow, typescript etc. dont on peut difficilement faire l'économie et qui sont pour la plupart relativement nouveaux et ont radicalement transformé l'expérience de développement sur ce langage.

**Sodium** · 26/05/2019, 15h26

On lit souvent ça mais je ne vois pas en quoi JavaScript évolue particulièrement vite. Déjà il ne peut pas se le permettre car il est encore et toujours limité par le fait qu'il soit dépendant du client. Le langage a plus de 20 ans, encore heureux qu'il ait évolué un minimum. Les librairies qui réparent ses faiblesses évoluent très vite effectivement, d'ailleurs trop vite puisque lorsque l'on se forme sur une techno JavaScript on ne sait pas si elle sera encore là ans deux ans.

**Eredin** · 26/05/2019, 16h06

Envoyé par Sodium

On lit souvent ça mais je ne vois pas en quoi JavaScript évolue particulièrement vite.

Pourtant, tu l'as toi-même dit je crois, je ne me souviens plus exactement des termes, mais dans les grosses lignes, JavaScript a commencé comme un langage joujou dans le navigateur. Tu concèderas que nous ne sommes plus exactement dans la même configuration en 2019.

Forcément, si tu le compares à ton langage préféré, tu trouveras qu'il n'est pas à la hauteur, c'est ton droit et je ne suis pas là pour débattre sur la supériorité de certains langages. Je met simplement en garde les lecteurs sur l'évolution de JavaScript afin que s'ils décident de développer dans ce langage, ils le fassent en étant conscient des changements opérés par ce langage ces dernières années et sur lesquels beaucoup de bouquins et ressources sont tout simplement inactuels et à jeter à la poubelle. C'est important parce qu'au vu de l'historique de JavaScript, un biais de confirmation peut se créer dans l'esprit de certaines personnes: "Je lis que JavaScript est un langage détesté" -> "Essayons d'en savoir plus, lisons un tutoriel JavaScript (made in 2004)" -> "Effectivement, c'est de la merde JavaScript !".

**Pyramidev** · 26/05/2019, 16h18

Envoyé par Sodium

Déjà il ne peut pas se le permettre car il est encore et toujours limité par le fait qu'il soit dépendant du client.

Les développeurs JavaScript utilisent des outils comme Babel pour transpiler du code écrit dans une version récente de JavaScript vers une ancienne version de JavaScript supportée par les navigateurs.

**Sodium** · 26/05/2019, 16h21

Envoyé par Eredin

Pourtant, tu l'as toi-même dit je crois, je ne me souviens plus exactement des termes, mais dans les grosses lignes, JavaScript a commencé comme un langage joujou dans le navigateur. Tu concèderas que nous ne sommes plus exactement dans la même configuration en 2019.

Mais encore heureux qu'il ait évolué, mais il n'y a rien de particulièrement foufou qui soit apparu à toute vitesse, il a surtout comblé peu à peu de très gros manques. Maintenant il supporte les classes et l'héritage, mais pas les paramètres typés ni la déclaration de propriétés en dehors des méthodes d'une classe. Pourquoi ? Pour en garder sous le coude pour les versions suivantes histoire que l'on ne les accuse pas de ne plus rien ajouter, un peu comme Steinberg rajoute des demi-fonctionnalités tous les ans pour les implémenter correctement dans la version suivante et donc vendre l'upgrade de son logiciel Cubase ? À côté de ça Microsoft a en très peu de temps corrigé presque tous les manques de JavaScript et il est un bonheur à utiliser dans un IDE sans rajouter 50 couches par dessus à l'avenir incertain.

Si quelqu'un a une liste exhautive de toutes les évolutions de JavaScript depuis sa création ça m'intéresse, je n'ai rien trouvé de très concret.

Envoyé par Pyramidev

Les développeurs JavaScript utilisent des outils comme Babel pour transpiler du code écrit dans une version récente de JavaScript vers une ancienne version de JavaScript supportée par les navigateurs.

Oui mais ça reste de la rustine bas de gamme. L'équipe derrière JavaScript aurait du donner un sacré coup d'accélérateur il y a 5 ans pour que tous les navigateurs actuels soient compatibles.

**air-dex** · 26/05/2019, 16h30

Envoyé par foetus

C'est vrai

... à part le fait que le couple HTML+CSS+JavaScript est + ou - [très] optimisé et le nombre d'outils de développement est énorme (<- c'est la même chose que JavaScript et c'est pour cela que @Sodium en est malade

)

HTML/CSS n'est juste pas naturel et intuitif du tout pour faire des interfaces si t'as un passé plus applicatif (GTK, Qt, Swing...), en bref si t'as déjà fait des interfaces avant HTML et CSS. On dirait JS avec son prototypage au milieu du monde objet (avant ECMAScript 2015 bien entendu).

Envoyé par foetus

Ensuite QML est quand même bien chelou : à quoi sert les états, les transitions concrètement ?

(et en plus la dernière fois que j'y ai touché, Qt Creator ne savait pas les gérer)

Les transitions sont des animations (genre fondu enchaîné).
Les états sont la même chose qu'ailleurs.

Code QML :

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
// Feu qui change de couleur
Rectangle {
    property color col_feu: "red"
 
    Text {
        id: t
        anchors.fill: parent
    }
 
    states: [
        State {
            name: "feu rouge"
            when: col_feu === "red"
            PropertyChanges {
                target: t
                text: qsTr("Le feu est rouge")
            }
        },
        State {
            name: "feu vert"
            when: col_feu === "green"
            PropertyChanges {
                target: t
                text: qsTr("Le feu est vert")
            }
        }
    ]
}

Après c'est sûr que si tu n'y as plus touché depuis que c'était en bêta...

Là je ne peux rien pour toi.

Envoyé par foetus

Et enfin quel avenir de QML ?

c'est un language qui a 10 ans, qui devenait devenir le moteur 2D de Qt mais rien aux dernières nouvelles.

L'éternel problèmes des technologies de Qt, que tu peux utiliser sans utiliser Qt, qui valent largement ce qui se fait en dehors, mais qui par réputation (erronnée) ne sont guère utilisées au delà de Qt.

Envoyé par foetus

Et le gros avantage de QML c'est son interaction avec le C++. Apparemment, coder le pont QML <-> C++ c'est chaud

(je me suis arrêté avant).
Mais tu ne feras pas croire que le couple QML+C++ est plus simple que le couple HTML+CSS+JavaScript

Au contraire c'est très simple. Tout passe par les meta-objects :

Une classe C++ héritant de QObject avec un constructeur par défaut.
T'exposes les méthodes que tu veux exposer à QML en leur donnant l'attribut Q_INVOKABLE.
T'exposes les attributs que tu veux exposer via des propriétés Qt (Q_PROPERTY).
Si tu veux utiliser une énumération tu l'englobes dans une classe et tu la déclares avec Q_ENUM.
T'appelles qmlRegisterType(); dans le main() pour pouvoir l'utiliser côté QML.
C'est bon.

Après il ne reste plus qu'à connaître les correspondances de type entre QML et C++.

Code C++ :

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
#include <QQmlEngine>
#include <QObject>
 
class Foetus: public QObject
{
    Q_OBJECT
 
    public:
        enum PositionTete {HAUT, BAS}
        Q_ENUM(PositionTete)
 
        Foetus() : QObject(), nb_semaines(0), name(""), position(PositionTete::BAS) {}
 
        Q_INVOKABLE bool need_cesarienne() const {
            return this->position == PositionTete::HAUT;
        }
 
    protected:
        PositionTete position;
 
        Q_PROPERTY(int nb_semaines READ getNbSemaines WRITE setNbSemaines NOTIFY nbSemainesChanged)
 
        int nb_semaines;
 
        int getNbSemaines() const {return this->nb_semaines; }
 
        void setNbSemaines(int value) {
            this->nb_semaines = value;
            emit nbSemainesChanged();
        }
 
        Q_PROPERTY(QString name READ getName WRITE setName NOTIFY nameChanged)
 
        QString name;
 
        QString getName const {return this->name; }
 
        void setName (QString value) {
            this->name = value;
            emit nameChanged();
        }
 
    signals:
        void nbSemainesChanged();
        void nameChanged();
};
 
int main(int argc, char ** argv) {
    QApplication app(argc, argv);
 
    qmlRegisterType<Foetus>("Ventre.TaMaman", 13, 37, "Foetus");
 
    //...
 
    int res = app.exec();
 
    // ...
 
    return res;
}

Code QML :

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
import QtQuick 2.12
import Ventre.TaMaman 13.37
 
Item {
    id: my_item
 
    Foetus {
        id: f
        nb_semaines: 25
        name: "Jean-Marc"
    }
 
    Text {
        anchors.fill: parent
        text: qsTr("Je m'appelle %1 et je suis un foetus de %L2 semaines. Aurais-je besoin d'une césarienne pour sortir ? %3.")
                .arg(f.name)
                .arg(f.nb_semaines)
                .arg(f.need_cesarienne() ? "Oui" : "Non")
    }
}

En effet c'est grave chaud, même pour un développeur senior !

**Eredin** · 26/05/2019, 17h09

Envoyé par Sodium

Mais encore heureux qu'il ait évolué, mais il n'y a rien de particulièrement foufou qui soit apparu à toute vitesse, il a surtout comblé peu à peu de très gros manques. Maintenant il supporte les classes et l'héritage, mais pas les paramètres typés ni la déclaration de propriétés en dehors des méthodes d'une classe. Pourquoi ? Pour en garder sous le coude pour les versions suivantes histoire que l'on ne les accuse pas de ne plus rien ajouter, un peu comme Steinberg rajoute des demi-fonctionnalités tous les ans pour les implémenter correctement dans la version suivante et donc vendre l'upgrade de son logiciel Cubase ? À côté de ça Microsoft a en très peu de temps corrigé presque tous les manques de JavaScript et il est un bonheur à utiliser dans un IDE sans rajouter 50 couches par dessus à l'avenir incertain.

TS fait partie de l'écosystème JS, tout comme Babel qui transpile tout ce que tu veux ou presque vers du code compatible avec n'importe quel environnement ou presque.

Plus personne ne code en ES5(2009!) en 2019. Dans l'univers JS, tu as le choix de faire du TypeScript, de l'ES2018, etc. Mon CV ne porte pas la mention "Développeur TypeScript" ou "Développeur JSX". Tout cela, c'est juste du JS moderne. Et si ma Team de dev veut utiliser Flow par exemple, il serait ridicule de jouer les puristes en mode "Je fais du JS, pas de typage statique chez moi". C'est pour cela que j'ai parlé d'écosystème JS, au-delà du langage. Après, on peut séparer le JS de base de tout le reste qui l'enrichit aujourd'hui pour l'essentialiser (et avoir une bonne excuse de le détester

), mais dans la réalité du quotidien du développeur JS moyen de 2019, il y a une perméabilité de ces différentes technologies, c'est juste une corde de plus à son arc.

Oui mais ça reste de la rustine bas de gamme.

(en parlant de Babel)

Pour une rustine bas de gamme utilisée par des milliards d'utilisateurs dans le monde, c'est pas si mal

(Oui, je fais référence à facebook.com)

**Sodium** · 26/05/2019, 17h23

Donc ton argument c'est "JavaScript c'est bien parce que c'est tellement nul que plus personne ne sérieux ne développe sans un certain nombre de couches entre son code et le résultat final" ?

"Regardez ma maison elle est super bien, y a des bols pour recueillir les fuites d'eau et des planches en bois pour pallier à l'absence de fenêtres."