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...
Précédent
Touche Q ou GAUCHE pour passer au fichier précédent
35 commentaires
Tri par popularité
Tri chronologique
Suivant
Touche D ou DROITE pour passer au fichier suivant
Bannière réalisée par l'extraordinaire Tzeenchy
Musique par Middle Ages
68
Libel Vermisseau
https://jmmv.de...w-machines.html
Bidon85 Vermisseau
GruikMan En réponse à Bidon85 Vermisseau
Jampol3 En réponse à Bidon85
GruikMan En réponse à Jampol3 Vermisseau
Bidon85 En réponse à GruikMan Vermisseau
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.
GruikMan En réponse à Bidon85 Vermisseau
Bidon85 En réponse à GruikMan Vermisseau
GruikMan Vermisseau
hercule18 En réponse à GruikMan Vermisseau
demondriver En réponse à hercule18 Asticot
Niveau perf, je n'ai globalement rien à redire que ce soir sur mon poste ou sur serveur.
hercule18 En réponse à demondriver Vermisseau
Libel En réponse à GruikMan Vermisseau
gloupi En réponse à Libel Lombric Shaolin
Petitprout Vermisseau
Cyclomore En réponse à Petitprout Vermisseau
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.
john5
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é.
Jampol3 En réponse à john5
Knout En réponse à Jampol3 Vermisseau
demondriver En réponse à john5 Asticot
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.
john5 En réponse à demondriver
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.
Weng-Weng En réponse à john5 Lombrico de la Cruz
Orme En réponse à Weng-Weng Dresseuse de lombriks
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/
Cyclomore En réponse à Orme Vermisseau
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.
Libel En réponse à john5 Vermisseau
... 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 !!!! ;)
Bidon85 En réponse à john5 Vermisseau
Cyclomore En réponse à john5 Vermisseau
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.
_pepe_ En réponse à john5
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...
Orme En réponse à _pepe_ Dresseuse de lombriks
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.
Libel Vermisseau
Friant Vermisseau
Peevee En réponse à Friant LoMBriK addict !
Weng-Weng En réponse à Friant Lombrico de la Cruz
gwen En réponse à Weng-Weng Vermisseau
Weng-Weng En réponse à gwen Lombrico de la Cruz