Ben c'était sûr en fait ...

#à_code_pourri_l'ordi_vomit

... à coder comme des gorets des applis de merde, le matériel il va pas sentir la rose et te dire merci.

Sans parler du nombre de "programme" qui sont juste des frontaux de navigateur web...

Envoyé par Libel le 3 juillet 2023 à 01h39

+ 0 -

Libel Vermisseau

Plus de biscuit là :
https://jmmv.de...w-machines.html
+ 3 -

Bidon85 Vermisseau

Excel 2000 avec XP sur un dual core avec 2Go de RAM + SSD => lancé en moins d'une seconde.
+ 2 -

GruikMan En réponse à Bidon85 Vermisseau

XP et VB6 !!
+ 0 -

Jampol3 En réponse à Bidon85

Excel 2020 sur un R7 2700X avec 16Go de ram sur un ssd sata => lancé en moins d'une seconde aussi. Mais plus joli et avec plus de fonctions :).
+ 1 -

GruikMan En réponse à Jampol3 Vermisseau

XP étant 32 bit ne gérait pas plus de 4GB de RAM....
+ 1 -

Bidon85 En réponse à GruikMan Vermisseau

Pas tout a fait exact. La base est la même que Windows Server 2003 et celui-ci est capable de gérer 64 Go en étant en 32 bits.
Il semblerait que les premières versions de Windows XP jusqu'au SP2 avaient aussi cette capacité mais l'ont perdu à la suite de mise à jour dans le but d'améliorer la stabilité. La cause serait que les pilotes "grand public" ne tenaient pas compte du PAE.
+ 0 -

GruikMan En réponse à Bidon85 Vermisseau

Et le multicore dans XP.. re lol.... j'en ai fait un sur une VM XP sous virtualbox...
+ 1 -

Bidon85 En réponse à GruikMan Vermisseau

Il y avait même la licence XP Pro 1 - 2 CPU pour le SMP.
+ 1 -

GruikMan Vermisseau

Installe Linux
+ 1 -

hercule18 En réponse à GruikMan Vermisseau

Ce n'est plus si vrai que ça, ça va vraiment dépendre des distrib que tu utiliseras. Dans le cadre de projets récents on s'est aperçu qu'on arriverai à développer des outils scriptés de sorting plus rapides avec des jeux de commande qui ont plus de vingt ans (peut être même plus) que des outils modernes. En sortie c'était un peu moins joli mais diablement plus efficace. D'ailleurs on travaille sur des bases de debian. Pour ceux qui utilisent Linux dans la vraie vie pour le travail, vous utilisez quoi?
+ 2 -

demondriver En réponse à hercule18 Asticot

Debian pour les serveurs, pour s'assurer une solidité à toute épreuve. C'est pas sexy mais ça marche et c'est vraiment pas gourmand. Pour les postes utilisateur, la boite préfère Ubuntu, mais je suis passé sur Mint que je trouve moins chiant (y'a pas cette merde de Snap).
Niveau perf, je n'ai globalement rien à redire que ce soir sur mon poste ou sur serveur.
+ 2 -

hercule18 En réponse à demondriver Vermisseau

Bon ben du coup je change rien ;-)
+ 0 -

Libel En réponse à GruikMan Vermisseau

Comme si j'avais déjà installé un Windows pour faire quelque chose de sérieux informatiquement parlant :]
+ 4 -

gloupi En réponse à Libel Lombric Shaolin

Comme si tu faisais quoi que ce soit de sérieux dans ta vie, informatiquement parlant ou pas.
+ 6 -

Petitprout Vermisseau

non, mais le vrai truc caché derrière tout ça, c'est Micron et son obligation vaccinale, c'est sûr !
+ 0 -

Cyclomore En réponse à Petitprout Vermisseau

Micro$oft, s'il te plait . Il faut rendre à césar ce qui est à césar.

Et sérieusement, oui il a beaucoup fait pour l'obfuscation du code à tous les niveaux. Ceci pour asseoir son emprise sur l'informatique grand public en garantissant aux fabricants qui installaient son OS que les prochaines versions obligeraient rapidement à changer de machine.

Et non, il n'est pas le seul à avoir fait ça, mais quand une recette marche, tout le monde s'y met. Et comme ça on a la guerre entre acteurs du domaine qui vient mettre un peu plus le souk. Par exemple, avant de faire un tri rapide, il est conseillé de randomiser l'ordre de ta liste d'abord, parce-que sinon, tu n'est pas à l'abri de tomber sur un fichier rangé exprès dans l'ordre qui va faire ramer ton algorithme.

Et là, je te parle juste des trucs qu'on apprenait à l'école il y à 20 ans. Depuis, ça a fait des progrès.
+ 20 -

john5

Arrête d’essayer de commenter des sujets que tu comprends pas. Les applis modernes sont plus lourdes qu’autrefois parce qu’elles sont plus complexes, ont plus de fonctionnalités et qu’elles sont fabriquées en kit. Plutôt que d’écrire des programmes de A à Z, on utilise un assortiment de librairies et de composants spécialisés qui vont se charger chacune d’un aspect du programme. Ça permet non seulement d’écrire des programmes beaucoup plus rapidement mais également de façon beaucoup plus fiable, puisque chaque composant sur lequel on s’appuie est déjà stable, testé et maintenu.
L’augmentation du nombre et de la taille des couches d’abstraction n’est ni infondée ni arbitraire, elle correspond à une amélioration continuelle de l’humanisation de l’informatique, c’est à dire l’effort de rendre la technique de plus en plus transparente pour que ce ne soit pas l’utilisateur qui doive s’adapter à la machine et à l’inverse. Il y a 30 ans il était plus ou moins impossible de se servir d’un ordinateur sans avoir suivi une formation spécifique. En 2023 un enfant de 2 ans peut arriver à se servir d’un smartphone et ce sans qu’on lui explique. C’est de ça qu’on parle et rien de plus.
Par ailleurs il est tout à fait logique, si on dispose de puissance supplémentaire, de vouloir s’en servir pour quelque chose d’utile. Et il y a peu de chance que ça change jamais, l’IA est en plein essor, c’est également quelque chose qui est très gourmand en ressources. Quiconque à la moindre notion de complexité algorithmique sait que peu importe la vitesse à laquelle la puissance du matériel augmente, il sera toujours possible très facilement d’utiliser 100% de ces ressources de façon utile. Et c’est ce qu’on fait et qu’on continuera de faire, en s’efforçant perpétuellement de trouver un équilibre entre réactivité et efficacité.
+ 1 -

Knout En réponse à Jampol3 Vermisseau

Suceur.
+ 5 -

demondriver En réponse à john5 Asticot

Je nuancerai un peu le propos (même si je suis complètement d'accord avec ton constat sur Libel. Mais bon, on ne donne pas à boire à un âne qui n'a pas soif...)
L'augmentation du nombre de couches d'abstractions a certes permis une facilité d'utilisation de l'informatique mais à entrainer également des dérives considérables.
Les abstractions présentent souvent deux défaut majeurs (je donnerais des exemples après):
1) l'enfermement des utilisateurs dans ces couches hautes, qui empêchent ceux-ci d'aller voir ailleurs en terme d'écosystèmes et donc les rends captifs économiquement
2) l'abstraction masque une partie voire toutes la complexité, bloquant de fait un entretient ou une prise en main fondamentale de l'outil.
Chez les utilisateurs lambda, l'exemple le plus facile est Apple. L'écosystème Apple est très cloisonné et c'est très compliqué pour quelqu'un sans connaissance de sortir de cet environnement sans un investissement fort (c'est plus un investissement cognitifs que financier). L'abstraction très forte d'Apple a certes des bon coté (facilité de prise en main, etc.), mais entraine aussi une méconnaissance importante de l'informatique en général qui peut s’avérer problématique (j'ai eu des cas de gens qui ne savait pas allumer le Wifi de leur mac, qui avait été désactivé par inadvertance)
En entreprise, les exemples sont plus nombreux, mais je vais citer SAP qui est certes utilisable par n'importe qui mais implique abstrait tellement de choses qu'interconnecter cet ERP à autre chose est souvent très complexe et couteux, et le coté NOCODE de la solution entraine des dépenses déraisonnable pour la maintenance à long terme (à moins de passer par le consulting de l'éditeur qui coute évidement une blinde).
La réponse à ça, elle se trouve du coté du logiciel libre, ou ces dérives sont canalisés (voire annulée) par le fait que cette philosophie place l'utilisateur comme responsable, et qu'il puisse connaitre ce qu'il y a derrière. Cette réponse n'est bien évidement pas parfaite, mais limite la casse.
+ 1 -

john5 En réponse à demondriver

Il faut être lucide, ça ne va pas s’arranger. Le nombre de couches plus réduits par le passé rendaient le métier très technique, mais en même temps il était possible à un ingénieur bien formé d’en appréhender l’ensemble. L’augmentation de l’abstraction, le fleurissement incessant d’écosystèmes numériques, l’approfondissement et la spécialisation de chaque domaine fait le métier "d’informaticien" qui pouvait avoir un sens aux débuts de l’informatique n’en a plus aujourd’hui parce qu’il est devenu impossible pour un individu lambda d’être expert dans l’ensemble des domaines du numérique, on ne peut être expert que dans un champ technique limité. Je donne un exemple à la con : les processus d’authentification, d’identification, de gestion des droits et de l’identité numérique étaient absolument simplissime autrefois. Les devs de n’importe quelle appli le faisaient eux-même, trois bout de code, un formulaire avec un champ mot de passe et une entrée en base de données et zou c’était fini. Aujourd’hui les exigences autant en terme de fonctionnalité que de sécurité dans ce domaine a considérablement augmenté. Le SSO est largement démocratisé, les utilisateurs s’attendent à ce que n’importe quelle appli leur permette de gérer leur identité, respecte le RGPD et utilise des protocoles de chiffrement sûrs et à jour et du coup pour une grosse appli, on ne fait plus ça soi-même, on utilise un framework dédié. Et ce n’est qu’un exemple parmi de nombreux.
Malheureusement je ne vois pas comment ça pourrait s’améliorer. Cette augmentation de l’abstraction et de l’atomicité des composants et des infrastructures numériques est indispensable à la bonne compréhension et à la bonne maintenabilité d’une logiciel.

Pour rentrer un peu plus dans le technique, par nature la programmation orientée objet aboutit mécaniquement à une baisse de performances puisque plus on organise le code d’une façon intelligible et plus on augmente le nombre d’objets, de méthodes et donc de couches sur la pile mémoire, d’appels de fonctions, etc., plus on augmente également la redondance, i.e. valeur d’une variable (ou au moins d’un pointeur) qui se retrouve copiée X fois à travers les appels.

Le coût de cette abstraction se retrouve également à travers l’amélioration des langages de programmation et l’émergence de nouvelles techniques. Par exemple la plupart des langages modernes proposent des outils de "list comprehension", comme Linq en C# par exemple, ou encore la très large démocratisation des "lambdas" rendent le code plus clairs mais pour un coût qui n’est pas toujours facilement estimable par un développeur lambda...

Quelques pistes pour améliorer cela serait sans doute d'œuvrer politiquement pour l’adoption de standards, ou bien j’imagine aussi que l’IA pourra également beaucoup nous aider notamment dans la création de compilateurs "intelligents" capables d’optimisations non-triviales.
+ 7 -

Weng-Weng En réponse à john5 Lombrico de la Cruz

J'ai vu un reportage sur un type qui code un jeu NES, il est obligé de se creuser la tete et trouver des astuces pour que le jeu puisse tenir sur une toute petite memoire. Est-ce que de nos jours les developpeurs s'embetent autant, est-ce que l'utilisation de bibliothèques rend ces processus inutiles? (Je m'y connais assez peu dans le domaine)
+ 4 -

Orme En réponse à Weng-Weng Dresseuse de lombriks

Ça dépends essentiellement du cahier des charges.

Il faut comprendre que les développeurs sont entre le marteau et l'enclume : le client d'un coté qui veut la Lune sans débourser un sou, et le chef de projet/hiérarchie en général de l'autre, qui veut que tout soit fait pour hier pour pouvoir nous assigner à plusieurs clients en même temps ( et les faire payer temps plein chacun, hein, faut pas déconner, on va pas les faire payer temp mutualisé et perdre une rentrée d'argent ).

Si le client fait bien son truc, le cahier des charges comprends les contraintes technologiques dans lesquelles on doit évoluer : type de machines, processeur, limite de mémoires, etc, etc. Là on sait où on s'en va et on a des arguments pour justifier telle ou telle façon de coder auprès du client et du chef de projet..

Si malgré nos demandes répétées le client s'acharne à rester vague, on fait signer le cahier des charges en l'état, et on transfère au juridique pour l'obliger à payer une fois qu'on lui aura livré la bouse qu'il a demandé. Sans demande précise du client, on fait du codage Lego car le temps de développement coûte cher et la direction nous oblige à faire de la merde pour aller plus vite.

Info connexe : si vous voulez développer pour vous même de façon simple et pondre des executables qui demandent pas 50 000 couches d'abstraction : PowerBasic

https://www.powerbasic.com/
+ 0 -

Cyclomore En réponse à Orme Vermisseau

Power basic? J'y jetterais un coup d'œil, tiens. J'ai détesté quand ils ont arrêté Visual basic . A l'époque, plus de 70% des applications dans le monde étaient développées avec.

Sinon, en informatique de gestion, j'arrive à me maintenir a flot avec Access. Je déteste Micro$oft, bien sûr, mais quand je vois les galères de certains clients qui on choisi SAP, je me dis que j'ai fait le bon choix. Sur un parc hétérogène XP W8 W10 W11, j'arrive à maintenir une ERP en access 2010 sans trop de problème. Et ça fait 20 ans que ça dure.
+ -4 -

Libel En réponse à john5 Vermisseau

Plus "lourde", comme mon post du dessous ;)
... il est clair que tu n'as pas lu mon post. Mais t'es tu même relu ?

"une amélioration continuelle de l’humanisation de l’informatique"
Hi hi !
On est clairement dans l'inverse, mais pas grave. On est plus à cela prêt ! ;)

L'Âne qui n'a pas soif ... de vaxxos !!!! ;)
+ 3 -

Bidon85 En réponse à john5 Vermisseau

Lorsque je vois la différence de consommation de ressource pour un simple "hello world" en VB6 et en VB .Net, ça ne se justifie pas...
+ 2 -

Cyclomore En réponse à john5 Vermisseau

Alors, chut Libel, chut Gandhi, on se fout de votre avis.

Mais quand même, tu avouera que le codage de trucs inutiles à autre chose que consommer des ressources, ça existe. Tu parle de transparence. Tu te souviens de celle de windows vista ? A quoi ça servait à part bouffer un max de ressources? Techniquement, j'avoue, c'était bluffant.

Mais à part pousser gentiment l'utilisateur lambda vers l'achat d'une machine plus puissante, ça ne servait pas à grand chose.
+ 0 -

_pepe_ En réponse à john5

Pas d'accord.

Le principe de la fabrication d'applications « en kit » n'a absolument rien de nouveau. Et si les applis modernes sont fabriquées « en kit » à l'aide d'un ensemble plus complexe de composants correspondant à des couches plus nombreuses d'abstraction, d'une part ça ne permet pas de les rendre plus rapides (c'est même le sujet des articles donnés en référence), d'autre part ça ne rend pas forcément leur utilisation plus naturelle ou intuitive. (Il semble hélas que l'ergonomie soit une science aujourd'hui oubliée par la plupart des développeurs de systèmes et d'applications. Quant au caractère intuitif d'un appareil, ce n'est pas son aptitude à être utilisé par un enfant qui l'a entre les mains depuis qu'il est né, mais celle d'être utilisé par un retraité qui n'a plus du tout les mêmes capacités d'apprentissage et d'adaptation.)

Les applis modernes n'ont pas non plus *forcément* plus de fonctionnalités (l'abandon de certaines fonctionnalités est d'ailleurs un point assez souvent déploré lors des évolutions majeures des systèmes). Et lorsqu'il y a effectivement une augmentation du nombre de ces fonctionnalités, les nouveautés qui s'imposent aux utilisateurs sont loin de correspondent toujours à des besoins ou à des attentes de leur part, et la diminution du ratio performance/puissance qu'ils subissent est, en proportion, généralement bien plus importante que cette augmentation.


Je ne nie pas que certaines nouvelles fonctionnalités aient été réellement utiles (voire indispensables) aux utilisateurs, ni qu'elles aient nécessité une inflation et une complexification des logiciels, ni qu'elles aient nécessairement entraîné une baisse des performances du système à puissance machine constante. Je ne nie pas non plus que des évolutions matérielles aient pu imposer certaines complications.

Ce que je dis en revanche, c'est que globalement la multiplication des fonctionnalités disponibles, la complexification des logiciels et la baisse de performances n'ont profité que très partiellement aux utilisateurs, et qu'elles ont même souvent été réalisées à leur détriment.

Les premiers bénéficiaires de cette inflation et de cette complexification sont les grands éditeurs de logiciels, qui ont ainsi pu imposer leurs modèles spécifiques d'organisation, d'usage et de développement, avec pour conséquence de rendre les utilisateurs et les développeurs captifs. Les développeurs ont également bénéficié d'outils qui les ont soulagés dans leur travail, le plus souvent au détriment de l'efficacité du résultat final.


Aujourd'hui, on sait développer des logiciels pour de petites plateformes matérielles visant à fournir la même ergonomie et les mêmes fonctionnalités que des applications modernes tournant sur des PC, sans pour autant devoir supporter la multitude ni la taille des composants et des sous-systèmes qu'on trouve sur ces derniers.

Au bout du compte, on arrive à obtenir une réactivité et des performances bien meilleures, en dépit d'une capacité mémoire et d'une puissance machine inférieures de plusieurs ordres de grandeur.

La grosse différence, c'est que la modularité et les abstractions utilisées lors du développement des logiciels ne transparaissent pratiquement pas dans le résultat final et, je l'admet, que ce type de réalisation n'est pas à la portée de développeurs amateurs. Toutefois, je m'étais laissé dire que, développeur informatique, c'était censé être un métier...
+ 0 -

Orme En réponse à _pepe_ Dresseuse de lombriks

Développeur EST un métier...

Le problème est que dans le modèle économique actuel, c'est le vendeur/chargé de projet qui a le pouvoir décisionnel. C'est pas un informaticien, c'est un technico-commercial.

Dans des grosses boites comme CGI ou Bell, ils ne « s'abaissent pas à consulter » les développeurs, je cite pour te donner une idée de la mentalité toxique qui règne dans ces sociétés.

Pareil pour les SSII, elles tout ce qui les intéressent c'est de vendre du temps de développement, pour elles les devs ne sont mêmes plus des êtres humains, on est juste un produit qu'elles vendent.

Il faut descendre au niveau des petites entreprises de moins de 50 employés pour retrouver une mentalité saine, où les chargés de projet prennent la peine de discuter, voire même ont monté les échelons par le mérite et savent de quoi ils parlent par l'expérience.
+ -2 -

Libel Vermisseau

Réponse au post du dessus ;)
Image de Libel
+ 4 -

Friant Vermisseau

Quid de la V3 ?
+ 4 -

Peevee En réponse à Friant LoMBriK addict !

Enfin un commentaire intéressant ajoutant une valeur concrète à cette discussion..
+ 1 -

Weng-Weng En réponse à Friant Lombrico de la Cruz

Elle est prête, c'est juste que les machines sur le marché à l'heure actuelle ne sont pas assez puissantes
+ 1 -

gwen En réponse à Weng-Weng Vermisseau

J'me suis fait un sli de 4090', sur un cm pcie5, avec 256 giga de ddr6, normalement je devrais pouvoir faire tourner les jeux en Java.
+ 0 -

Weng-Weng En réponse à gwen Lombrico de la Cruz

C'est pas faux!
Inscrivez-vous ou Connectez-vous pour envoyer un commentaire
14