Forum: Ruby Syntax

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
71f1b6b2c3fd9af2e8c52618fb91caa6?d=identicon&s=25 Jules Jacobs (jules)
on 2006-01-29 18:05
Hi,

Which syntax do you like most?

1. if
-----

# block-by-indentation

if a == 10
  print a

# Java/C, etc style

if(a == 10)
{
  print(a);
}

# Ruby style

if a == 10
  print a
end

2. Rails' link_to
-----------------

link_to 'Show', :action => :show, :id => @post

link_to 'Show', action: 'show', id: @post

link_to 'Show', action: :show, id: @post

link 'Show', to: {action: 'show', id: @post}

3. Classes
----------

# Ruby

class Foo
  def method
    print 'hi'
  end
end

# Indentation

class Foo
  def method
    print 'hi'

4. Loop
-------

5.times i
  print i

5.times do |i|
  print i
end

for 0, 5, i
  print i
end

5. Map
------

arr = [1, 2, 3]

arr.map{|e| e * 2}

arr.map do |e|
  e * 2
end

arr.map(e, e * 2)

arr.map(e * 2) # variable is 'e' (element) by default

or maybe:

arr = new Array();
arr.add(1);
arr.add(2);
arr.add(3);

for(i = 0; i < arr.length(); i++)
{
  arr[i] = arr[i] * 2;
}

;-)

--------------

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.

I also prefer this:

arr.map(e, e * 2)

or:

# parentheses are optional
arr.map e, e * 2

to this:

arr.map{|e| e * 2}

I'm not sure whether or not default variable names like this:

arr.map(e * 2)

are a good thing...

What do YOU like, and why?

Thanks in advance,

Jules
66247570dbe0c350a165cdabc2769ba1?d=identicon&s=25 Paul Robinson (Guest)
on 2006-01-30 11:20
(Received via mailing list)
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.
170bd539f12a1f93b2bd122183ed1cba?d=identicon&s=25 Matthias Ludwig (Guest)
on 2006-01-31 20:21
(Received via mailing list)
Hi,

> 1. if

I like ruby-syntax.
I like this one:

print a if a == 10

it's very bad, i know ;)

> 2. Rails' link_to

hmm, good question...
i use this one:
> link_to 'Show', :action => :show, :id => @post

> 3. Classes

full ACK to Ruby-Syntax...

> 4. Loop

this looks cool (maybe with an "end") because it's short:
> 5.times i
>   print i

but the "short" ruby one is ok, too:

5.times {|i| print i}

> 5. Map

i use this:
> arr.map{|e| e * 2}

to much letters: ;)
> arr.map do |e|
>   e * 2
> end

looks very nice:
> arr.map(e, e * 2)

grr, i want to know what happens to my vars...
i don't like this much:
> arr.map(e * 2) # variable is 'e' (element) by default

Matthias
F0223b1193ecc3a935ce41a1edd72e42?d=identicon&s=25 Zach Dennis (Guest)
on 2006-02-01 02:25
(Received via mailing list)
Jules Jacobs wrote:
> Hi,
>
> Which syntax do you like most?

> # Ruby style
>
> if a == 10
>   print a
> end

I prefer:
   print a if a == 10

>
> 2. Rails' link_to
> -----------------
>
> link_to 'Show', :action => :show, :id => @post

I prefer this one. It is the easiest to visual parse imo.

> end
I prefer this.

>
> for 0, 5, i
>   print i
> end

For multi-line loops I prefer the do/end syntax if you are *not* using
the return value. I prefer {} for one line loops unless you are using
the return value. Examples:

   5.times{ |i| print i }

   5.times do |i|
       #do something here
   end


> end
If you are going to use the return value of 'map', I prefer to use {}. I
you aren't going to use the return value and it is a one liner, I prefer
to use {}. If you aren't going to use the return value and it is not a
one liner then use the do/end block.


>
> arr.map(e, e * 2)

As already pointed out it looks like your passing arguments.

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

I don't think an indendation style should drive the syntax and meaning
of code. This is one of the reasons I dont like Python. Paul's analogy
of the motoroboat and the ocean is a great analogy imo.

> to this:
>
> arr.map{|e| e * 2}


I disagree, I think |e| makes it easy to visually parse what is going
on. It also lets you bind the value you are passing in to a variable
name that makes sense to that block of code.

>
> I'm not sure whether or not default variable names like this:
>
> arr.map(e * 2)
>
> are a good thing...
>
> What do YOU like, and why?

Your map example is an easy example though. How would you consistently
support things like?
    { :hash=>true }.each { ??? }
    [1,2,3,4,5].inject( 0 ) { ???? }

Here I like the flexibility of ruby to name the variable I am going to
bind the passed in value to.
    string.each_line{ |line| puts line.gsub /a/, '*' }

    files.each { |filename| ... }

    File.open 'file.txt', 'w' do |file|
      file.each{ |line| ???_what happens here_??? }
    end

And as you get more code in your blocks I think it makes more sense to
be able to provide a variable name that makes sense for the block of
code you're executing.

I think |varname| is an easy way to visually parse out that this value
is getting passed in here. Commas are list separators. By giving them
double meaning would make it confusing for a new user of your language.

Just my 2 cents.

Zach
2cf6d8e639314abd751f83a72e9a2ac5?d=identicon&s=25 Martin DeMello (Guest)
on 2006-02-01 23:43
(Received via mailing list)
Jules Jacobs <julesjacobs@gmail.com> wrote:
>
> 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.
>

If you want to see a language with really pretty syntax, take a look at
Haskell

martin
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2006-02-03 03:14
(Received via mailing list)
Hi,

In message "Re: Syntax"
    on Mon, 30 Jan 2006 02:05:38 +0900, Jules Jacobs
<julesjacobs@gmail.com> writes:

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

Welcome to the wonderful world of language designers.

But I recommend you to squeeze your brain first to set up your own
opinion over the 'perfect' language, before asking people the best
way.  You need to have firm, well-thought idea about the 'good'
languages to be a successful language designer.  You also need a lot
of luck to success.  But it's another story.

							matz.
This topic is locked and can not be replied to.