Discussion :

[Neckara]

StringBuilder pense à des exemples d'applications internes en entreprise où il n'y a pas besoin de séparer le client et le serveur et où on peut directement coder des applications Desktop.
Alors, les performances des applications Desktop sont meilleures, car on ne s'encombre pas des échanges HTTP entre la partie graphique et la partie métier/calculs.

Mmm… je comprends mieux.

Mais je ne suis pas encore d'accord. Il vaut mieux parfois fournir une application web accessible à partir d'un VPN ou via une connexion login/mot de passe, que de faire installer une application Desktop pour plusieurs raisons :

• on a pas à s'enquiquiner avec toutes les configurations différentes de tous les employés ;
• on peut vouloir contrôler l'accès à l'application de manière fine, notamment si un employé quitte la boîte, ou tente de redistribuer l'application à des tiers ;
• cela évite de devoir passer par une étape d'installation.

Cela permet aussi de donner des accès à des partenaires, sans avoir à leur demander d'installer le logiciel et de faire confiance à ce logiciel.

[Neckara]

Pour rappel : je demande en quoi TS peut remplacer Java ou C# côté backend (donc pour coder les API qui fournissent et traitent les données pour le compte de la partie client).
Car autant je suis convaincu pour faire du web riche, bah de toute façon c'est JS et rien d'autre (donc TS ou alternatives), autant côté serveur, j'ai toujours pas pigé ce que TS peut apporter, et comment il peut être plus performant.

Je t'ai déjà répondu sur cet aspect.

Je prend le premier tuto sur DVP et bam ! Premier IDE proposé est un truc payant :
https://tarh.developpez.com/articles...er-typescript/

SublimeText avec quelques plugins, c'est gratuit, et ça marche super.

File-moi des liens, car jusqu'à présent, j'ai toujours pas vu la moindre doc me parler de connexion ODBC ou autre à une base de données depuis JavaScript !

Cf un de mes messages précédents.

Et rien ne t'empêche de faire une rapide recherche Google aussi.

Ensuite, si les I/O sont dépendants de l'OS, de l'environement d'exécution (browser, serveur web, script, je ne sais quoi) alors

Pas de l'OS, mais en effet de l'environement d'exécution. Tout simplement parce que l'accès aux fichiers via le navigateur est plus restreint pour des raisons de sécurité.

[Marco46]

Pour rappel : je demande en quoi TS peut remplacer Java ou C# côté backend (donc pour coder les API qui fournissent et traitent les données pour le compte de la partie client).
Car autant je suis convaincu pour faire du web riche, bah de toute façon c'est JS et rien d'autre (donc TS ou alternatives), autant côté serveur, j'ai toujours pas pigé ce que TS peut apporter, et comment il peut être plus performant.

Pour la 2ème fois c'est pas TS qu'il faut regarder mais la plateforme donc node (ou deno mais c'est encore très très jeune).

Moralité, JS oblige a écrire 10 fois plus de TU pour compenser les lacunes (laxitudes ?) du compilateur.

Depuis quand un système de typage statique valide le fonctionnel d'une appli ? Les TU servent à ça et au passage tu verras tes problèmes de choux et carottes ou alors c'est que tu testes mal ton programme ou que tu ne valides pas correctement tes données en entrée.

Ok, donc t'as une interface ITruc.
Tu as un objet Machin qui n'hérite pas de ITruc, puisque ça sert à rien d'indiquer explicitement l'héritage quand on souhaite implémenter une interface : le faire d'implémenter les méthodes suffit (en gros, du moment que mon objet implémente certaines méthodes il hérite automatiquement de toutes les interfaces qui déclarent ces interfaces).
TU ou pas, le jour où tu passes dans ton code et que tu dégages une méthode car tu penses qu'elle ne sert à rien, ce n'est qu'en rejouant tous tes TU (si tu as bien pensé à tous les écrire) que tu te rendra compte que t'as fait pété un module qui appelle ton objet dans un coin totalement hors de ton contexte.

Oui les TU servent entre autre à ça. En quoi est-ce un problème ?

Par ailleurs si tu ne vois pas ce type de problème lors de l'exécution de tes tests c'est que tu testes mal.

Plus je te lis, plus j'ai l'impression que pour toi l'automatisation des tests est en option.

Je prend le premier tuto sur DVP et bam ! Premier IDE proposé est un truc payant :
https://tarh.developpez.com/articles...er-typescript/

Mouai t'as du tomber sur à peu près le seul produit payant utilisé pour JS. D'ailleurs il est très bon je me le suis payé mais probablement parce que je me payais déjà IntelliJ (même éditeur) du temps où je faisais encore du Java.

Ceci dit tu as Visual Studio Code de Microsoft qui fait le même taf et qui est gratuit. Mais je préfère l'UX de WebStorm perso.

Ok, donc un backend, j'ai pas de navigateur. Je suis libre, je souhaite écrire un ERP en TS, j'ai une base de données Oracle (histoire d'avoir un truc aussi bien présent sur Linux que Microsoft), je souhaite donc exécuter des requêtes SQL dedans.
File-moi des liens, car jusqu'à présent, j'ai toujours pas vu la moindre doc me parler de connexion ODBC ou autre à une base de données depuis JavaScript !

Franchement tu le fais exprès ? Tu vas dans Google tu tapes "sql oracle node" et le premier résultat c'est https://oracle.github.io/node-oracledb/

Donc en gros Oracle fournit bien évidemment un connecteur pour Node.

Pour ton client lourd la référence est Electron, d'ailleurs Visual Studio Code (et une myriade d'autres app client lourd) écrit avec. Et tu auras du vrai multi-plateforme en bonus.

Ensuite, si les I/O sont dépendants de l'OS, de l'environement d'exécution (browser, serveur web, script, je ne sais quoi) alors :
- Vas-y la merde pour se former
- Vas-y la pérennité des outils

T'imagines bien qu'un navigateur n'a pas le droit d'écrire sur le système de fichier ... Donc il ne fournit pas d'API pour le faire.

T'as en gros 2 API :
- pour le browser https://developer.mozilla.org/fr/docs/Web/JavaScript
- pour node (backend, client lourd, embarqué, partout où node peut être installé, ...) https://nodejs.org/en/docs/

Les plateformes fournissent une couche d'abstraction qui fait que tu n'as pas à tenir compte de l'OS quand tu écris ton code, enfin pas plus qu'avec Java.

Non, ça c'est pas un besoin, c'est une conséquence de l'architecture web riche : quand t'as un écran qui fait 200 appels à des API serveur par seconde afin d'avoir un chargement asynchrone, c'est la conséquence des choix effectués (application web, asynchrone, etc.)

Oui les fronts modernes font beaucoup d'appels, mais pas à ce point là. C'est surtout la conséquence d'avoir beaucoup d'utilisateurs. Et c'est bien un besoin : Gérer une masse importante de clients qui font beaucoup de requêtes et pas forcément de manière linéaire. Il faut être capable de gérer les pics en scalant rapidement (là aussi node est très fort pour ça avec son temps de bootstrap ultra rapide).

Effectivement si tu développes une appli de gestion qui va servir à 10 personnes de 9h à 18h 5j/7j dans un SI d'entreprise peut être que Windev te suffirait.

Je suis de la vieille école, j'ai pas sous la main un casque pour regarder des vidéos.
Si tu as des liens avec de la LECTURE et des exemples (si possible complets) alors je suis preneur, je veux bien me former pour aller plus loin dans ce débat.

Si tu veux de la lecture tu as la documentation de Node.js (linkée ci-dessus).

Mais tu devrais vraiment regarder cette présentation parce qu'elle est très importante, elle est fondatrice, c'est le speech de Ryan Dahl (l'auteur de Node.js) à la JSConf de Berlin en 2009 dans lequel il présente pour la première fois Node.js. C'est là qu'il a expliqué les raisons du pourquoi du comment et tu y trouveras donc une grande partie des réponses à tes questions IMHO.

Lire du code source sans comprendre l'architecture qui sous-tend l'ensemble ne sert à rien, ça va t'embrouiller plus qu'autre chose il te faut d'abord les bases et elles sont dans cette présentation.

Tu pourras ensuite regarder la présentation de la même personne 10 ans plus tard qui est revenu présenter "deno" qui est un nouveau node basé sur TypeScript et qui corrige tous les problèmes de conception de node selon lui. Je te laisse chercher le lien il y a une actualité récente à ce sujet.

[Invité]

Que vient faire javascript, je me le demande...

C'est bien ce que je dis, le gars bosse en Typescript et alors ? Il parle de la façon de programmer : POO ou fonctionnel. JavaScript n'est pas du tout le coeur du sujet.

Donc c'est l'avenir... Peut-être, qui sait. A l'heure actuelle, le fonctionnel répond à des problématiques, mais pas à toutes.

A quelles problématiques le fonctionnel ne répond pas ? Et la POO, elle répond à toutes les problèmatiques ?

Sinon, vous en pensez quoi de l'évolution javascript -> typescript -> fonctionnel, vous pensez que cela va résoudre le problème de la gestion des états des objets ?

Si tu t'étais un peu renseigné sur Elm (mentionné dans l'article), tu le saurais.

[el_slapper]

Mais je ne suis pas encore d'accord. Il vaut mieux parfois fournir une application web accessible à partir d'un VPN ou via une connexion login/mot de passe, que de faire installer une application Desktop pour plusieurs raisons :

• on a pas à s'enquiquiner avec toutes les configurations différentes de tous les employés ;
• on peut vouloir contrôler l'accès à l'application de manière fine, notamment si un employé quitte la boîte, ou tente de redistribuer l'application à des tiers ;
• cela évite de devoir passer par une étape d'installation.

Ton point 1 n'a aucun sens dans une boite qui a un parc de machines uniforme. Ca existe, j'en ai vu (et comme presta, on m'a fourgué une machine standard, sans droits admins, comme les autres). Et si on récupère la machine au départ de l'employé, ça rend le point 2 caduc aussi. L'industrialisation des parcs IT, c'est quelque chose de réel. Certains font ça de manière extrêmement poussée. Chez un client, je ne pouvais même pas installer Python pour faire tourner un utilitaire. J'ai du bricoler en urgence un équivalent sous VBA EXCEL (le seul langage de programmation qui soit installé sur toutes les machines corporate.). Chez un autre client, ils scannaient tous les postes toutes les nuits, et si ils trouvaient in .exe non répertorié, le lendemain matin, les malabars de la sécurité bancaire venaient te taper sur l'épaule. Je les ai vus. On ne rigole pas avec ces mecs là.

Le point 3 est, et de loin, le plus intéressant à mon sens. On arrive pas (pour des raisons extrêmement variées, de la plus raisonnable à la plus inacceptable) à faire migrer certains de nos clients de notre vieux client lourd vers notre nouvelle solution en tout web. Résultat, à chaque nouvelle version majeure (au minimum 2 par an, pour des raisons réglementaires), ce grand CHU a son équipe IT qui passe personnellement sur 5000 postes - un par un - pour lancer à la main la mise à jour pendant que les gens ne bossent pas sur la machine. Oui, c'est old school. Non ils n'aiment pas ça. Oui, ils le font.

Pour moi, c'est le seul avantage réel du client léger sur le client lourd. Mais il est décisif. Le jour ou on arrive à les faire signer sur notre solution moderne web, ils n'auront aucun regret. Aucun. Malgré les innombrables avantages du vieux client lourd. Juste pour cette seule et unique raison. La mise à jour qui n'a pas besoin d'action sur le poste client.

[Neckara]

Ton point 1 n'a aucun sens dans une boite qui a un parc de machines uniforme. Ca existe, j'en ai vu (et comme presta, on m'a fourgué une machine standard, sans droits admins, comme les autres).

Cela dépend en effet, mais tu peux déjà avoir de base du Windows, puis les graphistes/managers sous Apple, et des devs sous Linux.

Et si on récupère la machine au départ de l'employé, ça rend le point 2 caduc aussi.

Mais ne pourrait-il pas c/c les fichiers de l'application sur un autre support ?

Après, tu as aussi certaines entreprises qui sont sous le modèle "bring your own device" pour économiser de l'argent. Bien que ce soit rare je présume.

L'industrialisation des parcs IT, c'est quelque chose de réel. Certains font ça de manière extrêmement poussée. Chez un client, je ne pouvais même pas installer Python pour faire tourner un utilitaire. J'ai du bricoler en urgence un équivalent sous VBA EXCEL (le seul langage de programmation qui soit installé sur toutes les machines corporate.). Chez un autre client, ils scannaient tous les postes toutes les nuits, et si ils trouvaient in .exe non répertorié, le lendemain matin, les malabars de la sécurité bancaire venaient te taper sur l'épaule. Je les ai vus. On ne rigole pas avec ces mecs là.

Ouch…

Et je présume que lorsque tu as besoin d'une chose supplémentaire (e.g. installer git), ça te demande un parcours du combattant ?

La mise à jour qui n'a pas besoin d'action sur le poste client.

Ils n'ont pas de systèmes style puppet (?) ou une autre connerie du genre qui permet de gérer tous les clients à distances (comme un lot) via un système central ?

[el_slapper]

Cela dépend en effet, mais tu peux déjà avoir de base du Windows, puis les graphistes/managers sous Apple, et des devs sous Linux.

Tu penses boite d'info. Je parle boite financière. Qui va exceptionnellement autoriser certains développeurs à installer Eclipse, mais c'est tout.

D'ailleurs, nous, on est une boite d'info, mais on a pas de graphistes. On sous-traite. Les techos(sauf l'IT) se fadent du Windows (pour partager la peine du client, TOUS les hôpitaux sont sous Windows coté poste client), et les commerciaux du Apple.

Mais ne pourrait-il pas c/c les fichiers de l'application sur un autre support ?

C'est relativement blindé,et ce genre d'applis a toujours quand même besoin d'un serveur en face. Même si le gros du boulot est fait coté client, les données sont quand même coté serveur. On parle de client lourd, pas d'applis autonome. Dont tu as un bel executable, qui ne te sers à rien sans accès au serveur. Et les accès au serveur sont quand même sécurisés. Même chez les clients ineptes.

Ouch…

ça fait mal, hein!!!

Et je présume que lorsque tu as besoin d'une chose supplémentaire (e.g. installer git), ça te demande un parcours du combattant ?

Git? Pourquoi faire? Alors qu'il suffit de copier les sources sur une machine qui servira entre autres de backup? (on m'a vraiment balancé ça. En 2014, avant que je rentre en édition de logiciel. Je suis sur qu'en 2020 il y a encore des gens qui pensent comme ça). Git, tu n'auras pas, et Python, il aurait fallu la signature d'un N+4, plus une semaine d'attente, plus le bon vouloir de l'équipe IT. D'ailleurs, j'ai fini par l'avoir, mon Python. Quand je n'en avait plus besoin. Et ce genre de mésaventures m'est arrivé à d'autres endroits.

C'est pour ça qu'une directrice de projet pressée m'a montré un jour comment pirater mon propre poste de travail pour pouvoir bosser pour elle (temps pendant lequel j'était prêté à son équipe : 3 semaines. Temps qu'il fallait pour avoir techniquement le droit de bosser sur son projet : trois semaines. En pleine affaire Kerviel.)

Ils n'ont pas de systèmes style puppet (?) ou une autre connerie du genre qui permet de gérer tous les clients à distances (comme un lot) via un système central ?

Les plus sérieux d'entre eux ont CITRIX. Ca, ça envoie du pâté, coté centralisation et maîtrise des postes clients. Un seul poste client "maître", et tout le monde se connecte à une image du maître. Mais ça coûte la peau et les os, et surtout, ça demande des gens d'une certaine qualité technique pour être maintenu. En dessous, tu as le genre de solutions que tu préconises, qui demande moins de budget et de maîtrise, mais c'est quand même pas à la porté de tous nos clients. En outre, quand tu installe sur client lourd à distance, tu as toujours le risque que l'utilisateur décide de débrancher-rebrancher parce-que ça le fait chier. Et là, pour rattraper le poste client, tu en as pour la journée. Donc ils préfèrent encore tout faire à la main, et ignorer les outils coûteux qu'on leur a donné, dont ils savent se servir...mais qui est systématiquement saboté par des utilisateurs furax (ça fait 20 ans que les personnels hospitaliers ont de bonnes raisons de se venger, vu ce qu'on leur fait subir. Et d'aucuns se vengent).

Ce genre de problèmes n'arrive pas sous CITRIX, mais ce n'est vraiment pas une solution à portée de beaucoup d’hôpitaux. Donc ils font à la main pour éviter les vengeances (justifiées, mais contre productives).

D’où la supériorité du client léger. Le docteur peut balancer son U.C. par la fenêtre, on lui en donne une autre, avec juste un lien, et il peut bosser à nouveau. Non, je ne caricature pas beaucoup. Ils sont vraiment furax. Ils l'étaient déjà avant les récents événements. Et je ne parle même pas des personnels infirmiers ou administratifs hospitaliers.

[Neckara]

[StringBuilder]

Le point 3 est, et de loin, le plus intéressant à mon sens. On arrive pas (pour des raisons extrêmement variées, de la plus raisonnable à la plus inacceptable) à faire migrer certains de nos clients de notre vieux client lourd vers notre nouvelle solution en tout web. Résultat, à chaque nouvelle version majeure (au minimum 2 par an, pour des raisons réglementaires), ce grand CHU a son équipe IT qui passe personnellement sur 5000 postes - un par un - pour lancer à la main la mise à jour pendant que les gens ne bossent pas sur la machine. Oui, c'est old school. Non ils n'aiment pas ça. Oui, ils le font.

Pour moi, c'est le seul avantage réel du client léger sur le client lourd. Mais il est décisif. Le jour ou on arrive à les faire signer sur notre solution moderne web, ils n'auront aucun regret. Aucun. Malgré les innombrables avantages du vieux client lourd. Juste pour cette seule et unique raison. La mise à jour qui n'a pas besoin d'action sur le poste client.

Il existe beaucoup d'outils qui permettent une mise à jour automatisée de manière parfaitement transparente, sans nécessiter de droits d'administration particuliers.
Aussi, de nombreux programmes proposent des packages MSI qui peuvent être déployés de manière automatisée et de manière très fine via des GPO https://fr.wikipedia.org/wiki/Strat%C3%A9gie_de_groupe.

Quant à la mise à jour, manuelle ou non, on a le même problème avec les navigateurs.
=> Même si ces dernières années ça s'est pas mal amélioré, beaucoup d'applications Web d'entreprise sont mises à mal à chaque nouvelles mises à jour des navigateurs : entre IE, Edge, Chrome et Firefox qui ont chacun leur propre vision des choses en termes de standards (CSS, JS, HTML, etc.) et les règles de sécurité déployées par défaut qui changent d'une version à l'autre, il n'est pas rare qu'après une mise à jour d'un navigateur nos clients soient obligés d'appliquer un patch à leur application ou revenir en arrière. Cela demande beaucoup de travail aussi.

[Marco46]

=> Même si ces dernières années ça s'est pas mal amélioré, beaucoup d'applications Web d'entreprise sont mises à mal à chaque nouvelles mises à jour des navigateurs : entre IE, Edge, Chrome et Firefox qui ont chacun leur propre vision des choses en termes de standards (CSS, JS, HTML, etc.) et les règles de sécurité déployées par défaut qui changent d'une version à l'autre

Ces problèmes disparaissent comme par enchantement dès lors que l'on cesse de chercher à supporter les navigateurs de Microsoft. Les variances dans le support des standards entre Chrome et Firefox sont infimes.

Heureusement Microsoft a décidé d'arrêter d'enchoser toute le monde avec ses browsers en abandonnant le développement de ses moteurs de rendu et JS pour adopter Blink et V8. Pas top en terme de concentration monopolistique, j'aurais préféré les voir adopter Gecko et SpiderMonkey.

Ce problème de support de IE dans les SI est du principalement à de vieilles applications web développées dans des technos pourries qui ne fonctionnent que dans IE.

Je rajouterais un point 4, si on adopte une culture DevOps, on livre le plus souvent possible, jusqu'à plusieurs fois par jour, et de fait c'est beaucoup plus facile sur du client léger que sur du client lourd.

On pourrait également ajouter un point 5, avoir du client léger permet de faire du dev mobile quasi gratuitement en développant ses IHM en mobile first. Alors OK pour une application de comptabilité c'est peut être pas utile, mais pour une gestion commerciale c'est déjà beaucoup beaucoup beaucoup plus intéressant.

Bref, là on part vraiment en hors-sujet.

[el_slapper]

Il existe beaucoup d'outils qui permettent une mise à jour automatisée de manière parfaitement transparente, sans nécessiter de droits d'administration particuliers.
Aussi, de nombreux programmes proposent des packages MSI qui peuvent être déployés de manière automatisée et de manière très fine via des GPO https://fr.wikipedia.org/wiki/Strat%C3%A9gie_de_groupe.

Encore une fois, ça présuppose que les sites clients ont une IT qui sait ce qu'elle fait. Il n'y a pas assez de gens en IT qui avent ce qu'ils font pour toutes les entreprise de France.

(.../...)Je rajouterais un point 4, si on adopte une culture DevOps, on livre le plus souvent possible, jusqu'à plusieurs fois par jour, et de fait c'est beaucoup plus facile sur du client léger que sur du client lourd.

Ca, ça présuppose qu'on est en SAAS. Nos collègues du moyen Orient en sont déjà là. L'avantage d'états jeunes (dans leur forme moderne, en tous cas), il n'y a pas de stratifications historiques et de couches épaisses impénétrables. Le SAAS en France, c'est une belle idée. J'en avait parlé en 2014 quand je suis entré, ça me paraissait une étape évidente; réponse à l'époque : "les clients ne sont pas prêts". En 2020, toujours pas. Et ils veulent tous, je dis bien TOUS, des mises à jour rares en mode big bang. Donc, à chaque fois, on a trois personnes mobilisées toutes la nuit pour mettre à jour un hopital client. Et je parle de ceux qui sont déjà passés en client léger, donc pas les plus rétrogrades.

On pourrait également ajouter un point 5, avoir du client léger permet de faire du dev mobile quasi gratuitement en développant ses IHM en mobile first. Alors OK pour une application de comptabilité c'est peut être pas utile, mais pour une gestion commerciale c'est déjà beaucoup beaucoup beaucoup plus intéressant.(.../...)

On a commencé à faire de l'interface "mobile enabled", avec pour idée de base que pour une infirmière qui se déplace beaucoup, une tablette, c'est de la balle (même si les médecins et les administratifs restent généralement sur poste fixe). Résultat? Succès d'estime aux USA (essentiellement chez les militaires), en Australie (spécialement pour les docteurs perdus dans le bush), refus absolu en Europe, au Chili (y compris les militaires), en Thaïlande (même si notre prochain gros client là bas est en train de reconsidérer sa position), en Chine (enfin, la Chine, c'est compliqué), en Afsud. Succès total au Moyen Orient, comme d'habitude.

Mon expérience, c'est que le type de client influe beaucoup plus que le type d'application, sur ce genre de décision. Nos clients du moyen orient sont obsédés par l'idée de paraître moderne, ce qui leur fait parfois commettre des impairs, mais c'est globalement beaucoup plus facile de bosser avec eux qu'avec des occidentaux arque-boutés sur leurs vieilles habitudes.Un autre paramètre : certains sont plus pragmatiques, par la force des choses. Le docteur Australien qui va faire 150km en coucou pour aller soigner un aborigène ou un fermier qui a fait un AVC n'a pas envie de se trimballer un poste fixe avec lui, ni même un laptop à l'autonomie limitée - et il voit tout de suite l’intérêt d'une interface conçue pour téléphone mobile, là ou les mandarins de la médecine Française claquemurés dans leurs bureaux richement décorés exigeront un ordinateur fixe à 3000 boules pour exprimer leur statut social. Alors qu'ils ont exactement le même boulot, la même compétence, et notifieront les mêmes prescriptions sur la même appli.

Et les clients en France qui ont vu la mobile enabled et ont accepté l'idée, que dans un futur lointain, peut-être..... exigent de remettre dedans tout ce qui faisaient leurs petites habitudes. Donc on va voir un mobile enabled custom France, pas vraiment mobile . Enfin, un peu quand même.....mais rien à voir avec la nouvelle interface épurée et bien plus efficace avec laquelle les Moyen-orientaux travaillent déjà depuis presque un an.

[Invité]

J'ai du rater un truc mais c'est quoi le rapport avec le débat POO vs fonctionnel ?

[StringBuilder]

Je pense que sans l'exemple concret de code "POO" et "fonctionnel" de l'auteur de l'article, dans un même langage si possible, puisque je le répète, on choisi rarement un langage "car c'est le plus adapté" mais "parce que c'est le plus adapté de ceux qu'on maîtrise", je pense qu'on tournera de toute façon en rond.

Faire des "fonctions pures" (la base du fonctionnel) avec un langage tel que C, C#, Java, TypeScript passe obligatoirement par des normes de développement, sans lien avec le langage et le compilateur lui-même (ces langages se moquent de ce qu'on fait à l'intérieur d'un bloc { }), et à l'inverse faire de la POO avec des langages purement fonctionnels, c'est pas possible tout court... reste ceux qui sont le cul entre deux chaises (par exemple F#) et là encore, jusqu'à présent, seul l'auteur à compris quelle était sa problématique et sa solution pour la résoudre.

[Mat.M]

Faire des "fonctions pures" (la base du fonctionnel)

attention au sens que vous voulez donner à fonctions pures.
Un rapide coup d'oeil dans une encyclopédie bien connue en ligne nous dit que

* Sa valeur de retour est la même pour les mêmes arguments (pas de variation avec des variables statiques locales, des variables non locales, des arguments mutables de type référence ou des flux d'entrée).

* Son évaluation n'a pas d'effets de bord (pas de mutation de variables statiques locales, de variables non locales, d'arguments mutables de type référence ou de flux d'entrée-sortie).

Est-ce bien cela ?

D’ailleurs c'est a cause que la monté de la complexité du développmeent uqe l'on a inventé les IDE, les tests unitaires, les gestionnaires de version et le travail d'équipe,

oui d'accord mais même avec un outil qui se veut complet comme Visual Studio ça n'empêche pas, si on est mauvais programmeur de faire du code spaghetti ou code lasagne

c'est comme comparé une video fais par un youtuber seul (le dev des années 80) et hollwood ou tu as un réalisateur, un cadreur, des graphistes, des enregistreur de son...etc.

on dérive du sujet principal mais là il est question d'industrialisation d'un projet plus qu'autre chose.
Cependant combien de blockbusters Hollywood voire même des films français avec budget important ont fait des gros bides une fois distribués dans les salles ?

[Marco46]

on dérive du sujet principal mais là il est question d'industrialisation d'un projet plus qu'autre chose.

Non on parle de paradigme de programmation. L'industrialisation dans le logiciel démarre après le commit du développeur donc après la programmation. Il s'agit d'industrialiser la gestion du livrable (son build, son packaging, son déploiement, etc ...) pas son écriture. La partie conception / écriture relève de l'artisanat.

[StringBuilder]

attention au sens que vous voulez donner à fonctions pures.
Un rapide coup d'oeil dans une encyclopédie bien connue en ligne nous dit que

Est-ce bien cela ?

Oui, à ma connaissance, ni C, C++, C#, Java n'implémente de mécanisme capable d'indiquer :
- une fonction (fonction et procédure ont la même syntaxe, au "void" près)
- que la fonction est déterministe
- que la fonction ne modifie rien d'autre que des variables locales
Sans trop m'avancer, je pense que JavaScript et TypeScript sont lotis de la même manière.

Pourtant, quand on va sur cette même encyclopédie, il est indiqué que les "fonctions pures" sont la base du langage fonctionnel, qui ne permet de rien écrire d'autre que de telles fonctions (ce qui m'a fait sourire, puisque la définition d'une fonction est "ne fait rien mais vaut quelque chose", cela résume le langage fonctionnel à "ça coûte bien cher pour pas faire grand chose" )

-- Edit : cependant, les dernières évolutions de C# 9.0 donnent en grande partie raison à cet article, même si j'aimerais quand même voir du code pour de rendre compte de ce que ça apporte réellement (en terme de lisibilité et de maintenabilité, ce dont je ne suis absolument pas convaincu, par exemple le nouveau "new" qui se passe du nom de la classe, ou les "covariant method" qui permettent de retourner un type différent dans la surcharge d'une méthode, du coup on crée un objet mais difficile de savoir ce qu'on a réellement créé)

https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/

On note notamment l'apparition des "objets record", qui sont des objets "valeur" (pas pigé pourquoi ne pas avoir réutilisé les structures qui existent déjà pour ça) dont toutes les propriété ton immutables (uniquement initialisables) ce qui implique qu'une fonction qui manipule un tel objet ne pourra pas le modifier, on se rapproche à petits pas de la fonction pure.

[Invité]

Oui, à ma connaissance, ni C, C++, C#, Java n'implémente de mécanisme capable d'indiquer :
- une fonction (fonction et procédure ont la même syntaxe, au "void" près)
- que la fonction est déterministe
- que la fonction ne modifie rien d'autre que des variables locales
Sans trop m'avancer, je pense que JavaScript et TypeScript sont lotis de la même manière.

C n'a pas de lambda et ne gère pas les fonctions comme des first-class citizen. Ce n'est donc pas un langage fonctionnel et je ne vois pas pourquoi on en parle ici.

C++ implémente deux des trois points que tu cites. Les lambda interdisent de modifier autre chose que les variables locales et les variables indiquées dans la closure. Je ne connais pas C# et Java, mais je pense que ça doit être pareil.

Enfin, il est tout à fait possible de coder avec des fonctions pures en C++, C# ou Java. C'est juste que c'est le développeur qui doit faire attention à ne pas mettre d'instructions impures car le compilateur ne le détectera pas toujours. Après c'est effectivement mieux si le compilateur assure que les fonctions sont pures mais il n'y a que les langages fonctionnels purs qui font ça, par exemple Elm, Haskell. Mais ça n'empêche pas de faire de la programmation fonctionnelle, d'ailleurs Common Lisp et Ocaml autorisent les fonctions impures. Je crois que Rust demande d'indiquer les données mutables donc on doit pouvoir distinguer assez explicitement les fonctions pures des fonctions impures.

Pourtant, quand on va sur cette même encyclopédie, il est indiqué que les "fonctions pures" sont la base du langage fonctionnel, qui ne permet de rien écrire d'autre que de telles fonctions (ce qui m'a fait sourire, puisque la définition d'une fonction est "ne fait rien mais vaut quelque chose", cela résume le langage fonctionnel à "ça coûte bien cher pour pas faire grand chose" )

Encore une fois, on peut coder avec des fonctions pures dans beaucoup de langages. Quant aux sarcasmes de mauvais goût, je ne vois vraiment pas ce que ça prouve. Tu devrais plutôt essayer vraiment la programmation fonctionnelle, ou mieux un vrai langage fonctionnel comme F# si tu connais déjà C# ou Elm si tu connais déjà JavaScript (https://guide.elm-lang.org/).

[Pyramidev]

Je crois que Rust demande d'indiquer les données mutables donc on doit pouvoir distinguer assez explicitement les fonctions pures des fonctions impures.

En Rust, on a les const functions qui peuvent être exécutées à la compilation et qui sont pures.
Mais, pour les fonctions qui ne sont pas exécutables à la compilation, il n'y a pas de moyen de distinguer dans la signature de la fonction les fonctions pures des fonctions impures (qui peuvent interagir avec l'extérieur du programme comme le système de fichiers, la base de données, etc.)

Historiquement, d'après Graydon Hoare, le créateur du langage Rust, à l'origine, les fonctions en Rust étaient pures par défaut et il fallait utiliser un mot-clef, io, pour les rendre impures. Mais cette idée a été abandonnée. Source : https://mail.mozilla.org/pipermail/r...il/003926.html

Extraits choisis :

A long time ago we had an effect system and we made pure the default (since we didn't want people accidentally leaving it out due to sloth) and we made the impure specifier a very small and reasonable keyword: "io". It was still a heavy complexity bill (required a full extra dimension of subtyping, parametricity, etc.) and _still_ had people breaking the rule with `unsafe`, which meant that the putative benefits like "can do compile time evaluation" or "can spread on a GPU" weren't there anyways. And people couldn't do simple things like "put a printf in here for logging" (much like in haskell).

The split is too much for C programmers to accept; anywhere we try to draw the line appears to cause a lot of anger and resentment over mandatory type-system fighting.

[StringBuilder]

Enfin, il est tout à fait possible de coder avec des fonctions pures en C++, C# ou Java. C'est juste que c'est le développeur qui doit faire attention à ne pas mettre d'instructions impures car le compilateur ne le détectera pas toujours.

Donc c'est bien ce que je dis, ça relève de la norme de développement, et le compilateur ne sera d'aucune aide.
Par conséquent, difficile d'imposer cette méthodologie à une équipe, d'autant plus si c'est une équipe hétérogène (projets libres par exemple).

Après c'est effectivement mieux si le compilateur assure que les fonctions sont pures mais il n'y a que les langages fonctionnels purs qui font ça, par exemple Elm, Haskell.

Tu oublies T-SQL (qui n'est pourtant pas du tout un langage fonctionnel) : impossible de modifier des données dans une fonction, et pour certains traitement elle doit être déterministe. Par conséquent, T-SQL est capable de vérifier qu'une fonction est "pure".

[Invité]

Historiquement, d'après Graydon Hoare, le créateur du langage Rust, à l'origine, les fonctions en Rust étaient pures par défaut et il fallait utiliser un mot-clef, io, pour les rendre impures. Mais cette idée a été abandonnée. Source : https://mail.mozilla.org/pipermail/r...il/003926.html

Merci pour le lien. C'est vraiment intéressant de voir la démarche de Rust.

Donc c'est bien ce que je dis, ça relève de la norme de développement, et le compilateur ne sera d'aucune aide.
Par conséquent, difficile d'imposer cette méthodologie à une équipe, d'autant plus si c'est une équipe hétérogène (projets libres par exemple).

En suivant cette logique, on ne devrait pas faire de POO parce que les compilateurs ne vérifient pas que le code respecte les principes SOLID.

Tu oublies T-SQL (qui n'est pourtant pas du tout un langage fonctionnel) : impossible de modifier des données dans une fonction, et pour certains traitement elle doit être déterministe. Par conséquent, T-SQL est capable de vérifier qu'une fonction est "pure".

Génial. Et sinon tu as essayé un peu sérieusement un langage fonctionnel (comme par exemple, ceux que j'ai mentionné) ou tu préfères troller sur des points de détail ?