Zach wrote:
If you design a language in the two steps you just provided then i agree
with you. But having 20/20 hindsight what would have made more sense
when designing an inclusive and an exclusive range operators? What seems
more natural? Try to not include the reasoning "because that's how it
is" or "because that's what most people know".
To me, neither seems "more natural" once prior experience is removed.
It's quite arbitrary. If you think it's more natural a certain way,
then go ahead, but it's unlikely to convince me.
Speaking as a Ruby programmer again, I personally find nothing
whatsoever confusing about the literal range notation, inclusive or
exclusive.
I agree with you here as well. As a ruby programmer you know how they
work so there is no need to change them. Now envision that there is
someone you are teaching Ruby, and at the same time you are teaching
them how to program. What makes more sense when describing the .. and
... operators?
Again, neither. It's not been a problem when teaching people Ruby.
Those people were existing programmers of other languages, but I doubt
they were familiar with .. from anywhere.
I'll also point out, as I'm fond of doing, that you learn a language --
and of course, to learn programming at all -- you have to be willing to
actually *learn* a few things. I like to see it made as easy as
possible, but there are other considerations as well. This particular
piece of syntax took me no time at all to learn, and I'm not
extraordianarily brilliant, so I have no concern that it is confusing
for newbies. (I was one, once, and it wasn't confusing.)
Again, try not to include "because that's how it is" or
"because that's what people know". Try to keep it natural and making
sense.
And I
dislike the thought of reversing the notations; not based on precedent
and not wanting to change things, but based an aesthetics.
Where is the aesthetics in the reasoning for .. and ... ? I see no
beauty. I see nothing that makes sense.
Well I do. But that's probably because I take the attitude that it's
arbitrary, that it might as well be kept simple, and because that
notation looks better than any reasonable alternative I can think of.
I see something that is done a
certain way because that is how it was done before. Does this make it
the correct way to do things? Try to think about this from a scientific
view point when designing a language. Noting ahead of time you want
inclusive and exclusive range operators. Your goal for the language is
simplicity, elegance and to make it seem natural for the programmer.
What would you use to represent those operators and why? What logically
makes sense? Share your reasoning. Try to do this without using the
current implementation(s) in mind. Pretend you are designing your
language from scratch, or that you are developing a version that doesn't
need backwards compatibility. What is your conclusion and how did you
achieve it?
If inclusive and exclusive ranges were a significant goal of the
language, then my first thought would be this:
[x,y]
[x,y)
(x,y]
(x,y)
However, that's almost certainly going to clash with other goals of the
language, like representing arrays, etc. So it's time for plan B. Of
course, this language doesn't _rally_ need ranges as flexible as the
above representation allows, does it?
# BTW, I'm not entirely happy with Ruby's ranges, I'll have you know.
# They are only really useful for integers and perhaps some strings,
# but they _try_ to be useful for anything, and kind of botch it.
# Further, they take two otherwise aliases methods -- member? and
# include? -- and make them mean something different. This is poor
# form, IMO. They're trying to do too much.
So in my new language, I'd say "ranges are for integers only", and use
the .. and ... notations. Which one for inclusive and which one for
exclusive? To be honest, I don't care. Either one of them would make
sense once you're used to it. So, inclusive being the more common case,
perhaps I'd optimise it accordingly.
If you can answer those and come to a conclusion that the current
implementatoin makes the most sense for the elegance and natural feel
for your language, then I would love to hear your reasoning. Perhaps you
will convince me to change my view. As of yet, I haven't heard a
reason.
And trying to
explain why is like trying to explain appreciation for a poem.
If this were an actual language debate you would have just lost. You
didn't show any logical reasoning or rational conclusions to support
your position. This is like Larry Wall saying that Perl is the best
programming language syntacically because it is like a overly complex
Haiku and it just cannot be explained because of it's aesthetics.
I haven't seen any other attempts to portray logical reasoning towards
an unbiased conclusion, so I feel I'm in good company 
Cheers,
Gavin
