Matz Roundtable Summary (was Re: rubyconf notes)

Below is my pieced together summary of matz's roundtable summary.  It's
available online at the URL below.  Can people please email me
corrections and or omissions?  I'll forward the corrected verion on to
[e-mail] after that.

PS. Matz: can you look over the answers I wrote down and make sure I got
everything you were trying to say correctly?  I know it's a bit of a
read, but I'd hate to be misrepresenting or misunderstanding something
you were trying to say.

PPS. On a completely unrelated note, did we ever decide whether or not
we're allowed to pgp sign messages on the mailing list?  It's mildly
annoying to have to turn off message signing for this list all the time
(yes, I know I can just do a mutt hook and forget about it, but I prefer
signing all my messages).

-----------------------------------------------------------------------
RubyConf 2002 - Matz Roundtable Summary
Paul Duncan <[e-mail]>
2002/11/01
=======================================

Last updated on Mon Nov 04 22:18:58 2002 EST.  The latest version of
this document is available at http://www.pablotron.org/rubyconf2002/. 

Introduction
============
This document may not be totally accurate; I was transcribing what I
heard, and neither my eyes nor my fingers are perfect.  In other words,
this is all paraphrased, and there may be omissions and/or gratuitous
errors.  Also, I didn't know peoples' names, so I was unable to
associate most of the questions with the people asking them.  In the
future, it would be nice if people asking questions would mention their
names before asking a question.  Feel free to email questions, comments,
or corrections to me at [e-mail].

Roundtable Summary
==================
Q. Why doesn't Ruby have first class methods (eg python- and smalltalk-
style)?
A. Matz is saying 1. performance, 2. he only knows (knew?) the concepts
of Smalltalk, not really the language itself.  He says that if people
want Smalltalk features they should either implement them themselves or
teach him about them.
<some side offers to teach Matz about Smalltalk features from the
resident Squeak and Smalltalk experts>.

Q. What are the major remaining issues for 1.8?
A. Whether or not to merge the new regular expression engine (REE) and
the new generational garbage collector (GC).

Q. What's new about the new REE?
A. Written from scratch, better localization support, easier to
maintain, etc.

Q. Are you willing to learn more about and consider implementing
Smalltalk features in Ruby?
A. Yes.

Q. Will you be here for OOPSLA 2002?
A. Yes.

Q. You had made some comments on the mailing list and earlier today about
maybe needing to rework the allocation framework.
A. 1. No redefining allocation calls from Ruby (that's a bug).
   2. No method lookup for allocation calls.

Q. Are those for performance reasons or is there some architechtural
reason? (my question)
A.  Yeah, performance.  And the Ruby-level access to allocation is
really a bug.

Q. Is there any desire for Ruby in Ruby (eg Rite, etc)?
A. I'm not interested.  As for the IDE, He's not really interested in
making an IDE for himself.

Q. What's the rational for rewriting the REE right now?
A. The license.  And the maintainability.  The current REE is from
Emacs, hacked support Perl 5 RE syntax.  It's too difficult to maintain.

Q. How many different licenses are involved in Ruby?
A. LGPL for the RE calls, BSD for bits of it, and Artistic for the rest.
[note: the file LEGAL, distributed with Ruby, explains which licenses
apply to what parts of the tree]

Q. Where would you like to have RubyConf next year?
A. It's up to the coordinator.
<me> DC!
<dblack> Yes! I will be accepting bids!
<matz (continued)> We can't really have it in Japan because that would
be too hard for many of you to make it.

Q. Doesn't that cut out a lot of core Ruby developers? (from me)
A. Yeah, but most of the Japanese developers don't speak English
anyway.

Q. Any thoughts about encapsulating the parser globals in structs in
order to allow per-thread Ruby interpreters?  (from devEiant?)
A. 2.0 will support this, but I haven't decided if the class namespace
will be split on a per-thread basis or not.

Q. Won't that break all existing C extensions? (from me)
A. Not necessarily, but the 2.0 extension API won't be compatible with
the current one anyway.  I'm not sure how different it will be, but it
won't be compatible.

Q. There's been talk of opening up the CPAN mirrors to other language
modules.  What are your thoughts on having mirrored sources of software
instead of just linking to it? (from the Perl YAML guy)
A. People have been talking about enabling uploads for stuff on RAA.  He
thinks the CPAN idea is a good one.

Q. The core module method naming scheme is somewhat inconsistent (eg
some use camelCase, some have under_scores, and some have uppercase
require names, etc).  Any plan to make that more consistent before the
1.8 release?  (I think this question was from the Test::Unit guy)
A.  Which modules are you referring to in particular?

<he can't come up with any specifically>

<zenspider (checking source)> There's very little camelCase left in
the source. Some in the Tk stuff, some in CGI, some in the Test::Unit
software (apparently the Test::Unit stuff is fixed in CVS).

Q. Are there any outstanding performance issues you'd like to take care
of before the 1.8 release?
A. Most of the low hanging fruit has been taken care of in the last 8
years.

Q. What's your take on Ruby adoption outside of Japan, and what can the
community here do to assist adoption?
A.  I'm not sure what makes people adopt languagse.  For Java, it's
marketing to some extent, but it's other stuff as well.
<zenspider> There's a high saturation rate for languages already, so
we need to take ruby to other language groups and start "infecting the
bastards."

<some more conversation, talking about needing a niche, and how it
might be nice if ruby was adopted as a testing suite for the various web
services packages>

<matz (continued)> We do need a killer application.  Test suites might
be that field.

Q. So when are you going to write the Perl to Ruby translator?
A. <laugh from matz> :)

<some more talk about encouraging Ruby adoption>

<matz (continued)> Don't fight with python people.  And Perl people,
they will move to Ruby when Perl 6 comes out.

<lots more laughs from the audience>

<more conversation about testing, references to Nathaniel's test suite
presentation from earlier today>

<zenspider> People should be plugging the fact that the original drb
was < 500 lines of code.
[note: His comment was a bit longer than this, but I missed the second
half.  Basicaly he was saying people should use the concise and powerful
nature of ruby applications as an advocacy point]

<dblack> I recommend a more grassroots approach.  Offering to give a
short presentation on Ruby in a Unix class, etc.  
[note: Earlier in the day he also mentioned how he mentions Ruby to his
more technically adept students]

Q. Have you given any thought to something similar to Perl's "use"
statement (eg a mechanism where you don't need to know the filename,
containing a particular class or module, just the class or module name
itself)?
A. I've encouraged people to follow the consistent naming scheme;
lowercase the class or module name and replace "::" with "/".

Q. Jaguar (MacOS 10.2) has now sold more than 100k copies, making it
the largest default installed ruby base.  Are there any plans to making
it part of the default install in other operating systems?  i know
there's a lot of interest in FreeBSD, for example.
A.  I didn't do anything to convince apple.
[note: Apparently Jordan Hubbard (of FreeBSD fame) is interested in
Ruby.  There's a killer application for FreeBSD called PortUpgrade,
written in ruby, that is encouraging a lot of FreeBSD attention]

<zenspider> Apparently the stock Jaguar install has a few minor issues
(invalid entries in rbconfig, etc).
[note: It didn't sound like there was anything really significant wrong
with the Jaguar build.  Just minor issues.]

Q. Threading models.  Will 2.0 will support plug-in threading models?
A. Rite will be native thread-safe [note: he means multiple isolated
interpreter contexts in the same process, via native threads], partially
using global locks, but user-level [aka green, or platform-neutral]
threads will remain.  2.0 will include native thread support as a
separate module (maybe called 'nativethread').  Native threads by
default aren't really good for Ruby.  

Q. What do you think are some of the major flaws in Ruby, or things
that you'd like to change?  And can you think of any features from other
languages you'd like to have in Ruby?  (from me)
A. We need to fix in-block local variables.  I can't think of any
features from other scripting languages that I really miss.  

Q. The only feature I really miss from Python is the really
nice OS abstraction (OS::Path).  Are there any plans to implement
something similar in Ruby? (from zenspider)
A. matz hasn't really heard of it, but he'll check it out.

Q. Any idea when popen3 will be fixed in win32? (from the FreeRIDE guy)
A. I have no idea about the Win32 code.  I need patches.

Q. Any plans to emulate fork() on win32 via createprocess? that way we
could move away from cygwin for win32?
A. Does mingw not support fork()?

<from several win32 people> no

A. Does anyone have any idea how to make an efficient process copy on a
Win32 system?

<me> install Linux or FreeBSD on the system.

A. Probably.

<laughs from the audience>

<more converation. appraently postgres is adopting a slow fork()
emulation via CreateProcess() for its Win32 port>

A. I'm not sure what's going to happen on Win32 for fork().  There's
some maintenance work for more compatability, so mabye it'll work
better in the future.  You should contact the Win32 Ruby maintainer at
[e-mail] (<-- not sure if that's right).

Q. I can't read Japanese, so all I can see from the Japanese mailing
list is that there's a lot of people.  How does the Japanese Ruby
community compare to the English community, and what kind of stuff are
they working on?
A. Active subscribers to the Japanese list are mainly developers and the
conversation is mainly about the niches and various corners of the Ruby
language.  Most of the CVS committers are Japanese.  A lot of little
bugfixes are done by them.  They're relatively modest (like many
Japanese are).  

Q. In what kind of ways are people in Japan making use of Ruby?
A. I'm not sure, but they don't use Perl any more. :)

<laughs from the audience>

Q. What is the percent usage of various scripting languages in Japan?
[note: I missed the answer to this question.  Matz, care to answer it
again?]

Q. Seamless win32 support is important for a lot of us.  are there any
plans of improving win32 support?
A. He agrees but didn'tr eally elaborate.
<random conversation...  i think this is mainly dead>

Q. Is the source code for the ruby-talk maining list availabe anywhere?
A. Yes. I wrote it. It's written in perl. 

<laughs from the audience>

Q. How many Japenese ruby books are there?
A. 21, and a 22nd is coming out this month.
[note: At this point Masayoshi Takahashi brought out all 21 of the
Japanese Ruby books, which effectively killed the roundtable, since
everyone got up to ooh and aah over the books.  I took several pictures
of the books; one them is available at
http://www.pablotron.org/rubyconf2002/japanese_ruby_books.jpg.  The rest
of them will be available when I finish uploading the rest of my
pictures]


-- 
Paul Duncan <[e-mail]>        pabs in #gah (OPN IRC)
http://www.pablotron.org/               OpenPGP Key ID: 0x82C29562