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
- Interview (22 clics)
# Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 2.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Stéphane Traumat (site web personnel) . Évalué à 0.
http://about.me/straumat
[^] # Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 2.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par bmc . Évalué à 10.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Yusei (Mastodon) . Évalué à 6.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par bmc . Évalué à 4.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 9.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Coox . Évalué à 9.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par spart . Évalué à 2.
> 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 TSelek . Évalué à 5.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 5.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Cédric Foll . Évalué à 10.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Cédric Foll . Évalué à 2.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par lorill (site web personnel) . Évalué à 0.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Christian . Évalué à 1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par NeuCeu . Évalué à 9.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par NeuCeu . Évalué à 2.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 2.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Romain Guy . Évalué à -1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Romain Guy . Évalué à 3.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Romain Guy . Évalué à 3.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Sidoine de Wispelaere . Évalué à 9.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par lorill (site web personnel) . Évalué à 6.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Sidoine de Wispelaere . Évalué à 8.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par lorill (site web personnel) . Évalué à 3.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Sidoine de Wispelaere . Évalué à 3.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par lorill (site web personnel) . Évalué à 3.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Alexandre Beraud . Évalué à 2.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par MrTout (site web personnel) . Évalué à 2.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par NeuCeu . Évalué à 5.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Philippe F (site web personnel) . Évalué à 7.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Sidoine de Wispelaere . Évalué à 3.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par xsnipe . Évalué à 3.
# Ruby European Conference
Posté par NeuCeu . Évalué à 10.
[^] # Re: Ruby European Conference
Posté par xsnipe . Évalué à 2.
[^] # Re: Ruby European Conference
Posté par TSelek . Évalué à 3.
[^] # Re: Ruby European Conference
Posté par NeuCeu . Évalué à 3.
# Oui, mais...
Posté par Arthur Accroc . Évalué à 3.
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 Guillaume Laurent (site web personnel) . Évalué à 2.
C'est vrai, un langage de script où il faudrait soit-même gerer ses ressources, ça manque :-).
[^] # Re: Oui, mais...
Posté par Arthur Accroc . Évalué à 3.
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 Guillaume Laurent (site web personnel) . Évalué à 3.
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 Arthur Accroc . Évalué à 2.
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 Cédric Foll . Évalué à 4.
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 Arthur Accroc . Évalué à 4.
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.