Reprise du message précédent :

 
Mais il a peut etre un poil évolué depuis? tu n'est pas sensé ecrire du JS comme je le faisais en 2003

Je suis dev Full Stack PHP/JS, j'aime ça, et je vous merde

Bah t'facon c'est pas du VRAI code. Qu'est que tu vas faire avec? Le Nieme uber de la farine voila tout.
 

 
Je metterai un hola sur le salaire, en Node (ou pire en C), ca monte quand meme globalement plus haut. Et quand tu veux du haut salaire en PHP, ben t'en a autant que dans presque tous les autres languages en fait.
 

 
+1
 
 

 
Heu... Enfin quand meme quoi On va s'calmer

On a tous nos petits secrets

Much> https://twitter.com/ViteMaDose_off/ [...] 5200601088

Ce qui n'a rien a voir avec JS en fait...
 
Mais bon
 
EDIT: on va rester poli hein, mais si en entretien tu me sors un truc comme ca je t'engage pas, parce que ca veut dire que tu n'as jamais tappé IEE 754 dans google, que tu sais certainement pas ce que c'est, et que accessoirement tu sais pas comment un CPU gere les floats.

ça n'a rien à voir avec le langage, c'est juste la façon de fonctionner du standard IEEE 754. c'est exactement la même chose en Java par exemple. Lance le code suivant dans Jdoodle, et vois le résultat
 

public class MyClass {
    public static void main(String args[]) {
      System.out.println(0.1 + 0.2);
    }
}

Ajouter des float dans des appli de gestion ?  C'est une mauvaise idée dans beaucoup de langages

Et je ne parle même pas des règles d'arrondis qui peuvent être spécifiques au metier

Bon bah je me ferais pas vacciner aujourd’hui : j’avais pris rendez-vous sur ma pause dej, en arrivant à l’heure il y a 150 m de queue sur le parking, au bout de 15 minutes ça a à peine bougé. Fuck it

Je vois où tu veux en venir, mais l'exemple est un peu malheureux.

Tu pouvais en prendre un parmi ceux-là : https://javascriptwtf.com (sauf les float)

genre

 
Oui alors faut vraiment éviter d'étaler son opinion mal informée et poser ça comme "objectif" au risque de passer pour un guignol.

Clairement, full NUMERIC et en BDD.
 

 
Non mais cherche pas c'est pas le language.
 
Exemple:
 
En JS
https://www.npmjs.com/package/bigdecimal
 
En Rust
https://docs.rs/bigdecimal/0.2.0/bigdecimal/
 
En Java
https://docs.oracle.com/javase/7/do [...] cimal.html
 
En C
https://gmplib.org/
 
Bref, quasi tous les languages sont sur IEE 754 de base, et tous ont leur bibli/classes/extensions/autre quand tu as besoin d'en sortir.
 

 
 
VOILA LA ON PARLE, LA CA RESSEMBLE A RIEN

ça me rappelle ce post d'anthologie du regretté chrisbk à propos de Flash
https://forum.hardware.fr/hfr/Progr [...] m#t1302814

Nan
Des integer. En centième de centimes si besoin. Et tu les changes en valeur a l'affichage

Toutes les devises n'ont pas deux décimales, le Yen n'en a pas, certaines monnaies en ont 3 (par exemple les dinar, à Chypre aussi avant je sais plus quand, ...)

Yep c'est bien aussi. Car en DECIMAL en base c'est bien mais souvent tu manipules les données ensuite dans le langage applicatif, donc ça résout qu'une partie du problème.

Pas forcément d'accord si tu commences a toucher aux cryptos qui descendent bien plus qu'au centime en précision
 
Perso on store en PG en NUMERIC(40,20), sachant que l'on sait notre valeur maximale aux alentours de 100ke... je sais pas si c'est super recommendé (sachant que l'on a pas de risque a stocker un valeur meme legerement erronée donc c'est pas critique pour nous).

t'as vu la gueule des tableaux et la gestion des entiers?

J'ai pris des centièmes de centimes parceque c'est ce qui correspondait à mon use case

Manipuler des nombres a 60 chiffres n'est pas hyper courant quand même
Avec ma solution tu ne peux gérer qu'une petite vingtaine de chiffres en bigint

On peut comparer avec les tableaux associatifs php sans trop rougir

vous parlez trop

ok, j'ai déjà pris rdv, juste avant le rush

je crois que dans ma fièvre créatrice nocturne j'ai raté un gros détail: décompresser un PNG sur un très petit MCU, c'est proche de l'impossible, rien que la partie zlib demande 32ko de buffer.

oui, c'est juste donc pas une solution qui est généralisable partout

Franchement on ne va pas se mentir, globalement c'est de la merde le JS
 
Rien que l'éco-système et la gestion des dépendances est une horreur (la Comparaison à Composer en PHP ne tient pas, les dépendances sont mieux gérées, les packages managers savent en général ce qu'il font et te font péter toute la BC lorsqu'ils incrémentent une version mineur, etc).
 
Niveau éco-système il suffit de voir le nombre de frameworks / libs qui font plus ou moins toutes la même chose qui se sont succédés ces dernières années.
 
Ensuite on peut parler de structurer son projet / son code proprement, ce qui était quasi impossible jusqu'à l'apparition de "Class". On devait se taper plein de patterns plus ou moins moisi pour essayer d'avoir un semblant de cohérence dans les projets.
 
Puis ensuite il y a toutes les natasseries propres au langage.

Ce qu'on ne veut toujours pas utiliser

Putain on sent celui qui connaît rien au JS.  
 
J'en fais depuis longtemps et on pouvait le structurer et faire des "classes" avant 2000 mais bon, les gens qui connaissent pas le langage ils sont nombreux et ils ouvrent leur gueule pour critiquer. On dirait les mecs qui critiquent les vaccins en mode "j'ai un doctorat en virologie".  

Des "classes" ?

Avec les prototypes tu veux dire ?

Si non, c'est forcément avec un pattern qui te gère la visibilité

J'ai pas mentionné les superbes call stacks lorsque tu veux débuguer aussi.

On pourrait également parler de l'enfer des callbacks qui a duré pendant un certain nombre d'année même si aujourd'hui c'est moins le cas.

Spring joined the chat

Sinon gatsu comme je te sens énervé, bien évidemment que je trollais en disant "c'est de la merde". PHP a son lot de merde aussi (quoique ça tend à être moins vrai maintenant), comme beaucoup d'autres langages j'imagine.
 
Par contre les points que j'ai mentionné sont pour moi de vrais problèmes ou sujets d'agacement.

 
Pour connaitre franchement tres bien les deux, non, depuis la v5 de npm (2018), ca écrase completement Composer, en vitesse, en resolution, rien que ca:
 
https://docs.npmjs.com/cli/v7/commands/npm-audit
 
Roulala que c'est pratique, et autant que je sache Composer n'a que quelques maigre truc a se mettre sous la dent, et globalement c'est encore de la merde de ce coté.
 
Quand aux versions qui petent tout, depuis package-lock (2018), c'est fini (mais c'était deja franchement pas un probleme que tu rencontrais souvent de toute facon)...
 
 

 
Donc en fait quand un language est actif ca t'emmerde Apres si tu es en mode vieux papy, prend express + le driver de la BDD qui va bien, tu es probablement sur un truc qui a moins changé que laravel ou symphony
 
 

 
Franchement quel besoin? On a une grosse team ici, on fait majoritairement du Node (150 projets pour 20 personnes quand meme), depuis plusieurs années, c'est anarchique comme pas possible et... Ben en fait c'est nettement mieux que de structurer un projet:
  - on ramene pas des packages en veux-tu en voila, ca force a avoir un code assez plat, et donc en réalité bien plus facile a lire et a suivre qu'un code "correctement structuré"
  - la structure: core (fichiers de confs ou autre), models, queries, routes. Fin. Bete, et donc facile a piger.
  - et ca force a aller a l'essentiel et garder un code facile a lire. Et ca c'est en fin de compte le plus important.
 
Au final c'est un peu je pense le meme biais que ca: https://www.gamasutra.com/blogs/Rob [...] d_Code.php
 
La discussion dépasse je pense largement JS, et franchement, je suis du mauvais coté (aka j'ai toujours tendance a foutre une structure, des classes, et j'empile j'empile j'empile ).
 
Mais le fait est, que tu écris du code pour:
  - que ca parte de A a B, ce qui n'a rien a voir avec du code, c'est "business driven", la boite a besoin de A vers B, tu fais de A vers B, ca pourrait etre du code, comme un systeme de pistons, tant que ca fini la tache, avec le cout le plus bas possible, tout le monde sera content.
  - de ce fait ce qui se passe en dessous, a part un dev, tout le monde s'en branle.
 
Résultat, est-ce que écrire du code avec une structure a la moindre importance? Non. Ce qui compte, c'est que tu t'y retrouves toi, et un autre qui n'a pas écrit le code.
 
Et a ce jeux la, je dois admettre, l'abscence de structure me semble en fin de compte un meilleur deal que de la structure a outrance.
 

Ca par contre Mais tous les languages quasiment ont leur lot donc bon...

J'avoue que c'est la mentalité typique qu'on trouve dans les communautés de langages qui sont franchement mainstream que depuis quelques années, mais en gros cette approche elle marche uniquement si tu fais des choses triviales ou jetables.
Évidemment tant qu'il n'y a personne pour chiffrer le temps perdu à comprendre comment pouvoir écrire une évolution, voire le temps perdu à l'écrire à cause d'une code base mal branlée, tant que le "dev qui connaît" s'est pas barré de l'équipe et qu'on a l'illusion de contrôler, tout va bien.

Alors évidemment, je parle pas de faire des abominations de modèles à 5 couches comme le monde Java s'est amusé à en produire à la tonne pour améliorer les bilans annuels d'IBM et Sun, mais je suis extrêmement en désaccord avec ce propos là.
(j'imagine que ça n'est pas exactement ce que tu voulais dire par rapport à ton commentaire plutôt pertinent sur la structure de la codebase)

TIL : https://0.30000000000000004.com/

Tiens sinon dans le genre framework, je suis en train de démarrer avec Quarkus, bah c'est bin foutu quand même.

 
No shit.

 
 
C'était limité en insulte quand même, je pense qu'il est très TRES calme là.

Pas du tout j'ai juste envie d'envoyer chier la moitié de la planète et d'enculer l'autre avec du gravier

 
Si ça se trouve c'est quand il est pas vulgaire qu'il est le plus énervé.

Ou est ce que je peux trouver de la docs sur ReCaptcha et le RGPD ? on nous pose la question de savoir quelles données personnelles sont collectées dans ce cadre

 
Je te dirais qu'un bon code est par définition un code jetable. Et paradoxalement ce sera le code que tu voudras probablement le moins jeter car ce sera tres certainement le plus stable.
 
Si tu peux le jeter, c'est que tu peux le réécrire facilement, et que donc, il est correctement foutu. C'est aussi que son périmetre est suffisamment bien défini, qu'il n'a pas une chié de use case pourri a se trimbaler (parfois pas facile via ce que le business impose).
Pour ce qui est des uses cases business, souvent quand ils sont un probleme en code, c'est qu'ils sont un probleme dans le business aussi. Ici, on cherche a approcher le business au code et non l'inverse (c'est pas toujours possible cela dit), parce qu'un ingé pas trop con est une tres bonne machine de turing, et donc parfaitement apte a pondre des BPMN propre, et a titiller les bonnes questions sur le process coté business (et ca arrive souvent d'avoir des trous béant de logique comblé par "on a toujours fait comme ca" ).
 
 
Comme dirait mon ex boss avec qui je bataillais (vu que je suis du coté de la structure pour rappel ), le meilleur des codes, c'est un fichier vide, qui arrive quand meme a faire la tache qu'on lui demande: ca fait le boulot, ca t'a rien couté, t'a pas de maintenance, et c'est facile a refaire si besoin.
 
 
Et... Ben avec le recul, en connaissant bien les deux approches, il a raison, plus c'est con, moins t'a besoin de structure, moins tu perds de temps a t'occuper de la structure, ce que tu veux, en tant que manager, c'est que chaque ligne de code, chaque action de tes devs, serve a répondre au produit, soit a l'améliorer, soit a fixer un bug, pas ta satisfaction personnelle d'avoir un code bien rangé   D'ailleurs, le code trop bien rangé, je l'ai toujours vu finir avec ce fameux libs/helpers, a savoir ce fichier que tu sais pas trop ou le mettre, pouf, ca fini la, libs, c'est foure-tout
 
Apres ca demande aussi une équipe rompu a la méthode (ici on a 0 junior par exemple, on embauche a cher que des seniors rompu), et parmi les mauvais point je dirais que moi qui gere cette bande, ca met bcp plus de boulot sur mes épaules car il faut sans arret batailler (la complexité revient toujours par la petite porte, les gens ont sans arret dans l'idée de factoriser, de réorga, de...). Donc ca demande un process bien cadré sur les PRs and co, faut faire attention au détail, faut jeter, faut questionner.
 
Maintenant en terme de taille, je crois qu'on approche sur les 2/3 plus gros projets a quelque chose comme 200/300 endpoints par projet, donc ca va je peux sans trop sourciller dire que c'est pas specialement trivial et que ca tient bien la route malgré tout (mais jetable, oui, definitivement oui , tout doit etre fait pour etre jetable si besoin, ca fait parti du package si tu veux pouvoir avancer, sinon tu vas te prendre le mur de la réécriture complete un jour, et tu auras rien gagné).
 
 
/my2cents en intro developpment conclusion sur 500 pages