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

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-why-you.html),
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.)

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

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

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-forum.com/\.

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/112007jtech006.html

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-forum.com/\.

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

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

···

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.

---
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.)

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

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." :slight_smile:

Damn right. I don't listen much to podcasts, but I am listening to *this*
one. It covers a lot of bases, and is enthusiastic without hyping.

It certainly is an interesting article from a Ruby-curious point of view.
It articulates the value of metaprogramming and DSLs quite well.

The cows-in-the-road metaphor for Groovy is quite amusing too. It
summarises the philosophical and value differences between Groovy
and Ruby too.

···

On Nov 27, 2007 6:43 AM, Raul Parolari <raulparolari@gmail.com> wrote:

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/112007jtech006.html

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,

Since no-one has brought up ruby's "blank-space is meaningful" cousin
(Thou Shalt Not Name The Name!), let me just say that their libraries
are developed basically the same way as ours. There is no coalition of
central programmers with a roadmap and quotas toiling away at making
all the library extensions. Many of the libs are from small groups (or
single developers); for example ElementTree and the sqlite binding.
Both were created by individuals (and tweaked by small groups), and
both are now in the standard library, because they proved their worth.
Ruby has *more* of an organizing platform around rubyforge, if
anything. But ruby doesn't have as large a core of users. And that's
basically all it boils down to.

However, at the same time, sometimes people just aren't willing (or
don't know how?) to look for/use things. For example, people
complaining here about lack of GUI support. Well, I've not looked at
the native win32 bindings, nor very much at the wx or qt bindings (and
Tk, yeah I agree with everyone there...until Tile is distributed with
Tk, it makes me say "yuk"). But I have looked at ruby-gtk extensively,
and have programmed the *SAME APP* -- with semi-advanced stuff like
draggable, editable tree cells, draggable tabs and so forth -- in both
ruby and That Other Language, using their respective bindings to GTK
(to see how similar they were). The libs and docs for both were very
much on par with each other (which is to say excellent).

Ok, that's about all of my rambling. But I do want to make one last
point. Many other languages are as "poorly" documented (in their core
and popular libs), and are used every day for production or at least
prototyping. Notably, the functional languages: LISP (and it's read-
headed-stepchildren, Scheme, Guile, &c), SML and OCaml (not forgetting
their puritanical cousin Haskell). LISP has been around since the
50's(!) (on paper, anyway), and the others since the late 80's-early
90's. And they are not "fading" from sight any time soon. If anything,
they are becoming more popular than ever. So just because you can't
see something, doesn't mean it's not there, or is any less powerful; a
rip-current under what looks like calm seas can sink a freighter! And
a little iceberg can...well..."sink the titanic."

Whew! Now I'm done ranting. :slight_smile:

Regards,
Jordan

The podcast is memorable indeed and I will shamelessly use it to try
to get Ruby's foot into my enterprise.
I believe the quote
   "Ruby gives you a lot of spaces to put stuff"
describes Ruby as well as does the famous Dave Thomas quote: "Ruby
just stands out of your way".
Robert

···

On Nov 27, 2007 7:43 AM, Raul Parolari <raulparolari@gmail.com> wrote:

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/112007jtech006.html

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,

--

http://ruby-smalltalk.blogspot.com/

---
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.)

There is such a tool that I spent all summer writing, but very few
people use it. :slight_smile:

It's called dcov (rcov for documentation).

http://dcov.rubyforge.org

Of course, ironically, it's poorly documented, but you can still use
it just with little customization.

--Jeremy

···

On Nov 27, 2007 3:04 AM, Jari Williamsson <jari.williamsson@mailbox.swipnet.se> wrote:

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

--
http://www.jeremymcanally.com/

My books:
Ruby in Practice

My free Ruby e-book

My blogs:

http://www.rubyinpractice.com/

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." :slight_smile:

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.

> 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. :slight_smile:

···

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

I am sure that there are many more, just thinking of Facets or Ruport....
R.
http://ruby-smalltalk.blogspot.com/

···

On Nov 27, 2007 4:14 PM, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

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.

---
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.)

True.

To the degree this is a problem - and in a lot of cases, it is - it is
a combined culture and tools problem. The tools we have empatise
people people working alone, rather than letting other people into
your code.

For instance, RubyGems shuffle the gems production process towards the
original developer, and shuffle the use of the code away from hacking.
Using the default include method it isn't even possible to use code
checked directly out of version control.

RubyForge defaults to using centralized version control systems having
access only for the initiating developer, making it impossible for
somebody else to pick up if the developer falls off the face of the
earth.

The install/build tools people use (e.g, Rake) and packaging tools
doesn't enforce the structure of the source files/directory layout, so
we don't get easy hackability of code that's developed, so it is
harder than necessary for somebody to take over an old project.

Same with the fact that we use a number of different underlying
frameworks, such as Test::Unit vs RSpec.

Same with the fact that we use different version control systems.

Same with the lack of a generally trusted group that can "take over
support for projects", at least to the level where it is possible for
the group to assign a new maintainer if the old maintainer disappear.
The only person that is generally trusted is matz, and he's not into
that kind of thing.

All of this stuff is resolvable. It does require quite a bit of
effort, though, and probably taking one thing at a time. We had a
project that tried to handle a lot of it (RPA - www.rubyarchive.org) -
unfortunately, it died due to a number of unfortunate events
(including me not finding enough time/personal capacity to contribute
more than ideas). The Wiki there should still include the design for
a system that handle much of this; though, if I was to direct effort
to fixing all this today, I would probably start with picking
low-hanging fruit. Like maknig RubyForge default to asking for "Who
is going to be backup maintainer?" on creating a project, and
providing a small team to function as "default backup maintainer"
(which just give other people somewhere to take over if the original
maintainer stop having time for the project).

Eivind.

···

On Nov 27, 2007 4:14 PM, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

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.

I have to thank you guys for your comments. I was expecting to receive only
flames and idiocy - which admittedly guided my writing as well. Instead of
that there were sane voices, at least so far.

What is troublesome in getting into tk/gtk+/whatever comparison is that what
people expect is native looking and feeling applications. When they expect
is something that is like the rest of their desktop and applications.
Something like Shoes (does not do it at this moment, but) could do it -
abstract the most common needs and allow each platform to use the proper
toolkit. There is a realization there for the masses: it might just do the
trick to cover most but not even attempt to cover all of GUI concepts and
widgets. Supportability, implementability, and it makes developing most of
the GUIs again fun and even artful. It could become, when driven by good
people, yet another feature to "suck people into Ruby" as someone hinted
that Rails is doing at this moment! Quite honestly, last thing Ruby needs is
yet another "ooh we created 1:1 bindings on our belowed favorite gui
toolkit".

As someone hinted also, multi-domainity is hard. I just feel that covering
more is required even to drive in more contributors. That's a point when you
want to develop things. Fuel the process, don't attempt to carry it
yourself. Well, what I would do if I could and knew how to:

1) Something like Shoes for Ruby, core, and default on all platform
distributions. It should also look and feel native.
2) Finish/polish the UTF8 support and fast. It must be flawless.
3) Build a (Rails? Hah!) "Rosetta" (the translation tool the Ubuntu project
uses) alike web site for easier contributing to the documentation of the
Ruby's libraries. Make it usable and the features to direct towards
completeness. Build also a sane help browser system. Come on, it's Ruby
project, small and nifty, and much needed. Improve the documentation damnit!
4) After that, pick a new domain for the hype and fun. One thing that Ruby
doesn't have afaik even 3rd party access for is business orchestration
engines. Ruby is nearly entirely out of the SOA game at this moment. Hint
hint hint. Fun project, a little bit of Yaml, defining some basic constructs
and core engine, ... It for instance would lead into a lot of attention,
support, fun, and serious interest in Ruby.

Nice. However it does not lower the power required to participate.
"Rubydocforge" with good interfaces would be even better :slight_smile:

Here are the four "big" toolkits and some infos:

1.) Tk has an extension called Tile [1], which should be part of the
next major release as I understand it. I don't see why ruby wouldn't
have Tile support at that time (but don't hold me to it, just my
guess). Tile supports themes with more of a native look and feel (on
at least win* and *nix).

2.) WxWidgets supports true native widgets. I know it supports native
widgets on win* and *nix, and I think they have some cocoa support
(but not sure). I don't know how good the wxruby binding is firsthand,
but I've heard it's fairly decent. (Somebody?) For an example of a wx
app, check out the VLC screenshots [2]. VLC is a C/C++ app, but the
toolkit looks exactly the same as it would from a ruby app (look at
the native widgets screenshots, not the skins2 ones).

3.) No clue about QT. (Somebody?)

4.) GTK+. Native installer (.msi/.exe), about 12 megs. Excellent ruby
bindings and documentation. The default theme on win* using a .dll to
render native widgets. Looks about 95% native and is comparably fast.
Some screentshots of GTK+ running on win xp show how it looks. [3][4]
[5] And you don't have to just use the toolkit look, you can create
and theme your own widgets, and get something that looks like
fruityloops or 3dstudio if you want (like the free 3d modeler/ray-
tracer blender does [6]). Yes, I like gtk the best, but I see no
reason not to think that the others are/can be equally good.

So there is no shortage of cross-platform, native-look and feel
toolkits with ruby bindings. You just have to take the time and energy
to learn them. :slight_smile:

HTH,
Jordan

[1] Tile: an improved themeing engine for Tk
[2] VLC - Screenshots - VideoLAN
[3] myopensource.org
[4] http://members.hellug.gr/nkour/gmycosmos/screenshots/Gmycosmos_win32.png
[5] http://static.flickr.com/142/328140273_03cd2a4839_o.png
[6] Features — blender.org

···

On Nov 27, 11:42 am, Trollen Lord <trollenl...@gmail.com> wrote:

1) Something like Shoes for Ruby, core, and default on all platform
distributions. It should also look and feel native.