From: Alun ap Rhisiart Date: 2001-07-12T19:25:48+09:00 Subject: [ruby-talk:17707] Re: Ruby on Slashdot I'm new to this list , so forgive me if this has all been covered already. I started looking at Ruby about a month ago. I have been doing OO since 1988, first Object Pascal, then Smalltalk in 1989, and I have been working in Smalltalk ever since. I have used about eight languages to some extent, maybe three or four for a period of time. Although I am strongly motivated to like Java (brings lots of apps to Mac OS and Linux), I'm afraid I don't. This year, I tried Perl (and surprised myself by liking it), then Python, which I really like, and finally Ruby, which seems the best of all (although I would still do large multi-developer apps in Smalltalk). What I am concerned with is that Ruby may go the way of Smalltalk: a burst of relative popularity, then giving way to something distinctly inferior. I would like to say what I think went wrong with Smalltalk, and ask, 'How do we stop the same thing happening to Ruby?'. Smalltalk was ahead of its time, sure, but mostly I thing the vendors are at fault. First, it was too expensive, which meant that lots of people (eg students) couldn't just pick it up out of interest, and then form a pool of resource that managers could hire from. This doesn't affect Ruby. The next, and major, problem was standardization. The original ObjectWorks ( and later VisualWorks) worked on any platform, long before Java copied the idea. Then others produced versions, but with very significant differences in the class library (not the language), and none of them kept up the portability. The differences are such that I have been turned down without even an interview for a VisualWorks contract, even though I had 10 years experience in IBM VisualAge, Digitalk, and SmalltalkAgents - and they were right! When Microso$t tried to commandeer Java and add lots of non-portable stuff so that people would still end up making Windows-only apps, Sun (to their great credit) stamped on them. What happens when we have vendors making lovely IDEs for Ruby? And note, it is the class library rather than just the language syntax that really counts. The X3J20 standard was too little and too late to really benefit Smalltalk, should we be thinking about a Ruby standard now? Of course, other factors were involved beyond what I have mentioned here, in particular the rise of the internet, and Java's hitching on with applets at the right time, with Netscape's help. The real accent now is on server scripting rather than downloading applets, and there of course Ruby is well able to compete. The new rising star is XML, and Ruby should not be lax in hitching a lift on that. Alun ap Rhisiart On Wednesday, July 11, 2001, at 09:20 pm, David Alan Black wrote: > Hello -- > > On Thu, 12 Jul 2001, Mathieu Bouchard wrote: > >> On Mon, 9 Jul 2001, David Alan Black wrote: >>> "Extracting" a standard, strictly speaking, would include >>> standardizing bugs... so there could of course be some iterative play >>> between core Ruby and the descriptive standard. But the idea would be >>> to protect the current language-development culture while still >>> presenting a formal standard as an interface to the world. >> >> If you want to really push this idea forward, let's have: >> >> 1. two implementations of the whole interpreter+lib; >> 2. a test suite; >> 3. a contracts suite. > > I follow #2 and #3 more than #1 -- not as a general matter but just in > this connection. That is, I'm not sure why/whether the process of > capturing a standard from a given version of Ruby would require a > second implementation. > >>> * the floodgate of implementations could open; >> >> IMHO unless some people here are really motivated to document+stdize >> Ruby, >> this will begin to happen way before formal description happens. > > I agree, and I'm not sure how I feel about it. If it isn't clear > exactly what they're implementing (i.e., what exactly is "Ruby"), that > probably won't solve the problem that some have mentioned of > acceptance and credibility in the corporate world. (I can only > speculate on this, as I know that world mainly second-hand :-) Also > keeping in sync with developments would be easier with a written > standard, so that even if one were not cutting edge one would at least > know it (rather than every implementor having to follow every change > in Ruby -- which, I assume, they simply wouldn't). > > > David > > -- > David Alan Black > home: dblack@candle.superlink.net > work: blackdav@shu.edu > Web: http://pirate.shu.edu/~blackdav >