From: Trollen Lord <trollenlord@...>
Date: 2007-11-28T05:51:51+09:00
Subject: Re: "Why I Program In Ruby (And Maybe Why You Shouldn't)"

------=_Part_168_13631096.1196196714209
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
>
> > So which of these GUIs should be included in the standard Ruby
> > distribution, which was the OP's point?
>
> I'm not sure any of them need to be in the standard distribution
> (most languages don't have GUI toolkits there), but it is important
> that they be readily available without a painful build process.
>

I have to clarify. First of all, it was but one of my points, but one
nevertheless.

Now that is quite distinct question from whether it is a GOOD thing that
most languages don't have GUI toolkits there. We have been screwing up the
"art of programming" for couple decades already. Furthermore, how do you
define that "most languages". If you define it by "most used by amoutn of
programmers or applications at this moment", which seems more appropriate
then it becomes a battlefield of Delphi, Java and the .NET languages.

Build process is the engineering view imho. It is the "getting started using
something" process that you should worry about. Being tested (integration),
documented well, supported, fanboyed (perhaps even) is what you expect for
numerous positive reasons. Which means in other words: a plethora of
possibilities to build basic expected components of your platform you start
building on is really not as good as having something good by default. If
you went that way you'd be still happy programming in symbolic assembler or
so instead of Ruby. Like the article I referred to in my first post said:
Art. Focus on the programmer and feeling good. The present state does _not_
do that nor will.

Nor will slapping 1:1 bindings to some traditional single framework.

------=_Part_168_13631096.1196196714209--