Why not adopt "Python Style" indentation for Ruby?
Chris Dew
used with properly indented code.
class Foo
def bar(value)
if value < 7
puts "hello"
else
puts "world"
end
end
def foobar
puts "foobar"
end
end
could be
class Foo
def bar(value)
if value < 7
puts "hello"
else
puts "world"
def foobar
puts "foobar"
with no reduction in meaning, yet 25% fewer lines of code.
What are the reasons why this isn't used/implemented/liked? It would
be a small change to the interpreter. Enabling meaningful indentation
would only make 'end' optional, not invalid; backwards compatibility
wouldn't be a problem.
(I use both Ruby and Python. I think indentation is one of the few
*language* features where Python leads Ruby.)
If this post generates a positive response, I'll make a patch for Ruby
1.9.
Yukihiro Matsumoto
In message "Re: Why not adopt "Python Style" indentation for Ruby?"
on Fri, 18 May 2007 16:25:03 +0900, Chris Dew <cms...@googlemail.com> writes:
|What are the reasons why this isn't used/implemented/liked?
Python style block by indentation is an interesting idea, but it works
badly with
* tab/space mixture
* templates, e.g. eRuby
* expression with code chunk, e.g lambdas and blocks
So I'd rather be conservative here.
matz.
Michal Suchanek
preserved literally
Thanks
Michal
Julian Leviston
Isn't end repeating yourself full stop?
Do we really need it?
Julian.
Xavier Noria
code generators
cies
* templates, e.g. eRuby
* expression with code chunk, e.g lambdas and blocks
* clipboards, email, pastebins, and other places where the code is not
preserved literally
tabs can be made forbidden (g.v.rossum himself said he'd never
supported tabs in the first place if he new what it would cauze)
maybe it can be made optional. or one could write a little conversion script.
i agree python's indentation looks clean. yet i have experienced
allmost all of the above mentioned "cons"...
_c.
Xavier Noria
> * tab/space mixture
> * templates, e.g. eRuby
> * expression with code chunk, e.g lambdas and blocks
> * clipboards, email, pastebins, and other places where the code is not
> preserved literally
> * code generators
>
> tabs can be made forbidden (g.v.rossum himself said he'd never
> supported tabs in the first place if he new what it would cauze)
>
> maybe it can be made optional. or one could write a little
> conversion script.
Or add source filters:
http://search.cpan.org/~fxn/Acme-Pythonic-0.45/lib/Acme/Pythonic.pm
MWUUAHAHAHA.
-- fxn
Brian Candler
> >>|What are the reasons why this isn't used/implemented/liked?
> >>
> >>Python style block by indentation is an interesting idea, but it
> >>works
> >>badly with
> >>
> >> * tab/space mixture
> >> * templates, e.g. eRuby
> >> * expression with code chunk, e.g lambdas and blocks
> >* clipboards, email, pastebins, and other places where the code is not
> >preserved literally
>
> code generators
Disabling sections of code, i.e.
if false
...
... code with original indentation
...
end
Also, multi-level namespaces where you don't want to indent the entire
source file that much, e.g.
module Foo
module Bar
class Baz
def wibble
...
end
end # Baz
end # Bar
end # Foo
(Admittedly, I believe it's now possible to write
module Foo; module Bar; end; end
class Foo::Bar::Baz
...
end)
Daniel Martin
> As far as I can see, the 'end' keyword is 'repeating yourself' when
> used with properly indented code.
Note that the Haskell folks have managed to evolve a language in which
python-like spacing can be used to mark the extent of discrete code
chunks, but so can traditional braces.
This is more then kind of thing I'd like to see in Ruby: having it
allow the compact python notation, but not require it. (So that,
e.g., code generators would still be easy to write)
I think anyone serious about adding indentation-as-syntax to Ruby
should take a very close look at how Haskell manages to allow it
without requiring it.
--
s=%q( Daniel Martin -- mar...@snowplow.org
puts "s=%q(#{s})",s.to_a.last )
puts "s=%q(#{s})",s.to_a.last
Yukihiro Matsumoto
In message "Re: Why not adopt "Python Style" indentation for Ruby?"
on Fri, 18 May 2007 22:01:13 +0900, Daniel Martin <mar...@snowplow.org> writes:
|Note that the Haskell folks have managed to evolve a language in which
|python-like spacing can be used to mark the extent of discrete code
|chunks, but so can traditional braces.
I admit Haskell syntax is much better than Python's. But I am not yet
sure if it can be applied to Ruby.
matz.
Robert Klemme
Just to throw in my 0.02EUR here: I don't think it's worth the effort
(which I guess is huge) because Ruby's syntax *is* concise already. If
I got to decide I would rather see those efforts go into JVM based Ruby
implementations and / or native threads. But that's just my personal
preference.
Kind regards
robert
Ryan Leavengood
>
> What are the reasons why this isn't used/implemented/liked? It would
> be a small change to the interpreter. Enabling meaningful indentation
> would only make 'end' optional, not invalid; backwards compatibility
> wouldn't be a problem.
>
> (I use both Ruby and Python. I think indentation is one of the few
> *language* features where Python leads Ruby.)
This is a very subjective thing. A lot of people don't use Python
because they don't like this feature.
In my case I like the symmetry that Ruby's matching end provides. I
find it makes the code easier to read and maintain. I've written and
maintained some Python code that "trails off into nowhere" with a long
series of indentations. I find this "stairway" code rather painful to
work with.
But if it is possible to add this feature to Ruby without breaking
anything, it could be interesting. It would certainly draw a few
Pythonists to check out Ruby.
Ryan
S.Volkov
news:1179473895.694681...@x31.netlab.jp...
imho: indentation should not define semantic;
suggestion: make 'end' optional if code block contains only one statement;
BRs
Sergey Volkov
Yukihiro Matsumoto
In message "Re: Why not adopt "Python Style" indentation for Ruby?"
on Fri, 18 May 2007 23:15:05 +0900, "S.Volkov" <svo...@comcast.net> writes:
|imho: indentation should not define semantic;
Agreed.
|suggestion: make 'end' optional if code block contains only one statement;
I'm not sure if we can define syntax for above suggestion.
while cond
puts a
puts b # delimit by indentation or else??
or maybe
while cond: puts a # should be in same line
matz.
Jaroslaw Zabiello
> Python style block by indentation is an interesting idea, but it works
> badly with
>
> * tab/space mixture
Tabs are against PEP8 which recomends space usage only.
> * templates, e.g. eRuby
eRuby is crap if you compare it with Haml template
http://haml.hamptoncatlin.com/.
It is interesting how they use indendation and how clean it can be. And
finally... they are written in Ruby and for Ruby users! :)
What do you think about OPTIONAL block indendation in Ruby?
--
Jarosław Zabiełło
http://blog.zabiello.com
Jaroslaw Zabiello
> I admit Haskell syntax is much better than Python's.
Matz, you must be joking... Python is much easier to read than Haskell.
Eric Mahurin
I've picked up on python in the last couple months and like the
indentation. In addition to forced readablity, I find another
practical benefit is that it eliminates hard to track down syntax
errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
these errors can be painful to track down in a large file with lots of
blocks within blocks.
Syntactically it isn't too difficult once you have the lexer generate
indent and unindent tokens. Then the parser just looks for matching
indent and unindent tokens instead of {} or begin/end, etc.
You might consider something like this as an alternative block syntax.
Maybe a ":" followed by a newline (and extra indentation) would start
this style. I'm not sure of a clean way to handle arguments though.
p.s. in the late eighties I made a little shell language (for the
Atari ST) that used indentation just like python.
Gregory Brown
> > * templates, e.g. eRuby
>
> eRuby is crap if you compare it with Haml template
> http://haml.hamptoncatlin.com/.
Except eRuby is a general templating system, and Haml is for XHTML generation.
Filipe Fernandes
<snip>
> I've picked up on python in the last couple months and like the
> indentation. In addition to forced readablity, I find another
> practical benefit is that it eliminates hard to track down syntax
> errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
> these errors can be painful to track down in a large file with lots of
> blocks within blocks.
You could always run it through a tool to clean up code and provide
proper indentation. I personally don't like it when a language
dictates how my code ought to look, since I'm pretty picky myself :s
> Syntactically it isn't too difficult once you have the lexer generate
> indent and unindent tokens. Then the parser just looks for matching
> indent and unindent tokens instead of {} or begin/end, etc.
When working in a team, regardless of how the code has been formatted,
I've always been able to slap pieces of code together and not worry
about indentation (when such language doesn't worry about
indentation). Working in python always adds a little extra stress
when mixing and matching code, and the problem gets bigger when
indentation isn't standardized across teams or when applying code from
the web.
filipe
Peter Seebach
>|suggestion: make 'end' optional if code block contains only one statement;
>I'm not sure if we can define syntax for above suggestion.
I am pretty sure we can't, unless we acquire a machine sufficiently
quantum to let us simply generate multiple outputs for each input
program. That would, I think, resolve the question. Sort of.
-s
Jaroslaw Zabiello
> Except eRuby is a general templating system, and Haml is for XHTML generation.
It is not true. Haml can generate non valid XML content as well. But it is
true that Haml main target is XHTML and CSS generation. For CSS generation
is Sass which uses very similiar approach
http://haml.hamptoncatlin.com/docs/sass
Is it not strange that such solution was invented
by Ruby, not Python, guys? :)
Austin Ziegler
> eRuby is crap if you compare it with Haml template
> http://haml.hamptoncatlin.com/.
How well does Haml work with non-HTML templating?
-austin
--
Austin Ziegler * halos...@gmail.com * http://www.halostatue.ca/
* aus...@halostatue.ca * http://www.halostatue.ca/feed/
* aus...@zieglers.ca
Yukihiro Matsumoto
In message "Re: Why not adopt "Python Style" indentation for Ruby?"
on Sat, 19 May 2007 00:20:06 +0900, Jaroslaw Zabiello <hipert...@gmail.com> writes:
|> I admit Haskell syntax is much better than Python's.
|
|Matz, you must be joking... Python is much easier to read than Haskell.
To rephrase, "Haskell INDENTATION SYNTAX is much better than
Python's". Clear?
matz.
Austin Ziegler
> I've picked up on python in the last couple months and like the
> indentation. In addition to forced readablity, I find another
> practical benefit is that it eliminates hard to track down syntax
> errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
> these errors can be painful to track down in a large file with lots of
> blocks within blocks.
Scope indicated by whitespace is an indication, IMO, that the compiler
thinks that it knows better than you do.
Always a mistake.
I want a programming language that works how I do; I don't want to
have to work how a stupid programming language requires it.
(I sometimes put debug statements flush left so that it's a simple
/^p<CR> to search for them. Can't do that with scope controlled by
whitespace. Dumb, dumb, dumb, dumb.)
Austin Ziegler
> > Except eRuby is a general templating system, and Haml is for XHTML generation.
> It is not true. Haml can generate non valid XML content as well. But it is
> true that Haml main target is XHTML and CSS generation. For CSS generation
> is Sass which uses very similiar approach
> http://haml.hamptoncatlin.com/docs/sass
Neither is useful for those of us who want general purpose templating.
There are bigger problems in the world than your little web-apps.
-austin, generates C++ with erb
Peter Seebach
es:
>(I sometimes put debug statements flush left so that it's a simple
>/^p<CR> to search for them. Can't do that with scope controlled by
>whitespace. Dumb, dumb, dumb, dumb.)
Suspiciously familiar!
-s
Yukihiro Matsumoto
In message "Re: Why not adopt "Python Style" indentation for Ruby?"
on Sat, 19 May 2007 00:15:05 +0900, Jaroslaw Zabiello <hipert...@gmail.com> writes:
|What do you think about OPTIONAL block indendation in Ruby?
I am not positive for general block-by-indentation idea. If one
REALLY loves the idea, Python always waits for you.
But I sometime want "end"-less single line structure (in normal
order), e.g.
if foo then bar # pseudo syntax; you may require delimiters
not
bar if foo
especially when I write very small code chunk. Not knowing what
syntax it should be.
matz.
Eric Mahurin
> On 5/18/07, Eric Mahurin <eric.m...@gmail.com> wrote:
> > On 5/18/07, Yukihiro Matsumoto <ma...@ruby-lang.org> wrote:
> > I've picked up on python in the last couple months and like the
> > indentation. In addition to forced readablity, I find another
> > practical benefit is that it eliminates hard to track down syntax
> > errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
> > these errors can be painful to track down in a large file with lots of
> > blocks within blocks.
>
> Scope indicated by whitespace is an indication, IMO, that the compiler
> thinks that it knows better than you do.
>
> Always a mistake.
>
> I want a programming language that works how I do; I don't want to
> have to work how a stupid programming language requires it.
>
> (I sometimes put debug statements flush left so that it's a simple
> /^p<CR> to search for them. Can't do that with scope controlled by
> whitespace. Dumb, dumb, dumb, dumb.)
That is the exact same case I find the indentation thing gets in the
way. I had to change my way of putting in print debug statements
(same as yours). Every language makes you change your ways a bit. Of
course python's debug facilities (pdb) are much better than ruby's so
I don't do print debugging as much.
I would rather have multiple ways to specify blocks:
* {}'s
* indentation
* in-line (single statement/expression)
BTW, python's lambda sucks! You can't put generic code in there - it
must be a single expression. I think it has to do with the
indentation thing. Only statements can have code blocks (using
indentation) and a lambda is an expression. I don't like the clear
separation of statements and expressions that python has. I think it
all comes back to the indentation thing. They didn't do it right.
Sounds like Haskell did (but I have no experience with it).
gga
> On 5/18/07, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
>
> > Hi,
>
> > In message "Re: Why not adopt "Python Style" indentation for Ruby?"
> > on Fri, 18 May 2007 22:01:13 +0900, Daniel Martin <mar...@snowplow.org> writes:
>
> > |Note that the Haskell folks have managed to evolve a language in which
> > |python-like spacing can be used to mark the extent of discrete code
> > |chunks, but so can traditional braces.
>
> > I admit Haskell syntax is much better than Python's. But I am not yet
> > sure if it can be applied to Ruby.
>
> > matz.
>
> I've picked up on python in the last couple months and like the
> indentation. In addition to forced readablity, I find another
> practical benefit is that it eliminates hard to track down syntax
> errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
> these errors can be painful to track down in a large file with lots of
> blocks within blocks.
No, it is just the other way around. Languages that use curly braces
for indentation like C, Perl, etc. are EASY to work with once code is
not properly factored and it extends outside a single page. Ruby is
easy only when you use {, not so much when you use do/end,
unfortunately, as most editors know nothing about it. Some good
editors (emacs, for example), can tell you the context you are in the
modeline with curly braces, but not so with other block indentation
types. And most editors can easily find matching braces. No editor I
am aware knows how to match indentation yet or do/end contexts (not
that it could not be coded, thou).
Python is a true nightmare to debug and understand once you have code
that trails off a single page. A good example of these problems, for
example, is the Maya Python API which is as ugly as it can be, using
all of the ugliest things of python (tabulation using tabs, lots of
underscore methods, lots of code that is not easily refactored, etc).
Another problem with indentation only that has not been mentioned is
that simple cut and paste of source code between two files is not
guaranteed to work (and often will lead to a syntax error or worse, a
runtime error). This to me is still a big no-no for indentation only,
as most programmers *do* often cut and paste code from different
contexts or files. With languages that use braces or Ruby's do/end
you really don't have to worry about that, for the most part.
Jeremy Henty
> No editor I am aware knows how to match indentation yet or do/end
> contexts (not that it could not be coded, thou).
Emacs + ruby-mode.el understands do/end just fine.
Regards,
Jeremy Henty
S.Volkov
> Hi,
>
> In message "Re: Why not adopt "Python Style" indentation for Ruby?"
> on Fri, 18 May 2007 23:15:05 +0900, "S.Volkov" <svo...@comcast.net>
> writes:
>
>
> |suggestion: make 'end' optional if code block contains only one
> statement;
>
> I'm not sure if we can define syntax for above suggestion.
>
> while cond
> puts a
> puts b # delimit by indentation or else??
> or maybe
>
> while cond: puts a # should be in same line
Thus we introduce new semantic for newline!
Following construct becomes invalid (and confusing):
while cond: puts a
puts b
end
=>my personal opinion - NO
imho: we need special terminator anyway, now it is 'end', could be another;
suggestion: introduce ';;' terminator for 'implicit blocks (not started with
class/module/def/do/begin), ie:
#--
while cond : puts a ; puts b ;;
# but
while cond do puts a ; puts b end
#-- until - same as while
#--
if cond : p a ;;
#--
if cond : p a else p b ;;
#-- unless - same as if
#--
for var in expr : p var ;;
# but
for var in expr do p var end
#-- case - sorry my lunch time ended, has to return back to my office..
BRs
Sergey Volkov
Wolfgang Nádasi-donner
> As far as I can see, the 'end' keyword is 'repeating yourself' when
> used with properly indented code.
>
>
> def bar(value)
> if value < 7
> puts "hello"
> else
> puts "world"
> end
> end
>
> def foobar
> puts "foobar"
> end
>
> end
>
> could be
>
> class Foo
>
> def bar(value)
> if value < 7
> puts "hello"
> else
> puts "world"
>
> def foobar
> puts "foobar"
The is one big disadvantage in Python's syntax. Things like...
def bar(value); (value<7) ? (puts "hello") : (puts "world"); end
..are not possible in Python - and they are useful for the typical
one-to-three-liners in support areas, where Ruby still has the chance to
replace Perl - a chance that Python never had.
I know that my example has nothing to do with documentation oriented
software development, but this is not necessary for a broad range of
small ad-hoc tools.
Wolfgang Nádasi-Donner
--
Posted via http://www.ruby-forum.com/.
Enrique Comba Riepenhausen
> with no reduction in meaning, yet 25% fewer lines of code.
>
>
> What are the reasons why this isn't used/implemented/liked? It would
> be a small change to the interpreter. Enabling meaningful indentation
> would only make 'end' optional, not invalid; backwards compatibility
> wouldn't be a problem.
>
> (I use both Ruby and Python. I think indentation is one of the few
> *language* features where Python leads Ruby.)
Here my 5 cents...
Gentlemen, if you want to code Python style, go ahead, program in
Python.
I mean every language has it's pros an cons. I come from a Java world
(11 years of Java) and I am not asking that Ruby should be Java like.
That is absolute nonsense.
Ruby is like Ruby, so, if you like it (as I do) take it, if you
don't... there are lots of different programming languages out there
you can choose from, or like Mats, go ahead and develop your own (you
will notice it's actually not that easy to do it right...)
Cheers,
Enrique Comba Riepenhausen
Yukihiro Matsumoto
In message "Re: Why not adopt "Python Style" indentation for Ruby?"
on Sat, 19 May 2007 03:15:17 +0900, "S.Volkov" <svo...@comcast.net> writes:
|imho: we need special terminator anyway, now it is 'end', could be another;
|suggestion: introduce ';;' terminator for 'implicit blocks (not started with
|class/module/def/do/begin), ie:
For your information, 1.9 once had exact same syntax you've proposed
for a short while. I have a time machine. The idea was abandoned
since it caused serious unreadability.
matz.
Austin Ziegler
> No, it is just the other way around. Languages that use curly braces
> for indentation like C, Perl, etc. are EASY to work with once code is
> not properly factored and it extends outside a single page. Ruby is
> easy only when you use {, not so much when you use do/end,
> unfortunately, as most editors know nothing about it. Some good
> editors (emacs, for example), can tell you the context you are in the
> modeline with curly braces, but not so with other block indentation
> types. And most editors can easily find matching braces. No editor I
> am aware knows how to match indentation yet or do/end contexts (not
> that it could not be coded, thou).
Vim does this just fine.
-austin
Sven Suska
> You might consider something like this as an alternative block syntax.
> Maybe a ":" followed by a newline (and extra indentation) would start
> this style. I'm not sure of a clean way to handle arguments though.
What about another syntax:
Putting a special character at the beginning of every line that is
governed by significant whitespace.
Thes would cause no problems with normal Ruby syntax,
but would provide a way to use significant indentation if one really
wants to.
If "~" were that special character, it would look like that:
~ 5.times do |n|
~ n.times do
~ print n
~ puts
Of course, hardly any editor would be prepared to support this,
currently...
This approach would have the additional advantage
of being more robust to contexts where leading whitespace
gets stripped.
Cheers
Sven
Sven Suska
>But I sometime want "end"-less single line structure (in normal
>order), e.g.
>
> if foo then bar # pseudo syntax; you may require delimiters
>
>not
>
> bar if foo
>
>especially when I write very small code chunk. Not knowing what
>syntax it should be.
>
+1
Sven
Trans
On May 18, 5:22 pm, Sven Suska <sven71...@suska.org> wrote:
> Eric Mahurin schrieb:
>
> > You might consider something like this as an alternative block syntax.
> > Maybe a ":" followed by a newline (and extra indentation) would start
> > this style. I'm not sure of a clean way to handle arguments though.
>
> What about another syntax:
> Putting a special character at the beginning of every line that is
> governed by significant whitespace.
> Thes would cause no problems with normal Ruby syntax,
> but would provide a way to use significant indentation if one really
> wants to.
>
> If "~" were that special character, it would look like that:
> ~ 5.times do |n|
> ~ n.times do
> ~ print n
> ~ puts
I can't count how many times I've forgotten "do". Sometimes I have
wished a colon could "induce" the block:
5.times |n|:
n.times:
print n
puts
But I don't think a line prefix is worth the trouble.
T.
Robert Dober
>
>
> On May 18, 5:22 pm, Sven Suska <sven71...@suska.org> wrote:
> > Eric Mahurin schrieb:
> >
> > > You might consider something like this as an alternative block syntax.
> > > Maybe a ":" followed by a newline (and extra indentation) would start
> > > this style. I'm not sure of a clean way to handle arguments though.
> >
> > What about another syntax:
> > Putting a special character at the beginning of every line that is
> > governed by significant whitespace.
> > Thes would cause no problems with normal Ruby syntax,
> > but would provide a way to use significant indentation if one really
> > wants to.
> >
> > If "~" were that special character, it would look like that:
> > ~ 5.times do |n|
> > ~ n.times do
> > ~ print n
> > ~ puts
>
> I can't count how many times I've forgotten "do". Sometimes I have
> wished a colon could "induce" the block:
lot of Python experience. Not that I think bad of the ":" syntax, just
wondering.
Robert
>
> 5.times |n|:
> n.times:
> print n
> puts
>
> But I don't think a line prefix is worth the trouble.
>
> T.
>
>
>
--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw
S.Volkov
well, if suffix did not work,
can we try prefix syntax for 'end'-less constructs?
(if not has been tried before)
suggestion:
:& - prefixes 'single statement body' code block in
class/module/def/unless/then/else/while/until
#- samples
if cond :& puts a
if cond : puts a else :& puts b
while cond :& puts a
for var in expr :& puts var
# also valid:
if cond :& (puts a; puts b)
while cond :& begin puts a end
#- single statements 'chain'
unless cond_a
:& for ea in expr
:& for eb in ezpr
:& if cond(ea, eb)
:& do_smthng
#- simple functor with local state
class<<fib=Object.new
:& def get(m)
:& (@fh||=Hash.new{|h,n|h[n]=n<2?n:h[n-1]+h[n-2]})[m]
fib.get 10
#-> 55
BRs
Sergey
Trans
On May 19, 2:38 am, "Robert Dober" <robert.do...@gmail.com> wrote:
> On 5/18/07, Trans <transf...@gmail.com> wrote:
>
>
>
> > On May 18, 5:22 pm, Sven Suska <sven71...@suska.org> wrote:
> > > Eric Mahurin schrieb:
>
> > > > You might consider something like this as an alternative block syntax.
> > > > Maybe a ":" followed by a newline (and extra indentation) would start
> > > > this style. I'm not sure of a clean way to handle arguments though.
>
> > > What about another syntax:
> > > Putting a special character at the beginning of every line that is
> > > governed by significant whitespace.
> > > Thes would cause no problems with normal Ruby syntax,
> > > but would provide a way to use significant indentation if one really
> > > wants to.
>
> > > If "~" were that special character, it would look like that:
> > > ~ 5.times do |n|
> > > ~ n.times do
> > > ~ print n
> > > ~ puts
>
> > I can't count how many times I've forgotten "do". Sometimes I have
> > wished a colon could "induce" the block:
>
> That puzzles me, would you not forget the ":" then? Or do you have a
> lot of Python experience. Not that I think bad of the ":" syntax, just
> wondering.
Hehe. Probably so. I'm not a hisser ;) But I think I would forget the
colon much less often, especially given it created indention
significance.
T.
gga
No, it doesn't. When I type a close brace in emacs, I get the
corresponding line where the matching brace matches (hilited if
visible in the page, or in the modeline if not).
When I position myself next to a brace, I get the same hiliting
happening. Can't recall if that's a feature of hilite or the electric
mode of emacs.
However, whenever I type "end" to close a block, I have NO clue where
the block begins. And if it is code I did not write, not knowing
where the code begins is a killer.
Being emacs, I *could* potentially hack the lisp code to handle do/end
blocks properly (or indentation too). I haven't seen anyone do it yet
(and publically give it away).
Brendan
> ...
> with no reduction in meaning, yet 25% fewer lines of code.
>
> What are the reasons why this isn't used/implemented/liked? It would
> be a small change to the interpreter. Enabling meaningful indentation
> would only make 'end' optional, not invalid; backwards compatibility
> wouldn't be a problem.
>
> (I use both Ruby and Python. I think indentation is one of the few
> *language* features where Python leads Ruby.)
I personally prefer that 'end' be in place, so that all ruby code is
readable. I personally believe there may be something wrong with a
syntax which sacrifices explicit readability (for everyone, not just
python programmers) for increased typing speed and the illusory gain
of 'fewer LOC'. This was one of the major reasons which convinced me
to use ruby instead of python.
Chad Perrin
I, personally, don't have an argument on principle like that for my own
preferences in this matter. I just like the fact that an "end" makes it
look more complete to me. Reading Python code always makes me feel like
my eyes are just going to trail off the right-hand edge of the page
because the "shape" of the code never brings me back to the leftmost
edge, the way code "should".
When I look at Python code, and ponder the way it does things so
differently from Ruby regarding delimiters and indentation (the same
thing in Python), it seems to me that Python was created for people who
write code in a particular mindset, and it's not a mindset I share when
I'm writing code. I guess maybe some people, when writing code, think
in footnote hierarchies, while others (like me) think in nested scopes.
That's just an off-the-cuff hypothesis.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Larry Wall: "A script is what you give the actors. A program is what you
give the audience."
M. Edward (Ed) Borasky
this sort of thing can ever be solved, but here are my personal opinions:
1. When you come right down to it, there are only a few basic syntax
styles that have survived the test of time. *Most* languages, including
C, Ruby, Pascal and Perl, use some variant of the Algol 60 syntax. The
other "survivors" are the Lisp/Scheme variant of prefix notation,
Forth's postfix notation, and the regular expression syntax. I suppose
assembly language syntax has also survived, and FORTRAN and COBOL, but I
don't think anyone would design a new language with those.
2. I think Python's "variant" of Algol 60 notation is less than
satisfactory, but I also have problems with the liberality present in
the syntax of Perl and Ruby. I don't like to make the reader or parser
work any harder than necessary just for the convenience of the coder. So
I like explicit delimiters like curly braces, parentheses, mandatory
semicolons at the end of statements, begin/end pairs, etc. for the Algol
60 languages. Lisp/Scheme and Forth were deliberately designed to make
the parser's job trivial, and I like them too. :)
3. I've pretty much given up on the dream that I'll be able to program
in one language only, although some languages are close enough. At the
moment, I can get just about everything done in either Perl or R, with
the other languages simply being fun to learn and use but not essential.
I could probably eliminate Perl if there were more R programmers, but
there aren't and won't be, because R is designed for scientists and
mathematicians, not business people.
Sven Suska
>On May 18, 5:22 pm, Sven Suska <sven71...@suska.org> wrote:
>
>>Putting a special character at the beginning of every line that is
>>governed by significant whitespace.
>>Thes would cause no problems with normal Ruby syntax,
>>but would provide a way to use significant indentation if one really
>>wants to.
>>
>>If "~" were that special character, it would look like that:
>>~ 5.times do |n|
>>~ n.times do
>>~ print n
>>~ puts
>>
>>
>
>But I don't think a line prefix is worth the trouble.
>
>
Trouble? -- I want the editor to insert the prefix, of course.
Some editors are already able to do this with line comments,
so they can be adapted easily.
Sven
rocky.b...@gmail.com
> On 5/18/07, Austin Ziegler <halosta...@gmail.com> wrote:
>
>
>
> > On 5/18/07, Eric Mahurin <eric.mahu...@gmail.com> wrote:
> > > On 5/18/07, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> > > I've picked up onpythonin the last couple months and like the
> > > indentation. In addition to forced readablity, I find another
> > > practical benefit is that it eliminates hard to track down syntax
> > > errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
> > > these errors can be painful to track down in a large file with lots of
> > > blocks within blocks.
>
> > Scope indicated by whitespace is an indication, IMO, that the compiler
> > thinks that it knows better than you do.
>
> > Always a mistake.
>
> > I want a programming language that works how I do; I don't want to
> > have to work how a stupid programming language requires it.
>
> > (I sometimes put debug statements flush left so that it's a simple
> > /^p<CR> to search for them. Can't do that with scope controlled by
> > whitespace. Dumb, dumb, dumb, dumb.)
>
> That is the exact same case I find the indentation thing gets in the
> way. I had to change my way of putting in print debug statements
> (same as yours). Every language makes you change your ways a bit. Of
> course python's debug facilities (pdb) are much better than ruby's so
Well, I think that's going to change over the next year. If you
haven't tried Ken Sibilev's ruby-debug, http://rubyforge.org/projects/ruby-debug/
give it a shot. Over the last year it has improved quite a bit and I
expect over the next year it will make the same steady progress. I'm
hoping the next release will have a user manual, and possibly start
adding some regression tests (which by the way pdb doesn't currently
have).
As someone who's a little bit familiar with both debuggers, I think
the design of ruby-debug is the cleaner and more flexible. In fact, I
think it's the best organized debugger of any that I've seen so far.
(But then. as it grows..)
Robert Klemme
> 2. I think Python's "variant" of Algol 60 notation is less than
> satisfactory, but I also have problems with the liberality present in
> the syntax of Perl and Ruby. I don't like to make the reader or parser
> work any harder than necessary just for the convenience of the coder.
I would understand why you would want to make the reader's job easier -
but the parser? That's just a piece of software and I believe that we
should always strive to make software easier to use for humans not machines.
Besides of that, personally I don't find the current Ruby syntax hard to
read. Do you have some examples where you feel that reading Ruby is
made hard(er) because of the liberties you mention?
Kind regards
robert
SonOfLilit
parer, so both are the same.
Whenever there is syntax that's tricky to parse, it's also tricky to read.
See pythons space-vs-tab problem, for example.
Aur
zn...@cesmail.net
I can think of three examples right off the top of my head: Rails, Rake and
RSpec. There's something really eerie about seeing code like that. You *know*
it works, but you can't figure out why or how.
Dick Davies
> Quoting Robert Klemme <short...@googlemail.com>:
> > Besides of that, personally I don't find the current Ruby syntax hard to
> > read. Do you have some examples where you feel that reading Ruby is
> > made hard(er) because of the liberties you mention?
> I can think of three examples right off the top of my head: Rails, Rake and
> RSpec. There's something really eerie about seeing code like that. You *know*
> it works, but you can't figure out why or how.
And you think replacing do/end with indentation would help?
I really can't see how - could you give an example?
--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/
Peter Marsh
I totally agree. A line pre-fix is a bit pointless in my opinion,
although I am in favour in moving towards a Python-style indentation
syntax. As for the 'do' issue I don't see why it can't be removed, if
something is always expected then you can just assume its there, right?
5.times do |n|
n.times do
print n
end
puts
end
(Or using the ':' instead) Could just be:
5.times |n|
n.times
print n
end
puts
end
Michael Fellinger
Sorry, but how would you handle block_given? without parameters?
Michael Fellinger
> On 20/05/07, zn...@cesmail.net <zn...@cesmail.net> wrote:
> > Quoting Robert Klemme <short...@googlemail.com>:
>
> > > Besides of that, personally I don't find the current Ruby syntax hard to
> > > read. Do you have some examples where you feel that reading Ruby is
> > > made hard(er) because of the liberties you mention?
>
> > I can think of three examples right off the top of my head: Rails, Rake and
> > RSpec. There's something really eerie about seeing code like that. You *know*
> > it works, but you can't figure out why or how.
>
> And you think replacing do/end with indentation would help?
>
> I really can't see how - could you give an example?
>
Let's try:
describe 'myself'
it 'should be readable'
lambda
@reader.reading
.should change
@reader.knowledge
.by(text.amount)
# pretty much impossible, if you ask me :)
# same in usual ruby now
describe 'myself' do
it 'should be readable'
lambda{ @reader.reading }.
should change{ @reader.knowledge }.
by(text.amount)
end
end
# well?
Peter Marsh
>> puts
>>
> Sorry, but how would you handle block_given? without parameters?
I'm still quite new to Ruby, so I'm not entirely sure what you mean,
could you explain what you feel the problem would be please?
Dick Davies
The only extra words there are do/end and you could replace them
with {} if they really bothered you.
If you're saying you personally don't like do/end blocks, then you're
as entitled to that opinion as anyone else, but I don't see this as making
DSLs any more or less comprehensible personally
Michael Fellinger
uh, actually that was an example that i can't interpret the
indentation. I do like the idea of supporting indentation, but not
within ruby.
It's just getting into a mess with method-calls with blocks, manual
lambdas and doing methodchains like foo{bar}.duh{x} - it's not really
about the braces but about the possibility to write that code in a
different syntax at all.
If someone is brighter than me, you're welcome to propose alternatives :)
Gregory Brown
> I can think of three examples right off the top of my head: Rails, Rake and
> RSpec. There's something really eerie about seeing code like that. You *know*
> it works, but you can't figure out why or how.
None of those are especially magical if you have a decent understand
of how Ruby works.
method_missing + block syntax does not necessary mean evil black magic.
Neil Wilson
> As far as I can see, the 'end' keyword is 'repeating yourself' when
> used with properly indented code.
Maybe it is maybe it isn't. Personally I'm an 'end' man. I like my
blocks.
It would be easier if you learnt to type, or used editor macros.
> (I use both Ruby and Python. I think indentation is one of the few
> *language* features where Python leads Ruby.
>
> If this post generates a positive response, I'll make a patch for Ruby
> 1.9.
Nope, leave the language as it is. I like it unaltered thank you very
much.
However I've never understood why there has to be 'one true syntax'
for any computer language. As long as the syntax generates the same
ASTs in the interpreter I can't see why you couldn't choose the syntax
you prefer - whether that is whitespace indentation, or the symbolic
mush of the 'C' derived languages.
Marc Heiler
supported tabs in the first place if he new what it would cauze)"
Just a bit offtopic: I personally used tabs a lot and told people
that they could adjust them to their space-likings (2 or 4), however
as I comment quite a lot, i did find myself mixing tabs and spaces
so I finally changed, avoid using tabs, and use 2 spaces now
everywhere for code. (2 spaces because i like to keep 80 chars /
line, so i can fit more into a line :-) )
Chad Perrin
>
> Let's try:
>
> describe 'myself'
> it 'should be readable'
> lambda
> @reader.reading
> .should change
> @reader.knowledge
> .by(text.amount)
If Ruby looked like that, I'd probably not have bothered -- just stuck
with Perl.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Paul Graham: "Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts."
Trans
On May 20, 8:43 am, "Michael Fellinger" <m.fellin...@gmail.com> wrote:
> On 5/20/07, Dick Davies <rasput...@gmail.com> wrote:
>
> > On 20/05/07, z...@cesmail.net <z...@cesmail.net> wrote:
(I take it you meant 'if' not 'it')
> # well?
Actually, the later is pretty dang ugly --maybe worse the the first.
However colons would help the first example quite a bit:
describe 'myself':
if 'should be readable':
lambda:
@reader.reading
.should change:
@reader.knowledge
.by(text.amount)
Though any such indention significance is probably too big of a change
for Ruby at this point anyway. I'd much rather just see more
intelligent was to catch missing "end" errors. Even if meant the
option to put "endif", "endclass", etc.
T.
T.
Chad Perrin
>
> Actually, the later is pretty dang ugly --maybe worse the the first.
> However colons would help the first example quite a bit:
>
> describe 'myself':
> if 'should be readable':
> lambda:
> @reader.reading
> .should change:
> @reader.knowledge
> .by(text.amount)
>
> Though any such indention significance is probably too big of a change
> for Ruby at this point anyway. I'd much rather just see more
> intelligent was to catch missing "end" errors. Even if meant the
> option to put "endif", "endclass", etc.
I'd prefer we keep the plain ol' "end" syntax, and use editors that can
do delimiter matching as easily with "end" as with braces, brackets, or
parentheses.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Dr. Ron Paul: "Liberty has meaning only if we still believe in it when
terrible things happen and a false government security blanket beckons."
Trans
On May 20, 3:00 pm, Chad Perrin <per...@apotheon.com> wrote:
> On Mon, May 21, 2007 at 03:53:47AM +0900, Trans wrote:
>
> > Actually, the later is pretty dang ugly --maybe worse the the first.
> > However colons would help the first example quite a bit:
>
> > describe 'myself':
> > if 'should be readable':
> > lambda:
> > @reader.reading
> > .should change:
> > @reader.knowledge
> > .by(text.amount)
>
> > Though any such indention significance is probably too big of a change
> > for Ruby at this point anyway. I'd much rather just see more
> > intelligent was to catch missing "end" errors. Even if meant the
> > option to put "endif", "endclass", etc.
>
> I'd prefer we keep the plain ol' "end" syntax, and use editors that can
> do delimiter matching as easily with "end" as with braces, brackets, or
> parentheses.
Yes, that would be nice, but I've yet to see an editor do it.
T.
David Carlton
> On 19.05.2007 20:48, M. Edward (Ed) Borasky wrote:
>> I don't like to make the reader or parser work any harder than
>> necessary just for the convenience of the coder.
> I would understand why you would want to make the reader's job easier
> - but the parser? That's just a piece of software and I believe
> that we should always strive to make software easier to use for
> humans not machines.
In general, I agree. But I don't want to ignore parsers completely -
the easier a language is to parse, the easier it is for people to
develop tools to work with the language, making programmers' lives
easier. I'm pretty sure that one of the reasons why there aren't many
C++ refactoring tools is because the language is incredibly difficult
to parse, for example.
David Carlton
car...@bactrian.org
Stian Haklev
at least optionally... I hate when you have a long class file and you
get the dreaded Unexpected end of file, expecting END or something...
and you have no idea where in the 200 lines you forgot to insert an end,
or you left a brace hanging on the line above an end or what not. Even
if we didn't mandate endif, we could let end do what it does, but with
an optional argument (end if, end class, end def) - I would use these,
and the interpreter would thus be able to catch the error a lot closer
to the source -- class not closed at line 50 is more helpful then end of
file at line 230...
Stian
gga
> On 5/18/07, gga <GGarram...@aol.com> wrote:
>
> > No, it is just the other way around. Languages that use curly braces
> > for indentation like C, Perl, etc. are EASY to work with once code is
> > not properly factored and it extends outside a single page. Ruby is
> > easy only when you use {, not so much when you use do/end,
> > unfortunately, as most editors know nothing about it. Some good
> > editors (emacs, for example), can tell you the context you are in the
> > modeline with curly braces, but not so with other block indentation
> > types. And most editors can easily find matching braces. No editor I
> > am aware knows how to match indentation yet or do/end contexts (not
> > that it could not be coded, thou).
>
>
Really? Not the vim I'm using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks. Its status line also tells me nothing about
what function or class I'm in either. Worse, if I close a bracket,
and the opening of it is outside the "page", it does not tell me what
the opening statement was. So... no, I'd say it definitively fails
and is worse than emacs.
Or perhaps there's a setting I missed?
Gregory Brown
> Really? Not the vim I'm using (cream). It matches parentheses/
> brackets like most editors, but it does nothing to hilight matching do/
> end or def/end blocks. Its status line also tells me nothing about
> what function or class I'm in either. Worse, if I close a bracket,
> and the opening of it is outside the "page", it does not tell me what
> the opening statement was. So... no, I'd say it definitively fails
> and is worse than emacs.
> Or perhaps there's a setting I missed?
It's probably that Cream does not have the proper ruby configuration
files bundled with it.
Consider using plain vim or gvim rather than Cream, as it gets rid of
most of the reasons you'd use vim!
bbiker
Someone wrote a macro (or whatever it is called) for gvim that
automatically inserts an "end" statement whenever you enter a keyword
that requires an "end".
for example:
type:
"if cond" and press return
the cursor goes to the next line and an "end" statement appears on the
subsequent line with the proper indentation.
if cond
# cursor at start of this line.
end
Austin Ziegler
I don't use the cream settings. I use vim with the Ruby settings
available on RubyForge. Now, automatic highlighting isn't present
(e.g., the same way you get with {}), but you *can* hit "%" to jump
between matching pairs. It isn't for everyone, either, but the folding
available with vim does more for me being certain of matched pairs
than anything else (if it doesn't fold properly, it isn't likely to
compile properly).
I have TextMate (but don't use it), and I'm pretty sure it can do the
same. I've heard good things about Kate from Linux users, too.
-austin
--
Austin Ziegler * halos...@gmail.com * http://www.halostatue.ca/
* aus...@halostatue.ca * http://www.halostatue.ca/feed/
* aus...@zieglers.ca
Benjamin Kudria
> I have TextMate (but don't use it), and I'm pretty sure it can do the
> same. I've heard good things about Kate from Linux users, too.
Indeed, Kate is great (although not as good as what I'veseen/heard about
Textmate) butit certainly doesn't highlight do...end combinations, only the
standard [], {}, etc. It may be possible to add support for it, however.
-Ben
Erik Hollensbe
% works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.
Rick DeNatale
> On 2007-05-20 20:45:59 -0700, gga <GGarr...@aol.com> said:
> > Really? Not the vim I'm using (cream). It matches parentheses/
> > brackets like most editors, but it does nothing to hilight matching do/
> > end or def/end blocks.
> % works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
> not sure if this is the same as the dist that a few guys have been
> working on at rubyforge.
% in vim does something related to what he's asking for, but it
doesn't automatically highlight the matching token when the cursor
lands on it's mate. G?Vim will do this for single character matching
tokens like ( ), [] and {}, as you move the cursor over one of these
it will highlight its mate if it doesn't have to scroll to do so.
Personally, I don't miss it much.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Keith Fahlgren
> > % works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
> > not sure if this is the same as the dist that a few guys have been
> > working on at rubyforge.
>
> % in vim does something related to what he's asking for, but it
> doesn't automatically highlight the matching token when the cursor
> lands on it's mate. G?Vim will do this for single character matching
> tokens like ( ), [] and {}, as you move the cursor over one of these
> it will highlight its mate if it doesn't have to scroll to do so.
Actually, mate-highlighting was added in vim 7:
http://vimdoc.sourceforge.net/htmldoc/pi_paren.html#matchparen
HTH,
Keith
Rick DeNatale
Right, which is what I use. And as I said, it only highlights pairs
of single character delimiters which are unequal, it can't highlight
do/end or "/".
Jerry Blanco
it'll work with % and do/end.
Also, if you
:set sm
it will highlight briefly the opening of a block by the cursor going
there and back really quickly AND setting the opening and closing
markers in a different color.
There are some options with sm (showmatch) that I don't recall. Do
:help showmatch
in Vim for details.
My experience with Vim is that if you can think of ANYTHING for Vim to
do, chances are someone thought of it and created a plugin for it
(yes, you can play tetris and sokoban with vim ->
(http://www.vim.org/scripts/script_search_results.php?keywords=tetris&script_type=&order_by=rating&direction=descending&search=search).
If you haven't, I'd suggest checking the scripts section in vim.org
(http://www.vim.org/scripts/index.php). Also, use the search
(http://www.vim.org/search.php) to look for plugins.
HTH
Jerry.
--
/(bb|[^b]{2})/ <- The question
Jinjing Wang
Check out my project for Ruby space convention :/
It's code generation.
Brad Phelan
> I love indentations too..
>
> Check out my project for Ruby space convention :/
>
> http://lazibi.rubyforge.org
>
> It's code generation.
>
You don't need to do code generation, at least in the way you have done
it. I posted a solution way back up this thread that does not require
the creation of intermediate files to load.
In foo.rb
require 'pyrb.rb'
__END__
def foo:
[1,2,3,4].each do |i|:
puts i
[1,2,3,4].each do |j|:
puts i
if i == 2 :
puts "foo"
else:
puts "bar"
foo
See
http://xtargets.com/snippets/posts/show/68
for the details.
--
Brad Phelan
http://xtargets.com
Frasier Mruby
I am kind of new to ruby and like it after looking python first. As
some other people said, my only major complaint is it's many "END".
Among java/c/C++/python, the "END" keep reminding me the inconvenience
of it during coding ruby. I like ruby because it's easy to learn, and
to read. It's designed for be friends of programmers. But I feel the
"END" may have a negative role to ruby's purpose or attraction.
I am fine to have "END" for class or methods. But for IF,WHILE, CASE,
FOR, etc., when there are many levels it often make me confused what the
matching part of the those "END"s are.
I understand and agree your comment that ruby had better to have
something to close the code block. But I sincerely hope you could come
up something else to replace the "END".
My first thought to use brace "{...}" to replace "END" since it's a
popular convention.
I suggest to use only the "do...end" to formalize the blocks, brace {}
will be stopped to be used. It seems to me it's a waste of symbols to
have two ways to represent blocks, which may not be the most frequently
used. Or consider to use use:
"/* */", "|...|", "<...>", "[...]" , "(...)", "((...))", , "//...//", "
:...: ", " '...' ", " `...` " for blocks.
To enhance readability is probably one of ruby's design purpose and I
really hope some thing could be done earlier to make the "END" looks
prettier.
Thank you!
On 18/05/07, Yukihiro Matsumoto <ma...@ruby-lang.org> wrote:
> * tab/space mixture
> * templates, e.g. eRuby
> * expression with code chunk, e.g lambdas and blocks
* clipboards, email, pastebins, and other places where the code is not
preserved literally
James Britt
Why not adopt "Python Style" indentation for Ruby? Because that would
bite a big one.
>
> I am fine to have "END" for class or methods. But for IF,WHILE, CASE,
> FOR, etc., when there are many levels it often make me confused what the
> matching part of the those "END"s are.
Then don't do that. Seriously. Twisty conditionals is a code smell.
(Having fought with deep hierarchies of YAML and HAML, the lack of an
explicit "end" token doesn't really help in complex documents; in fact,
it can be detriment. Sometimes explicit is better than implicit.)
BTW, doesn't your code editor find the matching braces (or do/ends) for
you? (If not, get a real editor. They're free.)
> To enhance readability is probably one of ruby's design purpose and I
> really hope some thing could be done earlier to make the "END" looks
> prettier.
I *rarely* run into Ruby code that is not readable. When I do, it's
almost always for a reason (e.g. Camping source code, or some code
golfing).
The idea that coders need to be coerced into writing readable code is as
flawed as that of the need for Java-style static typing to avoid bugs.
It sounds good in blog posts and mailing lists, but lacks empirical
evidence.
--
James Britt
www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
Frasier Mruby
I didn't propose to get rid of the "END" like python does, but wondered
if there could be cleaner syntax to as an alternative for "END".
>James Britt wrote:
>> I am fine to have "END" for class or methods. But for IF,WHILE, CASE,
>> FOR, etc., when there are many levels it often make me confused what the
>> matching part of the those "END"s are.
>
> Then don't do that. Seriously. Twisty conditionals is a code smell.
> (Having fought with deep hierarchies of YAML and HAML, the lack of an
> explicit "end" token doesn't really help in complex documents; in fact,
> it can be detriment. Sometimes explicit is better than implicit.)
>
Ruby code is reasonable or readable with "END". And I agree a better
editor would help to find matching END, but still wonder if there could
be room to make the ruby code cleaner by considering other syntax to
replace "END".
What I was saying in previous post is to free up the braces "{}" out of
block syntax to replace "END". For blocks, besides "do...end", use
something else like "[], or /**/. e.g.:
class Foo
def bar(b)
c = b+1
if b is not nil
if c > 10
c++
if c %2 == 0
c += 3
print c
end
end
if d < 9
d += 2
print d
end
end
a = [1, 2]
a.each {|num| print num }
end
end
# tries to clean up the "END"s
class Foo
def bar(b) {
c = b+1
if b is not nil {
if c > 10 {
c++
if c %2 == 0 {
c += 3
print c
}
}
if d < 9 {
d += 2
print d
}
}
a = [1, 2]
a.each [|num| print num ]
a.each (|num| print num )
a.each < |num| print num >
a.each /* |num| print num */
a.each /# |num| print num #/
...
}
end
If {} can represent a bock, then personally it might also readable to
use [] and syntax above to denote blocks.
I also like the idea that "END" is optional for one line if, like:
if a > 0 :
print a
I can live with "END" in ruby, now just want to express an opinion or
wish to make the ruby code more cleaner, and more programmer attracted.
Brian Candler
I find Ruby's syntax as-is works remarkably well. The only problem it
causes me is with do-end mismatches where the parser just runs off the
end of the file, with no indication of where the missing do or end might
be. I have on many occasions resorted to chopping a copy of my source
file to find the problem (that is, lopping out a class or a method at a
time until the problem goes away)
DSL's are also a source of this problem:
context "an empty object" do
should "have zero size" do
...
end
end
Miss out either of those 'do's and it's hard to tell where the problem
is.
Personally, the solution I would love to have is a parser/pretty-printer
tool which can read a Ruby source file and spit it back out with
"standardised" indentation. It would then be obvious where the problem
lies. You'd get the benefit of python-style indentation, without
actually having to use python-style indentation :-)
Unfortunately, the lack of specification makes it really hard to
implement; and I don't think I could use something like ParseTree as I
think it would rely on the file being parsed successfully up-front,
whereas I want this for programs which don't parse. Maybe there's
another ruby implementation which could do this. Otherwise, the best I
can think of is to modify the existing Ruby parser to spit out
auto-indented code as it reads the source.
I don't wish to change to a different text editor, and in any case, I
don't believe that *any* editor has a sufficiently complete knowledge of
Ruby lexing and parsing rules that it will always match the Ruby way of
parsing source.
Anyway, if anyone knows of a tool which does this, it would make me very
happy :-)
Mark Thomas
> editor would help to find matching END, but still wonder if there could
> be room to make the ruby code cleaner by considering other syntax to
> replace "END".
After you use ruby for a while, you'll stop wanting to make it look
like some other language. You'll realize it's nice the way it is. And
certain things will start to grow on you, such as using @x instead of
self.__x.
> I also like the idea that "END" is optional for one line if, like:
>
> if a > 0 :
> print a
If that's a one-line 'if', what's this?
print a if a > 0
even better, that's what. :)
-- Mark.
Joe Wölfel
On 6 oct. 08, at 15:57, Brian Candler wrote:
> Personally, the solution I would love to have is a parser/pretty-
> printer
> tool which can read a Ruby source file and spit it back out with
> "standardised" indentation. It would then be obvious where the problem
> lies. You'd get the benefit of python-style indentation, without
> actually having to use python-style indentation :-)
Maybe this is close to what you want.
http://blog.neontology.com/posts/2006/05/10/beautiful-ruby-in-textmate
Joe Wölfel
James Britt
>
> I don't wish to change to a different text editor, and in any case, I
> don't believe that *any* editor has a sufficiently complete knowledge of
> Ruby lexing and parsing rules that it will always match the Ruby way of
> parsing source.
>
> Anyway, if anyone knows of a tool which does this, it would make me very
> happy :-)
Well, vi/vim/gvim users can have the code auto-format, which will "fix"
indentation.
When I get those nasty kEND errors I run the auto-format macro and scan
down the code until I see something out of place. Then error is usually
a few lines above that point.
Justin Collins
> Dear Mats,
>
> I am kind of new to ruby and like it after looking python first. As
> some other people said, my only major complaint is it's many "END".
> Among java/c/C++/python, the "END" keep reminding me the inconvenience
> of it during coding ruby. I like ruby because it's easy to learn, and
> to read. It's designed for be friends of programmers. But I feel the
> "END" may have a negative role to ruby's purpose or attraction.
>
Like any new language, it takes some time to adjust your eyes and fingers.
> I am fine to have "END" for class or methods. But for IF,WHILE, CASE,
> FOR, etc., when there are many levels it often make me confused what the
> matching part of the those "END"s are.
>
None of your suggestions seem to address this issue. Matching 'end' is
no harder than matching '}'. If you get confused, add documentation like
some people do:
end#if
end#while
end#class
> I understand and agree your comment that ruby had better to have
> something to close the code block. But I sincerely hope you could come
> up something else to replace the "END".
>
> My first thought to use brace "{...}" to replace "END" since it's a
> popular convention.
>
But then it looks like C/Java.
> I suggest to use only the "do...end" to formalize the blocks, brace {}
> will be stopped to be used. It seems to me it's a waste of symbols to
> have two ways to represent blocks, which may not be the most frequently
> used. Or consider to use use:
> "/* */", "|...|", "<...>", "[...]" , "(...)", "((...))", , "//...//", "
> :...: ", " '...' ", " `...` " for blocks.
>
> To enhance readability is probably one of ruby's design purpose and I
> really hope some thing could be done earlier to make the "END" looks
> prettier.
>
I think 'end' looks fine, personally. I used to use curly braces all the
time, but now I find myself using them as little as possible. do/end
seems nicer and I don't get them confused with hashes that way.
Besides, I enjoy the current look for conditionals. Given your later
example, I prefer to see
if b is not nil
def bar b
than
if b is not nil {
def bar b {
Especially if it's going to lead to arguments about where that '{'
should go. Same line? Next line? Next line indented? I don't want C. I
don't want Java. I don't want parentheses around my conditionals when
they aren't needed. I don't want to have to use my shift key more than
necessary. I really don't see the problem with the current syntax. I
respect your opinion but definitely do not agree.
-Justin
Tom Reilly
first.
I learned Ruby first then Python.
I never liked the indentation of Python probably as a result
Tom
David A. Black
On Tue, 7 Oct 2008, Tom Reilly wrote:
> I've thought that one rather likes the structure of a language learned first.
I like the structure of Ruby more than that of BASIC, so there goes
that theory :-)
David
--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!
Frasier Mruby
> After you use ruby for a while, you'll stop wanting to make it look
> like some other language. You'll realize it's nice the way it is. And
> certain things will start to grow on you, such as using @x instead of
> self.__x.
>
Ok. I will try to use ruby more then. I like ruby's other syntax such
as @x than self.__x. Only complaint is the "END", which I have to type
even for a couple of short lines of IF.
> If that's a one-line 'if', what's this?
>
> print a if a > 0
>
> even better, that's what. :)
>
> -- Mark.
Yeah, that's one line if but it seems Mats mentioned one syntax before
like : if a > 0 then do this . Sth like that. When if clause is
longer the existing one-line if may not looks elegant. Thanks.
Martin DeMello
Actually, the more I write in scheme, the more I like its structure.
It all just works.
martin
Frasier Mruby
> None of your suggestions seem to address this issue. Matching 'end' is
> no harder than matching '}'. If you get confused, add documentation like
> some people do:
>
> end#if
> end#while
> end#class
>
It's a good way. It's just that there're more typings. If you says
"matching end is no harder than }, then } could be an considered as an
option I assume.
>> My first thought to use brace "{...}" to replace "END" since it's a
>> popular convention.
>>
>
> But then it looks like C/Java.
>
Liking other languages may not be bad. Ruby's syntax on my first
impression is that it's similar to python, thinking about the "class" or
"def". Ruby has evolved by learning merits from other languages.
> I think 'end' looks fine, personally. I used to use curly braces all the
> time, but now I find myself using them as little as possible. do/end
> seems nicer and I don't get them confused with hashes that way.
>
Thanks for your reply, Justin. It seems I am not the only one who are
concerned with the "END". Not 2 years ago, 1 year ago, or now. On
ruby's logo, it says "programmer's best friend". It seems ruby's
objective is to make it programmer-friendly language. When there are
not few people have been wondering if any improvement could be made on
its syntax, some effort may need to be considered on the improvement.
If it's determined there's absolutely no room to improve, then that's
fine.
If no improvement will be made in near future, I can live with "END",
though in my mind I may still have the thought of it and wondering if it
could be made better.
Don't get my wrong. I hope ruby getting better and can attract more
programmers. With this mind, I pointed what I felt, which is shared by
other new comers.
Hassan Schroeder
> Only complaint is the "END", which I have to type
> even for a couple of short lines of IF.
If you use an IDE/editor like NetBeans, you don't -- it's inserted for you
when you enter something like
if @foo.nil? <return>
| # cursor placed here
end # auto-inserted
FWIW,
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
Bilyk, Alex
I always type (), [], {}, do/end, begin/end,<>, etc. upfront together and then insert what goes in between. I can't quite remember the last time I have mismatched these in any language.
OTOH, I can't stand Python's semantically significant white space approach. It seems to give me trouble a lot more often than I'd like... perhaps because I have not used it long enough.
Alex
Justin Stanczak
+1
I've used Java for years, and it's great, but I would not want to make Ruby
more like Java. I'm new to Ruby, but really enjoy it so far. As for Python,
I just can't get my self into it. I attended one of Mark Lutz's training
sessions, just to find I didn't care for coding Python. I'm sure it's a
great language, but I guess it's not for me. Mark did a great job. I find
Ruby very easy to use, and the syntax well thought out. Don't change a
thing, at least not until I've learned it better.
Stefano Crocco
I learned Python first, hated its indentation-based structure, switched to
Ruby and loved it.
Stefano
Justin Collins
> Hi --
>
> On Tue, 7 Oct 2008, Tom Reilly wrote:
>
>> I've thought that one rather likes the structure of a language
>> learned first.
>
> I like the structure of Ruby more than that of BASIC, so there goes
> that theory :-)
>
>
> David
>
Yeah :( Although sometimes I miss the simplicity of ON KEY GOSUB...
-Justin
Nobuyoshi Nakada
At Tue, 7 Oct 2008 04:57:45 +0900,
Brian Candler wrote in [ruby-talk:317027]:
> I find Ruby's syntax as-is works remarkably well. The only problem it
> causes me is with do-end mismatches where the parser just runs off the
> end of the file, with no indication of where the missing do or end might
> be. I have on many occasions resorted to chopping a copy of my source
> file to find the problem (that is, lopping out a class or a method at a
> time until the problem goes away)
Python style indentation also can't help you alone. How can it
know which did you intend?
if x == "ok":
print "ok"
print "foo"
if x == "ok":
print "ok"
print "foo"
> Personally, the solution I would love to have is a parser/pretty-printer
> tool which can read a Ruby source file and spit it back out with
> "standardised" indentation. It would then be obvious where the problem
> lies. You'd get the benefit of python-style indentation, without
> actually having to use python-style indentation :-)
Recent 1.9 warns when it see a mismatch.
$ ./ruby -ve 'begin
end'
ruby 1.9.0 (2008-10-07 revision 19704) [i686-linux]
/ruby: warning: mismatched indentations: line 1:'begin' and line 2:'end'
--
Nobu Nakada
Gaspard Bucher
I code in ruby and c++.
I love {} in c++.
I love "do", "end" in ruby.
That's just because I am deeply grateful for what both these languages
let me achieve, each in it's own field.
Gaspard
David A. Black
On Tue, 7 Oct 2008, Frasier Mruby wrote:
> Justin Collins wrote:
>
>> None of your suggestions seem to address this issue. Matching 'end' is
>> no harder than matching '}'. If you get confused, add documentation like
>> some people do:
>>
>> end#if
>> end#while
>> end#class
>>
>
> It's a good way. It's just that there're more typings. If you says
> "matching end is no harder than }, then } could be an considered as an
> option I assume.
That doesn't follow.
>>> My first thought to use brace "{...}" to replace "END" since it's a
>>> popular convention.
>>>
>>
>> But then it looks like C/Java.
>>
>
> Liking other languages may not be bad. Ruby's syntax on my first
> impression is that it's similar to python, thinking about the "class" or
> "def". Ruby has evolved by learning merits from other languages.
Yes, to a large extent. But Ruby also *is* a language. It's not an
experiment in how to stick different ideas from other languages
together.
Have you written to any C mailing lists, suggesting that C adopt
features from Ruby?
>> I think 'end' looks fine, personally. I used to use curly braces all the
>> time, but now I find myself using them as little as possible. do/end
>> seems nicer and I don't get them confused with hashes that way.
>>
>
> Thanks for your reply, Justin. It seems I am not the only one who are
> concerned with the "END". Not 2 years ago, 1 year ago, or now. On
> ruby's logo, it says "programmer's best friend". It seems ruby's
> objective is to make it programmer-friendly language. When there are
> not few people have been wondering if any improvement could be made on
> its syntax, some effort may need to be considered on the improvement.
> If it's determined there's absolutely no room to improve, then that's
> fine.
It's been discussed a million times over many years, if that's what
you mean. If Matz were going to remove the "end" keyword, I think he
would have done it by now.
> If no improvement will be made in near future, I can live with "END",
> though in my mind I may still have the thought of it and wondering if it
> could be made better.
>
> Don't get my wrong. I hope ruby getting better and can attract more
> programmers. With this mind, I pointed what I felt, which is shared by
> other new comers.
Please don't put this in terms of Ruby attracting programmers. Ruby
does about as good a job as any language I've ever heard of, when it
comes to having programmers like it. Not everyone does, of course, but
Matz has accomplished something truly great and amazing in exactly
that sense. "end" is not a test of whether or not Ruby is an
attractive language, and curly braces are not Ruby's ticket to
popularity.
In general, the best thing by far is to spend some time with the
language, and let it speak to you.