[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: [e-mail]
> work: [e-mail]
> Web:  http://pirate.shu.edu/~blackdav
>