Re^4: Perl is more intuitive

in reply to Re^3: Perl is more intuitive
in thread Perl is more intuitive

Ah, I see.

Then if I'm new to the language and I'm reading someone's code, it may be harder for me to understand what's going on, unless the variables are named such as to give a hint e.g. arr_grades, hash_address.

Comment on Re^4: Perl is more intuitive

Replies are listed 'Best First'.
Re^5: Perl is more intuitive by Joost (Canon) on Aug 19, 2005 at 14:08 UTC
That's true, but rubys library design is based on the idea that you should not tie down the type of a variable in the syntax, because if you do that, polymorphism becomes a lot more difficult (c.f. Java's interfaces, or C++'s multiple-inheritance). Take this simple function: `def print_all(array) array.each do \|el\| puts el end end` [download] The name of the parameter is "array", but because there is no type indication, this will work just as well with a File (print each line) a Set (print every element of the set), a Struct or some other object that happens to have an each() method that works like this. According to the idiom, an each method should "walk through" a collection - as long as you use idiomatic design, your code will remain relatively easy to interpret. I like this strategy, but as you noted, it does have some drawbacks if you want to figure out what a complex piece of code does exactly, or when the idiom is broken. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l]

Replies are listed 'Best First'.

Re^5: Perl is more intuitive
by Joost (Canon) on Aug 19, 2005 at 14:08 UTC

Take this simple function:

def print_all(array)
   array.each do |el|
       puts el
   end
end
[download]

The name of the parameter is "array", but because there is no type indication, this will work just as well with a File (print each line) a Set (print every element of the set), a Struct or some other object that happens to have an each() method that works like this. According to the idiom, an each method should "walk through" a collection - as long as you use idiomatic design, your code will remain relatively easy to interpret.

I like this strategy, but as you noted, it does have some drawbacks if you want to figure out what a complex piece of code does exactly, or when the idiom is broken.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

[reply]
[d/l]

In Section Meditations