2- Try to not think about interfaces, but enjoy fully the dynamic typing.
*Think* about interfaces, but for yourself, not for the compiler's
benefit. Don't *worry* about interface. Still enjoy fully the dynamic
typing.
5- Don't worry about performance until the program/library has been made.
In any language, I'd say, think about global performance issues before
writing the program (or at every major refactoring), but don't worry about
local performance issues until everything works. When one says "premature
optimisation is the root of all evil" it's usually implied that it's about
local optimisations.
10- Ruby is not a Silver Bullet, unlike Java, right?
Java's marketing/gospel/selfcontradiction/bellythinking department has
caused a lot of harm, so when looking at which preconceptions to drop
first, start there!
11- Reflection in Ruby is much easier than in Java, and more deeply into
the language than the java.lang.reflect tack-on.
12- eval.
13- the builtin classes are much faster because they're written in C and
not Ruby, and this should be taken into account. (same as for
Perl/Python/Tcl/...)
Well, Ruby does not have a lot of things, but listing them will not
always explain anything.
I would rephrase this as, "Ruby has types, but does not need type casting."
Or, simply, "Ruby does not need type casting."
I'm wondering, too, if the things to list can be divided into aspects
common to most dynamically typed languages and features largely
specific to Ruby.
So one could start with, 'Ruby has strong, dynamic typing, which
means, among other things: [list of stuff]'
Then, "And in addition to all the goodness of a dynamically-typed
language, Ruby has [blocks, closures, continuations, ...]
One could also make distinctions between features built into the
language (e.g. blocks, continuations) and features available through
bundled or otherwise available libraries (REXML, YAML, O/R mapping,
Rake).
James
···
On Fri, 28 Jan 2005 03:35:11 +0900, Joao Pedrosa <joaopedrosa@gmail.com> wrote:
Edgardo Hames said:
> I would suggest that once you come up with the top ten list, it would
> be really nice if you did post it to the mailing list. I'd like to
> forward it to some friends.
I'm going to collect responses in a public Ta-Da list at Feedback on "Ten Things a Java Programmer Should Know About Ruby" (which is already way
over 10 items!). Later (possibly this weekend) I'll sort through the
collected suggestions, edit them down to my top ten and publish the
result.
Also, if you are creating a presentation, it would great if you'd be willing
to add your presentation to those hosted on the WhyRuby? project (on
RubyForge).
13- the builtin classes are much faster because they're written in C and
not Ruby, and this should be taken into account. (same as for
Perl/Python/Tcl/...)
This reminds me...
- C extensions/wrappers are *much* easier in Ruby than JNI interfaces in
Java.
On Fri, 28 Jan 2005 04:43:05 +0900, Mathieu Bouchard <matju@sympatico.ca> wrote:
On Fri, 28 Jan 2005, Joao Pedrosa wrote:
> 2- Try to not think about interfaces, but enjoy fully the dynamic typing.
*Think* about interfaces, but for yourself, not for the compiler's
benefit. Don't *worry* about interface. Still enjoy fully the dynamic
typing.
> 5- Don't worry about performance until the program/library has been made.
In any language, I'd say, think about global performance issues before
writing the program (or at every major refactoring), but don't worry about
local performance issues until everything works. When one says "premature
optimisation is the root of all evil" it's usually implied that it's about
local optimisations.
> 10- Ruby is not a Silver Bullet, unlike Java, right?
Java's marketing/gospel/selfcontradiction/bellythinking department has
caused a lot of harm, so when looking at which preconceptions to drop
first, start there!
11- Reflection in Ruby is much easier than in Java, and more deeply into
the language than the java.lang.reflect tack-on.
12- eval.
13- the builtin classes are much faster because they're written in C and
not Ruby, and this should be taken into account. (same as for
Perl/Python/Tcl/...)
Some of the things I like in ruby thinking directly about java... being both a ruby and java programmer:
- there is no type casting in ruby
- ruby has better loop constructs
- writing a class in ruby opposed to writing a class in java takes much less time
- ruby eliminates the # of (, ), {, and } 's
- you can use characters like ?, !, etc.. in your method names
- you can use string interpolation, ex: "x: #{@myvar}" instead of having to say "x:" + myvar'
- ruby doesn't force you to have 1 file per public class, you can have all the public classes you want in a file (not that you have to do this, but it's a nice option to have)
- ruby has multiple inheritance through mixins (this is sooo nice to have)
- ruby has a lower percentage of dr. diagnoses carpal tunnel sydrome cases then java (ok, this is just an opinion...=)
- writing code in ruby, can improve the code you write in java (i say this from prototyping code in ruby, then porting it to java at work, because ruby allows me to focus on the design of my code more. Once my design and testing is done in ruby it's so easy to port it to Java and my java code looks better since I was able to put better design into upfront, then having to worry about typing 18,000 lines of code including the following characters: ;, return, int, char, String, byte, , {}, (), etc... )
- ruby has shortcuts for accessor methods which reduces alot of redundant coding in java
I know I've got lots more, but I'm at work now...and need to get to that 5pm java deadline. =) If it were ruby it would have been done before lunch...
Zach
P.S. - Although ruby's gui's are coming along, I still find Swing the easiest RAD GUI to use, and yes over VB...I hate VB. And because of JRuby I can utilize Ruby Code and a Swing GUI. Ah...raw power.
James G. Britt wrote:
···
On Fri, 28 Jan 2005 03:35:11 +0900, Joao Pedrosa <joaopedrosa@gmail.com> wrote:
Hi,
1- Ruby does not have type casting.
Well, Ruby does not have a lot of things, but listing them will not
always explain anything.
I would rephrase this as, "Ruby has types, but does not need type casting."
Or, simply, "Ruby does not need type casting."
I'm wondering, too, if the things to list can be divided into aspects
common to most dynamically typed languages and features largely
specific to Ruby.
So one could start with, 'Ruby has strong, dynamic typing, which
means, among other things: [list of stuff]'
Then, "And in addition to all the goodness of a dynamically-typed
language, Ruby has [blocks, closures, continuations, ...]
One could also make distinctions between features built into the
language (e.g. blocks, continuations) and features available through
bundled or otherwise available libraries (REXML, YAML, O/R mapping, Rake).
Java's marketing/gospel/selfcontradiction/bellythinking department has
caused a lot of harm, so when looking at which preconceptions to drop
first, start there!
11- Reflection in Ruby is much easier than in Java, and more deeply into
the language than the java.lang.reflect tack-on.
Objection on # 2
Everything is *not* object.
By believing the quote 'in Ruby, Everything is object' already made my life hard.
Mohammad
···
On Thu, 2005-01-27 at 14:36, Jim Weirich wrote:
Edgardo Hames said:
> I would suggest that once you come up with the top ten list, it would
> be really nice if you did post it to the mailing list. I'd like to
> forward it to some friends.
I'm going to collect responses in a public Ta-Da list at Feedback on "Ten Things a Java Programmer Should Know About Ruby" (which is already way
over 10 items!). Later (possibly this weekend) I'll sort through the
collected suggestions, edit them down to my top ten and publish the
result.
> 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 Managing complexity
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
···
On Fri, 28 Jan 2005 19:48:28 +0900, PA <petite.abeille@gmail.com> wrote:
I would suggest that once you come up with the top ten list, it would
be really nice if you did post it to the mailing list. I'd like to
forward it to some friends.
I'm going to collect responses in a public Ta-Da list at Feedback on "Ten Things a Java Programmer Should Know About Ruby" (which is already way
over 10 items!). Later (possibly this weekend) I'll sort through the
collected suggestions, edit them down to my top ten and publish the
result.
just a note: I'd present mixin as "interface withouth the need to rewrite everything" more than "multiple inheritance replacement".
Anyway, great list, bookmarked
- ruby has a lower percentage of dr. diagnoses carpal tunnel sydrome
cases then java (ok, this is just an opinion...=)
Definitely in my case. I switced over a year into RSI and it makes a huge
difference.
I know a lot of Java coders who say 'use an IDE to generate code to save typing'
but i like to see what code is being written on my behalf. A tool to churn out
code smells like bandaid to a brokenly verbose language to me...
I prefer to use my keypresses wisely in solving my problem rather than nursing a
compiler.
REXML vs. JAXP. I rest my case.
···
--
'zzz..Kill all humans. Kill all humans..zzz .....
I was having the most wonderous dream. You were in it.'
-- Bender
Rasputin :: Jack of All Trades - Master of Nuns
On Fri, 2005-01-28 at 06:34 +0900, Mohammad Khan wrote:
On Thu, 2005-01-27 at 14:36, Jim Weirich wrote:
> Edgardo Hames said:
> > I would suggest that once you come up with the top ten list, it would
> > be really nice if you did post it to the mailing list. I'd like to
> > forward it to some friends.
>
> I'm going to collect responses in a public Ta-Da list at
> Feedback on "Ten Things a Java Programmer Should Know About Ruby" (which is already way
> over 10 items!). Later (possibly this weekend) I'll sort through the
> collected suggestions, edit them down to my top ten and publish the
> result.
Objection on # 2
Everything is *not* object.
By believing the quote 'in Ruby, Everything is object' already made my life hard.
Everything *is* an object in Ruby. Variables are labels for objects;
they aren't anything that a programmer can access in any way --
which makes them irrelevant to the consideration.
-austin
···
On Fri, 28 Jan 2005 06:34:22 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
On Thu, 2005-01-27 at 14:36, Jim Weirich wrote:
Edgardo Hames said:
I would suggest that once you come up with the top ten list, it
would be really nice if you did post it to the mailing list. I'd
like to forward it to some friends.
I'm going to collect responses in a public Ta-Da list at Feedback on "Ten Things a Java Programmer Should Know About Ruby" (which is
already way over 10 items!). Later (possibly this weekend) I'll
sort through the collected suggestions, edit them down to my top
ten and publish the result.
Objection on # 2 Everything is *not* object. By believing the
quote 'in Ruby, Everything is object' already made my life hard.
- you can use string interpolation, ex: "x: #{@myvar}" instead of
having to say "x:" + myvar'
Ruby seems to lose here. The syntax #{@myvar} is a rare case of
ugliness.
- ruby doesn't force you to have 1 file per public class, you can have
all the public classes you want in a file (not that you have to do this,
but it's a nice option to have)
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?
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
···
On Jan 28, 2005, at 12:28, Joao Pedrosa wrote:
"Managing complexity"
Most software projects fail to meet their goals.
-- The Economist, Nov 25th 2004 Managing complexity
