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 lwn / lwn.net 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 <pabs / pablotron.org> 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 pabs / pablotron.org. 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 usa / ruby-lang.org (<-- 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 <pabs / pablotron.org> pabs in #gah (OPN IRC) http://www.pablotron.org/ OpenPGP Key ID: 0x82C29562