On Sunday 13 December 2009 06:47:14 pm Florian G. wrote:
On Dec 13, 2009, at 8:49 PM, David M. wrote:
On Sunday 13 December 2009 06:02:23 pm Florian G. wrote:
Okay, flame on ;)!
Well, if you want…
It was more meant as a joke. Remember: pack irony tags next time ;).
Oh, I got it. The smiley was a dead giveaway, right? 
Never, such a feature should not be optional.
If you mean you hate it so much you don’t want to see it, fine.
If you mean you’d like to see it go one way or another, that’s
interesting.
Parentheses are often optional in Ruby. I think options are good –
coding
conventions should be enforced by the project, not the language.
[snip]
While options are good (I do have my fair share of strange patterns I
love
to use as well), you can also over-cramp the language with options. As
I wrote,
I would love to see literal Ruby and actually thought about
implementing it.
But on such a scale, that would mean two and a half things:
- your project is not accepted and a lot of unnecessary work
That’s the purpose of this poll. If there’s no interest, I probably
won’t
bother.
2a. your idea is accepted into core
2b. you introduce a hard community split - those who install you
library and
those who don’t.
I don’t see where this is a huge problem. If it really can be a library,
there
are either those who adopt it or those who don’t. For example, Rails
introduces the .map(&:foo) idea, which eventually made it into core. It
also
introduces 5.hours.ago, 2.minutes.from_now, and ‘octopus’.pluralize,
none of
which will ever make it into core. And it’s far from the only library to
hack
all over core.
It would be especially non-problematic if it had a tool similar to
lazibi, so
that people who absolutely couldn’t stand it could convert it back.
But even as it is, we still have a few Lisp people who throw parentheses
around EVERYTHING in Ruby, a few people moving from C and other
languages who
find it just weird to define a method without parentheses, even if it
won’t be
used that way:
def foo(options)
…
end
foo :bar => :baz
And of course, we have people who use define_method and other
metaprogramming
techniques, and people who pipe things into eval, and people who store
configuration as Ruby scripts, and people who store it as Yaml, and
people who
write their own storage format.
I don’t think those who cry out in agony at the mere sight of
significant-
indentation code will really have more trouble reading and maintaining
it than
I would maintaining lisp-style Ruby.
For that matter, did you know Ruby 1.9 now supports this JSON-like
syntax
natively?
{
a: ‘b’,
c: 5
}
=> {:a=>“b”, :c=>5}
The new lambda syntax is cool, too:
-> { puts “I’m a lambda!” }
So I don’t think this is an issue – there are as many ways to write
Ruby than
there are other programming languages, and new versions can add new
syntax. I
think backwards-compatibility and parser manitainability are much bigger
concerns. That is, if my idea is a complete flop, it shouldn’t affect
anyone
else.
By the way: This post is a defense for the idea of alternate syntax.
I’m not
going to start advocating it again just yet.
