Asp Forum - "Why I Program In Ruby (And Maybe Why You Shouldn't)"

Trollen Lord

11/26/2007 8:55:00 PM

Note: parts of this message were removed by the gateway to make it a legal Usenet post.

Hello,

I read recently Bowkett's "Why I Program In Ruby (And Maybe Why You
Shouldn't)" (
http://gilesbowkett.blogspot.com/2007/11/why-i-program-in-ruby-and-maybe-wh...),
and I have given it a little bit thought. Ruby is indeed what Matz has aimed
for - a blur between art and craft. Guys like why make my day with their
posts and I watch with awe some of the projects that are using Ruby. It as
language makes me feel unbelievably comfortable and makes programming even
fun (I am Msc (econ), not an engineer!) but still something is wrong.

It is not just about language after all. The language is great already, but
it is not enough. The standard library is the problem. Ruby is nice for
small demoing, replacing shell scripts and such but when you try it for
something more complex than what that nice "try Ruby in your browser"
application was meant for you get into serious trouble. It is something like
trying to barbecue some chunky bacon using a toothbrush and a dead squirrel
as heat source. You get instantly dragged into installing extra native
libraries and their bindings (process that means unreliability and extra
work for packaging etc if you wanted to redistribute it) and attempting to
understand extremely poorly documented classes. Ruby is a lot like one of
those screwdrivers with detachable tips. The handle is awesome but there are
no tips for it.

Let's take the standard library under scrutiny. First of all, Ruby lacks a
GUI toolkit. For historical reasons it comes with the "cross-platform" TK.
That's nice if the cross-platformity meant the same as "looks and feels out
of place and plain amateurish on every platform". After seeing something
like Shoes the TK really makes baby jesus cry. Ruby is entirely unsuitable
for GUI application development. No one really wants to install all those
3rd party hackish dependencies and pray constantly that all your customers
etc manage to keep them runnin as well. Too much complexity and risks.

Drb is awesome, but try the crypto (SSL) version using proper keys and
certificates (which you require for nearly every REAL use case anyways).
Have fun hunting some sane examples and documentation. The same goes for the
other networked classes as well. Their even slightly more advanced use cases
are entirely undocumented or as with some plain impossible. Try implementing
SSL+xmlrpc server and client and come back in 6 months or so when you have
succeeded. Very basic and expected features, all missing. All around.

Although Ruby knows how to build documentation, where on earth is my search
function? Frames, butt-ugliness and awful usability is all that I can see.
You could have expected that sort of output in the 90s perhaps but not
nowadays, not in a modern environment! On top of that most of the std-lib
documentation is written for people who already have used those libraries.
API documentation is just a tiny part of what should be provided. The lack
of examples, rationaile and verbosity are lethal for attempting to
understand that jungle of hastily ported and imported mess. For example you
click on something like tracer and the most describing thing there is
"tracer main class". Uhh gee. Thanks. Very useful. I think tracer is a
bullet with incendiary chemicals added for burning while flying towards
target.. Still. The whole pile of "documentation" is like that. Unfriendly
and plain useless.

There's a lot of legacy in Ruby. For instance no real utf-8 (come on, UTF-8
is earlier 90s invention already!), stuff like webrick (there are better
alternatives nowadays), and so on. In fact I think there is nearly complete
lack of development outside the very core of the language. In fact I think
it was never developed far enough before it really stopped again. There is
no sense of it ever having any real direction and determinant force,
especially on what comes to the standard libraries which are mostly just
plain childish and protected by insane amount of change resistance and lack
of resources or will.

All in all, Ruby could really shine. But I think it will never do that. It
is a real shame because I kind of like it. Also I fear 99% of the people
that bothered reading past the title will not get what I tried to say. Do
not comment on any examples or individual problems. If you do, you have lost
the point entirely. The symptoms should not be fixed. The root causes
should. The root cause is: complete lack of vision, leadership and will to
make Ruby a complete and modern environment for most common tasks. At this
moment it is more of an academic and assembly-required thing that can not
(not defined by "ability" but by sanity of using it as a tool for such task)
be used for nearly any non-childishly simple project.

(Rails might be an exception though, but the web frameworks seem mostly the
only sane domain for Ruby at this moment.)

55 Answers

Kyle Schmitt

11/26/2007 9:17:00 PM

After suppressing the urge to rant and scream troll subsided, there
are a few good points, though I don't think they are precisely for the
reasons you state.

Yes, ruby needs a better definition of what it's standard library is,
and needs utf support at the core. I don't think this is for lack of
proper development or leadership however.

Jruby, unless I'm very mistaken, has utf8 support. Basic proof that
it's fully possible to do. Why haven't people fixed it in the core
ruby yet? Well, they're working on Ruby 2.0 instead of backporting
major effort into the 1.8. That's fine with me (as long as, of
course, it gets done eventually ;).

What is installed as a GEM doesn't need to be installed as a gem, it
can be installed as a ruby library, as part of the distro or OSes
ruby. So aside from defining what _needs_ to be there, it's an easy
fix. (yes finding enough influential and knowledgeable people to
agree and define it will be a problem).

Graphical toolkit. Every graphical toolkit will have it's pros, cons,
lovers and haters, not to mention the dozen platforms with their own
special graphical toolkits ruby is used on.
Ruby _needs_ multiple, good toolkits.
Anyway, AFAIK rubytk is only "default" on the windows one click
installer: other platforms don't really consider it default. Gtk2 for
ruby is just as easy to install as the rubytk libs, and probably has
just as many or more supporters now.

Just a few retorts, though in many ways, I do have similar worries.

Cheers.

--Kyle

Mark Roseman

11/26/2007 10:00:00 PM

These are the sorts of growing pains that most languages hit as
popularity increases, but there aren't the core resources to 'support'
that growth, in terms of the deep foundations you discuss. Usually you
end up with a lot of shallower efforts spread among many areas.

Regarding the lack of global vision, that's always tough for an
admittedly general purpose language. Making a successful language that
is all things to all people (all done by a core group) is a recipe for
disaster.

There has to be a critical mass of people working in a particular area
for there to be the deeper solutions available. Rails is an obvious
example of this.

Unless you've got critical mass in some other area, the libraries and
solutions for that area are going to be shallow, as per the examples you
gave. That Ruby hasn't flourished as a premier platform for say desktop
applications suggests that there isn't enough solid interest and
commitment - a few people to take charge and a whole lot of other people
to help them. Expecting that to come from the core language is not
realistic.

One specific example... I agree 100% with your comments on the pitiful
state of GUI programming, and decrepit Tk being the default choice.
Having said that, there is actually a group who for the past few years
have been very actively modernizing the look and feel of Tk, while
keeping the basic programming model. There have been some fantastic
results, and some great looking apps built with this new work (i.e. you
wouldn't know it was Tk). But none of that newer work has found its way
into Ruby yet, so you're left with ugly (and undocumented) crap.

The people currently working on Tk would love to have some more
involvement from the Ruby community (both in terms of continuing
improvements to Tk, but also just hooking up the non-crap Tk stuff so
it's available in Ruby). Hasn't been a lot of interest to say the
least.

Vision is certainly needed, but it may have to be distributed around in
different areas.

Mark

Robert Dober

11/26/2007 10:32:00 PM

On Nov 26, 2007 10:17 PM, Kyle Schmitt <kyleaschmitt@gmail.com> wrote:
> After suppressing the urge to rant and scream troll subsided, there
> are a few good points, though I don't think they are precisely for the
> reasons you state.
The trollish tendencies were obvious, too obvious IMHO, anyway the
link to Gilles Blog alone is worth a post, great stuff.
For the rest....
Cheers
Robert

---
All truth passes through three stages. First, it is ridiculed. Second,
it is violently opposed. Third, it is accepted as being self-evident.
Schopenhauer (attr.)

fedzor

11/27/2007 12:18:00 AM

Excellent post!

Let's face it - it's not like Ruby doesn't have people who want to
help out.
It's not like we don't have enough supporters. There are tons of
people in the Ruby
community! Just look at the mailing list! So lets really have a quick
look at what
the problem is here. We've already ruled out lack of troops. We've
ruled out lack of
motive. So what's keeping us from creating some unifying standard GUI
wrapper?
What's keeping us from making some alternate GUI library altogether?
And that DRB
stuff - couldn't we fix that, too?

Well? Anyone?

Nothing. Well, at least I see it as nothing. You know what we're
missing? Organization.
It's true, a leader should organize their people into doing something
productive, but that's
not what Matz is - Matz is a creator. He brought us here, and we have
to take care of ourselves now.
It's our responsibility to sit down and make Ruby a better language
for everyone.

I guess on paper/phosphorous (depending on how old you are), it's not
that hard. Do what Drupel
and have a giant meeting or time frame where everyone just works on
Ruby. Think about it - if
200 people from around the world just for one summer worked on making
something better,
wouldn't everyone benefit? 10-20 people working on a unifying GUI
toolkit. Or maybe even
just a wrapper, so you could specify which toolkit to use! Another
10-20 working on making
DRB examples better (and maybe regularifying the syntax (sorry for
the verbalization - blame
Esperanto)), and some other people speeding up some speed deprived
programs. I guess it
wouldn't be hard, if for one summer people just focused their energy
on it. I, being a student,
would devote a summer to this in a heartbeat.

Does this mean I should? Probably not. I'm new to Ruby - been
programming it and anything
for about 9 months now. The gestation period is over, and I'm looking
to grow to be a better
Ruby developer. However I'm just not good enough. Good god, I'd love
to help. I'd love to sit
down June 16 and look back at the clock to find it's September, with
a whole bunch of
enhancements at my fingertips. I could learn so much! A lot of the
times, I just fail at general
programming - I don't understand algorithms and can't come up with
ways to solve things.
With this conglomerate programmer experience, I would learn a whole
bunch, and actually
be a part of something big and meaningful. Given the chance, I would.
Without hesitation.

So let's start putting some plans together. Get a big group of people
looking to help out, and then get a list of jobs to do. Meet on IRC
or a mailing list a couple times a week, put in an hour or three a
day (I don't know an adult schedule), and then we'd slowly be making
progress. Give it two months of constant work, and we'll have
multiple functioning projects, that could soon become standard.

Like I said, I'd do. Would you?

- Ari Brown

M. Edward (Ed) Borasky

11/27/2007 1:35:00 AM

thefed wrote:
> I guess on paper/phosphorous (depending on how old you are), it's not
> that hard. Do what Drupel
> and have a giant meeting or time frame where everyone just works on
> Ruby. Think about it - if
> 200 people from around the world just for one summer worked on making
> something better,
> wouldn't everyone benefit? 10-20 people working on a unifying GUI
> toolkit. Or maybe even
> just a wrapper, so you could specify which toolkit to use! Another
> 10-20 working on making
> DRB examples better (and maybe regularifying the syntax (sorry for the
> verbalization - blame
> Esperanto)), and some other people speeding up some speed deprived
> programs. I guess it
> wouldn't be hard, if for one summer people just focused their energy on
> it. I, being a student,
> would devote a summer to this in a heartbeat.
>
> Does this mean I should? Probably not. I'm new to Ruby - been
> programming it and anything
> for about 9 months now. The gestation period is over, and I'm looking to
> grow to be a better
> Ruby developer. However I'm just not good enough. Good god, I'd love to
> help. I'd love to sit
> down June 16 and look back at the clock to find it's September, with a
> whole bunch of
> enhancements at my fingertips. I could learn so much! A lot of the
> times, I just fail at general
> programming - I don't understand algorithms and can't come up with ways
> to solve things.
> With this conglomerate programmer experience, I would learn a whole
> bunch, and actually
> be a part of something big and meaningful. Given the chance, I would.
> Without hesitation.
>
> So let's start putting some plans together. Get a big group of people
> looking to help out, and then get a list of jobs to do. Meet on IRC or a
> mailing list a couple times a week, put in an hour or three a day (I
> don't know an adult schedule), and then we'd slowly be making progress.
> Give it two months of constant work, and we'll have multiple functioning
> projects, that could soon become standard.
>
> Like I said, I'd do. Would you?
>
> - Ari Brown

We (and lots of other open source projects) do have a smaller-scale
version of this, orchestrated by Ruby Central during the Google Summer
of Code. I don't remember how many years this has been going on, but the
list of projects turned out is fairly impressive.

That said, what *I* think Ruby needs, and is getting, are:

1. A solid definition of the syntax and semantics of the language. Right
now we have the Ruby 1.8.6 C code base, which is commonly referred to as
Matz' Reference Interpreter (or Implementation, or something like that).
In other words, the language is defined by how a specific program
behaves when presented with inputs. There are some alternatives, most
notably jRuby, which implement an extended subset of the MRI definition,
and there is the Ruby 1.9.0 code base (KRI -- Koichi's Reference
Interpreter) but when *most* of us talk about "the Ruby language", what
we mean is defined as what MRI does.

2. Practical use in areas other than Rails. I don't think Rails is "the
gateway drug to Ruby". That's demeaning to both Rails and Ruby, for one
thing. For another thing, I don't believe for a minute that a team of
people as talented as the people who built Rails couldn't duplicate it
and its success or even improve upon it in *any* language. And by *any*
language, I include macro assembler, C++, Forth, Lisp/Scheme, Ada and
Java in addition to the "easy to use languages" -- Perl, Python and PHP.
In other words, "nothing succeeds like success." :)

3. Tools for writing efficient and provably correct concurrent software.
In a lot of cases, that's going to mean that programmers have to *give
up* some of their cherished freedom that makes Ruby attractive to them.
I've been programming long enough that the supposed loss of freedom
doesn't bother me -- it's the process of programming and of seeing
working efficient software being created and real-world problems getting
solved that's the fun part, not necessarily one programming language
over another.

Lloyd Linklater

11/27/2007 1:48:00 AM

Trollen Lord wrote:
> All in all, Ruby could really shine. But I think it will never do that.

Well, I think that it is overstating things to say that it will *never*
shine. People can do amazing things if properly motivated.

That having been said, I must say that I agree with you in spirit. I
think that, as a language, it is has great stuff inside and I feel good
when I write with it. OTOH, I also agree that it is not ready for GUI
IDE development. While it would be nice if there was a Delphi for Ruby,
I do not see an incipient release.

As was mentioned before, there are growing pains to be reckoned with. I
remember writing assembler programs using debug. That totally sucked,
but I persisted as did others and things got better. We do need to have
someone get things together. Things will take off in a major way when
people can write a reasonable IDE. Even if it is only what Visual Basic
or Delphi had 10 years ago, it would be more than enough to bring ruby
into prime time.

I love the language. I have tried several libraries to make GUI apps
with no success. I am thinking of writing something to use rails as
some kind of "I give up. Give me ANYTHING" kind of user interface. I
find that part frustrating especially as everything I learn about ruby
makes me love it more, I find that I cannot get much use out of it. I
just write small scripts to do grunt work.

Is someone working on this somewhere? /hope
--
Posted via http://www.ruby-....

Giles Bowkett

11/27/2007 2:54:00 AM

> > After suppressing the urge to rant and scream troll subsided, there
> > are a few good points, though I don't think they are precisely for the
> > reasons you state.
> The trollish tendencies were obvious, too obvious IMHO, anyway the
> link to Gilles Blog alone is worth a post, great stuff.

Cool! Thanks. :-)

--
Giles Bowkett

Podcast: http://hollywoodgrit.bl...
Blog: http://gilesbowkett.bl...
Portfolio: http://www.gilesg...
Tumblelog: http://giles....

Raul Raul

11/27/2007 6:43:00 AM

Trollen Lord wrote:
> All in all, Ruby could really shine. But I think it will never do that.

If you feel down (I did) after reading this intelligent but depressing
view of Ruby's future, get a lift from this podcast (link in Gilles
Bowkett blog)
http://www.javaworld.com/podcasts/jtech/2007/112007jte...

It is amazing to listen somebody from Java explaining (with an
enthusiasm, humour, intelligence very rare) why Ruby is different from
all other languages (even mentioning in the podcast metaprogramming
examples of how Ruby simplifies design challenges); and how JRuby might
be the vehicle for Ruby to enter, somehow stealthily, in the enterprise.

The post, the blog, the podcast; a memorable evening,

Raul

--
Posted via http://www.ruby-....

Jari Williamsson

11/27/2007 8:04:00 AM

Trollen Lord wrote:
> Still. The whole pile of "documentation" is like that. Unfriendly
> and plain useless.

I agree with lots of what you said, and I think much of it can be
because many might think of Ruby as a way to cut corners?

Why are there so few projects on Rubyforge that leave their alpha/beta
stages to Production/Stable? Why are there so few libs with really good
documentation? Why is there not even good documentation on how to create
a Gem or maintaining it with Hoe? Why are there so few documentation
packages that use anything other than the old frame-based default
template? And so on.

Anyway:
Is there a utility that analyzes the data that RDoc is processing for
documentation (or analyze the result)? It should scan for methods with
missing documentation, methods with missing examples, count
cross-references, etc, etc. If not, this is the challenge: to create
such a utility!
Developers should get help to spot weak documentation and it should be
possible to rate one's documentation and be able to say things like
"Documentation gets a 97% quality rating by <name of utility>"

Best regards,

Jari Williamsson

M. Edward (Ed) Borasky

11/27/2007 3:15:00 PM

Jari Williamsson wrote:
> Why are there so few projects on Rubyforge that leave their alpha/beta
> stages to Production/Stable? Why are there so few libs with really good
> documentation? Why is there not even good documentation on how to create
> a Gem or maintaining it with Hoe? Why are there so few documentation
> packages that use anything other than the old frame-based default
> template? And so on.

Well ... there are a finite number of developers but a potentially
infinite number of good ideas for projects. Given that, projects tend to
self-organize around "leaders" and tend towards a distribution where
there are a few large successful projects like Rails, RSpec and Ruby
itself, and a few small successful projects like the One-Click
Installer, RubyGems, Rake, Hoe, ZenTest and Heckle. The rest of the
infinite number of good ideas are one-person projects that probably
don't go anywhere.

> Anyway:
> Is there a utility that analyzes the data that RDoc is processing for
> documentation (or analyze the result)? It should scan for methods with
> missing documentation, methods with missing examples, count
> cross-references, etc, etc. If not, this is the challenge: to create
> such a utility!
> Developers should get help to spot weak documentation and it should be
> possible to rate one's documentation and be able to say things like
> "Documentation gets a 97% quality rating by <name of utility>".

There are tools like that for many languages. I think the technical term
is "document coverage". There is also literate programming. Again, it
depends on whether you want to do one thing really really well and hope
it catches on, like Rails did, or do lots of things and when one *does*
catch on, let it self-organize into a sub-community. And if it *never*
catches on, well, welcome to the 95 percent of the "mud that didn't get
to sit up and look around." :)

comp.lang.ruby

"Why I Program In Ruby (And Maybe Why You Shouldn't)"

Trollen Lord

Kyle Schmitt

Mark Roseman

Robert Dober

fedzor

M. Edward (Ed) Borasky

Lloyd Linklater

Giles Bowkett

Raul Raul

Jari Williamsson

M. Edward (Ed) Borasky

x Login to ForumsZone