Paul Robinson
1/30/2006 10:19:00 AM
On 29 Jan 2006, at 17:05, Jules Jacobs wrote:
> Which syntax do you like most?
The one that is closest to working the way I think. :-)
> # block-by-indentation
>
> if a == 10
> print a
I get what you're saying here, but this makes white-space important,
and I actually think it makes it all more ambiguous. Especially when
you consider the cost of making it more readable is just one extra line:
> if a == 10
> print a
> end
Not much to ask. And still 10x better than the Java/C version which
looks like a 3 year old has been scribbling on it.
> link_to 'Show', :action => :show, :id => @post
I learnt Rails from the Agile book, so I've got used to this syntax.
> link_to 'Show', action: 'show', id: @post
> link 'Show', to: {action: 'show', id: @post}
I didn't realise that was valid syntax until I read your post - I've
only been doing Ruby for less than a year, and not 100% full-time, so
I still get caught out from time to time. :-) Mildly more readable
for somebody who is new to programming, a bit of a head-scratcher for
somebody used to doing things the "Rails Way"
> # Indentation
>
> class Foo
> def method
> print 'hi'
That is horrid. Genuinely. I'd be sat there staring at the screen
wondering when the other boot was going to drop.
> 5.times do |i|
> print i
> end
That's a bit verbose. What's wrong with '5.times {|i| print i}' ?
> arr.map{|e| e * 2}
See, once you "get" associated code blocks, yield and this syntax,
that's just beautiful. To a new-comer it's horrid though.
> I am trying to imagine the 'perfect' scripting language (for me, at
> least ;-)). Ruby is close, but I prefer a different syntax in some
> cases. I find the indentation-based code-blocks nicer than
> do...end-blocks.
But that's because:
1. You probably indent your code perfectly every time. And of
course... errmmm... of course, I do as well... honest (thank you auto-
indenter code in my editor!)
2. You understand your program and don't need to be reminded that "an
end should be there, that's where we stop doing that bit"
3. You probably learnt to program when COBOL was popular. :-P
There is virtually nothing more annoying than trying to debug code
that isn't working properly and finding the error is in the white-
space. It's like being in a motorboat that breaks down and finding
that to fix it you should ignore the engine and instead spend your
time trying to fix the ocean...
> I also prefer this:
>
> arr.map(e, e * 2)
I see what you're saying, but that looks like you're passing e and e
* 2 as arguments to a method to me. Like map should be taking 1 and 2
where e = 1, and it's not obvious what it would be doing to it. I'd
need to go and look at the method documentation before I
realised .map was an iterator in this case, not a straight method
call. Then I'd get confused as to why we weren't doing something like
Map.iterate(arr, arr * 2) which is even more hideous.
The advantage of the rather 'strange' syntax we have now is that it
is *obviously* an iterator once you know what Ruby iterators look
like. It is obvious what the intended behaviour is, even if you've
never seen .map before, because you can guess.
> # parentheses are optional
> arr.map e, e * 2
That just makes it even more compounded a head-scratcher.
> I'm not sure whether or not default variable names like this:
>
> arr.map(e * 2)
>
> are a good thing...
Definitely not. I might have inadvertently used e as a variable
somewhere else (hey, I like short variables for throw-away items) and
it would suddenly confuse the heck out of the next coder to come
along trying to maintain my code.
Just my 2p worth.
--
Paul Robinson