Interview de Matz le créateur de Ruby

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
2
avr.
2003
Ruby
Le créateur de Ruby, Matz, a été interviewé sur le Slashdot Japonais.
Son interview a été traduite en anglais. La discussion est très instructive et souvent amusante (les créateurs de langages de scripts semblent avoir un sens de l'humour assez développé).

PS : serait-il possible d'avoir une rubrique Ruby sur LinuxFr ? Extraits:
-"Above all, you can't enjoy programming with much stress. Ruby's true motto is "Enjoy programming"".

-"But "more favorite languages" for me are those which were influenced by Lisp family. Needless to say about the descendants of Lisp (CommonLisp?, Scheme, and LOGO), I also think that Smalltalk and ML are under the influence of them."

Aller plus loin

  • # Re: Interview de Matz le créateur de Ruby

    Posté par  . Évalué à 2.

    J'aime bien la façon de voir les choses de 'Matz', il a une vision réaliste sur son propre langage et ne le prend pas pour plus qu'il n'est contrairement à une certain langage en perte de vitesse car super lour et surestimé par sa communauté...
    • [^] # Re: Interview de Matz le créateur de Ruby

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

      Ce language dont tu parles est aussi souvent sous estimé par les gens qui ne le connaissent pas...

      http://about.me/straumat

      • [^] # Re: Interview de Matz le créateur de Ruby

        Posté par  . Évalué à 2.

        Attention, je n'ai pas dit qu'il était vraiment mauvais (le Perl), c'est un bon langage procédural, il permet de faire de bons petits scripts d'administration système par ex., mais je trouve qu'il a trouvé ses limites et qu'il a (trop) pris de poids au fil des années et je trouve que la communauté (même si c'est de l'humour) avec ses références bibliques... C'est limite, mais ce n'est que MON avis perso qui ne fait pas forcément l'unanimité... PS : Je le connais peu c'est vrai mais ça m'a suffit pour m'en faire une idée.
        • [^] # Re: Interview de Matz le créateur de Ruby

          Posté par  . Évalué à 10.

          Il a pris du poids, c'est indéniable. En attendant, c'est un langage de script très puissant et très rapide. Ruby est très puissant, très beau, mais (et je n'aime pas dire ça car j'apprécie beaucoup ce langage), il est bien trop lent, mais alors vraiment trop lent. Un exemple idiot et très peu représentatif (mais évocateur): bmc@home:~$ time perl -e 'print "test\n"' test real 0m0.004s user 0m0.002s sys 0m0.002s bmc@home:~$ time ruby -e 'print "test\n"' test real 0m0.013s user 0m0.010s sys 0m0.003s Bien sûr, cet exemple est ridicule. Mais ayant utilisé personnellement les deux langages de façon intensive, je n'ai pour l'instant pas trouvé d'application où Ruby est plus rapide (même si sur de rares cas il fait jeu égal) que Perl à ce niveau. Je le répète, j'apprécie beaucoup Ruby, et c'est ce que j'utilise pour tous les développements rapides de quelques lignes. Mais pour tout ce qui est un peu plus «sérieux» en terme de besoin de performances, il ne fait pas le poids face à Perl. Pour plus de précisions (et ça vaut ce que ça vaut): http://www.bagley.org/~doug/shootout/ Merci de ne pas me ressortir les comparaisons face au C ou à d'autres langages compilés: comparons ce qui est comparable.
          • [^] # Re: Interview de Matz le créateur de Ruby

            Posté par  (Mastodon) . Évalué à 6.

            La lenteur de ruby est-elle due à sa conception, ou au fait que l'interpréteur n'est pas aussi optimal que celui de perl ? Autrement dit, est-ce que c'est une question de temps ou est-ce qu'il sera toujours plus lent ? À priori j'aurais tendance à pense qu'il sera toujours plus lent puisque perl compile ses programmes avant de les exécuter, et que ruby ne le fait pas, et ne semble pas pouvoir le faire à cause de son côté "dynamique", mais je n'y connais pas grand chose.
            • [^] # Re: Interview de Matz le créateur de Ruby

              Posté par  . Évalué à 4.

              Je pense que c'est une question de temps, étant donné que l'optimisation n'était pas le but premier des concepteurs de Ruby (ce qui est compréhensible). Quant à la dynamicité, je ne sais pas trop... je pense que Perl est très «dynamique» lui aussi. Qu'entends-tu par «Perl compile ses programmes avant de les exécuter» ? Perl parse les programmes, et les interprète, mais je n'ai jamais entendu parler de compilation Perl (sauf dans mes rêves, et certaines histoires qui parlaient d'un compilateur qui n'a pas avancé en 4 ans).
              • [^] # Re: Interview de Matz le créateur de Ruby

                Posté par  . Évalué à 9.

                Je ne suis pas un expert en langage de prog loin s'en faut, mais est-ce que le Perl est interprété ligne par ligne où produit-il un bytecode comme Python et Java?? Désolé pour ceux qui trouveront ma question idiote :)
              • [^] # Re: Interview de Matz le créateur de Ruby

                Posté par  . Évalué à 9.

                Perl parse les programmes, et les interprète, mais je n'ai jamais entendu parler de compilation Perl Un script Perl va dans un premier temps être "traduit" en bytecode optimisé, lequel va être exécuté. Il y a une synthèse très claire du principe d'exécution des programmes en Perl dans le bouquin "Programmation Avancée en Perl" de chez O'Reilly (2841770397). Il est possible de visualiser l'arbre d'opcodes d'un script en utilisant l'option -Dx (à condition d'avoir un Perl compilé avec -DDEBUGGING).
              • [^] # Re: Interview de Matz le créateur de Ruby

                Posté par  . Évalué à 2.

                > (sauf dans mes rêves, et certaines histoires qui parlaient d'un compilateur
                > qui n'a pas avancé en 4 ans)

                Si ce qui t'intéresse c'est de transformer un script en binaire exécutable,
                il y a le magnifique module d'Autrijus Tang:

                http://search.cpan.org/author/AUTRIJUS/PAR-0.67/lib/PAR.pm(...)

                $ pp -o hello_world hello_world.pl
                $ ls -l hello_world
                -rwxr-xr-x 1 pasnous pasnous 1637131 avr 2 17:51 hello*
                $ ldd hello_world
                libnsl.so.1 => /lib/libnsl.so.1 (0x40033000)
                libdl.so.2 => /lib/libdl.so.2 (0x40049000)
                libm.so.6 => /lib/libm.so.6 (0x4004c000)
                libc.so.6 => /lib/libc.so.6 (0x4006f000)
                libcrypt.so.1 => /lib/libcrypt.so.1 (0x401ab000)
                libutil.so.1 => /lib/libutil.so.1 (0x401d8000)
                /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

                Bref, à essayer d'urgence ! 8)
            • [^] # Re: Interview de Matz le créateur de Ruby

              Posté par  . Évalué à 5.

              Elle est avant tout dû à sa jeunesse. D'abord Ruby est encore en évolution, le travail de Matz étant clairement du coté des pragmatiques et méthodes "agiles". D'autre part comme pour tout langage, il faut distinguer "langage" et "runtime" : aujourd'hui ruby a un interpreteur qui vaut ce qu'il vaut (l'introspection de Ruby, qui est fabuleuse, est un point à considerer quand on compare les vitesses...), mais il existe de nombreux projets donc le plus interessant me semble être une VM. Ruby est encore jeune, il passera probablement par les mêmes étapes que Java (stabilisation APIs puis optimisations de plus en plus poussées des VM).
          • [^] # Re: Interview de Matz le créateur de Ruby

            Posté par  . Évalué à 5.

            Sur mon vieux coucou PII350, j'ai pour Perl: real 0m0.273s user 0m0.020s sys 0m0.000s et Ruby: real 0m0.192s user 0m0.080s sys 0m0.010s mais ça veut pas dire gd chose tout ça, même si sur de plus gros scripts la différence peut se faire réellement sentir... Quelqu'un a-t-il déjà fait des projets importants en Ruby et peut dire (objectivement) s'il est lent comparé à Perl (et à Python éventuellement)??
            • [^] # Re: Interview de Matz le créateur de Ruby

              Posté par  . Évalué à 10.

              J'ai déjà dvl des projets assez importants en Ruby: -serveur TCP multithread (a noté que le support des threads en Perl n'est pas finalisé): aucun pb en termes de perfs (avec une dizaine de clients simultanées). -prog faisait des DoS/Bench en surchargent de requetes un serveur lancé via inetd (ou autre) (une cinquentaines de thread en simultanées): aucun pb coté de perfs (le serveur tombe bien avant le prog Ruby). -Attaque force brute sur login/password vers serveur http, telnet, ftp, ... (encore pleins de threads): aucun pb. -Nombreux scripts parsants des gros fichiers logs (500 Mo) avec stockages dans des list ou des hash: diff avec Perl négligeable (mais c vrai que Perl va plus vite (+ ou - 50%)). -Développement d'un perceptron multicouche pour faire de la reconnaissance de forme: inutilisable que ce soir Perl ou Ruby (mon prog Ruby tournait un we quand mon prog en C tournait en 30 minutes). Donc en général quand on utilise des langages de scripts c que le vitesse n'est pas un paramettre critique, les résultats de Perl et Ruby sont comparables dans ce genre de situations (prog système/réseaux)
            • [^] # Re: Interview de Matz le créateur de Ruby

              Posté par  . Évalué à 9.

              J'écris personnelement de gros programmes en Ruby et même des GUI avec ruby-Qt. La lenteur n'est sûrement pas ce qui me gêne en premier dans Ruby. Le plus gros problème vient du fait que son système de threads est "déconnecté" des system threads, ce qui occasionne pas mal de problèmes lorsqu'il s'agit d'intégrer Ruby à des applis déjà existantes. Mais le plus fabuleux dans Ruby, c'est quand même la possibilité de sérialiser N'IMPORTE QUEL objet ! C'est quand même trop fort et surtout très pratique quand tu dois faire des applis distribuées. Sans parler de ses capacités d'introspection, son modèle objet "pur", etc...
              • [^] # Re: Interview de Matz le créateur de Ruby

                Posté par  . Évalué à 1.

                Et avez-vous personnellement pu comparer un projet écrit en Python et un équivalent en Ruby car j'avoue que j'hésite entre les deux pour créer un service intranet... J'aimerai savoir en fait quel est le plus habilité pour de gros projets (la rapidité n'entrant pas trop en ligne de compte, je recherche celui qui sera le plus robuste, le plus complet... et le plus facile à apprendre, suis nul en info :))
                • [^] # Re: Interview de Matz le créateur de Ruby

                  Posté par  . Évalué à 2.

                  Je connais assez peu Python, donc j'éviterai de me prononcer. Il semble que Python soit mieux fourni du côté GUI, notamment avec wxPython. Maintenant, pour la maintenabilité, je n'ai pas vu grand'chose de meilleur que Ruby.
                  • [^] # Re: Interview de Matz le créateur de Ruby

                    Posté par  . Évalué à 2.

                    Là je suis d'accord sur la maintenabilité, même si je ne connais pas (encore) Ruby, pour en avoir parcouru un script, je l'ai trouvé très clair et compréhensible, contrairement à du Perl, où il y a des accolades partout des $, des %, des @, d'autant plus que (si on le veut vraiment...), on peut écrire du Perl très illisible, ce qui est plus difficile avec le Ruby et le Python car on est "obligé" d'écrire convenablement...
                    • [^] # Re: Interview de Matz le créateur de Ruby

                      Posté par  . Évalué à -1.

                      Je suis un adorateur de Python. J'ai testé Ruby (un article pour Login: de plusieurs pages écrit en novembre dernier, à paraître en septembre prochain seulement) et je préfère Python. MAIS, voici trois exemples de ce qu'on peut faire avec Python dans le genre illisible :
                      FILE_EXTENSIONS   = ['.bmp', '.pcx']            # list of file extensions to handle
                      STOP_BY_DIRECTORY = ['htrack', 'strack']        # handle directories of one of these names
                      
                      def fileTreeVisitor(arg, dirname, names):
                        if os.path.split(dirname)[1] in STOP_BY_DIRECTORY: filterFiles(dirname, names)
                      
                      def filterFiles(dirname, names):
                        fileNames = [name for name in names if os.path.splitext(name)[1] in FILE_EXTENSIONS]
                        if len(fileNames) == 0: return
                        fileNames.sort()
                      
                        map(os.mkdir, [os.path.join(dirname, "Angle" + str(i)) for i in range(1, 9) if not os.path.exists(os.path.join(dirname, "Angle" + str(i)))])
                      
                        for i in range(0, len(fileNames), len(fileNames) / 8):
                          files = filter(lambda name: int(re.search("(\d+)\.", name).group(1)) % 2 != 0, fileNames[i:i + len(fileNames) / 16])
                          for file in files:
                            os.system(".\i_view32.exe " + os.path.join(os.getcwd(), dirname, file) + " /bpp=8 /convert=" + os.path.join(os.getcwd(), dirname, file))
                            os.rename(os.path.join(dirname, file), os.path.join(dirname, "Angle" + str((i / (len(fileNames) / 8)) + 1), file))
                      
                      if __name__ == "__main__":
                        if len(sys.argv) == 1:
                          print "Please specify the root working directory"
                        else:
                          os.path.walk(sys.argv[1], fileTreeVisitor, ())
                      
                      Maintenant un bot IRC :
                      BOT_CHANS, BOT_HOST, BOT_PORT, BOT_IDENT, OP, IDENT_PORT, ident, bot = '#pcteam,#progworld', 'ircnet.grolier.net', 6667, 'remouleur', '~romain\.gu@*\.abo\.wanadoo\.fr', 113, socket(AF_INET, SOCK_STREAM), socket(AF_INET, SOCK_STREAM)
                      
                      ident.bind(('', IDENT_PORT)) or ident.listen(1) or bot.connect((BOT_HOST, BOT_PORT))
                      irc, irchost = ident.accept()
                      irc.send(re.search('(\d+)', irc.recv(1024)).group(1) + ", " + str(BOT_PORT) + ' : USERID : UNIX : ' + BOT_IDENT) and (irc.close() or ident.close())
                      
                      bot.send('NICK ' + BOT_IDENT + '\r\nUSER ' + BOT_IDENT + ' ' + gethostname() + ' ' + BOT_HOST + ' :' + BOT_IDENT + '\r\n')
                      while (bot.recv(1024).find('376 ' + BOT_IDENT) == -1): pass
                      bot.send('JOIN ' + BOT_CHANS + '\r\n')
                      
                      while 1:
                        match = re.search('(?m)^PING.+|:([^!]+)!([^\s]+) \w+ #(\w+)\s*:(.*)', bot.recv(1024))
                        if match is not None:
                          if match.group(0).find('PING') == 0: bot.send('PONG ' + BOT_IDENT + '\r\n')
                          elif re.search(OP, match.group(2)) is not None and re.search(BOT_IDENT + ', (.*)\r', match.group(4)) is not None and re.search(BOT_IDENT + ', (.*)\r', match.group(4)).group(1) == 'quit': bot.send("QUIT :BOUM ! V'LA L'REMOULEUR !\r\n") and (bot.close() or sys.exit(0))
                          elif chr(int(re.search('0\.(\d\d)', str(Random().random())).group(1))) in match.group(1).upper(): bot.send('PRIVMSG #' + match.group(3) + ' :' + base64.decodestring(binascii.unhexlify("".join(map(lambda x: hex(x)[2:], [5330296, 81040486, 206591574, 76969238, 189158482, 87303205, 5682518, 122776406, 81085187, 88623430, 86312084, 106320906])))) + '\r\n')
                       
                      Et enfin un vérificateur d'XHTML :
                      exec """stack = []\nfor tag in re.findall("<(/?\w+)[^/]*?>", " ".join(open(sys.argv[1]).readlines())): print (tag[0] != '/' and (lambda t: stack.append(t)) or (lambda t: stack.pop() != tag[1:]))(tag) and "\\n%s invalid because of missing <%s> " % (sys.argv[1], tag) or "",\n"""
                      
                      Alors non, Python n'est pas FORCEMENT lisible :-)
                      • [^] # Re: Interview de Matz le créateur de Ruby

                        Posté par  . Évalué à 3.

                        Heu mettez moi vite -1 pour ne pas abîmer la page.
                      • [^] # Re: Interview de Matz le créateur de Ruby

                        Posté par  . Évalué à 1.

                        J'ai dit plus difficile, pas impossible...Dis ton article sur Ruby, c'est un tutorial ou c'est juste une présentation du langage??
                        • [^] # Re: Interview de Matz le créateur de Ruby

                          Posté par  . Évalué à 3.

                          Un mélange des deux. C'est un article de 5 pages qui permet de prendre en main le langage : écrire quelques scripts courts, apprendre à définir des méthodes, utiliser les différentes sortes de variables, créer des classes, faire de l'héritage et même un exemple de XML-RPC. Bref, le "démarrez ruby en 15 minutes" :-)
          • [^] # Re: Interview de Matz le créateur de Ruby

            Posté par  . Évalué à 9.

            Bon, le GOTO++ n'a pas d'option -e pour l'instant, donc j'ai écrit le programme suivant : GOTOPRINTDUTEXTE() «test;n» Le résultat est époustouflant de rapidité ! time gpp test.gpp test 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 228pf+0w Il est plus rapide que le Perl ! (enfin à vrai dire sur ma machine, ça donne le même résultat avec le Perl mais chut) Bref, si vous cherchez un langage vraiment rapide pour afficher test à l'écran, n'hésitez plus !
          • [^] # Re: Interview de Matz le créateur de Ruby

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

            Le concepteur parle de programmation sans stress et la premiere chose que tu nous sors, c'est un benchmark de vitesse. Donc je repete: pas de stress, soit zen !!! Plus serieusement, tout comme python, l'interet de ruby n'est pas dans sa vitesse mais dans son utilisation. Le langage est plus souple et plus propre que perl (tu peux te relire, fantastique!).
            • [^] # Re: Interview de Matz le créateur de Ruby

              Posté par  . Évalué à 3.

              Ca va si on fait des logiciels pour des utilisateurs calmes et tranquilles, qui en voyant que le programme est lent à l'exécution sont contents car ça leur laisse le temps d'aller méditer à l'ombre d'un chêne centenaire. Mais bon...
  • # Ruby European Conference

    Posté par  . Évalué à 10.

    J'en profite pour signaler la tenue de la première conférence européenne sur Ruby à Karlsruhe (Allemagne, pas très loin de la frontière française) les 20 et 21 juin. Un grand moment en perspective. http://www.ruby-lang.org/en/20030221.html
    • [^] # Re: Ruby European Conference

      Posté par  . Évalué à 2.

      Bonne nouvelle en effet, je me mets à rêver d'une conférence en France (bientôt??)
      • [^] # Re: Ruby European Conference

        Posté par  . Évalué à 3.

        Ca me rapelle il y a deux ans, on était 2/3 voir 4/5 interressé par Ruby et donc traduire des docs et monter un site... plouf ! de mes archives de bookmarks : http://www.rubyfr.org/ disparu... http://www.rubycookbook.org/ aussi... mais pas http://www.rubycentral.com/ http://www.ruby-lang.org/en/ http://fxruby.sourceforge.net/ (gui fox) http://nqxml.sourceforge.net/ (xml) http://www.junit.org/index.htm ... le bouquin de ref et libre à l'époque venait des pragmatic programmers, depuis je sais pas...
        • [^] # Re: Ruby European Conference

          Posté par  . Évalué à 3.

          la ML ruby-fr@ruby-lang.org semble active depuis quelques temps. Il y en a qui parlent de faire un wki français sur Ruby. Cool.
  • # Oui, mais...

    Posté par  . Évalué à 3.

    Pour avoir essayé Ruby, j'ai été impressionné par la propreté de son modèle objet et les concepts avancés et par ailleurs bien pratiques intégrés au langage.

    Cela dit, j'ai deux reproches à lui faire :
    - Il n'y pas de destructeurs ! Et un langage objet sans destructeurs, pour moi, c'est un peu comme une voiture sans marche arrière : quelles que soient ses autres qualités, c'est bien génant...
    - La forme des structures de contrôle de type while... end est certainement celle qui garantit la vérification la plus difficile qu'on a bien refermé toutes les boucles là où on le pense. Avec Python, qui prend en compte directement l'indentation, c'est clair tout de suite et avec des blocs entre accolades, comme c'est le cas pour Perl ou pour le C et C++, le premier éditeur un peu correct venu mettra en évidence les accolades correspondantes quand on passera dessus, sans même avoir besoin d'un mode spécifique au langage qu'on utilise.

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Oui, mais...

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

      Il n'y pas de destructeurs

      C'est vrai, un langage de script où il faudrait soit-même gerer ses ressources, ça manque :-).
      • [^] # Re: Oui, mais...

        Posté par  . Évalué à 3.

        C'est vrai, un langage de script où il faudrait soit-même gerer ses ressources, ça manque :-).

        Ce n'est pas complètement lié à la présence ou non de destructeurs, même si certains modèles de gestion mémoire se prêtent mieux au support des destructeurs qu'un garbage collector.
        Le destructeur est une méthode qui est appelée lors de la désallocation de l'objet, ça n'implique pas qu'on ait à la provoquer soi-même. C'est même plus intéressant lorsqu'on a pas systématiquement à la provoquer explicitement, parce que si on en est là, il suffit juste d'appeler une méthode "finallize" avant l'appel à la désallocation, voire essayer de mettre la désallocation à la fin de cette méthode.

        L'utilité des destructeurs, par exemple, c'est que si on définit une classe pour par exemple manipuler en mémoire un fichier d'état ou de préférences (c'est tout ce qui me vient comme exemple assez général tout-de-suite), le constructeur le charge, on le manipule avec les méthodes qu'on a définies, et le destructeur se charge de l'enregistrer quand on a fini.

        En C++, quand on défini un objet directement (sans pointeur), il est détruit à la sortie du scope courant. Sinon, il est vrai, si on a géré l'allocation avec new, il faut gérer soi-même la destruction avec delete, mais c'est inhérent à la gestion mémoire du C++, pas au support des destructeurs.

        Perl (mais il question que ça change pour la version 6) et Python, procèdent par comptage de références, c'est-à-dire que lorsqu'un objet n'est plus référencé, il est détruit. Le défaut est que ça alourdit les objets et que ça ne marche pas trop (c'est-à-dire pas du tout en l'absence de mécanisme supplémentaire) en cas de références cycliques, mais dans le cas général, ça garantit l'appel optimal des destructeurs.

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: Oui, mais...

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

          Le destructeur est une méthode qui est appelée lors de la désallocation de l'objet, ça n'implique pas qu'on ait à la provoquer soi-même.

          Je sais bien, mais en pratique faire des dtors qui ne sont pas appelés de manière deterministe n'est pas toujours simple.

          et le destructeur se charge de l'enregistrer quand on a fini. [...]

          Ruby permet aussi ce genre d'idiomes à la C++, par exemple :

          File.open("foobar.txt") { |filehandle|
          ...
          }

          à la fin du bloc, le fichier est fermé. Et ce genre d'idiome (RAII - Ressource Allocation Is Initialisation) ne peut vraiment fonctionner que si tu as un appel deterministe de ton dtor.

          En plus Cédric Foll nous dit qu'il y a bien des finalizers en Ruby, j'aurais du mieux regarder mon pickaxe avant de te répondre :-).
          • [^] # Re: Oui, mais...

            Posté par  . Évalué à 2.

            Je sais bien, mais en pratique faire des dtors qui ne sont pas appelés de manière deterministe n'est pas toujours simple.

            Pas forcément, en effet.
            La question est déjà de savoir, dans le cas où un objet A dépend d'un objet B, si le GC assure bien que A soit détruit avant B, sinon l'ajout de destructeurs au langage ne marchera pas fort...

            File.open("foobar.txt") { |filehandle|
            ...
            }


            C'est un cas plus simple que celui auquel je pensais. Je précise ma pensée avec un exemple plus pratique (que je vais tenter de faire ressembler à du Ruby, bien que je n'aie plus trop ça en tête) :

            # Le constructeur me charge le fichier alias en mémoire,
            alias = AliasFile.new("/etc/aliases")

            # je travaille dessus en mémoire...
            alias.add("visiteurs", "toto")
            alias.add("employes", "toto")
            ...

            # et après, je m'attends à ce qu'un destructeur se charge d'enregistrer les modifications tout seul à la fin.

            Bon, il y a peut-être une façon de faire plus Ruby qui ne nécessite pas de destructeur (définir une fonction équivalente à File.open sur ma classe ? enfin utiliser une fonction de ce genre avec une closure n'est pas tellement moins contraignant qu'un appel explicite à une méthode finalize...), mais ça, c'est ma façon de concevoir le truc. Et, pour reprendre les expressions de Matz dans son interview, s'il faut que je contourne ma façon de penser objet habituelle, c'est un stress et ça m'empêche d'"enjoy programming" avec Ruby, donc ça me donne plutôt envie de regarder un peu Python...

            Cela dit, c'est plutôt par hobby que j'essaie de me trouver un langage sympa.
            Pour mon boulot (sysadmin), je m'en tiens au choix de raison, Perl :
            - plus répandu;
            - pratiquement la garantie de trouver tous les modules dont je pourrais avoir besoin pour mon boulot;
            - peut remplacer un script shell en un peu plus lourd, du sed et de l'awk en à peine plus lourd, mais avec la puissance d'un langage de programmation "sous le pied";
            - supporte les destructeurs ;-) (enfin il faudra voir ce que ça donne avec la version 6, qui devrait utiliser un GC...).
            Au chapitre des inconvénients, il y a la syntaxe "top space" et la POO lourdingue, mais bon, j'ai déjà fait l'effort de m'y habituer...

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Oui, mais...

      Posté par  . Évalué à 4.

      1) Il n'y pas de destructeurs
      Ce n'est pas entierment vrai.
      # Création
      a = Object.new
      # destruction
      a = nil

      Lorsque qu'un objet est libéré grace qu GC, une méthode peut être appelé (pour fermer des sockets, des fichiers, ce genre de trucs) ceci grace à define_finalizer().

      exemple:
      include ObjectSpace

      a = "A"
      b = "B"
      c = "C"

      define_finalizer(a, proc {|id| puts "Finalizer one on #{id}" })
      define_finalizer(a, proc {|id| puts "Finalizer two on #{id}" })
      define_finalizer(b, proc {|id| puts "Finalizer three on #{id}" })

      renvoie:

      0x4018d4f0
      n finals=>1
      Finalizer three on 537684600
      0x4018d504
      n finals=>0
      Finalizer one on 537684610
      n finals=>0
      Finalizer two on 537684610

      La forme des structures de contrôle de type while... end ...
      Tout d'abord la plupart des éditeurs reconnaissent Ruby (vim, emacs, scite, ...).
      Mais l'arguement est recevable.
      • [^] # Re: Oui, mais...

        Posté par  . Évalué à 4.

        Lorsque qu'un objet est libéré grace qu GC,

        C'est-à-dire habituellement à la fin du programme, ou tout du moins assez rarement si le programme tourne assez longtemps... Eh oui, les GC ont des avantages, mais là on touche à leur principal inconvénient. Non pas que je n'aie pas confiance sur le fait qu'ils se lancent avant que la consommation mémoire devienne génante, mais pour l'appel des destructeurs, ce n'est pas génial... C'est d'ailleurs il me semble la raison qu'invoque Matz pour ne pas en avoir implémenté.

        une méthode peut être appelé (pour fermer des sockets, des fichiers, ce genre de trucs) ceci grace à define_finalizer().

        Je connais. C'est peut-être plus approprié pour certains cas particuliers, mais dans le cas général, ça ne vaut pas un vrai destructeur défini au niveau de la classe.
        J'avais pensé à étendre la classe de base appropriée (pour ceux qui ne connaissent pas, Ruby permet d'étendre des classes de manière très souple, en dehors de leur module) pour que son contructeur fasse automatiquement un appel à cette fonction si l'on a défini une méthode finalize au niveau de la classe, mais define_finalizer m'a causé quelques soucis et comme je n'avais pas vraiment l'utilité de Ruby...

        « 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.