From: Lyle Johnson Date: 2002-06-26T23:54:10+09:00 Subject: Re: Andy Roonie is perhaps excessively optimistic Benjamin Peterson wrote: > to me. Also let me > apologise for not knowing who Andy Roonie is. Andy Rooney is a commentator who appears on "60 Minutes", a television news magazine show in the U.S. His segment ("A few minutes with Andy Rooney") appears at the end of every episode and is just a short monologue about whatever's on Andy's mind that day. I don't think the real Andy's done a rant on Perl 6 yet, though ;) <... bits about i18n and text processing snipped ...> I will take your word for it that these are significant roadblocks for you and others. I typically deal with English (ASCII) text exclusively and so it hasn't been an issue for me -- yet. > "Right. Well, I guess we'll carry on with Perl on the > server, but maybe > we can deploy Ruby on the Windows desktops. We could > do with a powerful > scripting environment on those things. Is there an > ActiveState version?" > "No. ActiveState expressed interest in producing a > Windows distribution quite > a while back, but... well, it didn't happen. There is > a Windows binary > distribution, though." Just curious, what would be the significance (benefit) of having an ActiveState Windows distribution versus some other Windows distribution? > "Good! Let's just check if the database support works > right, and then --" > "Er, actually it's a distribution that doesn't have > any database support. The most recent Ruby installer for Windows (from Andy Hunt) included Ruby/DBI, DBD/ODBC, DBD/Postgres, DBD/MySQL and DBD/Oracle. > "There isn't really a 'standard' per se at all. > Actually there's a bit of a > split between native windows and cygwin, still." I can compile Perl for the "native" Windows runtime or Cygwin, but the standard installers for Perl (e.g. ActivePerl) are built for native Windows. I can compile Python for the "native" Windows runtime or Cygwin, but the standard installers for Python (e.g. the PythonLabs distro or ActivePython) are built for native Windows. I can compile Ruby for the "native" Windows runtime or Cygwin, but the standard installer for Ruby (e.g. the Pragmatic Programmers' distro) is built for native Windows. Notice a pattern emerging? > "I... see. I assume, of course, that a standard > Windows distro that puts a > predictable Ruby version with database support on a > user's desk is coming up > soon." Based on previous point, I believe this is already available. > "Well... the creator of Ruby has specifically > indicated that he isn't interested > in Windows support, but people are always making > noises about it..." This is an especially important point. Two of the primary reasons that the Windows ports of Perl and Python have become so strong are that: 1. There was a developer, or group of developers, who took up the task of making them strong. People like Mark Hammond (in the Python community) or ActiveState (in the Perl community). 2. The lead developers (Guido and Larry) didn't resist Windows support. So far, no one in the Ruby community has really emerged as a "leader" for making the Windows port any stronger than it is. And it's not clear that their suggestions or contributions would be incorporated into the core anyways. > "Right. Well, heck, I guess we can carry on using > Perl on the desktops too. > I tell you what, though, we might still use Ruby for > some large application that > doesn't need to interact with the outside world much. > Ruby's clean OO structure > should make multithreading pretty easy." > "It doesn't do multithreading. It has what you would > call 'fibers', but they > are not true threads. If you perform a blocking > operation, the whole program > blocks. The trouble is, the Ruby code assumes one > Ruby machine per process so > it's hard to roll your own multithreaded Ruby." > "Well, how on earth do you use it in a web server, > then?" > "You remember Apache version one?" Grins for the Apache 1 reference ;) Yes, I think most people agree that Ruby needs native threads support. And I think it's equally clear that there's no way to hack that into the present Ruby source and we'll need to wait for Rite. > This in itself, however, is not really a problem. If > Ruby isn't aimed at > people who need internationalization, then so be it -- > it's free, after all. > The problem is more the lack of information on when, > if ever, things will > change, which makes it difficult to reccommend Ruby > with confidence. It is > difficult to make Ruby seem like a good investment -- > or even > like a properly run software project -- when the main > channel for information > is the occasional laconic epigram from matz. > > Questions like: > 'What is the status of Rite?' > 'When will we know what ruby's i18n support will > consist of when it arrives?' > 'When will 1.8 be available and what will be in it?' > > simply cannot be answered and as a result it is hard > for Ruby to appear > credible outside of the lone developer's workstation. Most of your questions point out Ruby's shortcomings for use as an enterprise software development solution, i.e. a replacement for Java. And for those points I'd have to agree with you. But obviously, people are finding Ruby useful for other kinds of applications. The last year or so have been an interesting period in Ruby's life. I don't know how (or if) the development model should change, and of course, it's ultimately Matz's decision. As with other languages, a lot of Ruby's best functionality isn't implemented in the core, but rather as extensions (e.g. database support), for which you don't need to depend on Matz's schedule. But for things that do depend on modifications to the core it would be nice to have some more concrete plans to work with.