What is the reason for this syntax?

[Hal Fulton]

I'm very glad I bothered to bring this up since at least now I have a
workaround until such time that the defacto requirement for K&R style
indentation with respect to blocks is removed. I doubt any of us
would think it good to disallow the use of single letter variables in
Ruby simply because the makers all happen to think that single letter
variables are bad formatting. (Which they are but as long as you keep
them to blocks they are fine in Ruby anyway.) People would be better
served encouraging people to use comments in code other people could
reasonably be expected to need or want to read rather than forcing
users to use obscure forms of some structures, or building in silly
things like syntactic indentation that expects you to judge whitespace
for the beggining and ending of various things.

You're misunderstanding. It's not that anyone particularly was in love
with that style of brace-matching. It's just a consequence of the
language's syntax, based on features considered more important than
that kind of flexibility in pairing braces.

If you make semicolons optional, I don't know that there is any way
around the problem you perceive.

FWIW, I used to be troubled by this also. In a matter of weeks, I
got over it.


Hal

 

[Louis J Scoras]

David just because you like a given way of formatting does not mean
that everyone else should have to use it while they are creating
something even if they are working with you.

I'm not sure what you are asking for in that case. How is a language
supposed to figure out what you mean unless there is a specific
construct it understands? There has to be a specific rules for
syntax, even if it is a very simple one as with lisp.

The points you brought up are the reason people need to be using
comments in code not a reason for the language itself to try and
force a method of formatting onto its users. I can't count how many
times i have seen code that while well formatted does not make
nearly as much sense as it could because whoever wrote the code
did not put in enough comments if any at all. In the real world you
speak of people need to actually explain themselves when others
are going to be reading the code the formatting of the code is almost
entirely secondary.

I'm going to have to disagree with you on this one. More often than
not, copious comments are a bad code smell. It means that your code
isn't readable enough or is hard to follow. Try to refactor it to
make the logic cleaner instead.

(Are you sure you actually now what you are talking about what with
the overwhelming arrogance that you are exuding and all?)

You don't think you're being a little arrogant as well? You come off
as somebody that is just whining because things aren't the way you'd
like them to be. Language designers are--generally speaking--a pretty
intelligent group of people. Just because you don't like C's ternary
operator doesn't mean it was a design mistake.

I should have said that the ternary operator is a conditional
expression that often serves the same or very simillar functinction as
a "traditional" if statement in c/c++

Actually it doesn't. The ternary operator ?: is very different from
if/then in C because C, unlike Ruby, distinguishes between statements
and expressions.

However my real point was that requiring things like that which can be
very difficult to read is a mistake on the part of the people creating
the syntax of a language and that point still stands.
The only person who is flaming anyone here is you my friend.

This is purely an opinion. I find the construct to be sufficiently readable.

 

[Kevin Olemoh]

Thats why I keep sayind defacto (by default) in other words this style
became required because blocks are like parameters in ruby. I'm not
trying to say someone just happened to think K&R style was the best
thing ever with respect to blocks. This is why I asked what the
reason was for the parsing errors in my original question.

What does the first line you quoted have to do with syntax of a
language that statement was in response to davids assertion that
people should use one convention when programming in the real world
(IE one that he happens to like.) my contention is that this is not
really up to the language to enforce an indentation scheme.

With respect to copious amounts of comments what makes it a good idea
to assume that whoever else might be reading the code you have written
is at the same skill level as you are especially if you decide to
opensource your work.

Personally I try to keep the comments to anything I feel that might be
a bit strange to someone not because of formatting but because they
simply have never seen a given technique I use before. Eg:Case
statements alot of the people I know at Uni don't really understand
cases so I try to put comments near my cases if I am going to be
sharing code with them. Or I simply tell them what this or that does
while I am face to face with them.

With respect to the last line you quoted it is precisely because this
is an opinion that making it a syntactical requirement of the language
is a mistake not everyone will find the same parts of a language as
readable as others will. I find cases to be much easier to read than
if's generally should I go make a language that does not have an if
construct at all and instead only allows cases?

Also take note that I was refering to the use of ?: in c/c++ not in ruby.

As I said in the begining these are just minor annoyances I feel like
some here are taking things far too personally or are too busy trying
to pull rank on someone to actually see the point they are trying to
make. (I do not mean you Lou.)

 

[Louis J Scoras]

Thats why I keep sayind defacto (by default) in other words this style

became required because blocks are like parameters in ruby. I'm not
trying to say someone just happened to think K&R style was the best
thing ever with respect to blocks. This is why I asked what the
reason was for the parsing errors in my original question.

I know you didn't think it was a conspiracy or anything =)

Still, I think it is helpful to have a standard format for code,
whether it is enforced by the language or not. Coding standards are
established at many organizations, in the latter case, for just this
reason. Granted this is a touchy topic for a lot of people. I know
that many programmers react viscerally to the "wrong" indentation, but
you really do need a standard.

What does the first line you quoted have to do with syntax of a
language that statement was in response to davids assertion that
people should use one convention when programming in the real world
(IE one that he happens to like.) my contention is that this is not
really up to the language to enforce an indentation scheme.

You are exactly right. Unfortunately this topic generally tends to
get peoples blood boiling, probably to the same level as politics,
religion, et cetera.

Example: Should ruby enforce a two character indentation level? I'm
sure that would be a heated debate. I have my opinion, and I'm
betting it isn't the same as yours.

With respect to copious amounts of comments what makes it a good idea
to assume that whoever else might be reading the code you have written
is at the same skill level as you are especially if you decide to
opensource your work.

First, I think that it is a valid assumption that they have a grasp of
the programming language you are working in. Second, I'm not saying
that you shouldn't have _documentation_. I'm saying that you
shouldn't clutter your code with excess comments. You should have
developer documentation that you keep along with the code (with your
code artifacts, but not inside them).

Personally I try to keep the comments to anything I feel that might be
a bit strange to someone not because of formatting but because they
simply have never seen a given technique I use before. Eg:Case
statements alot of the people I know at Uni don't really understand
cases so I try to put comments near my cases if I am going to be
sharing code with them. Or I simply tell them what this or that does
while I am face to face with them.

*Shrugs.* I would assume that someone reading my code would know the
standard constructs of the language the program is written in. I
wouldn't annotate and English poem with grammar notes--unless I'm
writings a textbook on teaching English poetry.

With respect to the last line you quoted it is precisely because this
is an opinion that making it a syntactical requirement of the language
is a mistake not everyone will find the same parts of a language as
readable as others will. I find cases to be much easier to read than
if's generally should I go make a language that does not have an if
construct at all and instead only allows cases?

You need to have some way of expressing the concept. The implementers
have to select one or you don't get the feature unfortunately.

Also take note that I was refering to the use of ?: in c/c++ not in ruby.

As I said in the begining these are just minor annoyances I feel like
some here are taking things far too personally or are too busy trying
to pull rank on someone to actually see the point they are trying to
make. (I do not mean you Lou.)

Well, people will be people, and as I said above this topic tends to
be quite touchy for programmer types. Who knows why? Don't let it
bother you =)

I get what you are saying, but I still think that claiming that these
issues constitute a design error is a mistake.

 

[MonkeeSage]

Coding conventions (like where you place your braces in C) are
completely different from language syntax rules (like where parameters
to functions and blocks must be). You can code however you like *within
the bounds of the language syntax*. In C you can't write this, no
matter how much you like it:

printf "%s", "Hi" !

The C syntax requires parens for function invocation, and requires a
line to be terminated by a semi-colon, not an exclaimation mark. So by
all means, write your ruby code however you like it, but don't confuse
issues of coding convention with issues of syntaxis.

Coding convention:

if (blah.nil?) <- parens

if blah.nil? <- none


Syntax:

blah { block stuff } <- correct

blah < block stuff > <- invalid

blah
{ <- invalid (well, valid syntax, but taken as hash literal not method
block to #blah)
}

Regards,
Jordan

 

[Kevin Olemoh]

What you say is valid and gets right to what I am really trying to get
at with respect to the blocks the syntax rule is a bit too strict is
all. You have pointed out the distinction better than I was able to
that is for sure.

 

[David Vallner]

--------------enig7D67C73E474C8DC75375704F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

David just because you like a given way of formatting does not mean
that everyone else should have to use it while they are creating
something even if they are working with you. =20

It's not about personal preference, it's about accepted conventions.
Sun's *official* style guidelines say camelCase, and { on same line.
Microsoft's *official* style guidelines say PascalCase and { on new
line. I follow the former convention when coding Java, the latter when
coding C#. I snake_case method names for Ruby and Python, never in Java,
I don't write code with camelCase in Ruby either.

I do that precisely because my personal preference doesn't matter.
However, I realise there are people with more inertia using an
environment on the team, who are probably less flexible about that.
That's why I will follow the convention most likely to be agreed upon -
to make my code -less alienating to them-, and not to me. I mean, I
wrote the thing in the first place, and know where to click in an IDE to
move around my code by heart by then, I don't need these basic visual
aids to navigate.

The points you brought
up are the reason people need to be using comments in code not a
reason for the language itself to try and force a method of formatting
onto its users.=20

I never said anything about language-enforced formatting. Ruby does so
only where required by the semicolon-less syntax, and you just happened
to hit a sore spot of yours that just isn't parseable the way you would
like, period. It's not an arbitrary restriction someone made up because
it looks prettier.

However, personal preference is, in my opinion, not a reason to not
follow convention even if the convention isn't enforced.

In the real world you speak of people need to actually
explain themselves when others are going to be reading the code

Explaining themselves comes when it's time for code review. Often, that
time isn't. Also, most of real-life codereading occurs when the original
author has long ran for the hills.

the formatting of the code is almost entirely secondary.

Obviously, it isn't if you're willing to write reams of debate about how
you object to having to conform to a hard parser restriction.

Also, I take it you haven't tried to use CVS / SVN in a team with people
that run commits through a code beautifier first (generally a Good Idea
for the sake of consistency and general readability - noone likes
terminal-widening doc comments). If two people happen to have to edit
the same source file, and each one wildly repositions the braces, any
and all method signatures (for C-likes) stop matching and all hell
breaks loose as suddenly the file is in conflict in umpty places that
none of those people remember editing. Much groaning and valuable time
lost doing a manual merge follows.

This is what wikipedia has on the ternary operator
http://en.wikipedia.org/wiki/?:
=20

I'm not particularly interested in random references to your external
brain. Especially if you don't bother to read it.

"?: is a ternary operator that is part of the syntax for a basic
conditional expression"

C's if is syntax for a conditional statement, not expression.

(Are you sure you actually now what you are talking about what with
the overwhelming arrogance that you are exuding and all?)
=20

Yes. Don't confuse arrogance with being confident in one's skill /
experience. I don't have much of either in absolute values, but I've
already got a fair pile of irksome screwups of which some were relevant
to the topic at hand collected which I've seen, and of course done.

If I was being actually arrogant, I'd say I consider your tone moany,
your nitpicking at trivial issues childish, and your rants ill-informed.

Whoops, looks like I just did. Well, I'm glad the formal pleasantries
have been exchanged.

The only person who is flaming anyone here is you my friend.
=20

Why, yes, I am. And?

David Vallner
Troll


--------------enig7D67C73E474C8DC75375704F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFJxeMy6MhrS8astoRAp2HAJ4hk/fLLgpiS/kxJPG1qrzNjijcFQCcDCYC
lGcSAoZ623/T03ahjxFJkC4=
=I+9X
-----END PGP SIGNATURE-----

--------------enig7D67C73E474C8DC75375704F--

 

[Louis J Scoras]

Coding conventions (like where you place your braces in C) are
completely different from language syntax rules (like where parameters
to functions and blocks must be). You can code however you like *within
the bounds of the language syntax*.

Correct. The issue is how the language decides to draw the line
between the two.

Take whitespace for instance, as has already been brought up in this
thread. In some languages whitespace is syntactically meaningful,
while in others it is not. If you believe that indentation should be
purely a formatting issue then you probably prefer the latter.

Also, you bring up brace style in C. It is true that this matter is
left up to convention: the compiler doesn't care about whitespace here
and you can break a line before a brace if you wish. However, there
isn't any technical reason why it couldn't be a syntactic requirement.

The C compiler could have easily said

int foo(int x) {
// body
}

is correct, while

int foo(int x)
{
// body
}

is a compile time error. And why not? <Deity> clearly intended the
former, right? =)


I'm not entirely sure, but its possible that I might be--at least
partially--playing devil's advocate here. I'll admit that I haven't
thought about it enough to be certain whether this would bother me or
not. That being said, however, I strongly suspect that it would
*not*.

Do I wish that you could split lines in ruby before an operator rather
than after? Yes. Do I care? Not really. As long as it is consistant
in all of the code, its fine.

All of this leads to the question: If you have to code to a standard
anyway--which you should--would you mind if the language enforced said
standard?

 

[MonkeeSage]

All of this leads to the question: If you have to code to a standard
anyway--which you should--would you mind if the language enforced said
standard?

Me? I don't mind justified syntax rules; but I don't like the coding
conventions of others to be forced on me. I don't like the (ethical?)
imperative "should" for subjective issues of taste. Regarding the OP's
gripe, the syntax rules there seem justified to me:

This has one syntactical meaning:

blah do
stuff
end

This has another:

blah
do
stuff
end while cond

And this has yet another:

blah
{ 'stuff' => 'more stuff' }.display

So requiring the block to start on the same line as the method
invocation is not simply that Matz likes to write code that way, but
that it creates a (not easily resolved!) syntactical ambuity otherwise.
So I don't think that the gripe has merit. However, speaking
hypothetically, if parens are valid in conditionals for grouping (i.e.,
if (a and b) or c ), yet there was a syntax rule that a conditional
without a disjunction or conjunction (i.e., if a ) could not use them,
for no other reason than because Matz didn't like them to be used that
way; then I would be annoyed.

Regards,
Jordan

 

[MonkeeSage]

All of this leads to the question: If you have to code to a standard
anyway--which you should--would you mind if the language enforced said
standard?

Me? I don't mind justified syntax rules; but I don't like the coding
conventions of others to be forced on me. I don't like the (ethical?)
imperative "should" for subjective issues of taste. Regarding the OP's
gripe, the syntax rules there seem justified to me:

This has one syntactical meaning:

blah do
stuff
end

This has another:

blah
do
stuff
end while cond

And this has yet another:

blah
{ 'stuff' => 'more stuff' }.display

So requiring the block to start on the same line as the method
invocation is not simply that Matz likes to write code that way, but
that it creates a (not easily resolved!) syntactical ambuity otherwise.
So I don't think that the gripe has merit. However, speaking
hypothetically, if parens are valid in conditionals for grouping (i.e.,
if (a and b) or c ), yet there was a syntax rule that a conditional
without a disjunction or conjunction (i.e., if a ) could not use them,
for no other reason than because Matz didn't like them to be used that
way; then I would be annoyed.

Regards,
Jordan

 

[MonkeeSage]

All of this leads to the question: If you have to code to a standard
anyway--which you should--would you mind if the language enforced said
standard?

Me? I don't mind justified syntax rules; but I don't like the coding
conventions of others to be forced on me. I don't like the (ethical?)
imperative "should" for subjective issues of taste. Regarding the OP's
gripe, the syntax rules there seem justified to me:

This has one syntactical meaning:

blah do
stuff
end

This has another:

blah
do
stuff
end while cond

And this has yet another:

blah
{ 'stuff' => 'more stuff' }.display

So requiring the block to start on the same line as the method
invocation is not simply that Matz likes to write code that way, but
that it creates a (not easily resolved!) syntactical ambuity otherwise.
So I don't think that the gripe has merit. However, speaking
hypothetically, if parens are valid in conditionals for grouping (i.e.,
if (a and b) or c ), yet there was a syntax rule that a conditional
without a disjunction or conjunction (i.e., if a ) could not use them,
for no other reason than because Matz didn't like them to be used that
way; then I would be annoyed.

Regards,
Jordan

 

[MonkeeSage]

the same thing three times

Ack...sorry. Google acting up again.

 

[Austin Ziegler]

What you say is valid and gets right to what I am really trying to get
at with respect to the blocks the syntax rule is a bit too strict is
all. You have pointed out the distinction better than I was able to
that is for sure.

It's not too strict. You're wanting something unreasonable. Most of us
(I think) don't want to have explicit expression terminators. If we
did, we'd be using Perl (which has explicit expression terminators).

The cost of not having explicit expression terminators is either a
much slower parser or one that has slightly stricter rules about where
certain things can appear. In your case:

blah
do |x, y|
...
end

do |x,y| is not a valid expression. However, in the case of:

blah
1, 2
do |x, y|
...
end

1, 2 is a valid expression.

I'd much rather have the expressiveness Ruby gives with minor
inconveniences (which isn't "K&R style" as much as you'd like to
pretend it is) than needing to end expressions with a semicolon in all
cases.

You'll get over your desire soon enough.

-austin

 

[Tom Armitage]

With respect to copious amounts of comments what makes it a good idea
to assume that whoever else might be reading the code you have written
is at the same skill level as you are especially if you decide to
opensource your work. [snip]
Eg:Case
statements alot of the people I know at Uni don't really understand
cases so I try to put comments near my cases if I am going to be
sharing code with them. Or I simply tell them what this or that does
while I am face to face with them.

I want to go back to this.

Comments aren't to do with bringing people up to a skill level.
Comments are to do with explaining things that anyone of a reasonable
skill level couldn't work out.

I'm not a fulltime programmer, and I don't have a CS degree. But I
work in Ruby quite a lot. I've seen quite a bit I don't understand -
in opensource and internal projects - and I've either *worked it out*
or *asked somebody*.

So: case statements are a classic example. I don't think it's
unreasonable to assume a half-skilled programmer would get a case
statement. But even if they don't, because they've used some evil
language without them forever, I expect them *to be able to use
Google*. (Similarly: I'd expect a Ruby programmer to know certain
idioms, even if they don't use them themselves).

Here we go: Ruby case expressions, straight from the pickaxe:
http://whytheluckystiff.net/ruby/pickaxe/html/tut_expressions.html#S5

If the first line: "The Ruby case expression is a powerful beast: a
multiway if on steroids." doesn't make things blindingly clear, the
two examples do. If you don't know about Ruby's case statements...
well, now you do! Wow!

There's a difference between "reasonable" syntax (stuff I use that you
may not use, but you can understand) and "unreasonable" syntax
(hideously obfuscated one-liners, I'm looking at you, Perl).

Comments aren't to explain things in the langauge someone might not
understand. They're to explain things in your program; WHY you do a db
write everytime someone logs in; HOW the API to the other server
should be implemented; WHAT the reasons behind a chunk of code are.
They're not to educate the other programmer.

There's been a lot of "real world" talk. In the real world, comments
are almost never for things "that might be a bit strange to someone
not because of formatting but because they simply have never seen a
given technique I use before". They are often for documenting which
technique you've used - for instance, how I document CSS hacks - but
that's as much for yourself as for other people. It's not about
education. There are other resources for that.

And, as a hacky programmer with no formal training, I say that having
used those other resources copiously.

 

[M. Edward (Ed) Borasky]

There's a difference between "reasonable" syntax (stuff I use that you
may not use, but you can understand) and "unreasonable" syntax
(hideously obfuscated one-liners, I'm looking at you, Perl).

Yeah, but you don't *have* to write hideously obfuscated one-liners in
Perl. In APL, that's the *only* way you can code!

<ducking>

 

[Booker C. Bense]

-----BEGIN PGP SIGNED MESSAGE-----

I don't think of the blocks in the same way the real problem is that
since the open brace is so close to the close to another character I
have trouble actually seeing the brace itself. Editors that support
brace matching are great and I use them but they don't help much if I
am looking at code in a book or on a webpage.

When I say "until such time as the defacto requirement for K&R style
formating with respect to blocks is removed..." I do not mean making
said style illegal in anyway, all I mean is that programs breaking
because someone didn'r use this style is eliminated.

_ It's NOT a formating convention. Newlines are end of statements
in Ruby, not formatting convience. Until you get your head around
that you'll have a really hard time with Ruby. If you don't like
this, pick another language. You're asking Ruby to be broken in
a very fundemental way.

If you're familiar with perl, your request would be that perl
should honor this syntax

array.each ;
do {
#stuff
};


_ Booker C. Bense

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBRS0ycGTWTAjn5N/lAQEC4gQAiSazPxFXxoYyvnQsf/5a0bcOpHyoUIz9
amSkZLJKMqH7QXh1dfLuppYuYsh6m6cqLy0GjG6+YzVyK8kuqdTgWiHBSLfXeblw
Mu2dUPeduXaXyS6VyNpv4/UgOQxR1hAwoPyu4a+qAD5zY5mCO4BdkdxCavEabrxy
qiJQ9jXD9gs=
=ClJp
-----END PGP SIGNATURE-----

 

[Rick DeNatale]

With respect to copious amounts of comments what makes it a good idea
to assume that whoever else might be reading the code you have written
is at the same skill level as you are especially if you decide to
opensource your work. [snip]
Eg:Case
statements alot of the people I know at Uni don't really understand
cases so I try to put comments near my cases if I am going to be
sharing code with them. Or I simply tell them what this or that does
while I am face to face with them.

I want to go back to this.

Comments aren't to do with bringing people up to a skill level.
Comments are to do with explaining things that anyone of a reasonable
skill level couldn't work out.

Hear, hear!

There are are also dangers to overcommenting.

Some years ago Gerry Weinberg wrote the classic "Psychology of
Computer Programming" and he talked about this.

One danger is that you can fall into the trap of debugging the
comments rather than the code when something doesn't work. The
comments are really only the authors *opinion* of what the code is
supposed to be doing. If you can't write clear code, and rely on
comments to 'explain' your thinking, you, or someone who comes after
you, can be tricked into thinking that the comments are accurate, and
miss what's really happening when the code and the comments don't
agree.

Weinberg went so far as to suggest that a useful tool would be one
which stripped source code of all comments.

If the guys you are sharing code with don't understand the language,
either teach them or give them a book on the language.

 

[Kevin Olemoh]

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.


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.

I'm sure a word processor could be written that would dissallow using
a carriage return after only one sentence. You could argue that you
are trying to enforce good formatting rules with respect to
paragraphs, but your argument in no way invalidates the fact that
people should be able to use a carriage return whenever and however
they see fit.

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?

With respect to copious amounts of comments what makes it a good idea
to assume that whoever else might be reading the code you have written
is at the same skill level as you are especially if you decide to
opensource your work. [snip]
Eg:Case
statements alot of the people I know at Uni don't really understand
cases so I try to put comments near my cases if I am going to be
sharing code with them. Or I simply tell them what this or that does
while I am face to face with them.

I want to go back to this.

Comments aren't to do with bringing people up to a skill level.
Comments are to do with explaining things that anyone of a reasonable
skill level couldn't work out.

Hear, hear!

There are are also dangers to overcommenting.

Some years ago Gerry Weinberg wrote the classic "Psychology of
Computer Programming" and he talked about this.

One danger is that you can fall into the trap of debugging the
comments rather than the code when something doesn't work. The
comments are really only the authors *opinion* of what the code is
supposed to be doing. If you can't write clear code, and rely on
comments to 'explain' your thinking, you, or someone who comes after
you, can be tricked into thinking that the comments are accurate, and
miss what's really happening when the code and the comments don't
agree.

Weinberg went so far as to suggest that a useful tool would be one
which stripped source code of all comments.

If the guys you are sharing code with don't understand the language,
either teach them or give them a book on the language.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

 

[Rimantas Liubertas]

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?

I think it is well within human capacity to accept some rules of the language -
or to choose another language if one does still does not like the rules.
There were numerous explanations in this thread why Ruby behaves the
way it does,
and, frankly, I do like it this way.


Regards,
Rimantas

 

[Kevin Olemoh]

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.

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.

Where did I say it was easy to fix? I said it is easier to address
this type of thing in something that is manufactured rather than
something "grows" like a spoken language. So please do pull your head
out of your backside ahnd don't shove words in my mouth thank you.