La valeur de []+{} est consistante entre les plateformes.
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...
Dernière modification par William Vaurien ; 29/09/2017 à 17h39.
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
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!
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...
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 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...
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.
Pas douze milles : 13 depuis la première version (cf lien plus haut).
On compare avec le bordel Java ?
C'est ce que fait le nouveau Framework .NET Core, c'est pour ça que ça tourne sur toutes les archi d'ailleurs.
Ç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.
Dernière modification par Dross ; 29/09/2017 à 18h28.
Tout à fait. Ça permet d’ailleurs de faire ce genre de chose : http://jsfiddle.net/ds1yqhhz/
- - - Updated - - -
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.
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 ?
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
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
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 - - -
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
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.
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.
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.
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 - - -
J'ai 0 doute là-dessus, mais j'essayais de reconstituer l'argumentaire typique du haterz de node.
"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.
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'...
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.
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.
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.
@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).
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.)
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.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
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
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
Ça ressemble à quoi un programme Java qui a des fuites ?