Forum général.général Moyens techniques vs finalité d'un développement

Posté par  (site web personnel) .
Étiquettes : aucune
0
10
nov.
2006
Que pensez-vous de cette phrase ?

"En effet, dans l'exemple des communautés de développement de logiciels Open Source, on peut penser que l'intérêt pour la technique peut parfois prendre le pas sur l'objectif final du développement. L'expérimentation d'un nouvel outil suscite ainsi souvent un fort sentiment de curiosité et une envie d'expérimentation. "

Avez-vous des données objectives pour infirmer ou confirmer ce point de vue ?

  • # Quand j'ai vu ...

    Posté par  . Évalué à 2.

    ... la news du 61/10/2006 (http://linuxfr.org/2006/10/21/21509.html ), je me suis posé à peu près la même question à la lecture du titre....
    Je me suis dit, tiens, ils ont développé un truc, mais ils (les développeurs) ne savent même pas quoi en faire.
    De même avec cette news, encore en première page :
    http://linuxfr.org/2006/11/09/21587.html
    Il semblerait qu'une nouvelle technologie ait été développée, (si j'ai bien compris, c'est unbinding Java à la bibliothèque Qt
    et l'objet du concours organisé, c'est bien de chercher à quoi donc ça peut bien servir...
    Ceci-dit, je trouve quelque part que cette démarche peut s'avérer saine, car elle stimule les efforts de recherches. Le but de ce post est juste d'alimenter le troll, et en aucun cas de dénigrer le travail fait par ces différentes équipes.

  • # Ca dépend des fois...

    Posté par  (site web personnel) . Évalué à 8.

    Il est effectif que parfois l'intéret du développement prend le pas sur l'objectif. C'est notament le cas avec Emacs qui sait faire de nombreuses chose très importantes tel le café mais qui a de se fait perdu énormément en ergonomie pour ce qui est de l'édition de texte (sauf à avoir un clavier spécialement conçu pour ce logiciel, ce qui n'existe pas encore).
    A contrario, il est des fois ou l'objetif final est sublimér tel que ce fut le cas pour VI ou l'on dispose d'un outil extrèmement bien conçu, léger et ergonomique.
    D'ailleurs on entre dans des cercles vertueux ou vicieux à la suite de cela.
    En ce qui concerne VI, c'est le cercle vertueux du toujours mieux, toujours plus ergonomique, d'ailleurs on voit à peine ces modifications qui sont peut nombreuses car presque inutiles. Alors que pour Emacs, on y developpe de nouvelles chose juste pour prouver que c'est faisable genre
    "-J'suis sur qu'avec Emacs tu peux faire des frites
    -Non... Tiens, tu vois, google il dit que non"
    3 jours après...
    "-Voila, ca y est j'ai developper une interface pour ma friteuse pilotable par Emacs, tu vois qu'il peut faire des frites"
    Si ce n'est pas l'example parfait du cercle vicieux ca...

    • [^] # Re: Ca dépend des fois...

      Posté par  . Évalué à 8.

      Je ne vois pas vraiment en quoi il est vicieux de piloter une friteuse avec emacs. Interfaçage ordinateur/friteuse, spécifications de la friteuse, demande de libération des firmwares parce que les modules binaires fermés saimal, manifestation devant le siege d'un fabriquant d'electroménager pour demander un port de communication plus rapide que 9600 bps sur la friteuse etc ...

      Emacs qui prend le filet à patate, les lave, les épluche, les coupe et les fait frire, il est là le vice, car il serait capable de les manger !

    • [^] # Qui est le plus gros bousin ?

      Posté par  (site web personnel) . Évalué à 2.

      $ echo "qui est le plus gros bousin ?">haouais.txt
      $ emacs -nw haouais.txt
      $ vim haouais.txt
      $ grep ^Vm /proc/`pidof emacs`/status
      VmPeak: 11468 kB
      VmSize: 11468 kB
      VmLck: 0 kB
      VmHWM: 6124 kB
      VmRSS: 6124 kB
      VmData: 976 kB
      VmStk: 204 kB
      VmExe: 1340 kB
      VmLib: 4320 kB
      VmPTE: 20 kB
      $ grep ^Vm /proc/`pidof vim`/status
      VmPeak: 20640 kB
      VmSize: 20636 kB
      VmLck: 0 kB
      VmHWM: 6472 kB
      VmRSS: 6472 kB
      VmData: 1228 kB
      VmStk: 88 kB
      VmExe: 1564 kB
      VmLib: 15444 kB
      VmPTE: 28 kB

      Héhéhé... Vim c'est trop lourd. Et en plus il ne fait ni le café ni les frites !

      • [^] # Re: Qui est le plus gros bousin ?

        Posté par  . Évalué à 3.

        je voulais faire le même comparatif pour voir ce que ça donne sur ma bécane, mais j'y arrive pas. J'ai le message d'erreur suivant:
        -bash: emacs: command not found
        quelqu'un saurait d'ou ça peut venir ? ;-)

        bon, j'ai réussi à trouver une autre bécane, en faisant les même manips que toi, ça donne ça :
        $ grep ^Vm /proc/`pidof emacs`/status
        VmSize: 11944 kB
        VmLck: 0 kB
        VmRSS: 5672 kB
        VmData: 948 kB
        VmStk: 204 kB
        VmExe: 1324 kB
        VmLib: 6256 kB
        VmPTE: 36 kB
        $ grep ^Vm /proc/`pidof vim`/status
        VmSize: 8844 kB
        VmLck: 0 kB
        VmRSS: 3096 kB
        VmData: 1296 kB
        VmStk: 88 kB
        VmExe: 1804 kB
        VmLib: 5308 kB
        VmPTE: 32 kB

        quelle conclusion en tirer ?
        facile, le troll vim/emacs a encore de beaux jours devant lui :p

        • [^] # Re: Qui est le plus gros bousin ?

          Posté par  (site web personnel) . Évalué à 1.

          Difficile de comparer un truc qui se lance dans un terminal et un autre qui se lance avec une interface graphique. Si tu veux que ton test soit bon, soit tu lances les deux en mode graphique soit tu lances les deux en mode texte...

          Et oui curieusement et contre toute attente Emacs prend moins de place...

          • [^] # Re: Qui est le plus gros bousin ?

            Posté par  . Évalué à 1.

            bien tenté, mais sur ce coup là, pas de bol, les deux étaient bien lancés en mode texte (machine distante, pas de export DISPLAY, toussa). Le résultat de mon test a autant de valeur que le tien. Je voulais juste souligner le fait qu'un unique test sur un unique fichier sur ta machine à toi ne permet pas de tirer la conclusion définitive que tu en tires. La preuve, un test sur un unique fichier sur une autre machine donne des résultats différents.
            D'autres part, aucun de nous deux n'a précisé les versions de chaque appli qu'il utilise, ni les options avec lesquelles elles ont été compilées.

            Bref, tout ça pour dire que ça fait un peu juste pour affirmer tel éditeur est plus lourd que tel autre.

            En vrai, les performances comparées des deux éditeurs, je m'en fous un peu. J'utilise vim parce que j'aime le concept mode édition / mode commande et que j'ai plaisir à m'en servir (il se trouve que c'est mon outil de travail principal).

            Sinon, ton commentaire confirme la conclusion de mon commentaire précédent :-)

            • [^] # Re: Qui est le plus gros bousin ?

              Posté par  (site web personnel) . Évalué à 1.

              Exact :-), je ne voulais pas te piéger, mais j'avais pas capté qu'il s'agissait bien du mode texte.

              Pour tout te dire je m'en fous aussi et j'utilise bien souvent vim. De toute façon j'aurais benchmarké à mort avec les specs, les extensions chargées pour tel type ou tel type de fichier, je me serais clairement fait chier pour rien, parce que ça n'aurait pas été plus convaincant, grâce à la merveilleuse phrase « oui, mais les benchmarks ça veut rien dire m'voyez ».

              J'ai toutefois était à plusieurs surpris par la pas si grosse lourdeur d'Emacs que ça comparé à vim/gvim même qu'il pouvait être plus léger. Je tenais donc à en faire part pour souligner l'élégance de la friteuse :-).

  • # Ce que j'en pense

    Posté par  (site web personnel) . Évalué à 3.

    Que pensez-vous de cette phrase ?

    Qu'elle est mal rédigée L'expérimentation d'un nouvel outil suscite ainsi souvent [...] une envie d'expérimentation. :-)

    Plus sérieusement, c'est très variable en fonction des gens et des projets. Certains s'amusent à faire des trucs qui déchirent et les recommencent régulièrement sans essayer de sortir un truc complet et vraiment utilisable (genre e17), d'autre sortent des logiciels au code et au système de build pourris mais qui marchent et répondent au besoin des utilisateurs (je ne citerai pas d'exemple même s'il y en a plein).
    Sur un projet assez gros et bien géré, je pense qu'il y a une version principale et des gens qui jouent à coté dans leur branche et remontent de temps en temps des nouvelles features ou des améliorations du code.

  • # Back to technics

    Posté par  . Évalué à 4.

    C'est surtout révélateur d'un phénomène bizarre : la plupart des gens ne comprend pas l'intérêt que l'on peut trouver à développer des logiciels, ni même à réaliser des outils informatiques soignés. Alors même que faire de l'électronique de loisir ou du radio-amateurisme, voire même des mathématiques fondamentales (ou au moins appliquées sous la forme d'énigmes et de jeux de stratégie) est complètement intégré dans les moeurs, faire de l'informatique ne peut pas être une fin en soi ...

    Pour le reste, cette assertion est pour l'essentiel vraie, mais ce n'est pas une relation de cause à effet : l'ouverture et la liberté du code est souvent nécessaire pour qu'un logiciel "s'auto-optimise" par l'entremise de ses utilisateurs, et la volonté de développer et mettre en commun ses ressources a naturellement conduit à initier le mouvement libriste.

    Il n'y a pas vraiment d'objectif sous-tendu mais plutôt deux concepts qui vont naturellement de pair.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.