Utiliser WebAssembly aurait peut être été plus judicieux, plutôt que de passer de C++ vers TypeScript.
Utiliser WebAssembly aurait peut être été plus judicieux, plutôt que de passer de C++ vers TypeScript.
Le typage statique est une bonne chose, surtout quand un langage le supporte correctement.
- L'intérêt le plus connu du typage statique est de renforcer les contrôles lors de l'analyse statique du code. Dans un article, tu as écrit « Aujourd'hui l'usage d'un linter dans les projets ne fait plus débat, c'est obligatoire. L'absence d'usage d'un linter est un signal fort indiquant un manque de professionnalisme et de sérieux ». Eh bien, le typage statique, c'est un peu pareil : tu peux le voir comme une extension du linter.
- Un autre intérêt du typage statique est de faciliter l'optimisation quand le code est compilé.
- Dans certains cas, le type joue un rôle de documentation. Par exemple, quand on code une fonction, on veut souvent signaler à l'utilisateur ce qu'il a le droit de passer en paramètre. Mais c'est encore plus fort que de la documentation, car il s'agit d'une information exploitable par les outils pour analyser le code et éventuellement l'optimiser.
Dans d'autres cas, on n'a pas envie d'écrire explicitement le type d'une variable. Un bon langage permet alors de faire de l'inférence de type. Certains langages sont plus forts que d'autres à ce niveau. Par exemple, Haskell est excellent en inférence de type. Dans ce langage, dire que le typage statique est lourd serait saugrenu.
Il n'est pas toujours souhaitable d'obliger le client à attendre que le réusinage de code et les tests unitaires soient terminés avant d'utiliser une certaine fonctionnalité. Parfois, le client a vraiment besoin d'utiliser une fonctionnalité à une certaine date avant que le travail ne soit fini, même s'il y a un risque de bogues. Alors, on finit le travail pendant que l'utilisateur a déjà accès à la fonctionnalité.
De manière générale, il est souhaitable de pouvoir écrire un programme fiable même avant d'avoir le temps et les moyens d'effectuer une couverture à 100% de tests unitaires.
Quand on tient ce genre de discours, on est soit très vieux et dépassé, soit très jeune et inexpérimenté, soit juste incompétent. Tu te situes dans quelle catégorie ?Parce que tu t'es séquestré dans le paradigme orienté objet.
Quand tu auras pris un peu de bouteille tu te rendras compte qu'il y a d'autres horizons.
Non. Le typage fort systématique c'est un truc de bourrin. Et c'est tout l'intérêt de TypeScript, tu l'utilises quand tu veux. Mais tu as d'autres outils, t'as flow, t'as hapijs/joi (c'est pas du typage mais ça permet de check au moment où t'en as besoin pendant le runtime, typiquement en entrée d'un endpoint), t'as la lib d'un modo de dev.com nommée ObjectModel, liste non-exhaustive.
Ça permet de cibler le besoin.
Les tests automatisés doivent jouer le rôle de documentation, mais pas le type.
Dans le cas d'une API publique la documentation est essentielle. Mais c'est un cas à la marge.
Qu'on soit clair, quand je parle de tests unitaires, je parle pas de la QA, pour moi c'est precommit et ça prend quelques minutes à exécuter au maximum.
Non je ne suis pas d'accord. Le testing automatisé et l'implémentation sont absolument indissociables, ils s'agit des deux faces d'une même pièce.
Après si vous préférez travailler à la papa ça vous regarde mais perso j'ai arrêté de faire comme ça. Je TU/TI/TF tout ce dont j'ai besoin et personne n'a à me dire de pas faire les tests.
Alors évidemment si je travaille sur du legacy je suis bien obligé de m'adapter et de mettre de l'eau dans mon vin mais depuis quelques j'arrive à esquiver les bouses plutôt bien.
C'est ce que l'on a actuellement de mieux pour garder un code court, maintenable, propre et bien documenté.Vieux et dépassé ? Parce que tu penses que la POO c'est le summum de la modernité ?
L'intérêt du paradigme POO sa n'est pas ça du tous...
On peut très bien avoir "un code court, maintenable, propre et bien documenté" sans utiliser de POO. (c'est le cas de tous mes codes Arduino (c/c++) et Rpi (python) qui sont en procédurale)
Et surtout il n'a rien d'universelle, il y a plein de domaine ou il n'est pas du tous adapté (Code BDD, Code Electronique/IoT, Code systéme, etc...) et ou d'autres paradigme sont bien plus adapté.
Pourquoi se priver, même de temps en temps, du typage statique ? À quoi sert vraiment le typage dynamique ?
Dans ce que j'ai vu jusqu'à présent, tout ce qu'on peut faire en typage dynamique, il est possible de le faire en typage statique, en mieux :
- Ne pas être obligé d'écrire le type est possible en typage statique grâce à l'inférence de type.
- L'équivalent du duck typing est le typage structurel.
- Transformer une chaîne de caractère en code est possible en typage statique quand c'est fait à la compilation (ex : mixins du langage D).
- Etc.
Cela dit, j'avoue ne pas m'être encore penché sur les langages qui supportent l'homoiconicité, comme Lisp. Ce jour-là, on verra si je tombe sur un cas où le typage dynamique sert vraiment à quelque chose.
Je suis en général assez d'accord avec tes posts, mais la pour le coup.
Ou tu as raison c'est que la POO n'est pas adapté à tous les cas de figure. Étant électronicien à la base je vois bien de quoi tu veux parler.
Néanmoins (haha c'est quand même pourris ce terme, néanmoins..., bref)
Donc néanmoins(...) la POO est une méthode de conception/codage qui à quand même pour but d'amener de la maintenabilité en modularisation et factorisant le code d'une application.
En gros le principe c'est comme les math, une appli est un gros problème qu'on décompose en sous problème plus petits.
Après, ça reste une méthode, on peut faire de la grosse daube en POO mal structuré, illisible si pas de convention de codage et bon la doc, j'en parle pas.. (c'est un problème universel)
Enfin si j'ai bien compris de quoi on parle![]()
Là dessus, nous sommes en désaccord.
- Court, certainement pas, au contraire. Le paradigme fonctionnel permet d'écrire un code plus court. Par exemple, avec le patron de conception Stratégie, avec une classe de base n'ayant qu'une seule fonction virtuelle, créer une nouvelle classe dérivée sera plus verbeux qu'écrire un lambda.
- Maintenable, peut-être, mais uniquement parce que la majorité des développeurs ne connaissent que le procédural et l'orienté objet.
- Propre est un adjectif ambigu. Si on se penche sur les contrôles à la compilation, la programmation générique surpasse la programmation orientée objet. Si on se penche sur la possibilité de découper un code en un ensemble de briques réutilisables, l'objet est meilleur que le procédural car il supporte l'inversion des dépendances. Mais les autres paradigmes de haut niveau le supportent aussi. En terme d'abstraction, la programmation fonctionnelle et la métaprogrammation surpassent la programmation orientée objet.
- Bien documenté, ça n'a pas de rapport avec le paradigme.
Jusqu'à plus d'une dizaine de contributeurs sur le même source, pas forcément en même temps d'ailleurs. Pourquoi cette question je ne vois pas le rapport avec la discussion ?
Je préfère faire const url = 'http://www.domain.tld' plutôt que const url: string = 'http://www.domain.tld'. C'est souvent simplement du bruit inutile le type. C'est une url tu m'étonnes que c'est une string.Envoyé par Pyramidev
Il ne s'agit pas de se priver du typage statique, il s'agit de ne pas être forcé de l'utiliser systématiquement.
Juste pour savoir si a plusieurs, t'avais pas préféré les langage plus "contraignant".
Ex: si je prend ton propos sur l'Url, j'en connais qui qui serait capable de me mettre une classe URL (je pense à la classe c#) au lieu d'un string si le les laisse faire. Je veut dire par là que souvent, ce qui est clair pour un ne l'est pas dans le contexte d'une autre personne. Après un projet c'est aussi un choix entre les contraintes/besoins et donc avantages/inconvénients d'une solution etc.....
Tu confonds typage statique et typage explicite.
Par exemple, en Haskell, quand on écrit url = "http://www.domain.tld", le compilateur va en déduire que url est de type String (un alias de [Char]), même si on n'a pas écrit String. Si tu passes url en argument d'une fonction qui n'accepte pas les String, tu auras une erreur de compilation, donc le typage est bien statique.
Le fait que le compilateur déduise automatiquement le type sans qu'on l'écrive explicitement s'appelle l'inférence de type.
Peut-être à l'avenir mais le WebAssembly n'est pas encore assez mature pour des applications de cette importance en production.
La plupart de langages statique permettent de faire de l'inférence de type comme C++, C#, Rust, ... ou sont en train de s'y mettre comme Java. Pas besoin de typage dynamique si ton but est de t'économiser quelque touches clavier.
Et non une Url, ça n'est pas forcément une string. Tu peux très bien avoir un objet qui encapsule une URL par exemple pour apporter des garanties sur sa validité.
En C#, quand on part sur de la réflexion le typage peux parfois poser problème car on ne sait pas a l'avance le type d'objet que l'on aura, juste qu'il implémentera tel ou tel méthode ou propriété.
La solutions la plus simple dans ce genre de cas est d'utiliser des interfaces et de "caster" les objets obtenu via réflexion, mais dans certain cas sa n'est pas possible ou tous simplement pas voulu, donc utilise le type dynamic.
Je répondais principalement a cette affirmation:
un code court, maintenable, propre et bien documenté
- un code court : l'intéret de la POO n'est pas d'avoir le code le plus court possible, vue que sa peut avoir tendance au contraire a rallonger le code.
- maintenable : la maintenabilité n'est clairement pas définie par le paradigme que l'on utilise, mais par les bonnes pratique de programmation (respect des convention, ...).
- propre : ...
- bien documenté : même remarque que pour la maintenabilité
Bref, son argumentation n'est au final pas lié a la POO, juste a de bonne pratique.
Si on m'avais demandé en quoi la POO c'est mieux que par exemple le procédurale, j'aurais eu une montagne de chose a dire, mais certainement pas ça...
Aurais-tu un exemple où on utilise la réflexion sans connaître le type à l'avance ? Je pose la question pour vérifier si on ne peut pas remplacer ça par de l'introspection à la compilation ou de la métaprogrammation à la compilation.
En langage D, selon Wikipédia, on peut faire ceci :
Code : Sélectionner tout - Visualiser dans une fenêtre à part mixin(fooToD(import("example.foo")));
- "example.foo" est une adresse de fichier qui doit être connue à la compilation.
- import("example.foo") retourne une chaîne qui correspond au contenu du fichier "example.foo".
- fooToD est une fonction que l'on code qui prend en paramètre une chaîne et retourne une chaîne. Cette fonction peut être exécutée à la compilation. D'ailleurs, le langage D autorise à faire de l'allocation dynamique à la compilation (sinon, les manipulations de chaînes seraient pénibles).
- mixin(chaîneDeCaractères) "imprime" la chaîne sous forme de code, qui sera compilé. Si la chaîne ne respecte pas la syntaxe du D, on a une erreur de compilation.
Le reste du code peut alors se servir du code "imprimé", en profitant des contrôles et optimisations du compilateur.
Remarque : Je n'ai pas encore testé cette fonctionnalité. Je suis encore débutant en D.
Un code court ça ne se compte pas en nombre de lignes brutes mais en nombre de lignes par fonctions / méthodes.un code court : l'intéret de la POO n'est pas d'avoir le code le plus court possible, vue que sa peut avoir tendance au contraire a rallonger le code.
Un code court c'est des classes de maximum 10 méthodes qui exécutent 1 à grand maximum 10 instructions.
Je serais ravi de voir des exemples de gros programmes procéduraux propres et maintenables.maintenable : la maintenabilité n'est clairement pas définie par le paradigme que l'on utilise, mais par les bonnes pratique de programmation (respect des convention, ...).
En PHP il y a WordPress qui est très peu orienté objet et c'est un incroyable foutras avec des classes qui font des milliers de lignes, totalement illisibles.
Un code bien écrit est un code qui nécessite très peu de documentation, c'est à dire un code factorisé en petites classes qui font une chose et dont on comprend immédiatement ce qu'elle fait en lisant son nom.bien documenté : même remarque que pour la maintenabilité
Un code constitué de blocs qui font 2-3 lignes a rarement besoin d'être commenté.
Si dans le code imprimé il y a un type A (qui provient de example.foo), on peut l'utiliser même si a la compilation il n'existe pas encore ? (vue que example.foo n'a pas encore été analysé)
En c#, il est possible de charger une DLL pendant l'exécution (donc on ne la connait pas au moment de compiler), puis de l'analyser pour y découvrir les class qu'elle contiens, puis de créer des instances.
Pour ces instances créer dynamiquement, on a trois choix :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 Assembly assembly = Assembly.LoadFrom("MaDLLDotNET.dll"); Type objectType= assembly.GetTypes()[0];//On prend la première class object instance = Activator.CreateInstance(objectType);
- Les stocker dans un objet de type "object", puis d'user de la réflexion pour invoquer les méthodes.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 object instance = Activator.CreateInstance(objectType); instance.GetType().GetMethod("MaMethod").Invoke(instance);- De faire un cast via une interface (sous réserve que la class en question implémente une interface qui devra être stocker dans une DLL que le programme en cours d'exécution ainsi que la DLL externe connaisse tous les deux)
A ma connaissance, c'est la technique la plus sur.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Interface instance = (Interface)Activator.CreateInstance(objectType); instance.MaMethod();- Utiliser une variable dynamic, c'est beaucoup plus dangereux, mais nettement plus simple
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 dynamic instance = Activator.CreateInstance(objectType); instance.MaMethod();
Voici un autre exemple avec CSScript (une sur-couche a CodeDom et Mono.Cecil qui permet de compiler du code a la volé):
Dans ce code on compile le code c# a la volé, pour qu'ensuite en arrière plan la nouvelle assembly généré soit charger dans le code et puisse être appeler.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 dynamic instance = CSScript.Evaluator .LoadCode(@"using System; public class MaClass { public int Sum(int a, int b) { return a+b; } }"); int result = instance.Sum(1, 2);
Probléme, au moment de coder, la class présente dans le script n'est pas connue, on ne peut ainssi pas l'utiliser, sinon le code ne compilera pas.
L'utilisation d'une variable de type dynamic permet donc de palier a se probléme.
En gros dans le code "instance" est une instance de la class "MaClass", mais non typé sur cette class (puisqu'elle n'existe pas dans le context au moment d'écrire le code).
Le dev a écrie "instance .Sum(1,2)" parce que la class contient une méthode Sum avec cette signature.
Mais rien empêche d'écrire "instance .toto("Salut")", le code compilera sans problème, vue que la variable est dynamic, mais sa plantera au moment de l'appelle.
Après, bien sur il est possible d'utiliser la réflexion pour faire la même chose, mais avec un code beaucoup plus complexe.
Et quand on se retrouve avec du code beaucoup plus complexe, qui utilise par exemple des expression lambda, la réflexion devient rapidement trop complexe utiliser.
Alors que l'utilisation de variable dynamic permet d'avoir un code beaucoup plus simple et plus lisible (bon je dit ça, mais étant allergique au type dynamic, je préfère m'arracher les cheveux sur la partie réflexion).
Mais quand on utilise certaine lib comme CSScript ou IronPython, c'est quasiment imposé d'utiliser la technique des variable dynamic...
----------------------------------------------------
On peut dire la même chose pour du code d'autres paradigme, pas plus de x fonctions dans le même fichier, et pas plus de x lignes par fonction, etc....
Là aussi c'est applicable a d'autre paradigmes.
Tu sais qu'il existe des gros projets POO qui sont tout aussi illisibles?
Tu sais qu'en POO on peut aussi écrire des méthodes qui fond des milliers de lignes?
Le problème c'est pas le paradigme, mais les devs qui font n'importe quoi.
En procédurale si on nomme bien les fichiers, qu'on applique les bonnes conventions, on peut se retrouver avec des gros projets très lisibles et maintenables.
J'avais lu le code source d'un gros ERP ecris en C et c'était parfaitement compréhensible car la structure du code était bien foutue, les fichier/fonction/variable bien nommé et le code bien commenté.
Tes arguments ne sont pas en faveur de la POO, mais des bonnes pratiquent et peu importe le paradigme, si tout le monde s'applique, il n'y a pas de raison qu'un projet devienne illisible et chiant à maintenir.
La POO a des gros avantage, je ne dit pas le contraire, mais sa n'est ceux que tu cites.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager