Le topic de la programmation: Et envoyez des sioux!

[Charmide]

La valeur de []+{} est consistante entre les plateformes.

[Orhin]

Le sel est pur.

[William Vaurien]

http://lmgtfy.com/?q=framework+.net+4.7
Et tu peux lier l'installateur .Net à ton projet :

Suffit de faire un package complet.

Oui, sauf que quand le framework ne veut pas s'installer, ça te fait une belle jambe... On retombe dans la même merde qu'un prog java sans sa JVM...

et mon PC refuse 4.7, mais accepte 4.6.2. Et seulement avec l'installeur complet, pas le web installer qui se fait bloquer sur mon poste. Tu parles d'un bordel !

J'avais juste besoin d'évacuer ma frustration et de cracher un peu sur .NET...


Et je me disais aussi que ça manquait de blague sur ce bon vieux javascript, le cousin idiot qui est devenu la star du moment...
A force de faire évoluer le langage, il va bien finnir par ressembler à Java, et à force de faire des 'transpiler' (ce mot ), javascript 'nature' va bien finir par redevenir le truc un peu inutile qu'il était avant...

[Charmide]

Ouais, plus personne (dans les bons) ne fait du javascript en vrai, la question c'est devenu quel framework tu utilises voire quel truc tu compiles.
Donc au final, que le langage soit caca a peu d'importance.

Mais bon j'ai fait genre 12 pages pour défendre "l'écosystème" sur ce topic ou celui du web il y a quelques mois, du coup j'ai arrêté et je me content de blagues

- - - Mise à jour - - -

J'ai commencé un side-project en Elm au boulot (#yolo), pour l'instant personne n'a remarqué j'attends de voir les réactions

[William Vaurien]

Tiens je viens de voir ça: doppio une JVM en typescript => execution de code java dans le browser (sans plugin)

This demo comes packed with a number of JVM languages (Scala, Groovy, Scheme),
some basic programs and utilities (javac, accounting software), and standard
shell commands that interact with our in-browser filesystem!
...
Hop into Clojure's repl with the `clojure` command. Or try `nashorn`,
repl for JavaScript running on the JVM!

[Orhin]

Ouais, plus personne (dans les bons) ne fait du javascript en vrai, la question c'est devenu quel framework tu utilises voire quel truc tu compiles.
Donc au final, que le langage soit caca a peu d'importance.

Ceci.

Et c'est d'ailleurs vrai pour tous les langages en fait.
Framework + environnement >>> qualités intrinsèques du langage

A moins de vouloir réinventer la roue et tout recoder soit même à chaque fois bien sur (ou d'avoir des très gros besoins de perf).

[William Vaurien]

En même temps avec des aberrations () come node.js, il y a des dev qui se font avec du js. Et du coup les compétences 'brutes' en js sont demandées...

[Charmide]

Ceci.

Et c'est d'ailleurs vrai pour tous les langages en fait.
Framework + environnement >>> qualités intrinsèques du langage

A moins de vouloir réinventer la roue et tout recoder soit même à chaque fois bien sur (ou d'avoir des très gros besoins de perf).

Tu as raison, c'est loin d'être JS spécifique. On y surestime l'importance de la qualité du langage parce qu'il est particulièrement caca mais je pense que c'est une erreur commune.

Au-delà de l'aspect framework+environnement, ça me rappelle certains fanatiques de la programmation fonctionnelle qui font croisade pour que tout le monde utilise Haskell alors qu'ils devraient plutôt passer leur temps à insister sur des design patterns ou des bonnes pratiques qui découlent de l'approche fonctionnelle et que tu peux appliquer dans n'importe quel langage et contexte.

- - - Mise à jour - - -

Tiens je viens de voir ça: doppio une JVM en typescript => execution de code java dans le browser (sans plugin)

Tiens je crois pas que j'avais vu ça passer, c'est bô

C'est vraiment attaqué de partout ce problème entre les trucs type ScalaJS, cette approche là, le webassembly...

[Dross]

Donc non, le framework .net n'est pas fourni

Il est fourni, mais pas les versions postérieures à la dernière mise à jour (ton windows n'est donc pas à jour).
Comme tu pourra le voir avec l'historique des versions.

Ba oui, parce que contrairement à Java qui n'est pas lié plus que ça à l'OS (une version windows 32 et une 64, pareil pour Linux...), il y a douze milles variantes du framework .net en fonction de l'os, des patchs , des la version en cours et de l'âge du capitaine.

Pas douze milles : 13 depuis la première version (cf lien plus haut).
On compare avec le bordel Java ?

Alors que bon, un programme Java (ou Kotlin, ou Groovy ou Scala) se package très bien avec sa propre JVM et peut s'installer et se lancer sans avoir besoin de droit admin...

C'est ce que fait le nouveau Framework .NET Core, c'est pour ça que ça tourne sur toutes les archi d'ailleurs.

Et pour savoir la version courante ??? java -version. Merci.

Ça c'est quand l'installeur d'Oracle rajoute le chemin vers l'exécutable java dans la variable d'environnement. Pour l'avoir fait il y a 3 semaines, je peut te dire que ce n'est pas le cas.


Engueule le mec qui t'a fourni du code sur la dernière version de .NET sans l'installeur pour te l'installer, car c'est pas très pro... Sans parler du fait qu'il est à peut prêt sûr qu'il n'utilise rien du 4.7, et aurait pus te l'envoyer en 4.6.

[Charmide]

En même temps avec des aberrations () come node.js, il y a des dev qui se font avec du js. Et du coup les compétences 'brutes' en js sont demandées...

Moi ça me tuerait de m'entendre demander ça. Si t'es RH pourquoi pas, tu fonctionnes par mots-clés, on te dit JS tu cherches JS.
Mais si c'est un techos/opérationnel, au secours. Ils veulent quoi, de la compréhension de la programmation par prototypes?

[Frypolar]

La valeur de []+{} est consistante entre les plateformes.

Tout à fait. Ça permet d’ailleurs de faire ce genre de chose : http://jsfiddle.net/ds1yqhhz/

- - - Updated - - -

Tu as raison, c'est loin d'être JS spécifique. On y surestime l'importance de la qualité du langage parce qu'il est particulièrement caca mais je pense que c'est une erreur commune.

Euh ouais enfin en js il peut t’arriver des saloperies sur un paquet de frameworks juste à cause du langage de base qui est daubé. C’est tout l’intérêt de TypeScript et compagnie, on pose un bon gros coussin sur le js et on l’étouffe. Ensuite on est à peu près tranquille.

[Teocali]

Il ose insulter l'assembleur avec le mot en trois lettres interdit !
Brûlons-le !

Tiens je viens de voir ça: doppio une JVM en typescript => execution de code java dans le browser (sans plugin)

Ok, pause. On parle d'une JVM (execution de bytecode) ou d'un interpreteur ? S'pas la même chose.

Et sinon, si j'ai bien pigé, le mec a &écrit un programme dans un langage transpilé en javascript pour convertir du code écrit dans un troisième langage vers JS toujours... le bordel.

Et "Nashorn", ça fait quand même JS->Java->JS... Rassurez-moi, s'tun troll project ?

[Møgluglu]

Non, l'intérêt est que tu peux faire tourner ça dans un browser écrit en Java qui tourne dans une JVM sous jslinux.

Sinon, en parlant de Java, IBM a libéré sa JVM. Pour ceux que ça intéresse de voir comment c'est fait un JIT :
https://github.com/eclipse/openj9
https://www.slideshare.net/DanHeidin...pen-source-jvm

[Sangoon]

En même temps avec des aberrations () come node.js, il y a des dev qui se font avec du js. Et du coup les compétences 'brutes' en js sont demandées...

Désolé, si je vous "choque" ou si ma question vous parait naïve, mais concrètement, en quoi Node.js est-il une aberration ?

De mon point de vue, y a pas grand chose de plus efficace à l'heure actuelle pour faire un backend http rapidement, et performant.

[Dross]

Non, l'intérêt est que tu peux faire tourner ça dans un browser écrit en Java qui tourne dans une JVM sous jslinux.

Quelle est cette sorcellerie ?

[Charmide]

Euh ouais enfin en js il peut t’arriver des saloperies sur un paquet de frameworks juste à cause du langage de base qui est daubé. C’est tout l’intérêt de TypeScript et compagnie, on pose un bon gros coussin sur le js et on l’étouffe. Ensuite on est à peu près tranquille.

Je sais bien pour TypeScript. C'était assez explicitement inclus dans mon "plus personne (dans les bons) ne fait du javascript en vrai, la question c'est devenu quel framework tu utilises voire quel truc tu compiles."

Par contre je veux bien des exemples concrets sur les "saloperies" qui t'arrivent à cause du langage de base. J'ai bossé sur du angular 1.X pendant un bon moment sans "coussin par dessus" et j'en suis pas mort.
A te lire (encore que t'es pas le pire) on a l'impression que tous les jours tu passais 2h à débugger un truc au comportement cosmique à cause du fait que {}+[] ait un résultat chelou, ou bien à essayer de te battre contre le langage qui ne te permet pas d'implémenter une fonctionnalité critique dans ton app parce que quand t'évalues 2 == [[2]] c'est vrai.

Perso la seule conséquence concrète du fait que le langage soit tout pourri, c'est qu'on se marre bien et qu'on peut faire des blague dessus. Et les mecs qui font pas de web peuvent se palucher sur leur supériorité intellectuelle.

A part ça, en vrai, on a fait des tonnes de trucs pour se simplifier la vie et on a pas à toucher aux entrailles.
Ce sur quoi t'as l'air d'être d'accord avec moi, mais c'était vrai avant ton TypeScript, ou Elm, ou Babel+JS6, ou de mettre une JVM dans ton navigateur, ou même des trucs plus light genre Flow.

La souffrance en terme de tooling remonte probablement pré-SPA, disons circa 2005, mais même à l'époque je doute que coder en JS plutôt qu'en <n'importe quel language de script qui à l'inverse de JS est foutu de façon logique> aient hanté leurs nuits quand ils avaient à mettre de l'~AJAX~ sur leur oueb page 2.0

... Et merde je me suis fait avoir je recommence avec ces pavés.

- - - Mise à jour - - -

Désolé, si je vous "choque" ou si ma question vous parait naïve, mais concrètement, en quoi Node.js est-il une aberration ?

De mon point de vue, y a pas grand chose de plus efficace à l'heure actuelle pour faire un backend http rapidement, et performant.

Si les gens disent ça, c'est qu'il y a juste pas d'intérêt, à part ouvrir un champ d'applications (le backend) à des mecs qui ont la connaissance de JS uniquement et pas envie d'apprendre un nouveau langage. Tu pourrais argumenter que c'est un mérite mais bof.

Ensuite, il y a ce qui relève des qualités intrinsèques de Javascript par rapport aux autres langages qui sont disponibles en backend, là où l'argument n'e(tait)st pas applicable dans le navigateur.

Pour te répondre sur le backend HTTP rapide, tu pouvais le faire en Flask, Sinatra, ou 12 autres trucs différents en bien plus rapidement (on peut faire la course entre npm et pip ) avant que Node.JS débarque.

Après, moi je ne n'appelerais pas ça une abbération. Hakuna matata, qu'on réinvente la roue et qu'on essaie 12 000 trucs différents, c'est comme ça qu'on avance. Y'en aura 11 999 overhypé qui servent à rien et 1 qui fera avancer le schmilblick.
Les mecs malins choisiront des techs adaptées, ou à défaut seront efficace de toute façon.
Et ça sera toujours plus intéressant que de faire du FORTRAN

[Sangoon]

...
Pour te répondre sur le backend HTTP rapide, tu pouvais le faire en Flask, Sinatra, ou 12 autres trucs différents en bien plus rapidement (on peut faire la course entre npm et pip ) avant que Node.JS débarque.
...

Ok question faisabilité on peut tout faire depuis un bail, mais question démocratisation du reactive programming, node.js à quand même mis un bon coup de pied dans la fourmilière non ?

[Charmide]

Possible. J'ai fait très peu de node donc je n'ai pas d'avis sur le type d'architecture ou de design patterns qui y sont utilisés. Le "reactive programming" m'intéresse davantage même si c'est un de ces mots à 12 définitions.
Du coup c'est un peu comme je disais plus haut: dans ce cas, ce genre de trucs c'est plus important que le langage et en est largement indépendant.

Ca me fait penser que node a aussi a une réputation de générer des sacs de noeud indebuggables via stacks de callbacks de 3 mètres de haut, c'est ce qu'avance certains pour dire que c'est affreux.

[Møgluglu]

Au-delà de l'aspect framework+environnement, ça me rappelle certains fanatiques de la programmation fonctionnelle qui font croisade pour que tout le monde utilise Haskell alors qu'ils devraient plutôt passer leur temps à insister sur des design patterns ou des bonnes pratiques qui découlent de l'approche fonctionnelle et que tu peux appliquer dans n'importe quel langage et contexte.

Je suis le premier à me moquer des Haskelleux (enfin surtout des Camlistes), mais là, faut pas déconner.

Les design patterns sont les organigrammes du 21e siècle. On utilise les designs patterns comme le programmeur des années 50 dessinait des organigrammes au gabarit sur papier quadrillé :

Comme les organigrammes ont disparu dans les années 70 avec les langages structurés, les design patterns disparaîtront quand les langages évolueront. Quand on en arrive à devoir s'imposer des disciplines de programmation, c'est un bon indice que les langages qu'on utilise sont inadaptés.
(Oui, j'ai déjà dit ça d'UML dans le précédent topic, mais je fourre les design patterns dans le même sac.)

Ta remarque s'applique parfaitement aux fanatiques de la programmation structurée, ceux qui faisaient croisade pour que tout le monde utilise Pascal avec des if-then-else et des boucles dans les années 70. Alors qu'ils auraient du plutôt passer leur temps à insister sur comment dessiner des organigrammes ou des bonnes pratiques qui découlent de la programmation structurée et que tu peux appliquer dans n'importe quel langage avec des goto.

Perso la seule conséquence concrète du fait que le langage soit tout pourri, c'est qu'on se marre bien et qu'on peut faire des blague dessus. Et les mecs qui font pas de web peuvent se palucher sur leur supériorité intellectuelle.

Le code n'est pas lu que par des programmeurs et des interpréteurs. Un bon langage, c'est un langage facilement analysable par les compilateurs et les outils de vérification. Comme conséquence concrètes, on peut commencer par toutes les failles de sécurité qui auraient pu être évitées ou détectées automatiquement avec un langage plus facilement analysable.

[Sangoon]

Possible. J'ai fait très peu de node donc je n'ai pas d'avis sur le type d'architecture ou de design patterns qui y sont utilisés. Le "reactive programming" m'intéresse davantage même si c'est un de ces mots à 12 définitions.
Du coup c'est un peu comme je disais plus haut: dans ce cas, ce genre de trucs c'est plus important que le langage et en est largement indépendant.

Ca me fait penser que node a aussi a une réputation de générer des sacs de noeud indebuggables via stacks de callbacks de 3 mètres de haut, c'est ce qu'avance certains pour dire que c'est affreux.

Le "callback hell" que tu décris en fin de ton message est effectivement un problème avec Node.js mais peut être reglé par l'utilisation de promesses, en tout cas dans tous les cas d'usages que j'ai rencontré ça fait bien le job en plus de rendre le code bien plus lisible.

[Orhin]

Ca me fait penser que node a aussi a une réputation de générer des sacs de noeud indebuggables via stacks de callbacks de 3 mètres de haut, c'est ce qu'avance certains pour dire que c'est affreux.

C'était vrai à ses début.
Maintenant si t'utilises des Promise ou des Observable, t'as absolument plus ce soucis.

[Charmide]

Je suis le premier à me moquer des Haskelleux (enfin surtout des Camlistes), mais là, faut pas déconner.

Les design patterns sont les organigrammes du 21e siècle. On utilise les designs patterns comme le programmeur des années 50 dessinait des organigrammes au gabarit sur papier quadrillé :
http://www.fh-jena.de/~kleine/histor...dsize-huge.jpg
Comme les organigrammes ont disparu dans les années 70 avec les langages structurés, les design patterns disparaîtront quand les langages évolueront. Quand on en arrive à devoir s'imposer des disciplines de programmation, c'est un bon indice que les langages qu'on utilise sont inadaptés.
(Oui, j'ai déjà dit ça d'UML dans le précédent topic, mais je fourre les design patterns dans le même sac.)

Ta remarque s'applique parfaitement aux fanatiques de la programmation structurée, ceux qui faisaient croisade pour que tout le monde utilise Pascal avec des if-then-else et des boucles dans les années 70. Alors qu'ils auraient du plutôt passer leur temps à insister sur comment dessiner des organigrammes ou des bonnes pratiques qui découlent de la programmation structurée et que tu peux appliquer dans n'importe quel langage avec des goto.

Je comprends pas bien l'opposition avec ce que je raconte en fait, je crois que t'as mal interprété ce que je voulais dire.
Et derrière tu me balances un cours avec une certaine condescendance, ça fait très prof

Ce que je ne dis pas, c'est que le langage est inutile et qu'il n'y a pas de raison d'évoluer parce que tu peux faire du code propre et arbitrairement complexe même en partant d'une base moche ou simpliste. AKA tout le monde devrait bosser sur du COBOL parce que c'est turing complet donc OSEF.
Ma déclaration d'amour pour Scala plus haut, qui est sorti d'une équipe de chercheurs pensant justement qu'on peut aller vers le mieux et le plus productif en créant un nouveau langage, est représentatif de ça.
Ce que je dis par contre qu'il y a une tendance à surestimer l'importance du langage parce que tout le monde aime bien une bonne vieille bataille de clochers, ou alors a ses habitudes, alors que ça n'est qu'une partie du problème. Un classique plus général dans le dev où ça se perd vite en considération sur les outils plutôt que la finalité.
En passant, je dis bien "certains fanatiques". Je pensais que c'était suffisamment évident vu le contexte mais ces certains là sont bien ceux (comme encore plus camelinos par rapport aux haskelliens en effet) qui se concentrent sur le langage au détriment de ce que je considère être plus substantiel et planqué derrière.

Sur le reste, j'ai jamais considéré les design patterns comme une contrainte imposée ou une histoire de discipline. C'est sûrement le cas pour les devs Java avec leurs Factory de Factory de Factory d'AbstractFactory de Proxy d'Observers, ou de certaines personnes qui bossent à la BNP avec des architectes nazillons, mais c'est pas mon domaine et ça me semble être une définition bien étroite.
J'ai en tête la définition plus générale qui s'étend à plein de domaines même hors IT, au pif celle sur wikipédia: "a general reusable solution to a commonly occurring problem".
Quelque chose me dit que ça, ça ne s'éteindra jamais peu importe les évolutions techniques.
Ou alors il faut qu'il nous reste que des problèmes communs sans solutions réutilisables et on est pas dans la merde

Donc pour clarifier le passage que tu cites avec ces deux éléments: je pense qu'il y a davantage d'intérêt, pour prendre un exemple simple, à faire comprendre aux gens pourquoi l'utilisation d'un maximum de fonctions pures (un design pattern au sens que je lui donne) rend le code davantage testable, lisible et debuggable; plutôt que d'essayer de faire migrer toute l'industrie sur un langage tounaze et mathématiquement pur qui va aller tuer toute ta famille si tu tentes de déclarer une variable mutable (ce que font "certains" fanatiques).
J'espère qu'on est au moins d'accord là-dessus !

- - - Mise à jour - - -

Le "callback hell" que tu décris en fin de ton message est effectivement un problème avec Node.js mais peut être reglé par l'utilisation de promesses, en tout cas dans tous les cas d'usages que j'ai rencontré ça fait bien le job en plus de rendre le code bien plus lisible.

C'était vrai à ses début.
Maintenant si t'utilises des Promise ou des Observable, t'as absolument plus ce soucis.

J'ai 0 doute là-dessus, mais j'essayais de reconstituer l'argumentaire typique du haterz de node.

[Sahnvour]

"Suite" du talk de Herb Sutter à l'ACCU de cette année pour les gens qui se paluchent en ne faisant pas de web qui montre des trucs sacrément cools et une bonne réflexion (sans mauvais jeu de mot) derrière.

[vectra]

Ca fait plaisir de revoir ce topic aussi vivant.
Dommage que je ne puisse plus participer en journée, mais ça ne saurait durer....

- - - Mise à jour - - -

Pour ceux qui ont un niveau master dans une autre discipline, il y a aussi les masters CCI: compétence complémentaire en informatique. Ça permet d'avoir une remise à niveau et un diplôme d'informatique.

Ca intéresserait pas mal ma soeur, qui est plutôt biostat en R et qui aimerait bien être embauchable...

[William Vaurien]

c'est bien un peu d'animation

Il faut bien que JVDaedelus se rende compte d'en quoi il allait se fourrer en voulant devenir dev


Il y a trop de matière pour répondre à tout, mais je voulais défendre Java: je dirais juste:
InternalFrameInternalFrameTitlePaneInternalFrameTi tlePaneMaximizeButtonWindowNotFocusedStat (jdk6)

ou encore, avec un peu d'auto-dérision chez Spring:
HasThisTypePatternTriedToSneakInSomeGenericOrParam eterizedTypePatternMatchingStuffAnywhereVisitor

Pour .NET et mon Windows pas à jour, il faut voir ça avec mon service IT. En fait j'ai déjà de la chance d'avoir un windows 10, et pas un 98 ou un XP... En comparaison un jdk/jre java peu s'installer très facilement avec un simple copié/collé et une variable d'environnement. Un utilisateur non admin peut se débrouiller pour s'installer un environnement, alors que du coup avec .NET tu dépends beaucoup plus de ton OS et de ta DSI...
Et c'était pas pour faire le troll: en fait j'aime beaucoup C#, mais il fallait remettre un peu de relativité dans le message disant: .NET c'est de la balle, le framework est pré-installé partout...

Pour Doppio, ça à l'air très sérieux: c'est à la base un projet universitaire: "et si on implémentait une JVM en javascript ?" et, en partant sur du typescript pour ne pas se mutiler le cerveau, ils ont réussi à en implémenter une.
Du coup le browser peut interpréter du bytecode, par extension charger des jar et même compiler avec sa version de javac. Et comme la JVM est capable de faire tourner autre chose que du Java, leur JVM aussi. J'imagine que certaines partie du jdk sont ignorées, mais j'aime beaucoup l'idée. Beaucoup plus que de faire du transpilage.

Après les perfs ont l'air minable (entre 20x et 40x moins bien d'après un article), et le webassembly semble être la solution élégante pour la sortie en douceur du JS.

Et mon avis sur node.js, c'est que je ne comprends absolument pas quel besoin a été comblé par le fait de ramener JS vers le backend... J'ai déjà du mal avec les langages dynamiques pour les projets assez conséquents, alors en plus aller chercher un des langages le plus bancal pour le faire... Je comprend à la limite (et encore) pour faire du prototypage, ou un micro service ultra basique, mais j'ai beaucoup de mal avec l'argument 'avec un seul langage c'est plus simple, c'est full-stack' alors que de l'autre côté on s'escrime à s'en débarrasser à coup de frameworks et de 'transpiler'...

Ma déclaration d'amour pour Scala plus haut, qui est sorti d'une équipe de chercheurs pensant justement qu'on peut aller vers le mieux et le plus productif en créant un nouveau langage, est représentatif de ça.

C'est exactement pour ça que Kotlin est né et que je suis content qu'il y ait une certaine adoption: c'est pas uniquement des 'chercheurs' qui ont développé ce langage et s'il est plus limité, plus 'terre à terre', il reste plus simple à prendre en main. Comme un Java moderne. Pas mal de témoignage parle justement de devs Java qui sont efficaces en Kotlin après quelques jours, avec du code maintenable, alors qu'en Scala c'est vite un foutoir sans nom dans les sources.

Voilà voilà. Je crois que j'ai fais le tour, je vous laisse.

[Charmide]

Il faut bien que JVDaedelus se rende compte d'en quoi il allait se fourrer en voulant devenir dev

BAAAASTON

C'est un peu ça quand même, vouloir faire du dev à plus d'une personne c'est avant tout s'exposer à des débats philosophiques intense et à essayer de communiquer des concepts pas toujours évident tant bien que mal.

C'est exactement pour ça que Kotlin est né et que je suis content qu'il y ait une certaine adoption: c'est pas uniquement des 'chercheurs' qui ont développé ce langage et s'il est plus limité, plus 'terre à terre', il reste plus simple à prendre en main. Comme un Java moderne. Pas mal de témoignage parle justement de devs Java qui sont efficaces en Kotlin après quelques jours, avec du code maintenable, alors qu'en Scala c'est vite un foutoir sans nom dans les sources.

Oui, et c'est drôle de voir l'évolution parce que Scala c'était aussi ça à l'origine: appuyons nous sur la JVM qui est un truc industriel et présent partout (contrairement à la VM d'erlang ), plus une hybridation avec de la POO que tout le monde connait, pour faire passer des concepts fonctionnels qui jusque là étaient dans des langages trop "purs" et complexe pour devenir mainstream.
Martin Odersky qui a crée le langage c'est aussi pas un chercheur en tour d'ivoire justement, il a pas mal bossé pour l'adoption de Scala dans le privé et a même lancé une boîte de consulting/services pour se faire du pognon dessus.

Et maintenant c'est au tour de Scala d'être taxé d'élitisme/complexité et de se faire dépasser en pragmatisme !

J'en profite pour balancer cette métaphore qui faute d'être super fidèle probablement m'avait bien fait marrer:

Scala is like an Apache attack helicopter, it is really good when you need to thoroughly destroy an enemy tank, it is not so good when you need to go to a department store in your neighbourhood.

Kotlin is just another family car, maybe with some extra gadgets and better polished than the old rust bucket you were driving (Java), but all in all, it’s just a pragmatic choice for something you intend to use for typical tasks.

Kotlin provides 90% of the benefits that are claimed by Scala for 10% the learning effort, as long as you’re not doing something equivalent to destroying enemy tanks.

[deathdigger]

@Vaurien, tu veux qu'on parle des fuites mémoires de java qui font que lorsqu'on développe un service avec, il faut penser à le redémarrer régulièrement ?
Pour en revenir au choix du langage pour un débutant, je ne conseille pas python, parce qu'au niveau taf, il n'apportera pas grand chose. Faire du Java ou du C#, ça rend tout de suite un CV bankable. Et niveau apprentissage, les deux son relativement faciles. En plus, on passe de l'un à l'autre sans problèmes
Faire du bas niveau, c'est bien pour la compréhension, mais ce n'est pas vital. Un mécanicien n'a pas besoin d'avoir le savoir d'un motoriste pour travailler (et y'a plus de boulots pour les mécaniciens que pour les motoristes).

[Møgluglu]

Je comprends pas bien l'opposition avec ce que je raconte en fait, je crois que t'as mal interprété ce que je voulais dire.
Et derrière tu me balances un cours avec une certaine condescendance, ça fait très prof

Eh mais attends j'ai même pas été lourd, d'habitude je remonte à la notation mécanique de Babbage ou au moins au Plankalkül de Zuse, avec encore plus de condescendence et d'analogies anachroniques foireuses.
(D'ailleurs ça m'a donné une idée, dans mon cours je vais parler des GPU de Jacquard et des canuts qui programmaient leurs shaders sur cartes perforées. Et je suis pas prof.)

J'ai en tête la définition plus générale qui s'étend à plein de domaines même hors IT, au pif celle sur wikipédia: "a general reusable solution to a commonly occurring problem".
Quelque chose me dit que ça, ça ne s'éteindra jamais peu importe les évolutions techniques.
Ou alors il faut qu'il nous reste que des problèmes communs sans solutions réutilisables et on est pas dans la merde

Oui, c'est justement ce qui me gène dans les design patterns. Ils donnent (ou sont utilisés comme) des recettes de cuisine, des solutions toutes faites, plutôt que des concepts qui permettent de raisonner à un niveau d'abstraction plus haut. Si c'est simplement un raisonnement "j'identifie un problème de type x -> j'applique le design pattern y", alors c'est fondamentalement automatisable. La valeur ajoutée des programmeurs humains, c'est d'inventer des solutions originales. Si c'est juste pour reconnaître des situations connues et y appliquer des solutions connues, autant les remplacer par des réseaux de neurones.

[Teocali]

@Vaurien, tu veux qu'on parle des fuites mémoires de java qui font que lorsqu'on développe un service avec, il faut penser à le redémarrer régulièrement ?

99% des fuites mémoires en java, c'est parce que le mec qui a developpé son programme en Java (ou le mec qui a developpé le framework utilisé) à fait de la merde.

Dans java, c'est pas parce que tu as un garbage collector que tu es as l'abri des "fuites mémoires" (le guillemet est là parce que c'est pas l'equivalent exact de C/C++). Juste qu'elles sont plus facile à éviter, voire à repérer et corriger.

J'ai des micro-programme (service REST en plus) en java qui ont un uptime de 500 jours, et toujours une consommation réduite. De toute façon, si ils consomment plus que ce qui est prévu, ils plantent

[Cwningen]

Ça ressemble à quoi un programme Java qui a des fuites ?