"Why I Program In Ruby (And Maybe Why You Shouldn't)"
Trollen Lord
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.)
Kyle Schmitt
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
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
> 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.
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.)
thefed
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
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
> 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/.
Giles Bowkett
> > 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.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com
Raul Parolari
> 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
Jari Williamsson
> 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
> 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." :)
Robert Dober
> 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.
R.
http://ruby-smalltalk.blogspot.com/
Richard Conroy
> 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,
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.
Eivind Eklund
> > 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.
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.
MonkeeSage
(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. :)
Regards,
Jordan
Trollen Lord
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.
Robert Dober
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
--
MonkeeSage
> 1) Something like Shoes for Ruby, core, and default on all platform
> distributions. It should also look and feel native.
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. :)
HTH,
Jordan
[1] http://tktable.sourceforge.net/tile/
[2] http://www.videolan.org/vlc/screenshots.html
[3] http://www.myopensource.org/screenshots/gimp.png
[4] http://members.hellug.gr/nkour/gmycosmos/screenshots/Gmycosmos_win32.png
[5] http://static.flickr.com/142/328140273_03cd2a4839_o.png
[6] http://www.blender.org/features-gallery/features/
MenTaLguY
> So there is no shortage of cross-platform, native-look and feel
> toolkits with ruby bindings.
Let's not forget the option of using Java GUI toolkits like Swing or
SWT with JRuby, either.
-mental
MonkeeSage
> On Wed, 28 Nov 2007 03:30:00 +0900, MonkeeSage <MonkeeS...@gmail.com> wrote:
> > So there is no shortage of cross-platform, native-look and feel
> > toolkits with ruby bindings.
>
> Let's not forget the option of using Java GUI toolkits like Swing or
> SWT with JRuby, either.
>
> -mental
Good catch! And on that note, an app people may be familiar with is
azureus 2.5 [1] which has a native look and feel on all three major
platforms via SWT, which as mental said, is exposed through JRuby.
So that's 5 major toolkits (or 6 if you count pure Swing, but I don't
know to what extent it implements native widgets; I think it's kind of
got its own look/feel and themes)...at *least* three of which are
production quality and support native look and feel across platforms
(SWT, WxWidgets, GTK). And BTW, that deserves a giant THANK YOU to
all the folks who made the ruby bindings happen for those toolkits.
And while I'm thinking of it, just as big a thank you to the smaller
guys write the bindings for FOX and FLTK and other lesser known
toolkits (keep up the good work!).
[1] http://azureus.sourceforge.net/screenshots_v2.php
Getting a bit mushy and GUI over all the options-ly yours,
Jordan
Brian Adkins
wrote:
> I don't think Rails is "the
> gateway drug to Ruby".
It was mine. I now very much like Ruby for its own sake, but Rails
brought me to the party.
> 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.
I respectfully disagree. Other languages, yes, *any* language, no. Of
course, you and I may differ on the meaning of "success".
Jari Williamsson
> 3.) No clue about QT. (Somebody?)
I believe QT would be a no-no in the default Ruby distribution, due to
the license agreement.
Best regards,
Jari Williamsson
Jari Williamsson
So which of these GUIs should be included in the standard Ruby
distribution, which was the OP's point?
Best regards,
Jari Williamsson
MonkeeSage
Trolltech actually have a dial-license (alternate GPLv2) for non-
commerical uses. [1] But I wasn't suggesting proposals for core
library packages (I don't really think that Tk should be in core). I'm
just trying to list the available options for major, cross-platform
toolkits. I believe that ruby as a GUI glue language (it is *much
more* than glue, but it is *at least* glue), shouldn't focus on
distributing GUI toolkits or bindings as part of the standard library;
instead, it should be up to the developer to redistribute or make
accessible those requirements. For example, when an XP user downloads
a .NET2 and and only has .NET1 installed, there is no magical genie
that pops out of the app and says "poof, be installed--you now
have .NET2 *fireworks and party favors*" Instead, they are directed to
windows update to get the required software (or else it's bundled as a
redist and starts a separate install process). I see no reason for
ruby to be different. (Sorry...this is not directed at you at all
Jari, I'm just voicing my stream-of-consciousness. I thank you for
your input!).
[1] http://trolltech.com/products/qt/licenses/licensing/opensource/
Regards,
Jordan
MenTaLguY
> So that's 5 major toolkits (or 6 if you count pure Swing, but I don't
> know to what extent it implements native widgets; I think it's kind of
> got its own look/feel and themes)...at *least* three of which are
> production quality and support native look and feel across platforms
> (SWT, WxWidgets, GTK).
In terms of look and feel, Swing is at least as "native" as Gtk is; both
use theme engines rather than wrapping actual native widgets. The main
difference is that GTK normally defaults to a theme emulating the native
look and feel, whereas most distributions of Swing (except the bundled
one on OS X) do not. It's easy to force Swing to use the native look
and feel though:
require 'java'
UIManager = Java.javax.swing.UIManager
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName)
..the last line of which you could also write:
UIManager.look_and_feel = UIManager.system_look_and_feel_class_name
(This IS Ruby, dammit.)
One other advantage of Swing over Gtk is the OS X support -- on OS X,
if the com.apple.macos.useScreenMenuBar runtime property is set to
true your application will use the system menu bar for menus, which is
not (as far as I know) yet possible with Gtk.
One downside to Swing on Windows is that the native Win32 theme lacks
some refinement (mostly odd padding choices), although Java 7 promises
to improve that situation.
-mental
MenTaLguY
> 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.
-mental
MonkeeSage
Nice. I've only played a little bit with JRuby, no GUI stuff, just
basics (my work is non-technical, so I've only used Java/Jruby/and
lately Scala as a hobby); other than that, I haven't run any Java apps
for quite some time. I just remembered a purple-ish sort of UI akin to
old macs (mac 7 or 8?).
> UIManager.look_and_feel = UIManager.system_look_and_feel_class_name
I like how the setter is automatically initialized. :)
Regards,
Jordan
Trollen Lord
>
> Here are the four "big" toolkits and some infos:
>
> 2.) WxWidgets supports true native widgets. I know it supports native
>
Not on Vista anymore, where WPF is slowly beginning to be the standard.
WxWidgets is deterotiating at this moment pretty fast if compared to the
platform (which is developing).
Well, themeing is nice. It is not however the same as being genuinely
native. The looks is easy part but achieving the feel is extremely hard.
Some widgets simply always react slightly differently which bugs users even
though they don't always consciously notice it. That is why only native is
native.
> 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]
The 5% is still on missing on XP as you pointed out as well. Anyways, it is
the "legacy" look (even most of the applications that target XP use newer
"Office" style looks etc) and sometimes fails to render properly (some
corporate environments for instance have group policies for unifying the
look of desktops, breaking the service that the native widgets feature of
gtk+/wimp requires. It falls back to default gtk in that case..) I'd say the
part that it handles natively is great, but it fails way too often.
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. :)
I have known all those for years. The shortcomings make them appalling. Why
I even bother talking about this is that it is quite possible to make a sort
of toolkit that is used for telling "I want this sort of interaction" and
the toolkit selects the proper real native way to accomplish it. That would
be like holy grail of GUIs for Ruby.
Btw, QT never has attempted to blend in. You can theme the looks somewhat
but it feels on all but KDE desktops pretty weird. On top of that some
things are really hard to get right and those are at least the menus. Popups
and the main menus are quite different and irritating on QT.
Trollen Lord
> Good catch! And on that note, an app people may be familiar with is
> azureus 2.5 [1] which has a native look and feel on all three major
> platforms via SWT, which as mental said, is exposed through JRuby.
>
The newest Sun's jre actually calls native libraries to achieve most or at
least some. At least afaik. It should know at least GTK+ and windows forms
and changing between them is a matter of roughly 5 lines of code. You need
at least 1.6 though.
Gerardo Santana Gómez Garrido
<jari.wil...@mailbox.swipnet.se> wrote:
> MonkeeSage wrote:
>
> > 3.) No clue about QT. (Somebody?)
>
> I believe QT would be a no-no in the default Ruby distribution, due to
> the license agreement.
You believe wrong.
Qt is dual-licensed. Trolltech offers free of charge a GPL licensed Qt.
--
Gerardo Santana
Trollen Lord
>
>
> > 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.
MenTaLguY
>> UIManager.look_and_feel = UIManager.system_look_and_feel_class_name
>
> I like how the setter is automatically initialized. :)
There are a lot of niceties to JRuby's Java integration -- for
example, a method called #isSomePredicate is also accessible as
#some_predicate?, and (at least in 1.1) you can use a Ruby block
in lieu of a terminal argument whose type is any single-method
interface (e.g. Runnable). Java collections also implement
Ruby enumerable and so on.
Not that there aren't rough spots to work out yet, but we're
making a concerted effort to have Java libraries feel as "Ruby" as
possible.
-mental
MonkeeSage
> [...snip...]
But you are complaining about the general state of affairs; not
anything ruby specific. As my posts demonstrated (I think) the ruby
toolkit bindings are on par with the state of the art; whether that
state is sufficient is another story. (And regarding Vista, that's
kind of a low-blow, as less than half of the XP apps even work
natively in Vista64, if at all). In any case, one is not without
recourse when it comes to x-platform GUI options in ruby. At least,
ruby is not behind any other language (including C) in this area,
because that's simply the state of the toolkits themselves. Toolkits
aren't Hellen Keller, and Ruby isn't the Miracle Worker. You can only
do so much with what you're given. ;)
Regards,
Jordan
Trollen Lord
> But you are complaining about the general state of affairs; not
> anything ruby specific. As my posts demonstrated (I think) the ruby
> toolkit bindings are on par with the state of the art; whether that
Yes, BINDINGS are on par. However...
The state of the art? I'd say Shoes is that. It is dumb. Very dumb. But what
being dumb means is that there is a promise of separating the "this is what
I want" and "this is how I want to see it" from each other. It has been done
in other technologies like the web (html vs css) ages ago already and it has
major advantages. Shoes doesn't do it yet technically (nor ever will I
think?) but take a look at how you define the GUIs. It wouldn't be hard
removing the Cairo dependency and making it more dynamic. THAT is state of
the art and would make defining most of the GUIs a wonderful and Rubyish
process.
> state is sufficient is another story. (And regarding Vista, that's
Yup.
>
> kind of a low-blow, as less than half of the XP apps even work
> natively in Vista64, if at all). In any case, one is not without
They do in Vista32. Which I am using at this moment. I don't have very many
things to complain about actually and have not bumped into even one single
application myself yet that would not have worked. But I think that is
irrelevant path to start discussing further. In any case, Vista seems to be
closer to 10% adoption rate and somewhere perhaps near 20% (just a quick
quess, although it is possible to estimate really accurately and reliably -
there are methods for that if you have complete marketing data from longer
period) there is the tipping point. After that it will be landslide. That
10% from roughly 1,3 billion computers is 130 millions already. We are not
talking small "markets" here in any case.
because that's simply the state of the toolkits themselves. Toolkits
> aren't Hellen Keller, and Ruby isn't the Miracle Worker. You can only
> do so much with what you're given. ;)
>
I just have the feelign the entire approach is aged and there would be a
good moment for throughout sanity check.
MonkeeSage
A bit off-topic, but how does JRuby resolve that (i.e., the
convenience method resolution)? It is some AST magic, or something as
mundane as splitting camel-cased indentifier strings? (not to knock
the latter; if it works, it works). I'll have to digg into JRuby
againt next weekend. It's been three or four months since I last had a
gander. :)
"Keep on keepin' on"-in,
Jordan
MenTaLguY
> Build process is the engineering view imho. It is the "getting started
> using something" process that you should worry about.
That's what I'm getting at. For the most part, today, users have to
compile the library themselves if they want to use it. That's a pretty
high bar.
At least the Qt binding actually has a win32 gem, though everyone else
still has to compile from the .tgz. Ruby-gnome has... well, it's got
Debian packages. Actually building ruby-gnome from source is not a
fun experience.
> Nor will slapping 1:1 bindings to some traditional single framework.
It'd be a distinct improvement, although it's not clear that any one
is suitable -- all the available frameworks involve considerable
tradeoffs. I do think that Swing with JRuby is the best option for GUI
programming with Ruby at the moment: if you have Java, it just works out
of the box. It's obviously not the final answer for Ruby as a whole
though, nor is it that pleasing to use.
If Shoes matures and gets the rough bits filed off, I think it could
be a solid contender for a ships-with-Ruby solution that's actually
fun. But right now Shoes is an experiment and we're still at the
stage of doing R&D to determine what sort of shape a good Ruby GUI
library has.
-mental
MonkeeSage
>
> > But you are complaining about the general state of affairs; not
> > anything ruby specific. As my posts demonstrated (I think) the ruby
> > toolkit bindings are on par with the state of the art; whether that
>
> Yes, BINDINGS are on par. However...
>
> The state of the art? I'd say Shoes is that. It is dumb. Very dumb. But what
> being dumb means is that there is a promise of separating the "this is what
> I want" and "this is how I want to see it" from each other. It has been done
> in other technologies like the web (html vs css) ages ago already and it has
> major advantages. Shoes doesn't do it yet technically (nor ever will I
> think?) but take a look at how you define the GUIs. It wouldn't be hard
> removing the Cairo dependency and making it more dynamic. THAT is state of
> the art and would make defining most of the GUIs a wonderful and Rubyish
> process.
You might be interested in XULRunner [1] from the Mozilla foundation
(i.e., the dudes who make firefox). XUL is already a cross-breed
between markup and GUI, and works on the "big three" OS's as it comes.
It's actually very easy to use if you know HTML/XML. The main drawback
is that it requires JavaScript to drive it (inc. DCOM, XPCOM).
XULPlanet.com has in-depth documentation however. [2]. I have no
problem with JS, but some people hate it.
[1] http://developer.mozilla.org/en/docs/XULRunner
[2] http://xulplanet.com/
> They do in Vista32. Which I am using at this moment. I don't have very many
> things to complain about actually and have not bumped into even one single
> application myself yet that would not have worked. But I think that is
> irrelevant path to start discussing further. In any case, Vista seems to be
> closer to 10% adoption rate and somewhere perhaps near 20% (just a quick
> quess, although it is possible to estimate really accurately and reliably -
> there are methods for that if you have complete marketing data from longer
> period) there is the tipping point. After that it will be landslide. That
> 10% from roughly 1,3 billion computers is 130 millions already. We are not
> talking small "markets" here in any case.
I don't question the market share! And obviously, monkey-makers like
WoW are going to be updated to work *no matter what* ("OMG! LOL!!
LOLZ!! PWNED!"). But apps of lesser importance like FileZilla FTP
Server, aren;t guaranteed to work. My point was simply this; you can't
use a relatively new platform to hold against toolkits that took years
to integrate with the old platform. The standard is still the old
platform, the new, is, well...new!
Regards,
Jordan
Jeremy McAnally
people use it. :)
It's called dcov (rcov for documentation).
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.wil...@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
http://www.manning.com/mcanally/
My free Ruby e-book
http://www.humblelittlerubybook.com/
My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/
MonkeeSage
It actually would, since Cairo is full bitmap rendering suite...it
would involve implementing all the of the bit-bliting all over agin,
for one (very small) thing. Cairo is a general purpose screen drawing
library. Replacing/re-implementing it would be a *HUGE* (and
pointless) task.
Regards,
Jordan
MenTaLguY
> A bit off-topic, but how does JRuby resolve that (i.e., the
> convenience method resolution)? It is some AST magic, or something as
> mundane as splitting camel-cased indentifier strings? (not to knock
> the latter; if it works, it works).
It uses the Java reflection API to enumerate methods on Java classes
and splits camel-cased names to produce the "Ruby" versions. There
isn't any syntax magic required on the Ruby side of things.
> I'll have to digg into JRuby againt next weekend. It's been three
> or four months since I last had a gander. :)
I'll forewarn you that the Java integration portion of the code is
a bit pain-inducing. We're working towards a rewrite/cleanup though.
-mental
MenTaLguY
> You might be interested in XULRunner [1] from the Mozilla foundation
> (i.e., the dudes who make firefox). XUL is already a cross-breed
> between markup and GUI, and works on the "big three" OS's as it comes.
> It's actually very easy to use if you know HTML/XML. The main drawback
> is that it requires JavaScript to drive it (inc. DCOM, XPCOM).
> XULPlanet.com has in-depth documentation however. [2]. I have no
> problem with JS, but some people hate it.
Personally, I don't think XUL does a very good job of speparating
content and presentation. It's certainly not very enjoyable to use.
-mental
MenTaLguY
The Shoes drawing stuff doesn't expose cairo directly, however. In
principle Shoes could also be implemented atop something like
Swing/Java2D without a huge amount of effort.
JShoes might be an interesting project for my copious spare time (ha!)
actually.
-mental
Trollen Lord
> XULPlanet.com has in-depth documentation however. [2]. I have no
> problem with JS, but some people hate it.
I'd say the ui of my Firefox is a little bit sluggish if compared to some
others... It is clearly visible on slower computers. Other than that it is a
good example of more modern approach and I kind of like the idea. However,
Ruby way would not likely use XML but Ruby classes? People (at least I learn
that with Rails and all the definitions:) are used to defining things like
that.
I don't question the market share! And obviously, monkey-makers like
Yeah it's better since I just wrote a study about the market share of
GNU/Linux and while at it saw all the numbers about the other platforms as
well and can drown anyone in a plethora of references if required ;-)
> Server, aren;t guaranteed to work. My point was simply this; you can't
> use a relatively new platform to hold against toolkits that took years
> to integrate with the old platform. The standard is still the old
> platform, the new, is, well...new!
>
Still more important from many viewpoints though than some other older
platforms ever.
Trollen Lord
> It actually would, since Cairo is full bitmap rendering suite...it
> would involve implementing all the of the bit-bliting all over agin,
> for one (very small) thing. Cairo is a general purpose screen drawing
> library. Replacing/re-implementing it would be a *HUGE* (and
> pointless) task.
>
Take a look at http://hackety.org/images/shoes-0.r252-small.png . The
rightmost sample. Is that generated using Cairo at some phase? It looks like
native, not themed, to me. Good enough for now. What is striking.. Is that
the toolkit handles is so that the leftmost and the image on the middle are
possible as well without twiddling with code. That is sufficient.
Technical hair splitting is not my panachea, it's too moot. If the Cairo
does all that and could do even the missing ones (WPF? QT?) then it is
simply wonderful to me. I just don't want to ever have to even know that it
exists at all if I am attempting to solve my primary task.
Marc Heiler
wonderful and Rubyish process."
There are many ruby bindings to gnome but while there are some nice
apps, you dont really see a lot of breathtaking programs in it.
There are simply too many limits. The dependency issue is not really
problematic. On windows you can install those fat .exe' files and
thats about it. I must know because I do it all the time on
windows (I still look for ruby-automation to install these things
but for now i do this manually, on windows ... windows is so
annoying, on linux i just run a few ruby scripts and be done with
it...)
In a way, the process to build complex apps is to blame for the problem
that there are not really VERY good AND big apps available in the
ruby-gui world. I.e. it should be simple to do a ruby-gimp version,
but what about the underlying library, or what if the
supported widgets are not yet on par with what gimp uses, etc...
It also takes a LOT of time ... research time too.
Shoes addresses this build-up process by offering a great abstraction to
this overall process.
Claiming to remove cairo as part of a "solution" to a problem which does
not really exist the way you wrote is like ... I don't know... rubbing
your face against a wall and complaining that your face gets dirty and
hurt in the process.
"The standard library is the problem."
I do not agree about "the" problem, but I would agree that there could
be a some little improves on it, especially from docu side.
Past when i looked at std lib, the docu was sometimes incomplete or not
really useful (for me). Something like noobkit is what I like and i
think this is
a good step away from the static and ugly looking .html/rdoc
combination.
Or, you can find a mail where I thought that Ruby as language should get
a stronger foothold on www aspects, just like PHP (and how php grew).
But then again different people have different opinions anyway and
altogether Ruby beats all the other languages out there easily for
my needs. You also must acknowledge, that a better language, enables
"stupid" people (like me) to build and do better (more sophisticated)
stuff. AND IN YOUR FLAMES YOU DO NOT SUGGEST ANY ALTERNATIVE!
This trolling is annoying. However, you raised some points that
have a little truth in it... lets get on it
"You get instantly dragged into installing extra native
libraries and their bindings"
I agree partially but even though others wrote this already:
Ruby != Java
And on Windows, where is the problem anyway... click-click-click
INSTALLED. Did you look at how large java+netbeans is?
This is insane man ...
"Ruby is entirely unsuitable for GUI application development."
BULLSHIT!
Either you lie or are clueless. Don't get me wrong on it. I admit
that there are problems. I started with ruby-gtk because of the
wiki, and I have not regretted it in overall.
Ruby-gtk fits most of my needs.
I use it on windows too. I never had the need to use Tk and I am
also not a mac user. For my linux and windows needs it is
perfect, and EXACTLY the wiki was my reason to pick it.
I am bad at learning so I need all the docu i can find, and
i think i wrote around 300 more or less small apps with
ruby-gtk (which is another reason why I will agree stating that
something like shoes is wonderful to have. I hope shoes will
rock)
"Too much complexity and risks."
I laugh about customers and their fears! Go Java, customers,
embrace your favourite world!
I use Ruby because I love it as a language. For me, all my
apps work, and if they don't i can fix it instantly ;)
The biggest stepping stone was never ruby as such, but
always my lack of knowledge (and this is to a lot degree
to be blamed on docu)
Anyway, I know you are a troll and you deserve pointless
flaming. But I accept some of your other points,
these should not be dismissed too easily.
So apologies if my tone is inappropriate.
"All in all, Ruby could really shine. But I think it will never
do that. "
But still i have to say - you shine as a troll.
Cheers! ;)
--
Posted via http://www.ruby-forum.com/.
Luc Heinrich
> So there is no shortage of cross-platform, native-look and feel
> toolkits with ruby bindings.
Calling all these libraries "native look and feel toolkits" is just
marketing bullshit. They are *NOT*. They might allow to have a native
*look* by simply using the native widgets, but the *feel* is
absolutely *never* native. Never. Usually quite the contrary.
Crossplatform GUIs are a myth. Crossplatform native look and feel
does not exist, and never will, because all platforms are different,
and WANT to be different.
--
Luc Heinrich
Trollen Lord
>
>
> There are simply too many limits. The dependency issue is not really
> problematic. On windows you can install those fat .exe' files and
> thats about it. I must know because I do it all the time on
> windows (I still look for ruby-automation to install these things
> but for now i do this manually, on windows ... windows is so
> annoying, on linux i just run a few ruby scripts and be done with
> it...)
Yes, if you work on single workstations. Try using group policy rolling out
the Ruby and dozens of 3rd party bindings and .exes... Where I have been
having fun has had at least jre's already installed. No dependencies, just
webstart or copy couple simple files using group policy. Voila.
Mass-deploying Ruby is not a problem, but the rest is inconvenient,
especially to be done to reach sane basic expected functionality instead of
some rare specialities.
> Claiming to remove cairo as part of a "solution" to a problem which does
> not really exist the way you wrote is like ... I don't know... rubbing
>
I don't even honestly care what Cairo is. It's moot technical details. I
care just about the productive programming part. If cairo can produce native
widgets on all the most important platforms then why not just move Cairo
into Ruby's core dependencies.
> "The standard library is the problem."
> I do not agree about "the" problem, but I would agree that there could
> be a some little improves on it, especially from docu side.
It's piss poor, especially the documentation. After a few days working with
Visual Studio's help browser and the .NET MSDN libraries (or Sun's javadocs,
or what Delphi comes with) seeing the Ruby's 80s rdoc that is built for
target group that already has used those libraries but just needs reference
for checking parameters makes my eyes bleed.
>
> "stupid" people (like me) to build and do better (more sophisticated)
> stuff. AND IN YOUR FLAMES YOU DO NOT SUGGEST ANY ALTERNATIVE!
Yes I have. Several times, and extemely clearly. You just went into hair
splitting about irrelevant issues and not even attempted to understand the
other viewpoints.
>
> And on Windows, where is the problem anyway... click-click-click
> INSTALLED. Did you look at how large java+netbeans is?
> This is insane man ...
Most of it is documentation. The actually pretty darned good goldmine of
information that is nearly entirely nonexistent for Ruby.
>
> I use it on windows too. I never had the need to use Tk and I am
> also not a mac user. For my linux and windows needs it is
> perfect, and EXACTLY the wiki was my reason to pick it.
Then you obviously do not understand very much of usability and the
requirement of consistency. It's okay, 99% of the software is like that -
plain trash - anyways. I just myself wouldn't want to commit those
astrocities.
> "Too much complexity and risks."
> I laugh about customers and their fears! Go Java, customers,
> embrace your favourite world!
> I use Ruby because I love it as a language. For me, all my
If you loved it as a language you would want more people into improving it
and coming forth with their ideas for refinement instead of scaring them
away. Especially as the aims are really not contradictory.
_why
> Take a look at http://hackety.org/images/shoes-0.r252-small.png . The
> rightmost sample. Is that generated using Cairo at some phase? It looks like
> native, not themed, to me.
So, hello and might I just add that what we have in Shoes are three
things to manage drawing the window, which are:
* Cairo for sketching shapes and colors
http://hackety.org/2007/08/02/mashingInSomeGraphics.html
* Pango for doing text wrapping, i18n, linking and all that
http://hackety.org/2007/08/17/hypershoes.html
* And native widgets using plain win32, osx and gtk code
But Shoes only has a handful of native widgets. The idea is to make apps
that look are more like browser apps than traditional gooey apps.
No need for menus and tree controls and pinned windows and all that.
http://code.whytheluckystiff.net/svn/shoes/trunk/README
So, Shoes is a bit more than Cairo. Such as: it wraps Ruby for its
scripting and VLC for embedded video. Not that any of this should
give anyone much pause. Nobody knows Shoes.
_why
Trollen Lord
Nice. However it does not lower the power required to participate.
"Rubydocforge" with good interfaces would be even better :)
Jeremy McAnally
Ruby documentation very easy, but it's been slow. I'm hoping to have
something to show very soon...
Until then, I'm not sure what to do to stimulate people to document.
There's a fairly rampant perception that your tests/specs should acts
as documentation, but I think that perhaps they don't fill the gap by
themselves. They're no doubt a great complement to API/narrative
documentation, but I don't think they stand alone very well.
Perhaps we should start a fund to document stuff (there's one for
Rails but it'd be neat to see one for general Ruby libraries).
Bounties, anyone? :)
--Jeremy
On Nov 28, 2007 2:01 PM, Trollen Lord <troll...@gmail.com> wrote:
> Nice. However it does not lower the power required to participate.
> "Rubydocforge" with good interfaces would be even better :)
>
--
MenTaLguY
> So, Shoes is a bit more than Cairo.
I think (given the confusion in the thread so far) it's also important
to point out that Shoes isn't a wrapper for cairo per se: it just uses
cairo behind the scenes to implement its own drawing API.
-mental
MenTaLguY
> I think (given the confusion in the thread so far) it's also important
> to point out that Shoes isn't a wrapper for cairo per se: it just uses
> cairo behind the scenes to implement its own drawing API.
(Which is essentially the NodeBox drawing API...)
-mental
Rick DeNatale
> Nobody knows Shoes.
You keep saying that.
I guess you've never met my wife! <G>
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
MonkeeSage
Sorry if I contributed to the confusion. My comment about Cairo was
intended to be generic, not about Shoes in particular. Saying "just
remove the Cairo stuff" for *any* graphical app built against Cairo is
*alot* more work that the person who suggested that seems to think,
even if only a few bits of Cairo are actually used.
Regards,
Jordan
MonkeeSage
I missed this. I'm certainly no XUL evangelist--and less so for
JavaScript! (I'm praying for the day that we can use ruby or even
python to interact with the gecko DOM! [1]). But I think it really
depends on the programmer. You can use CSS just as with (X)HTML. The
separation is just as clear as you, the programmer, want to make it.
Now, whether it is enjoyable to use JavaScript after using a language
as pleasant as ruby, that's kind of unfair! That's like asking if it's
more enjoyable to do long-division by hand or with a calculator,
heh! ;)
[1] http://rightfootin.blogspot.com/2006/08/kazehakaseruby-in-your-browser.html
Regards,
Jordan
Jari Williamsson
> Indeed. I've started work on a really nice utility to make working on
> Ruby documentation very easy, but it's been slow. I'm hoping to have
> something to show very soon...
This sound fantastic!
Let me know if you want any ideas! Here are some obvious ones:
1. The utility you're now building also must have state-o-the-art
documentation (good and well-organized tutorials, index, good template,
etc). Setting good examples are of course important.
2. That your utility includes a few help templates. You could for
example ask the authors of existing templates (such as "jamis" and
"Allison") if the could distribute those.
3. That your utility bundles a few PD icons for often-used situations
(code samples, exclamation point, question mark, etc)
> Until then, I'm not sure what to do to stimulate people to document.
I think the key actually is in the blog post that started this whole
long thread (about American culture not having a conceptual word for
what Ruby really stands for). If there's a mantra going that Ruby is
designed to make programmers feel good, it should be pretty evident that
bad documentation disrupt that feel.
Another thing: there are 100's of web sites on how to program in Ruby,
but is there any site on how to write documentation for Ruby
programmers? And I don't just mean RDoc tags and such, but how to
organize, how to write tutorials, how and when to write code examples,
etc. Perhaps that could be part of your project as a Wiki?
I'm really looking forward to your project!
Best regards,
Jari Williamsson