LCC 290 - Mettre tes lunettes dans ta base de données

31 views

Skip to first unread message

Emmanuel Bernard

unread,

Jan 14, 2023, 8:04:01 AM1/14/23

to lescast...@googlegroups.com

Guillaume et Arnaud discutent de tech en cette nouvelle année 2023.

GraalVM dans OpenJDK, Rust, Webassembly, containers. postgres, ChatGPT, le rôle de l'architecte et la ribambelle de rétrospective 2022.

https://lescastcodeurs.com/2023/01/14/lcc-290-mettre-tes-lunettes-dans-ta-base-de-donnees/

Emmanuel

Cédric Champeau

unread,

Jan 16, 2023, 3:40:48 AM1/16/23

to lescastcodeurs

Merci pour la mention de mon blog. Pour info, il y a une version en français ici : https://melix.github.io/blog/2022/12/astrophoto-2022-fr.html

Par ailleurs, il y a un compte Mastodon pour les LCC ? Perso, Twitter je n'y suis plus perso, et il commence à y avoir plein de trucs cassés. Par exemple, je ne reçois plus les notifs sur Android (sauf un RT d'un tweet datant d'il y a plus de 10 ans, de tps en tps...).

Guillaume Laforge

unread,

Jan 16, 2023, 3:45:16 AM1/16/23

to lescast...@googlegroups.com

Merci pour le lien en français !

Effectivement, pas encore de compte Mastodon pour les LCC.

Mais oui, pourquoi pas, il va falloir qu'on y réfléchisse !

Guillaume

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/21153249-75bc-4a60-aaac-93639b9c86ddn%40googlegroups.com.

Guillaume Laforge
Apache Groovy committer

Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/

Twitter: @glaforge

Frédéric Camblor

unread,

Jan 18, 2023, 8:26:34 AM1/18/23

to lescast...@googlegroups.com

Hello,

Ceux qui me connaissent bien savent combien j'aime Typescript (je suis donc sûrement biaisé) : je n'avais pas eu connaissance de l'article mentionné pendant l'épisode sur le sujet et y ai jeté un oeil.

J'avoue être un peu tombé de ma chaise et je suis loin d'être d'accord avec la plupart des points : j'ai donc revêtu ma cape de "quelqu'un a tord sur internet" :-)

Quelques opinions (perso) sur le sujet :

Learning Curve : Personnellement, je trouve que l'apprentissage s'est fait relativement en douceur : quand on débute on n'est pas _obligé_ de tout typer (merci le type any) et ça permet notamment de mettre en place Typescript sur une codebase existante de manière progressive/incrémentale.

À titre perso, ce n'est par exemple que très récemment que j'ai compris des concepts assez avancés (comme le fonctionnement de infer) alors que je fais du Typescript au quotidien depuis plus de 7 ans maintenant.
Strict Type checking system : J'ai beaucoup de mal avec le raccourci montrant que s'il est possible de faire des choses compliquées avec un outil, c'est que cet outil est compliqué à utiliser au quotidien.

Le type BubbleSort utilisé permet de montrer quelque chose de très puissant (à ce jour, je n'ai jamais rencontré de langage qui permettait d'aller aussi loin dans la description d'un type) mais je ne pense pas qu'un tel niveau de complexité soit _souvent_ utilisé dans une codebase (ou alors le niveau de maturité TS des contributeurs à ladite codebase devra être élevé, là je suis d'accord).
C'est un peu comme quand on utilise une lib : en général, cette dernière masque une complexité de manière à la rendre simple/compréhensible par les consommateurs. Si vous souhaitez comprendre ce qu'il y a derrière cette lib, libre à vous d'aller consulter le code qu'il y a derrière, mais le "commun des mortels" s'arrêtera à son API et c'est très bien comme ça.
Verbosity and Lack of Readability : Cette partie est très subjective je trouve (comparaison de la syntaxe entre JSDoc et Typescript ... Really ? moi perso je trouve la JSDoc plus verbeuse).

Ce que je vois surtout, c'est que la jsdoc ne permet pas de "forcer" le typage au moment où on écrit le code (à moins d'utiliser une règle de linter qui l'enforce, mais dans ce cas je vois encore moins l'intérêt).
Ce qui m'embête là-dedans, c'est l'aspect "non contaminant" des types, qui ne va pas encourager le/la développeur(se) à typer sa codebase => les types resteront très marginaux (et leur intérêt du coup très limité)
Lack of intuitive syntax : J'ai du mal à saisir l'argument ici. L'exemple du typage obligatoire des variables, je ne le comprends pas car la plupart du temps le type d'une variable est inféré.
Pour les paramètres de fonction, oui en général c'est à positionner mais :

On peut positionner un type "any" sur le paramètre si on a vraiment la flemme
On peut aussi positionner un noImplicitAny=false dans le tsconfig si on a un très gros niveau de flemme (je ne l'encourage pas)
Est-ce vraiment une si mauvaise chose de typer le contrat (entrées/sortie) d'une fonction ?

Lack of Compatibility : Je suis en partie d'accord avec le contenu (utiliser Typescript, c'est rajouter une couche d'outillage supplémentaire) mais le titre me paraît un peu trompeur et surtout, jusqu'à maintenant, je n'ai pas connu un seul moment où ça a été compliqué de rajouter une étape de compilation typescript dans mon build ("au pire", utiliser le compilateur typescript tsc en direct permet de résoudre la plupart des problèmes de build .. en tous cas ça a été le cas pour mes usages).
Low Productivity : Je suis d'accord sur l'overhead. Moi à titre perso, je suis prêt à payer ce prix car ça m'a toujours aidé :

À mieux comprendre mon propre code quand je revenais dessus quelques temps après (après un "flush" de ma mémoire sur l'endroit du code concerné)
À m'aider grâce à la complétion de code dans mon IDE, qui va également détecter les typos que je peux faire
Un autre point non négligeable : avec les types, je suis capable de mettre des garde fou sur des portions du code où j'aimerais rendre (sciemment) difficile le fait de tordre le système (que ce soit par un collègue, ou par mon "futur moi" qui interviendra sur le code dans 6 mois quand je n'aurai plus tout le contexte en tête)

Après, je comprends que dans un Hackathon on veuille prendre des raccourcis, et c'est totalement OK (l'espace temps d'un hackathon est très court, mais je ne pense pas qu'il faille utiliser cet argument et le généraliser à toutes les applications, particulièrement celles à longue durée de vie)

False Promises : Sûrement l'un des points avec lequel je suis le plus d'accord. Cette dualité compile-time vs run-time est sûrement l'un des premiers murs qu'on se prend avec Typescript lorsqu'on vient d'un langage typé au runtime (comme Java).

Il faut être conscient de cette dualité, et accepter le fait que ce n'est pas parce qu'on a décrit qu'une variable était d'un certain type dans le code source, que cette contrainte sera vérifiée à tout moment au runtime : ce n'est pas le cas.

Après, il existe des librairies comme zod qui permettent de rajouter des couches de validation (à la bean validation) de manière à garantir qu'une instance reflète bien un type au runtime à partir d'un certain moment (c'est très utile, comme bean validation, sur toutes les couches qui communiquent avec "l'extérieur" comme les controllers HTTP ou les Entités qui sont mappées sur votre DB)

Enfin, je finirai par dire que l'objectif de typescript, c'est d'être un "static typechecker" pour du code JS, pas de résoudre tous les problèmes de JS.
Lack of Flexibility : J'ai pas du tout compris là où il voulait en venir. En tous cas le jugement de valeur sur le dernier paragraphe m'a énervé :-)
Giant Corposation Abuse : J'ai un peu du mal à voir où est le mal à avoir une grosse société derrière un langage.
Ceux qui suivent cet argument et qui font du Java, du Kotlin ou du Go devraient du coup se poser la même question :)
(je ne dis pas que c'est bien ou mal, il faut juste être conscient de cette gouvernance qui d'un côté peut apporter une dynamique dans les évolutions du langage, mais de l'autre peut restreindre sa roadmap à uniquement ce qui intéresse le vendor en question)

À titre perso, je n'aime pas l'argument visant à dire "mauvais un jour, mauvais pour toujours". MS va dans la bonne direction avec son ouverture sur le langage, et j'ai l'impression qu'Oracle (par exemple) aurait des choses à apprendre de cette ouverture.
Clever Devs Abuse : Beaucoup de jugements de valeurs dans cette section, je n'adhère pas beaucoup.
Il fait pas bon d'être un "clever developer" par les temps qui courrent on dirait... (et il semblerait qu'il n'existe pas de "clever developer" qui fasse du JS ?)
Not a JS Superset : C'est vrai que si on renomme un fichier JS en TS puis qu'on essaie de le transpiler, on aura sûrement plein d'erreurs remontées par le type checker (comme c'est le cas dans l'exemple).
En revanche, le transpiler ressortira la même sortie que ce qu'on lui a donné en entrée : ce n'est pas parce que le type checker va râler qu'on n'aura pas d'output qui sera valide (en JS).
C'est dans ce sens, je pense, qu'on a souvent (et je pense que j'ai sûrement dû le dire dans mes talks sur TS) l'habitude de dire que TS est un superset à JS.
Slower compile time : C'est évidemment valide, et le prix à payer pour avoir du type checking.
Additional transpilation step : Par curiosité, j'aurais bien aimé avoir des exemples de transpilation qui change des noms des variables.
Les moments où le code généré peut en effet être compliqué à relire, c'est sur des features non disponibles dans la cible de compilation (par exemple, usage de async/await, ou de generators, vers du ES5 et inférieur)
Mais je trouve que c'est justement une des forces de la transpilation d'être en mesure de pouvoir générer du code compatible avec des runtime JS plus anciens (même si cette fonctionnalité a de moins en moins d'intérêt maintenant que la plupart des navigateurs sont evergreen)
Lack of Performance : J'ai pas compris ... en quoi écrire du TS (transpilé en JS) rend mon code moins performant ? J'aurais bien aimé comprendre car ça me paraît un argument fallacieux.
Writing Unit Tests : Moi, je suis plutôt content quand, lorsque je fais un refacto dans mon code, je sache qu'il faut impacter ce refactoring également dans mes tests (quand ça n'est pas mon IDE ne m'aide pas déjà à répercuter mon refacto dans ces derniers automatiquement)
Types are not that useful : J'ai du mal à voir ici un nouvel argument par rapport aux différentes sections vues précédemment.
Oui, l'inférence de type Typescript n'est pas parfaite, mais elle fait déjà le job pour la plupart des cas de figure : elle me paraît par exemple bien meilleure que celle de Java (même si le cas énoncé ne sera pas problématique en Java) notamment au niveau du control flow (le fait que les tests des if aient un impact sur le bloc du if/else ... un peu comme ce qui est en train d'arriver avec les instanceof dans les dernières versions de Java)
Heavier Tech Debt : Au final, l'output reste du JS, relativement similaire au code d'origine (si on met de coté les quelques problèmes évoqués en 13 qui arrivent lorsqu'on fait de la transpilation vers de "vieilles" cibles de compilation).

Je pense d'ailleurs que c'est un peu l'idée qu'a Microsoft quand ils poussent pour que les ":" soient ignorés par le runtime JS : ça permettrait d'avoir des fichiers typescript qui soient "lisibles" "as is" par le runtime JS dès lors qu'on n'utilise pas de mot-clef spécifiques à typescript dedans ("type", "interface", "enum", "namespace", "abstract", "private", "protected" et "public").
On pourrait imaginer, par exemple, n'avoir recours à ces derniers que dans les fichiers d.ts qui ne seraient utilisés que par le type checker ... on pourrait alors totalement s'abstraire de la phase de transpilation qui génère l'overhead évoquée au point 12.

Donc si un jour Typescript n'a plus la cote, il sera toujours possible de prendre le code JS généré et de le porter vers un autre langage.
Je ne vois pas en quoi il y aurait un quelconque "locking" ici.

Et je trouve cela assez amusant de voir que juste après ce paragraphe, l'auteur propose des "alternatives" à Typescript qui sont toutes sujettes au même problème : que se passe-t-il si demain on abandonne JSDoc, Flow et consors ?

Pour celles et ceux désireux(ses) d'aller plus loin dans Typescript, je ne peux que vous conseiller le site https://type-level-typescript.com/ écrit par Gabriel Vergnaud (un frenchie chez Datadog) qui est super didactique sur le sujet.

Frédéric Camblor

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAJ2HCd9W3%2B%3DOf_Mjcq04dOFddzf%3DA9A4bh9TQgmd_%2BavzyDqkA%40mail.gmail.com.

Remi Forax

unread,

Jan 18, 2023, 10:29:42 AM1/18/23

to lescastcodeurs

Je suis assez d'accord avec tout ce que tu as écrits,

- à part sur la notion de Clever Dev, c'est un vrai problème (cf plus bas).

- à part que je trouve que Microsoft fait de l'open source comme Google fait de l'open source, tu peux contribuer au code source mais pas à la gouvernance.

Pour moi, le prinicpale problème attribué à TypeScript est que cela force à voir TypeScript/JavaScript comme un vrai langage.

On peut pas se contenter de faire de l'angular (exemple de framework choisi presque au hazard) sans savoir comment JS marche au dessus, puis comment TS marche par dessus.

Donc râler sur TypeScript est plutôt un symptome d'une mauvaise compréhension de qui fait quoi, comment cela marche, ah bon c'est pas magique, coté front.

Cela dit, il y a aussi certain problèmes que je vois avec mes étudiants qui utilisent TypeScript.

1) Le système de typage est complexe, c'est normal, l'idée est de typé du JavaScript après coup.

Cela pose un vrai problème si tu as un bon étudiants qui se fait plaisir (CleverDev) car les autres de son équipe arrivent pas à comprendre les types écrits.

Microsoft devrais définir des profiles différents quand tu veux typé une appli que tu es entrain d'écrire où tu as pas besoin de toutes la puissance de TS et

quand tu veux typés une librarie/module où là tu veux tous les outils à ta disposition.

2) Tu as pas de système d'assertion des types à l'exécution (cela rejoint FalsePromise).

Au moins pour les tests du devrais avoir une vérification des types (simples) à runtime. Peut-être sous forme de plugin ?

3) Le problème des fichiers d.ts. Si une lib utilise des fichiers d.ts, cela veut souvent dire que TypeScript est un "second class citizen".

Dans le meilleur des cas, les exemples/doc de la lib utilise JavaScript et tu es obligé de lire les fichier d.ts pour comprendre le typage.

Dans le pire, tu as une de-synchro entre les fichiers .js et les d.ts correspondant.

(Une partie du problème vient du fait que les étudiants utlisent une lib sans se poser de questions sur la qualité de la lib).

4) Certains messages d'erreurs sont pas compréhensible sans un tableau blanc et du temps devant toi.

Cela vient du fait que le système de type est structurelle mais Microsoft devrait payer des personnes à plein temps pour bosser sur le report des erreurs,

trop souvent l'information pertinante est noyée au milieu de types qui sont pas intéressant pour comprendre l'erreur.

5) Les versions de TypeScript sont pas compatibles entre elle ET certaines libs demandent des versions différentes de TypeScript.

Microsoft est vraiment mauvais là dessus, tu devrais pas avoir de problème de compatibilité sur des versions mineurs de TypeScript.

Il devrait aussi y avoir une notion de LTS.

6) TypeScript fait pas que du typage, tu as des features de TS genre enums ou decorateurs qui n'ont pas d'équivalent en JS.

Cela veut dire que, si dans le future, JS ajoute ces features cela va être le bazard (même problème que actuellement les modules en JS).

7) le fichier tsconfig est trop facilement éditable, c'est pas rare d'avoir une PR qui change les options de config (genre noImplicitAny) car tsc "ne marche pas".

Cela rejoint le point (1).

Frédéric Camblor

Rémi

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CADH39npg5%3DAZSxp8D2%2BWyWnaSiWzPER%2BkDiT3Xv_AFJZKD8dJA%40mail.gmail.com.

Frédéric Camblor

unread,

Jan 18, 2023, 1:42:51 PM1/18/23

to lescast...@googlegroups.com

Hello Rémi (et bonne année :))

Mes commentaires inline ! :)

On Wed, Jan 18, 2023 at 4:29 PM Remi Forax <fo...@univ-mlv.fr> wrote:

Je suis assez d'accord avec tout ce que tu as écrits,
- à part sur la notion de Clever Dev, c'est un vrai problème (cf plus bas).
- à part que je trouve que Microsoft fait de l'open source comme Google fait de l'open source, tu peux contribuer au code source mais pas à la gouvernance.

Tu as raison, le modèle de Typescript est un modèle à la Google avec peu de PR "externes" qui sont finalement acceptées j'ai l'impression (les quelques PRs que j'ai pu faire en tous les cas, ont toutes été fermées)

Ça ne me pose pas plus de soucis que ça tant que le projette avance et ne végète pas, l'avantage étant qu'on peut forker à tout moment si on n'est pas content d'un truc (c'est ce que j'ai fait sur les PR non mergées et dont j'avais besoin sur l'un de mes projets).

Pour moi, le prinicpale problème attribué à TypeScript est que cela force à voir TypeScript/JavaScript comme un vrai langage.
On peut pas se contenter de faire de l'angular (exemple de framework choisi presque au hazard) sans savoir comment JS marche au dessus, puis comment TS marche par dessus.
Donc râler sur TypeScript est plutôt un symptome d'une mauvaise compréhension de qui fait quoi, comment cela marche, ah bon c'est pas magique, coté front.

Je plussoie.

Quand je regarde mes collègues qui n'ont jamais fait de Typescript autrement que via Angular, j'ai l'impression qu'on ne parle pas du même langage.

L'aspect "Framework" les rend fainéants à l'apprentissage du langage, c'est assez flagrant (et un peu triste aussi) combien les "exemples angular" ne les font pas se poser plus de questions que ça sur les features du langage :)

Cela dit, il y a aussi certain problèmes que je vois avec mes étudiants qui utilisent TypeScript.

1) Le système de typage est complexe, c'est normal, l'idée est de typé du JavaScript après coup.
    Cela pose un vrai problème si tu as un bon étudiants qui se fait plaisir (CleverDev) car les autres de son équipe arrivent pas à comprendre les types écrits.
    Microsoft devrais définir des profiles différents quand tu veux typé une appli que tu es entrain d'écrire où tu as pas besoin de toutes la puissance de TS et
    quand tu veux typés une librarie/module où là tu veux tous les outils à ta disposition.

Je suis assez mitigé, il y a toujours des gens qui approfondissent les sujets et pas d'autres.

Ça me paraît dommage de limiter un langage du fait de son usage par les utilisateurs : est-ce qu'à la sortie de Java 5 on a dit que les Generics ne devaient être utilisés que par une élite ?

A-t-on eu tort de ne pas le dire ?

Est-ce que justement, de ne pas avoir fait ce type de ségrégation n'a pas démocratisé leur usage au cours du temps ? (aujourd'hui, pour moi, les Generics sont utilisés / utilisables par beaucoup plus de monde qu'en 2004)

C'est un peu pareil pour moi..

2) Tu as pas de système d'assertion des types à l'exécution (cela rejoint FalsePromise).
Au moins pour les tests du devrais avoir une vérification des types (simples) à runtime. Peut-être sous forme de plugin ?

Tu as des choses comme reflect-metadata qui te permettent d'utilisation un équivalent de la reflection au runtime.

Ça reste cependant pas mal de "magie noire" qui rajoute un overhead non négligeable dans le code JS généré.

Je désespère de voir un jour un plugin du compilateur TS arriver et permettant de manipuler l'AST (cette issue notamment)

Au niveau des tests, tu as aussi la possibilité d'utiliser des libs pour tester tes types (cf cet article)

Même si ça me paraît aller un cran trop loin, ça peut parfois être utile.

3) Le problème des fichiers d.ts. Si une lib utilise des fichiers d.ts, cela veut souvent dire que TypeScript est un "second class citizen".
    Dans le meilleur des cas, les exemples/doc de la lib utilise JavaScript et tu es obligé de lire les fichier d.ts pour comprendre le typage.
    Dans le pire, tu as une de-synchro entre les fichiers .js et les d.ts correspondant.
    (Une partie du problème vient du fait que les étudiants utlisent une lib sans se poser de questions sur la qualité de la lib).

Les d.ts, c'est le problème de l'oeuf et de la poule : tant que TS n'est pas considéré par l'écosystème comme ce "first class citizen", les gens l'utilisent pas de facto.

Aujourd'hui, j'ai quand même l'impression qu'on a de moins en moins ce soucis et que c'est devenu mainstream (68% d'adoption de TS dans le state of JS 2022)

4) Certains messages d'erreurs sont pas compréhensible sans un tableau blanc et du temps devant toi.
Cela vient du fait que le système de type est structurelle mais Microsoft devrait payer des personnes à plein temps pour bosser sur le report des erreurs,
trop souvent l'information pertinante est noyée au milieu de types qui sont pas intéressant pour comprendre l'erreur.

100% d'accord avec toi ... les erreurs restent assez cryptiques ... c'est un peu comme les stacktraces Spring, on met du temps avant de comprendre qu'il faut partir de la fin pour comprendre le problème :-)

5) Les versions de TypeScript sont pas compatibles entre elle ET certaines libs demandent des versions différentes de TypeScript.
    Microsoft est vraiment mauvais là dessus, tu devrais pas avoir de problème de compatibilité sur des versions mineurs de TypeScript.
    Il devrait aussi y avoir une notion de LTS.

Je suis d'accord avec toi : pour moi, on a un gros trou dans la raquette quand il s'agit d'exprimer la version minimum/maximum de Typescript qui est requise pour que le code de la lib qu'on importe fonctionne.

C'est mis au second plan car au runtime, tout finit par être du JS.

Mais c'est vrai que compile time, ça pourrait aider de détecter qu'une lib ne devrait pas être utilisée dans une version trop récente de TS car utilisant des éléments dépréciés du langage (je n'ai personnellement jamais trop eu de gros problèmes là-dessus .. mais le jour où ils mettront à la poubelle leurs saletés d'enum, ça en deviendra un)

6) TypeScript fait pas que du typage, tu as des features de TS genre enums ou decorateurs qui n'ont pas d'équivalent en JS.
Cela veut dire que, si dans le future, JS ajoute ces features cela va être le bazard (même problème que actuellement les modules en JS).

Oui, il faut espérer que l'adoption de TS, qui possède ces features en "preview" depuis longtemps, pèsera (un peu) dans le choix de la syntaxe (bon, pour les modifiers private sur les classes ça n'a pas été le cas...)

Je pense (j'espère ?) que pour les décorateurs, ça ne sera pas trop problématique.

Mais pour les enum, je pense que le mal est fait tellement ils ont mal été designés.

J'ai toujours dit aux personnes qui travaillent avec moi de ne jamais les utiliser car c'est le mal incarné :)

7) le fichier tsconfig est trop facilement éditable, c'est pas rare d'avoir une PR qui change les options de config (genre noImplicitAny) car tsc "ne marche pas".
Cela rejoint le point (1).

À grands pouvoir ... :)

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/432569438.775276.1674055693127.JavaMail.zimbra%40u-pem.fr.

Remi Forax

unread,

Jan 18, 2023, 5:25:04 PM1/18/23

to lescastcodeurs

From: "Frédéric Camblor" <fcam...@gmail.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Wednesday, January 18, 2023 7:42:37 PM
Subject: Re: [LCC] Re: LCC 290 - Mettre tes lunettes dans ta base de données

Hello Rémi (et bonne année :))

oui, bonne année à tous ...

Mes commentaires inline ! :)

On Wed, Jan 18, 2023 at 4:29 PM Remi Forax <fo...@univ-mlv.fr> wrote:

Je suis assez d'accord avec tout ce que tu as écrits,
- à part sur la notion de Clever Dev, c'est un vrai problème (cf plus bas).
- à part que je trouve que Microsoft fait de l'open source comme Google fait de l'open source, tu peux contribuer au code source mais pas à la gouvernance.

Tu as raison, le modèle de Typescript est un modèle à la Google avec peu de PR "externes" qui sont finalement acceptées j'ai l'impression (les quelques PRs que j'ai pu faire en tous les cas, ont toutes été fermées)

Ça ne me pose pas plus de soucis que ça tant que le projette avance et ne végète pas, l'avantage étant qu'on peut forker à tout moment si on n'est pas content d'un truc (c'est ce que j'ai fait sur les PR non mergées et dont j'avais besoin sur l'un de mes projets).

mouais, vu la taille du bouzin, à part si il y a des gens payés pour bosser dessus, forker le projet va mener nulle part.

Pour moi, le prinicpale problème attribué à TypeScript est que cela force à voir TypeScript/JavaScript comme un vrai langage.
On peut pas se contenter de faire de l'angular (exemple de framework choisi presque au hazard) sans savoir comment JS marche au dessus, puis comment TS marche par dessus.
Donc râler sur TypeScript est plutôt un symptome d'une mauvaise compréhension de qui fait quoi, comment cela marche, ah bon c'est pas magique, coté front.

Je plussoie.

Quand je regarde mes collègues qui n'ont jamais fait de Typescript autrement que via Angular, j'ai l'impression qu'on ne parle pas du même langage.

L'aspect "Framework" les rend fainéants à l'apprentissage du langage, c'est assez flagrant (et un peu triste aussi) combien les "exemples angular" ne les font pas se poser plus de questions que ça sur les features du langage :)

C'est marrant à quel point Angular et React sont différents sur ce point.

Angular veut te faire croire que tu écrits pas du JS au point de venir avec son propre runtime qui essaye de corriger celui de JavaScript.

React, c'est tout le contraire, tu dois connaitres les dernières nouveautés de JS et comment marche les hacks par dessus (JSX ou les hooks).

Cela dit, il y a aussi certain problèmes que je vois avec mes étudiants qui utilisent TypeScript.

1) Le système de typage est complexe, c'est normal, l'idée est de typé du JavaScript après coup.
    Cela pose un vrai problème si tu as un bon étudiants qui se fait plaisir (CleverDev) car les autres de son équipe arrivent pas à comprendre les types écrits.
    Microsoft devrais définir des profiles différents quand tu veux typé une appli que tu es entrain d'écrire où tu as pas besoin de toutes la puissance de TS et
    quand tu veux typés une librarie/module où là tu veux tous les outils à ta disposition.

Je suis assez mitigé, il y a toujours des gens qui approfondissent les sujets et pas d'autres.
Ça me paraît dommage de limiter un langage du fait de son usage par les utilisateurs : est-ce qu'à la sortie de Java 5 on a dit que les Generics ne devaient être utilisés que par une élite ?
A-t-on eu tort de ne pas le dire ?
Est-ce que justement, de ne pas avoir fait ce type de ségrégation n'a pas démocratisé leur usage au cours du temps ? (aujourd'hui, pour moi, les Generics sont utilisés / utilisables par beaucoup plus de monde qu'en 2004)

Je pense pas que les generics soient une feature avancé, tu en as besoin dès que tu as des tableaux en JS.

Mais pour prendre un exemple en Java, les wildcards c'est clairement une feature avancée.

En TS, les types nominaux classe/interface, les unions de types, les unions discriminés, les generics, c'est Ok.

Tous ce qui renviens à des fonctions de types, à part les generics, c'est pas un truc que tu vas utiliser/que tu veux utiliser dans ton appli, mais tu en a besoin dans les libraries.

C'est un peu pareil pour moi..

2) Tu as pas de système d'assertion des types à l'exécution (cela rejoint FalsePromise).
Au moins pour les tests du devrais avoir une vérification des types (simples) à runtime. Peut-être sous forme de plugin ?

Tu as des choses comme reflect-metadata qui te permettent d'utilisation un équivalent de la reflection au runtime.

Ça reste cependant pas mal de "magie noire" qui rajoute un overhead non négligeable dans le code JS généré.
Je désespère de voir un jour un plugin du compilateur TS arriver et permettant de manipuler l'AST (cette issue notamment)

Tu as ttypescript (https://www.npmjs.com/package/ttypescript), mais l'AST de tsc est pas versionné (ceux de Java (javac) et C# (Roslyn) le sont) donc c'est un boulot à plein temps de maintenir ce genre de plugin.

Au niveau des tests, tu as aussi la possibilité d'utiliser des libs pour tester tes types (cf cet article)
Même si ça me paraît aller un cran trop loin, ça peut parfois être utile.

3) Le problème des fichiers d.ts. Si une lib utilise des fichiers d.ts, cela veut souvent dire que TypeScript est un "second class citizen".
    Dans le meilleur des cas, les exemples/doc de la lib utilise JavaScript et tu es obligé de lire les fichier d.ts pour comprendre le typage.
    Dans le pire, tu as une de-synchro entre les fichiers .js et les d.ts correspondant.
    (Une partie du problème vient du fait que les étudiants utlisent une lib sans se poser de questions sur la qualité de la lib).

Les d.ts, c'est le problème de l'oeuf et de la poule : tant que TS n'est pas considéré par l'écosystème comme ce "first class citizen", les gens l'utilisent pas de facto.

Aujourd'hui, j'ai quand même l'impression qu'on a de moins en moins ce soucis et que c'est devenu mainstream (68% d'adoption de TS dans le state of JS 2022)

Attention, c'est comme demander en conf quelle version de Java les gens utilisent. Tu as un fort biais vers la nouveauté avec ce genre de questionnaire.

4) Certains messages d'erreurs sont pas compréhensible sans un tableau blanc et du temps devant toi.
Cela vient du fait que le système de type est structurelle mais Microsoft devrait payer des personnes à plein temps pour bosser sur le report des erreurs,
trop souvent l'information pertinante est noyée au milieu de types qui sont pas intéressant pour comprendre l'erreur.

100% d'accord avec toi ... les erreurs restent assez cryptiques ... c'est un peu comme les stacktraces Spring, on met du temps avant de comprendre qu'il faut partir de la fin pour comprendre le problème :-)

Dans le cas de Spring, c'est auto-infligé, ils ont choisi de composer les intercepteurs par délégation.

Pour tsc, il te faut des algos smarts qui une fois qu'une erreur est detectée n'affiche que la partie du contexte qui est intéressante, cela me semble bien plus dure.

5) Les versions de TypeScript sont pas compatibles entre elle ET certaines libs demandent des versions différentes de TypeScript.
    Microsoft est vraiment mauvais là dessus, tu devrais pas avoir de problème de compatibilité sur des versions mineurs de TypeScript.
    Il devrait aussi y avoir une notion de LTS.

Je suis d'accord avec toi : pour moi, on a un gros trou dans la raquette quand il s'agit d'exprimer la version minimum/maximum de Typescript qui est requise pour que le code de la lib qu'on importe fonctionne.

C'est mis au second plan car au runtime, tout finit par être du JS.

Mais c'est vrai que compile time, ça pourrait aider de détecter qu'une lib ne devrait pas être utilisée dans une version trop récente de TS car utilisant des éléments dépréciés du langage (je n'ai personnellement jamais trop eu de gros problèmes là-dessus .. mais le jour où ils mettront à la poubelle leurs saletés d'enum, ça en deviendra un)

Microsoft a une liste, pas exaustive, des breaking changes (c'est marrant, il y en a tellement qu'ils ont ajouté une flèche dépliante)

https://github.com/microsoft/TypeScript/wiki/Breaking-Changes

Emmanuel Bernard

unread,

Jan 21, 2023, 4:13:03 AM1/21/23

to lescast...@googlegroups.com

Si j'étais toi Frédéric, j'en ferais une entrée de blog.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CADH39npg5%3DAZSxp8D2%2BWyWnaSiWzPER%2BkDiT3Xv_AFJZKD8dJA%40mail.gmail.com.

Guillaume Laforge

unread,

Jan 21, 2023, 4:30:11 AM1/21/23

to lescast...@googlegroups.com

Voire même un crowdcast, ou une interview s'il y a matière 😊

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAEW2RjLC1Z5ZR_YiFxEu-O%2BLwHQP7MWJ%3DntPNvLJnv%2BVYU74ZA%40mail.gmail.com.

Reply all

Reply to author

Forward

0 new messages