I love Ruby - But how bright is Ruby's Future?

Ruby
101

“I then jumped into Ruby(a whole lot of fun!) but I don’t get the warm
and fussies about
Ruby’s lasting power.”

Going back to the original poster’s “problem”, I think we have to ask
him which kind of “lasting power” he is talking about. Will somebody
still be using it twenty years from now, or will it become a hotbed of
job opportunities in the near and longer term future?

A tale of two languages…
Forth and C both came onto the scene around the same time (more or less

  • work with me here).

I don’t think anyone would try to convince you that Forth is or has ever
been a good way to make a living, but as a quirky, interesting,
portable, dare I say it “fun” language, it has stood the test of time in
the sense that almost any platform you can think of almost immediately
upon creation has a forth interpreter and a small following. It clearly
has “lasting power” of a sort. I think it would be easy to make the
case for Ruby having this type of lasting power. It too is quirky and
“fun”.

C, on the other hand, quickly and somewhat permanently became the
defacto standard against which other newcomers have to battle for a
place in the mainstream. Is it fun? Hardly. What is it about C that
allowed it to gain such a foothold that it is still such a player twenty
years later?

Answer that, and apply those criteria to Ruby and perhaps you will have
an answer to Ruby’s potential for the “other kind” of lasting power.

Does Java have that type of lasting power? I think not. I think it has
a third kind of lasting power that is shorter lived. Inventor Dean
Kamen recently spoke at our company. He likes to talk about how the
bulk of “technology” is expended in an effort to “solve existing
solutions”. In other words, a course of action is chosen hastily, and
then years and years of effort go into solving the shortcomings inherent
in the path that was chosen. Dean likes to think of himself as a guy
who comes in and points that out and gets people to consider a new
solution to the original problem rather than “solving the solution”. I
believe that Java was marketed well and quickly adopted. In the ensuing
several years, while it has become somewhat ubiquitous, most of the
effort has gone into developing huge piles of technology to wrap it in
that solve some of it’s problems.

Who knows, maybe Ruby will turn out to be a better solution to the
original problem; while those who are experts at solving Java solutions
will continue to be well employed for years to come just as COBOL
programmers were (are?) - simply because it was so widely adopted by the
business people it was marketed to.

Another important question might be “Can I find enough work that it will
be practical for me to enjoy making a living with a new and better
solution rather than by solving the old solution”? I know which kind of
development I would rather do. :slight_smile:

jp

102

Matthew S. wrote:

I actually pointed towards Paul Graham earlier in the thread, though
not about Arc in particular. I’ve been watching Arc for a while, and
I think I’ll reserve judgement until it actually appears. My bet is
that PG’s been sidetracked by the spam issue in much the same way that
Knuth got sidetracked by TeX while writing the Art of Computer
Programming.
Email spam doesn’t bother me nearly as much as the endless barrage of
junk that is delivered to my regular residential mailbox, over half of
which needs to be shredded to prevent identity theft. Benjamin Franklin
must be rolling over in his grave about now.

Dennis Ritchie, Bjarne Stroustrup, and James Gosling (and their
colleagues and collaborators) may disagree with your assertion that
they are ‘businesses’ rather than ‘people’.
I suppose, but they designed C, C++ and Java with business projects in
mind, rather than for the pure joy of it or as an academic exercise.
APL emerged out of Harvard’s proto-CS department (not really a
business), though the name of its creator eludes me.
Kenneth Iverson. My recollection was that he was an IBM employee at the
time he invented APL … I was an IBM employee at the time and I
distinctly recall him visiting our labs touting it and looking for a
project to bring it to life. Said project later became known as APL\360,
a product that was licensed.
I’d also be willing to bet that there was an individual at IBM
directly responsible for designing Fortran (though this hunch is based
more on the nature of Fortran and the size and nature of the industry
at that point in history than any concrete knowledge).
John Backus and a team of about five or six others whose names escape me
at the moment. Fortran I had been superseded by Fortran II by the time I
got to IBM (1962). Fortran I was pretty much an IBM 704 macro assembler
with arithmetic statements (FORmula TRANslation) added on. An amazingly
primitive language. Now that I think of it, FORTRAN saw the light of day
in 1956, which means we should be celebrating its 50th birthday this
year!!! Again, a project motivated by a commercial interest.

This was exactly the point I’m trying to make: if a business wants
something which conforms to their needs, they need to directly invest
in the process of its creation. Such as by hiring people like those
listed above to design languages.
In the “good old days”, language design was in a certain sense
subservient to the then-onerous task of compiler writing. As I said in
another post, compilers sucked back then, and serious programmers could
out-code them not only in terms of execution speed but also in terms of
time to completion of the software. If you think compilers sucked,
compiler-compilers really sucked. :slight_smile: Languages had to be easy to
compile or nobody used them.

And the phrases we toss about today in discussing Ruby –
meta-programming, domain-specific languages and automatic programming –
were all part of the vernacular in “the good old days”.

Their contribution to projects like Ruby (or even Java, if you include
its community process) has always been the marginal one of providing
incidental employment to people who made direct contributions in their
spare time.
Uh … OK … but I don’t consider my employment as a performance
engineer “incidental”. Maybe the Swiss Patent Office provided
“incidental employment” to Einstein while he was pondering the
photoelectric effect and relativity. I don’t think of the role John
Backus played at IBM as “incidental employment”.

That marginal contribution has recently been dropping in importance
for a number of reasons, so it really shouldn’t surprise these
businesses that projects to which they make essentially no
contribution don’t really reflect their needs.
Well … I think you’re understating the contribution of businesses to
the “open source community”. They contribute because it’s good business
to contribute, not because they feel guilty about using, say, Linux,
which was developed by a community. I don’t know how it is with Ruby,
since I’m a newcomer to Ruby, but the other open source communities I
hang out in don’t have any trouble getting contributions from business.

–
M. Edward (Ed) Borasky

103

Would it be correct to characterize your thinking, to a first approximation,
as the following? “Corporate IT has no use for Ruby and Ruby has no use for
corporate IT. Everywhere else, Ruby is booming and will continue to do so.”

No! My thinking is that you need to write good code!

My thinking is that this entire question is completely irrelevant and
– as I said before – it’s much more important to think about your
future than the future of any given language.

My thinking is that the question does not matter at all. It’s like
asking whether penguins prefer to sing opera in the key of G or F#.
The question probably can’t be answered and even if it could its
answer would not be useful to anybody.

It just doesn’t matter.

Ruby was beautiful before Rails. Now it is beautiful and popular. If
Rails fades away, Ruby will still be beautiful. That alone is reason
enough to code in it.

The corporate/business distinction is an interesting question but it’s
got nothing to do with my opinions on the matter. I brought it up
because it’s a logical differentiation that you appeared to have
overlooked. But my own position, I stated it earlier: write the best
code you can, find the best customers you can, and ignore everything
else because life’s short.

104

wanted plug-and-play code by and for plug-and-play coders. Instead of
looking to see how to best build a business, people were looking mostly
to preserve what they had, and would pick the safest choices to cover
their asses. (I.e., “Best practices: Adequate choices that probably
won’t get you fired.”)

So, it may be good if companies adopt Ruby, but if they end up
dictating, for example, that every Web app must use Rails, even if
their developers can offer better alternatives, then the fun can fade.

Yeah - this kind of mindset jeopardizes quality in exchange for
minimizing accountability. It’s the anti-risk mindset. It’s a mindset
that says “stay out of trouble,” for the sake of job security. It’s a
mindset that leads to bad code.

105

On Jun 9, 2006, at 5:32, M. Edward (Ed) Borasky wrote:

Backus played at IBM as “incidental employment”.
I have a hunch that I haven’t been clear enough - it seems like we
agree at the basics, so I’ll try and restate it. I have nothing
against commercial motivation or business in general. What I do
recognise is that there are many different classes of business when
it comes to their contributions and attitudes to software
development. So let me explain what I mean by ‘incidental’
employment: if I’m working on some project in my own time, my
employment (no matter how interesting it is in and of itself) is
incidental to that project (and vice-versa). Implicitly, there are
any number of jobs that I could have which would contribute equally
to my other project.

Now, my employer can be said to be contributing to that project,
since they’re supporting me while I undertake that (unpaid) project,
but it’s a pretty marginal contribution. I wouldn’t suggest that
Backus’ contributions were incidental to his role at IBM at all,
while I’m not a party to his job description, it seems likely that he
was employed specifically to make contributions like that.

I think I should emphasise the fact that I’m not really talking about
the IBMs and Suns of the world; companies who are in the business of
creating tools like Fortran and Java. They, rather obviously, are
busy directly producing software tailored to their (business) needs.

I don’t know how it is with Ruby,
since I’m a newcomer to Ruby, but the other open source communities I
hang out in don’t have any trouble getting contributions from
business.

That’s exactly what I’ve been trying to say, along with the notion
that not all businesses are the same. The result of this is that the
people involved don’t have to pander to the traditional notion of
“business acceptance” in order to get contributions and support,
because there’s another class of business which doesn’t apply the
usual criteria that “business acceptance” normally implies.

I think that’s a brilliant situation, and only hope it expands. It
provides a much broader spectrum of employment for programmers, which
can’t be a bad thing, and is changing the way that business invests
in software in a way that allows for much more flexible development
priorities, and a process where technical concerns have a bigger
place at the table than risk aversion. The risk aversion implied by
“business acceptance” (as I went into earlier) leads businesses to
adopt less technically-sophisticated methods and prefer a relatively
de-skilled type of commodity programmer - something I doubt anyone
particularly wants to be.

What I particularly dislike is the notion that unless project X
obtains this ethereal state of “business acceptance” that there’s no
way it can be used to make money - you’ve pointed out it’s not true,
I’ve pointed out it’s not true, but people still say things like
this: “It may be that [without business acceptance] Ruby’s future is
all about projects that are undertaken for love, not money.”[1] and
insisting that being used in mainstream corporate work is the all-
singing all-dancing holy grail for a software project.

matthew smillie.

[1]I love Ruby - But how bright is Ruby's Future? - Ruby - Ruby-Forum

106

Jeff P. wrote:

Forth and C both came onto the scene around the same time (more or less

  • work with me here).

In the microcomputer world, there were decent Forth interpreters long
before a C compiler worthy of the name existed. The competition was
between Basic and Forth, not C and Forth. :slight_smile:

I don’t think anyone would try to convince you that Forth is or has ever
been a good way to make a living, but as a quirky, interesting,
portable, dare I say it “fun” language, it has stood the test of time in
the sense that almost any platform you can think of almost immediately
upon creation has a forth interpreter and a small following. It clearly
has “lasting power” of a sort. I think it would be easy to make the
case for Ruby having this type of lasting power. It too is quirky and
“fun”.

Forth is an excellent way to make a living in the niche it occupies,
embedded systems. It’s interesting that you link Forth and Ruby this
way, though, because Ruby is much more frequently compared with Lisp
(another fun language in a much deeper way) than Forth.

Speaking of Forth, I dragged out my gForth/VMgen documentation today,
spurred on by the discussions here about virtual machines and core Ruby
performance.

I don’t think Ruby is quirky at all – not alongside Forth, Lisp, or
APL. Ruby is Java done right. :slight_smile:

C, on the other hand, quickly and somewhat permanently became the
defacto standard against which other newcomers have to battle for a
place in the mainstream. Is it fun? Hardly. What is it about C that
allowed it to gain such a foothold that it is still such a player twenty
years later?

It was the first “portable assembler”. If you were at all careful about
big-endian versus little-endian, once all the 12-bit, 36-bit, etc.
architectures and bizarre non-IEEE floating point formats got flushed
out of the marketplace, it was possible to write efficient portable code
in a high-level language and have the compiler do the heavy lifting. I
don’t program in C, but I suppose I should. :slight_smile:

Answer that, and apply those criteria to Ruby and perhaps you will have
an answer to Ruby’s potential for the “other kind” of lasting power.

I don’t see why it can’t be as efficient as any dynamic language. But
you’re always going to have the interpretation overhead, so, like Lisp,
a compiler needs to evolve into the Ruby run-time environment.

Does Java have that type of lasting power? I think not.
I was originally attracted to Java because of “write once, run
anywhere”. Back then, “anywhere” was Windows, Solaris and half a dozen
other breeds of UNIX, including Tru64. Now “run anywhere” is Windows,
Linux and I guess Solaris, although I haven’t touched a Solaris box in
so long I’ve forgotten what was so special about them. I wrote one piece
of software in Java, defying a couple of managers in the process. It
never got used. It sits in CM today. I should have written the damn
thing in Perl and released it as open source. :slight_smile:

Oh, yeah … one more thing. This may be the wrong thread to bring this
up, but it’s certainly the right forum. I’m tired of hearing “Ruby
programming is fun, and programming in other languages isn’t.” I’ve
programmed in macro assembler, Fortran, C, Lisp, Pascal, Forth, Ada,
Perl, Java, Awk, R, Neliac, APL and even some microcode. It’s all been
fun! Even the microcode … even the Neliac.

Then again, I’ve never programmed in C++ or worked on a project as a
junior member of a 1500-person team. :slight_smile:

M. Edward (Ed) Borasky

107

Elliot T. wrote:

but don’t always know how to, or notice the repetition. ruby helps us
notice it, and avoid it. sometimes ruby helps us avoid it without even
noticing anything has happened. this could increase the subjective fun
factor of ruby, because we find ourselves writing better, DRYer code.
Somebody has to do the tedious jobs. Our preference as programmers is
to automate them, of course. I’d like to semi-challenge a couple of your
frames, though:

  1. “If you’re being paid to do something, you have to do it reasonably
    fast.” Sure, we have to meet deadlines, but if you can’t ask for more
    time to get correct results, I don’t care what language you’re using …
    fun just disappeared by definition.

  2. You can usually write a code generator very quickly in almost any
    language. Regular expressions make it easier; so do compiler-compilers
    if you know how to use them.

similarly, by being higher level than some languages, ruby sometimes
helps us to write complex, interesting algorithms.
I think most of today’s languages allow recursion, iteration, control
flow, and some form of object-oriented design, although the details of
the object paradigms are widely different in Ruby and, say, R or CLOS.
What I see as Ruby’s main advantages are

  1. Scripting language features: interpreted, dynamic typing
  2. “Conventional” object design paradigms: classes, methods,
    message-passing
  3. Built-in data structuring and regular expression handling.

Perl has 1 and 3 but falls short on 2. Objects were tacked on to Perl
and it shows. Java has 2 and 3 but falls short on 1. R has a little of
1, an unconventional but highly useful (for its domain) set of object
paradigms, and some of 3. C has none of these and C++ only has 2.

ruby is prettier and less verbose than some languages. hitting extra
keys on the keyboard is a form of needless work/repetition. pretty and
elegant code seems fun to me.
There are different kinds of elegance. I find elegance in Forth’s
threaded inner interpreter, Lisp’s macros, selectors, constructors and
predicates, APL’s array orientation, Perl’s arrays and hashes, and
everybody’s garbage collection. And, of course, given how long I’ve
been programming, I find immense joy in the simple fact that I now have
both upper and lower case letters at my disposal. :slight_smile:

if we can still read our code a month later, maybe that’s fun. if we
can read our code to our girlfriend because it’s so much like English,
maybe that’s fun.
OK … again it seems that the programming practices and styles are what
makes programming fun or not fun, not the language.

–
M. Edward (Ed) Borasky

108

On Jun 9, 2006, at 8:10 PM, M. Edward (Ed) Borasky wrote:

Then again, I’ve never programmed in C++ or worked on a project as a
junior member of a 1500-person team. :slight_smile:

there are things that make coding more or less fun. maybe all coding
is more fun than flipping burgers. but not all coding is equally fun.
here are a few thoughts:

if you were required to use copy/paste as a replacement for methods,
that would get annoying quickly (if the methods take arguments, just
edit the paste by hand each time to use the right value :slight_smile:

ultimately, any technique with unnecessary repetition can get
frustrating when you know better ways to accomplish the same task.

ruby does a good job of helping us avoid repetition. it’s always
possible in other languages (at least if you count code generators).
but in ruby it’s often convenient. and if you’re being paid to do
something, you have to do it reasonably fast, so you can’t write a
code generator to avoid a little copy/pasting.

also, a lot of us aren’t perfect. so we’d like to avoid repetition,
but don’t always know how to, or notice the repetition. ruby helps us
notice it, and avoid it. sometimes ruby helps us avoid it without
even noticing anything has happened. this could increase the
subjective fun factor of ruby, because we find ourselves writing
better, DRYer code.

similarly, by being higher level than some languages, ruby sometimes
helps us to write complex, interesting algorithms.

ruby is prettier and less verbose than some languages. hitting extra
keys on the keyboard is a form of needless work/repetition. pretty
and elegant code seems fun to me.

if we can still read our code a month later, maybe that’s fun. if we
can read our code to our girlfriend because it’s so much like
English, maybe that’s fun.

– Elliot T.