Microsoft serait en train de réécrire certains de ses outils et logiciels en JavaScript ? ou pas ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

14/06/2018, 01h16
psychadelic

Citation:

Envoyé par SimonDecoline

Merci pour le lien. Quelques extraits pour les JS fanboys

:nono: J'ai plutôt eu l'impression qu'il s'agissait surtout ici de JavaScript Bashing mené par des FanBoys C / C++ ...
14/06/2018, 02h13
koyosama

Je viens devoir ça tomber.

https://mspoweruser.com/no-microsoft...in-javascript/

Dsl de casser vos rêve. Mais bon la com chez Microsoft c'est pas encore ça.
14/06/2018, 02h29
psychadelic

Et bien ouf!
même si cela peut sembler étrange pour certains, ce cafouillage / rectification en Com de Microsoft (+ le fait que MS office va bien resté codé en C / C++) me rassure 8-)
14/06/2018, 06h55
Invité

Citation:

J'ai plutôt eu l'impression qu'il s'agissait surtout ici de JavaScript Bashing mené par des FanBoys C / C++ ...

Encore une fois il est stupide de parler de bashing de la part de fanboys de tel ou tel langage.
Il faut arrêter de prendre les gens pour des neuneus, nous sommes nombreux ici à détester JavaScript justement parce que nous le connaissons (trop) bien.
14/06/2018, 07h35
PatrickNice

javascript

J'ai testé un programme en c++ et en javascript = meilleur temps en javascript (mais pas le même suivant le navigateur)
14/06/2018, 08h14
ndjpoye

Citation:

Envoyé par PatrickNice

J'ai testé un programme en c++ et en javascript = meilleur temps en javascript (mais pas le même suivant le navigateur)

Ça dépend ce que fait le programme et comment il est codé.
De plus, rien n’empêche de faire du code "lent", quelque soit le langage.
14/06/2018, 08h17
ndjpoye

Citation:

Envoyé par psychadelic

Et bien ouf!
même si cela peut sembler étrange pour certains, ce cafouillage / rectification en Com de Microsoft (+ le fait que MS office va bien resté codé en C / C++) me rassure 8-)

Je suis pas certain que ce soit un "cafouillage". Certe, pour moi, il n'a jamais dit que les autres langages dégagés. Mais bon, qu'un tweet pareil ai été interprété par certain comme il l'a été, c'était, il me semble, prévisible.
Donc cafouillage ou petit buzz volontaire ?

Ha la com :)
14/06/2018, 08h30
ElMnOp

Ca veut dire qu'on aura accès au code source ???

Ca, ça serait une révolution... Où alors ils ont trouvé un bon moyen d'obfusquer le code...

Citation:

Envoyé par Sodium

Non tu n'as pas compris ce que je voulais dire en effet...

Tu ne peux pas faire ça en JavaScript :

Tu es obligé d'initialiser les propriétés de la classe à l'intérieur d'une méthode avec this.test1 = '...', ce qui est loin d'être propre.

Tu peux faire ça en JS :
Code:

1 2 3 4 5 6 7 8 9 10 function Rectangle(width, height) { //private var _width = width; var _height = height; //public props Object.defineProperty(this, "Width", { get: function(){ return _width; }, set : function(value){ _width = value }}); Object.defineProperty(this, "Height", { get: function(){ return _height; }, set : function(value){ _height = value }}); }; var r = new Rectangle(50, 20);
Et c'est juste l'une des nombreuses façon de faire.

Le mot clé class c'est du sucre syntaxique (créer uniquement pour faire plaisir a ceux qui refuse d'apprendre le fonctionnement des prototype), qui au final n'a pas sa place en JS vue que c'est de la POO orienté Prototype et non par Class.
En arrière plan le mot clé class sera toujours convertie en Prototype.
https://developer.mozilla.org/fr/doc...érateurs/class

14/06/2018, 09h52
danielhagnoul

:salut:

J'ai lu toute la discussion. Je me suis cru dans le bêtisier informatique.

Sacré troll ! Mais cela fait du bien de rire de temps en temps. :ptdr:

Certains messages sont... (abstenons-nous) !

Retenons les mots naïfs, crédules, mal formé (ES2015+) et bien entendu mal informé.

Du point de vue de Microsoft, c'est ce que l'on appelle faire de la publicité à moindres frais.
14/06/2018, 09h53
Invité

Citation:

Le mot clé class c'est du sucre syntaxique (créer uniquement pour faire plaisir a ceux qui refuse d'apprendre le fonctionnement des prototype), qui au final n'a pas sa place en JS vue que c'est de la POO orienté Prototype et non par Class.
En arrière plan le mot clé class sera toujours convertie en Prototype.
https://developer.mozilla.org/fr/doc...érateurs/class

Si l'on veut utiliser des classes, ce n'est pas que l'on refuse d'apprendre la programmation par prototype, c'est que :
1) La programmation par prototype est dégueulasse et ton exemple montre bien à quel point même un code très simple devient difficilement lisible.
2) Un développeur est forcément au cours de sa carrière amené à travailler avec de multiples langage et devoir utiliser un syntaxe particulière juste pour UN langage qui ne fait rien comme tout le monde est pénible.
14/06/2018, 09h57
Invité

Citation:

Envoyé par psychadelic

:nono: J'ai plutôt eu l'impression qu'il s'agissait surtout ici de JavaScript Bashing mené par des FanBoys C / C++ ...

Oui ce doit être le complot franc-maC++, en aucun cas une réaction à un troll "Microsoft serait en train de réécrire certains de ses outils et logiciels en JavaScript" (à la place de C++) qui vanterait les merveilleux avantages du JS (à la place de C++) et que seul JS, qui est le meilleur langage du monde, possède (à la place de C++).
14/06/2018, 10h19
Marco46

Citation:

Envoyé par Sodium

Si l'on veut utiliser des classes

Mais quel est l'intérêt d'utiliser des classes à part pour définir un modèle ? Et j'ai envie de dire, et encore même là l'utilité se discute ya d'autres outils pour introduire du type checking strict.

On a pas besoin des classes il y a les modules.

Citation:

Envoyé par Sodium

2) Un développeur est forcément au cours de sa carrière amené à travailler avec de multiples langage et devoir utiliser un syntaxe particulière juste pour UN langage qui ne fait rien comme tout le monde est pénible.

8O

Si t'as plusieurs langages t'as plusieurs syntaxes ... C'est quoi cet argument ?!?
14/06/2018, 10h22
goldbergg

Citation:

Envoyé par Sodium

1) La programmation par prototype est dégueulasse et ton exemple montre bien à quel point même un code très simple devient difficilement lisible.

Comme je l'ai dit il y a x façon d'écrire ce code, a la convenance de chacun et sans pour autant utiliser le mot clé class.
Il en existe des bien plus lisible mais je ne vois pas en quoi c'est dégueulasse ?.

Citation:

Envoyé par Sodium

2) Un développeur est forcément au cours de sa carrière amené à travailler avec de multiples langage et devoir utiliser un syntaxe particulière juste pour UN langage qui ne fait rien comme tout le monde est pénible.

Je ne comprendrais jamais cette logique...

J'ai déjà coder en JS, PHP, PL/SQL/, Transact/SQl, Python (2 et 3), VB, C, C++, C#, W-langage et bien d'autre.

Quand je me suis retrouvé a écrire des milliers de ligne en Transact (sur un gros projet) je n'est pas cherché a faire en sorte de pouvoir réutiliser la syntaxe du PHP ou du C#, j'ai appris a faire du Transact et j'ai tous coder de cette manière.

Il en vas de même pour tous les langage, quand je me suis retrouver a faire des site SPA, bin j'ai appris le JS et c'est tous, rien d'insurmontable, idem pour le Python quand je me suis mit a l'IoT.
Aujourd'hui je passe sans problème de C# à C++ à JS à Python et dans chacun des se langage je respect la façon de coder qui est "imposé".

PS: et js n'est pas le seul language POO par prototype, donc non, il ne fait pas "rien comme tout le monde"
14/06/2018, 10h35
youtpout978

Ce qui m'a sidéré c'est l'annonce du passage au tout JS alors que WebAssembly est sur les rails, bon finalement c'était un pétard mouillé c'est juste pour quelques UI de certaines applications et dans quel contexte on ne le sait pas vraiment, (React native est compatible Windows 10 min, je ne pense pas que pour certains outils ils vont abandonnée Windows 7 tout de suite).
14/06/2018, 10h38
GordonFreeman

Citation:

Envoyé par Marco46

ES6 est sorti officiellement en 2015, Babel (anciennement 6to5) doit dater de 2014, ça veut dire que au mieux ton expérience d'un JavaScript moderne se limite à 4 ans.

Est-ce que j'ai dit que je n'en faisait plus actuellement ?

Oui JS 'évolue', comme tout les langages d'ailleurs hein.
Perso pour JS j'appel pas ça des évolutions (d’où les guillemets) mais du rattrapage. Alors oui il s'améliore mais on est encore très loin de quelque chose de viable à mon sens. Mais on y arrivera peut être un jour. Et ce jour la Javascript ressemblera aux autres langages 'évolués'
Mais tous les autres auront aussi évolué entre temps, faut pas l'oublier. (un bel exemple qui était dans ce cas PHP)

Citation:

Envoyé par Marco46

La différence entre ES5 et ES6 est absolument énorme, ça n'a plus rien à voir.

Tu va en plus dans mon sens en disant que ES5 n'a rien à voir avec ES6. C'est super rassurant de ce dire que la techno doit être revue de fond en comple pour palier à des manque ou des problème de conception d'origine..
Et pour info tous les langages évoluent! Java, C# , C++. Et alors ? Les concepts de fond de la technologie n'ont eux pas changé, c'est des évolutions!

Mais malgré toutes les 'évolutions' de JS, tu n'as toujours pas (et surement jamais) :
de typage statique correct
de pas de compilation -> ça pète au runtime.
De respect correct des concepts objets -> nécessite du typage. (je ne parlerai pas de l'hétitage par prototype ...) -> ce qui induit énormément de chose en temre de conception
pas de mécanique forte d'abstaction via les interfaces
Pas d'injection de dépendances
Pas d'aspects
etc, etc... J'en reste là, tellement la liste serait longue.

Citation:

Envoyé par Marco46

Et dans le même temps tu as le json qui supplante le xml et Node.js qui devient mainstream et qui a permis le développement d'un tooling d'excellente qualité.

Tu parles de JSON, qui est effectivement issu du monde js, mais JSON est un modèle de structuration des données qui est également utilisé dans d'autre technologie. Je me souviens à l'époque (il y a 5 à 8 ans) le gars qui codaient en JS disaient déjà que c'était 100 fois mieux que XML et que XML allait disparaître au profit de JSON
Résultat ? XML est toujours là (Même que JSON répond à un besoin et est très utilisé. Le fait est qu'on parle de validation de JSON. En gros on aura la même chose qu'on à avec XML depuis 15 ans avec les XSD ou autre...

Et encore une fois, pour moi Typescript est un langage (libre et open source d'ailleurs) à part entière, avec ses règles, ça syntaxe et ses évolution indépendantes de JS. Même s'il repose sur JS à la base.
Les DLL Java ou la JVM sont écrites en C ou C++, donc sans ces 2 technos pas de Java. Mais Java reste une techno à part entière ?
Le fait que tu puisses les utiliser conjointement (Typescript et JS) ne veut rien dire.
En C# je peux invoquer du C! Mais ça ne veut pas dire que C# est lié au C

Citation:

Envoyé par Marco46

Tout ça pour dire que l'impression que ça donne c'est que beaucoup de développeurs qui ont fait du js ces 15 dernières années ont besoin d'une grosse mise à niveau.

Et pourquoi je me mettrais à niveau avec JS ? Typescript ou autre pourquoi pas.
Pour rappel, JS à eu la chance d'être à la bonne place au bon moment et c'est retrouver comme standard de facto car il à largement été utilisé et il répondait à un besoin clair et n'avait pas de concurrent à ce moment (heureusement ça change)
Si tu commence de construire un édifice sur du sable tu as beau couler du béton à outrance pour améliorer, tes fondations seront toujours bancales.

Du coup, perso je préfererai mille fois faire du Python, mais ça c'est personnel!
14/06/2018, 11h39
Marco46

Citation:

Envoyé par GordonFreeman

Est-ce que j'ai dit que je n'en faisait plus actuellement ?

Ça me semblait implicite. Je comprends tout à fait qu'on déteste ES5, mais il n'y a aucun argument rationnel pour détester ES6.

Citation:

Envoyé par GordonFreeman

Oui JS 'évolue', comme tout les langages d'ailleurs hein.
Perso pour JS j'appel pas ça des évolutions (d’où les guillemets) mais du rattrapage. Alors oui il s'améliore mais on est encore très loin de quelque chose de viable à mon sens.

Du rattrapage ça c'est clair, mais maintenant on est bien, on est tellement bien que Java se mets à piller le JavaScript. Les temps changent, c'est à Java de rattraper le retard maintenant.

Au fait, qu'est-ce qu'il manque à js que Java ou C# ont par exemple ?

Citation:

Envoyé par GordonFreeman

Tu va en plus dans mon sens en disant que ES5 n'a rien à voir avec ES6. C'est super rassurant de ce dire que la techno doit être revue de fond en comple pour palier à des manque ou des problème de conception d'origine..

Elle a pas été revue de fond en comble puisque c'est retro compatible. Je croyais que tu étais un expert ? :roll:

Citation:

Envoyé par GordonFreeman

Mais malgré toutes les 'évolutions' de JS, tu n'as toujours pas (et surement jamais) :
de typage statique correct

Comme je te le disais, son utilité est tout à fait discutable en fonction du projet. C'est une lourdeur souvent inutile dans la plupart des projets de gestion, on peut parfaitement utiliser d'autres outils pour avoir du contrôle de type aux besoins endroits aux bons moments plutôt que de l'avoir partout.

Citation:

Envoyé par GordonFreeman

de pas de compilation -> ça pète au runtime.

Quand on dev en amateur c'est possible. Si tu testes sérieusement tes applis ça ne peut pas arriver avec une bonne couverture.

Citation:

Envoyé par GordonFreeman

De respect correct des concepts objets -> nécessite du typage. (je ne parlerai pas de l'hétitage par prototype ...) -> ce qui induit énormément de chose en temre de conception

Osef. C'est une excellente chose de ne pas avoir ce gloubi boulga inutile de classes. La bonne brique de base pour programmer c'est la fonction, pas la classe.

Citation:

Envoyé par GordonFreeman

pas de mécanique forte d'abstaction via les interfaces

Tu veux mettre des interfaces dans un langage fonctionnel ? :weird:

Citation:

Envoyé par GordonFreeman

Pas d'injection de dépendances

C'est une plaisanterie ? L'injection de dépendances c'est un gros mot pour dire passer une variable en paramètre. Qu'est-ce qui empêche d'avoir un paramètre deps passé à une fonction et de le destructurer derrière pour retrouver tes petits ?

Citation:

Envoyé par GordonFreeman

Pas d'aspects

Osef ça scale pas.

Citation:

Envoyé par GordonFreeman

etc, etc... J'en reste là, tellement la liste serait longue.

Pour le moment ta liste est vide :mrgreen:

Citation:

Envoyé par GordonFreeman

Tu parles de JSON, qui est effectivement issu du monde js, mais JSON est un modèle de structuration des données qui est également utilisé dans d'autre technologie. Je me souviens à l'époque (il y a 5 à 8 ans) le gars qui codaient en JS disaient déjà que c'était 100 fois mieux que XML et que XML allait disparaître au profit de JSON
Résultat ? XML est toujours là (Même que JSON répond à un besoin et est très utilisé. Le fait est qu'on parle de validation de JSON. En gros on aura la même chose qu'on à avec XML depuis 15 ans avec les XSD ou autre...

Dans les faits json à bel et bien supprimé l'usage du XML pour la communication inter-systèmes.

J'ai plus refait de xml depuis 2008/2009 perso.

Citation:

Envoyé par GordonFreeman

Et encore une fois, pour moi Typescript est un langage (libre et open source d'ailleurs) à part entière, avec ses règles, ça syntaxe et ses évolution indépendantes de JS.

J'ai rien à répondre à ça tellement t'es sur orbite. Ptet que pour toi TypeScript est indépendant mais pour TypeScript c'est pas le cas, c'est même écrit dans l'intro de sa spec ...

Citation:

Envoyé par GordonFreeman

Et pourquoi je me mettrais à niveau avec JS ? Typescript ou autre pourquoi pas.

Si tu te mets à niveau sur TypeScript, mécaniquement tu vas devoir apprendre tout JavaScript !

Ou alors t'as toujours pas compris le sens du mot : sur-ensemble ?

Citation:

Envoyé par GordonFreeman

Pour rappel, JS à eu la chance d'être à la bonne place au bon moment et c'est retrouver comme standard de facto car il à largement été utilisé et il répondait à un besoin clair et n'avait pas de concurrent à ce moment (heureusement ça change)

Ah bon js a un concurrent :lol: ? Quel est ce nouveau langage implémenté massivement dans les browsers j'ai pas suivi ?
14/06/2018, 12h08
goldbergg
Citation:

Envoyé par Marco46

Dans les faits json à bel et bien supprimé l'usage du XML pour la communication inter-systèmes.

J'ai plus refait de xml depuis 2008/2009 perso.

Malheureusement c'est faux...
D'ailleurs contrairement a se que l'on pourrai pensé SOAP est encore très utilisé dans les grosse entreprise.

Il faut aussi prender en compte que le Xml permet certaine chose que le json ne permet pas.
Par exemple :
Code:

1 2 3 <elem prop="propValue" > elemValue </elem>
N'a aucun équivalent natif en json
14/06/2018, 12h44
Invité

Citation:

Comme je te le disais, son utilité est tout à fait discutable en fonction du projet. C'est une lourdeur souvent inutile dans la plupart des projets de gestion, on peut parfaitement utiliser d'autres outils pour avoir du contrôle de type aux besoins endroits aux bons moments plutôt que de l'avoir partout.

Une première utilité commune à tout projet, c'est déjà de voir en direct quand l'on fait des conneries dans son code.
En TypeScript si tu envoies une variable du mauvais type à une fonction l'ide le souligne tout de suite et ça évite d'avoir à s'en rendre compte au moment de l'exécution du programme.

Citation:

Osef. C'est une excellente chose de ne pas avoir ce gloubi boulga inutile de classes. La bonne brique de base pour programmer c'est la fonction, pas la classe.

Désolé mais c'est juste de l'argumentation de développeur débutant.
Effectivement, les classes, l'héritage, l'injection de dépendances, le typage fort etc ça ressemble à des contraintes ou à de la complexité inutile ... et puis on prend de l'expérience et l'on commence à comprendre l'intérêt de la chose.
Je vois que tu es inscrit à ce forum depuis 2005, si ça fait plus de 10 ans que tu codes et que tu en es encore à dire que la programmation à base de classes ça ne sert à rien, je trouve ça triste et je n'aimerais pas être ton employeur.
14/06/2018, 13h07
GordonFreeman

Citation:

Envoyé par Marco46

Ça me semblait implicite. Je comprends tout à fait qu'on déteste ES5, mais il n'y a aucun argument rationnel pour détester ES6.

Du rattrapage ça c'est clair, mais maintenant on est bien, on est tellement bien que Java se mets à piller le JavaScript. Les temps changent, c'est à Java de rattraper le retard maintenant.

Au fait, qu'est-ce qu'il manque à js que Java ou C# ont par exemple ?

Elle a pas été revue de fond en comble puisque c'est retro compatible. Je croyais que tu étais un expert ? :roll:

Comme je te le disais, son utilité est tout à fait discutable en fonction du projet. C'est une lourdeur souvent inutile dans la plupart des projets de gestion, on peut parfaitement utiliser d'autres outils pour avoir du contrôle de type aux besoins endroits aux bons moments plutôt que de l'avoir partout.

Quand on dev en amateur c'est possible. Si tu testes sérieusement tes applis ça ne peut pas arriver avec une bonne couverture.

Osef. C'est une excellente chose de ne pas avoir ce gloubi boulga inutile de classes. La bonne brique de base pour programmer c'est la fonction, pas la classe.

Tu veux mettre des interfaces dans un langage fonctionnel ? :weird:

C'est une plaisanterie ? L'injection de dépendances c'est un gros mot pour dire passer une variable en paramètre. Qu'est-ce qui empêche d'avoir un paramètre deps passé à une fonction et de le destructurer derrière pour retrouver tes petits ?

Osef ça scale pas.

Pour le moment ta liste est vide :mrgreen:

Dans les faits json à bel et bien supprimé l'usage du XML pour la communication inter-systèmes.

J'ai plus refait de xml depuis 2008/2009 perso.

J'ai rien à répondre à ça tellement t'es sur orbite. Ptet que pour toi TypeScript est indépendant mais pour TypeScript c'est pas le cas, c'est même écrit dans l'intro de sa spec ...

Si tu te mets à niveau sur TypeScript, mécaniquement tu vas devoir apprendre tout JavaScript !

Ou alors t'as toujours pas compris le sens du mot : sur-ensemble ?

Ah bon js a un concurrent :lol: ? Quel est ce nouveau langage implémenté massivement dans les browsers j'ai pas suivi ?

OMG :ptdr:

Mais ça :

Citation:

Envoyé par Marco46

Du rattrapage ça c'est clair, mais maintenant on est bien, on est tellement bien que Java se mets à piller le JavaScript. Les temps changent, c'est à Java de rattraper le retard maintenant.

Houlala... là, c'est beaucoup trop lourd!!! OK t'as gagné, j'abandonne.
Et non comme je ne vais pas perdre mon temps te donner des exemples factuels pour que tu les détournes avec du subjectifs ou éléments détournés comme tu l'as fait tout au long de ta réponse.

Comme dit le proverbe y'a pas plus aveugle que celui qui ne veut pas voir.

Sur ce, bon bricolage :roll:
14/06/2018, 13h28
Dhafer1

Utiliser WebAssembly aurait peut être été plus judicieux, plutôt que de passer de C++ vers TypeScript.
14/06/2018, 13h48
Pyramidev
Citation:

Envoyé par Marco46

Citation:

Envoyé par GordonFreeman

Mais malgré toutes les 'évolutions' de JS, tu n'as toujours pas (et surement jamais) :
de typage statique correct

Comme je te le disais, son utilité est tout à fait discutable en fonction du projet. C'est une lourdeur souvent inutile dans la plupart des projets de gestion, on peut parfaitement utiliser d'autres outils pour avoir du contrôle de type aux besoins endroits aux bons moments plutôt que de l'avoir partout.

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.
Citation:

Envoyé par Marco46

Citation:

Envoyé par GordonFreeman

de pas de compilation -> ça pète au runtime.

Quand on dev en amateur c'est possible. Si tu testes sérieusement tes applis ça ne peut pas arriver avec une bonne couverture.

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.
14/06/2018, 13h50
Marco46

Citation:

Envoyé par Sodium

Effectivement, les classes, l'héritage, l'injection de dépendances, le typage fort etc ça ressemble à des contraintes ou à de la complexité inutile ... et puis on prend de l'expérience et l'on commence à comprendre l'intérêt de la chose.

[...]

Je vois que tu es inscrit à ce forum depuis 2005, si ça fait plus de 10 ans que tu codes et que tu en es encore à dire que la programmation à base de classes ça ne sert à rien, je trouve ça triste et je n'aimerais pas être ton employeur.

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.
14/06/2018, 13h53
Invité

Citation:

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.

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 ?
14/06/2018, 14h07
Marco46

Citation:

Envoyé par Pyramidev

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.

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.

Citation:

Envoyé par Pyramidev

Dans certains cas, le type joue un rôle de documentation.

Les tests automatisés doivent jouer le rôle de documentation, mais pas le type.

Citation:

Envoyé par Pyramidev

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 le cas d'une API publique la documentation est essentielle. Mais c'est un cas à la marge.

Citation:

Envoyé par Pyramidev

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é.

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.

Citation:

Envoyé par Pyramidev

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.

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.
14/06/2018, 14h09
Marco46

Citation:

Envoyé par Sodium

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 ?

Vieux et dépassé ? Parce que tu penses que la POO c'est le summum de la modernité ?
14/06/2018, 14h17
ndjpoye

Citation:

Envoyé par Marco46

Vieux et dépassé ? Parce que tu penses que la POO c'est le summum de la modernité ?

Juste une question qui n'a pas pour but d'être désobligeant, tu travailles (ou a travaillé) en étant plusieurs à coder sur un même projet ?
14/06/2018, 14h20
Invité

Citation:

Vieux et dépassé ? Parce que tu penses que la POO c'est le summum de la modernité ?

C'est ce que l'on a actuellement de mieux pour garder un code court, maintenable, propre et bien documenté.
14/06/2018, 14h30
goldbergg

Citation:

Envoyé par Sodium

C'est ce que l'on a actuellement de mieux pour garder un code court, maintenable, propre et bien documenté.

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é.
14/06/2018, 14h39
Pyramidev
Citation:

Envoyé par Marco46

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. [...] Ça permet de cibler le besoin.

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.
14/06/2018, 14h47
GordonFreeman

Citation:

Envoyé par goldbergg

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é.

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 :aie:
14/06/2018, 14h58
Pyramidev
Citation:

Envoyé par Sodium

C'est ce que l'on a actuellement de mieux pour garder un code court, maintenable, propre et bien documenté.

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.
14/06/2018, 15h32
Marco46

Citation:

Envoyé par ndjpoye

Juste une question qui n'a pas pour but d'être désobligeant, tu travailles (ou a travaillé) en étant plusieurs à coder sur un même projet ?

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 ?

Citation:

Envoyé par Pyramidev

Pourquoi se priver, même de temps en temps, du typage statique ? À quoi sert vraiment le typage dynamique ?

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.

Il ne s'agit pas de se priver du typage statique, il s'agit de ne pas être forcé de l'utiliser systématiquement.
14/06/2018, 15h43
ndjpoye

Citation:

Envoyé par Marco46

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 ?

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.....
14/06/2018, 16h00
Pyramidev

Citation:

Envoyé par Marco46

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.

Il ne s'agit pas de se priver du typage statique, il s'agit de ne pas être forcé de l'utiliser systématiquement.

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.
14/06/2018, 16h13
Uther

Citation:

Envoyé par Dhafer1

Utiliser WebAssembly aurait peut être été plus judicieux, plutôt que de passer de C++ vers TypeScript.

Peut-être à l'avenir mais le WebAssembly n'est pas encore assez mature pour des applications de cette importance en production.

Citation:

Envoyé par Marco46

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.

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é.
14/06/2018, 16h28
goldbergg
Citation:
Envoyé par Pyramidev

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.
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.

Citation:

Envoyé par GordonFreeman

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 :aie:

Je répondais principalement a cette affirmation:

Citation:

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...
14/06/2018, 17h19
Pyramidev
Citation:

Envoyé par goldbergg

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.

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:

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.
14/06/2018, 18h31
Invité

Citation:

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 ça ne se compte pas en nombre de lignes brutes mais en nombre de lignes par fonctions / méthodes.
Un code court c'est des classes de maximum 10 méthodes qui exécutent 1 à grand maximum 10 instructions.

Citation:

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, ...).

Je serais ravi de voir des exemples de gros programmes procéduraux propres et maintenables.
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.

Citation:

bien documenté : même remarque que pour la maintenabilité

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.
Un code constitué de blocs qui font 2-3 lignes a rarement besoin d'être commenté.

Citation:

Envoyé par Pyramidev

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:

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.

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.
Code:

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);
Pour ces instances créer dynamiquement, on a trois choix :
Les stocker dans un objet de type "object", puis d'user de la réflexion pour invoquer les méthodes.
Code:

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)
Code:

1 2 Interface instance = (Interface)Activator.CreateInstance(objectType); instance.MaMethod();
A ma connaissance, c'est la technique la plus sur.
Utiliser une variable dynamic, c'est beaucoup plus dangereux, mais nettement plus simple
Code:

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é):
Code:

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);
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.

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 :aie:).
Mais quand on utilise certaine lib comme CSScript ou IronPython, c'est quasiment imposé d'utiliser la technique des variable dynamic...

----------------------------------------------------

Citation:

Envoyé par Sodium

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 c'est des classes de maximum 10 méthodes qui exécutent 1 à grand maximum 10 instructions.

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....

Citation:

Envoyé par Sodium

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.
Un code constitué de blocs qui font 2-3 lignes a rarement besoin d'être commenté.

Là aussi c'est applicable a d'autre paradigmes.

Citation:

Envoyé par Sodium

Je serais ravi de voir des exemples de gros programmes procéduraux propres et maintenables.
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.

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.

Voir 40 message(s) de cette discussion en une page