Discussion :

[el_slapper]

Même sans aller au C/C++, il y a plein d'autres architectures qui sont extrêmement performantes. Allez, j'ai déjà du la raconter, mais elle est parfaitement d'equerre avec la discussion.

début des années 90, un grand compte développe son SI en COBOL/CICS. Ca marche, mais c'est moche. C'est très complexe et ça fait un tas De trucs. Bien, et vite. Et très moche. Les utilisateurs s'en plaignent.

Milieu des années 2000, grand projet de remplacement. Il s'agit de faire mieux - en JAVA. Après 5 ans d'efforts acharnés, ça marche à peu près. Alors on y migre quelques clients. C'est lent, douloureux, mais ça avance. Certains y croient encore. Jusqu'aux traitements de fin d'année. COBOL/MVS traitait des millions de contrats en quelques heures. JAVA a mis une semaine à traiter 5% de la volumétrie.

Résultat? Poubelle. alors que ça marchait enfin. Mais les performances étaient abyssimales. L'appli COBOL, elle, fonctionne toujours du feu de Dieu. Avec certes des couts de maintenance non négligeables, mais vi la taille du SI, rien de scandaleux. Et les utilisateurs gueulent toujours. Je connais aussi des maisons ou on fait encore du FORTRAN. J'ai moi-même coopté un développer C++ pour de l'industriel. Je fais du VB6 en ce moment. Et on m'a parlé de MUMPS récemment.

@Pmithrandir : tu est aveuglé par ton propre travail. Le client lourd, il y en a partout. Son seul inconvénient, c'est le déploiement. C'est parfois assez massif pour justifier de passer au client léger, mais en dehors du déploiement, le client lourd est supérieur à tous les points de vue. Donc, parfois, son maintien est justifié. Malgré la douleur du déploiement (qui est un vrai problème, je le concède).

Tu a noté récemment que certains de tes développeurs Roumains étaient formés à COBOL. C'est normal. Ca existe toujours, et dans sa niche(traitement massif de fichiers plats infinis contenant des données comptables), c'est inégalable. Même par C/C++(envoyez les insultes par MP, merci). C'est certes immonde sorti de ladite niche, mais dedans, c'est juste parfait. Pas d'objets pour venir polluer l'esprit, une grande indépendance entre les composants pour éviter les effets de bord, des fuites mémoire impossibles par définition(la mémoire totale utile est définie à la compilation. Ca manque de dynamisme pour les algos compliqués, mais en même temps, j'en ai fait 2 en presque 8 ans - pas la mer à boire).

en d'autres termes, ce que tu sais être vrai, ne l'est que dans ton petit univers de développeur web. Dès que tu en sors, il y a des dizaines d'autres vérités. Toutes aussi valables que la tienne

@R0d : d'ou l'importance d'être agile(en manière de pensée, pas forcément en péthode), et d'avoir les moyens de déployer une version "à chaud" sans avoir besoin de l'autorisation de 3 chefs. Toujours en COBOL, sur des batches sensibles, j'ai parfois pu réagir en quelques minutes - là ou les gens du JAVA n'avaient pas le droit d'intervenir à moins de deux semaines. Là, ça n'est pas le langage qui est en cause, c'est le processus de travail. Sous pretexte de "contrôler" le process, on interdit aux développeurs de maintenance de faire leur boulot(i.e. de réparer la merde, peu importe à qui la faute, tout de suite, pas dans 2 semaines, pas même dans 2 minutes). On était tellement efficaces, que parfois, le surlendemain, un chef apprenait qu'il y avait eu un problème. Seule l'exploit' et nous l'avions su sur le moment. Mais nous étions efficaces parceque nous en avions les moyens.

Si les gens qui travaillent sur le serveur web ont autant de lattitude que moi pour déployer leurs correctifs à chaud, il n'y a pas de raison qu'ils soient moins réactifs que moi. Enfin, si ils ont un langage performant et puissant, celà va de soi. (bon, ce lien est un peu un troll, hein, je précise pour les âmes sensibles. Il dit même du mal du COBOL, c'est dire. Mais pour COBOL en dehors de sa niche, il a 100% raison - c'est juste nul).

[r0d]

[...] COBOL. C'est normal. Ca existe toujours, et dans sa niche(traitement massif de fichiers plats infinis contenant des données comptables), c'est inégalable. Même par C/C++(envoyez les insultes par MP, merci)

Je suis d'accord avec toi concernant COBOL (envoyez les insultes à el_slapper, il retransmettra. Merci).

@R0d : d'ou l'importance d'être agile

C'est très intéressant tout ce que tu dis là. Mais comme toujours, en fait ça dépend. Et ce que j'ai écrit précédemment pêche aussi par une trop grande généralisation.
En ce moment par exemple, je travaille sur une chaine de traitement que, même avec une armée de dev, bons, libres et expérimentés, il faut du temps à modifier, car chaque maillon est extrêmement complexe au niveau des mathématiques qu'il y a derrière. Chaque modification implique des jours d'épluchage de papiers et de bouquins qui traitent du sujet, puis des longs tests. Donc dans mon cas particulier, l'agile ne nous sert pas à grand chose. En revanche, en arrivant ici, la première chose que j'ai faite ce fut la mise en place de tests automatisés, et ça a été une petite révolution (positive) dans la boite. Alors que dans d'autres contextes, les tests automatisés peuvent ne pas être cruciaux.
J'ai récemment discuté avec des dev de SAS* et nous partagions ce constat: le problème du format des données en entrée. La difficulté étant l'automatisation du formatage et de la validation. En ce moment je bosse sur autre chose, mais je vais bientôt m'attaquer à ce problème et je me languis

* SAS est en train d'essayer de se positionner violemment sur le data mining, le problème c'est qu'ils sont trop gros et ils ont du mal à suivre. Alors ils essaient de s'imposer par la force, c'est à dire par la force de conviction de leur commerciaux et leur force de frappe financière, mais je n'ai pas l'impression que ça marche bien. Récemment ils ont essayé de nous vendre un soft qui est censé gérer, justement, la validation de données. Les performances du soft en question étaient impressionnantes, alors nous avons voulu tester. Trois commerciaux avec des costumes à 5000€ sont arrivés avec un technicien et une blade sur laquelle était installée leur soft miraculeux. Ils nous ont fait la démo. Je ne me souviens plus des chiffres mais c'était impressionnant. Nous avons alors demandé les specs de la blade, et là on a vite compris: 8 processeurs quadcore, mais surtout, 1 Terra Octet de RAM!!! C'était l'année dernière, je ne savais même pas que c'était possible... alors oui, tu m'étonnes que leur soft il envoie du bois sur une machine comme ça... et ils n'ont pas voulu qu'on teste sur une machine normale...

[fcharton2]

J'ai récemment discuté avec des dev de SAS* et nous partagions ce constat: le problème du format des données en entrée. La difficulté étant l'automatisation du formatage et de la validation. En ce moment je bosse sur autre chose, mais je vais bientôt m'attaquer à ce problème et je me languis

C'est un de mes chevaux de bataille (je crois que tu l'as deviné). Dans ce domaine, la position de SAS est assez extrème. Comme tous les logiciels de stats (SAS, SPSS, et les autres), tout, chez eux, repose sur un format de données interne, très particulier, et très adapté à leur soft. Une fois que tes données sont "sous SAS", tout devient facile, et puissant, et merveilleux. Mais charger tes données, ça peut être long et difficile, voire quasiment impossible si tu rentres mal dans leur paradigmes (en gros, des tables rectangulaires avec pas trop de trous dedans).

A l'inverse, tu as les applis de type tableur (Excel, Powerpoint) qui mangent n'importe quoi en entrée, peuvent facilement faire de petits trucs, mais deviennent infernaux à gérer et à maintenir si tu veux réutiliser, ou si tu veux un peu plus que cinq tableaux, toujours les mêmes, et dix graphiques, toujours les mêmes.

Le problème, c'est d'avoir un truc un peu entre les deux. C'est plus ou moins ce que faisait Business Object sur des données issues de bases relationnelles, mais j'ai l'impression qu'ils ont les mauvais côtés des deux : ca devient vite compliqué comme Excel, et c'est contraignant côté données.

A mon avis, il y a un vrai truc à inventer à mi-chemin. Il faut un format interne de données à la SAS, mais plus souple, car les données réelles ne sont pas aussi tabulaires qu'on le voudrait, mais il faut un format strict, et relativement math-friendly pour pouvoir "miner" facilement (le problème des JSON et autres, c'est que c'est monstrueux à utiliser avec des algos sérieux) Mais à l'autre bout, il faut un système plus amical de chargement de données, et de contrôle surtout (et là, on est dans le monde des langages de script...).

C'est un peu pour cela que je parle d'AWK sur l'autre fil, mais si le sujet te branche, je suis TRES preneur d'une discussion. Tu sais où me trouver, je pense.

Francois

[daniel.d]

des fuites mémoire impossibles par définition(la mémoire totale utile est définie à la compilation.

.

Si si on peu y arriver dépassement mémoire à l'appel d'un module, résultat écriture dans l'exécutable du CICS, CICS down par la suite.
Sinon c'est sur c'est pas sexy mais efficace.
L'efficacité n'est pas tant due au COBOL, qu'à la performance des disques durs avec accès par fibre optique dans certains cas.
Sinon sur Mainframe on peu faire du C++, faire tourner un Linux mais bon jamais vu.
Sur tests de plans de reprise incident cas ou il y a un gros crash dans SI reprise des données et traitmetn sur mainframe 90% sur architecture réseaux PC 70%.

[fcharton2]

Le client lourd, il y en a partout. Son seul inconvénient, c'est le déploiement. C'est parfois assez massif pour justifier de passer au client léger, mais en dehors du déploiement, le client lourd est supérieur à tous les points de vue. Donc, parfois, son maintien est justifié. Malgré la douleur du déploiement (qui est un vrai problème, je le concède).

Le déploiement, ce n'est lourd QUE si tu tombes dans les pièges que te tend le méchant Crosoft... Si tu as besoin d'un setup, et d'être en mode admin parce que tu as besoin d'aller dans les coins dégoûtants de la base de registre (ceux que le DSI semi paranoiaque, oui oui, pléonasme, je sais, de ton client a rendus très difficiles d'accès), c'est galère. Mais si tu conserves des programmes qui peuvent se copier, avec des fichiers ini ancien modèle, et que tes dll, ben... tu les attaques à l'ancienne (getproc et tout cela), il n'y a pas de problèmes d'install.

Sérieusement, je ne sais pas combien de postes client lourds on a dans ma boite, mais ca se compte en milliers, et on peut en installer quelques centaines d'un coup... Et on n'a guère que deux personnes sur le sujet, qui font aussi le commercial, la formation et la hotline...

Le déploiement, c'est un faux problème dans presque tous les cas...

Ca existe toujours, et dans sa niche(traitement massif de fichiers plats infinis contenant des données comptables), c'est inégalable. Même par C/C++(envoyez les insultes par MP, merci).

Je ne vais pas répondre à ce gros troll, mais sur le fond, l'inégalable, ce sont plus les fichiers plats bien pensé que les langages. Je suis persuadé que même avec un langage à la mode pour gens pas sérieux comme Java, on peut faire des merveilles si

- on accepte de remplacer la sacro sainte base de données par des fichiers plats
- on trie ces fichiers dans un ordre utile, une bonne fois pour toute (au lieu de le faire à chaque appel)
- on évite le réseau à chaque fois qu'on peut, et on reste sur le poste local, avec ses belles ressources si mal utilisées

@R0d : d'ou l'importance d'être agile(en manière de pensée, pas forcément en méthode), et d'avoir les moyens de déployer une version "à chaud" sans avoir besoin de l'autorisation de 3 chefs.

Et aussi d'avoir une vision incrémentale des versions: pas de saut brutal, qui nécessiterait des armées de testeurs, et une validation client, et JAMAIS de réécriture complète (ben oui, c'est plus exigeant, parce qu'il faut faire évoluer le code, sans le réécrire d'un coup, mais on n'a rien sans rien).

Francois

[GPPro]

Je ne vais pas répondre à ce gros troll, mais sur le fond, l'inégalable, ce sont plus les fichiers plats bien pensé que les langages. Je suis persuadé que même avec un langage à la mode pour gens pas sérieux comme Java, on peut faire des merveilles si

- on accepte de remplacer la sacro sainte base de données par des fichiers plats
- on trie ces fichiers dans un ordre utile, une bonne fois pour toute (au lieu de le faire à chaque appel)
- on évite le réseau à chaque fois qu'on peut, et on reste sur le poste local, avec ses belles ressources si mal utilisées
Francois

Juste pour argumenter là dessus : il y a quelques mois j'ai eu à traiter quelques millions de séquences d'ADN De quelques centaines de paires de base. Première version C++. Deuxième version java. La deuxième version était plus rapide (et pas d'un petit peu) : j'avais juste trouvé une bonne ruse à base de HashMap, qui visiblement sont hyper optimisées dans la bibliothèque standard. Sur du one shot, ça m'allait parfaitement. Certes avec du C++ j'aurais fini par atteindre de meilleures perfs, But at what cost?

[pmithrandir]

Pour le deploiement de client lourd, je me demande quand même comment tu peux avoir plus de flexibilité qu'un logiciel sur navigateur qui fonctionne un peu comme nos vieilles console des années 80 dans l'esprit. Tout sur un serveur unique et rien sur le poste utilisateur.

On peut imaginer des mises a jour quotidiennes, et on ne se gene pas pour en faire toutes les 2 semaines. Tu arrives à déployer aussi vite ? (c'est vraiment une question)

[fcharton2]

j'avais juste trouvé une bonne ruse à base de HashMap, qui visiblement sont hyper optimisées dans la bibliothèque standard. Sur du one shot, ça m'allait parfaitement. Certes avec du C++ j'aurais fini par atteindre de meilleures perfs, But at what cost?

Je suppose que ce serait allé aussi vite en C++, ce qui est en cause, c'est l'efficacité des tables de hachage. Mais même si toutes les versions récentes de la STL ont des hashtables celles ci sont un peu cachées/moins documentées donc moins connues des développeurs C++. Mais je suis d'accord avec toi, avec un algorithme efficace, tu gagnes des ordres de grandeurs en vitesse, bien plus que ce qu'apporte un changement de langage, ou une optimisation du code.

Et c'est un des gros problèmes que je vois chez certains développeurs. A force de s'entendre répéter que l'optimisation prématurée c'est mal, ils ont fini par croire qu'on ne regarde la performance algorithmique qu'à la fin, généralement au moment où intégrer un algo réellement efficace modifierait trop les structures de données.

En traitement de données (ou dans tout ce qui fait des calculs), en général, on choisit les algos d'abord, et on structure les données autour...

Francois

[fcharton2]

Pour le deploiement de client lourd, je me demande quand même comment tu peux avoir plus de flexibilité qu'un logiciel sur navigateur qui fonctionne un peu comme nos vieilles console des années 80 dans l'esprit. Tout sur un serveur unique et rien sur le poste utilisateur.

Sans doute, mais le client lourd n'est pas aussi lourd que tu le crois, et à moins d'avoir des mises à jour quasiment instantanées (et surtout concurrentes), l'avantage du logiciel sur navigateur est assez faible.

On peut imaginer des mises a jour quotidiennes, et on ne se gene pas pour en faire toutes les 2 semaines. Tu arrives à déployer aussi vite ?

Oui, dans l'application sur laquelle je travaille actuellement (installée sur quelques centaines de postes, dont de grosses structure avec une informatique interne paranoiaque et délocalisée), les données sont mises à jour hebdomadairement, et on a va bientôt passer à des mises à jour quotidienne. La donnée, c'est plusieurs giga-octets de fichiers plats et très compacts, donc ce sont de gros volumes. En terme de versions du soft, les bonnes semaines je peux en produire trois, et le client a généralement une mise à jour par semaine (souvent on la passe au moment de la mise à jour des données).

L'application d'avant (notre vaisseau amiral) a moins de mises à jour de données (tous les mois, environ), mais beaucoup plus d'utilisateurs. On a en gros une mise à jour par semaine, et des environnements client parfois bizzares (des client avec des filiales délocalisées, du citrix avec des bulles dans tous les sens), mais le processus de mises à jour est LE truc qui marche bien.

Le déploiement d'un client lourd (et des données qui vont avec) va très vite si ce n'est qu'une affaire de copie de fichiers, qui est rapide, peut facilement être scriptée, ne demande aucun droits, et n'abuse pas du téléchargement (l'accès web, c'est toujours lent, souvent en panne, et c'est là que le DSI du client exerce sa créativité). Il faut concevoir le logiciel dans cet esprit (centraliser le téléchargement, ne pas utiliser les bases de registres, éviter comme la peste toutes les fonctionnalités demandant des droits admin, en particulier quand tu choisis les modules à installer à côté de ton soft, et bien penser tous les cas de mises à jour, pour que le système puisse évoluer) mais une fois que c'est fait, c'est très efficace.

Et après avoir grogné contre ces "produits pas modernes" (comment ça pas de setup?), l'informatique du client t'adore, parce que tu ne lui donnes aucun travail...

Francois

[Simara1170]

Sous delphi, tu peux embarquer le setup dans l'appli lourde, et l'exécuter en silencieux, le tout en tapant dans la base de registre (suffit juste d'avoir une autorisation pour se programme, c'est pas la mer à boire, mais c'est vrai que sans, c'est encore mieux), alors non, j'ai vraiment pas de soucis non plus déployer mon application lourde

[Bousk]

On peut imaginer des mises a jour quotidiennes, et on ne se gene pas pour en faire toutes les 2 semaines. Tu arrives à déployer aussi vite ? (c'est vraiment une question)

Pour ne parler que de ce que je connais, et sont grands publics, regarde Steam et le nouveau client BNet
C'est des clients lourds, qui gèrent des clients lourds. Et tout ça se met à jour tout seul sans aucune action de l'utilisateur.
Faut arrêter de croire que client lourd = setup.
Il y en a un initiale, parfois très léger puisqu'il va lui-même télécharger le vrai setup, fichiers nécessaires etc, mais après il fait sa vie.
Et c'est pas plus contraignant que de devoir télécharger une page web finalement.

[phili_b]

Business Objects a été racheté par Oracle,

Objection votre honneur: BO a été racheté par SAP.

Sinon j'ai d'autres entreprises informatiques françaises rachetées: Sunopsis qui est devenu Oracle Data Integrator, SDP l'éditeur d'AMC*Designor (Power AMC) par Sybase.

En plus il semble qu'à chaque fois ça ne soit pas un achat hostile mais une vente volontaire. On dit que souvent les créateurs d'entreprise se lassent quand ils sont plus en mode création, n'empêche que cela aurait été bien si elles avaient été rachetées par des entreprises françaises ayant une vision.

edit: Mais ce n'est pas évident d'avoir le nez creux. Sunopsis étant à Lyon, j'ai eu droit à une démo dans une agence lyonnaise d'une ssii au début des années 2000, ben je n'ai pas du tout adhéré à la version 1. Sans savoir que des années après ce produit deviendra une de mes compétences principales. Mais bon quand Oracle a racheté Sunopsis le produit était pour le coup tout à fait mature et efficace.

[CodeurPlusPlus]

Je ne vais pas répondre à ce gros troll, mais sur le fond, l'inégalable, ce sont plus les fichiers plats bien pensé que les langages. Je suis persuadé que même avec un langage à la mode pour gens pas sérieux comme Java, on peut faire des merveilles si

- on accepte de remplacer la sacro sainte base de données par des fichiers plats
- on trie ces fichiers dans un ordre utile, une bonne fois pour toute (au lieu de le faire à chaque appel)
- on évite le réseau à chaque fois qu'on peut, et on reste sur le poste local, avec ses belles ressources si mal utilisées



Et aussi d'avoir une vision incrémentale des versions: pas de saut brutal, qui nécessiterait des armées de testeurs, et une validation client, et JAMAIS de réécriture complète (ben oui, c'est plus exigeant, parce qu'il faut faire évoluer le code, sans le réécrire d'un coup, mais on n'a rien sans rien).

C'est sans doute tout à fait vrai (en tout cas c'est une réflexion que je me suis souvent faite). Mais ce n'est pas du tout un gros troll : COBOL est vraiment une bête de course pour ces genres de traitements, et devrait garder son avantage longtemps sur les autres langages même si on suit les idées que tu indiques. Certes, le gain COBOL versus Java sera moindre que le gain organisation intelligente versus organisation conne.