Reprise du message précédent :
C'est surtout l'inverse, la main gauche tient le manche donc ça decharge ton cerveau de la replacer spacialement a chaque fois. Par contre avec la droite t'es plus précis pour trouver et actionner les boutons.
 
Idem avec le volant tenu de la main gauche et les vitesses/boutons de la droite (tampis pour les anglois et les nihon)
 
My 2 cents

Les deux fonctionnnent. Dans un airbus par exemple, le commandant de bord a le joystick à gauche avec les commandes à droite alors que son copilote a l'inverse. En résumé, si tu monte en grade, tu dois changer de coté.  

Pour remonter le topic. Une phrase d'un gars qui n'est pas un inculte (loin de là) mais qui m'est restée.
 
Je faisait mon stage de fin d'étude (on était en 2006 (ca remonte)). Il y avait des gars qui faisait de la recherche (ca a son importance car desfois ils sont complètement isolés des entreprises). Au cours d'une discussion avec l'un d'eux, il me sort : "Mais c'est complètement has been le xml."
 
Ah ? Une fois diplômé et "chez les pros" ( ), je me suis appercu que du xml ... il y en avait* partout.    
 
* : Je parle au passé car c'est en train de devenir obsolète. Le json est de plus en plus utilisé. Mais à l'époque ce n'était pas du tout le cas.
 
PS : je ne suis pas un partisan du xml. Ni de l'html d'ailleurs (et encore moins du javascript   ).

 
Il n'avait pas tout à fait tort... en 2006 déjà je bossais sur le remplacement progressif des couples XML/XSLT vers JSON

Peut être. Mais le temps que ca arrive chez Cogip&cie ...  

 
c'était chez une assurance en 3 lettres qui commence par un A et qui finit par un A

les Assurance MMA ?

Elle existe encore cette assurance avec un X au milieu ?

 
tu ne croix pas si bien dire !

D'ailleurs, j'ai une anecdote bien dans le contexte du topic...
 
C'est là bas que j'ai découvert le XML "Filler"... Les mecs sortaient des copy cobol avec des filler "englobant" autours des champs pour simuler un balisage XML...
 
Le problème, en dehors d'être totalement degueulasse, c'était que les champs étaient, comme tout bon copy cobol qui se respecte, en taille fixe...
 
On se retrouvait donc avec des truc dans le genre :
 

 
C'était fabuleux    

Remarque aussi si la taille fixe était suffisamment dimensionné, ça pouvait faire le taf

et tu peux parser ton xml avec uniquement les fonctions left et right, c'est quand même bien pratique.

 
Ce qui était amusant, c'était pour les valeurs numériques...
 
 
<montant>000000000000000000000537.3500</montant>
 
 

 
Ca dépend. Des trucs crades ca veut pas dire que t'es incompétent ou ignorant, ca peut être parce que t'as pas envie de te faire chier ( demande à la con ) ou alors délais intenables donc tu fais au plus vite.

C'était la belle époque avant les csv.    
 
Les champs à taille fixe, il y a que ca de vrai.  

 
C'est plus rapide pour accéder à un enregistrement. Quand t'avais des machines pas rapides, tu pouvais faire un seek de n*taille de ton enregistrement.

 
Bha c'est à dire qu'à côté on avait du bon vieux copy cobol avec un deserializer permormant qui nous mappait le tout sur de beaux objets générés, un truc qui tournait super bien et qui permettait de sortir le format voulu derriere.. XML, Json, etc...
 
Mais là, non, c'était vraiment une idée sorti d'un esprit tordu et malsain (et pas incompétent car pour pondre un truc pareil, fallait quand même avoir réfléchi )

 
ok    je connais pas du tout le cobol les mauvais programmeurs ça existe aussi , il y en a plein !

Ca se tient.

T'est juste quelqu'un qui fait des "copy cobol".   Donc ca se tient. Les machines qui tournaient du colbol n'étaient pas rapides et la mémoire et l'espace disque étaient (très) restreints.

CSV

 
Désolé, j'ai pas compris où tu voulais en venir  

Les champs à taille fixe c'est surtout un bel héritage de la carte perforée du 19° siècle  

Toi qui ne connait pas le cobol (rassures moi, t'en a entendu parler au moins ?), c'est un language de programmation antédiluvien. Ca s'utilisait dans les années 60/70.  
 
Dans ces années là, les grosses mémoires se comptaient en kilo (!). Et les puissances de calculs de l'époque ... comment dire ... le moindre circuit imprimé de frigo made in china aujourd'hui aurait été vu comme une F1 turbocompressée futuristique à l'époque  
 
Donc on optimisait. Et on faisait des "seek[s] de n*taille de ton enregistrement." Aujourd'hui plus aucun intérêt. Un peut scanner des table des millions de lignes avec des jointures de partout et la requête prendra qu'un dixième de seconde.

 
Mouarf.
Le nombre de base de donnée et backend mal branlé que j'ai rencontré.
"Ça marche sur mon Core i7, 32Go de RAM SSD avec 100 lignes de test dans la base de donnée donc ça tiendras en prod avec les 10 millions de ligne"    
 
Et au final ton API répond en 2, 5, 10 sec au lieu de 200ms

 
C'est pour ça qu'encore aujourd'hui, les banques, assurances et grande distrib ne jurent encore que par le couple Cobol/DB2 pour leur coeur de SI
 
c'est vieux,
c'est imbouflable,
 
mais c'est robuste...
 
par contre, on trouve de moins en moins de dev

Maintenant, j'ai compris. Je me suis mal exprimé en supposant que tu était un cobolar. Ces des gens très compétents mais qui codent à l'ancienne. Et le code à l'ancienne marche (et est très optimisé ) mais est très parfois.
 
Edit :

Je ne peut que plussoyer.  

C'est pour ca qu'on l'isole dans un "microservice". Personne n'ose toucher à ce genre de truc. Ces codes, c'est de zones de catastrophes naturelle.   Touche un truc et tout peut peter.  

 
Quand je dis que je ne connais pas le COBOL, c'est que je n'ai jamais programmé en COBOL, je n'ai pas appris le langage donc je ne sais pas ce qui est possible et ce qu'il permet. Bien sur que je connais le langage de nom et à quoi il a servi, étant programmeur depuis les années 90 ( plein de dev COBOL recherchés dans ma région d'origine la Marne, fin des années 90 ,je pouvais pas postuler ).
Je ne me permettrais jamais de juger le niveau de quelqu'un juste parce qu'il a fait de la merde à un moment donné dans du code, sans connaitre le contexte derrière.
 
Quand à l'optimisation de code du fait des machines pas assez puissantes, j'ai connu, il est vrai que c'est moins nécessaire maintenant, enfin en tout cas pas pour les mêmes choses. Les alignements sur 4-8-16 octets restent nécessaires pour optimiser des calculs, notamment pour des décodeurs matériels et textures représentant une image video.

Mais toutes ces compagnies qui gèrent des informations importantes sur nos vies (assurances, banques, etc), ça roule encore avec du Cobol ? Ils vont faire quoi quand tous les dev Cobol seront à la retraite ou morts de vieillesse ? Et ça tourne sur des machines aussi vieilles que la code lui-même ou on peut mettre ça sur des bécanes récentes ou en virtuel ?

 
 
figure toi que le problème se pose déjà...
 
Si tu veux faire une carrière de dev avec un salaire à 6 chiffres, c'est le moment, lance toi
 
par contre, c'est vraiment relou comme langage
 
Edit: pour le matos, c'est bien simple, ça tourne aujourd'hui sur ce qui se fait de plus gros en terme de CPU

 
L'effondrement nous rattrapera avant, t'inquiète pas

 
Le dev m'intéresse mais pas à ce point
 

 
Me voilà rassuré

On a des bouts de programme FORTRAN écrits par des ingénieurs de l'époque où les premières machines IBM type System/360 sont arrivées en France, même un polytechnicien n'arrive pas à démêler le tas de merde tellement ils codaient n'importe comment à l'époque  

Je plussoie pout le salaire, j'ai des potes qui sont sortis vers 2005, en ayant pris la spécialisation vieux langage de programmation.  Ils avaient déjà +30% sur le salaire des jeunes diplômés,  15 ans plus tard les bons ont des salaires monstrueux et des offres d'emploi toutes les semaines pour les débaucher...
Ils ont plutôt la belle vie.

C'est pas qu'une question de ca. C'est aussi qu'on codait différemment à l'époque.  
 
Aujourd'hui, on a des design patterns, principes de machin-trucs, test unitaires, etc. On a aussi des standards de codage, des méthodes pour faire bien structuré et lisible.
 
A l'époque, tu pouvais avoir à maintenir des trucs comme ca :
https://en.wikipedia.org/wiki/Fast_ [...] f_the_code
 
()

Cobol, fortran, as400 et autres c'est tellement relou que y  a toute une génération de développeur qui ont craché dessus, en disant que tel ou tel langage allait les remplacer... Alors que le nombre de grand système à maintenir dans ces vieux langage est énorme.
Y a des projets de migration en cours dans les banques en particuliers, de quoi y passer route sa carrière.

 
Les magic numbers, je suis fan  

preparez vous , bientot le php sera un vieux langage !
http://www.commitstrip.com/fr/2019 [...] loves-you/

 
J'ai 12 postes de dev cobol à pourvoir sur toute la France en permanence, et ça fait 6 ans que ça dure... à peine on en trouve 1 pour combler une offre, on a 2 nouvelles offres qui arrivent...
 

 
edit : on peut pas spoiler les balises code  

C'est passé par un obfuscateur.    
 
Ca sert à quoi ? C'est un main qui se relance à l'infini ? Ca serait pas plus simple de faire un while(1) fork(); ?