Ten Things Every Java Programmer Should Know About Ruby

[Navindra Umanee]

No matter what you say, I prefer doing interpolation over " + " anyday.
I've writtent 15 times the amount of java code in thepast few months for
work-related reasons then i have in ruby, you would think I'd prefer the
" + " way...

I have to say you've quite convinced me. Now that you mention it, I'm
myself quite sick of those long text string issues you bring up with
Java. It's nice that Ruby does interpolation similar to the way we're
used to with shell scripts.

And besides, I've found you can somewhat simulate the Java behaviour
anyway:

class String
def -(arg)
to_s + arg.to_s
end
end

p "one: " - 1 - " two: " - 2

Thanks for the tips and insightful commentary to you and Joao. I'd be
interested in seeing the Rails code for recursive require.

Cheers,
Navin.

 

[Navindra Umanee]

Sorry to reply to myself, but I didn't think that you were complaining
of the interpolation, which is plenty useful when passing code around
to be evaluated (eval).

Well, I wasn't really. It was just a trite comment on the
variable/field syntax itself as you remarked.

Cheers,
Navin.

 

[Zach Dennis]

Thanks for the tips and insightful commentary to you and Joao. I'd be
interested in seeing the Rails code for recursive require.

This isn't Rails code, but it's recursive loading code:

def require( str )
if File.exist?( str )
Dir["#{str}/**/*.rb"].each do |file|
require file[0..-4]
end
else
super
end
end

Make a test few subdirectories "mymodule", and a few directories beneath
that, and a few test ".rb" scripts....

require "mymodule"

will recursively load all the .rb files in the directory mymodule and
subdirectories.


Zach

 

[Zach Dennis]

Thanks for the tips and insightful commentary to you and Joao. I'd be
interested in seeing the Rails code for recursive require.

This isn't Rails code, but it's recursive loading code:

def require( str )
if File.exist?( str )
Dir["#{str}/**/*.rb"].each do |file|
require file[0..-4]
end
else
super
end
end

bah typo snuck in there!! Although it'll still work with the typo. This
should be:

def require( str )
if File.directory?( str )
Dir["#{str}/**/*.rb"].each do |file|
require file[0..-4]
end
else
super
end
end

sorry about that,

Zach

 

[Tobias Luetke]

If you want to convince java folks of the merits of ruby introduce
them to rails.

Rails is what ruby has going for it in praxis.

They will be convinced of ruby all by themselves because ruby is what
makes rails possible.

 

[Joel VanderWerf]

On the other hand, if you *want* to put each class in a file, you end
up having to painfully "require" each file every time you want to
access a class. Java can automatically find classes in the current
package and load them. Or is just me? Is there a Ruby Way?

autoload?

 

[Joel VanderWerf]

All but variables, blocks (which are not Procs), methods (which are not
Methods and not even UnboundMethods, which are both mere wrappers) and,
for all practical purposes, every single bit of code, because even though
Ruby stores all the method code as trees of objects ("AST"), those are not
exposed to the user, so they don't count.

Any other exceptions to the rule I might be missing ?

The ruby interpreter itself. (Maybe someday ruby will have multiple
interpreters.)

 

[ts]

Z> yes...so yes!!

eval is evil, to paraphrase someone else

"You never know what is evil unless you know what is more than evil"



Guy Decoux

 

[Robert Klemme]

We will be introducing Ruby to our XP Users group in Cincinnati next week.
I thought it would be fun to create a list of "Ten Things Every Java
Programmer Should Know About Ruby" to help the transition. I've got a
number of things in my head, but would love to hear ideas from the mailing
list.

So go ahead and submit your ideas. What things should a Java programmer
be aware of when starting out in Ruby?

There are no interfaces - and you don't need them.

There are anonymous functions, called "blocks" or "lambdas". Learn to use
them.

Use IRB.

"finally" is called "ensure". Use blocks for transactional behavior like
File.open() does.

Cou can find help here:
http://www.ruby-doc.org/
http://www.ruby-lang.org/en/

Strings are mutable but can be frozen.

Don't worry if your Ruby program is half LOC of the same Java program. As
soon as you get experienced this will drop to one fourth or less.

"Serializing" is called "marshalling" in Ruby.

You can keep your habit of ending every statement with a semicolon - but
without them Ruby code looks much better.


Kind regards

robert

 

[Peter Hickman]

We will be introducing Ruby to our XP Users group in Cincinnati next week.
I thought it would be fun to create a list of "Ten Things Every Java
Programmer Should Know About Ruby" to help the transition. I've got a
number of things in my head, but would love to hear ideas from the mailing
list.

So go ahead and submit your ideas. What things should a Java programmer
be aware of when starting out in Ruby?

You will end up writing less code and it will do more.

 

[PA]

You will end up writing less code and it will do more.

And then you will be rightly reward by sharing the fait of most
software projects 8^)

“Managing complexity”
Most software projects fail to meet their goals.
-- The Economist, Nov 25th 2004
http://www.economist.com/business/PrinterFriendly.cfm?Story_ID=3423238

Cheers

 

[Joao Pedrosa]

Hi,

And then you will be rightly reward by sharing the fait of most
software projects 8^)

"Managing complexity"
Most software projects fail to meet their goals.
-- The Economist, Nov 25th 2004
http://www.economist.com/business/PrinterFriendly.cfm?Story_ID=3423238

Remember that Ruby is more than a decade old. It has been used
successfully in the US, in Japan and in many other places. People have
created many frameworks on which we can depend if we wish to keep the
complexity lower. Ruby as a dynamic language provides means for rapid
development and prototyping, which can prove much sooner if an idea
works or not. If it works and the prototype is good enough, ship it.


If you are in an ethernal fight with the language then the goal seems
farther away, nothing that one year of development (like we hear from
time to time) does not fix.

AOP; EJB; JDO vs O/R mapper vs JDBC; which framework to use? which
sub-framework to use?; standardize on an IDE? what one? IntelliJ,
Eclipse, NetBeans, JBuilder, etc.; JSP vs tag-libs vs Velocity vs JSF
etc.; Buy some "cheap" J2EE App Server? Use JBoss and pay for support?
Use JBoss and don't pay for support?; Write once and run anywhere, as
long as it's on the server?

Etc.

Yeah, complexity kills projects.

Cheers,
Joao

 

[PA]

Yeah, complexity kills projects.

The only thing I wanted to "subtly" hint at is that implementation
languages are the least important factor in the ultimate success and/or
failure of a project.

In other words, an implementation language of any sort is not a silver
bullet of any sort.

After all, blaming or praising a language for your own success or
failure would be equivalent to a writer blaming its pen for "writer's
block".

Cheers

 

[Joao Pedrosa]

Hi,

The only thing I wanted to "subtly" hint at is that implementation
languages are the least important factor in the ultimate success and/or
failure of a project.

In other words, an implementation language of any sort is not a silver
bullet of any sort.

After all, blaming or praising a language for your own success or
failure would be equivalent to a writer blaming its pen for "writer's
block".

Maybe you are right. I just wish that Sun had supported Ruby instead
of Java. That's all.

Regards,
Joao

 

[Kristof Bastiaensen]

All but variables,

Variables are placeholders for objects. Though there may be a good point
here (since variables can refer to more than one object).

blocks (which are not Procs),

Blocks are objects. Even anonymous blocks, thought they cannot be
manipulated as such (they are anonymous, right?).

methods (which are not
Methods and not even UnboundMethods, which are both mere wrappers) and,

Methods are part of objects. So they do belong to the object-system.

for all practical purposes, every single bit of code, because even
though Ruby stores all the method code as trees of objects ("AST"),
those are not exposed to the user, so they don't count.

That's implementation specific, but the Ruby language doesn't specify
that, so it isn't strictly part of the language. For example a Ruby
program could be converted to a fpga, or will run in the future on some
weird hardware that we cannot imagine now.

Kristof

 

[James Britt]

In other words, an implementation language of any sort is not a silver
bullet of any sort.

After all, blaming or praising a language for your own success or
failure would be equivalent to a writer blaming its pen for "writer's
block".

But each can have significant influence. If you are trying to write
something out in longhand , and your pen weighs 700 pounds, it will take
a little longer to complete, and you will be a little less likely to
explore possibilities that don't show immediate payoff. You may also be
less likely to go revise earlier work, and may be more willing to settle
for a less-than-ideal end result.


James

 

[Curt Hibbs]

But each can have significant influence. If you are trying to write
something out in longhand , and your pen weighs 700 pounds, it will take
a little longer to complete, and you will be a little less likely to
explore possibilities that don't show immediate payoff. You may also be
less likely to go revise earlier work, and may be more willing to settle
for a less-than-ideal end result.

Excellent point and analogy -- I'm going to save this!

Curt

 

[PA]

But each can have significant influence. If you are trying to write
something out in longhand , and your pen weighs 700 pounds, it will
take a little longer to complete, and you will be a little less likely
to explore possibilities that don't show immediate payoff. You may
also be less likely to go revise earlier work, and may be more willing
to settle for a less-than-ideal end result.

Well, in practice, the choice is more like between a Montblanc or a
Faber. Same difference.

Plus I have become quite proficient at manipulating halbards 8^)

http://www.angelfire.com/games2/cautionwetpaint/gallery2/
2_GK_Halbard_front.jpg

Cheers

 

[James Edward Gray II]

def require( str )
if File.directory?( str )
Dir["#{str}/**/*.rb"].each do |file|
require file[0..-4]
end
else
super
end
end

This seems to make a nice entry for the list of things to tell Java
programmers:

* If a Ruby core method isn't behaving quite like you need it to, just
edit it to fit your task.

James Edward Gray II

 

[Hugh Sasse Staff Elec Eng]

But each can have significant influence. If you are trying to write
something out in longhand , and your pen weighs 700 pounds, it will take a

You don't need a 700 pound pen for this analogy: There has been a
progression in writing systems that could possibly be said to
parallel the progression in programming systems:
Cunaeform, Hyeroglyphics and other systems of marking clay.
[direct machine code input]
Quills, and possibly dip pens with wet ink.
[Assemblers -- one can instruct someone to "carve this"]
Ballpoint pens, pencils
typewriters
[compilers, interpreters -- the process is that much easier]
Wordprocessors.
[Code generators? Refactoring tools?]

These have affected how people write as well...

little longer to complete, and you will be a little less likely to explore
possibilities that don't show immediate payoff. You may also be less likely

Ballpoints and pencils facilitate making notes anywhere.
The typewriter sped up writing legibly considerably.

to go revise earlier work, and may be more willing to settle for a
less-than-ideal end result.

This last point is interesting: being able to churn out fiction can,
it is sometimes argued, allow people to produce lots of lower
quality work than if they have to rework parts. I'm not sure how one
applies that point to programming though, but maybe we are still at
the typewriter stage. Is there any evidence that refactoring
browsers allow people to "leave quality till later" and never get
back to fix it? There are other factors at work though, not just
the tools: time pressure for one.

The above should be taken with a bucket of salt, I've no substance
to support this analogy, so it may be worthless.

James

Hugh