Cher nal,
En ce dimanche automnal qui ici reste bien doux, je prends ma plume mon clavier pour te parler d'un fait qui me taraude. Oui, je sais, ça fait longtemps que je te laisse prendre la poussière, je n'écris jamais, ne me coupe pas la parole, ta gueule quand je te parle !
Notre outils à tous, cette merveilleuse technologie m'inquiète un peu plus chaque jour.
Il n'y a pas loin de 15 ans, on sentait bien les limites de nos machines, notre pingouin venait en sauveur contre le vil XXXXXX 98 (troll censored), feu BeOS était encore plus véloce (le seul avec lequel je pouvais coder, émuler avec bochs et mater un film sans faire fondre ma machine de l'époque, bien que pas loin…), RiscOS donnait l'impression d'avoir acheté une nouvelle machine à chaque update tant elle devenait chaque jour plus rapide.
Nos téléphones mobiles faisaient encore téléphone, voire SMS de façon pleinement satisfaisante et efficace, et surtout tenaient la batterie une bonne semaine, si ce n'est plus.
Où en sommes-nous aujourd'hui ?
Rien que mon smartphone un peu ancien maintenant (grosso modo 3 ans, une éternité) laggue chaque jour un peu plus, taper un sms et qu'il soit reçu peut me prendre jusqu'a 5 minutes tant il semble compliqué d'associer une frappe sur le clavier à l'apparition du texte à l'écran. Alors bon, l'interface est plus jolie, j'ai des icônes, le clavier est graphique, mais… mon pc des années 90, voire mon non PC 8 bits d'avant ne me donnait pas l'impression de lagguer, pour un résultat similaire voire plus compliqué, comme envoyer un mail HTML (ptet pas sur le 8 bit certes).
Sur la notice de mon téléphone, il est indiqué un bon GHz pourtant. De quoi faire rougir mes bonnes vieilles machines à moins de 10MHz qui m'énervaient moins.
J'en suis venu à commander un nouveau modèle, schyzophrène multicore. Mais est-ce vraiment la bonne solution ?
Quand je vois le dev des applis d'aujourd'hui, la bonne vieille appli, simple, efficace et soignée a fait place à la grosse appli sans limites définies, aux specs sans fin, à la complexité innommable, remplie d'objets, d'héritages multiples, imbriqués, templatés en boucle… on y fait des noeuds de partout sans se demander ce qui va réellement se passer derrière !
Il y a quelques années, booter mon PC me prenait quelques minutes. Aujourd'hui mon PC actuel est digne d'un ovni en comparaison de ma pirogue de l'époque, et le boot est toujours du même acabit, à peine plus rapide (sauf avec e17 ou xfce).
Je veux bien croire que les services se sont multipliés, l'archi complexifiée, mais l'entropie ne nous jouerait-elle pas des vilains tours ?
J'ai bien un VTT, mais j'ai encore tout mes cheveux, suis je déjà vieux ? ou avons-nous raté un truc en chemin ?
ou dois-je me reconvertir dans la restauration, la peinture ou la menuiserie ?
# rho
Posté par BAud (site web personnel) . Évalué à 6.
moi qui pensait que tu aurais installé debian sur ton mobile, je suis déçu déçu déçu :/
[^] # Re: rho
Posté par vincent LECOQ (site web personnel) . Évalué à 2.
elle tournait bien sur mon freerunner, tout comme sur mon zt180 !
# Il ne faut pas confondre l'innovation et le progrès.
Posté par Zylabon . Évalué à 1.
Tout est dans le titre.
Quand la mise à jour d'un logiciel sort et qu'elle apporte des régressions majeures, on garde la vielle version. Pourquoi ne pas généraliser cette technique d'une efficacité stupéfiante ?
Please do not feed the trolls
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par BAud (site web personnel) . Évalué à 1.
va en parler à ceux qui ont mis à jour leur application et ne peuvent plus revenir en arrière :/
http://linuxfr.org/users/fork_bomb--2/journaux/les-cartes-du-systeme-d-exploitation-mobile-le-plus-avance-du-monde
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Zylabon . Évalué à 10.
Quand on a renoncé à contrôler la version du logiciel exécutée sur sa machine, effectivement, c'est mort (la régression s'est faite au moment de ce renoncement).
Please do not feed the trolls
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par vincent LECOQ (site web personnel) . Évalué à 2.
devons nous considérer un temps d'execution sur un support plus rapide comme une regression fonctionnelle ?
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par hervé Couvelard . Évalué à 10.
oui
Que l'on ne cherche pas à descendre de 2 secondes à 1 secondes 47 je veux bien le croire. Mais il y a des limites.
Je me souviens de mon premier ordinateur : c'était un 486 DX266, était vendu avec le nouveau et révolutionnaire win95 et tournait dans 8 mo. Je pouvais faire de la compta (works), du traitement de texte (works), du dessin (works). Il n'y avait pas de carte réseau mais un port série ou je pouvais connecté un modem usrobotics 14.4 k et je pouvais tenter de récupérer un mail sur un abonnement payant à la minute. J'avais trouvé un logiciel (payant) pour faire jouer et dessiner mes enfants kid pix studio.
Aujourd'hui, je reste sur une vielle bécane, un corde 2 duo T7250 à 2 ghz et 2 Go de ram. Je sais que je fait bien plus de choses mais je ne le trouve pas pus rapide (à l'utilisation).
Je comprends que l'on code ce que l'on aime, mais je trouve inadmissible qu'il ne reste pas une série d'applications simples permettant de faire rapidement les choses courantes. Toutes les évolutions d'application se font dans le grossissement du ventre, sans gagner grand chose : elles sont plus lourdes, plus lentes (compensé par la vitesse de la machine) et ne donnent pas beaucoup plus de fonctionnalité. Ma veille technologique utilise une bonne partie du temps à trouver des applications libres utilisant peu de ressources, même si cela implique moins de fonctionnalités.
Maintenant je sais que si je veux je n'ai "kafaire". Comme je n'ai pas le temps (ni l'envie) de coder une application qui existe déjà à des dizaines d'exemplaires, je descends les marches de l'expérience utilisateurs en choisissant de "vieilles applications" qui font peu de choses mais correspondent à ce que je cherche. Pour taper quelques lignes de textes kwrite ou leafpad ou même nano. Pour coder geany ou, grand luxe, kate. pour les mails je n'ai pas encore eu le courage de changer icedove, mais je sais que cela va arriver : il faut que je trouve un truc qui permette de passer à maildir.
Je ne comprends pas que dans le libre les "codeurs" et "décideurs" n'arrivent pas à stabiliser des applications simples, faisant les trucs de base et pouvant tourner dans un espace oublié de la mémoire. J'ai été chef de projet sur une application de labo de langue, je devais me battre continuellement avec le dev pour lui interdire toute nouvelle dépendance et tout nouveau ralentissement impliqué par une fonctionnalité nouvelle.
J'ai fait l'erreur de sa réalisation en QT. Un jour je le reprendrais pour le refaire en python. Tout ne compile plus sur un système tout frais installé aujourd'hui. WTF ? à peine 5 ans et il faut retoucher le code. Et encore il n'avait que peu de dépendances…
Le monde change, les gens aussi. Toutes les concessions qui ont été faites pour "attirer du monde" sont en train de se payer. Nous avons éduqué nos jeunes au pragmatisme : ils le mettent en oeuvre et ont décidé que la liberté était secondaire. vlc qui passe à lgpl ! ! Pour gagner quoi ? quel est le gain de permettre à des entreprises de faire du proprio avec du code libre ? sur un lecteur vidéo ? RIEN. Juste permettre à ceux qui ne veulent pas se donner les moyens de leur liberté d'en profiter à peu de frais.
Oui cela ne changera pas pour moi car je pourrais toujours utiliser vlc si je le veux. Mais nous envoyons un message au monde "pragmatique" qui considère que la liberté de l'utilisateur est secondaire : nous lui disons : prenez notre code et fermez le, la liberté des autres on s'en moque. Il ne faut plus venir raler contre apple et microsoft : ils font ce qu'on leur donne l'autorisation de faire. rien de plus, rien de moins.
Oui nous sommes en plein régression. Mais les effets vont se faire réellement sentir dans 4-5 ans et il sera trop tard. Mais peut importe, on ne fait pas boire un âne qui n'a pas soif.
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par BAud (site web personnel) . Évalué à 3.
t'abuses http://www.elho.net/mutt/maildir/
de rien :-)
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par claudex . Évalué à 4.
Ça arrive tout doucement dans Thunderbird. Ce n'est pas encore du maildir je crois mais c'est un format similaire (un fichier par mail). http://jaisejames.wordpress.com/2012/03/15/to-activate-maildir-in-thunderbird/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Astaoth . Évalué à 4.
Je ne qualifierai pas Thunderbird de "léger", et de logiciel faisant peu de chose mais le faisant bien.
Emacs le fait depuis 30 ans.
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par gnumdk (site web personnel) . Évalué à 4. Dernière modification le 18 novembre 2012 à 18:59.
C'est vrai que du coup, ça fait un peu peur, confondre Qt et Python, tu bossais chez Edu4, c'est ça ?
Alors, déjà, y'a 5 ans c'était Qt3 et ce dernier est toujours fonctionnel, donc si c'est cassé, c'est certainement pas la faute de Qt…
De plus, 5 ans? Mais c'est normal, c'est un filtre automatique du logiciel libre, les logiciels qui ne sont pas maintenus meurent: ça s'appelle la sélection naturelle…
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par hervé Couvelard . Évalué à 10.
non, je ne confonds pas QT et python. Lorsqu'on l'a mis en route il a été décidé (avec le codeur) de le faire en Qt parce qu'il connaissait bien. J'ai laissé faire, maintenant je regrette un peu.
Il y a toute une partie lié à QT (plus que la GUI) et ca me chatouille un peu tout de même.
Ce n'est pas dans Qt que ca a cassé, mais la dépendance avec libvlc et des fonctionnalités qui sont sorties. Il faut retoucher le code.
Ce que tu appelles filtre automatique des logiciels libres est une fausse excuse. Mais je ne vais pas chercher à argumenter avec toi cela ne sert à rien, tu as déjà ton idée sur la question et nous ne sommes pas d'accord. Un logiciel qui est fonctionnel, qui apporte une solution et qui utilise une bibliothèque extérieure devrait normalement toujours compiler SAUF si les fonctions qu'il utilise disparaissent car elles sont une faille de sécurité.
Que la compatibilité binaire ne soit pas assurée, pas de soucis, mais qu'il y ait incompatibilité sur les sources ! C'est un peu gros de devoir retoucher le code sur des fonctions simples de la lib. Que l'on retouche le code pour utiliser une nouvelle fonctionnalité, oui mille fois oui, mais pour juste compiler comme il faut… Tu as l'impression que 5 ans c'est une éternité, un logiciel dans une école peut bien rester 20 ans ! ! ! On se demande pourquoi les dev incorporent dans leurs applis des dossiers complets d'autres applis ! ! ! On se demande pourquoi les gens compilent en static. Lorsqu'on fournit une lib, il me semble que maintenir les fonctions de bases de versions en versions est un peu un minimum, mais ce n'est que MON opinion et ce que MOI je ferais si je devais fournir une lib.
Maintenant lorsque je prendrais un peu de temps, je ferais les modifications dans le code pour qu'il continuer à compiler.
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par claudex . Évalué à 8.
C'est marrant d'avoir une justification pareille et de dire en même temps qu'il aurait fallu le faire en Python qui a cassé énormément de truc avec la version 3.
Un logiciel pour lequel il n'y a plus personne pour faire les petites modifications pour que le code continue à compiler me fait assez peur du point de vue de la sécurité. Mais si cette dernière n'est pas un problème, il suffit de compiler avec une vielle version de la lib (la dernière version de Qt3 par exemple).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par hervé Couvelard . Évalué à 8.
pour python, je peux toujours "compiler", avec python 2.6 ce que j'ai codé à l'époque personne n'est obligé de passer à python 3. Si demain python 2.x disparaît des distributions ca va râler sec.
Le truc avec le logiciel libre, c'est que tu ne le paies pas. et que celui qui le code, souvent, ne gagne pas sa vie avec et le fait, à coté, pour des raisons philosophiques.
Comme le code source tu as, tu trouveras toujours quelqu'un pour faire les modifications en le payant. et tu n'es même pas obligé de donner ces modifications et tu peux les garder pour toi.
Maintenant ne trouves-tu pas idiot de devoir payer quelqu'un pour modifier quelques lignes pour faire compiler un truc, par exemple sur une nouvelle machine que tu achètes et installes avec le dernier debian stable (ou pire le dernier ubuntu?) juste parce que la lib n'est pas entièrement compatible source avec la versions d'alors ? Moi je trouve cela dommage.
Je regarderais à l'occasion lorsque j'aurais le temps et l'envie pour l'installer sur une machine avec une distribution récente pour mes enfants. Maintenant les écoles qui l'ont installé, pour qui ça fonctionne parfaitement, qui n'ont pas de rond pour payer ni l'installation, ni une mise à jour, l'ont dans le baba parce que ca compile plus et ne peuvent pas le faire sans "ramer à installer une vieille distribution : on va devoir faire à la windows, garder les sources complètes et les binaires des distributions installées pour pourvoir mettre une nouvelle machine. et LÀ il y a un problème de sécurité.
Alors oui je pourrais regarder et faire les modifications, mais ca ne compilerait plus sur les anciennes machines, faudrait bien garder les binaires… Et pour le moment, je n'ai pas de temps à consacrer à cela.
Ensuite compiler avec les vielles versions ca complique pas mal le truc : faut que vlc soit compilé avec la même version de la lib, donc faut recompiler le nouveau vlc ou l'ancien vlc sur la distribution plus récente. Ca devient vite assez complexe. JUSTE parce qu'une lib ne garde pas sa compatibilité source.
je ne râle pas plus que ça parce que les dev de vlc font ce qu'ils veulent, mais je trouve que c'est une régression et que nous n'allons pas dans le bon sens. Mais ce n'est que MON avis..
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Milridor (site web personnel) . Évalué à 10.
Si on a pas les compétences, on paye un contrat de maintenance ou on paye à chaque petit acte.
C'est vrai pour tout les domaines: Industrie, Automobile, Bâtiment, etc.
Je ne vois pas pourquoi l'informatique échapperait à ça.
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par gnumdk (site web personnel) . Évalué à 9.
Donc en gros ça casse dans une libs autre que Qt et c'est Qt le problème… Dis toi quand même que si il avait codé avec autre chose que Qt, y'aurait surement encore plus de choses cassées…
T'inquiètes je connais bien le problème, des logiciels de merde qui ont 20 ans, j'en vois plein, enfin j'en voyais car depuis que je suis arrivé, j'ai demandé aux enseignants de trouver des alternatives pour ne pas transformer nos postes Windows en passoire…
Après, désolé, mais si tu veux que ton logiciel soit fonctionnel 20 ans plus tard, tu le compiles en static et tu seras peinard…
Quand à l'argument bidon de python, tu l'aurais fait avec quoi l'ui de ton logiciel ? Avec Tk ?
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Astaoth . Évalué à 10. Dernière modification le 18 novembre 2012 à 21:56.
Ce que je note avec GNU/Linux, c'est qu'un logiciel qui n'a plus de mises à jour parce qu'il marche correctement, sans bugs, et auquel on n'ajoute pas de fonctionnalité est considéré comme non-maintenu, et voir éjecté des dépôts.
Emacs le fait depuis 30 ans.
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Atem18 (site web personnel) . Évalué à -8.
Un logiciel à toujours des bugs. Et qui dit bugs, dit faille de sécurité potentielle. Comme les distros Linux ne peuvent se le permettre, ben hop dehors.
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Astaoth . Évalué à 1.
Un logiciel n'a pas toujours de bugs, tout dépend de comment il est programmé. D'ailleurs, les langages de programmations fonctionnels sont en parti conçus pour pouvoir démontrer mathématiquement que le programme fonctionne sans bugs.
Si c'est un ordinateur déconnecté du réseau ce n'est pas trop un problème. Et peut-être qu'une faille d'un logiciel qui fonctionne sans utiliser le réseau, et qui n'est pas spécialement connu (donc pas beaucoup de monde pour chercher les failles) ne me gêne pas.
Sauf que les distro GNU/Linux conservent dans leurs dépôts des logiciels buggés, et dont les bugs sont connus, du moment qu'il y ait quelques mises à jours de temps en temps qui ne corrigent pas forcément de bugs.
Emacs le fait depuis 30 ans.
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
" les langages de programmations fonctionnels sont en parti conçus pour pouvoir démontrer mathématiquement que le programme fonctionne sans bugs."
non, ils ne font que détruire les classe de bug lié à la gestion de la mémoire ou les pointeurs nuls. C'est énorme mais pas encore suffisant.
"Si c'est un ordinateur déconnecté du réseau ce n'est pas trop un problème. Et peut-être qu'une faille d'un logiciel qui fonctionne sans utiliser le réseau, et qui n'est pas spécialement connu (donc pas beaucoup de monde pour chercher les failles) ne me gêne pas."
Les fabricants de matos industriels pensaient comme ça aussi. Maintenant, tout est mis en réseau, et un grand nombre de ligne de production sont de vrai passoire.
"La première sécurité est la liberté"
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par navaati . Évalué à 1.
Non non, on parle vraiment de preuve formelle que le programme est sans bug (c'est à dire qu'il correspond rigoureusement à ses spécifications).
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Langages de programmation fonctionnel ne veut pas dire forcément langage formel prouvable. On ne peut pas tout "prouver" en ocaml.
De plus, la "preuve" concerne un théorème qui correspond à un point de spec, il peut y avoir des oublis ou quelques choses de mal définis. Même un langage "à preuve" ne sera pas sans bug. Et puis dans la pratique, les "prouveurs" automatiques ne passent pas à l'échelle.
"La première sécurité est la liberté"
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par lolop (site web personnel) . Évalué à 4.
Un programme ça s'exécute sur un ordinateur physique, avec un OS, des drivers, des événements utilisateur, des problèmes de disque ou de réseau, des fichiers mal formés… bref, un monde réel.
Dans quel monde sont définies les spécifications ?
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Référence nécessaire. Et n'oublie pas que Lisp a été conçu dans les années 50, hein. Tu me donneras une liste des propriétés qui ont été prises en compte dans le design de Lisp pour qu'on puisse prouver mathématiquement l'absence de bugs dans les programmas.
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
D'après un bouquin d'architecture d'ordinateur célèbre dont j'ai oublié le nom, une machine balancé a 1 Mo, pour 1 Mips et 1 Mbps d'IO. Aujourd'hui, on est à 8 Go de RAM, 4*6Gips et 1gbps ethernet (maxi) + 200Mo/s vers un disque (500 sur SSD).
Les cpu ont bien plus progressé que le reste. Il suffit de voir une machine avec un SSD pour comprendre la différence de sensation de vitesse. Sur un ordinateur portable avec leur HD poussif, la différence est énorme (j'ai mis un SSD dans un EEE). On retrouve ce même genre de sensation lorsque la fonction fsync() de la machine est désactivé. Nombre de logiciel en abuse et cela a un impact énorme sur les performances des IO.
"La première sécurité est la liberté"
[^] # Légèreté --> langage interprété ? (Python ici)
Posté par freem . Évalué à 8.
Y'a que moi qui fait un buffer overflow en lisant que tu râles après la performance merdique des softs modernes et que derrière tu estimes que python est un meilleur choix que C++/Qt?
Faut m'expliquer la…
Bon, pour le reste, je pense qu'effectivement ton dev à commis une erreur: le framework graphique devrait se limiter aux graphismes. Maintenant, Qt, c'est presque un langage en soi (et devinez pourquoi j'aime pas…)
Après, ça dépends aussi des spéc que tu demandais. La cible était windows only? Ben, utiliser l'API win32 aurait permis une compatibilité pour les années à venir, et elle est plutôt complète.
Ah, ça devait être portable? Hum, la, c'est un fait, c'est tout de suite plus dur de trouver quelque chose qui ne bouge pas en fonction des OS sur lesquels ça marche.
Après, problème dû à un changement de version? As-tu tenté de compiler la version de Qt d'origine? Ben oui, quand on passe des version X.a.b aux versions Y.c.d ça implique traditionnellement que l'on casse l'API publique, c'est bien connu et la plupart des dev suivent cette méthode. A noter que souvent, le 3ème chiffre permet de conserver la compatibilité binaire, chose qui n'arrive que rarement avec le 2nd.
Et pour le fait de retoucher des trucs qui marchent, je trouve ça normal. Sur une appli que je fais (stade alpha, certes), j'ai un code crado pour le menu, intimement lié aux plug-ins. Ben ça rend la maintenance plus chère, alors je suis en train de réécrire ça (et de tenter de dissimuler mon incompétence de l'époque derrière un flot de commit XD).
Donc, une telle modification à un rôle (au choix, droit de sélectionner plusieurs résultats): booster la perf, faciliter la maintenance, diminuer le couplage avec d'autres composants…
Dans le cas de Qt, il semble que la dernière option ait été un objectif majeur de la version 3 à la 4.
Et je vais finir par la référence au code orienté objet.
Ca me fait définitivement marrer d'estimer qu'un code orienté objet est plus lourd/lent. Pourquoi? Parce que dans les code C, faits par ceux qui aiment pas les classes, on trouve, entres autres:
Et, je suis navré de vous le dire, mais c'est du code objet, version illisible. A part ne pas utiliser le mot-clé class (et devoir se taper le passage du 1er argument de façon systématique, avec risque de merder sur l'allocation mémoire, bien sûr), il n'y a aucune différence… Enfin, si on adopte un langage dont la mentalité est de pas faire payer pour les trucs qu'on demande pas explicitement (je ne citerai pas de noms pour éviter de déclencher plus de trolls).
L'objet n'alourdit pas le code, il le rend lisible. Et ce n'est pas lié au langage, mais à la façon de penser du dev. De toute façon, tout finit en assembleur, alors rien n'est objet, pas vrai?
[^] # Re: Légèreté --> langage interprété ? (Python ici)
Posté par Batchyx . Évalué à 4.
Ce que tu montre n'est pas du code objet, désolé. l'Objet suppose qu'il y ai au moins de l'héritage et des méthodes virtuelles. Là j'en vois pas. Pourtant, c'est souvent ces deux points qui font qu'un code objet est plus lent: Les méthodes virtuelles interdisent toute optimisation par exemple.
[^] # Re: Légèreté --> langage interprété ? (Python ici)
Posté par lolop (site web personnel) . Évalué à 8.
L'objet n'implique pas la notion d'héritage ni de méthodes virtuelles. On a l'encapsulation des données et les méthodes de manipulation qui gèrent le comportement.
Après, le fonctionnement en classes, l'héritage, c'est un plus (ou un moins pour certains).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Légèreté --> langage interprété ? (Python ici)
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
D'ailleurs, je serais curieux de voir un langage objet sans héritage, qui ne sert quasiment jamais (90% du temps, c'est de l'inclusion de faignant), mais qui interdit le polymorphisme et/ou l'inférence de type.
"La première sécurité est la liberté"
[^] # Re: Légèreté --> langage interprété ? (Python ici)
Posté par claudex . Évalué à 3.
Pas mal de langage (au moins Java et Python) utilise l'héritage à partir d'une classe de base (Object en Java, object en Python). C'est donc assez utilisé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Légèreté --> langage interprété ? (Python ici)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Oui mais tu peux faire la même chose différemment. De mémoire, c'est pour faciliter la stringification, l'allocation mémoire voir l'introspection.
"La première sécurité est la liberté"
[^] # Re: Légèreté --> langage interprété ? (Python ici)
Posté par barmic . Évalué à 1. Dernière modification le 21 novembre 2012 à 12:00.
La généricité de java se base sur cet héritage aussi. Les exceptions s'en servent aussi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Légèreté --> langage interprété ? (Python ici)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
tu peux avoir les 2, sans héritage du tout (type somme, polymorphisme).
"La première sécurité est la liberté"
[^] # Re: Légèreté --> langage interprété ? (Python ici)
Posté par barmic . Évalué à 1.
J'ai pas dis le contraire. Le C++ fait de la généricité sans héritage par exemple. Je donne juste des cas d'utilisation.
Par contre le polymorphisme utilise l'héritage la majorité des fois (c'est d'ailleurs pour ça que l'on crée des fonction virtuelle).
Encore une fois je ne parle pas de ce qu'il est possible de faire mais de ce qui est fait.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Il ne faut pas confondre l'innovation et le progrès.
Posté par FantastIX . Évalué à 1.
C'est ainsi que, de plus en plus, je me dis que, si ça continue, je n'utiliserai plus l'informatique que pour mes besoins personnels. Un peu de fatalisme. Si ça ne change rien, ça ne peut pas faire de tort… /o\
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
# ou pas ?
Posté par antistress (site web personnel) . Évalué à -9.
ou pas GANGNAM STYLE !
# Téléphone
Posté par barmic . Évalué à 1.
Tu ne décris absolument pas mon vécu. J'ai utilisé des téléphones Nokia/Simbian jusqu'à l'an dernier (5160, 3410, 3510i, 6086 et enfin le 5230) je suis ensuite passé à Samsung/Android (avec le Galaxy Ace). Je suis toujours aussi rapide pour écrire mes textos et je n'ai rencontré des latences qu'avec le 5230, mais c'était du à la technologie de son écran (ça réagis super mal !). Par contre oui je change toujours de téléphone pour avoir quelques chose de plus évolué et qui fait pleins de choses (maintenant je surf, fais des photos/vidéos, etc).
Je ne sais pas quel téléphone tu as, ni avec quel système il tourne mais n'en fait pas une généralité. D'autre part c'est ton choix d'utiliser ce genre de téléphones, il en existe des simples qui sont comme ceux d'avant, de plus ils sont moins chère que les smartphones.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Téléphone
Posté par Julien Gilbert . Évalué à -3.
Cher auteur du journal, arrête de faire le vieux con, tu as énervé le petit, il est parti bouder dans sa chambre (il te prend d'ailleurs ouvertement pour un con "c'est ton choix d'utiliser ce genre de téléphones, il en existe des simples qui sont comme ceux d'avant")
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Téléphone
Posté par barmic . Évalué à 3.
Parler de mon expérience c'est être un jeune con (surtout que je pars d'un des premiers GSM grand public sorti il y a une petite quinzaine d'année) ?
Que chacun le prenne comme il veut. S'il n'est pas content que son téléphone soit lent pour appeler et envoyer des texto alors que ses anciens téléphones étaient si bien pourquoi ne pas prendre un téléphone comme un Samsung Solid ?
Même dans le cas où il veut aussi avoir un gros smartphone des familles, je me demande vraiment où est son problème. Je n'ai jamais constaté le genre de lenteur qu'il décris sur les téléphones que j'ai pu voir (en plus de ceux sus-cités il y a le HTC Wildfire et le Samsung Galaxy Mini2).
Si son téléphone est un N900 c'est lui qui se fout de nous. L'achat de ce téléphone aussi bon soit-il a toujours était considéré comme quelque chose à la marge pas vraiment un produit fini, mais plutôt un couteau suisse pour geek. La pile logicielle est peu optimisée pour ce genre d'usage et ça se voit.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Téléphone
Posté par philou . Évalué à 0.
Ah ben oui, bonne solution. C'est pas grave qu'un téléphone soit lent pour remplir sa fonction première puisqu'il y en a d'autres qui ne le sont pas. On pourrait du coup avoir deux téléphones d'ailleurs.
Blague à part, je ne vois pas pourquoi cet argument serait recevable : on devrait pouvoir utiliser un téléphone moderne et envoyer un SMS sans avoir à poser un congé. Ce n'est pas parce qu'on a pu faire ça un jour qu'il est interdit d'envisager de pouvoir le refaire. Bref, ce b-a-ba devrait être conservé avec les nouvelles générations de téléphones « intelligents ».
Je suis un peu dans la même situation que l'auteur. J'ai un HTC qui tourne (lentement) sous Android et même si je n'envisage plus un retour au bon vieux Nokia 3310 – c'est pratique d'avoir Internet sur son mobile – bah j'ai du mal à accepter qu'il soit tellement long d'envoyer un SMS ou de passer un appel. Pour ma part, je suis prêt à accepter l'absence d'icônes, des menus simples et sans transitions, pas d'effets glossy groovy crazy stupéflip… mais un peu plus de réactivité !
Faudrait déjà que ça marche vite et bien avant de songer à mettre autant de poudre aux yeux. Et après, s'il faut vraiment en mettre, il serait sympa de le faire d'une façon raisonnée par rapport à ce que permettent les terminaux mobiles actuels (et passés, dans une certaine mesure).
[^] # Re: Téléphone
Posté par barmic . Évalué à 1.
Non j'explique 2 choses, d'une part que de mon point de vu vous devez être tombé sur de mauvais numéro, d'autre part que si vraiment tout les « smartphones » sont si horribles à utiliser il existe des alternatives (ce n'est pas parce que le marketing le cache que ça n'existe pas).
Je passe un coup de fil en quelques secondes avec mon téléphone et j'envoie un sms en moins d'une minutes. Non seulement l'interface réagis bien mais en plus les interfaces et l'organisation me permet d'être bien plus rapide qu'avant (notamment grâce à l'organisation des contacts et le clavier prédictif plus évolué que le mode T9).
Je me demande si vous n'avez pas installé un logiciel qui tourne en tâche de fond et qui consomme vos ressources parce que mis à part sur le (très) bas de gamme. C'est quelque chose que je n'ai pas constaté et j'ai jamais vu de retour dans ce sens.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Téléphone
Posté par philou . Évalué à 0.
Non non, je surveille les applis qui tournent sur la machine et n'utilise que le strict nécessaire :
Par contre, je possède un HTC Wildfire, et c'était pas un rapide, même à sa sortie ;) Donc ça peut venir de là. Cependant, si j'en crois les expériences de mon entourage, on a souvent ce problème de lenteur quand même, quelque soit le modèle ou l'OS (Wave II, Xperia, etc.)
Je vais quand même expliquer ce que j'entends par « lenteur » :
Donc si on compte, j'ai mélangé ici 3 problèmes différents que je ne rencontre pas forcément simultanément, évidemment, mais que je rencontre souvent quand même (une fois sur deux, il se produit un truc comme ça et je n'ai parlé que des SMS).
D'où mon opinion sur le besoin de concilier lourdeur applicative et possibilités matérielles ou encore de développer bien d'abord puis beau ensuite.
# Bah, utiliser des contournements
Posté par reno . Évalué à 4.
Certes moi aussi je regrette BeOS, mais plutôt que d'attendre qu'Haiku ait un support matériel décent j'ai acheté un SSD!
Pour les téléphones,
1) si tu n'utilise pas les nouveautés, les téléphones à l'ancienne ça existe toujours!
2) si tu utilise les nouveautés, alors 1) c'est que tu admets que le "progrès" c'est utile 2) Jelly Bean a été fait spécifiquement pour améliorer la fluidité sur Android, ça peut peut-être te convenir.
# Méthodes de développement
Posté par Anonyme . Évalué à 9.
Il est sans doute probable que l'absence d'amélioration des performances soit sans doute aussi dû aux façons dont l'on développe aujourd'hui les applications par rapport à cette époque là.
On utilise plus volontiers des langage de très haut niveau, tout est développé en objet, sans parler des langages de scripts qui sont de plus en plus utilisés également, tout ça fait que les applications sont foncièrement plus lente car tout cela combiné multiplie le nombre de cycle processeurs pour faire des choses simples.
Du coup, il faut effectivement des millions d'octets de mémoires pour faire fonctionner un téléphone qui aura besoin de son environnement java, il faudra des milliards de cycles processeurs pour booter un os et tout ses services.
[^] # Re: Méthodes de développement
Posté par arnaudus . Évalué à 10.
Il faut donner l'autre côté de la pièce : du coup, on dispose de milliers d'applications (certes, pour la plupart inutiles), puisque le temps de développement est considérablement réduit du fait de l'utilisation de langages de haut niveau.
[^] # Re: Méthodes de développement
Posté par fravashyo . Évalué à 3.
avant c'était programmé en assembleur (cf. le code source du jeu Alpha Waves sur atari et un intéressant commentaire de l'auteur sur cette époque), alors pour le coup c'était sans doute bien optimisé, mais au final pas très portable.
Ensuite, même si l'auteur du journal pouvait coder et voir un film en même temps sur son ordinausaure faisant tourner BeOS, de nos jours on peut quand même bien plus.
Parfois ça peut donner l'impression de lagger, mais c'est aussi souvent parce qu'on en demande trop. Combien ai-je de fenêtre ouvertes sur mon bureau en ce moment ? (16, merci compiz, sans compter mes 500 onglets firefox)
J'ai encore pas mal de mémoire et de puissance processeur de libre, et c'est sans compter la puissance de calcul nécessaire pour regarder une video dans youtube ou dailymotion (même, voire surtout, en html5), pour calculer du javascript, pour dessiner des fenêtres plus complexes qu'à l'époque quand même.
De plus, à l'époque du 8bits, de BeOS et compagnie, le logiciel propriétaire était de mise, et on avait beaucoup moins de bons outils libres que maintenant. On peut également faire assez facilement de petits programmes dans des langages de haut niveau.
Il est également possible de garder une certaine simplicité en évitant les *office, par exemple la plupart de mes documents sont dans un format textuel, que je peux modifier avec n'importe éditeur de texte, même avec Pe depuis Haiku :)
On peut également concevoir des diagrammes en ascii avec Ditaa ou en langage de description avec Graphviz, de la 3D avec povray etc
Finalement, je ne suis pas convaincu qu'on ait perdu au change !
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Méthodes de développement
Posté par Slauncha (site web personnel) . Évalué à 6.
Je lisais un article sur l'évolution des méthodes de développement d'y a quelques années à aujourd'hui (honte sur moi, j'ai complétement oublié de bookmarquer cette page, l'article était fort intéressant), l'analyse était faite par un vieux de la vieille, développeur C++ je crois.
En substance, il décrivait son sentiment sur les nouveaux développeurs, pour lui, il disait que les nouveaux développeurs faisait plus de l'assemblage de briques logicielles, de gérer des problèmes d’interactions entre diverses couches d'abstraction que du "réel" (ce qu'il avait toujours fais jusqu'à présent) développement comme lui l'entendait.
Ya qu'a voir sur des projets JEE par exemple, on peux facilement quantifier le temps que l'on perds sur des problématiques de ce types (JBOSS, Tomcat, Hibernate, SPRING, …), des demis journées entières, pour ne pas dire des journées. C'est lourd au développement, c'est lourd à l'utilisation …
Fut un temps, un développeur faisait du développement, point barre. Aujourd'hui il doit être admin JBOSS, Tomcat, etc…
Sans parler de ce que fait les différents frameworks tout seul.
Quand je vois sous Java les fuites de mémoire ou toutes problématiques de goulot d’étranglement de perfs, … j'en reviens à regretter la gestion à la mano de pointeurs. A croire que le développeur n'ayant plus cette problématique à gérer fait comme si cette problématique n'existait plus.
[^] # Re: Méthodes de développement
Posté par Slauncha (site web personnel) . Évalué à 2.
Mon neurone de blond à retrouver l'article en question, mais a fait quelques transfert au passage, "développeur C++" :
http://www.developpez.com/actu/41930/-Quelque-chose-ne-va-vraiment-pas-avec-les-developpeurs-modernes-un-developpeur-a-l-ancienne-critique-la-multiplication-des-bibliotheques/
et plus précisément : http://williamedwardscoder.tumblr.com/post/18065079081/cogs-bad
De rien.
[^] # Re: Méthodes de développement
Posté par freem . Évalué à 1.
Le point en gras n'a, à mon très humble avis, rien à voir avec le fait que les gens codent comme des porcs.
J'ai, personnellement, une anecdote, un souvenir de BTS relativement frais (même pas 10 ans).
Dans ce souvenir, le prof disait qu'on se fout d'utiliser un int (par défaut, ça veut dire un signed long, si je ne m'abuse) pour stocker à nombre de 0 à 10 plutôt qu'un unsigned char…
La conséquence, très simple, c'est qu'une appli consomme 4 fois plus de mémoire en 32 bits (long => DWORD => 4 octets) et peut-être (trou de mémoire, l'asm auto-didacte remonte à loin) des instructions plus complexes pour la manipuler parce que c'est un signé.
A partir de là, pourquoi ne pas prendre un double (nombre réel le plus précis) pendant qu'on y est!!!
Mon chef actuel m'a aussi raconté que les gens ne font plus attention à ce qu'ils utilisent comme type dans les tables de bases de données.
Plutôt que de taper sur un paradigme, une façon de penser propre (qui est tout aussi propre que les autres, d'ailleurs, juste plus à la mode) il serait peut-être temps de remettre en cause les dev eux-même, ceux avec les diplômes d'ingé…
En revanche, oui, java, C#, obj truc… et les frameworks de dev C++, je pense qu'on en fait une surconsommation. Cela dis, quand le temps de dev est divisé par 10, on peut aussi le comprendre. Nombreux sont ceux qui ne dev pas, ou ne dev plus, par plaisir, j'ai l'impression.
Signé: un dev de 26 piges, qui a appris tout seul et à tellement fait le con au bts qu'il l'a pas eu et n'est donc pas une référence :D
[^] # Re: Méthodes de développement
Posté par Anthony Jaguenaud . Évalué à 3.
Il a raison, l’ int est sensé avoir la taille d’un registre de ton processeur (historiquement l’accumulateur), donc c’est l’entier le plus rapide à utiliser. Pour tout ce qui est variable locale, compteur de boucle… c’est le bon choix. Après, si tu veux mon avis, on ne devrait jamais utiliser un int pour autre chose. Surtout pas pour stocker des données, car il est possible que sa taille change en changeant d’architecture matérielle. Dès qu’on veut connaitre la plage d’un entier, il faut utiliser short, long… voir u8, u16, u32, u64…
Quand à la taille, dans le cas d’utilisation décrit, il s’agit de la pile, et probablement que dans le registre si le compilateur optimise correctement.
[^] # Re: Méthodes de développement
Posté par claudex . Évalué à 3.
Sauf qu'un int, c'est 16 bits minimum. Donc tant que si la donnée reste sur des nombres petits, ce n'est pas gênant (mais il faut être sûr de son coup).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Méthodes de développement
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tous les compilo transforment des short et des char en int quand ils sont manipulé directement (pas dans un tableau par exemple). C'est évident si on joue avec des shift. (chat c = 0XFF; char c2 = c << 8; printf("%i", c2>>8);)
"La première sécurité est la liberté"
[^] # Re: Méthodes de développement
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le gain ne font jamais sur ce genre de détail. Ils se font sur les tailles gigantesques des piles d'appel virtuel que l'on peut voir en java. Sur l'inlining de code et notamment des getter/setter qui sont une catastrophe de performance en java. Sur le passage par valeur de structure (!), d'allocation/désalocation mémoire dans une boucle interne. Et je ne parle pas de l'usage de container sous optimal en C, car il n 'existe pas de structure de donné dynamique native.
Ils peuvent aussi se faire, sur l'absence de maitrise des interactions réseau qui sont planqués derrière une api (qui se soucis de minimiser les "round-trip"). Le code est rapide sur la machine de dev, mais devient très lent une fois déployé sur un serveur et un client, avec des données de tailles conséquentes (j'ai beaucoup aimer une application web qui générait à chaque appel, des chiffres sous formes d'image png).
(tsss la modif ne fonctionne pas avec un verrou mais avec un timeout !!!!)
"La première sécurité est la liberté"
[^] # Re: Méthodes de développement
Posté par claudex . Évalué à 3.
Les deux mon capitaine.
("Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind.")
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Méthodes de développement
Posté par ahuillet (site web personnel) . Évalué à 1.
Ta remarque est fausse, ça a été précisé avant moi. Effectivement tu économises un peu de mémoire (encore que vu la granularité des allocations sur la pile - une page - je suis pas sûr que ca soit visible en pratique pour les variables locales), par contre tu payes très cher en performance en x86[-64] et sur d'autres architectures.
int, c'est la taille du registre, c'est ce qui est garanti comme étant le plus rapide. La bonne pratique c'est de s'en servir tout le temps sauf raison exceptionnelle.
Quant aux instructions plus complexes ce n'est pas très vrai. La division va coûter plus cher, à part ça…
[^] # Re: Méthodes de développement
Posté par 2PetitsVerres . Évalué à 2.
Ça dépend. Ton compilateur peut très bien décider de mettre son char sur 4 octets, parce qu'il pensera que ce sera plus rapide (et de ce que tu lui demandes). Du coup il ne perdra pas de temps. Et il ne gagnera pas de place en mémoire non plus. Par contre, sur d'autres architectures (je ne connais pas bien x86, à ce niveau) il y a des instructions de load non alignées, qui prennent le même temps qu'un load aligné, si je ne me trompe pas. Du coup tu peux gagner de la place sans perdre en performance. Mais c'est plutôt à réserver aux applications où tu en as vraiment besoin, ou éventuellement aux tableaux. Tu ne gagnes globalement rien si tu passes 42 int en char dans tout ton programme. (dans un précédent projet, on avait une table de calibration composée de 2*4*27*27 char si je me rappelle bien. Et 4Mo de RAM, 2Mo de ROM. La différence entre char et int (de 4 octets) c'est 17 ko, presque 1% de la ROM, 0.5% de la RAM.
Pour un exemple de load non aligné, il y a par exemple
sur sparc.
Faut faire quand même faire attention, ça peut avoir des effets ailleurs (enfin, ça a été révélateur d'un bug). On réutilisait un code de correction d'erreur (c'était un système embarqué fort exposé aux rayonnements, donc beaucoup de bit flip) qui faisait simplement, à la réception de l'interruption "erreur détectée" un load et un store de l'adresse qui avait généré l'erreur (il y avait un système d'EDAC dans l'électronique qui nous corrigeait la valeur quand on loadait, et donc on restaurait la bonne valeur lors du store) Et ce code, qui était une réutilisation de code qui marchait, nous a provoqué une belle erreur sur un load non aligné…
(la correction c'est de modifier l'adresse pour l'aligner sur un multiple de 4 dans la gestion de l'interruption, mais c'était du code qui existait depuis longtemps, et jusque là ça ne s'était jamais produit… enfin c'était un bug intéressant à comprendre, c'est juste dommage que ça se produise quand le machin était déjà lancé)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Méthodes de développement
Posté par ahuillet (site web personnel) . Évalué à 1. Dernière modification le 20 novembre 2012 à 14:51.
C'est une connerie. Si tu as besoin d'exploiter ces détails architecturaux, tu écris de l'assembleur, pas du C. Utiliser char pour "économiser de la place" c'est un non sens en C.
uint8_t, par contre, c'est un autre débat.
[^] # Re: Méthodes de développement
Posté par 2PetitsVerres . Évalué à 3. Dernière modification le 20 novembre 2012 à 15:14.
Oui, ok, c'est ce que je voulais dire. Désolé je ne pensais pas spécifiquement à "char" dans mon commentaire, mais à déclarer ses entiers de la taille dont on a besoin.
Mais c'est quand même au compilateur de passer d'un tableau d'entier de cette taille à l'utilisation de l'instruction appropriée.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Méthodes de développement
Posté par Anthony Jaguenaud . Évalué à 3.
D’autant que
charn’a pas de signe… la norme ne définie pas s’il doit être signé ou non. Du coup, ce n’est pas la même chose entreccsous solaris etgccsous GNU/… et un :Peut-être une boucle infinie ou pas. En plus, pour ne pas faire de conversion de type implicite, il faudrait écrire :
[^] # Re: Méthodes de développement
Posté par fearan . Évalué à 3.
moi j'ai un énorme problème avec des objets qui ne sont pas cohérent et ou tu te retrouves a devoir faire du check de valeur nulle ou tableau de taille 0 à tout va.
J'ai un peu l'impression que les gens ont oublié qu'un objet on ne le construit pas à moitié; c'est sensé être un tout cohérent. Ça alourdi le développement, et l'exécution alors que si les objets étaient cohérent…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# moi aussi
Posté par nomorsad . Évalué à 10.
Comme toi, je me souviens nettement que mon premier PC (un Pentium 75 16mo) me suffisait largement. Il bootait rapidement, je pouvais faire tout ce que j'avais besoin, etc….
Mais méfions nous de nos souvenirs! Un jour je l'ai rallumé et ma nostalgie en a pris un coup! Mais comment c'était humainement possible de bosser la dessus? Mais que c'est leeeeeent
Mortalité, le cerveau et ses souvenirs ne sont pas nos amis.
[^] # Re: moi aussi
Posté par arnaudus . Évalué à 10.
Expérience exactement identique. J'ai rebooté il y a quelques mois un portable qui fonctionne très bien mais qui a 15 ans, et je suis resté scotché par la lenteur du boot, le temps de chargement du bureau, etc. Krrr krrr krrr ça swappe à mort, krrr krr krrr malgré un superbe 640 x 480 (bon, peut-être un peu plus, je ne me rappelle plus). On lance firefox des années 2000, Krrr krrrr krrr krrr krrrr krrr… OUvrir un document avec OpenOffice, krrr krrr krrr krrr krrr krr krrr krrr… mince, je me rappelle, il vaut mieux fermer Firefox, krrr krrr krrr krr… En tout cas, les logiciels libres évoluent aussi parfois dans la bonne direction, parce qu'on a bien oublié le boulot d'optimisation qui a été réalisé à partir de bloatwares proprios (netscape, StarOffice…). Ça prouve la diversité et l'efficacité du développement libre, qui va dans plusieurs directions à la fois.
[^] # Re: moi aussi
Posté par karteum59 . Évalué à 3.
Ah ? Moi j'ai relancé mon vieil Amiga 1200, avec un disque dur probablement plus lent que ledit portable… et ça ne rame pas un poil (démarre même plus rapidement que mon laptop+SSD actuel). Bon évidemment, on ne peut pas comparer des choux et des carottes et il ne faut pas lui demander de fonctionner en 1080p et d'interprêter des trucs modernes, mais cette machine continue de m'impressionner quand on pense aux limitations du hardware !
[^] # Re: moi aussi
Posté par arnaudus . Évalué à 7.
Je pense qu'on ne parle pas de la même chose… Une console de jeux des années 1990 démarre également super vite et fait tourner des trucs parfois à peu près équivalents à ce qu'on trouve en «jeux flash» aujourd'hui, qui nécessitent 100 fois plus de puissance. Je parlais d'une machine sous Linux, avec c'est clair une distrib un peu lourde (une des premières Ubuntu, de mémoire), et la tripotée de trucs modernes qui vont avec : bureau Gnome, navigateur avec plugin flash, outils de bureautique, Gimp, etc. Il faut évidemment comparer des choses qui ont un niveau de fonctionnalité équivalent. La tonalité du journal était qu'on régressait, et je voulais simplement illustrer le fait qu'on s'habituait aussi énormément à la rapidité des machines, et qu'on ne se rappelait pas à quel point les anciennes étaient lentes à fonctions équivalentes.
Il suffit d'ailleurs de prendre un logiciel qui a peu évolué (malheureusement) : Gimp. Aujourd'hui, il se lance super-rapidement ; il y a 10 ans, c'était une application majeure qui bouffait une grosse partie de la RAM et qui mettait une minute à se lancer (je me souviens du splash screen avec la liste des greffons et scripts qui se chargeaient). Là, je viens d'essayer, ça met 3 secondes à se lancer sur ma machine, on voit à peine le splash screen.
[^] # P'tet faire gaffe aux bloat-wares?
Posté par freem . Évalué à 0.
J'ai récemment récupéré une machine certifiée pour windows millenium. J'ai vu plus vieux, mais ça a fini par tomber en rade :D
Bref. 64Mo de ram à l'origine, un disque dur de 10Go et w2000 Nt promptement remplacé par debian testing, avec i3 en gestionnaire de fenêtre, uzbl dans le rôle du browser.
Ben, c'est plus rapide que windows 2000, c'est certain (celui-ci n'étant pas capable d'accéder au net avec son IE4 :P). Et pas de souci d'installation non plus…
Depuis, j'ai chipé dans un coin une barrette de 128 qui manque sûrement pas à son propriétaire (vue la quantité et la couche de poussière qui l'environnaient…) et remplacé le disque par un 80. C'est mieux malgré tout…
Par contre, le boot est long, on à même le temps de voir le tableau qui récapitule le matos, après le POST du BIOS :D
En fait, je crois que le temps que cette machine arrive sur grub, une de mes quotidienne arrive à démarrer presque entièrement. Et j'ai pas de ssd…
Maintenant, c'est sûr: si tu colles du gnome3 avec bloatuntu, y'a pas de risque de pas swapper.
A vieille machine, logiciels minimaux ou alors tu te prends une swap en pleine poire, pire qu'une baffe :P
# appli d'aujourd'hui,oui mais laquelle?
Posté par Gabin II . Évalué à 0.
Tu parles d'un middleware en J2EE?
Y a t-il d'autres applications touchés? À part les rescapés d'anciens soft proprio (cf: Firefox, Libreoffice, etc… )
Tiens-tu comptes des évolutions "systèmes"? ça fait parti du progrès de l'informatique aussi et on ne peut pas dire que ça va si mal.
# progres...heu....
Posté par kuroineko . Évalué à 1.
les machines 8 bits étaient fiables et rapide parce qu'il n'y avait pas le choix, il fallait un code hyper-optimisé pour réussir à faire quelque chose. (peut importe la machine).
Maintenant c'est exactement le contraire, les machines sont puissantes alors seuls des langages de très haut niveau d'abstraction, sont utilisés, résultat, la machine est sous-exploitée, et les applications rament voir plantent.
certes les couts 'immédiats' ont baissé grace à l'évolution matérielle mais la vérité c'est surtout que l'évolution matérielle n'est là que pour compenser incompétence des développeurs. Et encore parler incompétence est un abus de langage dans la mesure où ils codent comme on leur à appris sur les langages qu'ils ont appris.
Bref on fait baisser les couts pour que les clients finaux aient l'illusion que c'est de moins en moins cher, mais au prix d'un renouvellement OBLIGATOIRE ET PAS NEGOCIABLE de leurs softs et idem dans une moindre mesure de leurs matériels. Résultat parce que le renouvellement est rapide, ça cache les problème d'évolution, et tout le monde s'est mis à confondre évolution & progrès.
certes ça évolue, mais il y a aucun progrès, même pire, parfois qu'il y a quelques années.
L'exemple type est une application gourmande sur une opération normalement longue, on voit bien que pour gagner quelque peu de confort d'utilisation, il faut renouveler sa version, impliquant des lourdeurs telles qu'il faut changer le matériel et tout ça pour découvrir au bout de quelques temps que la version précédente était bien meilleure que la nouvelle, (ergonomie, fonctions qui disparaissent…etc….)
Je reste volontairement hyper-vague et général… et ne parle pas de l'obsolescence programmée des materiels
# Complexité
Posté par 2PetitsVerres . Évalué à 5.
Il faut remarquer que la taille des "problèmes" à résoudre augmente aussi. La "puissance" de calcul brute augmente vite (supposons qu'elle est proportionnel au nombre de transistors, qui d'après la loi de Moore double tous les deux ans), mais les choses qu'on demandent augmentent aussi. Bon évidemment, c'est assez dépendant de l'application, mais beaucoup de problèmes ne peuvent pas voire augmenter leur taille aussi vite que la puissance de calcul.
Si un problème est de complexité O(n), on peut le doubler quand la puissance de calcul double. S'il est de complexité O(n2), on ne peut doubler la taille pour un même temps de calcul que lorsqu'on quadruple la puissance de calcul.
Alors évidement, la plupart des applications de tous les jours ne font pas de calcul intensif, mais par exemple le nombre de pixel qu'un programme doit afficher a tendance à quadrupler quand la taille (en nombre de pixels dans une direction) double. C'est pas nécessairement intensifs en calculs (ça dépend de ce qu'on veut afficher, et puis si c'est "complexe" et "3D" ce sera fait en partie par le GPU), mais on trouve ce genre de trucs un peu partout.
Après à la limite ça va dans ton sens, sur la partie "les applications aujourd'hui sont des trucs imbriqués dans tous les sens" (si j'ose résumé comme ça) parce qu'on gagne plus en vitesse si on utilise le meilleur algo connu en O(np) et pas celui plus simple en O(nq) avec q > p. (Enfin ça dépend de n et de la constante cachée dans le O.) Donc un développeur qui connait (ou se renseigne) son domaine et qui utilise le bon algo dans un truc à l'archi compliqué pourra (peut-être) faire un programme plus rapide qu'un développeur qui fera une archi plus simple mais avec un moins bon algo. Le mieux étant probablement l'archi simple avec le bon algo, mais ça demande du temps (et de l'investissement.)
C'est plus simple de passer de 4 Go de ram à 24Go pour pouvoir dire "ouais, il y a peut-être une fuite mémoire, mais bon, avec 24Go de ram vous aurez de la marge, faudra surement redémarrer l'appli pour une maj avant que la fuite n'ait tout pris." (à peu près l'idée d'un truc qui a été fait ici… /o\)(je suis l'utilisateur pas le dev, mais en même temps je suis nul en IHM donc je ne critique pas trop)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Loi de Sygne
Posté par Sygne (site web personnel) . Évalué à 10.
C'est une loi informatique qui repose sur une vérité statistique: les plus veilles applications ont prouvé durer plus longtemps que les plus récentes.
C'est aussi une loi informatique qui repose sur un constat: les applications modernes évoluent beaucoup, utilisent des bibliothèques à évolution rapide, et utilisent de nombreuses bibliothèques, ce qui fait que le tout est «méta-stable». Autrement dit, si l'application ne suit pas le rythme général, elle est condamnée à court terme.
Le nouveau est d'avance obsolète, alors que l'ancien sera de plus en plus pérenne.
Bon vendredi :)
[^] # Re: Loi de Sygne
Posté par freem . Évalué à 1.
Pas entièrement faux, sauf que je dirais plus que le problème viens de tout baser sur un framework, pas de la multiplication des dépendances.
Exemple: j'utilise wxWidgets pour un truc. 5 ans plus tard, nouvelle version majeure est arrivée.
Version majeure, cassage de l'api, normal. Donc, soit j'évolue et maintiens mon appli, ce qui peut ne pas coûter trop cher si je l'ai fait au fur et a mesure, soit je reste avec l'ancienne version. Vu que je me suis basé sur une lib open source, je peux même la maintenir moi-même.
Mais dans le 1er cas, il m'aura fallu maintenir l'application entière, parce que j'ai utilisé une usine à gaz qui fait même le café.
A contrario, si je fait la même chose, mais en utilisant des lib spécialisées pour les tâche, en divisant l'application en modules qui ont chacun leurs propres dépendances, je me retrouve avec une appli plus dure à construire, mais dont la maintenance sera plus aisée, car les maj majeures des libs n'affecteront qu'un seul module, et n'iront pas toucher le coeur de l'application (qui a été créé parce qu'il n'existait pas, sinon on aurait pas réinventé la roue, pas vrai?).
Par contre, les vieilles applis vivent plus vieilles, parce que la force de l'habitude est dure à détruire. Ca vaut pour le matos, il suffit de regarder le layout clavier universel ;)
PS: Ca marche aussi avec Qt, MFC, …
PPS: je me rattrape de dredi :P
# ....ou pas
Posté par chamandier . Évalué à 5.
Moi ces tics de langage, ça m'énerve.
Comme terminer chaque phrase par un "ou pas".
Comme s'il fallait toujours préciser l'alternative à son locuteur :
ça va ou pas ?
[^] # Re: ....ou pas
Posté par Frank-N-Furter . Évalué à 2.
T'as pas tort, ou pas.
Depending on the time of day, the French go either way.
[^] # Re: ....ou pas
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
Cela pourrait être pire: ça va ou bien ? (que le francophones d'origine d'outre Léman me pardonnent ;-))
[^] # Re: ....ou pas
Posté par zebra3 . Évalué à 6.
Encore pire : ouech, bien ou bien ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ....ou pas
Posté par navaati . Évalué à 3.
tavu
[^] # Re: ....ou pas
Posté par zebra3 . Évalué à 4. Dernière modification le 19 novembre 2012 à 22:02.
Bof, le « ça va ou pas ? » je le comprends comme une vraie question, où le choix est ouvert.
Tandis que quand on demande « ça va ? », c'est une question rhétorique à laquelle on n'attend pas vraiment la réponse négative où la personne commence à t'expliquer ses problèmes…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# problème de développeur plutôt que de code
Posté par RD . Évalué à -4.
Le développeur n'est plus (ou moins) seul face à son code.
Sans trop évoquer d'aspect sociologique (l'esprit techno-scientiste béat qui n'en fini pas de se répandre dans la plupart des couches de la société), les structures du développement logiciel ont changé, à commencer par la professionnalisation.
La professionnalisation induit évidemment une manière erronée d'envisager les priorités tel que l'illustre magnifiquement le terme part de marché.
Mais les machines qu'utilisent les développeurs des principaux logiciels (qui ont subi le plus intensément la professionnalisation) sont différentes:
Là où auparavant les contributeurs bénévoles et autres geeks passionnés utilisaient une machine de "base (milieu de gamme; mais bien supportée) et testaient (et compilaient) leur code sur leur propre machine, les nouveaux développeurs disposent des machines de leurs
entreprisesfondations dopées aux Go de RAM, associées à des fermes de compilation dans un cadre d'_intégration continue_. Ils n'ont que peu de rapports avec la compilation du projet, et moins encore avec son utilisation sur les machines d'il y a 5 ans.À titre d'exemple et d'hypothèse (qui ne sera malheureusement pas démentie à l'avenir), imaginez ce qui arrive au matériel moins concurrentiel, dont les firmes ont moins de développeurs, vis à vis du support par le noyau ? Certes l'exemple est ambigu car il s'agit bien évidemment aussi d'une question de politique conciliante (ou non) vis à vis d'un noyau libre dès la conception du produit.
Mais on peu néanmoins sans peine imaginer qu'un produit IBM pour lequel le fabricant alloue un budget pour le support GNU/Linux trouvera un bien meilleur et rapide support dans le kernel qu'un autre, quand bien même le matériel serait moins répandu chez des particuliers.
Certes le Yeelong est contre-exemple valable. Mais ce qui me semble essentiel c'est que les efforts bénévoles tendant à diminuer avec la professionnalisation (à minima "en proportion"), c'est vers le matériel le plus profitable que vont s'orienter inexorablement les efforts de développement.
Ma CG (GeForce FX 5200, 2003) continue de planter assez régulièrement mais je parie que ce n'est pas le cas des derniers modèles Nvidia sortis. Car c'est pour ces derniers les développeurs talentueux qui travaillent à nouveau (exemple pris un peu arbitrairement et peut-être même assez injustement en l’occurrence) sont incités d'orienter leurs efforts.
Les développeurs professionnels représentant une portion aisée de la population et assez souvent décomplexée vis-à-vis de la société de consommation (non pas de généralisation hâtive). Les heures de développement se font avec (et lorsqu'elles touchent au matériel, se font pour) du matériel récent et régulièrement "mis-à-jour".
Et lorsqu'on ne connait personne ayant dans son cercle occidental ayant moins d'1Go de RAM, cela n'incite pas à s'infliger des contraintes de simplicité. Surtout si "l'ergonomie" (encore un terme souvent travesti) à le moindre risque d'en pâtir.
Ainsi que c'est avec le ventre vide que le poète chante le mieux. , le jour où les développeurs des logiciels "de base" s'auto-limiteraient dans les performances de leurs machines personnelles on pourrait voir émerger du code performant (plus indépendamment de l'industrie du hardware) apparaître.
L'industrie des jeux vidéos, que je méconnaît, a dû réfléchir à cette problématique il y a bien longtemps déjà. Des conséquences en ont-elles été tirées ?
my 2c
[^] # Re: problème de développeur plutôt que de code
Posté par Milridor (site web personnel) . Évalué à 5.
Ok, on a déjà le ton…
Mais bien sûr! Plus aucun dev n'a de machine perso!
Les fermes de compilation et l’intégration permettent justement de repérer rapidement les régressions. Mais bon pour ça il faut écrire des tests.
Bah en même temps, ils travaillent sur le matos qu'ils ont, tu es allé sur leur FAQ?
[^] # Re: problème de développeur plutôt que de code
Posté par ckyl . Évalué à 3.
Ca c'est une pépite de caca !
Et les gentils super dev amateurs bisounours qui faisait le bien du monde ils sont morts ?
Si tu fais des stats je te pari qu'en moyenne les machines en environnement pro sont en deçà des machines perso. Simplement par ce que les machines pro ne sont jamais upgradées entre l'achat et la mort. Ces 4Go de RAM supplémentaires qui seraient amorti en une semaine vu ton coût horaire statistiquement tu ne les verra jamais. Le dev amateur ca fait longtemps qu'il a été les acheter. Tu oublis aussi comment les machines pro sont bridée en moyenne (bonjour à toi qui bosse dans un VM ou avec 7 antivirus et logiciels maisons qui font tomber de 50% les perfs de ta machine)
Oui par ce que c'est bien connu on ne compile et ne fait pas tourner les tests en local avant. On pousse notre caca au petit bonheur la chance. Mais je comprend ton aversion pour cette stupidité qui est de rechercher la qualité, l'automatisation et le reproductibilité.
Comme partout. Si tu paies pas quelqu'un pour faire le boulot bin soit t'attends que quelqu'un d'autre le fasse (mais qui va payer pour supporter ton matos ?), soit t'attend que le dev-amateur-bisounours que tu aimes tant fasse le boulot, soit ça sera pas fait. Ca me semble une vérité générale non ?
Si tu ne trouves pas de dev-amateur-bisounours alors paie un connard de professionnel pour ce que tu veux. Ramener à la masse d'utilisateur ça ne coûte pas très cher…
Incité par qui ?
Après quand tu développes un projet long sur du hardware c'est logique de bosser sur des trucs récents. Si il te faut 3 ans pour atteindre un état stable et que tu bosses sur du matos qu'il y a 5 ans. Quand tu releases il a 8 ans et plus personne ne s'en sert. Le développement noyau à ceci de particulier que par définition tu bosses sur le matos de la génération suivante (celui qui va arriver). Autrement y'a pas de support quand c'est releasé et surtout si tu ne conçois pas pour les archis de dans 2/3/5 ans tu vas très vite être dépassé.
Just do it.
# Loi de Wirth !
Posté par Arthur Accroc . Évalué à 7.
Tu n’es pas le premier à constater le ralentissement des logiciels, c’est ce qu’on appelle la loi de Wirth : (je cite Wikipédia)
Elle s’expliquerait notamment par le fait que « la loi de Moore [est] une excuse à la production d’obésiciel ».
Cela dit, il ne faut pas désespérer, si certains logiciels suivent la loi de Wirth (Windows, MS Office, Gnome…), il y a des exceptions, notamment dans les logiciels libres (le noyau Linux, Xorg, Xfce…). Soit parce que leurs développeurs ne sacrifient pas les performances, soit simplement parce qu’ils se retiennent d’ajouter des fonctionnalités superflues à un projet abouti.
Au début des années 1990, un noyau de type Unix et l’interface X11 étaient très lourds pour les machines de l’époque, même les stations Unix très chères.
L’équivalent actuel sur les machines actuelles est quand même bien plus fluide (au moins tant qu’on ne le leste pas avec des obésiciels comme environnement ou applications)…
Après, il y a aussi des logiciels qui vont plutôt en s’améliorant côté performances, mais pas forcément de manière visible, parce qu’en parallèle, on leur en demande de plus en plus ; par exemple, les navigateurs.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.