From: Conrad Schneiker <schneik@...>
Date: 2000-06-30T14:21:52-05:00
Subject: [ruby-talk:03734] Re: Why it's quiet

Hi,

Charles Hixson wrote:

> "NAKAMURA, Hiroshi" wrote:
>
> > ...
> > Compilation to exe!
> > Supports (Win32) native call!
> >
> > ...
> >
> > It is not worth Ruby, isn't it?
> >
> > // NaHi
>
> I don't really think that OS dependent features
> should be a part of a language.  An add on library
> if needed, or perhaps a post-processor.  And even
> for the libraries I feel that they should be
> minimized.  (E.g., tc/tkl and gtk are to be
> preferred over QT because the Win32 version of QT is
> expensive, but DirectX is to be TOTALLY avoided,
> because it only exists on Win32.)
>
> Perhaps if they are libraries that aren't
> distributed with the core language they would do no
> harm, or at least minimal harm.

Well, I think OS-dependent features for very widely used OS's are a good
idea for Ruby's standard libraries for general pragmatic and ease-of-use
reasons. The Ruby tar.gz file is still comparatively small; especially
in comparison to Java IDEs for instance.

There is a big difference between so-called "hackers" (who don't mind
fetching extra modules and dealing with the system administration and
distribution issues of coordinating all this stuff) and more so-called
"ordinary" end-users (and their managers) who avoid such things. This is
(ro will be) a much bigger consideration for most Ruby users that the
since of the distribution. I am all for supporting open source, but our
_primary_ concern should be focused on being _pro-end-user_ (for
_whatever_ library is reasonably widely used), rather than focused on
being anti-proprietary/pro-open source.

Obviously you don't want to include every OS-related library there is,
but I think it will greatly factiltate the growth of Ruby usage to
include the more commonly used ones (open source or otherwise). Likewise
for GUI libraries. This also makes life much easier for people who write
Ruby applications (for internal or external use).

--
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)