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

I've been trying to pickup Ruby for a few months now. I've written a few
good programs that help me at work with SAN/Unix Administration. I've
also run into a few dificult(for me) programming problems. I like to
figure things out on my own so I never post questions in forums like
this, this probably contributes to my bad programming skill, but that's
besides the point.

I'm at a point where I'm asking myself if it is worth the trouble for me
to learn Ruby. How many people are really writting Ruby? Are there any
truly robust, good applications being written in Ruby? How well are Ruby
libraries being maintained? I know there is a lot of documentation for
Ruby but I find it hard to find very specific docs. Python seems to have
a whole lot more doc and many more books exist for Python. Does Python
have a greater following. I love Ruby but I don't want to waist my time
with a laguage that may not have a future.

I don't really care about learning 10 programming languages. My brain
wouldn't be able handle it. I want to learn 1 or two languages and learn
them well.  I know Pascal very well, I know Perl pretty well, now I
would like to get away from Perl and so I started out leaning Python. I
think Python is ugly and not very fun to write. I then jumped into
Ruby(a whole lot of fun!) but I don't get the warm and fussies about
Ruby's lasting power.

On Jun 4, 2006, at 10:09 PM, Hector wrote:

> time
> Ruby's lasting power.
Have you seen the press on Ruby On Rails?
  Linux Journal
  Business Week
  Wired
  News Week
  ...and many others

It is certainly a hot topic now.

And, others are talking about Ruby (the Language) now.
Leo Laporte talks about it on his KFI The Tech Guy show - says it's
his favorite language.
Plus it is used in almost every major corporation - whether they know
it or not.

The press hype may die down, but the infrastructure that is being
built (and the fact that people like the language) pretty much secure
Ruby's existence for some time to come.

Relatively speaking, it is new compared to Python. That is most
likely the reason
that there is less documentation. But, there are about 20 books
poised for
publication on Ruby and Ruby on Rails.

Stay tuned, you have made a good choice.

Jim Freeze

On 6/4/06, Hector <dummy@tracatran.com> wrote:
> libraries being maintained? I know there is a lot of documentation for
> Ruby(a whole lot of fun!) but I don't get the warm and fussies about
> Ruby's lasting power.

Python probably does have a greater following, but is that the
deciding factor?  Java has a bigger following than Python, and I'm
fairly sure that C can beat Java on that.  If 'largest following' were
everything, we'd all still be listening to ABBA or the Village People
(thank God we aren't).

Does it matter?

If Ruby helps you with something today, odds are it can help you with
something tomorrow.  If there's never another release, will that
change that fact?

If you like what it does now, use it now.  If you like the next
upgrade (if there is one), use that.  If not, contintue to use it as
it is.

If you don't like it does now, well then, why would you care what it
does in the future (for that matter, why would you ask the question)?

In a nutshell (or any shell of your choosing), Ruby is what it is.
You either like it, or you don't.  Let that decide whether you use it
or not.

NOT Posted via http://www.ruby-forum.com/.

On 6/4/06, Hector <dummy@tracatran.com> wrote:
> I've been trying to pickup Ruby for a few months now. I've written a few
> good programs that help me at work with SAN/Unix Administration. I've
> also run into a few dificult(for me) programming problems. I like to
> figure things out on my own so I never post questions in forums like
> this, this probably contributes to my bad programming skill, but that's
> besides the point.

It never hurts to ask.  If you're running into some roadblock that's
keeping you from getting work done, chances are someone else ran into
it previously and you're likely to ge an answer in an hour or two on
this forum.

> I don't really care about learning 10 programming languages. My brain
> wouldn't be able handle it. I want to learn 1 or two languages and learn
> them well.  I know Pascal very well, I know Perl pretty well, now I
> would like to get away from Perl and so I started out leaning Python. I
> think Python is ugly and not very fun to write. I then jumped into
> Ruby(a whole lot of fun!) but I don't get the warm and fussies about
> Ruby's lasting power.

Actually, you should never get complacent about a language's 'lasting
power'.  Always be ready to learn a new one.

To address your question:  I've been programming in Ruby since early
2001.  Back then it was like pulling teeth to convince management to
let you use it.  First you had to educate people as to the existence
of Ruby and then you had to educate them as to it's capabilities,
stability, viability, etc.  Had you posted your question back then you
would have probably gotten a lot of answers that told you not to worry
about 'lasting power', if Ruby's doing the job for you then go ahead
and use it (and that's still good advice).

Fast forward to 2006: Last week I decided that I wanted to generate
some C++ files from some XML files using Ruby/REXML.  That meant that
Ruby had to be part of the build process and environment.  A few
emails were sent and some discussion ensued with the result being that
by the next day Ruby was now part of our build environment.  People in
the group keep coming to me and asking what's the best way to learn
Ruby (if they don't already know it). I've already seen PickaxeII
books appearing on people's desks.  People have either heard of Ruby
and would like to learn it, or they have already started learning it.
It's a big change from 2001.  Your question had a lot more validity
back then, but now it's not really an issue.

Ruby is now mainstream; time to learn Io ;-)

Phil

On Jun 4, 2006, at 11:09 PM, Hector wrote:
> for me
>
> I don't really care about learning 10 programming languages. My brain
> wouldn't be able handle it. I want to learn 1 or two languages and  
> learn
> them well.  I know Pascal very well, I know Perl pretty well, now I
> would like to get away from Perl and so I started out leaning  
> Python. I
> think Python is ugly and not very fun to write. I then jumped into
> Ruby(a whole lot of fun!) but I don't get the warm and fussies about
> Ruby's lasting power.

The first thing I'd say here is that Ruby just got the cover of both
Dr. Dobb's and Linux Journal, which is a pretty big statement of how
far it's reaching.  Can't say the same for many languages.  As for
materials, it's worth it to note that (1) Python's a little older,
(2) Ruby started in Japan so there's a lot of Japanese documentation
out there that hasn't been translated yet.

But I think the most important thing you should note is how much fun
you have programming in Ruby.  If you're enjoying it, you can trust
that a lot more other people do too.  And that's a REAL "killer
app".  (David Heinemeier Hansson of ruby on rails talks about
happiness a lot in this respect)

-Mat

Mat, your statements are right on the money. To the extent that 
developers
enjoy using a language, they will use it, when they are at liberty to
choose. But I think it's important not to lose sight of the fact that
programmers in corporate environments are not always free to so choose. 
The
Ruby community has some way to go in meeting the desiderata of the 
relevant
decision makers who are not developers and for whom the joy of 
programming
is a secondary concern. The degree to which we embrace this challenge as 
a
community will have a lot to say about whether we will be able to use 
our
favorite language in more and more places.

Many capable Rubyists that I know are of the opinion that nothing 
matters
but the joy of programming Ruby. True enough as far as it goes, and that
alone will drive significant acceptance of the language. But not as fast 
or
as far as I would like. I realize I'm throwing down a gauntlet here, but 
the
Pythonists have been better at this than we have so far.

On Jun 5, 2006, at 9:14 AM, Francis Cianfrocca wrote:
> Many capable Rubyists that I know are of the opinion that nothing  
> matters
> but the joy of programming Ruby. True enough as far as it goes, and  
> that
> alone will drive significant acceptance of the language. But not as  
> fast or
> as far as I would like. I realize I'm throwing down a gauntlet  
> here, but the
> Pythonists have been better at this than we have so far.

Not sure what "this" is.  Corporate acceptance?
-Mat

I'm still new to the language myself, but I'm comming at it as an 
enterprise
web developer (Java/.Net).

The killer app for Ruby, for me at least, is Rails. Rails has got so 
much
right with regards web development it makes you question how Sun got it
quite so wrong... or at least not as good. However, I can't see big JEE
houses switching to Rails any time soon.

There are two aspects of Ruby that destroy Rails for enterprise 
computing.
The good news is, that they are both fixable.

The first is performance. Ruby might be the same age as Java, but Java
developers are 10 a penny and that means that Ruby is more expensive, 
both
in terms of the hardware required to run it, and people required to 
develop
it. In order for it to get its foot in the door it needs to massively 
reduce
its TCO.

If Ruby's performance could get close to Java then the reduced 
development
costs would be enough to justify the risk of taking on another new 
language.
The most obvious way of doing that is to compile it. I know there are
projects to do this already to CLI, bytecode and machine code. My two 
cents
is that Ruby should aim for something like Obj C or LISP: native code 
with a
heavy reliance on a portable runtime environment.

The biggest mistake I think Ruby could make in this respect is the 
continue
to rely on third party groups to add this much needed functionality. 
Choice
is good, but it makes it even harder for enterprise to latch on to 
something
as they have to sit down and evaluate each solution or worse hire
consultants to tell them which solution to take... shudder.

The second is the effect of soft/duck typing on the IDE. Theology aside,
code completion reduces the learning curve, reduces bugs and increases
productivity. All of these things are a Good Thing (TM). I fully 
understand
that for a complete novice that intelligent IDEs can hinder overall
understanding, but no more than garbage collection - and what high
productivity language would be without that?

Would allowing the language some syntactic sugar to merely decorate an
object with a type, which could be completely ignored by the runtime, 
really
be that much of a bad thing?

I know Ruby isn't necessarily going after the enterprise market, but 
it's so
neat that I think it would be a waste if it didn't.

What makes it so unique is that the syntax scales with the project. No 
one
would routinely write a shell script in Java as they would in Perl, but 
no
one would think that writing a word processor in Perl would be a good 
idea
either. Ruby fits for both... at least syntax does.

On Jun 5, 2006, at 9:35 AM, Tom Marsh wrote:
> development
> costs would be enough to justify the risk of taking on another new  
> language.
> The most obvious way of doing that is to compile it. I know there are
> projects to do this already to CLI, bytecode and machine code. My  
> two cents
> is that Ruby should aim for something like Obj C or LISP: native  
> code with a
> heavy reliance on a portable runtime environment.

Everything I've heard so far points to Ruby having similar
performance to Java, but I'm no expert.  The availability of
programmers is a bit of a catch 22 problem.  But I think the previous
"joy" argument will help fix this to a certain extent.  And the
(IMHO) rest can be covered by lowering barrier to entry, which the
ruby community works on daily.

> The biggest mistake I think Ruby could make in this respect is the  
> continue
> to rely on third party groups to add this much needed  
> functionality. Choice
> is good, but it makes it even harder for enterprise to latch on to  
> something
> as they have to sit down and evaluate each solution or worse hire
> consultants to tell them which solution to take... shudder.

I feel like the ruby community is essentially all third party
groups.  But I agree that a rally behind a particular software
package does make the decision process easier.  I think there should
be a balance.  Diversity is natural.  Java has a wealth of competing
tools, if .Net had a stronger community, I'm sure it would too.

> runtime, really
> be that much of a bad thing?

RDT is making some good headway on code completion.  Personally, I
find that type hinting leads to slower, more bug prone development
because it's one more thing for the developer to think about.  Decent
code completion is possible without adding rigidity to the typing
system.  But I suppose if a particular IDE wanted an easy way to
implement it, they could do it by way of special comments.

> either. Ruby fits for both... at least syntax does.
Personally, I dig the closures.  But that's just me :)
-Mat

Well, you're going to get a lot of....um, "passionate" responses to your
specific points, so I'll keep it high-level. You've made a very good 
case
that corporate IT needs a better programming language, but Ruby isn't 
it.
One way to summarize your argument is that Ruby would be better accepted 
if
it were more like Java in specific ways. But Ruby is fundamentally 
different
from Java in both essence and detail. We still haven't answered this
question: do the things that make Ruby unique qualify it or disqualify 
it as
an enterprise development language? Are corporate developers ready for a
fairly serious change in the way they work? Especially since many of the
younger CS grads have never thought in any language but Java.

If we try to make Ruby an incrementally better Java as a way of driving
corporate acceptance, we'll fail at both goals.

I don't understand what you mean when you say that "syntax scales with 
the
project."

Tom Marsh wrote:
> There are two aspects of Ruby that destroy Rails for enterprise computing.

I personally don't think that Ruby needs to be "enterprise" in order to
have a bright future.

> The good news is, that they are both fixable.

I think there is a temptation for newbies, especially those that are
experienced in other languages (like myself), to want to mold Ruby in
some way that is familiar to them.

Although this is natural, I think trying to keep a beginner's mind is
important, because it will enable one to really learn something new and
appreciate it for its differences without imposing one's experiential
biases.  If I wanted something like Java or .NET, I'd just use Java or 
.NET.

> The first is performance. Ruby might be the same age as Java, but Java
> developers are 10 a penny and that means that Ruby is more expensive, both
> in terms of the hardware required to run it, and people required to develop
> it. In order for it to get its foot in the door it needs to massively
> reduce
> its TCO.

Above you disregard the cost of development itself (and
maintenance/enhancement), which should be included in TCO.

Although I agree that Ruby can be faster, and I'm certain it will be
with YARV/Rite, IME, typically the performance bottleneck is the backend
DB, not the application server.  I'm not in production yet, but right
now, Ruby is fast enough for me.

> If Ruby's performance could get close to Java then the reduced development
> costs would be enough to justify the risk of taking on another new
> language.

Reducing development costs can make a significant difference and there
is risk in playing it safe (i.e. opportunity costs if one believes that
Ruby/Rails will provide a technological advantage).

> The biggest mistake I think Ruby could make in this respect is the continue
> to rely on third party groups to add this much needed functionality. 

Take a look at YARV/Rite.

> The second is the effect of soft/duck typing on the IDE. Theology aside,
> code completion reduces the learning curve, reduces bugs and increases
> productivity. All of these things are a Good Thing (TM). I fully understand
> that for a complete novice that intelligent IDEs can hinder overall
> understanding, but no more than garbage collection - and what high
> productivity language would be without that?

IMO, one cannot separate the "Theology" from the argument.  If one
believes that duck typing improves productivity and the language
overall, then its impossible to remove it from the context of the
discussion.  It's one of the things that makes Ruby, Ruby.

But regardless, I think the tools side is moving forward.  IMO,
ActiveState has a good IDE for Ruby; Arachno is good too.  Although it
doesn't look like an "IDE", Mac users seem to really like TextMate.

My personal opinion is that Ruby shouldn't worry about tools; I
appreciate that the emphasis in the community is less on tools and more
about the language, frameworks, etc.  Tools vendors are smart, IDE's are
a mature discipline, so I have confidence they'll find ways of making
Ruby accessible to newbies.

> Would allowing the language some syntactic sugar to merely decorate an
> object with a type, which could be completely ignored by the runtime,
> really
> be that much of a bad thing?

My initial reaction is: yes, it would be a bad thing.  I trust those
that know Ruby a lot better than me to make decisions about language
direction.

> I know Ruby isn't necessarily going after the enterprise market, but
> it's so
> neat that I think it would be a waste if it didn't.

I personally think it's more important for the Ruby community to be
focused on solving real-world problems than to try to market itself to
anything.

Certainly a real-world problem is: how to get my organization to use
Ruby.  I personally believe there will be business opportunities for
those motivated enough to capitalize on providing Ruby services for the
Enterprise (whatever those things are...).  Book publishing is one
aspect of it, training is another, web hosting, consulting, etc.  I
believe it's happening now and will continue to do so.

Tom Marsh wrote:
> The first is performance. Ruby might be the same age as Java, but Java
> developers are 10 a penny and that means that Ruby is more expensive, 
> both
> in terms of the hardware required to run it, and people required to 
> develop
> it. In order for it to get its foot in the door it needs to massively 
> reduce
> its TCO.

Hi Tom, I just wanted to respond to these two points.

Although no one is arguing against improved Ruby performance, I think 
you overestimate the hardware issues.  I find I am quite comfortable 
developing Rails code on my 6 year old laptop.  However, I wouldn't even 
consider developing a non-trivial Java application on the same hardware. 
Although I'm talking develement and not production deployment, I think 
you will find that true across the board.

Justin Gehtland had some numbers on comparing Ruby performance with a 
similar Java webapp.  You can read about it here: 
http://blogs.relevancellc.com/articles/2005/04/04/some-numbers-at-last 
(looks like relevance has changed their blog software and some of the 
postings lost all formatting ... the words and numbers are all there, 
you just have to read carefullly, sorry).  The summary is that the 
unoptimized versions of the Ruby and Java apps had very similar 
performance, and that it was very easy to tune the Ruby version with 
selective caching options.

The assertion that Ruby cost more in terms of people is an interesting 
one as well.  Although I don't have numbers for myself, Stewart Halloway 
has published some figures for his consulting company.  They offer both 
Ruby and Java services and charge 10% to 50% less for Ruby jobs over 
Java jobs.  And this is after paying Ruby developers more (about 10%).

You can read about Stewart's findings here:

http://blogs.relevancellc.com/articles/2005/12/19/ruby-rails-put-your-money-where-your-mouth-is
http://blogs.relevancellc.com/articles/2005/12/20/bidding-projects-with-ruby-rails-take-2

-- Jim Weirich

I don't think any programming language is guaranteed to run
forever. A programming language is mortal. Consider assembly language.
It was widely used at first, but it was soon surpassed by C. Later,
people started to learn C++ because it is a successor of C and it has
object oriented programming feature. Later, Java stroked the earth.

Recently, Bruce A. Tate wrote a book titled 'Beyond Java.' In that book,
he said that Java may face a death sooner or later, and java programmer
have to consider other alternatives. Interestingly, he took Ruby as an
example. That means that RoR and Ruby certainly seems to be promising.

I agree with you that Python is not fun, but it has lots of users and
documents and websites about it. In fact, 'a good language' does not
imply 'a succeeded language.' Many other factors like community affects
the fate of a language, and python has some strong points that Ruby
doesn't have.

To be frank, I would recommend you to learn C++ or Java if you want to
become an application programmer. If you want to be a system programmer,
C is the best choice. If you care a lot about web programming, I 
recommend
Ruby/Java/.NET. If you want to learn some language which glues well with
existing language like C, C++ and want to write some simple apps, I
would recommend Python.

I myself am learning Python after I finished basic grammars and 
techniques
of Ruby, and I've found interesting posts at comp.lang.python in which
people
talk about Python's future with regard to Java. They also consider Java 
as
fairly prominent while Python's future as murky.

But who knows the future? haha.

Sincerely,
Minkoo Seo

Phil Tomson wrote:
> 
> Actually, you should never get complacent about a language's 'lasting
> power'.  Always be ready to learn a new one.
> 
I don't agree with this statement.

You should look very hard at a language (just like the owner of this 
thread is doing), to make sure you are making the right choice.

Many developers, Project Managers, etc., have lost thier jobs because of 
making the wrong development choice.

Look at Kylix and C++Builder X, they fit the bill when they where 
released, but now people are scrambling to find a replacement (or a new 
job).


I'm also fighting these same concerns.
Here's my list...

1. No native OS threads.

2. To get the fully benefit from Rails, your database has to have a 
specific naming convention. (Makes it impossible to migrate to RoR from 
something else).

3. No generic database drivers built into Rails for databases other than 
the top 3 and open-source databases. (Makes it impossible to migrate to 
RoR if you use a different database)

4. Slow performance.

5. Kind of a hack job to get it to work with Apache. (But this could 
also be my lack of knowledge)


I still love the language, but I do have reservations.

On Jun 5, 2006, at 11:22 AM, ReggW wrote:
> 1. No native OS threads.

I hear this argument a lot.  I do web development, so I rarely worry
about threads at all.  What's the problem here that it makes so many
people's lists?

> 2. To get the fully benefit from Rails, your database has to have a
> specific naming convention. (Makes it impossible to migrate to RoR  
> from
> something else).

You can configure ActiveRecord to a certain extent.  It sounds like
you might want to investigate it more before saying "you have to".
You could also use rails w/o ActiveRecord if you really wanted to.

> 3. No generic database drivers built into Rails for databases other  
> than
> the top 3 and open-source databases. (Makes it impossible to  
> migrate to
> RoR if you use a different database)

I think you're wrong here.  I'm seeing stuff in the rails wiki for
Oracle, SQL server, Sybase...

> 4. Slow performance.

"Fast enough" seems to be the going mantra.

> 5. Kind of a hack job to get it to work with Apache. (But this could
> also be my lack of knowledge)

I haven't had a lot of luck here either.

On 6/5/06, ReggW <me@yourhome.com> wrote:
> Phil Tomson wrote:
>> Actually, you should never get complacent about a language's 'lasting
>> power'. Always be ready to learn a new one.
> I don't agree with this statement.

I'm not sure why you don't agree, because your example (Kylix &
C++Builder) very *much* agrees with what Phil said.

> You should look very hard at a language (just like the owner of this
> thread is doing), to make sure you are making the right choice.

If you're planning on making it your primary programming language, sure.
I don't get to spend a lot of time programming in Ruby with my current
job, but my Ruby has definitely informed and improved my C++ (and
congealed my hate of that language).

[...]

> Look at Kylix and C++Builder X, they fit the bill when they where
> released, but now people are scrambling to find a replacement (or a
> new job).

Actually, neither was a problem, nor are they really problems. Just
because a tool falls out of favour does not mean that the tool was bad
in the first place. Java *will* fall out of favour, just as COBOL has.
That's inevitable. The trick is to be an agile enough to recognise when
something *new* has to be done.

> 1. No native OS threads.

This is less a problem than you might imagine. However, it will be
addressed with YARV/Rite. (In fact, Ko1-san is possibly planning on
making it possible to have Ruby's green threads run on top of OS
threads. Last year's YARV presentation suggested that it might even be
possible in the future for a green thread to migrate across OS threads
for performance reasons.)

> 2. To get the fully benefit from Rails, your database has to have a
> specific naming convention. (Makes it impossible to migrate to RoR
> from something else).

This isn't a Ruby problem. It is, however, still possible to migrate.
You will have to do a little more work, but you *can* override the
defaults for ActiveRecord and once overridden, all of the rest of the
benefits still apply.

> 3. No generic database drivers built into Rails for databases other
> than the top 3 and open-source databases. (Makes it impossible to
> migrate to RoR if you use a different database)

This is more a matter of applicability; if most folks don't need it,
they won't create it. Maybe it would be worth talking to the vendor
about this.

> 4. Slow performance.

This is often claimed, but never conclusively proven in a way that is
generally applicable and generally applicable to the language. Yes, Ruby
has points where it is slow. But performance is not an absolute
measurement; it is a relative measurement. There are definite places to
get improvements from the *language*, and many of these will be
addressed by YARV (which I'll finally be able to play with!).

> 5. Kind of a hack job to get it to work with Apache. (But this could
> also be my lack of knowledge)

I can't answer this, but I suspect that it's a knowledge thing.

-austin

On 6/5/06, Mat Schaffer <schapht@gmail.com> wrote:
>
> On Jun 5, 2006, at 11:22 AM, ReggW wrote:
> > 1. No native OS threads.
>
> I hear this argument a lot.  I do web development, so I rarely worry
> about threads at all.  What's the problem here that it makes so many
> people's lists?


From a web perspective it even has the potential for performance issues.
Because there are no native threads, its very easy for a system call 
(file
or socket handling most commonly) to block the entire Ruby process, not 
just
the current ruby thread.  Thanks to the ease of IPC in Ruby it can be 
less
of an issue, but is definitely something that potentially affects many
people's views of ruby.

> > than
>
> > 5. Kind of a hack job to get it to work with Apache. (But this could
> > also be my lack of knowledge)
>
> I haven't had a lot of luck here either.


Correction, getting RAILS to work with Apache is a pain.  While pure CGI 
or
mod_ruby may have performance issues in many cases, it is far from 
difficult
to set up.  But given the size and complexity of the Rails environment 
it
has significant performance requirements, that go beyond the ability to 
use
CGI or mod_ruby, but that isn't entirely the failing of Ruby.

> Correction, getting RAILS to work with Apache is a pain.  While 
> pure CGI or
> mod_ruby may have performance issues in many cases, it is far from 
> difficultto set up.  But given the size and complexity of the Rails 
> environment it
> has significant performance requirements, that go beyond the 
> ability to use
> CGI or mod_ruby, but that isn't entirely the failing of Ruby.
> 

Hi

I've gotten Rails to work with Apache and FastCGI _VERY_ much without
pain. Getting Tomcat to play with Apache is much harder in my opinion.

/O

On 6/5/06, ReggW <me@yourhome.com> wrote:
> Phil Tomson wrote:
> >
> > Actually, you should never get complacent about a language's 'lasting
> > power'.  Always be ready to learn a new one.
> >
> I don't agree with this statement.
>
> You should look very hard at a language (just like the owner of this
> thread is doing), to make sure you are making the right choice.

It may be years before you know if you've made the 'right' choice.

If you do happen to choose 'wrong' (whatever that might mean for you)
you can always go back and learn another language(s).  It's not like
you're locked into some binding contract or something.

>
> Many developers, Project Managers, etc., have lost thier jobs because of
> making the wrong development choice.
>

Perhaps it's not because they made the 'wrong choice' but more because
they weren't willing to learn new things?

> Look at Kylix and C++Builder X, they fit the bill when they where
> released, but now people are scrambling to find a replacement (or a new
> job).
>

Those are tools, not languages.  If they know C++ well, they'll be fine.


Phil

>>>>>>>Because there are no native threads, its very easy for a system call
(file
or socket handling most commonly) to block the entire Ruby process, not 
just
the current ruby thread.
<<<<<<<<<<<<

Try it. You'll find that your statement is false. There are a lot of 
reasons
why one might want native-thread support in Ruby but not blocking a 
whole
process on a file or socket i/o isn't one of them.

Austin Ziegler wrote:
>ReggW wrote: 
>> Look at Kylix and C++Builder X, they fit the bill when they where
>> released, but now people are scrambling to find a replacement (or a
>> new job).
> 
> Actually, neither was a problem, nor are they really problems. Just
> because a tool falls out of favour does not mean that the tool was bad
> in the first place. Java *will* fall out of favour, just as COBOL has.
> That's inevitable. The trick is to be an agile enough to recognise when
> something *new* has to be done.
> 

It wasn't the tool that failed, but the framework (and of course Borland 
had a lot to do with that).

>> 1. No native OS threads.
> 
> This is less a problem than you might imagine. However, it will be
> addressed with YARV/Rite. (In fact, Ko1-san is possibly planning on
> making it possible to have Ruby's green threads run on top of OS
> threads. Last year's YARV presentation suggested that it might even be
> possible in the future for a green thread to migrate across OS threads
> for performance reasons.)
> 
This is a problem that I'm experincing now.
I'm "trying" to convert an existing app that uses thread to Ruby.

This brings up another issue that I have (and I suspect many other) is 
that I'm always seeing these new names being used. Like YARV/Rite but 
none of this is anywhere on the rubyonrails.org website.

The website doesn't inform you of what is being worked on for the next 
release, actually, the website doesn't inform a person about much of 
anything that is currently going on with Ruby.



>> 3. No generic database drivers built into Rails for databases other
>> than the top 3 and open-source databases. (Makes it impossible to
>> migrate to RoR if you use a different database)
> 
> This is more a matter of applicability; if most folks don't need it,
> they won't create it. Maybe it would be worth talking to the vendor
> about this.
> 

Talk to what vendor?
My database vendor?
And asked them what??

This could be resolved with a out-of-the-box ODBC/JDBC driver as part of 
the different type of databases supported.


>> 4. Slow performance.
> 
> This is often claimed, but never conclusively proven in a way that is
> generally applicable and generally applicable to the language. Yes, Ruby
> has points where it is slow. But performance is not an absolute
> measurement; it is a relative measurement. There are definite places to
> get improvements from the *language*, and many of these will be
> addressed by YARV (which I'll finally be able to play with!).
>

I wish I knew what this YARV is...it sounds like the magic bullet I've 
been looking for. I'll do some research on it later.

Thanks

On 6/5/06, ReggW <me@yourhome.com> wrote:
> This brings up another issue that I have (and I suspect many other) is
> that I'm always seeing these new names being used. Like YARV/Rite but
> none of this is anywhere on the rubyonrails.org website.
>
> The website doesn't inform you of what is being worked on for the next
> release, actually, the website doesn't inform a person about much of
> anything that is currently going on with Ruby.

That's because ror.org is for the Ruby on Rails framework, not an
informative site for the Ruby language itself.  For that, check out
http://www.ruby-lang.org

> I wish I knew what this YARV is...it sounds like the magic bullet I've
> been looking for. I'll do some research on it later.

http://www.atdot.net/yarv/

On 6/5/06, ReggW <me@yourhome.com> wrote:
> It wasn't the tool that failed, but the framework (and of course
> Borland had a lot to do with that).

Um. Has the framework failed, or is it now just that the vendor support
for the tool and framework gone away?

>>> 1. No native OS threads.
>> This is less a problem than you might imagine. However, it will be
>> addressed with YARV/Rite. (In fact, Ko1-san is possibly planning on
>> making it possible to have Ruby's green threads run on top of OS
>> threads. Last year's YARV presentation suggested that it might even
>> be possible in the future for a green thread to migrate across OS
>> threads for performance reasons.)
> This is a problem that I'm experincing now. I'm "trying" to convert an
> existing app that uses thread to Ruby.

Um. Why does your existing app use threads, and does the assumption that
moved you to threads still apply, or may multiple processes with some
form of IPC be better? I wouldn't simply try to do a functional
conversion of an application from any language to Ruby. I'd take it as
an opportunity to reimplement based on what I've learned about how the
application is actually used.

> This brings up another issue that I have (and I suspect many other) is
> that I'm always seeing these new names being used. Like YARV/Rite but
> none of this is anywhere on the rubyonrails.org website.

Nor would it be. Rubyonrails.org is about Rails, not Ruby. Look at
ruby-lang.org and rubygarden.org and the mailing list history[1].
The Rails website will never be about Ruby in general.

> The website doesn't inform you of what is being worked on for the next
> release, actually, the website doesn't inform a person about much of
> anything that is currently going on with Ruby.

This is correct. This is because it's the Rails website, not the Ruby
website. The Ruby website needs a bit more content up-to-date, but I
hope that will change when the new visuals come on-line, too. If you
REALLY want to know what's happening with Ruby's future, join
ruby-core@ruby-lang.org and watch rcrchive.org.

> This could be resolved with a out-of-the-box ODBC/JDBC driver as part
> of the different type of databases supported.

No, it can't. Why can't it? Because if people don't *need* such a
driver, they're not going to *develop* such a driver. I'm sure that the
Rails team would be happy to add other drivers (if there aren't plugin-
hooks for use with RubyGems for such drivers, which is even more
sensible), but it has to be developed first. That's why you talk to the
database vendor and say "You should really look at this Rails thing."
Maybe get *them* to develop the driver for you.

>>> 4. Slow performance.
>> This is often claimed, but never conclusively proven in a way that is
>> generally applicable and generally applicable to the language. Yes,
>> Ruby has points where it is slow. But performance is not an absolute
>> measurement; it is a relative measurement. There are definite places
>> to get improvements from the *language*, and many of these will be
>> addressed by YARV (which I'll finally be able to play with!).
> I wish I knew what this YARV is...it sounds like the magic bullet I've
> been looking for. I'll do some research on it later.

There are no magic bullets. YARV is predicated on Ruby 1.9 and there are
syntactical changes in Ruby 1.9 (which is the development bed for Ruby
2.0).

-austin
[1] You may *think* you're posting to a web forum. You're not. You're
    posting to a mailing list (ruby-talk@ruby-lang.org) over a web forum
	interface. You're dealing with something that has a much longer
	history than Rails.

Tom Marsh wrote:
> I'm still new to the language myself, but I'm comming at it as an 
> enterprise
> web developer (Java/.Net).
> 
> The killer app for Ruby, for me at least, is Rails. Rails has got so much
> right with regards web development it makes you question how Sun got it
> quite so wrong... or at least not as good. 

Sun had a different opinion on how to do Web development.


--
James Britt

"I often work by avoidance."
- Brian Eno

>> Many capable Rubyists that I know are of the opinion that nothing
>> matters but the joy of programming Ruby. True enough as far as
>> it goes, and that alone will drive significant acceptance of the
>> language. But not as fast or as far as I would like. I realize I'm
>> throwing down a gauntlet here, but the Pythonists have been
>> better at this than we have so far.
>
> Not sure what "this" is.  Corporate acceptance?

"This" appears to be resume-padding usefulness.

Two corrections: first, it's Pythonistas, not Pythonists. I don't know
why, but it is. Second, my experience of the two communities is that
while these statements might be perceived as a gauntlet being thrown
down in the Python community, that perception seems much less likely
in the Ruby community.

Anyway -- to answer your main question -- I have a very skeptical,
cynical side which believes that the real question here is "how much
padding will my resume gain if I learn Ruby?" That's such a bad
question. The real benefit in learning a new language is not the
ability to get better jobs but the ability to write better programs.
If you're learning a language simply because it has a bright future,
you're investing your effort in the language's future rather than your
own.

Two of the best languages to learn are Smalltalk and Lisp. Neither one
of these languages has virtually ANY future, but if you learn them,
you will become a better programmer, and YOU will have a brighter
future, because your work will improve. Invest time and energy in YOUR
future. I'm new to Ruby too but one thing I really like about it is
that I'm learning a LOT more from my beginner steps in Ruby than I
learnt from my beginner steps in Python (or indeed at almost any stage
in coding Java).

DHH was able to write in Ruby, even though at the time the language
had no mainstream acceptance. Avi Bryant has an entire company running
on Smalltalk, even though that language has no mainstream acceptance.
Paul Graham sold a company for $40 million after writing every line of
its code in Common Lisp, even though that language had no mainstream
acceptance either (and probably never will). Coding in a language
because it has mainstream acceptance is putting the cart before the
horse.

Good programmers produce business results. Business people don't
understand what the difference is between languages in the first
place. They don't care -- in fact since they can't even tell languages
apart in any meaningful sense, they don't even have the ability to
care. The crappy ones say various things as if they really cared but
the truth is they're just BSing to protect themselves in various
ridiculous corporate environments -- and the truth is you don't want
anything to do with crappy business people anyway. If you produce the
business results, you can use any language you want, and if you don't
produce the business results, you're just screwing around -- in which
case, again, you might as well use any language you want.

Long story short, focus on your SKILL. Focusing on whichever trend is
most popular with corporations at any particular moment is a recipe
for turning yourself into a bad programmer. Don't believe me? Learn
Java!

On Jun 5, 2006, at 10:30 AM, Giles Bowkett wrote:

> Two of the best languages to learn are Smalltalk and Lisp. Neither one
> of these languages has virtually ANY future

Lisp is *the* future :)

(Opinions vary)

The reason these languages are good to learn is they have important
knowledge in them. We want knowledge in our future, don't we?

Elliot

On Jun 5, 2006, at 17:50, James Britt wrote:

> Sun had a different opinion on how to do Web development.
https://glassfish.dev.java.net/

https://phobos.dev.java.net/

There's always something new around the corner, and it always builds
on past experience.  Don't fool yourself into thinking that there are
constant revolutionary changes and "killer apps" for any language.
Java was meant to be its own "killer app" - whither now the Virtual
Machine, making all platforms equal?  They're running on *servers*,
which is almost the exact opposite of the original view of Java.

As for "what language should I use?" I think there are few more
informative essays that one could read than this one by Paul Graham;
it's Lisp-centric in its particulars, but many of the points made can
apply to Ruby as well (even some of the Lispier ones, at a stretch):

"Revenge of the Nerds"
http://www.paulgraham.com/icad.html


Other good ones are:

"Being Popular" - very interesting in light of Ruby's recent surge in
popularity.
http://www.paulgraham.com/popular.html

"LFM and LFSP" - Expands to "Languages For the Masses and Languages
For Smart People", some speculation on what makes languages "fun."
http://www.paulgraham.com/vanlfsp.html


matthew smillie.

On Monday 05 June 2006 11:42, Elliot Temple wrote:
> On Jun 5, 2006, at 10:30 AM, Giles Bowkett wrote:
> > Two of the best languages to learn are Smalltalk and Lisp. Neither one
> > of these languages has virtually ANY future
>
> Lisp is *the* future :)
 ^
(Maybe so, but you're missing an opening parenthesis... ;)

On Jun 5, 2006, at 1:42 PM, Elliot Temple wrote:
> On Jun 5, 2006, at 10:30 AM, Giles Bowkett wrote:
>
>> Two of the best languages to learn are Smalltalk and Lisp. Neither  
>> one
>> of these languages has virtually ANY future
>
> Lisp is *the* future :)

And always will be.... :)

Austin Ziegler wrote:
> On 6/5/06, ReggW <me@yourhome.com> wrote:
>> It wasn't the tool that failed, but the framework (and of course
>> Borland had a lot to do with that).
> 
> Um. Has the framework failed, or is it now just that the vendor support
> for the tool and framework gone away?
>
What's the difference.  Once you have coded to a framework, your code 
will only work with that framework.

So once the support for the framework goes away, you are now stuck in a 
never progressing environment.

That's is why you can't just "jump" into any language just because you 
like it.
Unless you are only doing it as a hobby or working for yourself.


> 
>> This could be resolved with a out-of-the-box ODBC/JDBC driver as part
>> of the different type of databases supported.
> 
> No, it can't. Why can't it? Because if people don't *need* such a
> driver, they're not going to *develop* such a driver. I'm sure that the
> Rails team would be happy to add other drivers (if there aren't plugin-
> hooks for use with RubyGems for such drivers, which is even more
> sensible), but it has to be developed first. That's why you talk to the
> database vendor and say "You should really look at this Rails thing."
> Maybe get *them* to develop the driver for you.
> 

Here is a list of Drivers that people *need* for Rails...
http://wiki.rubyonrails.com/rails/pages/DatabaseDrivers

Approx. 90% of these would go away if they implemented ODBC.

On 6/5/06, ReggW <me@yourhome.com> wrote:
> Here is a list of Drivers that people *need* for Rails...
> http://wiki.rubyonrails.com/rails/pages/DatabaseDrivers
>
> Approx. 90% of these would go away if they implemented ODBC.

Then someone should post a bounty for those drivers. In open source,
people implement what they need or what others are willing to pay them
for.

That, however, isn't a Ruby problem. It's a Rails problem.

-austin

Both you and someone else asked what I meant by saying that the Python
community is ahead of us in some important respects. It didn't haven't 
even
the slightest thing to do with resumes. I'm not sure if you're applying 
your
skepticism and cynicism to your case. You're not applying it to mine. (I
haven't written a resume in 15 years. I used to make my living selling 
my
programming skills but now I'm mostly a buyer of the programming skills 
of
others. I guess that makes me a crappy business person.)

What I meant was that Python has achieved a degree of respectability in
corporate environments that Ruby hasn't yet. And this doesn't happen by
itself, and it certainly doesn't happen just because a language is
particularly well-done or particularly nice for programmers to use. I 
think
you may be underestimating the degree to which technology choices in 
large
organizations are driven by the need to reduce the perception of risk. 
It's
not universally true that a programmer who "delivers the goods" will get 
to
pick his technology.

But the question gets asked here time and again: who cares if people in
corporations don't use Ruby, as long as I can use it on my own projects?
Entirely valid. But if you really like using a language, wouldn't you 
want
to use at work as well as at play? And to get that kind of acceptance 
for
Ruby will take some serious advocacy. With the rise of Rails, that may 
be
starting to happen, but it's too soon to tell.

Because I'm a businessperson, I'm always struck that people would 
question
the value of achieving greater acceptance for anything. Different 
strokes
for different folks, of course. But at some level, I have to think about
protecting the investment that I make in people who learn Ruby while 
working
on my projects, which I've done several times in the three-plus years 
I've
been shipping commercial software written in Ruby. Although I personally
love programming in Ruby and do it whenever I can, your points really 
throw
the larger business questions into relief.

(For the little that it's worth, we shipped a pair of apps in Rails, and
coudn't get past the performance issues, so we now ship web apps in
handwritten Ruby with our own handwritten web servers.)

And to your point about programmers who deliver the goods: I've been
privileged at several times to have some of those magical crazy people
working for me who can deliver almost anything on almost any schedule. 
And
although the sample set is small, those I have known all share this key
characteristic: the programming language DOESN'T MATTER. An individual 
who
really understands software development doesn't pick a programming 
language
to concentrate on. He's productive in anything you tell him to use, and 
he
doesn't particularly care either.

Hector wrote:
> 
> I'm at a point where I'm asking myself if it is worth the trouble for me
> to learn Ruby...
> 
My answer would be yes, not because it is the best language
that will /ever/ be written, but because of the way the
features it has implemented provide an almost unlimited
capacity for future scaling.

That capacity derives from Ruby's ability for
/language extensions/. I wrote at length on that subject
here: http://www.treelight.com/software/ruby/RubyRocks.html

On the other hand, I agree that documentation is an issue.
The situation is getting better, though. (Thank goodness for
Wiki pages!) And there are several great books.

Too, I really miss the kinds of APIs that are generated
for Java, as well as IDEs that interact with them so
nicely.

So my take at the moment is that it can take several hours
to figure out how to do something, but when I finally do,
the solution is small, clean, and elegant.

So Ruby is where Java was in the mid-90's, but without
the huge investment required to market it, document it,
and make technology additions.

But it is hecka fun...
:_)

Francis Cianfrocca wrote:

> An individual who
> really understands software development doesn't pick a programming language
> to concentrate on. He's productive in anything you tell him to use, and he
> doesn't particularly care either.
> 

Wow. That's surreal.

I have a hard time imagining someone who really understands software
development and yet doesn't care if someone dictates what language is
used.  And yet can be (equally, one hopes) productive whether working
with VB, Lisp, Cobol, or Brainfuck.

 > Because I'm a businessperson, I'm always struck that people would
 > question the value of achieving greater acceptance for anything.

Interesting.  I'm always stuck by people who don't get think that
everything is fair game for questioning.


--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine

Somebody mentioned that if you want to do any serious application 
programming you should look elsewhere.  I've also noticed that while 
there are several attempts out there at application frameworks based on 
Ruby, there don't seem to be any that beget any enthusiasm.  Discussions 
of the existing ones are usually of the form "Yeah this one wasn't too 
bad, and the other one was almost adequate".

Since Rails is considered by many to be the "killer app" for Ruby, why 
doesn't there seem to be a contender in the non-web-app type application 
framework genre for Ruby?  Is there something about the language that 
makes it an inappropriate choice for "real" application work, or is it 
more just a matter of coincidence that the right group of people hasn't 
done something as stellar as Rails in that space yet?

I, for one, would fall in love with Ruby all over again if there was a 
truly cross-platform native application framework even half as brilliant 
as Rails.  You could call it "Ruby on 'Roids".

thanks,
jp

Francis Cianfrocca wrote:
> 
> Because I'm a businessperson, I'm always struck that people would 
> question
> the value of achieving greater acceptance for anything. Different 
> strokes
> for different folks, of course. But at some level, I have to think about
> protecting the investment that I make in people who learn Ruby while 
> working
> on my projects, which I've done several times in the three-plus years 
> I've
> been shipping commercial software written in Ruby. Although I personally
> love programming in Ruby and do it whenever I can, your points really 
> throw
> the larger business questions into relief.
> 

Well said...I totally agree !!

On Jun 6, 2006, at 2:42, James Britt wrote:

> > Because I'm a businessperson, I'm always struck that people would
> > question the value of achieving greater acceptance for anything.
>
> Interesting.  I'm always stuck by people who don't get think that  
> everything is fair game for questioning.


It's worth questioning, because what does "acceptance in industry"
mean for a language?

In my view, it means "average".

It means "Nobody ever got fired for picking X" (canonically, of
course, X=IBM).

It means crunch-time, late nights, and all of the Mythical Man-Month
traps which are also accepted by industry.



Being accepted by industry doesn't actually provide me with anything
other than a few extra buzzword points on my CV.

More importantly, it wouldn't provide my hypothetical manager with
anything other than a false sense of security, and a small dose of
backside-covering warm fuzzy feelings, because the vast majority of
the time it isn't a question of whether or not Ruby/Python/Lisp/Java/
Smalltalk can do it, it's a question of whether or not *I* can do it,
and no amount of industry acceptance will change that.

I think it's pretty much agreed that good programmers don't need
industry acceptance of their tools to do their job.

What we ought to realise is that good managers shouldn't need it either.

matthew smillie.

Because I respect you, I'm going to respond as if you're serious.

It may be that you haven't ever worked with the kind of person I'm 
talking
about. He's the one programmer in a hundred who can do the work of the 
other
ninety-nine. I probably wouldn't waste him on a Cobol or a VB project. 
I'd
certainly consider him for Lisp. If I really had to code something in
Brainfuck and had made the decision rationally, then I'd certainly 
consider
him for that as well. (But wouldn't assembly language be better than BF 
for
almost any purpose other than demonstrating BF's specialness? And yes, I
would definitely use my superstar on an assembler project.)

I can't speak to your experience. But in mine, the very best of the best 
are
seduced by the inherent interest of the project, the opportunity to work
with people they respect (and it's HARD to win their respect), and above 
all
the chance to learn something new. The choice of programming language is
something they care about (I exaggerated upthread), but it's far from 
the
top of their list.

I asked one of my favorite guys to do a Ruby project three years ago. He 
had
never heard of Ruby but he took the project. Just as I expected, he was
right up to speed on Ruby almost immediately (essentially in one night) 
and
did more production-quality work in less time than all of the 
experienced
Rubyists on the project. With these guys, it's like their brains are
orthogonal to language issues.

>>>Interesting.  I'm always stuck by people who don't get think that
everything is fair game for questioning.

Here, you made two different points ("get" vs "think") as you decided 
midway
through writing the sentence to pull your punch ;-). I get (and I even
think) that everything is fair game for questioning. But James, think 
twice
about this: not everything is WORTH questioning.

On 6/5/06, James Britt <james_b@neurogami.com> wrote:

>> Wow. That's surreal.
>>
>> I have a hard time imagining someone who really understands software
>> development and yet doesn't care if someone dictates what language is
>> used.  And yet can be (equally, one hopes) productive whether working
>> with VB, Lisp, Cobol, or Brainfuck.

On Jun 5, 2006, at 8:10 PM, Francis Cianfrocca wrote:

> than BF for
> the chance to learn something new. The choice of programming  
> night) and
> did more production-quality work in less time than all of the  
> experienced
> Rubyists on the project. With these guys, it's like their brains are
> orthogonal to language issues.

I would happily do a project in assembly if there was a good reason
to. I would hatefully do a project in assembly if Ruby was a 100x
better choice.

James is right that we should care which language we use. Using the
best language for the job (or a reasonable, competitive choice) is
very important. Making your star code everything in Java would
considerably lower his morale and productivity.

Francis is right that a star does good projects, and what tools he is
using is a side issue, because he can easily pick up any tools ... as
long as he wants to. If the tool is actually an appropriate choice,
and the project is interesting, the star will want to.

-- Elliot Temple
http://www.curi.us/blog/

Francis Cianfrocca wrote:
> consider
> the chance to learn something new. The choice of programming language is
> orthogonal to language issues.
I was that sort of programmer a few decades ago. There are only so many
opportunities for "them" (formerly "us"). It took me something like 30
years to outgrow assembly language. :) IIRC I wrote my last line of
assembly code (well, Forth for the 80186) in the early 1990s. I went
directly from microcode to Perl :).

At this point, I'd learn Ruby if there was someone else around at work
who was interested in it. I don't suspect that will happen any time
soon. It was tough enough to find another person interested in R, a
language ideally suited to some of the tougher problems I work on.

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

On 6/5/06, James Britt <james_b@neurogami.com> wrote:
> I have a hard time imagining someone who really understands software
> development and yet doesn't care if someone dictates what language is
> used.  And yet can be (equally, one hopes) productive whether working
> with VB, Lisp, Cobol, or Brainfuck.

Glad I wasn't the only one who was absolutely stunned by that
statement.  You expressed what I was thinking far better than I could
have.

Francis, if you truly have people that can produce quality code in the
language of your choosing (at random), well, umm, pay them extremely
well, lock them in a room, and never reveal their names, or they won't
be yours for long.

>  > Because I'm a businessperson, I'm always struck that people would
>  > question the value of achieving greater acceptance for anything.
>
> Interesting.  I'm always stuck by people who don't get think that
> everything is fair game for questioning.

Indeed.

Entirely valid and thought-provoking point of view, and one that I'm 
finding
is quite characteristic of the Ruby community, perhaps indeed the 
defining
characteristic.

Ruby is the only programming language I know that (for specific reasons
inherent in the design of the language) has some potential to challenge 
the
prevailing wisdom among businesspeople who manage IT projects. Which, to
oversimplify, is that a large problem requires something at least 
resembling
a large team. I'm eliding some of the logical steps, but this entrains 
much
of what you and others (with some justification) criticize as
backside-covering.

But this goes directly against the ethos that software production is a 
fine
art, and that the choice of tools matters less than the quality of the
artifact. This feeling has been a recognizable characteristic of 
software
practitioners long before Ruby was invented, as has the concomitant
criticism of IT managers. As one of those managers, I wouldn't dream of
attempting to build a large one-off enterprise application in Java with 
one
or three top-quality programmers and five assistants. But someday I 
might
actually consider doing it in Ruby.

The best Ruby programs are small ones. This is wired into the genetics, 
and
the aesthetics, of the language. But small Ruby programs can be 
remarkably
powerful, in ways that can fundamentally change the dynamics of software
production. If this point can be made by powerful and eloquent advocates
then Ruby may become a much more widely used language. But so much 
depends
on the goals one chooses to pursue. Many committed Rubyists have stated 
many
times that Ruby should not have widespread adoption by business as a 
goal.
(Perhaps underneath this, there is fear that success would corrupt 
Ruby's
essential character. If so, that's a topic for another thread.) But this
does explain why the Ruby community has so few powerful and eloquent
advocates.

Francis Cianfrocca wrote:
> Because I respect you, I'm going to respond as if you're serious.

Thanks, but I am serious.

> 

> I asked one of my favorite guys to do a Ruby project three years ago. He 
> had
> never heard of Ruby but he took the project. Just as I expected, he was
> right up to speed on Ruby almost immediately (essentially in one night) and
> did more production-quality work in less time than all of the experienced
> Rubyists on the project. With these guys, it's like their brains are
> orthogonal to language issues.
> 

One night?   Right up to speed?



Ok.



>>>> Interesting.  I'm always stuck by people who don't get think that
> 
> everything is fair game for questioning.
> 
> Here, you made two different points ("get" vs "think") as you decided 
> midway
> through writing the sentence to pull your punch ;-). 


Really?  Which of the two words did I intend to delete, but missed in my
editing?


> I get (and I even
> think) that everything is fair game for questioning. But James, think twice
> about this: not everything is WORTH questioning.

Ah, but how does one know before hand?  Or should I not question this?

I'm deeply skeptical of extravagant claims and sweeping assertions.
(I'm leery of the notion of superstar programmers, but that's another
matter.)

But about Ruby popularity: I'm a businessman, too.  And a coder, and an
artist, and a writer, and a bunch of things.   Widespread
[interest|use|acceptance] of Ruby has different value to me from
different perspectives, but overall it is not a big concern.  That a
client is aware of Ruby has, on at least one occasion, been useful.
That magazine editors consider Ruby of sufficient reader interest to pay
me to write articles is quite nice.

On the other hand, I wasn't drawn to Ruby because of its popularity, or
the prospect that it might one day be big.  And the increase in traffic
on ruby-talk is a mixed blessing (although a false elitism is no fun
either).  But here we are.

Years ago, when (once again) trying to decide what to be when I grew up
(a consideration still unresolved to this day), I read The Soul of a New
Machine, by Tracy Kidder.  It describes how engineers from Data General
designed and built a new 32-bit minicomputer.  And very early in the
book it said that the founder of the company recruited  his engineers
with a small ad that said, "Have fun and make money."

That's pretty much been my goal.  Have fun, and make money (in that
order).  And Ruby helps me do that.  So long as that stays true, I'm 
happy.



--
James Britt

"Programs must be written for people to read, and only incidentally
  for machines to execute."
   - H. Abelson and G. Sussman
   (in "The Structure and Interpretation of Computer Programs)

On 6/5/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
 > What I meant was that Python has achieved a degree of respectability 
in
> corporate environments that Ruby hasn't yet.

It all depends on where you're looking.  I'm in a very big corporate
environment (though, admitedly we're kind of an isolated group that
has some independence) - It's a well known, household-word type tech
company.  I'm seeing that Ruby has lots of respectability in our
group.  Even more than Python seems to have.

>  And this doesn't happen by
> itself, and it certainly doesn't happen just because a language is
> particularly well-done or particularly nice for programmers to use. I think
> you may be underestimating the degree to which technology choices in large
> organizations are driven by the need to reduce the perception of risk. It's
> not universally true that a programmer who "delivers the goods" will get to
> pick his technology.

If you're in a reasonable group then the emphasis is on delivery.  If
you can deliver product X twice as fast by using technology Z then
after a while nobody (including management) is going to care that
technology Z hasn't been blessed by corporate.  At some point it will
be blessed by corporate because it increases productivity.  It can
take a while to get there sometimes, but I think Ruby has pretty much
arrived at the point where it's being 'blessed by corporate' in enough
shops that it's really just about mainstream.

>
> But the question gets asked here time and again: who cares if people in
> corporations don't use Ruby, as long as I can use it on my own projects?
> Entirely valid. But if you really like using a language, wouldn't you want
> to use at work as well as at play? And to get that kind of acceptance for
> Ruby will take some serious advocacy. With the rise of Rails, that may be
> starting to happen, but it's too soon to tell.

Compared to 2001 it _has_ happened; back then it was an uphill battle
getting companies to use Ruby.  Rails has helped tremendously, but
looking back I notice that I've had several paying jobs that involved
writing Ruby code (even back in 2001).   The change now is that I
don't have to educate people about what Ruby is, they already know
about it and either they've been learning it or they want to.

> (For the little that it's worth, we shipped a pair of apps in Rails, and
> doesn't particularly care either.
But the language choice _does_ often matter especially when schedules
are tight and manpower is short.  If you want product Z done and you
give me the choice of implementing in either C++ or Ruby and you want
a schedule I'm going to tell you that in Ruby I could get it done in x
weeks while in C++ it'll take 4x weeks.  If runtime performance isn't
an issue then using Ruby for the project is an easy choice. Even if
runtime performance is an issue, Ruby and some C code might still be a
very good choice.

I suspect that these magical people you're referring to would balk if
you suggested that you want your next project done in COBOL or Basic,
so programming language choice does matter to some extent even for
them.  If it weren't for the adventurous programmers who decided they
weren't satisfied with the status quo we'd likely still be using COBOL
and FORTRAN.

Phil

Austin Ziegler wrote:
> On 6/5/06, ReggW <me@yourhome.com> wrote:
>> Here is a list of Drivers that people *need* for Rails...
>> http://wiki.rubyonrails.com/rails/pages/DatabaseDrivers
>>
>> Approx. 90% of these would go away if they implemented ODBC.
> 
> Then someone should post a bounty for those drivers. In open source,
> people implement what they need or what others are willing to pay them
> for.
> 
Just like most open-source zealots, when presented with the facts you 
change your story.

That's ok, I still love the language, but hate the mentality of *some* 
of it's users/developers.

Thanks

>>>One night?   Right up to speed?
Yes. And I knew he would because I'd seen him do similar things before. 
No,
it's not normal. But there is a remarkably small amount of really great
software in the world (although I think my definition of great probably
differs from yours), and much of it is written by that kind of guy.

>>>Interesting.  I'm always stuck by people who don't get think that
everything is fair game for questioning.
The fact that "get think" makes this an invalid English sentence 
suggests to
me (perhaps wrongly) that you changed your thought midway through. Not a
point worth arguing.


"I get (and I even think) that everything is fair game for questioning. 
But
James, think twice about this: not everything is WORTH questioning."

>>>>>Ah, but how does one know before hand?  Or should I not question this?

Ah, but this is a very important question. How do you know beforehand?
Experience and TASTE. I've learned to recognize and pay a lot of 
attention
to people who have a knack for recognizing what are the important 
questions,
and which are the minor side issues. People who are good at this tend to
become leaders.

On 6/5/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> >>>Interesting.  I'm always stuck by people who don't get think that
> everything is fair game for questioning.
> The fact that "get think" makes this an invalid English sentence suggests to
> me (perhaps wrongly) that you changed your thought midway through. Not a
> point worth arguing.

I think assume that he means how are you sure that he didn't initially
make a milder comment, then decide to throw a punch?

Anyway, there have been countless threads on whether Ruby can be
accepted by "the enterprise."  Doing a search will cover the the same
tired arguments that reappear.

In my opinion, "the enterprise" is full of people who are too stupid
to use Ruby.  I read a lot of comments about how to lock Ruby down a
bit more so that it's more accessible to larger teams...what they're
really asking is how to dumb it down for less capable programmers.
Bottom line is that the people who are capable enough and have the
desire to use Ruby are in positions where higher ups tell them to get
things done, and don't care about how.

Nobody would ever ask, "How do I make a stock car safer for my toddler
to drive?"

Pat

Francis Cianfrocca wrote:

> 
>  ...
> Ah, but this is a very important question. How do you know beforehand?
> Experience and TASTE. I've learned to recognize and pay a lot of attention
> to people who have a knack for recognizing what are the important 
> questions,
> and which are the minor side issues. People who are good at this tend to
> become leaders.
> 


Ah.  Well, you've just made something very clear for me.


Thank you.

--
James Britt

"Blanket statements are over-rated"

On 6/6/06, ReggW <me@yourhome.com> wrote:
> >
> Just like most open-source zealots, when presented with the facts you
> change your story.

You *really* don't want to take that attitude with me. You don't know
me and you obviously don't know what contributions that I *have* made
in the past and will make again as soon as I find time. I'm not trying
to toot my own horn, but basically what I'm saying is that no one is
going to do your ODBC drivers for you unless there's something in it
for them.

I, for one, have no need for ODBC drivers for Rails.

Why? Because I don't use Rails. That's right. I don't use Rails.

So why would I *possibly* do anything to support the development of
ODBC drivers for Rails?

You, however, use Rails. You, however, seem to need ODBC drivers. So
... why aren't you developing them or making the effort to make sure
that they do get developed? Or is it just easier to whine that Rails
doesn't have ODBC drivers?

My story on this hasn't changed, Regg. If you look closely, you'll see
that I've always been pushing you toward getting someone to develop
the drivers for you. If you're not going to do it yourself, complain
to your database vendor that you need Rails support. If they don't
listen, find out whom else needs what you need and post a bounty to
get it done.

> That's ok, I still love the language, but hate the mentality of *some*
> of it's users/developers.

Try again. You're not talking to someone who has that mentality. I
would strongly suggest you google some of your correspondents -- not
just me -- before you start spouting off "open source zealot." I, for
one, am nothing of the sort. I'm just not your unpaid code monkey,
either.

-austin

On 6/5/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> I used to make my living selling my
> programming skills but now I'm mostly a buyer of the programming skills of
> others. I guess that makes me a crappy business person.)

Well, I would have no way to assess that as either true or false, but
certainly that wasn't what I meant.

It does sound, however, as if you have some crappy business people for
customers. (No offense, so do I!)

> What I meant was that Python has achieved a degree of respectability in
> corporate environments that Ruby hasn't yet. And this doesn't happen by
> itself, and it certainly doesn't happen just because a language is
> particularly well-done or particularly nice for programmers to use. I think
> you may be underestimating the degree to which technology choices in large
> organizations are driven by the need to reduce the perception of risk.

No, I am completely aware of that, I'm just firmly of the opinion that
working for large corporations is detrimental for the sharpness of
programming skills.

> It's
> not universally true that a programmer who "delivers the goods" will get to
> pick his technology.

True, but although it isn't **universally** true, it is true for a
number of excellent programmers who also make very good business and
marketing decisions. Other things are true for other programmers, but
I don't care, because those other programmers aren't my role models.
I'm firmly of the opinion that the answers you find are much less
significant than the questions you ask. Consequently I'm only willing
to ask the questions that will make me an excellent programmer.

> But the question gets asked here time and again: who cares if people in
> corporations don't use Ruby, as long as I can use it on my own projects?

Hold on -- I have herad that question, but you're assuming everybody
only works on large corporate projects. In my case, I don't want to
work for large corporations, but I do want to be paid to use Ruby.

> Entirely valid. But if you really like using a language, wouldn't you want
> to use at work as well as at play? And to get that kind of acceptance for
> Ruby will take some serious advocacy. With the rise of Rails, that may be
> starting to happen, but it's too soon to tell.

The ability to use Rails is a major priority for selecting my next
job. But it only takes serious advocacy if you're choosing customers
who have prioritized minimizing risk over maximizing results. If
you're only even willing to consider customers who prioritize
maximizing results over minimizing risks, the advocacy effort becomes
nonexistent.

> Because I'm a businessperson, I'm always struck that people would question
> the value of achieving greater acceptance for anything.

Fair enough, you're thinking of marketing, obviously increased demand
can be a good thing. But you have to realize the dangers of a
commodity-oriented model when you're running a service business. You
don't want to compete on price. (Chad Fowler's book "My Job Went To
India" explains why.)

> handwritten Ruby with our own handwritten web servers.)
Using parts of Rails, or entirely handwritten?

Are the web servers in Ruby?

> And to your point about programmers who deliver the goods: I've been
> privileged at several times to have some of those magical crazy people
> working for me who can deliver almost anything on almost any schedule. And
> although the sample set is small, those I have known all share this key
> characteristic: the programming language DOESN'T MATTER. An individual who
> really understands software development doesn't pick a programming language
> to concentrate on. He's productive in anything you tell him to use, and he
> doesn't particularly care either.

I think on this point at least you and I are totally in agreement.
It's good to understand Language X but it's much better to understand
programming.

On 6/5/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> point worth arguing.
> and which are the minor side issues. People who are good at this tend to
> become leaders.
>

Yep.  Like GWB.

<ducks>





phil

I wanted to also include a mention of the Google summer of Code project
where many great projects are being worked on currently to further
contribute to the ruby community, rubys future definetely seems less 
grimm
each day. I do believe as long as you can justify and actualize it's use
beneficially for your applications, it is going to remain a useful tool.

Benjamin

Austin Ziegler wrote:
> On 6/6/06, ReggW <me@yourhome.com> wrote:
>> >
>> Just like most open-source zealots, when presented with the facts you
>> change your story.
> 
> You *really* don't want to take that attitude with me. 

Why...are you going to beat me up?

ReggW wrote:
> Austin Ziegler wrote:
>> On 6/6/06, ReggW <me@yourhome.com> wrote:
>>> >
>>> Just like most open-source zealots, when presented with the facts you
>>> change your story.
>> 
>> You *really* don't want to take that attitude with me. 
> 
> Why...are you going to beat me up?

Very mature guys ....

The point of a programming language is to solve a specific problem. 
Some languages are better suited for solving certain problems compared 
to others.  For example, C is great for having total control of memory 
and ensuring that the code executed can perform at an optimal level, but 
there are definitely times such performance constraints don't exist ... 
and then managed programming languages are better options.

This is to address the origional author's statement of not learning many 
programming languages; to leverage languages effectively you need to 
know them, or need to be able to pick them up quickly ... or at least 
certain types of languages.  I suggest understanding unmanaged code (C, 
C++), managed code (Java, C#), and then the "dynamic" languages (Python, 
Ruby, etc).  The differences between dynamic and managed languages are 
mainly that managed languages are compiled while dynamic languages are 
in some form interpreted.  Also most dynamic languages are dynamically 
typed, compared to static typing (declaring a variable of a type that 
can not be changed).  This provides flexability and most programmers 
find it easier to work with.

In short, languages are a tool.  If you've got a nail, you don't try to 
drill it in; you use a hammer.  Using a language that is not suited for 
the problem is like trying to force that nail in with a drill.  So I 
suggest using the knowledge people have given in this thread and decide 
whether Ruby is a tool you want to apply to the problems you are trying 
to solve.

~Jimmy

On Tue, 2006-06-06 at 13:43 +0900, ReggW wrote:
> That's ok, I still love the language, but hate the mentality of *some* 
> of it's users/developers.

Me, too. Only *very* few, but congratulations - you made the list
already.

(I'm really getting the feeling from both the ML and the newsgroup that
we're being deliberately baited just lately. Anyone else noticing that,
or am I being paranoid?).

James Schementi wrote:
> ReggW wrote:
>> Austin Ziegler wrote:
>>> On 6/6/06, ReggW <me@yourhome.com> wrote:
>>>> >
>>>> Just like most open-source zealots, when presented with the facts you
>>>> change your story.
>>> 
>>> You *really* don't want to take that attitude with me. 
>> 
>> Why...are you going to beat me up?
> 
> Very mature guys ....
> 

I'm just poking fun as Austin :)

Lighten up...

On 05/06/06, Tanner Burson <tanner.burson@gmail.com> wrote:
> From a web perspective it even has the potential for performance issues.
> Because there are no native threads, its very easy for a system call (file
> or socket handling most commonly) to block the entire Ruby process, not just
> the current ruby thread.  Thanks to the ease of IPC in Ruby it can be less
> of an issue, but is definitely something that potentially affects many
> people's views of ruby.

Worth pointing out that this is only an issue if you are using a 
multithreaded
webserver. It's not an issue with fastcgi dispatchers, as a blocked 
thread only
blocks one dispatcher.

On 6/6/06, ReggW <me@yourhome.com> wrote:
> Austin Ziegler wrote:
> > On 6/6/06, ReggW <me@yourhome.com> wrote:
> >> Just like most open-source zealots, when presented with the facts you
> >> change your story.
> > You *really* don't want to take that attitude with me.
> Why...are you going to beat me up?

Oh, good god. Once again, ruby-forum demonstrates its that it's the
cess-pit of Ruby users.

No, Regg, I'm not going to "beat you up." You don't want to take that
attitude with me because you're going to alienate me (and probably
others)  from *wanting* to help you. Based on your responses, it seems
that you think that it's your god-given right to have the
functionality *you* need in an open-source mostly-volunteer project.

Guess what: you don't. You sometimes have to pay for what you need.
And sometimes, just sometimes, you can't even do that. (I have had
people offer to pay me to do certain features on PDF::Writer. I have
appreciated the offers, but I don't have time to work on PDF::Writer
right now because of a *lot* of reasons, but I'll have time later and
I have my own priorities with PDF::Writer.)

-austin

Giles: this is a Ruby-language forum, and the title of the thread is "I 
love
Ruby but is its future bright?" As interesting as your comments are 
about
business, I don't want to stray too far offtopic.

I'd like Ruby to become as good a language and 
language-implementation(s) as
possible. And to do so quickly would be a big plus. One way to do that 
is to
get more smart, well-motivated people to work on the language. And one 
way
to do that is to expand the number of people who use the language. If 
this
happens, then the big question will be: can Ruby survive success? And 
that
will depend on the leadership skills of Matz and the more important 
people
in the community.

If it doesn't happen, then Ruby will continue to be what it is today: a
lovely language with applicability to a reasonably interesting class of
problems.

To your questions about Rails: we sometimes use pieces of ActiveRecord. 
The
rest of our stuff is done in pure Ruby, using a framework very similar 
to
Rails without most of the edge features. It usually profiles at least 
ten
times faster than Rails (often twenty times). The web servers are 
written in
a mix of Ruby and C++. Made sense for us because we've been writing
high-performance servers for distributed apps for a lot of years so we 
had a
lot of good knowledge to draw on.

Austin Ziegler wrote:
> On 6/6/06, ReggW <me@yourhome.com> wrote:
>> Austin Ziegler wrote:
>> > On 6/6/06, ReggW <me@yourhome.com> wrote:
>> >> Just like most open-source zealots, when presented with the facts you
>> >> change your story.
>> > You *really* don't want to take that attitude with me.
>> Why...are you going to beat me up?
> 
> No, Regg, I'm not going to "beat you up." You don't want to take that
> attitude with me because you're going to alienate me (and probably
> others)  from *wanting* to help you. Based on your responses, it seems
> that you think that it's your god-given right to have the
> functionality *you* need in an open-source mostly-volunteer project.

Austin, I was only poking fun at you, no harm was meant :)

Also, I'm not looking for help. I'm only airing some of my concerns with 
Ruby's decision and direction.

It's ok for you and I to disagree on some issues.
Thru these types of disagreements and discussions comes some very 
enlightening details.

For one you have informed me that I have been dealing with the wrong 
website in getting the latest Ruby information.
Also, that there may be a new product (YARV/Rite) that may help with 
some of my concerns.

Thanks

Jeff Pritchard wrote:
> ...

> Since Rails is considered by many to be the "killer app" for Ruby, why 
> doesn't there seem to be a contender in the non-web-app type application 
> framework genre for Ruby?  Is there something about the language that 
> makes it an inappropriate choice for "real" application work, or is it 
> more just a matter of coincidence that the right group of people hasn't 
> done something as stellar as Rails in that space yet?
> 

Perhaps there are languages that, by their nature, require an
application framework exist before one can expect to build certain kinds
of applications.  And there are there other languages where this is not
needed; they make it easy enough to just grow your own application or
in-house set of tools; they language helps avoid exploding complexity.

It's similar to the complaint that Ruby does not have an IDE such as
Eclipse; some Rubyists argue that there isn't one because there is no
compelling need for it, as there is in Java.



--
James Britt

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools

I'd like to see a serious enterprise-grade SOA framework that is either
written in an agile language or supports them well. Doesn't matter if 
it's
Ruby or Python. Python's Twisted has PB, but it's several steps short of
what is really needed. Ruby has nothing close yet.

> It's similar to the complaint that Ruby does not have an IDE such as 
> Eclipse; some Rubyists argue that there isn't one because there is no 
> compelling need for it, as there is in Java.

www.radrails.org

Apologies for the rant, but...

On Jun 6, 2006, at 9:52 AM, Francis Cianfrocca wrote:

> I'd like to see a serious enterprise-grade SOA framework that is  
> either
> written in an agile language or supports them well. Doesn't matter  
> if it's
> Ruby or Python. Python's Twisted has PB, but it's several steps  
> short of
> what is really needed. Ruby has nothing close yet.

Having worked with a number of "enterprise-grade SOA frameworks" I
think the best available one, by a long shot, is HTTP and and a good
glue language (Perl is the most common, Ruby is moving way faster
though). (2)

A realistic SOA framework is a set of state transfer idioms and
protocols which will be adhered to as best as possible across
languages, platforms, and applications. The most useful set of
guidelines for this which I have seen as an implementor (NOT as  a
vendor) is Roy Fielding's thesis. (1) I believe that a push model is
also important, but for that we have no good solution yet, in any
language, for any platform.

This is all completely language independent. In my experience the
tools and systems which have tried to create a super-high level
language for integration/SOA have pretty much been abysmal failures,
and the folks embracing protocol based and idiomatic integration at a
lower level have met with lots of success. This is, of course a
generality, but the correlation is very high based on the data
available to me.

One big problem seems to be that, by and large, when people are
shopping for an SOA framework they are looking for way to make non-
programmers (in which category I include incompetent programmers)
into useful programmers. This is all well and good, but training and
protocol understanding, not tooling to abstract the solution away
form the problem, is a much more fruitful path.

This is not to say the building these systems is simple with
protocols and glue, and that sophisticated tools are not useful, but
that the sophisticated tools which are useful are generally the ones
which embrace the wire protocols and data idioms rather than hide
them. Point of reference, mod_rewrite has done more good for
distributed systems than all of WS-* in its entirety or any of its
parts.

My 2p =)

-Brian

1. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

2. For the enterprisey folks out there, JBI based tooling, and its
competitors in the programming standards space (SCA, Indigo, ???),
when the API's are used directly, is HTTP with a set of idioms glued
on top and a mediocre to poor glue language. When drag and drop is
used to generate Java/C# by folks who don't know what an idempotent
method is, it is generally borkage.

Peter Ertl wrote:
>>It's similar to the complaint that Ruby does not have an IDE such as 
>>Eclipse; some Rubyists argue that there isn't one because there is no 
>>compelling need for it, as there is in Java.
> 
> 
> www.radrails.org


I thought that was focused on Rails, and did not do automatic
refactoring or  code completion.

But if it works for general Ruby the same way as Eclipse works for Java,
then that's quite slick.


--
James Britt

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools

On Jun 6, 2006, at 1:01 PM, Peter Ertl wrote:

>> It's similar to the complaint that Ruby does not have an IDE such as
>> Eclipse; some Rubyists argue that there isn't one because there is no
>> compelling need for it, as there is in Java.
>
> www.radrails.org

RadRails is for Rails, but it uses RDT which is the ruby toolkit that
can be downloaded separately:

http://rubyeclipse.sourceforge.net/

Both RDT and RadRails rock.  I use them daily.
-Mat

On Jun 6, 2006, at 1:54 PM, James Britt wrote:

> Java, then that's quite slick.
To clarify, code completion is a bit limited, but works.  Refactoring
appears to be non-existent in the current release, the I get by
pretty well with Eclipse's search and replace features.
-Mat

Mat Schaffer wrote:
> On Jun 6, 2006, at 1:54 PM, James Britt wrote:
> 
>> Java, then that's quite slick.
> To clarify, code completion is a bit limited, but works.  Refactoring
> appears to be non-existent in the current release, the I get by
> pretty well with Eclipse's search and replace features.
> -Mat

I can't get any code completion to work with RadRails.

This is the ONLY thing that RadRails really needs, and it would be the 
best Ruby/Rails IDE available.

I think JEdit has the best code completion, but it lacks the rails 
features of RadRails and the ProjectViewer plug-in doesn't bring your 
entire project directory structure from the hard drive.

Anyway, RadRails is almost the best IDE.

Francis Cianfrocca wrote:
> Ruby is the only programming language I know that (for specific reasons
> inherent in the design of the language) has some potential to
> challenge the
> prevailing wisdom among businesspeople who manage IT projects. Which, to
> oversimplify, is that a large problem requires something at least
> resembling
> a large team. I'm eliding some of the logical steps, but this entrains
> much
> of what you and others (with some justification) criticize as
> backside-covering.
Well ... I suppose it depends on how you define "large problem". Let's
assume, for example, that you have a well-behaved business problem whose
natural solution algorithm uses resources that grow no faster than N log
N, where N is the size of the inputs. A prototypical such problem is
sorting.

That may be a large problem, given, say, trillions of records to sort
through. But it does not require a wide variety of domain expertises,
and as far as I can tell is no easier in Ruby than in any other
language, including some very old ones.

In the scientific realm, consider the problem of hurricane forecasting.
Again, there isn't a wide variety of domain expertises required,
although just about everybody understands sorting and not just about
everybody understands partial differential equations and atmospheric
physics. This is also a problem for which it is highly unlikely that a
Ruby solution would be proposed.

So there are two examples of large problems which would not necessarily
require a large team. I'm sure there are numerous others -- Google has a
solution to one of them at its core.

I think perhaps you're mistaking "large team required" with "non-agile
process required" and unconsciously linking agile processes with Ruby.
I've seen a lot of programming languages, both general purpose and
special purpose, and I guess I'm not convinced that Ruby is the "best"
general purpose language, or even significantly "better" than, say,
Java, Ada, or even Common Lisp.
> actually consider doing it in Ruby.
Pure Ruby, or Ruby plus Rails plus all of the other tools that have
sprung up from Ruby? And what about .NET?
>
> The best Ruby programs are small ones. This is wired into the
> genetics, and
> the aesthetics, of the language. But small Ruby programs can be
> remarkably
> powerful, in ways that can fundamentally change the dynamics of software
> production. If this point can be made by powerful and eloquent advocates
> then Ruby may become a much more widely used language.
I don't think this is true only of Ruby. Small, elegant solutions to
problems can be powerful in quite a few other languages. The ones that
spring to my mind right now are Lisp, Forth, APL, R and SmallTalk. And
one other that probably doesn't spring to many minds except my own these
days -- macro assembly language. :)

And I can think of languages where it isn't true -- Fortran, C, COBOL
are the obvious ones. And then there are "borderline cases" -- Perl and
Java are the two that I know of. I don't know enough Python or PHP to
classify them.

> But so much depends
> on the goals one chooses to pursue. Many committed Rubyists have
> stated many
> times that Ruby should not have widespread adoption by business as a
> goal.
> (Perhaps underneath this, there is fear that success would corrupt Ruby's
> essential character. If so, that's a topic for another thread.) But this
> does explain why the Ruby community has so few powerful and eloquent
> advocates.
I wonder if a language can "have a goal". Ruby, like some other
languages, is a community that sprung up around a creative force, in
this case Matz. Perl sprung up around Larry Wall, Lisp around John
McCarthy, APL around Ken Iverson and Forth around Chuck Moore.

John McCarthy's goal was to create a computer that could take advice.
Chuck Moore's goal was to write a lot of programs in a compact way. Ken
Iverson's goal was to bring the tools of mathematical formalism to
programming. As far as I know, none of them -- Larry Wall and Matz
included -- had as a goal getting rich, or world domination, or creating
the "best" computer language.

I think Ruby *does* have powerful and eloquent advocates. I'm just not
sure they are advocating Ruby so much as they are advocating agile
processes, metaprogramming, domain-specific languages, "duck typing",
dynamic languages, and, of course, Rails. :)

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

Large problems: you're playing word games with me. "Large" has many
meanings. Two that are germane to my point are: information systems with 
an
extremely long anticipated lifetime (meaning that it's unwise to expect 
the
original developers to stay committed to it), and systems that cut 
across a
large number of knowledge domains in a single organization (meaning you
can't leverage the expertise of a world full of developers). A lot of
resources go into solving problems that are understood along these 
lines,
and a lot of those resources get wasted. THAT is a problem that's worth
solving. Ruby could be part of the solution, if more of the community 
were
interested in the problem.

Advocacy: you make a compelling point that the advocacy around Ruby is 
part
of the more general enthusiasm for agile development and dynamic 
languages.
Well and good, so long as your focus is on computer programs as
beautifully-crafted artifacts. But this advocacy is largely meaningless
several steps higher, where decisions are made about which computer 
programs
to fund the development of. A different kind of advocacy is required 
there,
and it's becoming clear to me that Ruby advocacy probably doesn't belong 
at
that level. The original topic of this thread was Ruby's future. It may 
be
that Ruby's future is all about projects that are undertaken for love, 
not
money. And there's nothing wrong with that.

Phil Tomson wrote:
>
> It may be years before you know if you've made the 'right' choice.
>
> If you do happen to choose 'wrong' (whatever that might mean for you)
> you can always go back and learn another language(s).  It's not like
> you're locked into some binding contract or something.
I've lost count of how many times I made the wrong choice of language. I
don't regret the learning I've taken from macro assembler, Lisp, APL,
Forth or Java. But I made money programming in Fortran, Perl and R. So 
...

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

Hector wrote:

> I'm at a point where I'm asking myself if it is worth the trouble for me
> to learn Ruby. How many people are really writting Ruby? Are there any
> truly robust, good applications being written in Ruby? How well are Ruby
> libraries being maintained? I know there is a lot of documentation for
> Ruby but I find it hard to find very specific docs. Python seems to have
> a whole lot more doc and many more books exist for Python. Does Python
> have a greater following. I love Ruby but I don't want to waist my time
> with a laguage that may not have a future.

I downloaded Ruby at monday. Today I'm creating fxRuby application with 
MySQL backend and everything works fine :-)... BUT I think that Ruby 
resources (docs, external modules like MySQL and others) are very very 
scattered.

Francis Cianfrocca wrote:
> and he
> doesn't particularly care either.
When I was one of those "magical crazy people", the choices were fewer.
And almost invariably the magical crazy people programmed in assembly
language whenever they could. Hardware was expensive, compilers sucked,
machines were slow and had limited memory.

Because of changing economics, programming language may not matter as
much as it used to, but I think today's magical crazy people probably,
if they had their druthers, would program in ... (pregnant pause) ... C.
At least the compilers don't suck any more. :)

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

Francis Cianfrocca wrote:
> and a lot of those resources get wasted. THAT is a problem that's worth
> solving. Ruby could be part of the solution, if more of the community
> were
> interested in the problem.
As in "Enterprise Integration With Ruby?" Yeah ... I probably write what
you'd call "enterprise integration" but what I call "glue logic" in
Perl. That's mostly because I learned Perl 4 about ten years ago and
haven't needed anything better, except for math, where I have R. But I'm
a "domain expert" in performance engineering, monitoring, analysis, etc.
-- at least that's my role at present. Nobody would ask me to write a
web application. If they did, it would undoubtedly be in either .NET or
PHP, not Ruby.

Long lifetimes ... is that air traffic control system from the late
1960s still up and running? :) The one that was written in System\360
Assembler, PL/I and probably some other languages? Is Chuck Moore's Kitt
Peak Forth code still driving that telescope? Has NASTRAN been ported
from Fortran to some more "modern" language?

Resources wasted? That's a "fundamental law of nature" having to do with
large teams starting to exhibit behavior reminiscent of gas dynamics. I
don't see how Ruby changes the realities of large teams, any more than
any other "magic bullet" has in the 44 years I've been programming. If
the "Ruby community" isn't interested in *that* problem, more power to
them! :)
> there,
> and it's becoming clear to me that Ruby advocacy probably doesn't
> belong at
> that level. The original topic of this thread was Ruby's future. It
> may be
> that Ruby's future is all about projects that are undertaken for love,
> not
> money. And there's nothing wrong with that.
Yeah ... Ruby is certainly a beautifully-crafted artifact. It's perhaps
more complicated than it needs to be, especially when you compare it
with the stark simplicity of Lisp, Forth or LIW microcode. Any language
with "lambda" is OK in my book. :)
>> > prevailing wisdom among businesspeople who manage IT projects.
>> N, where N is the size of the inputs. A prototypical such problem is
>> everybody understands partial differential equations and atmospheric
>> special purpose, and I guess I'm not convinced that Ruby is the "best"
>> dream of
>> > the aesthetics, of the language. But small Ruby programs can be
>> days -- macro assembly language. :)
>> > goal.
>>
>> dynamic languages, and, of course, Rails. :)
>>
>> -- 
>> M. Edward (Ed) Borasky
>>
>> http://linuxcapacityplanning.com
>>
>>
>>
>

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

On Jun 6, 2006, at 5:25 PM, ReggW wrote:
> This is the ONLY thing that RadRails really needs, and it would be the
> best Ruby/Rails IDE available.
>
> I think JEdit has the best code completion, but it lacks the rails
> features of RadRails and the ProjectViewer plug-in doesn't bring your
> entire project directory structure from the hard drive.
>
> Anyway, RadRails is almost the best IDE.

You may want to check your settings, then just hit you completion key
on a blank line and see if anything comes up.  I get a whole slew of
things.  But as often the case for dynamic typing, it's not always
relevant to the variable I'm dealing with.
I'm on RDT 0.8.0.604272100PRD, RadRails 0.6.3.
-Mat

On Jun 7, 2006, at 6:25, Francis Cianfrocca wrote:

> resources go into solving problems that are understood along these  
> lines,
> and a lot of those resources get wasted. THAT is a problem that's  
> worth
> solving. Ruby could be part of the solution, if more of the  
> community were
> interested in the problem.

I think it's important to remember that you're talking about a
distinct class of businesses; businesses that are too big and varied
to buy off-the-shelf software, but who aren't involved in full-time
software development (and either staff-up or contract-out as needed
on a project-by-project basis).  It's a very large class of
businesses, I admit, quite likely it's the large majority of the
available market for programmers, but it's not all businesses, which
will be important later on.


In any case, it's interesting that you think these are problems which
are solvable via language design (or by a particular language).  If
you ask me, they're problems of management; I'll split up my analysis
below.

1: long lifetimes.

For small values of "long" (say, 5-10 years, though this will vary by
domain) the language will have some impact - languages which
encourage self-documentation will have a slight advantage over
languages which don't, given similar standards and practices within
the organisation, but it's those standards and practices which will
have the largest impact.  This is a problem of management and
engineering, the realm of specifications and documentation and
requirements; it's essentially language-agnostic.

For medium values of long, your implementation is going to become
obsolescent, especially if you don't periodically renovate/
reimplement it.  I expect this to be less of an issue between now and
2030 than it was, say, between 1975 and Y2K, but I believe there's a
very solid economic reason to that obsolescence is the norm (which
I'll briefly discuss below), regardless of your choice of language.

For big values of long - your guess is likely as good as mine, but
I'd pick Lisp.  Four decades and still going strong.

2: organisation-specific knowledge.

Again, this is primarily an issue of management; it includes system
design and specification, organisational history, and also the
retention of those individuals who incorporate that knowledge.  If
those processes fail, there's little that the choice of language can
do to compensate for that.

> required there,
> and it's becoming clear to me that Ruby advocacy probably doesn't  
> belong at
> that level.

And there's the big disconnect: management decisions are made for
economic reasons, not purely technical ones, and there are big
economic factors throwing their weight around:

First: [Freely-available] Computer languages and their associated
libraries approximate public goods (I am aware of theoretical nits
that might be picked with this assertion).  From a business
perspective, they represent a positive externality; businesses
benefit from the production of these goods ("language design") while
contributing little to it.  Typical profit-motivated businesses
either can't afford or wouldn't be willing to fund language design
simply to support their own projects, they instead rely on
individuals with significantly different economic motivations to
design these languages and libraries.

The catch is that unlike typical examples of beneficial externalities
in business (e.g. the road network), languages can change at a pace
faster than or comparable to the business itself.  This is one reason
why projects tend towards obsolescence: current languages evolve,
their libraries change, deprecation ensues (Java), some fall out of
fashion (COBOL, Fortran), new languages are created (Perl, Python,
Ruby), some come back into fashion (Lisp), and so on.  In the
maintenance phase of its life-cycle, your system is essentially
static with respect to this churn.  Without a direct involvement in
the process of language design - which the typical business doesn't
pursue - the odds are very much higher that your system will be left
behind.


The second big economic gorilla is the fact that for a certain type
of production - into which most 'enterprise' software falls - profit
is maximised at the expense of efficiency.  If someone using
technically-sophisticated methods to accomplish a project should
leave, the cost of replacing them (basically, the time it takes to
find someone with equivalent knowledge + the time it takes the
replacement to get up to speed with the existing work/start over) is
quite high, but such methods are more efficient and will get the job
done faster.  On the other hand, it's easier to replace people
working using less sophisticated methods, but such methods are less
efficient and the project will take longer.

Accounting for this risk/efficiency trade-off, profit ends up getting
maximised somewhere in the middle of the efficiency spectrum - a
middle currently occupied quite comfortably by Java and .NET.
"Business acceptance" in this regard is highly correlated to 'dumbing-
down' the language to make it more suitable for less-skilled (rather,
de-skilled) labour.



> The original topic of this thread was Ruby's future. It may be
> that Ruby's future is all about projects that are undertaken for  
> love, not
> money. And there's nothing wrong with that.

You may be right, but I'm willing to bet that you're only right
insofar as you mean *your* money.

The economic motivations of businesses mentioned above are often
contrary to the economic interests of the programmers they employ.
Where businesses have a motivation *not* to invest in the production
of public goods such as languages and libraries, programmers do have
such motivation; both in a higher value on non-monetary reward
(typical in particular of language developers), and as a method of
ensuring that they don't have to pay to practice their trade[1].
Where businesses have a motivation towards average, simple systems,
programmers (on the whole) would prefer working on interesting and
sophisticated ones, again both for monetary reasons (better pay or
the strong likelihood of better pay in the future) and non-monetary
ones (intellectual stimulation and less chance of terminal ennui in
the future).

Recent changes in the programming industry have meant that
programmers can now pursue their own economic interests more freely,
instead of relying upon "business acceptance" for economic security
(and the associated compromise of their own interests).

Opportunities to pursue technically-sophisticated projects have grown
enormously: from Google's Summer of Code to a few paid hours a week
at your usual job to contribute to an open-source project, to grants
and full-time employment on open source projects.  In the private
sector, Google, Microsoft, NTL, and IBM all have well-funded and
diverse research divisions.  I'd say that even academic opportunities
are improving (this is harder to quantify, since it occurs over
longer periods, though certainly industry-associated funding is
rising).  It's feasible to say that this class of businesses has
benefited from aligning their interests with the programmer's
interests, rather than forcing it the other way around.

And as a result, "business acceptance" in its traditional sense is
becoming less relevant to language design because typical businesses
are contributing less to language design; essentially nothing in
direct terms, and even their marginal contribution of providing jobs
to direct contributors (i.e. jobs not involving those contributions)
is proportionally lower than it ever has been.


matthew smillie.



[1] Take the hypothetical situation where a company requires as part
of their license terms that everyone programming with their language
and/or library holds a certification (which only they provide).

If I have a quoted symbol, i.e. :'some symbol' then when I dump the
YAML for it and then load the results I don't get back the symbol I
put in, but get an extra set of escaped quotes.   The following irb
session shows this:

irb(main):014:0> YAML.dump(:'some symbol')
=> "--- :\"some symbol\"\n"
irb(main):015:0> YAML.load("--- :\"some symbol\"\n")
=> :"\"some symbol\""
irb(main):016:0> YAML.load("--- :\"some symbol\"\n").class
=> Symbol

~> ruby -v
ruby 1.8.4 (2005-12-24) [powerpc-darwin8.6.0]

I was a bit surprised it wasn't using something like
	ruby/symbol 'some symbol'
to do the encoding.

Dave.

On Wed, 7 Jun 2006, Dave Baldwin wrote:

> If I have a quoted symbol, i.e. :'some symbol' then when I dump the YAML for
> it and then load the results I don't get back the symbol I put in, but get an
> extra set of escaped quotes.   The following irb session shows this:

i don't see the problem:


   harp:~ > ruby -r yaml -e' qs = YAML.load(YAML.dump(:"foo bar")); p 
qs; p qs.class; p VERSION '
   :"foo bar"
   Symbol
   "1.8.4"


you are just confusing yourself with irb/inspect

> irb(main):014:0> YAML.dump(:'some symbol')
> => "--- :\"some symbol\"\n"
      ^^^^^^^^^^^^^^^^^^^^^^^^
      this is the output of String.inspect - not the literal string


try

   harp:~ > irb -r yaml
   irb(main):001:0> dumped = YAML.dump(:'some symbol')
   => "--- :\"some symbol\"\n"
   irb(main):002:0> YAML.load dumped
   => :"some symbol"
   irb(main):003:0> YAML.load(dumped).class
   => Symbol


regards.

-a

On Thu, 2006-06-08 at 02:21 +0900, ara.t.howard@noaa.gov wrote:
>    :"foo bar"
>    Symbol
>    "1.8.4"
> 
> 
> you are just confusing yourself with irb/inspect

That's wierd. I've seen this problem before (I switched to Marshal in
the end), and I still seem to get it now.

$ ruby -v -ryaml -e 'p YAML::Syck::VERSION'
ruby 1.8.4 (2005-12-24) [i686-linux]
"0.60"

$ ruby -r yaml -e' qs = YAML.load(YAML.dump(:"foo bar")); p qs; p 
qs.class '
:"\"foo bar\""
Symbol

On Jun 7, 2006, at 1:21 PM, ara.t.howard@noaa.gov wrote:

>
>> => "--- :\"some symbol\"\n"
>   => :"some symbol"
> makes the suffering disappear.
> - h.h. the 14th dali lama
>

ara, try this:

% irb
irb(main):001:0> require 'yaml'
=> true
irb(main):002:0> sym = :"a symbol"
=> :"a symbol"
irb(main):003:0> sym == sym
=> true
irb(main):004:0> sym == YAML.load(YAML.dump(sym))
=> false
irb(main):005:0> sym
=> :"a symbol"
irb(main):006:0> YAML.load(YAML.dump(sym))
=> :"\"a symbol\""
irb(main):007:0> VERSION
=> "1.8.4"

Looks like a bug to me.

On Thu, 8 Jun 2006, Logan Capaldo wrote:

> => false
> irb(main):005:0> sym
> => :"a symbol"
> irb(main):006:0> YAML.load(YAML.dump(sym))
> => :"\"a symbol\""
> irb(main):007:0> VERSION
> => "1.8.4"
>
> Looks like a bug to me.



   harp:~ > irb -r yaml
   irb(main):001:0> sym = :"a symbol"
   => :"a symbol"
   irb(main):002:0> sym == sym
   => true
   irb(main):003:0> sym == YAML.load(YAML.dump(sym))
   => true
   irb(main):004:0> sym
   => :"a symbol"
   irb(main):005:0> YAML.load(YAML.dump(sym))
   => :"a symbol"
   irb(main):006:0> VERSION
   => "1.8.4"


looks like a bad ruby to me.  a package installer?  mine is compiled on 
rhe and
seems to work fine?


-a

On Jun 7, 2006, at 2:53 PM, ara.t.howard@noaa.gov wrote:

>> => true
>
>   => :"a symbol"
>
> -a
> -- 
> suffering increases your inner strength.  also, the wishing for  
> suffering
> makes the suffering disappear.
> - h.h. the 14th dali lama
>

Compiled from source on OS X. Yay! A platform-specific problem. My
favorite.

On Thu, 8 Jun 2006, Logan Capaldo wrote:

> Compiled from source on OS X. Yay! A platform-specific problem. My favorite.

ah.  bummer.  this is what's kept me from moving to mac - seen too many 
of
these thus far.  guess i'll have to wait a while more ;-(

cheers.

-a

Hi --

On Thu, 8 Jun 2006, Logan Capaldo wrote:

>>> irb(main):002:0> sym = :"a symbol"
>>> => "1.8.4"
>>  irb(main):003:0> sym == YAML.load(YAML.dump(sym))
>> and
> Compiled from source on OS X. Yay! A platform-specific problem. My favorite.
I think it's a platform-specific solution -- that is, it only works on
Ara's computer :-)  I get the same results you get, on my Mac and on
a PC running Fedora.  I guess RHE must have patched Ruby in some way.


David

On Thu, 8 Jun 2006 dblack@wobblini.net wrote:

> I think it's a platform-specific solution -- that is, it only works on
> Ara's computer :-)  I get the same results you get, on my Mac and on
> a PC running Fedora.  I guess RHE must have patched Ruby in some way.

nope - rhe uses ruby 1.6.8!  this is ruby compiled from source:

   harp:~ > ruby --version
   ruby 1.8.4 (2006-01-12) [i686-linux]

   harp:~ > ruby -r yaml -e'  p YAML.load(YAML.dump( :"foo bar" ))  '
   :"foo bar"

what's yours?

-a

Hi --

On Thu, 8 Jun 2006, ara.t.howard@noaa.gov wrote:

>
>  harp:~ > ruby -r yaml -e'  p YAML.load(YAML.dump( :"foo bar" ))  '
>  :"foo bar"
>
> what's yours?

   $ ruby -r yaml -ve 'p YAML.load(YAML.dump( :"foo bar" ))'
   ruby 1.8.4 (2005-12-24) [i686-linux]
   :"\"foo bar\""

Interesting.  What's the 2006-01-12 1.8.4?


David

On Thu, 8 Jun 2006 dblack@wobblini.net wrote:

>> nope - rhe uses ruby 1.6.8!  this is ruby compiled from source:
>  ruby 1.8.4 (2005-12-24) [i686-linux]
>  :"\"foo bar\""
>
> Interesting.  What's the 2006-01-12 1.8.4?

ah.  i guess you guys don't run latest stable?  that 1.8.4 is getting 
old!

;-)

i've always use the latest stable compiled from source.  obviously i 
haven't
compiled for a bit - but this is just a development machine.

might want to try to compile a new ruby up and (before installing dear
readers!) see if that fixes issues.  don't forget to re-compile any 
binary
exts!

regards.


-a

On Thu, Jun 08, 2006 at 07:09:44AM +0900, dblack@wobblini.net wrote:
> On Thu, 8 Jun 2006, ara.t.howard@noaa.gov wrote:
> > harp:~ > ruby --version
> > ruby 1.8.4 (2006-01-12) [i686-linux]
> >
> > harp:~ > ruby -r yaml -e'  p YAML.load(YAML.dump( :"foo bar" ))  '
> > :"foo bar"
> 
>   $ ruby -r yaml -ve 'p YAML.load(YAML.dump( :"foo bar" ))'
>   ruby 1.8.4 (2005-12-24) [i686-linux]
>   :"\"foo bar\""

At the risk of accusing Ara of being ahead of the curve, a patch was 
committed
in January by ocean. [1]  I think Ara's got a branch snapshot.  Sounds 
like a
good time to bring up 1.8.5 on ruby-core again.

Thanks everyone!

_why

[1] 
http://rubyforge.org/tracker/func=detail&atid=1698&aid=2535&group_id=426

If your question is only whether ruby is better than python - yes, it
is. =)

There are some smaller things that lack some bug fixes but in all
fairness I believe python has an advantage because more people are using
it (at least they dont write japanese docu only, and i really dislike
that there is so much docu in only-japanese available)

Ruby is beauty, Python is not.

For me, this sold me on Ruby. (Well ok, I try to write beautiful Ruby
code. I dont like obfuscation at all.)

How did this thread get hijacked?

I'm changing it back.

Matthew Smillie wrote:
> For big values of long - your guess is likely as good as mine, but I'd
> pick Lisp.  Four decades and still going strong.
Actually, Lispnik Paul Graham is "redesigning" Lisp to last 100 years
(from now). Do a search for "Paul Graham" and "ARC" to see what he's
proposing. It hasn't moved a lot recently; perhaps he's leaning towards
jumping on the Ruby bandwagon. :)

> And as a result, "business acceptance" in its traditional sense is
> becoming less relevant to language design because typical businesses
> are contributing less to language design; essentially nothing in
> direct terms, and even their marginal contribution of providing jobs
> to direct contributors (i.e. jobs not involving those contributions)
> is proportionally lower than it ever has been.
Hmmm ... well, maybe business didn't contribute much to the design of
*Ruby*, but C, C++, C#, Java, Visual Basic, APL and Fortran were
designed by businesses!

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

On 8-Jun-06, at 12:33 AM, M. Edward (Ed) Borasky wrote:

> Matthew Smillie wrote:
>> For big values of long - your guess is likely as good as mine, but  
>> I'd
>> pick Lisp.  Four decades and still going strong.
> Actually, Lispnik Paul Graham is "redesigning" Lisp to last 100 years
> (from now). Do a search for "Paul Graham" and "ARC" to see what he's
> proposing. It hasn't moved a lot recently; perhaps he's leaning  
> towards
> jumping on the Ruby bandwagon. :)

Not to hijack the thread, but make a casual comment regarding Arc.
Paul Graham has done a lot for the Lisp community, however, he's
basically gone in and said "look how great lisp is" while in the same
breath stating, "but wait, ignore it, I'm redesigning it making it
better, but I don't have anything yet, stay tuned". Which essentially
killed a lot of the forward momentum and acceptance of lisp. He's not
exactly someone I'd point to if I were trying to make the point
you're trying to make.

--
Jeremy Tregunna
jtregunna@blurgle.ca


"One serious obstacle to the adoption of good programming languages
is the notion that everything has to be sacrificed for speed. In
computer languages as in life, speed kills." -- Mike Vanier

On Jun 8, 2006, at 5:33, M. Edward (Ed) Borasky wrote:

> Matthew Smillie wrote:
>> For big values of long - your guess is likely as good as mine, but  
>> I'd
>> pick Lisp.  Four decades and still going strong.
> Actually, Lispnik Paul Graham is "redesigning" Lisp to last 100 years
> (from now). Do a search for "Paul Graham" and "ARC" to see what he's
> proposing. It hasn't moved a lot recently; perhaps he's leaning  
> towards
> jumping on the Ruby bandwagon. :)

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.

>> And as a result, "business acceptance" in its traditional sense is
>> becoming less relevant to language design because typical businesses
>> are contributing less to language design; essentially nothing in
>> direct terms, and even their marginal contribution of providing jobs
>> to direct contributors (i.e. jobs not involving those contributions)
>> is proportionally lower than it ever has been.
> Hmmm ... well, maybe business didn't contribute much to the design of
> *Ruby*, but C, C++, C#, Java, Visual Basic, APL and Fortran were
> designed by businesses!

Dennis Ritchie, Bjarne Stroustrup, and James Gosling (and their
colleagues and collaborators) may disagree with your assertion that
they are 'businesses' rather than 'people'.   APL emerged out of
Harvard's proto-CS department (not really a business), though the
name of its creator eludes me.  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).

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 any case, it wasn't the Suns, Microsofts, and IBMs of the world
that I was talking about, but those companies who aren't in the
business of creating languages and tools, but merely sit on the
sidelines and say "but is it Acceptable to Business?  I won't let you
use it unless it's Acceptable to Business."  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.

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.

What I'm trying to point out is that standing on the sidelines saying
"wow, you've got a really nice project there, maybe you should make
it Acceptable to Business so I can use it" is an unrealistic
solution,  at least in part because the implicit threat of "or noone
will ever give you money for it" isn't particularly true anymore.

matthew smillie.

Jeremy Tregunna wrote:
> killed a lot of the forward momentum and acceptance of lisp. He's not
> exactly someone I'd point to if I were trying to make the point you're
> trying to make.
I think he also said something along the lines of "all Ruby needs to be
better than Lisp is Lisp-style macro capabilities." If he didn't,
someone did, and whoever said it, I agree. :) Still, designing a
programming language is more about choosing what to leave out than what
to put in.

So ... on the main thread, where are we?

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

> So ... on the main thread, where are we?

Well, the main thread was about how long will it be until selling Ruby
to corporations becomes easy. Because people like to work.

The interesting thing is that if you have Gmail, the hijacked version
of the thread -- with all its mentions of Lisp -- is showing me ads
for jobs at Google, Art & Logic, and Jane Street Capital.

Talk about Lisp and Ruby enough in Gmail, and all you get is job ads.

Not to be totally intractable, but I think this totally proves my
earlier point, that people who are looking for good programmers are
much better customers than people who want you to code in Language X.

On the other hand, the Google job ads are all for Java jobs, so,
whatever. Who knows.

The original post's title: "I love Ruby - But how bright is Ruby's 
future?"
Also from the original post: "I love Ruby but I don't want to waist 
[sic] my
time with a laguage [sic] that may not have a future." Fundamentally, 
this
has nothing to do with how long it will take to sell Ruby to 
corporations.

I tried to establish that widespread adoption by corporate IT shops (in 
the
way that has been achieved by Java) would be a good way to ensure that 
Ruby
has a bright future. But the consensus of the thread (as I read it) is 
that
widespread adoption by business is not material to Ruby's success, and 
is at
least suspicious when considered as a goal for the Ruby community.

Ruby can clearly be sold to programmers on its merits as a programming
language. (It can't be sold to IT managers on that basis, but our sense 
is
that their acceptance doesn't really matter.) Beyond that, I'm not sure 
if
we've come any closer to answering the original question.

Matthew Smillie <M.B.Smillie@sms.ed.ac.uk> writes:
> name of its creator eludes me.  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.  Perhaps you've heard of Backus-Naur Form as well?

Steve

On 6/8/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> The original post's title: "I love Ruby - But how bright is Ruby's future?"
> Also from the original post: "I love Ruby but I don't want to waist [sic] my
> time with a laguage [sic] that may not have a future." Fundamentally, this
> has nothing to do with how long it will take to sell Ruby to corporations.
>
> I tried to establish that widespread adoption by corporate IT shops (in the
> way that has been achieved by Java) would be a good way to ensure that Ruby
> has a bright future.

???

"Fundamentally, [the brightness of Ruby's future] has nothing do with
how long it will take to sell Ruby to corporations...widespread
adoption by corporate IT shops...would be a good way to ensure that
Ruby has a bright future."

???

????????????????????????????????

**jaw hanging open**

**totally not getting it**

> But the consensus of the thread (as I read it) is that
> widespread adoption by business is not material to Ruby's success, and is at
> least suspicious when considered as a goal for the Ruby community.

well, a lot of new people are coming to the Ruby community via Rails.
I can't speak for everybody but that's a big part of what brought me
here. and the thing is, if you look into the roots of Rails, the
company it came from, 37 Signals, they're very strident and hardcore
about the difference between corporations and business. in fact a lot
of the norms of corporate IT departments are viewed pretty scornfully
by those guys (e.g., "Meetings Are Toxic," "There's Nothing Functional
About A Functional Spec," Jason Fried's rants about the way things are
generally done in corporate IT departments).

I think there's definitely a difference between corporations and
business in general. I think widespread adoption by **corporations**
is viewed suspiciously. I could be wrong tho.

I think the general opinion might be that corporate IT departments are
bright for Ruby's future as a source of income but dark for its future
as a beautiful language. But that could be wrong. As I understand it
Ruby is pretty mainstream in Japan.

Giles: I can't say anything about Japan. I was using the word "business" 
to
mean "corporate IT." Given that you make the distinction between
old-fashioned, hidebound corporate IT and other kinds of businesses, 
then I
can see the point you're making.
And you're probably right.

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

Giles Bowkett wrote:

> ... 
> I think there's definitely a difference between corporations and
> business in general. I think widespread adoption by **corporations**
> is viewed suspiciously. I could be wrong tho.
> 

In the USA, it is nigh impossible to run a business without also being
incorporated.  Even non-businesses, such as Ruby Central, are Inc.'ed.

But I think I get your point.

When I had a Real Job, I was glad when I was able to move from VB to
Java, largely because I got to work with some very smart people writing
good, inventive Java.  I learned a lot and it was fun.

But a few years later, management changed, and what might be called the
Corporate Mindset took over.  So, I was still doing Java, but the
particulars were dictated: J2EE +iPlanet.  Ick.   We became framework
scripters.

No more using the language in whatever means was most appropriate.  They
  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.


--

James Britt

http://web2.0validator.com    - We're the Dot in Web 2.0
http://refreshingcities.org   - Design, technology, usability
http://yourelevatorpitch.com  - Finding Business Focus
http://www.jamesbritt.com     - Playing with Better Toys

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

jp

Matthew Smillie 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. :) 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

http://linuxcapacityplanning.com

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

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

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]http://www.ruby-forum.com/topic/68101#87612

Jeff Pritchard 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. :)
> 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. :) <ducking>
> 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. :)
> 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. :)

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

M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

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

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

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 Temple
http://www.curi.us/blog/

Elliot Temple 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. :)
>
> 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

http://linuxcapacityplanning.com