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

M

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
 
M

MenTaLguY

dynamic.

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.

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
 
T

Trollen Lord

Note: parts of this message were removed by the gateway to make it a legal Usenet post.
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.
 
T

Trollen Lord

Note: parts of this message were removed by the gateway to make it a legal Usenet post.
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.
 
M

Marc Heiler

"THAT is state of the art and would make defining most of the GUIs a
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! ;)
 
L

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

Trollen Lord

Note: parts of this message were removed by the gateway to make it a legal Usenet post.
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.
 
T

Trollen Lord

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

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

Jeremy McAnally

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

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

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



--
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/
 
M

MonkeeSage

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

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
 
J

Jari Williamsson

Jeremy said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,077
Latest member
SangMoor21

Latest Threads

Top