It also simplify many semantic in Ruby for example. defining
class/method could be viewed as a method that takes a block. But "do"
wouldn't make sense there, but:
class Person is #<<< just a method taking a block
def say(message) is #<<< Don't know :S
...
end
end
It may make Ruby code reflect more closely to what I am thinking in
word.
I think I like this. If it were an RCR, I just might vote for it.
But I would want two things:
1. Not too much proliferation, please. "is" and "do" are enough.
2. Let's make it clear that "is/end" and "do/end" shall behave
exactly the same way. No subtle differences, please.
This almost makes me want an alias_keyword... but that would probably
cause more problems than it would solve.
Austin Ziegler ha scritto:
>>What do you think about those "end"s? Do you *REALLY* like them?
>>Will Ruby-2 offer an alternative? Well, maybe not "indentation" but
>>will another solution be available?
> I hope that the mistake that Python makes isn't repeated in Ruby 2.0.
> I prefer explicit -- and more flexible -- than implicit and
> inflexible.
are you citing line 2 of "the zen of python"[1] consciously?
Doubtful. I don't follow Pythonistas. However, if they are at all
serious about it, the irony involved in their *own* failure to be
explicit is delicious.
> In other words, I really *do* like the ends.
I always have the feeling that there could be something better than
ends, but untile I find it I'm happy with them.
I've never had that feeling. I've programmed in too many different
programming languages to feel that there's anything "wrong" with them.
Honestly, I prefer ENDs to indentation, I prefer curly braces to ENDs.
But how about something like this:
def foo @var
}
···
On 02/02/06, Austin Ziegler <halostatue@gmail.com> wrote:
On 01/02/06, Rubyist <nuby.ruby.programmer@gmail.com> wrote:
> >> What would be even better would be to allow optional labels after end
> >> statements, such as "end class", "end def", so the parser can catch
> >> more errors.
> That sound like a good idea. But what about "if", "when", "for",
> "until" etc?
> Hmm...
> "endif", "end when", "end for", "end until", "end class", "enddef",...
> Umh! A never "ended" nightmare.
I'm not particularly fond of IF ... ENDIF constructs, but one can simulate this:
def foo
...
end # def foo
I don't do it, though. Vim does a damn fine job of folding things for me.
On Thu, 2006-02-02 at 15:48 +0900, Jim Freeze wrote:
On Feb 1, 2006, at 3:38 PM, Rubyist wrote:
>>> I have looked at some of my and other people's Ruby code and
>>> often been tempted to select those last 5
>>> 'ends' and hit the delete button. : )
>
> Thank God! I am not alone on the earth! ;-D
> Man, you've made me so laughed! Hahaha!
>
I think we can learn a lot from programming languages and Python.
First off, we should be writing in a fixed space font so we
can take visual cues from spacing more easily.
Next, why do we need periods at the end of a sentence
when we know that two spaces after a word mean
that the previous sentence just ended Doesn't
that make sense And do we really need caps at
the beginning of a sentence we know all sentences
are capitalized and we have just defined that
two spaces before a word means that it is at the
beginning of a sentence next we should look at
spelling double consonants don't realy add to
the meaning so begining now we spel words by
droping repeated consonants just look at al
these great benefits we can learn from python
self.we self.just self.need self.to self.learn
self.to self.ignore self.certain self.aspects
self.that self.may self.cary self.over
I have looked at some of my and other people's Ruby code and
often been tempted to select those last 5
'ends' and hit the delete button. : )
Thank God! I am not alone on the earth! ;-D
Man, you've made me so laughed! Hahaha!
I think we can learn a lot from programming languages and Python.
First off, we should be writing in a fixed space font so we
can take visual cues from spacing more easily.
Next, why do we need periods at the end of a sentence
when we know that two spaces after a word mean
that the previous sentence just ended Doesn't
that make sense And do we really need caps at
the beginning of a sentence we know all sentences
are capitalized and we have just defined that
two spaces before a word means that it is at the
beginning of a sentence next we should look at
spelling double consonants don't realy add to
the meaning so begining now we spel words by
droping repeated consonants just look at al
these great benefits we can learn from python
self.we self.just self.need self.to self.learn
self.to self.ignore self.certain self.aspects
self.that self.may self.cary self.over
I have looked at some of my and other people's Ruby code and
often been tempted to select those last 5
'ends' and hit the delete button. : )
Thank God! I am not alone on the earth! ;-D
Man, you've made me so laughed! Hahaha!
I think we can learn a lot from programming languages and Python.
First off, we should be writing in a fixed space font so we
can take visual cues from spacing more easily.
Next, why do we need periods at the end of a sentence
when we know that two spaces after a word mean
that the previous sentence just ended Doesn't
that make sense And do we really need caps at
the beginning of a sentence we know all sentences
are capitalized and we have just defined that
two spaces before a word means that it is at the
beginning of a sentence next we should look at
spelling double consonants don't realy add to
the meaning so begining now we spel words by
droping repeated consonants just look at al
these great benefits we can learn from python
self.we self.just self.need self.to self.learn
self.to self.ignore self.certain self.aspects
self.that self.may self.cary self.over
"Jim Freeze" <jimfreeze@gmail.com> wrote in message
news:72811398-6AA5-483D-AC6C-81FBB7F852B4@gmail.com...
···
On Feb 1, 2006, at 3:38 PM, Rubyist wrote:
>>> I have looked at some of my and other people's Ruby code and
>>> often been tempted to select those last 5
>>> 'ends' and hit the delete button. : )
>
> Thank God! I am not alone on the earth! ;-D
> Man, you've made me so laughed! Hahaha!
>
I think we can learn a lot from programming languages and Python.
First off, we should be writing in a fixed space font so we
can take visual cues from spacing more easily.
Next, why do we need periods at the end of a sentence
when we know that two spaces after a word mean
that the previous sentence just ended Doesn't
that make sense And do we really need caps at
the beginning of a sentence we know all sentences
are capitalized and we have just defined that
two spaces before a word means that it is at the
beginning of a sentence next we should look at
spelling double consonants don't realy add to
the meaning so begining now we spel words by
droping repeated consonants just look at al
these great benefits we can learn from python
self.we self.just self.need self.to self.learn
self.to self.ignore self.certain self.aspects
self.that self.may self.cary self.over
For what it's worth, I also strongly dislike it. It was one of my least
favorite features of OCaml's syntax.
But here, the biggest problem is that (relative to other block endings
in pretty much any language I can think of), it's much harder to
visually count ;;s if they are squashed together as in your example.
I think this is largely because there aren't any visual cues to the
boundary between tokens. The gap between two ;s within the same ;; and
the gap between two ;s in adjacent ;; aren't visually distinguishable.
-mental
···
On Fri, 2006-02-03 at 12:46 +0900, Yukihiro Matsumoto wrote:
> It sounds to me like it'll make reading ruby libraries / code a bit
> more difficult since both can exist. Is it worth that price? Am I
> missing something?
No. The purpose of this experiment is hearing other opinions. So
yours is quite worthwhile.
I haven't liked them. But curly braces may me quite better.
I'd vote for curly braces, if it's possible at all. (Curly braces are
already used for blocks, so I'm not sure it's possible/feasible.)
In fact, "do", "then", "end", etc. make one-liners harder to read
and, as a result, make them less valuable. Compare,
for example,
if cond then meth this; func that end #(1)
with
if (cond) {meth this; func that} #(2)
The second is easier to grasp at a glance. Why?
Because "names" are written in words and grammatical
constructions are written in symbols (except for "if").
Code (1) is harder to read because everything is a word.
In any case, however, I'm quite happy with Ruby. This issue
is very minor at best. All I'm saying is, if possible, I prefer
the style of code (2).
Even if "end if" is no longer feasible to parse because of the if
modifier there is still the possibility to have optional "end def" and
"end class" instead of just "end". It could make finding the place
where an end is missing much easier.
Michal
(0..10).each do |i|
# Do something with i
end what?
I agree with you mostly on this kind of option, since I always add
comments after every 'end' of a deep embedded structure to make the
logic more readable.
I definitely wouldn't want that. I really feel that "less is more".
Less keywords, not more, will result in less confusion.
···
On 2/5/06, Hal Fulton <hal9000@hypermetrics.com> wrote:
joesb wrote:
> It also simplify many semantic in Ruby for example. defining
> class/method could be viewed as a method that takes a block. But "do"
> wouldn't make sense there, but:
>
> class Person is #<<< just a method taking a block
> def say(message) is #<<< Don't know :S
> ...
> end
> end
>
> It may make Ruby code reflect more closely to what I am thinking in
> word.
I think I like this. If it were an RCR, I just might vote for it.
But I would want two things:
1. Not too much proliferation, please. "is" and "do" are enough.
2. Let's make it clear that "is/end" and "do/end" shall behave
exactly the same way. No subtle differences, please.
This almost makes me want an alias_keyword... but that would probably
cause more problems than it would solve.
--
R. Mark Volkmann
Partner, Object Computing, Inc.
Agreed, curly braces are much less intrusive. Also more intuitive I think.
You have an opener and a closer. Indentation strictness... <shudder>
···
On 2/1/06, Serdar Kılıç <skilic@gmail.com> wrote:
Honestly, I prefer ENDs to indentation, I prefer curly braces to ENDs.
But how about something like this:
def foo @var
}
On 02/02/06, Austin Ziegler <halostatue@gmail.com > wrote:
> On 01/02/06, Rubyist <nuby.ruby.programmer@gmail.com> wrote:
> > >> What would be even better would be to allow optional labels after
end
> > >> statements, such as "end class", "end def", so the parser can catch
> > >> more errors.
> > That sound like a good idea. But what about "if", "when", "for",
> > "until" etc?
> > Hmm...
> > "endif", "end when", "end for", "end until", "end class", "enddef",...
> > Umh! A never "ended" nightmare.
>
> I'm not particularly fond of IF ... ENDIF constructs, but one can
simulate this:
>
> def foo
> ...
> end # def foo
>
> I don't do it, though. Vim does a damn fine job of folding things for
me.
>
> -austin
> --
> Austin Ziegler * halostatue@gmail.com
> * Alternate: austin@halostatue.ca
>
>
i used the ti-83+, and still do (as i'm still in high school) i just don't
program it as much as i used to
but anyway, one thing i would like better than the current "end"s, is
wrapping everything in do/end like this:
while condition? do #action
end
or maybe even:
if condition?
then do #action
else do #action
end
greetings, Dirk.
···
2006/2/2, Jeffrey Schwab <jeff@schwabcenter.com>:
Dirk Meijer wrote:
> i like the "end"s, it reminds me of the old days when i programmed my
Texas
> Instruments calculator and always forgot an "end" somewhere
I loved my TI-82, and I remember how excited I was over my 85. Now that
I'm a grown-up, of course, I have a Voyage 200.
"Serdar Kiliç" <skilic@gmail.com> wrote in message
news:9bff27860602011620p4d20335es@mail.gmail.com...
Honestly, I prefer ENDs to indentation, I prefer curly braces to ENDs.
But how about something like this:
def foo @var
}
Oooh. Now I found quite attractive. It's like a single bookend keeping
things upright between itself and the wall.
I don't think Ruby ever needs to be ashamed of being Ruby.
James Edward Gray II
···
On Feb 2, 2006, at 10:07 PM, MenTaLguY wrote:
On Fri, 2006-02-03 at 12:46 +0900, Yukihiro Matsumoto wrote:
It sounds to me like it'll make reading ruby libraries / code a bit
more difficult since both can exist. Is it worth that price? Am I
missing something?
No. The purpose of this experiment is hearing other opinions. So
yours is quite worthwhile.
I was going to write my own post, but it seems MenTaLguY did it for me!
I am in total agreement; semicolons are an ugly way to end sections.
Curly braces I have a much easier time with.
Tom
···
* On Feb 3 13:07, MenTaLguY (ruby-talk@ruby-lang.org) wrote:
For what it's worth, I also strongly dislike it. It was one of my
least favorite features of OCaml's syntax.
But here, the biggest problem is that (relative to other block endings
in pretty much any language I can think of), it's much harder to
visually count ;;s if they are squashed together as in your example.
I think this is largely because there aren't any visual cues to the
boundary between tokens. The gap between two ;s within the same ;; and
the gap between two ;s in adjacent ;; aren't visually distinguishable.
>
> Even if "end if" is no longer feasible to parse because of the if
> modifier there is still the possibility to have optional "end def" and
> "end class" instead of just "end". It could make finding the place
> where an end is missing much easier.
>
> Michal
>
(0..10).each do |i|
# Do something with i
end what?
