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

Citation:

---

Envoyé par ndjpoye

Juste pour savoir si a plusieurs, t'avais pas préféré les langage plus "contraignant".

---

Disons que ya des contraintes beaucoup plus efficaces. Linters et tests sur les hooks precommit / prepush et en bout de ligne de la code review sur les merge request.

Citation:

---

Envoyé par ndjpoye

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

---

Ben typiquement je valide pas la merge request et je demande une modif. Classe inutile dans le contexte. T'as pas besoin de typer une url, le bon type d'une url c'est string sauf use case spécifique du fait du besoin d'un api (DOM par exemple).

Citation:

---

Envoyé par Pyramidev

Tu confonds typage statique et typage explicite.

---

Ok je veux bien mais la plus value de forcer un typage systématique elle est où ? Le rapport avantage / inconvénient est pas si évident que ça en pratique, pour moi ça relève beaucoup du dogme.

Citation:

---

Envoyé par Uther

Pas besoin de typage dynamique si ton but est de t'économiser quelque touches clavier.

---

C'est pas le sujet, il s'agit d'épurer le code. C'est du même ordre que d'avoir un commentaire qui décrit l'objet d'une variable alors que le naming est explicite. C'est inutile la plupart du temps.

Citation:

---

Envoyé par Uther

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

---

Tu peux mais c'est de l'overkill. Tu as seulement besoin d'une fonction de validation.

Citation:

---

Envoyé par Sodium

Un code court c'est des classes de maximum 10 méthodes qui exécutent 1 à grand maximum 10 instructions.

---

C'est beaucoup, beaucoup, beaucoup trop long. Le simple fait d'exposer tes méthodes te prend la moitié de l'écran. Une classe c'est un moule à objet, c'est pas une lib.

@goldbergg :

Avec DMD 2.080.1 (un compilateur D), je viens de faire le test suivant :

Je crée un fichier "example.foo" qui contient la chaîne "unNomDeStructure".
Dans le même dossier, je crée un fichier "main.d" avec le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

import std.ascii : toUpper; import std.stdio : writeln;   void main() { UnNomDeStructure var; var.aMember = 5; writeln("var.aMember == ", var.aMember); }   mixin(codeOfStructWithUpperCaseFirstLetter(import("example.foo")));   string codeOfStructWithUpperCaseFirstLetter(string input) { assert(input.length > 0); char[] structName = input.dup; structName[0] = toUpper(input[0]); char[] result = "struct " ~ structName ~ " {\n" ~ "int aMember;\n" ~ "}"; return result.idup; }

---

Le code charge le fichier "example.foo" et passe la chaîne correspondante à codeOfStructWithUpperCaseFirstLetter qui retourne le code d'une structure dont le nom ("UnNomDeStructure") est égal à la chaîne en paramètre, mais en remplaçant la première lettre par une majuscule. mixin "imprime" le code de cette structure.
Cela définit une structure UnNomDeStructure, que je peux utiliser dans main().

En ligne de commande, si je tape « dmd -J"." main.d », cela compile bien et crée un exécutable "main.exe" dont l'exécution affiche « var.aMember == 5 » dans la sortie standard.
L'option -J indique une adresse de dossier dans lequel chercher quand on fait import(adresseRelativeDeFichier).

Si je remplace le contenu de "example.foo" par "unNomDeStructureD" et que j'essaie de recompiler, le compilateur m'affiche :

Code:

---

main.d(5): Error: undefined identifier UnNomDeStructure, did you mean UnNomDeStructureD?

---

Si je remets "example.foo" comme avant mais si, dans codeOfStructWithUpperCaseFirstLetter, je remplace la chaîne "int aMember;\n" par "int someMember;\n", le compilateur ne sera pas content non plus :

Code:

---

1 2	main.d(6): Error: no property aMember for type UnNomDeStructure main.d(7): Error: no property aMember for type UnNomDeStructure

---

Donc le chargement du fichier "example.foo" et l'exécution de codeOfStructWithUpperCaseFirstLetter se passent bien à la compilation.

Remarque : Le langage D est assez permissif sur l'ordre des déclarations dans un module. Alors, j'ai pu utiliser UnNomDeStructure dès la ligne 5 avant de définir cette structure, à la ligne 10 avec mixin. De même, j'ai pu utiliser codeOfStructWithUpperCaseFirstLetter à la ligne 10 avant de la définir, à la ligne 12.

Citation:

---

Envoyé par Marco46

Citation:

---

Envoyé par Uther

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

---

Tu peux mais c'est de l'overkill. Tu as seulement besoin d'une fonction de validation.

---

L'avantage d'une classe Url qui encapsule une URL, qui a pour invariant de classe que l'URL encapsulée est bien formée et dont le constructeur et les mutateurs s'assurent que l'invariant de classe est respecté, c'est que, une fois que l'objet est construit, on sait que l'URL contenue est valide.
Du coup, avec du typage statique, quand une fonction prend en paramètre un objet de type Url, on a la garantie que l'URL est bien formée. Sinon, l'objet n'aurait pas réussi à se construire et ne serait pas arrivé en paramètre. Donc on sait qu'on n'a pas besoin d'appeler la fonction qui vérifie si l'URL est bien formée.

Dans ton cas, concrètement, si tu as des fonctions qui parsent des URL, cela te permettra d'éviter d'écrire des tests unitaires inutiles dans lesquels tu passes à ces fonctions des URL mal formées pour voir si elles signalent bien une erreur : tu ne pourras pas leur passer des URL mal formées, puisque le constructeur de la classe Url t'en empêchera.

Je ne relirai pas les 5 pages pour rien. Ils ont nié, du moins pour Office.

Non, Microsoft n’a pas abandonné C++, C#, … pour réécrire ses outils et logiciels en JavaScript :
Un développeur de la firme fait des précisions

Un développeur de Microsoft a, il y a quelques jours, fait une apparition sur Twitter pour passer le message selon lequel Microsoft est en train de réécrire ses outils et logiciels en JavaScript. Le tweet n’a pas manqué de générer de nombreux questionnements sur les objectifs poursuivis par l’entreprise. Il y a en effet que les écarts en matière de performances entre des langages de programmation comme le C++ et JavaScript sont importants pour ne pas appeler à une telle posture. Mais 280 caractères peuvent s’avérer très insuffisants pour traduire le fond d’une pensée. Sean Thomas Larkin a fait une nouvelle sortie pour apporter des précisions.

L’entreprise n’est pas en train de laisser tomber tous les autres langages pour JavaScript comme le laissait penser le précédent message de Larkin : « je n'ai jamais été capable de le dire jusqu'à maintenant. Eh bien, en fait, tout Office 365 est en train d'être complètement réécrit (et c'est presque terminé) dans ce petit langage de script appelé #JavaScript. Et Skype, et Microsoft Teams, et Visual Studio Code, et tout le protocole de débogage de Microsoft Edge (au lieu de C ++). »

« Nous ne sommes pas en train de laisser tomber C++, C# ou tout autre langage, API et outils dont nous faisons usage au sein de Microsoft », écrit-il. À la réalité, JavaScript est beaucoup plus utilisé par les équipes de développement de Microsoft pour monter des interfaces utilisateur. À propos de la suite bureautique Office 365 par exemple, Larkin indique que Microsoft s’appuie sur le framework React Native (Windows) pour l’UI, mais pas dans son entièreté. « Les API et services continuent d’être développés en C++, C# ou tout autre langage jugé le plus approprié », précise-t-il. Même son de cloche pour le moteur de rendu EdgeHTML que Larkin dit être développé en C++ dans sa quasi-totalité. Là encore, JavaScript revient pour certains éléments d’interface utilisateur en s’appuyant sur React ou webpack.

Pièce jointe 388878

Pourquoi le choix de JavaScript pour le développement d’interfaces utilisateur ?

Parce que cette approche permet de mettre le pied dans pratiquement toutes les maisons (entendez ici plateformes). Il y a en effet que le langage JavaScript est vu comme le langage de demain parce qu’il bénéficie d’un vaste écosystème. Sur un PC ou sur un ordinateur monocarte comme le Raspberry Pi on peut lancer un navigateur web. Or, JavaScript est « la star » sur ces derniers, ce qui veut dire qu’avec des compétences en développement web ces plateformes constituent des bastions qu’on peut conquérir. Ajoutez des composants comme les WebView à la sauce et il est possible de mettre sur pied une application pour Android et iOS sans compétence extrêmement pointues en déveleppement pour ces systèmes d'exploitation. Maintenant, quand on connaît les possibilités d’interfaçage de JavaScript avec des langages comme C++ on ne peut qu’en profiter comme Microsoft.

Source : Twitter

Et vous ?

:fleche: Que pensez-vous de l’approche adoptée par Microsoft ?

:fleche: Quels pourraient être les bénéfices pour toutes les parties prenantes de l’univers du logiciel Microsoft ?

Voir aussi :

:fleche: Quel est l'intérêt d'écrire ou réécrire un logiciel en JavaScript ? Partagez votre expérience

:fleche: Excel : Microsoft ajoute la possibilité d'écrire des fonctions personnalisées en JavaScript, mais également des fonctions d'apprentissage automatique

:fleche: Hyperapp, une bibliothèque JavaScript de 1 ko pour la création d'applications Web front-end, en quoi diffère-t-elle des bibliothèques existantes ?

Citation:

---

Envoyé par Marco46

Tu peux mais c'est de l'overkill. Tu as seulement besoin d'une fonction de validation.

---

Pour moi l'overkill c'est surtout s'amuser à perdre inutilement plus de 20% de puissance pour des vérifications de types à l'exécution et se rajouter de potentiels ambiguïtés et bugs facilement évitables avec des vérifications de type à la compilation.

Citation:

---

s'amuser à perdre inutilement plus de 20% de puissance pour des vérifications de types à l'exécution et se rajouter de potentiels ambiguïtés et bugs facilement évitables avec des vérifications de type à la compilation

---

Passons outre ce petit troll du dredi matin.

Réécrire Office en javascript permet :

1. de proposer le soft via le web
2. de proposer la même version en soft (electron, etc)
3. de décrire l'interface en html/CSS

On en dira ce qu'on veut, mais aujourd'hui pour faire des interfaces simplement, ce sont les moteurs de rendu web qui sont les plus pertinents : interface avec un design sur mesure, possibilité de dyamiser le tout, nombre de personnes connaissant le js, ...
Donc développer des softs en JS pour bureau ne me paraît pas étonnant.

Après, le JS reste un langage assez ignoble (mon humble avis), avec ses nombreux défauts. Les langages bas niveau (relativement) tels que C, C++, C# et autres Java vont rester majoritaires, notamment parce qu'ils permettent de créer des exécutables assez légers (avec Electron on se trimballe un moteur de rendu par logiciel), qui prennent beaucoup moins de place en mémoire (bon ça dépend, mais si mon éditeur de text pesait aussi lourd que Chrome pour éditer un fichier, je serais assez énervé) et sont plus rapides/réactifs.

Mais bon, parfois un programme écrit en JS peut être beaucoup plus rapide qu'un petit soft écrit en C-- (C avec des classes).

Citation:

---

C'est beaucoup, beaucoup, beaucoup trop long. Le simple fait d'exposer tes méthodes te prend la moitié de l'écran. Une classe c'est un moule à objet, c'est pas une lib.

---

Laisse moi devenir, tu fais partie de ces codeurs qui se prennent pour des cadors parce qu'ils travaillent sous VIM ? :roll:

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.



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.



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

---

Je n'ai jamais vu un Troll pareil dans un forum informatique. Tu sors de quelle planète franchement ? Tu fais du cobol objet ? Du html 1.0 avec du ColdFusion ?

Tu peux faire des choses dégueulasses avec n'importe quel langage ! Que ça soit du JS du C++ du C# ... C'est quoi cette idée que c'est impossible de faire du propre en procédurale ? Tu es un POO Fanboy ? Du moins si tu l'étais tu ne cracherais pas sur javascript, tu es un Fanboy des classes :) !

Tu peux être rassuré M$ n'abandonne pas C# et C++ ils vont continuer à utiliser le paradigme des CLASSES !

Open your mind my friend and the world will be beautifull

Citation:

---

s'amuser à perdre inutilement plus de 20% de puissance pour des vérifications de types à l'exécution et se rajouter de potentiels ambiguïtés et bugs facilement évitables avec des vérifications de type à la compilation

---

Je suis tout à fait d'accord avec ça, dans les langages non typés c'est incontournable pour éviter des erreurs et ne pas mettre des try catch partout... Non ??!! Les humains ne codent pas tout sans jamais aucune erreur que je sache... même parmis une même entreprise, voire team.
Donc vérifications, donc plus de code, donc moins vite.
Mais bon Microsoft est une entreprise, et le but d'une entreprise en économie est de faire de l'argent, donc c'est normal. Tant qu'on ne voit pas la différence entre un clic droit en C++ à 0.02sec et un clic droit en js en 0.03sec...

@Cxx-waves: ta réponse est assez subjective, à mon avis. Je me permets de te donner un point de vue légèrement différent

Citation:

---

Envoyé par Cxx-waves

de proposer le soft via le web

---

C'est déjà le cas, avec Office 365 ; mais je t'accorde que quitte à faire du web, c'est mieux d'être en full web.

Citation:

---

de proposer la même version en soft (electron, etc)

---

Là par contre, je ne suis pas d'accord, quitte à faire du desktop, autant ne pas faire du web et utiliser une techno plus adaptée. Voulais-tu plutôt parler du cross-platform ?

Citation:

---

de décrire l'interface en html/CSS

---

Ca, c'est un fait, pas un argument.

Citation:

---

On en dira ce qu'on veut, mais aujourd'hui pour faire des interfaces simplement, ce sont les moteurs de rendu web qui sont les plus pertinents : interface avec un design sur mesure, possibilité de dyamiser le tout, nombre de personnes connaissant le js, ...
Donc développer des softs en JS pour bureau ne me paraît pas étonnant.

---

Bon, là, je ne vais pas discuter, c'est très subjectif et ça dépend beaucoup des compétences de chacun. Mais je connais pas mal de "vieux" développeurs qui regrettent le ... WinForms ! En effet, pour eux, c'est ce qu'il y a de plus simple et fiable pour développer des interfaces graphiques. Et honnêtement, suivant le niveau d'exigence que tu te fixes, ce n'est pas forcément faux.

Citation:

---

Mais bon, parfois un programme écrit en JS peut être beaucoup plus rapide qu'un petit soft écrit en C-- (C avec des classes).

---

L'OBJET VAINCRA !!!!! (dixit un type qui fait aussi de la programmation fonctionnelle :P )

Citation:

---

Envoyé par LapinGarou

Je suis tout à fait d'accord avec ça, dans les langages non typés c'est incontournable pour éviter des erreurs et ne pas mettre des try catch partout... Non ??!! Les humains ne codent pas tout sans jamais aucune erreur que je sache... même parmis une même entreprise, voire team.
Donc vérifications, donc plus de code, donc moins vite.

---

Ce n'est pas qu'une question de robustesse du code, tu as aussi une question d'allocation mémoire, qui est bien plus efficace dans les langages typés.

Citation:

---

Je n'ai jamais vu un Troll pareil dans un forum informatique. Tu sors de quelle planète franchement ? Tu fais du cobol objet ? Du html 1.0 avec du ColdFusion ?

---

Du PHP sous Symfony et de l'Angular 6 (en TypeScript) principalement.

Citation:

---

Tu peux faire des choses dégueulasses avec n'importe quel langage !

---

Et tu peux te tuer en voiture même en mettant la ceinture ... ce n'est pas un argument valable pour ne pas la mettre.

Citation:

---

C'est quoi cette idée que c'est impossible de faire du propre en procédurale ?

---

Ce n'est pas impossible ... tant que l'application est très simple.

Citation:

---

Envoyé par Patrick Ruiz

Maintenant, quand on connaît les possibilités d’interfaçage de JavaScript avec des langages comme C++ on ne peut qu’en profiter comme Microsoft.

---

Justement, j'aimerais bien savoir comment on peut interfacer JS/C++. Parce que les C++ Addons ou la N-API de node, c'est franchement de la préhistoire par rapport aux outils d'interfaçage Python/C++ comme boost python ou pybind11.

Citation:

---

Que pensez-vous de l’approche adoptée par Microsoft ?

---

Peros j'ai déjà eu à écrire des UI en :
- HTML/CSS/JS
- QT
- MFC
- Swing
- JavaFx
- Android

et très clairement le combo html/css est le plus facile à mettre en oeuvre dès qu'on à besoin de personnaliser son UI. On peut aller très loin sans difficulté particulière , là ou d'autre demanderais des surcharge de classe et autre joyeuseté.

Pas étonnant donc que l'accent soit mit sur cette techno quand c'est possible pour réaliser des UI.

Citation:

---

Envoyé par SimonDecoline

Justement, j'aimerais bien savoir comment on peut interfacer JS/C++. Parce que les C++ Addons ou la N-API de node, c'est franchement de la préhistoire par rapport aux outils d'interfaçage Python/C++ comme boost python ou pybind11.

---

J'imagine que l'on peut le faire via les WebAssembly, non ? Enfin ça, c'est pour le côté client.

Citation:

---

Envoyé par Pyramidev

L'avantage d'une classe Url qui encapsule une URL, qui a pour invariant de classe que l'URL encapsulée est bien formée et dont le constructeur et les mutateurs s'assurent que l'invariant de classe est respecté, c'est que, une fois que l'objet est construit, on sait que l'URL contenue est valide.
Du coup, avec du typage statique, quand une fonction prend en paramètre un objet de type Url, on a la garantie que l'URL est bien formée. Sinon, l'objet n'aurait pas réussi à se construire et ne serait pas arrivé en paramètre. Donc on sait qu'on n'a pas besoin d'appeler la fonction qui vérifie si l'URL est bien formée.

---

C'est une mauvaise pratique que de faire faire autre chose à un constructeur que de l'assignation de valeurs. Pour plein de raisons à commencer par une toute simple, c'est que le code ne fait pas strictement ce qu'il dit. Comment je sais à la lecture d'un tel code const url = new Url('http://www.domain.tld') que je suis entrain de vérifier la validité de l'url ? C'est écrit explicitement où ? Qu'est-ce qui me garanti que je ne fais que ça et pas autre chose ?

Citation:

---

Envoyé par Pyramidev

Dans ton cas, concrètement, si tu as des fonctions qui parsent des URL, cela te permettra d'éviter d'écrire des tests unitaires inutiles dans lesquels tu passes à ces fonctions des URL mal formées pour voir si elles signalent bien une erreur : tu ne pourras pas leur passer des URL mal formées, puisque le constructeur de la classe Url t'en empêchera.

---

Je ne vois pas en quoi les tests sont inutiles, il faut bien tester la logique de vérification de l'url. Que tu implémentes la vérification dans ton constructeur ou que tu passes par une fonction n'y change rien. Ou bien tu envisages de ne pas tester ta logique de vérification ?

Citation:

---

Envoyé par Sodium

Laisse moi devenir, tu fais partie de ces codeurs qui se prennent pour des cadors parce qu'ils travaillent sous VIM ?

---

?!?

Si ça t'intéresse j'aime beaucoup WebStorm mais il faudrait que je prenne le temps de tester Visual Studio Code il parait qu'il est top. Juste faut prendre un moment pour découvrir l'ergo et les raccourcis.

Citation:

---

Envoyé par ijk-ref

Pour moi l'overkill c'est surtout s'amuser à perdre inutilement plus de 20% de puissance pour des vérifications de types à l'exécution et se rajouter de potentiels ambiguïtés et bugs facilement évitables avec des vérifications de type à la compilation.

---

En quoi l'usage d'un type vérifie-t-il la validité d'une url ? Ya une regexp qui est exécutée par magie parce que tu as écrit une classe ?

Citation:

---

Envoyé par Marco46

C'est une mauvaise pratique que de faire faire autre chose à un constructeur que de l'assignation de valeurs. Pour plein de raisons à commencer par une toute simple, c'est que le code ne fait pas strictement ce qu'il dit. Comment je sais à la lecture d'un tel code const url = new Url('http://www.domain.tld') que je suis entrain de vérifier la validité de l'url ? C'est écrit explicitement où ? Qu'est-ce qui me garanti que je ne fais que ça et pas autre chose ?

---

L'usage d'une Fabrique pour la classe Url permet justement d'assurer tous les contrôles nécessaires et d'occulter le constructeur standard de la classe.
L'utilisateur étant obligé de passer par la fabrique pour obtenir un objet Url, on est assuré que les contrôles sont toujours faits.

@Marco46 : Dans le cas de la classe Url, dans le constructeur, j'aurais mis en place une précondition : la chaîne passée en paramètre doit être une URL bien formée.

Début du code du constructeur avec une syntaxe C++ :

Code:

---

1 2 3 4

Url::Url(std::string_view str) { BOOST_ASSERT(isWellFormedUrl(urlStr))); // BOOST_ASSERT indique qu'il y a une erreur de programmation si la condition est fausse ... }

---

Le code appelant ressemblerait alors à ceci :

• Cas où on sait qu'une chaîne est déjà une URL bien formée :
  
  Code:

  ---

  1 2 3

  const auto urlStr = external_api::someFunctionWhichReturnsAWellFormedUrlString(); BOOST_ASSERT(isWellFormedUrl(urlStr))); Url url{urlStr};

  ---

• Cas où on fait le contrôle explicite :
  
  Code:

  ---

  1 2 3 4 5 6

  Url buildUrlOrThrowIfMalformed(std::string_view str) { if(isWellFormedUrl(str))) { return Url{str}; else throw MalformedUrlException{str}; }

  ---

• Cas où on appelle la fonction ci-dessus :
  
  Code:

  ---

  const auto url = buildUrlOrThrowIfMalformed(urlStr);

  ---

En C++, on peut configurer BOOST_ASSERT en définissant une fonction qui décrit son comportement quand la condition est fausse, par exemple arrêter le programme ou lancer une exception de type « Erreur de programmation » (donc qui dérive de std::logic_error).
Remarque : Si le code est très bien testé et que l'on veut essayer de gratter des performances, on peut aussi désactiver tous les BOOST_ASSERT d'un coup. Le choix se fait dans les options de compilation.

Mais, dans tous les cas, une fois que l'objet de type Url est construit, il n'y a plus besoin d'appeler de nouveau isWellFormedUrl.

Remarque : BOOST_ASSERT vient d'une bibliothèque C++ qui s'appelle Boost. La bibliothèque standard du C++ possède une macro assert, mais qui est moins personnalisable que BOOST_ASSERT, car assert n'a que deux comportements possibles quand la condition est fausse : ne rien faire ou arrêter le programme (le choix se fait dans les options de compilation).

8O

Mais pourquoi tu me sors du C++ alors qu'on parlait de l'utilité de la POO en JavaScript ?!?

@Hellwing

Génial encore des classes, et un bon vieux design pattern Factory des familles :aie:

Bon allez c'est bon on va arrêter le tir c'est plus intéressant.