Where does ruby excel?

[Dolazy]

I have only used ruby for writing little scripts. Things that are
typically done using Perl/awk/bash... Ruby has the potential for much
more, but there doesn't seem to be a problem domain where it truly
excels. Maybe Rails, but that's a bit controversial (would it carry
large websites like Amazon or Facebook?).

On the client side Javascript seems to be the big winner. It is the
plugin language for Firefox, and in the future it may even become a
standard choice for desktop software development (with Adobe Air).

So where is ruby nowadays? For what kind of software would ruby be the
programming language of choice?

 

[Phlip]

I have only used ruby for writing little scripts. Things that are
typically done using Perl/awk/bash...

Ruby makes super-huge projects - such as multiple websites running across
multiple servers over multiple databases - just as easy. Dave Thomas's term
for this is "Ruby stays out of your way".

Ruby has the potential for much
more, but there doesn't seem to be a problem domain where it truly
excels. Maybe Rails, but that's a bit controversial (would it carry
large websites like Amazon or Facebook?).

That's simply because all the "killer apps" were written before Ruby came
along. Ruby did not invent OO, or AI, or the Web, or the GUI Desktop. Yet
Ruby is more than competitive in all these fields.

Rails is an exception. Whatever Ruby's merits, the simple fact is all the
web platforms before Rails sucked. They did not "stay out of your way", and
they did not minimize the logical distance between any two points in an MVC
framework. They made you spend time writing redundant plumbing. So Rails is
Ruby's killer app.

And, yes, Rails could provide a cleaner implementation of any one of those
megasites - Yahoo, Google, Amazon, etc. Read up on the problems with EBay's
source code to see what I mean!

On the client side Javascript seems to be the big winner. It is the
plugin language for Firefox, and in the future it may even become a
standard choice for desktop software development (with Adobe Air).

Horses for courses. Servers need expressive languages that value programmer
time. Anyone proficient in both Ruby and Javascript can code faster in
Ruby. Clients need a minimal, stable, and _standard_ language that always
does the one dumb thing it's told to.

So where is ruby nowadays? For what kind of software would ruby be the
programming language of choice?

Any new project of any type, with the obvious exception of life-critical (or
money-critical) applications. That's because the Ruby community prefers to
rapidly change things, and if I want to publish a tweak to one of my
libraries I don't need to worry it will kill someone I don't know. There
are alternate systems for those kinds of applications. For everything else,
use a language that stays out of your way!

 

[Joel VanderWerf]

So where is ruby nowadays? For what kind of software would ruby be the
programming language of choice?

As a high-level API wrapper (or domain-specific language) around some C
library.

 

[M. Edward (Ed) Borasky]

So where is ruby nowadays? For what kind of software would ruby be the
programming language of choice?

Well, certainly Rails is a large part of it, but I would say that the
second biggest "almost-killer-app" for Ruby is in test/behavior driven
development. I haven't looked very hard, but I don't know of anything
that comes close to RSpec that is written in another language.

Another area where I think Ruby is the language of choice is when you
need to create an "internal" domain-specific language. It used to be if
you wanted to do something like that, you pretty much had to use
Lisp/Scheme or Forth, and in many cases require your users to adapt to
Lisp/Scheme parenthesized prefix or Forth postfix notation.

 

[Bryan JJ Buckley]

I have only used ruby for writing little scripts. Things that are
typically done using Perl/awk/bash... Ruby has the potential for much
more, but there doesn't seem to be a problem domain where it truly
excels. Maybe Rails, but that's a bit controversial (would it carry
large websites like Amazon or Facebook?).

Rails carries Twittr, apparently, and that's pretty huge - there are
plenty of examples of high volume Rails sites (shameless plug:
traveliq.de, is one German example). It scales better than people
generally seem to think, and it's (arguably) infinitely easier to
maintain large well-written Rails apps than those written in some
other configuration-heavy frameworks. Rails isn't perfect, but God
knows Struts aren't either.

On the client side Javascript seems to be the big winner. It is the
plugin language for Firefox, and in the future it may even become a
standard choice for desktop software development (with Adobe Air).

Client-side ruby (in the context of the web) doesn't really make much
sense, and it's usually safest to assume that the ubiquitous
browser-embedded technology is Javascript. But conversely, despite
Netscape's hard work, server side Javascript is pretty rare.

So where is ruby nowadays? For what kind of software would ruby be the
programming language of choice?

Choice is a big word. Ruby would be my choice for any application
where I didn't rely on an end-user to already have it installed. This
includes server-side web apps, internal tools such as build systems,
and large user-applications where bundling a Ruby with the
distribution wouldn't seem like overkill. If you're more comfortable
in another language, then that should be your choice. Or if you can't
find a Ruby binding to a required library (and don't want to write
one), then go with a language for which such a binding exists. And if
you're writing an inter-continental ballistic missile launch
controller, just make sure you have every line of code tested.

 

[Marc Heiler]

Ruby has the potential for much more, but there doesn't seem to

be a problem domain where it truly excels.

Any place perl is used, ruby beats it with ease.

Personally I never understood people who claim to use the right tool for
the right job is the proper thing - and using 20 different solutions to
achieve this with archai unix solutions.

On the client side Javascript seems to be the big winner.

Ruby as a language - including practical and from a language design
point of view - beats Javascript every time.

That Javascript is a web-browser language only is a huge disadvantage. I
have yet to see gtk widgets in Javascript. In ruby, piece of cake.

It is the plugin language for Firefox, and in the future it may
even become a standard choice for desktop software
development (with Adobe Air).

In the future it might conquer the world, but ruby is a better choice
until that day. And when that day comes, I want to use ruby instead of
javascript, even if this means that only other people who have
ruby can "benefit" from it - I guess writing perl or php can be
more annoying than writing in javascript, but javascript soon follows
these languages.

 

[Robert Dober]

On Mon, Jun 23, 2008 at 4:50 AM, Michael T. Richter

Personally I prefer JavaScript's prototype object system over Ruby's ... Agree 100%
pretty damned odd hybrid system. Ruby's singleton classes, for example,
look to me an awful lot like a kludge hacked on to give capabilities that
come out of the box for prototype-based systems.

Although I feel "damned odd" exaggerated, I guess people are pretty
much aware of the shortcomings
of mixins and traits were not around when Ruby was created. When it
comes to singleton classes I rather
like them, but you are right that they would not be needed in a
prototyped class system and neither in
a traited system as long as traits are allowed to be applied to *any* objec=
t.
Now I see the advantage of traits over prototypes in the simple,
single feature of conflict resolution.

That Javascript is a web-browser language only is a huge disadvantage.

I humbly submit that you haven't seen them because you've allowed prejudi= ce
to make you not look for them. It took me less than five minutes of
googling and hitting links to find the above stuff.

Good point Michael but would you mind sharing the links ?

Cheers
Robert


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

---
Les m=EAmes questions qu'on se pose
On part vers o=F9 et vers qui
Et comme indice pas grand-chose
Des roses et des orties.
-
Francis Cabrel

 

[Robert Dober]

On Mon, Jun 23, 2008 at 3:10 PM, Michael T. Richter
you probably did and I missed it, thx for reposting them.
Cheers
Robert

 

[David Masover]

I have only used ruby for writing little scripts. Things that are
typically done using Perl/awk/bash... Ruby has the potential for much
more, but there doesn't seem to be a problem domain where it truly
excels. Maybe Rails, but that's a bit controversial (would it carry
large websites like Amazon or Facebook?).

Answer: It already does, to some extent.

The trick is, first of all, programmer time is more important than
performance. If you can throw another ten servers at a problem instead of
another ten developers, that is a massive win.

And second, Rails is designed to encourage a share-nothing style of app, which
makes it horizontally scalable. That means you can actually just throw more
hardware at the problem. Obviously, it's more complex than that in practice,
but nothing as big as Amazon or Facebook will ever work without being
horizontally scalable.

On the client side Javascript seems to be the big winner. It is the
plugin language for Firefox, and in the future it may even become a
standard choice for desktop software development (with Adobe Air).

That hasn't happened yet. Until it does, we still have things like Shoes for
true desktop apps, and various tweaks to get Ruby into JavaScript. There's
already IronRuby, for .NET, which means you could theoretically use Ruby in
Silverlight, and I'd be surprised if no one ports Ruby to Tamarin, which is
the bytecode engine used for Javascript/Actionscript in Flash (and in future
versions of Firefox).

For what kind of software would ruby be the
programming language of choice?

Anywhere I can -- I like the syntax. What I would ask is, for what kind of
software would ruby _not_ be suitable for?

I have three answers:

First, anywhere that you can't actually run Ruby right now. For now, it's
better to write the client side of a web app in Javascript -- but that's no
reason the server side can't be Ruby.

Second, anywhere performance on a given set of hardware is important. You
might well write a word processor or a spreadsheet in Ruby, but you probably
wouldn't write a fast-paced first-person-shooter in Ruby -- at best, you
might use Ruby to script it, once the engine has been written in C/C++. And
many embedded controllers would physically not be able to load the Ruby
interpreter, let alone an app.

And third, anywhere you actually need to work at a low-level -- in C or ASM.
Things like bootloaders, device drivers, and bytecode compilers are probably
not practical in Ruby -- and this is also generally an area where #2 applies
as well. (If you want the game to run fast, the video driver must be fast as
well.)

As a side note, if a project has a very tight deadline, it might make sense to
use whatever currently has the libraries you need. If something exists on
CPAN, but not in Rubygems, you'll be using Perl. But that's mostly related to
#1 -- things Ruby hasn't been ported to, or things which haven't been ported
to Ruby.

What does that leave?

Quite a lot, actually. I plan to write a filesystem in Ruby. It doesn't need
to be fast, as I know for a fact that the underlying medium will be very slow
(recordable DVDs) -- and I can use the Ruby FUSE bindings.

 

[M. Edward (Ed) Borasky]

The trick is, first of all, programmer time is more important than
performance. If you can throw another ten servers at a problem instead of
another ten developers, that is a massive win.

For some business models, this may be true. In general, it is not. If
you do not pay attention to performance in your design process, then
your "ten developers" are not earning their keep.

 

[John Joyce]

For some business models, this may be true. In general, it is not.
If you do not pay attention to performance in your design process,
then your "ten developers" are not earning their keep.

Basically, Ed is spot on with this.
While there are some cases where more hardware is a more practical
solution than more programmers, good programming will rule the day
most of the time. (microsoft is the exception that comes to mind
most...)

While there are lots of things that "work", sensible software design
decisions will always be better decisions.

Think about systems engineers... they're almost always going to choose
software performance.

 

[Mike McKinney]

[Note: parts of this message were removed to make it a legal post.]

systems engineers (or anyone asked to choose software) usually go with a
nice combo of performance and "reputation" of the vendor/software... in big
(gov) shops, rep wins A LOT.

On Sat, Jun 28, 2008 at 5:43 PM, John Joyce <

 

[ara.t.howard]

So where is ruby nowadays? For what kind of software would ruby be the
programming language of choice?

anything which requires high level abstraction - ruby is easily in a
hand-full of languages which allow the programmer to reason over
complex problem domains with a significantly lower mental effort.
anytime you have a hard problem it's good to start in ruby - if you're
lucky you can stay there.

a @ http://codeforpeople.com/