What is the reason for this syntax?

[Kevin Olemoh]

damn double post wierdness sorry.

 

[Zed A. Shaw]

So I take it you all just assume that people know the same things you
do? That is real smart, just assume that a person is going to be able
to read your mind when he comes across your work. You cannot make the
assumption that your code is going to be perfectly clear to an
individual other than yourself; this would be like expecting anyone to
have the exact same command of English as you do. In programming we
have facilities for at the very least informing someone what a given
line or block is the idea that you should not actually use this
facility because whatever you wrote is going to be obvious to anyone
reading your code is a joke.

Damn, I wish all my programming problems were just how the source should be formatted. I've gotta wrestle with arcane paragraphs inside weird parts of RFCs that are damn near impossible to implement without huge hacks. Then there's the problem of how to keep Ruby from crashing when the very latest bug in 1.8.5's IO comes up. Or, how to keep the memory consumption down without requiring people to patch Sync or array.c themselves. Or even whether Ruby is worth using in my next projects considering two more versions are coming out and there will be incompatibilities. I then worry about the cryptographic design of my latest project and whether allowing random channel identification in the AAD of ECC encrypted packet headers allows for client interaction leakage.

But hey, you've got source formatting to worry about. That's super important.

 

[Kevin Olemoh]

Duh I never said it was did you read the starting post so exactly what
is the point of the sarcasm..oh wait there is none. I said from the
begining that it was a minor gripe but that doesn't mean I am not
going to not defend my points about the readability of the code
especially if people are accusing me of telling them to writ a book in
the code itself. You could very easily take care of the comments
after you make it work.

 

[Austin Ziegler]

So I take it you all just assume that people know the same things you
do? That is real smart, just assume that a person is going to be able
to read your mind when he comes across your work. You cannot make the
assumption that your code is going to be perfectly clear to an
individual other than yourself; this would be like expecting anyone to
have the exact same command of English as you do. In programming we
have facilities for at the very least informing someone what a given
line or block is the idea that you should not actually use this
facility because whatever you wrote is going to be obvious to anyone
reading your code is a joke.

Not at all. Speaking as someone who's been at the software development
business for a while, there's nothing worse than a comment that reads:

// added to fix a coredump

If that isn't bad enough, you look around, and you don't see any code to
which this could possibly apply.

On the other hand, it might be worse to read:

// adding 1 to foo
foo += 1

Comments should be used sparingly: they interrupt the flow of the code.
Clearly commenting at the head of methods (especially complex ones) is
useful. Commenting inside of a method is usually useless. ESPECIALLY
when, as always happens, the code and the comment diverge.

I have literally come across comments that I've made a year after I've
made them and they make no sense -- because someone else in the company
modified the code surrounding them but didn't clean up the comments.

Why didn't they? Because it's easy to remove or change code that doesn't
work the way it's supposed to. It's much harder to remove comments that
don't apply any more, because since you're just maintaining something
that someone else wrote.

No one is saying you shouldn't comment things. But there is such a thing
as over-commenting and over-compensating. If case statements are part of
the language, it is reasonable to expect that anyone programming in that
language will understand a case statement.

Scratch that. It's not reasonable -- it's a *given* that you'll either
understand such syntactical tricks or you will ask someone to explain it
to you (and then you'll understand). Yes, there are advanced tricks that
one can do in almost any programming language, and it's often worth
commenting those tricks (or not using them without really good reasons),
but comments can detract from the code.

Actually I am asking for ruby to allow me the freedom to make my own
code readable to me. I personally don't know perl so I can't comment
on Perl however I will say that the interpereter should know when you
are using a block and search for the do keyword or { and ignore the
newline. In other words a method that requires a block as a parameter
(like each) should *not* be terminated by a newline they should be
terminated either by a closing brace or tne end keyword. Grabbing the
user by the balls with respect to how the code is formatted is not a
good thing even if it is a side-effect of how blocks work in the
language.

Then you're welcome to try to patch the parser to make it do that, and
you're welcome to fork Ruby when such a patch is refused because it's
nonsensical.

In four and a half years of using Ruby, you are the very first person
who I have seen request this because they don't think that the existing
block format is reasonable or readable enough. I have seen people ask
"why doesn't this work", but none say that the language isn't good
enough.

Let me give you a small clue: all methods take blocks. Every single last
stinkin' one of them. It just so happens that there's a lot of methods
that don't do anything with them.

def foo
puts "I have a block!" if block_given?
puts "I have no block." unless block_given?
end

foo
foo {||}

There's nothing that the parser knows that says that "foo takes a
block." The interpreter will carry the block that was given to a method.
If the block isn't used (with &block or yield or -- to a degree --
super), then it's silently discarded. If it's used in execution, then
it's executed.

So. Just because you're not comfortable with:

foo do ||
end

and would rather have:

foo
do ||
end

You want to either (a) make the parser know something about execution
time [not smart] or (b) force extra lookahead interpretation for EVERY
METHOD CALL. No, thanks. You'd be much better off either getting used to
the way that Ruby works, or if you can't, finding something that does.

Every spoken and written language has rules and conventions however
they all allow different ways to say one thing (some many more than
others.) all of them probably also have examples of unnessecary
rigidity however unlike programming languages spoken and written
languages are not exactly engineered in a controlled environment so
its not entirely possible to address those issues; it is indeed
possible with programming languages. So shouldn't things that can
adversly affect the readability of the language itself be addressed
since it is well within human capacity to do so?

It has yet to be established that most people fine the standard block
formatting unreadable. All I've heard is one person who doesn't seem to
know much about quality programming practices say that they find it less
readable, and they've done so by comparing it with, well, the wrong
thing. Most of us gave up on the One True Brace Style fight years ago.

-austin

 

[Austin Ziegler]

The Firefox developers have been busy for about five years telling
people that there should not be an interface to change keybindings.
The gnome developers have been telling people that they don't need
various options for some time as well and they are definetly not right
on alot of those issues. Opera software has had ages to implement an
extension system yet they do little if anything at all while people
say that Opera does not need a robust extension system like the one in
Firefox (completely ignoring reality) Just because some "heavy" weight
says one thing does not make it right.

It wasn't just said: it was explained. Why does Firefox need an
interface (I presume you mean GUI) to change keybindings? What
*possible* value does it provide that isn't countered by the massive
headache it would introduce? While I think that the GNOME developers
have hidden *too much*, I think that it's better to by default hide
things that don't matter to 99% of the people out there.

Compare it to Rails. Close to 90% of the decisions about the structure
of your application are made *for* you by Rails. Sure, you can override
it, but you have to go out of your way to do so. I disagree with a lot
of the choices that the Rails core team has made, but I can't argue with
the speed with which I've developed the application I have been using
for my wedding guest list management.

My whole point is that the interpereter should not have syntactic
rules that end up creating formatting requirements. As someone else
pointed out those two are indeed different so the question is really
"Should block parameters break because of a newline before '{' ?" The
fact that {} is a parameter is not really even relevant to my request.
It just gives me insight into why the problem exists in the first
place.

I see your problem here, Kevin. You're not understanding Ruby.

# This method takes a block. It just doesn't do anything with it.
def foo
end
foo {|| puts "ha!" }

# This method also takes a block. It does something with it.
def bar
yield
end
bar {|| puts "ha!" }

# This method *also* takes a block, and turns it into a formal
# parameter. It doesn't do anything with it.
def baz(&block)
end
baz {|| puts "ha!" }

# This method *also* takes a block, and turns it into a formal
# parameter. It does something with it.
def quux(&block)
block.call
end
quux {|| puts "ha!" }

# This method takes a block as a formal parameter only.
def qix(block)
raise unless block.kind_of?(Proc)
block.call
end
qix(lambda {|| puts "ha!" })

A block is not a parameter. You can *make* it a parameter, as shown
above, but by default, it's something that's implicit. So, it isn't even
remotely close to what you thought it was.

If you still think it can be fixed and is worth fixing, please -- try to
patch the code.

-austin

 

[rpardee]

I confess I haven't really followed this thread carefully, but--I
totally agree on the 'elsif' keyword. Wouldn't it be possible for ruby
to accept *either* spelling?

If so, I would definitely advocate it--you don't lose anything for the
perlsters, and those of us coming from other languages won't have to
deal w/the IMHO surprising spelling.

I remember dealing w/this same issue while learning pl/sql. After
staring at my modest program for like 40 minutes looking for the
complained-of syntax error, I was bitter bitter bitter when I finally
learned that I was expected to mis-spell 'else'...

I actually thought ruby did this already--had to write a little script
to verify that it doesn't...

Cheers,

-Roy

 

[dblack]

Hi --

I confess I haven't really followed this thread carefully, but--I
totally agree on the 'elsif' keyword. Wouldn't it be possible for ruby
to accept *either* spelling?

If so, I would definitely advocate it--you don't lose anything for the
perlsters, and those of us coming from other languages won't have to
deal w/the IMHO surprising spelling.

I remember dealing w/this same issue while learning pl/sql. After
staring at my modest program for like 40 minutes looking for the
complained-of syntax error, I was bitter bitter bitter when I finally
learned that I was expected to mis-spell 'else'...

I actually thought ruby did this already--had to write a little script
to verify that it doesn't...

When you're using Ruby, it's best just to come from Ruby. Then you
don't have to be surprised by things like this, or feel any resentment
toward Ruby for failing to be C or Java or whatever. Languages do
lots of things differently from each other. Some day they may all
converge, but that convergences doesn't have to be called Ruby


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[M. Edward (Ed) Borasky]

Languages do
lots of things differently from each other. Some day they may all
converge, but that convergences doesn't have to be called Ruby

Nor does the converged spoken language have to be called English.

But seriously, folks, a billion or so people speak Chinese and I've
forgotten how many speak Spanish and Hindi. Is English even number three
as a native spoken language yet?

Of course, I view almost all contemporary programming languages as
dialects of C, since most of the interpreters and compilers are either
written in C or bootstrapped from C.

<ducking>

 

[rpardee]

But isn't almost everybody coming from *somewhere*? This seems to me a
cost-free change--a win-win...

Hi --

I confess I haven't really followed this thread carefully, but--I
totally agree on the 'elsif' keyword. Wouldn't it be possible for ruby
to accept *either* spelling?

If so, I would definitely advocate it--you don't lose anything for the
perlsters, and those of us coming from other languages won't have to
deal w/the IMHO surprising spelling.

I remember dealing w/this same issue while learning pl/sql. After
staring at my modest program for like 40 minutes looking for the
complained-of syntax error, I was bitter bitter bitter when I finally
learned that I was expected to mis-spell 'else'...

I actually thought ruby did this already--had to write a little script
to verify that it doesn't...

When you're using Ruby, it's best just to come from Ruby. Then you
don't have to be surprised by things like this, or feel any resentment
toward Ruby for failing to be C or Java or whatever. Languages do
lots of things differently from each other. Some day they may all
converge, but that convergences doesn't have to be called Ruby


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Austin Ziegler]

But isn't almost everybody coming from *somewhere*? This seems to me a
cost-free change--a win-win...

No change is cost free, and this is a lose-lose proposition.

You're complaining about:

if foo
do_foo
elsif bar
do_bar
end

What does this look like in other languages?

if (foo)
{
do_foo();
}
else if (bar)
{
do_bar();
}

if foo then
do_foo;
elseif bar then
do_bar;
end;

if [ ! -z "$foo" ]; then
do_foo
elif [ !-z "$bar" ]; then
do_bar
fi

Which of these would you have Ruby emulate? All of them? If you're
wanting a PHP-ism, that's a damned good reason to *not* have it (IMO,
PHP has done *everything* wrong that's possible to do wrong in language
design). Why can't I have my shell-ism (elif), if you get your PHP-ism?

Sorry, but Matz made a choice here. If you don't like the choice, you
can either (1) create a preprocessor that converts your preferred form
into the correct form, (2) make an autocorrection in your favourite
editor to turn elseif into elsif as Ruby requires, (3) use a different
language, or (4) get used to it, already.

I've been using Ruby for four years; there are very few warts on the
language, and this ain't one of them.

-austin

 

[dblack]

Hi --

But isn't almost everybody coming from *somewhere*? This seems to me a
cost-free change--a win-win...

But then if a Rubyist starts learning Java, Java has to change to make
the Rubyist happy. And C has to change to make Haskell programmers
happy. And Python has to change to make Smalltalk programmers happy.
And so on.

It seems to me it's best to break the cycle. Of course languages
evolve from, and borrow from, each other. But they don't incur an
obligation to add features and behaviors simply because practitioners
of other languages are used to those features and behaviors. It's
better just to get used to the language you're using, when you're
using it.


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Kevin Olemoh]

Personally I don't think else if needs to be an actual reserved word.
It would make more sense just to allow people to put an if right after
an else (with a space or newline, not some silly terminator.) in order
to achieve the effect of the keyword. I am not entirely certain of
this but I think that this is how C++ and java happen to work.

Hi --

But isn't almost everybody coming from *somewhere*? This seems to me a
cost-free change--a win-win...

But then if a Rubyist starts learning Java, Java has to change to make
the Rubyist happy. And C has to change to make Haskell programmers
happy. And Python has to change to make Smalltalk programmers happy.
And so on.

It seems to me it's best to break the cycle. Of course languages
evolve from, and borrow from, each other. But they don't incur an
obligation to add features and behaviors simply because practitioners
of other languages are used to those features and behaviors. It's
better just to get used to the language you're using, when you're
using it.


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Kevin Olemoh]

I wanted to add that it may not be so advantageous to have so many
programming languages;unlike spoken languages which actually benefit
from their diversity since they are allow humans to create entirely
new concepts. Programming languages are somewhat restricted by how
hardware actually works and hence perform the same functions with
different ways of getting to the same result. Perhaps one method of
dealing with the current trend of programmers being schooled in two or
more languages just to be marketable is to try to standardize the
behavior of various constructs across languages so things work more
the same across the board. Granted this does happen somewhat
naturally already what I am postulating is that it may be advantageous
to actively try to direct this phenomena.

It would keep things like this from happenning:

a bunch of languages support += as a shorthand for incrementing accumulators

A SQL implementation comes along and does not support this relatively
common short hand..WTH Why???

Anyway that is a discussion unto itself.

 

[Marc Heiler]

I like ruby elsif.
I dont want another syntax.

One addition though:

"What does this look like in other languages?"

You left out the indented Python version.
Python's ability to omit end keywords can be really nice
visually, as you can simply leave them out. This gets
especially nice when you do nest multiple ifs/elsifs and
need to put end at each of them.
(But then again Python has some other bigger flaws than that as well)

 

[Austin Ziegler]

I wanted to add that it may not be so advantageous to have so many
programming languages;unlike spoken languages which actually benefit
from their diversity since they are allow humans to create entirely
new concepts. Programming languages are somewhat restricted by how
hardware actually works and hence perform the same functions with
different ways of getting to the same result. Perhaps one method of
dealing with the current trend of programmers being schooled in two or
more languages just to be marketable is to try to standardize the
behavior of various constructs across languages so things work more
the same across the board. Granted this does happen somewhat
naturally already what I am postulating is that it may be advantageous
to actively try to direct this phenomena.

It would keep things like this from happenning:

a bunch of languages support +=3D as a shorthand for incrementing accumul= ators

A SQL implementation comes along and does not support this relatively
common short hand..WTH Why???

Anyway that is a discussion unto itself.

Oh, please. Your thoughts here are na=EFve, at best. Let's pick on one
of the syntax things that Ruby doesn't support: ++. There are very
good reasons that Ruby doesn't support this syntactic increment
shorthand -- and there's no way to make Ruby support it in a way that
doesn't break a lot of other things or is thread safe. (It's also only
possible to support the prefix form, not the postfix form.)

Language -- whether it's computer language or human language --
changes the way that you think. When I work in C, i think in much
lower-level terms. This is the *purpose* of C -- a portable assembly,
if you will. When I work in C++, I add a bit of object oriented and
template magic to C. My concepts in C++ are still pretty low-level.
When I move to shell scripting, I think in different terms yet -- I
think in terms of "what tools do I have that will help me do what I
must do?" And when I'm in Ruby, I think in terms that are much more
complex than I do with almost any other language.

You say that a bunch of languages support +=3D -- I can think of at
least as many that *don't* support +=3D at all, and even among those
that do support it, there are some that are just whacked out.

The problem we have isn't that programmers must know two or more
languages; it's that there's too many programmers out there who barely
know one. I personally know at least fifteen, although I haven't used
half of them in years. But I use at least four on a regular basis at
work.

I have learned a lot from every single language -- and look forward to
learning even more so that I can advance the state of *my* art.

-austin
--=20
Austin Ziegler * (e-mail address removed) * http://www.halostatue.ca/
* (e-mail address removed) * http://www.halostatue.ca/feed/
* (e-mail address removed)

 

[Kevin Olemoh]

All I said was that perhps there needs to be a movement to remove some
of the differences in the behavior of programming languages; in effect
an effort analogus to the movement to have a set of standards for html
design so that coders don't have to code differently for four and five
browsers, not to mention accounting for the bugs within those browsers
that affect how pages are rendered. I'm not saying that there should
be one syntax standard or even that, that would be a good idea, what I
am saying is that it may be a good idea for all of these languages to
come together and take features from each other where applicable.
Maybe supporting ++ incrementation breaks something in a given
language but how can it be naive to suggest that at the very least
what that type of incrementation shorthand should be represented in
some way across the board. For example maybe you use something like:

a=3D(1) it depends.

What you are suggesting is that the differences between languages are
a good thing and thinking in different ways given the structure of a
language is a good thing, and you are correct to a point the diversity
also makes it more difficult for people to work effectively because
they have to deal with two and three sometimes totally different ways
of thinking.

This kind of thing makes communication between different people more
difficult than it would be if there was a common language that both
could use to communicate. Saying that I am naive for suggesting this
is like suggesting that it is a good idea to expect business people to
speak nearly every language currently spoken on earth rather than
gravitating towards a common language simply because the other
languages exist in the first place.

 

[Austin Ziegler]

All I said was that perhps there needs to be a movement to remove some
of the differences in the behavior of programming languages; in effect
an effort analogus to the movement to have a set of standards for html
design so that coders don't have to code differently for four and five
browsers, not to mention accounting for the bugs within those browsers
that affect how pages are rendered.

These two issues are completely unrelated; trying to relate them is a
matter of inexperience. The browser standards issue is more analagous to
the standards track for ISO C and ISO C++ than what you're suggesting,
which *is* attempting to standardize on a single set of concepts for
programming languages.

I suggest that you start learning a few more languages and understanding
how they represent different *concepts* differently, which leads to
syntactical and other differences that preclude what you're suggesting,
often.

What you are suggesting is that the differences between languages are
a good thing and thinking in different ways given the structure of a
language is a good thing, and you are correct to a point the diversity
also makes it more difficult for people to work effectively because
they have to deal with two and three sometimes totally different ways
of thinking.

I absolutely *know* that the differences are a good thing. I think that
you're misunderstanding what I'm saying because you've already made up
your mind, despite all evidence to the contrary.

This kind of thing makes communication between different people more
difficult than it would be if there was a common language that both
could use to communicate. Saying that I am naive for suggesting this
is like suggesting that it is a good idea to expect business people to
speak nearly every language currently spoken on earth rather than
gravitating towards a common language simply because the other
languages exist in the first place.

I think your position here is na=EFve, and suggests a monoglot mindset.
I'm not a polyglot, but I work with polyglots and work in a polyglot
world. International Business 101: If you're selling a product in
Mexico, you do your marketing in Spanish. More than that: you have a
Mexican person involved in the preparation of the marketing. When you're
selling in Canada, you don't advertise with the *exact* same ad that you
use in the U.S., and you really don't do so if you're selling in Quebec.

There are cultural differences; trying to make everything a monoculture
is arrogant, ignorant, and ultimately stultifying.

-austin
--=20
Austin Ziegler * (e-mail address removed) * http://www.halostatue.ca/
* (e-mail address removed) * http://www.halostatue.ca/feed/
* (e-mail address removed)

 

[Rick DeNatale]

There are cultural differences; trying to make everything a monoculture
is arrogant, ignorant, and ultimately stultifying.

This whole discussion reminds me of the old joke:

What do you call someone who speaks two languages?
Bilingual.
What do you call someone who speaks three languages?
Trilingual.
What do you call someone who speaks on language?
An American.

You know, there are some things about French which I think we should
change English to use.

Take this <<short word>> and his adjective following. Is it not
that we should put the adjective after his noun, like this <<word
short>>? Then the people french would be some people happier, when
they spoke some english! Not is that?

It would seem to be a situation win-win, not is that?

Il y'a beaucoup des langages, vivent les differences!

 

[Matt Lawrence]

This whole discussion reminds me of the old joke:

What do you call someone who speaks two languages?
Bilingual.
What do you call someone who speaks three languages?
Trilingual.
What do you call someone who speaks on language?
An American.

You know, there are some things about French which I think we should
change English to use.

Take this <<short word>> and his adjective following. Is it not
that we should put the adjective after his noun, like this <<word
short>>? Then the people french would be some people happier, when
they spoke some english! Not is that?

It would seem to be a situation win-win, not is that?

You do realize that the standard for French is maintained by a committee.
Sort of like Ada in the computer world...

-- Matt
It's not what I know that counts.
It's what I can remember in time to use.

 

[Kevin Olemoh]

Having ten dialects of the same language does not nessecarily improve
anything at all. Just as having only one thing does not nessecatily
improve anything. It really is a balancing act for example as far as
human biology is concerned there is only about a one percent
difference between any two given people on earth. If there was too
little differentiation at the genetic level we would all suffer
greater and greater genetic damage due to inbreeding and eventually
cease to exist. To call me arrogant for pointing out that too much or
too little difference (depending on the situation) is a bad thing
shows that you don't know what you are talking about. The inability
or human beings to focus on the things that the have in common has
been the source of so much greif.

Furthermore as far as computers go limiting things to a set of agreed
upon standards is part of what allowed the desktop computer as we
understand it to take off. If every manufacturer used their own
standards people would not be able to easily replace parts and they
would probably end up locked into one or two vendors. (the situation
with laptops currently.) The vendor could also charge fairly high
prices since they are the only ones who produce the hardware; however
since we have an agreed upon standard for most hardware we have low
prices and the buyer is more or less in control of his or her own
machine rather than the vendors.

Creating a common culture or language need not suppress diversity of
culture and ways of thinking in the attempt to bridge the gaps between
people and in the case of a programming language what can be done with
the various languages.