Curly braces
Alexey Gokhberg
if x > 0 {
sign = 1
} else if x == 0 {
sign = 0
} else {
sign = -1
x = -x
}
From time immemorial I use the ancient style of Kernighan & Plauger's
"Software Tools" while coding in Ratfor, C, C++, and Java. I would
like to continue using this style with Go and format the above
statement like this:
if x > 0 {
sign = 1
}
else if x == 0 {
sign = 0
}
else {
sign = -1
x = -x
}
Unfortunately, this code is illegal in Go: compiler will insert
semicolons after closing braces.
In principle, it should be possible to change slightly the syntax
rules of Go by forbidding automatic insertion of semicolons before the
"else" token. This change will not affect Go code formatted in the
standard way, but will give more freedom to programmers.
Would it make sense to introduce such a change in Go specification?
Peter Bourgon
the infancy of golang-nuts; check the archive to learn more. In short,
no, this will not happen. Best to accept it and move on to more
interesting topics. And frankly I find your particular mutation of
brace style really horrific, I would oppose it on humanitarian grounds
anyway ;)
bflm
> I would
> like to continue using this style with Go and format the above
> statement like this:
>
> if x > 0 {
> sign = 1
> }
> else if x == 0 {
> sign = 0
> }
> else {
> sign = -1
> x = -x
> }
>
> Unfortunately, this code is illegal in Go: compiler will insert
> semicolons after closing braces.
used to (the formatting) and is valid Go:
switch {
case x > 0: {
sign = 1
}
case x == 0: {
sign = 0
}
default: {
Alexey Gokhberg
But I agree - there are more interesting topics indeed. There is not
much to discuss about braces; I will simply implement the feature I
want in the next release of Express Go.
On 22 Sep., 22:34, Peter Bourgon <peterbour...@gmail.com> wrote:
> There have been long and protracted discussions about brace style in
> the infancy of golang-nuts; check the archive to learn more. In short,
> no, this will not happen. Best to accept it and move on to more
> interesting topics. And frankly I find your particular mutation of
> brace style really horrific, I would oppose it on humanitarian grounds
> anyway ;)
>
> On Wed, Sep 22, 2010 at 10:27 PM, Alexey Gokhberg
>
>
>
Alexey Gokhberg
On 22 Sep., 23:45, bflm <befelemepesev...@gmail.com> wrote:
> In this particular case the following may be closer to what you're
> used to (the formatting) and is valid Go:
>
> switch {
> case x > 0: {
> sign = 1
> }
> case x == 0: {
> sign = 0
> }
> default: {
> sign = -1
> x = -x
> }
>
reasonable:
switch {
case x > 0:
sign = 1
case x == 0:
sign = 0
default:
sign = -1
x = -x
}
Steven
yy
> But why always "switch" if there is "if-else" there?
And why if-else if you have switch. Personally, I would have prefered
that they were merged:
if {
x > 0:
sign = 1
x == 0:
sign = 0
else:
sign = -1
x = -x
}
But I'm sure this construction will also have its own problems (I
don't want to spend time thinking about them). If you look at all the
stuff that you can do with if and switch you will see that they can
really do a lot of different things. Sometimes both overlap and you
can chose, that's all.
You know what? Go is probably the most readable language I have seen.
I want to think this is a consequence of the good taste of the
designers when deciding about these small details, even if I don't
agree with every single decission. We could argue about syntax the
whole life, but I doubt that is going to make the language any better.
--
- yiyus || JGL . 4l77.com
Uriel
<expre...@unicorn-enterprises.com> wrote:
> The style is not mine, it is Kernighan and Plauger's. :)
I'm not sure about Plauger, but it would seem that Kernighan moved on
from that style long ago, check your copies of K&R and The Practice of
Programming.
In any case this is a very silly and unproductive topic, and Go's
tendency to encourage a single style, plus the wonderful help of
gofmt, are very good things that save plenty of time of senseless
arguments.
I'm as liberal as you can get, but maybe some times less freedom can
be a good thing in certain contexts? It certainly makes it easier to
decide how to do things.
uriel
Steven
On Thu, Sep 23, 2010 at 12:50 AM, Alexey Gokhberg
<expre...@unicorn-enterprises.com> wrote:
> The style is not mine, it is Kernighan and Plauger's. :)I'm not sure about Plauger, but it would seem that Kernighan moved on
from that style long ago, check your copies of K&R and The Practice of
Programming.
In any case this is a very silly and unproductive topic, and Go's
tendency to encourage a single style, plus the wonderful help of
gofmt, are very good things that save plenty of time of senseless
arguments.
I'm as liberal as you can get, but maybe some times less freedom can
be a good thing in certain contexts? It certainly makes it easier to
decide how to do things.
uriel
Jay Sistar
Ok, your reference to Orwell implies that you think of the formating rules as a hinderance to your personal, rather than syntactic freedom. We are speaking about syntax, not rights.
Your argument looks to me (and I'm sure to other Go progrmmers) like an argument that multiple spellings or word orderings for the English language should be allowed. That allowance would cause mass confusion, and it would benefit nobody.
I understand that it's the norm for languages to allow much more syntatic flexibility than Go, but that is also the reason that more apps like auto binders (like cgo), IDL from source generators, and symbol extractors for IDEs are so few. Simpler is better when your going to have to parse it yourself (not just the compiler).
Also, when you say "bogus syntatic reasons" please provide the yacc rules as they are, then which ones would be eliminated, which ones would be changed, and which ones would be added. Accually, if you could just send a zip of the modified gofmt source with the changes that you propose, that would make us all give your claim some good thought. You might be right, after all, and if you are, then that source would tell us just how right you are.
-Jay
>
>
> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
> Well, programmers have varying preferences and I don't think that
> gofmt output would provide the most suitable format for all of them.
> On another hand, those who like this format could always use gofmt to
> convert any foreign Go code to their favourite uniform style. So why
> not to allow a bit more freedom?
>
> Alexey
>
> P.S.
>
> "ORWELLIAN NEWSPEAK: The two examples above illustrate how, all too
> often, Go "knows what is good for you" and won't let you deviate from
> the party line. This goes as far as imposing where the braces go for
> rather bogus syntactic reasons, deciding when you can use upper-case
> letters, or formatting the code automatically when you submit it!"
> http://grenouille-bouillie.blogspot.com/2010/03/why-go-isnt-my-favourite-programming.html
> [1]
> On Wed 22/09/10 5:15 PM , Jay Sistar jsis...@gmail.com sent:
> No please. The gofmt app was made to make all go code the same for
> easy reading by other programmers. All Go code -should- use the same
> style to remove the possibilty of misreading (by humans).
>
> -Jay
>
>
>
> Links:
> ------
> [1]
> http://grenouille-bouillie.blogspot.com/2010/03/why-go-isnt-my-favourite-programming.html
chris dollin
> Your argument looks to me (and I'm sure to other Go progrmmers) like an
> argument that multiple spellings or word orderings for the English language
> should be allowed.
As indeed they are -- since you must know that, I assume you're
being ironic.
> That allowance would cause mass confusion, and it would
> benefit nobody.
That's certainly not true.
> I understand that it's the norm for languages to allow much more syntatic
> flexibility than Go, but that is also the reason that more apps like auto
> binders (like cgo), IDL from source generators, and symbol extractors for
> IDEs are so few. Simpler is better when your going to have to parse it
> yourself (not just the compiler).
That depends what "syntactic flexibility" you're talking about. The
difficulties in, say, C, are to do with context-sensitivity; you can't
correctly parse C without doing semantic analysis. (Not to mention
the dog's breakfast of conditional compilation.) That's not (just)
"syntactic flexibility", that's sowing the path with caltrops. Brace
placement is hardly in that category, and the rules on brace placement
in Go are at least partly a consequence of a deliberate decision to make
the semicolon-insertion rule not depend on the tokens on the following
line.
> Also, when you say "bogus syntatic reasons" please provide the yacc rules as
> they are, then which ones would be eliminated, which ones would be changed,
> and which ones would be added. Accually, if you could just send a zip of the
> modified gofmt source with the changes that you propose, that would make us
> all give your claim some good thought. You might be right, after all, and if
> you are, then that source would tell us just how right you are.
Oh, come on; "If you don't do this expensive thing we won't take your
views seriously". That's not an argument, that's bullying. It's reasonable
to illustrate the non-trivialities and ask how they might be addressed;
it's not reasonable to ask for the entire answer. Apart from anything else,
/both/ sides stand to gain by talking about it before putting further
effort into it -- and it looks like the Go teams' opinions are pretty much
fixed. (I'm not sure why they thought that fixing brace style would /stop/
arguments about the Right Way, because it clearly wouldn't and doesn't.)
There are certainly aspects of Go that seem more important than code
layout style -- like, no conditional expressions and a slightly-broken
test for checking that a function exits along all its paths -- but the
characters and their layout is, after all, /the/ way the code gets into
(most of our) our heads, and we all have our own perceptual foibles
and preferences; it's not surprising that it's contentious.
Chris
--
Chris "you should be able to guess my position" Dollin
Cory Mainwaring
slow compile times if the compiler has to move back and forth in the
source during the semi-colon placement (can't just be read through the
one time, spots in the source must be touched multiple times with this
change).
This will slow your compile times, maybe not by much, but at least by
some, which is something the powers that be will not look favorably
on. If you can figure out how to not "look ahead" and do semi-colon
insertion whilst allowing that syntax, there's no other valid argument
to not having it be allowed. It won't be standard syntax, but it will
be compilable.
Alexey Gokhberg
On 23 Sep., 15:19, Jay Sistar <jsist...@gmail.com> wrote:
> Ok, your reference to Orwell implies that you think of the formating rules
> as a hinderance to your personal, rather than syntactic freedom. We are
> speaking about syntax, not rights.
I cite in my post. And as far as I could understand, he means
precisely the syntactic, not personal freedom.
>
> Your argument looks to me (and I'm sure to other Go progrmmers) like an
> argument that multiple spellings or word orderings for the English language
> should be allowed. That allowance would cause mass confusion, and it would
> benefit nobody.
>
freedom to place on a page correctly spelled words of a grammatically
correct text.
> I understand that it's the norm for languages to allow much more syntatic
> flexibility than Go, but that is also the reason that more apps like auto
> binders (like cgo), IDL from source generators, and symbol extractors for
> IDEs are so few. Simpler is better when your going to have to parse it
> yourself (not just the compiler).
>
auto binders, IDL from source generators, and symbol extractors for
IDEs to an issue of placing braces?
I actually argued that:
"programmers have varying preferences and I don't think that gofmt
output would provide the most suitable format for all of them. On
another hand, those who like this format could always use gofmt to
convert any foreign Go code to their favourite uniform style. So why
not to allow a bit more freedom?"
> Also, when you say "bogus syntatic reasons" please provide the yacc rules as
> they are, then which ones would be eliminated, which ones would be changed,
> and which ones would be added. Accually, if you could just send a zip of the
> modified gofmt source with the changes that you propose, that would make us
> all give your claim some good thought. You might be right, after all, and if
> you are, then that source would tell us just how right you are.
>
entire working Go compiler that accepts the proposed syntax change.
Could I hope that then my views would be "worth a good thought"?
Cory Mainwaring
won't be. Compile speed is much more important than making things more
flexible.
On 23 September 2010 11:19, Alexey Gokhberg
Alexey Gokhberg
On 23 Sep., 17:22, Cory Mainwaring <olre...@gmail.com> wrote:
> If it slows down compile time by more than 0.5% or so, likely, it
> won't be. Compile speed is much more important than making things more
> flexible.
>
Jay Sistar
I don't mean to bully you. The changing of gofmt to decide new style rules was how these sorts of discussions were meant to be settled. (See Rob Pike's October 2009 video on YouTube when he talks about gofmt).
Also, I don't think it's expensive to show yacc rule changes. That's the purpose of yacc: to make it easy to define and change the rules. Please don't interpret this as bullying, I'm just paraphrasing documentation from memory.
Becides, as Cory points out, if you look at the rules with the prism of the goals of Go, you could find insight as to why they are as the are.
Please see:
$GOROOT/src/cmd/gc/go.y
Alexey Gokhberg
On 23 Sep., 17:03, Cory Mainwaring <olre...@gmail.com> wrote:
> Allowing this would force the compiler to "look ahead" which could
> slow compile times if the compiler has to move back and forth in the
> source during the semi-colon placement
'expr_or_type' in GO.Y without some sort of look ahead.
Peter Bourgon
<expre...@unicorn-enterprises.com> wrote:
> "programmers have varying preferences and I don't think that gofmt
> output would provide the most suitable format for all of them. On
> another hand, those who like this format could always use gofmt to
> convert any foreign Go code to their favourite uniform style. So why
> not to allow a bit more freedom?"
>
> Wouldn't you agree with this?
Part of learning a new language is learning its idioms. One of Go's
idioms is that there should generally be only one idiomatic (heh) way
of doing something, and that idiom extends to the formatting. This
contributes to a feeling in the language that I, personally, find
really great and unique: emphasis on readability & maintainability
through a sort of uniformity. Monkey-patching this is not (and thank
God for that).
So no, in the general case and in Go's case specifically, I don't
agree that "allowing a bit more freedom" is always the correct thing
to do. "Programmers' varying preferences" are not sacrosanct,
especially w.r.t. such ultimately inconsequential things as brace
style.
Alexey Gokhberg
On 23 Sep., 17:43, Peter Bourgon <peterbour...@gmail.com> wrote:
> Part of learning a new language is learning its idioms. One of Go's
> idioms is that there should generally be only one idiomatic (heh) way
> of doing something, and that idiom extends to the formatting. This
> contributes to a feeling in the language that I, personally, find
> really great and unique: emphasis on readability & maintainability
> through a sort of uniformity.
>
from being readable or uniform:
if x > 0 {
abs = x
sign = 1
} else if x == 0 { abs = 0; sign = 0 } else {
abs = -x;
sign = -1 }
Go syntax does not forbid such a horrible layout. In this context,
what role could play the severe syntactic restrictions on placing
braces?
I think that in fact uniformity in Go coding style cannot be achieved
without some sort of the style guide, not enforceable by the syntax,
and with this respect Go is not different from the commonly used
languages.
Cory Mainwaring
layout. Sure, it's not strictly enforced, but it's a standard of the
Go community (you can't get it submitted to the source without it
getting formatted). The standard library typically determines what
outside libraries look like for many languages today, and having a
tool that can easily retool the layout of a source tree with a command
or two is a powerful way of maintaining uniformity.
On 23 September 2010 12:05, Alexey Gokhberg
Alexey Gokhberg
one contains the standalone brace and the second starts with "else"?
On 23 Sep., 18:08, Cory Mainwaring <olre...@gmail.com> wrote:
> run any piece of Go code through gofmt and you get a uniform style and
> layout. Sure, it's not strictly enforced, but it's a standard of the
> Go community (you can't get it submitted to the source without it
> getting formatted). The standard library typically determines what
> outside libraries look like for many languages today, and having a
> tool that can easily retool the layout of a source tree with a command
> or two is a powerful way of maintaining uniformity.
>
Eleanor McHugh
> Your argument looks to me (and I'm sure to other Go progrmmers) like an argument that multiple spellings or word orderings for the English language should be allowed. That allowance would cause mass confusion, and it would benefit nobody.
It's a nice theory however your basic premise simply isn't true. British English (both colloquial and as codified in our much-ignored grammar textbooks) does allow both multiple spellings and extensive variation of word ordering without any particular loss of clarity. Indeed the ambiguity arising from these subtleties is often considered a positive benefit by many of its more advanced users and as a result is embraced in numerous literary works.
Indeed the common usage of English is probably best summed up by a quote from Alice in Wonderland:
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less."
"The question is, " said Alice, "whether you can make words mean so many different things."
"The question is," said Humpty Dumpty. "which is to be master—that's all."
As programmers it's the very nature of our avocation that we are the masters of words and not their servants, otherwise we wouldn't have the temerity to coin new usages on a daily basis. And if meaning is to be malleable to our needs then why should syntax be any less our tool?
Ellie
Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason
Peter Bourgon
> from being readable or uniform:
>
> if x > 0 {
> abs = x
> sign = 1
> } else if x == 0 { abs = 0; sign = 0 } else {
> abs = -x;
> sign = -1 }
>
> Go syntax does not forbid such a horrible layout. In this context,
> what role could play the severe syntactic restrictions on placing
> braces?
I consider the fact that Go syntax does not forbid such code layout a
quirk of the implementation, rather than a product of the design. In
other words, I reject the framing and implicit assumptions of your
question.
Cory Mainwaring
submit the consensus thus far has been no.
On 23 September 2010 12:15, Alexey Gokhberg
Alexey Gokhberg
On 23 Sep., 18:17, Peter Bourgon <peterbour...@gmail.com> wrote:
> I consider the fact that Go syntax does not forbid such code layout a
> quirk of the implementation, rather than a product of the design. In
> other words, I reject the framing and implicit assumptions of your
> question.
describes syntax that allows such kind of layout. This has little to
do with implementation, I think.
Russ Cox
a net loss for programmer productivity: it makes
mixing code harder, programmers used to one
style have a hard time working with programmers
who insist on another style, and countless hours
are spent debating which one is best.
No one style is best: they are all just different, and
people can adapt to one or the other easily enough.
I had to learn a new style when I started at Bell Labs,
when I started at MIT, when I started at Google, and
when I've started contributing to essentially any
open source project. The familiar style is only that.
We built gofmt to avoid this productivity time sink.
I am sure that every one of the Go developers sees
things they disagree with in the output, but having
a precisely defined, agreed upon, automated style
means we can spend more time coding and less
time wondering where to put a brace or parenthesis.
On to the specific issue of this brace...
Compile time is not relevant here.
Lookahead has no cost in the parser.
Lookahead does have a cost in the language:
it complicates the rule about semicolon insertion,
a rule that is intentionally as simple as possible
so that the behavior will be as predictable as possible.
(Compare this situation to the one in JavaScript,
where semicolons are inserted only when trying
to recover from a syntax error.)
Since the semicolon insertion rule is compatible
with the existing gofmt style and the point of gofmt
was to avoid having lots of variant styles, we felt
(and still feel) no need to complicate the rule to
enable complexity we're trying to avoid.
Lookahead also has a cost in an interactive interpreter:
having to look at the next token requires the person
using the interpreter to type a next token. Typically
interpreters solve this problem by requiring an explicit
end-of-statement like a ; or by changing the input
language they accept. For example, Python will run
this program if read from a file:
if True:
pass
else:
pass
but if you paste it into the interpreter, it will treat the blank
line as finishing the if statement, and then the else is
a syntax error.
Not having the lookahead in the language means that
an interpreter can accept exactly the same language
that the compiler does, without any workarounds.
I admire that you've managed to avoid learning a
new coding style since 1976, but I'd still encourage
you to give writing Go in the standard style a try.
It will mean that you can share code easily with
others, and when you read other code, you will
not be distracted by seeing the standard formatting.
I also think it has a real benefit for the interpreter
you're building.
Russ
Alexey Gokhberg
On 23 Sep., 18:17, Cory Mainwaring <olre...@gmail.com> wrote:
> Nope, but does everyone want their code to look like that?
...
}
else if ... {
...
into pretty
...
} else if ... {
...
Why not to want it?
Eleanor McHugh
> On Thu, Sep 23, 2010 at 5:19 PM, Alexey Gokhberg
> <expre...@unicorn-enterprises.com> wrote:
>> "programmers have varying preferences and I don't think that gofmt
>> output would provide the most suitable format for all of them. On
>> another hand, those who like this format could always use gofmt to
>> convert any foreign Go code to their favourite uniform style. So why
>> not to allow a bit more freedom?"
>>
>> Wouldn't you agree with this?
>
> Part of learning a new language is learning its idioms. One of Go's
> idioms is that there should generally be only one idiomatic (heh) way
> of doing something, and that idiom extends to the formatting. This
> contributes to a feeling in the language that I, personally, find
> really great and unique: emphasis on readability & maintainability
> through a sort of uniformity. Monkey-patching this is not (and thank
> God for that).
The thing about uniformity is that humans are all a bit idiosyncratic and therefore not really suited to it. They'll give it a go, and many will even say they're happy with it so as not to cause offence, but at the end of the day it doesn't engage their passions - unless of course they're the ones imposing it...
> So no, in the general case and in Go's case specifically, I don't
> agree that "allowing a bit more freedom" is always the correct thing
> to do. "Programmers' varying preferences" are not sacrosanct,
> especially w.r.t. such ultimately inconsequential things as brace
> style.
Why drive people away from a language just because their aesthetics differ from yours?
Cory Mainwaring
"No, that would be a silly rule to enforce" the representative replied
"Well, you smell like elderberries!" he responded as he stormed off
Insert any non-consequential syntax requirement and persons will be
leaving based on aesthetics. It doesn't matter, but to accommodate
every syntactic preference, the compiler would have to read the mind
of programmer, then take the problem and solve it, compile the program
it wrote to solve it, and output it into machine code. At which point,
some programmer somewhere will be pissed that the machine code wasn't
formatted right and you'd still drive people away because of
aesthetics.
If something that's not important is driving people away (especially
when they can write their code however they like and throw it through
gofmt before compilation so they can write it however they prefer),
then I'm not sure they'll be happy with any language...
On 23 September 2010 12:33, Eleanor McHugh
Peter Bourgon
Humans are adaptable: suited to anything (within reasonably boundaries).
> Why drive people away from a language just because their aesthetics differ from yours?
If you're capable of being "driven away" from a language because of
inconsequential and potentially net-positive things like the
enforcement of a particular coding style, the problem is manifestly
your own :)
Cheers,
Peter.
Eleanor McHugh
> Lookahead also has a cost in an interactive interpreter:
> having to look at the next token requires the person
> using the interpreter to type a next token. Typically
> interpreters solve this problem by requiring an explicit
> end-of-statement like a ; or by changing the input
> language they accept. For example, Python will run
> this program if read from a file:
>
> if True:
> pass
>
> else:
> pass
>
> but if you paste it into the interpreter, it will treat the blank
> line as finishing the if statement, and then the else is
> a syntax error.
However this isn't a fair comparison given that Python follows the lead of Intercal in believing that white space should be significant. That's very much a minority position in language design.
Go for example shouldn't demonstrate the same defect thanks to curly braces, any more than in C, Ruby, Basic, Lisp, or any other language which supports block delimiters.
And you are of course talking about a very specific form of interpreter: an interactive command-line. This is conceptually two separate programs...
> Not having the lookahead in the language means that
> an interpreter can accept exactly the same language
> that the compiler does, without any workarounds.
...and the defect lies not in the interpreter itself but in the front-end application which is driving it. In the far-off days of home micros we used to solve this by using a "run" command to invoke execution. This had the advantage of allowing the front-end application to also provide simple editing facilities, something you still find in many Forth and Lisp implementations. As to whether those additional commands are a deviation from the underlying language depends on whether you believe languages should have a distinct meta-model for manipulating their compilation or instead consider such an external facility.
Eleanor McHugh
>> The thing about uniformity is that humans are all a bit idiosyncratic and therefore not really suited to it.
>
> Humans are adaptable: suited to anything (within reasonably boundaries).
The adaptability of individual humans is often overstated, as too is the reasonableness of particular boundaries...
>> Why drive people away from a language just because their aesthetics differ from yours?
>
> If you're capable of being "driven away" from a language because of
> inconsequential and potentially net-positive things like the
> enforcement of a particular coding style, the problem is manifestly
> your own :)
But a potential net-positive doesn't counterbalance an actual net-negative, so unless you have a stronger value proposition to put on the table your aesthetic bigotry would cost the community a potentially consequential number of developers who by bringing different and fresh perspectives could well have been useful to Go's longterm evolution.
Jay Sistar
I believe that you missed Russ' point. Not all of us are as well traveled as him, true, but those of us whom have worked for many companies and may universities know that each 1 has a seperate style, and a guide to follow with repremands if you don't. The gofmt was is no different in that reguard, but it makes it easier by preventing plurality of styles for which guides must be written. The more style that exist, the more we have to waste time learning them. It doesn't matter what style gofmt choses as long as it is consistant, then noone needs to waste time reading or writing style guides.
Cory Mainwaring
it through gofmt whenever you need to get back to the standard one (so
it's quite a bit more useful than all those style guides).
Eleanor McHugh
> I believe that you missed Russ' point. Not all of us are as well traveled as him, true, but those of us whom have worked for many companies and may universities know that each 1 has a seperate style, and a guide to follow with repremands if you don't. The gofmt was is no different in that reguard, but it makes it easier by preventing plurality of styles for which guides must be written. The more style that exist, the more we have to waste time learning them. It doesn't matter what style gofmt choses as long as it is consistant, then noone needs to waste time reading or writing style guides.
I'm well aware of Russ's point, and having also travelled extensively I can see the merit in a tool like gofmt for producing publication-quality code. However this is just one group's opinion of what constitutes a good, clean, aesthetically pleasing style and I see no reason why if there were say a million Go coders worldwide the majority of them would necessarily agree with those judgements. Nor indeed would they have to as gofmt provides an excellent base from which to develop their own pretty printers.
However the core argument here has nothing to do with gofmt and everything to do with one particular consequence of the language spec, and as it speaks very cleanly on this subject I'll quote it:
"White space, formed from spaces (U+0020), horizontal tabs (U+0009), carriage returns (U+000D), and newlines (U+000A), is ignored except as it separates tokens that would otherwise combine into a single token. Also, a newline may trigger the insertion of a semicolon."
For Alexey's case it's that last line that's the sticking point as a } will automatically cause a ; to be inserted if one is absent and it's at the end of a line. There's a certain anachronistic perversity about the semi-colon rules which this highlights quite nicely...
Clark Gaebel
learning it) is that it enforces seemingly trivial rules like this.
Although it's nice to use whatever style you're used to on personal
projects, when working with a team you (almost, although I've never
experienced the contrary) always have to read their style guide; going
over things such as naming style, brace placement, spaces vs tabs, and
various other trivialities.
A complete style guide for C++ can easily be tens of pages long. Two
that I've (re-)read recently are:
Google's: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
LLVM's: http://llvm.org/docs/CodingStandards.html
Seriously. Look at how long those are. Those guides took way too many
hours to write and have wasted countless programmers' time reading them.
Imagine a world where such lengthy documents for EVERY project weren't
necessary?
Oh wait, that's the world Go is striving for.
Regards,
-- Clark
Russ Cox
> I can see the merit in a tool like gofmt for producing publication-quality
> code. However this is just one group's opinion of what constitutes a
> good, clean, aesthetically pleasing style and I see no reason why if
> there were say a million Go coders worldwide the majority of them
> would necessarily agree with those judgements. Nor indeed would
> they have to as gofmt provides an excellent base from which to
> develop their own pretty printers.
Sorry, but you are missing the point.
The point is not to make code "publication-quality".
The point is, as a group, to suspend our personal judgments
about what is "aesthetically pleasing" in order to reap
the benefits that arise from not having those superficial
differences available to discuss. The main benefit is
that then we might focus on the actual content of a
particular piece of code.
Russ
Alexey Gokhberg
On 23 Sep., 20:43, Cory Mainwaring <olre...@gmail.com> wrote:
> Also, with gofmt, you can keep your own personal style guide and throw
> it through gofmt whenever you need to get back to the standard one (so
> it's quite a bit more useful than all those style guides).
>
The own personal style guide can be kept only if the code so styled is
valid according to the language grammar. Unfortunately, this is not
true for my preferred style. Nor it is true for less antiquated styles
like
if x >= 0 {
sign = 1
}
sign = -1
}
if x >= 0
abs = x
sign = 1
}
else
sign = -1
}
enter "c++ coding style guide" in Google and see what comes out).
But both code fragments are not valid in Go.
P.S. A friend of mine - a very efficient Java coder - formats his code
like this:
if (x > 0) {
sign = 1; }
abs = -x;
sign = -1; }
He claims that this style improves his productivity. I believe him.
Steven
Alexey Gokhberg
On 23 Sep., 22:18, Eleanor McHugh <elea...@games-with-brains.com>
wrote:
> There's a certain anachronistic perversity about the semi-colon rules which this highlights quite nicely...
>
semicolons are introduced for the sake of coding without semicolons at
all.
:)
ptolomy23
jimmy frasche
> boon, not a bane, they feature a fundamental hole: they are talking about
> word choice and word order, where here we're talking about punctuation.
We're not even talking about punctuation. We're talking about how to
draw the punctuation marks. You should draw your comma thicker. Give
it more of an arc--it looks too sharp.
Eleanor McHugh
> One of the nice things about Go (and one of the reason I started
> learning it) is that it enforces seemingly trivial rules like this.
>
> Although it's nice to use whatever style you're used to on personal
> projects, when working with a team you (almost, although I've never
> experienced the contrary) always have to read their style guide; going
> over things such as naming style, brace placement, spaces vs tabs, and
> various other trivialities.
>
> A complete style guide for C++ can easily be tens of pages long. Two
> that I've (re-)read recently are:
>
> Google's: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
> LLVM's: http://llvm.org/docs/CodingStandards.html
>
> Seriously. Look at how long those are. Those guides took way too many
> hours to write and have wasted countless programmers' time reading them.
> Imagine a world where such lengthy documents for EVERY project weren't
> necessary?
>
> Oh wait, that's the world Go is striving for.
Yet the very reason such documents exist is because one size can only fit all in a fairly bounded space. If you believe that Go is likely to change that then you're in for bitter disappointment if and when the language gains widespread adoption.
I'm well aware that on this issue - as on most others - I'm out of step with popular sentiment in the current Go community. And you know what? I really don't care. I write code to suit my particular prejudices for the projects I'm committed to. When I open source that code I hope that others will find it as useful as I do, but I couldn't care less whether it conforms to 'good' style any more than I expect T. S. Elliot to write in the same vocabulary and with the same syntactic constraints as Shakespeare or Milton.
After all, we all have gofmt in our tool-chain ergo the responsibility for butchering my aesthetic choices lies firmly in the hands of the recipient.
Jessta
<ele...@games-with-brains.com> wrote:
> After all, we all have gofmt in our tool-chain ergo the responsibility for butchering my aesthetic choices lies firmly in the hands of the recipient.
Auto formaters have existed for years and years. But they have been
useless for most of that time.
Gofmt isn't for re-formatting code, it's for formatting code so you
don't have to worry about it.
Re-formating code leads to horrible commits to source control systems.
Having a language wide formatting tool means that you can auto-format
your code and not have to worry about it messing up your source
control.
By going against this you are intentionally putting additional work on
to other people just for your aesthetic preferences.
The different coding style guides between different projects are not
for a need, but the result of ongoing arguments between people on
those projects, each advocating the style they are used to.
- jessta
--
=====================
http://jessta.id.au
Eleanor McHugh
Actually this is precisely about making the code "publication" quality in the very precise sense that an editor might use such a term. After all, the machine couldn't care less about any of these issues so long as it receives a valid sequence of instructions it can execute, and likewise end users only care that the resultant executable performs its tasks correctly.
As to being part of a group that suspends personal judgements regarding aesthetics, unfortunately I have to demure. I'm right-brain dominant and aesthetics are my tool of choice. But look on the plus side, I'm just a Go user and not a core developer so what I do is pretty insignificant in the broader scheme of things.
Eleanor McHugh
Indeed :)
I find it endlessly perplexing that my 4MHz home micro could provide a reasonable experience in interpreted Basic - a language which lacks semicolons - without ever getting confused over line termination, and yet my 1.6GHz netbook will supposedly be put at serious risk of processor overload by not having semicolons in Go's grammar. I guess that 400x increase in clock speed and corresponding four-fold increase in bus width hasn't really bought me much at all...
Eleanor McHugh
> On Fri, Sep 24, 2010 at 9:14 AM, Eleanor McHugh
> <ele...@games-with-brains.com> wrote:
>> After all, we all have gofmt in our tool-chain ergo the responsibility for butchering my aesthetic choices lies firmly in the hands of the recipient.
>
> Auto formaters have existed for years and years. But they have been
> useless for most of that time.
> Gofmt isn't for re-formatting code, it's for formatting code so you
> don't have to worry about it.
>
> Re-formating code leads to horrible commits to source control systems.
>
> Having a language wide formatting tool means that you can auto-format
> your code and not have to worry about it messing up your source
> control.
Clearly our use cases differ.
> By going against this you are intentionally putting additional work on
> to other people just for your aesthetic preferences.
So? If I give something to you for free, it's not my business whether you have to put some work in to get the full benefit out of it. Likewise it doesn't bother me if I have to rewrite chunks of code I pick up off the internet to gain full insight into how they work as I take it for granted that's necessary anyway.
> The different coding style guides between different projects are not
> for a need, but the result of ongoing arguments between people on
> those projects, each advocating the style they are used to.
And those arguments exist for a very good reason: aesthetics matter to people. You can't make that go away by legislating against it any more than you can make everyone like hot pink.
Ian Lance Taylor
> I find it endlessly perplexing that my 4MHz home micro could provide a
> reasonable experience in interpreted Basic - a language which lacks
> semicolons - without ever getting confused over line termination, and
> yet my 1.6GHz netbook will supposedly be put at serious risk of
> processor overload by not having semicolons in Go's grammar. I guess
> that 400x increase in clock speed and corresponding four-fold increase
> in bus width hasn't really bought me much at all...
The semicolon rule is not about parsing efficiency. It's about knowing
when a statement ends without requiring lookahead which sees tokens
which are not part of the statement. Russ already elucidated why that
is a good thing. In most C-style languages, semicolons provide the
marker you need to avoid the lookahead. Go permits omitting those
semicolons, but you get the semicolon rule as a consequence. The rule
is easy to mock but not so easy to change without losing something else.
As with all language decisions, it's a matter of balancing different
options.
Ian
Eleanor McHugh
As I seem to be playing devil's advocate on this: I see assertions in the language design FAQ that this is a good thing and that the advantages vastly outweigh the negatives, but I'm damned if I can find a clear listing of those advantages in the document. Whilst such an inclusion is unlikely to end debate of these matters, it would at least allow us all to do so from a more informed perspective without having to scan the mailing-list archives or cobble together views from a variety of other sources.
Cory Mainwaring
all the semi-colons:
Less Typing (you don't have to write those semicolons before you hit enter)
Less Clutter (you don't have to look at all those semicolons, instead
wrapping the end of lines with graceful whitespace)
Benefits of having non-look-ahead semi-colon rule instead of having a
look-ahead one:
Reduced Compile Time (you don't have to look ahead to the next
significant token to determine whether to put a semi-colon right here)
Less Typing (you aren't allowed to add in extraneous carriage returns)
Resulting Downside:
Less Flexibility (you can't add in extraneous carriage returns)
Well, you get 2-4 ups vs. 1 down, that's 2:1 or 4:1 in favor of the
rule. Indeed, time is saved by not having to type semi-colons,
precious short term memory is not wasted on semi-colons and in
general, it looks better to read code that doesn't have semi-colons.
As for the 4Mhz vs 1.6Ghz, the issue is that in Basic, there is a
statement that terminates an if/else block, one which Go doesn't have
(instead it has a generic punctuation with a semi-colon rule) which
increased it's comprehension complexity, but reduced it's parsing
complexity and increased the speed at which one could write it. The
4Mhz vs. 1.6Ghz is also just extraneous information meant to distract.
:P
On 23 September 2010 20:54, Eleanor McHugh
⚛
wrote:
>
> > On 23 Sep., 22:18, Eleanor McHugh <elea...@games-with-brains.com>
> > wrote:
>
> >> There's a certain anachronistic perversity about the semi-colon rules which this highlights quite nicely...
>
> > And there is some irony in the fact that the rules for inserting
> > semicolons are introduced for the sake of coding without semicolons at
> > all.
>
> Indeed :)
>
> I find it endlessly perplexing that my 4MHz home micro could provide a reasonable experience in interpreted Basic - a language which lacks semicolons - without ever getting confused over line termination, and yet my 1.6GHz netbook will supposedly be put at serious risk of processor overload by not having semicolons in Go's grammar. I guess that 400x increase in clock speed and corresponding four-fold increase in bus width hasn't really bought me much at all...
I guess, the problem is that today's compilers are much less efficient
(as in: 100x less efficient) than what was available on 8-bit
computers. On some 8-bit computers the program is stored in a much
more efficient format than Go source code. Concrete examples are:
Atari BASIC [http://en.wikipedia.org/wiki/Atari_BASIC#The_tokenizer],
and ZX Spectrum Basic [http://en.wikipedia.org/wiki/Sinclair_BASIC].
After the programmer pressed Enter, the line of the BASIC program was
checked and converted into a more efficient form. It is also
interesting that both the BASIC parser and interpreter fit into less
than 8K/16K bytes of memory.
In case you wanted your BASIC programs to run much faster by avoiding
the interpretation overhead, you could compile the BASIC program into
machine code. The most interesting thing is that the compiler consumes
just a few KB of memory. For instance, on ZX Spectrum, MCoder2 is 6KB,
HiSoft Basic is 11KB. Of course they aren't capable of doing any
advanced optimizations, but neither is the Go compiler. I am not
suggesting that BASICs on the old machines are as advanced as Go, I am
just trying to note that this kind of comparison brings some very
interesting thoughts about compiler efficiency into the mind.
It is a somewhat controversial statement to speak of Go as having a
fast compiler, while quite a lot of efficiency (both in terms of space
and time) is lost because of the form in which Go source codes are
being stored.
bflm
> It is a somewhat controversial statement to speak of Go as having a
> fast compiler, while quite a lot of efficiency (both in terms of space
> and time) is lost because of the form in which Go source codes are
> being stored.
code* should be saved to a file in some *non-textual* form? Hope I
just misunderstood something.
chris dollin
No, ⚛ is alluding to the time needed to turn source code into something
that code can be generated from and, I believe, how an IDE could be
faster by keeping a pre-parsed version of Go code fragments around.
(As far as I can tell, Go's having a fast compiler is "controversial" only
because ⚛ controverts it and doesn't compare like-for-like.)
Chris
--
Chris "allusive" Dollin
⚛
bflm
> > That form is called UTF-8. Is this really a suggestion that Go *source
> > code* should be saved to a file in some *non-textual* form?
>
> Why not?
representation is automaton based what concerns the parsing per se and
this is a) very, very fast, b) is, I believe, the minor (in time
domain) part of the compilation task.
So using the preparsed and/or pretokenized form will save, I guess,
few percents of the compilation time. The cost is - no more ability to
view/edit the Go sources in a plain text editor, no grep, no text
processing tool at all. Kind of disaster for me.
I think this is a very bad idea.
(Actually I haven't yet written/generated a single Go source file
which doesn't compile in a sub second time span on an ordinary 2.5 GHz
Linux PC.)
⚛
On Sep 24, 12:55 pm, bflm <befelemepesev...@gmail.com> wrote:
> On Sep 24, 12:36 pm, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
> > > That form is called UTF-8. Is this really a suggestion that Go *source
> > > code* should be saved to a file in some *non-textual* form?
>
> > Why not?
>
> Turning the textual source code into a compiler intermediate
> representation is automaton based what concerns the parsing per se and
> this is a) very, very fast, b) is, I believe, the minor (in time
> domain) part of the compilation task.
from "lex.c" while compiling some files:
- total compilation time: 604 ms
- time spent in "yyparse()": 112 ms
112/604 = 18.5%
I agree, it is minor. The parsing as such is only a part of those
18.5%. I don't know how to measure the time 8g spends solely in
parsing the UTF-8 text. Lets suppose that it might be around 10% of
the 604 ms.
> So using the preparsed and/or pretokenized form will save, I guess,
> few percents of the compilation time. The cost is - no more ability to
> view/edit the Go sources in a plain text editor, no grep, no text
> processing tool at all. Kind of disaster for me.
There are multiple solutions to this issue. The one I like the most is
to modify the OS (Linux) to add support for typed files. Under the
assumption that the OS supports typed files and transparent conversion
between types, the Go source code is saved (in pretokenized form) into
a file of type "preprocessed Go source code". When a "legacy program"
which has no idea about an OS with file types, such as a plain text
editor, opens this file, the file contents will be transparently
converted into plain text. If the "legacy program" opens the file for
writing, the file is automatically turned into a plain text file (the
file type is "plain Go source code" now). After this, when the Go
compiler opens this file, it examines its type, and if it has type
"plain Go source code" it will convert it into type "preprocessed Go
source code". When the compiler encounters the file again sometime in
the future (which I think is probable), the file type will be
"preprocessed Go source code" and thus the compiler will be able to
run slightly faster because the file is already preprocessed.
Conversion into plain text takes place only if the file is *modified*
by a "legacy program" (vim, Kate, etc). If the file is opened for
reading only (hg, git, cat, diff, ...), the OS might decide not the
scrap the "preprocessed Go source code" version, because the file
hasn't been modified.
> I think this is a very bad idea.
that you get "the best of both worlds".
> (Actually I haven't yet written/generated a single Go source file
> which doesn't compile in a sub second time span on an ordinary 2.5 GHz
> Linux PC.)
not talking about that. I am talking about striving for efficiency as
such. If you aren't willing to accept the goal of making things more
efficient whatever the current efficiency is, then you can treat the
matter I am talking about as a thought experiment.
Mue
I'm a wanderer through different languages for now more than 26y.
Basic, Pascal for a long time, a bit C/C++ and Scheme, ReXX, many
years of Java and Python, a short C# interlude, Smalltalk since now
about 6 years, and during the last few years now Erlang and Go. And
yes, allways the same - mostly useless - discussions about the coding
conventions and the style.
It's funny that I don't remeber such a discussion for any real
language feature.
Please, if a language has its own style, take it or leave it.I'm
totally with Russ. Writing code that works is by far more importand to
me than code which looks like especially I'm wanting it to do. And for
the code I'm publishing as OSS it's importand to be understandable for
many people. So I really gofmt. One keypress and my code looks like
the code of hundreds of other Go developers and for all of them it's
simple to read my code (as long as I use good identifiers and comments
*smile*).
Just my 2c.
mue
PS: The more than 200 code snippets in my Go book are all set the
gofmt style. *g*
chris dollin
One keypress and my code looks like
> the code of hundreds of other Go developers and for all of them it's
> simple to read my code
NO. That is exactly the point that some of us are making. What is
simplicity to you is sandpaper to eg me. I can put up with it -- it's
a lot less to put up with than you get in many other languages --
but it's there as a perpeptual low-grade irritation.
Alexey Gokhberg
On 23 Sep., 23:48, ptolomy23 <ptolom...@gmail.com> wrote:
> On Thu, Sep 23, 2010 at 2:26 PM, Alexey Gokhberg <
> It might make him more productive because that's what he's used to or
> because his tools help him type it, but there are more
> benefits in consistency and having tools that do your formatting for you
> than there are in the readability of any particular style (assuming
> the standard style isn't something wacky).
development and maintenance of a couple of large critical
applications, and productivity really matters there. If, as he claims,
his style helps him to improve his performance (and again, I think his
claim is absolutely right), this provides a very material and
important benefit for him and his company.
Those "more benefits" discussed here simply do not exist in his
business context. If he followed the official Java Style Guide, this
would not bring him any real gain. In particular, making his code
easily readable for the worldwide community is irrelevant, as this
code will be never shared with this community.
What is benefit and what is not depends on the context. More freedom
granted by language design just means that the language can provide
real benefits in a wider range of contexts.
Alexey Gokhberg
On 24 Sep., 14:12, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> Well, you are right about the sub second compilation times. But I am
> not talking about that. I am talking about striving for efficiency as
> such. If you aren't willing to accept the goal of making things more
> efficient whatever the current efficiency is, then you can treat the
> matter I am talking about as a thought experiment.
for it. When you have to pay a certain cost to get the negligible gain
in compilation speed, can this be called efficiency?
Russ Cox
worth the increased speed in compile time from not having
to deal with lookahead. This is like dividing by 0.
There is NO SPEED BENEFIT to the current semicolon rules.
The rationale behind them has nothing to do with compile
time efficiency. For details, see my earlier mail on this thread.
Russ
Ian Lance Taylor
> No, it is certainly not silly. My colleague is responsible for
> development and maintenance of a couple of large critical
> applications, and productivity really matters there. If, as he claims,
> his style helps him to improve his performance (and again, I think his
> claim is absolutely right), this provides a very material and
> important benefit for him and his company.
I'm sorry, but I don't buy it. Like many others here, I have been
forced to write code in a variety of different styles; heck, I've even
written style guides. It is always slower at first to use a different
style, but after a while it does not matter. It becomes second nature,
and seeing code written in a different style becomes jarring. In fact,
I have to write code in multiple different styles today as I work on
different programs: the Google style used for internal Google code is
different from the GNU style used for gccgo and both are different from
the Plan 9 style used for the C code in the Go library. And I recently
did a lot of work on SWIG which uses yet another style. Switching
styles all the time is a pain, but it is entirely doable. Each style
has advantages and disadvantages, there is no perfect approach.
So while I'm sure your colleague believes that he is telling the truth,
I am equally sure that he is mistaken. He could adapt if he had to, and
in a short period of time he would be equally productive in whatever
style he had to use.
The Go approach is to simply say that all this switching between styles
is pointless and counter-productive. When working in Go there is only
one style. It's not perfect, but there is no perfect style. Everybody
is capable of adapting.
Note that this argument about style is entirely separate from the
argument about the semicolon rule. The semicolon rule has two goals: no
lookahead is required to determine the end of a statement, and
semicolons are generally not required. If somebody has a better
approach to this issue which addresses both goals, I'm sure we would all
be interested in hearing it.
The semicolon rule and the style discussion intersect because the
semicolon rule only works because of the single preferred style. The
notion that there is a single correct style for Go is a specific
language design choice, and I can't see the Go team changing their minds
about that. The semicolon rule is a syntactic detail aimed at specific
goals, and it could be changed if there were a better idea. After all,
it was already changed once since the public release.
Ian
Mue
> > the code of hundreds of other Go developers and for all of them it's
> > simple to read my code
>
> NO. That is exactly the point that some of us are making. What is
> simplicity to you is sandpaper to eg me. I can put up with it -- it's
> a lot less to put up with than you get in many other languages --
> but it's there as a perpeptual low-grade irritation.
situation? Or what's your solution to provide code formatted for a
large number of readers?
mue
⚛
- The cost is that a developer will have to spend a month (or several
months) on improving compilation speed by a negligible amount, say by
5%. The cost on the side of the compiler user is zero (the change is
transparent to the user). The benefit or value the user gets is:
compilation time is improved by 5%. However, there are thousands of Go
compiler users around the world.
- As stated previously, I measured that the Go compiler spends some
18.5% of time in function "yyparse". That means that 81.5% of time is
spent in symbol table lookup, type checking, code generation,
evaluation of constant expressions, etc. Provided you are allowed to
save the source code in a "preprocessed" form, you might try to off-
load some of the symbol table lookups, locally decidable type checks,
constant evals, etc. So it may potentially be possible to achieve more
than just negligible gains (in case the preprocessed file is input to
the compiler more than once, and in case of incremental updates to the
source code).
Of course, unless somebody actually implements this - which I doubt
will happen - we are not going to know by how much faster the compiler
can be.
Cory Mainwaring
split it up. It would probably take longer to compile when going from
UTF-8 -> compiled program because of the extra program doing a UTF-8
-> pre-process.
Also, if the advertisement is that compilation is super-fast, it's
cheating to offload 18.5% of compilation to a different program to
"increase efficiency". Efficiency in compiling (as done by compilers
today) would be to make better code and make that code faster, going
from a textual format to a machine-readable format.
⚛
> The point is moot, not because it wouldn't decrease compile time, just
> split it up. It would probably take longer to compile when going from
> UTF-8 -> compiled program because of the extra program doing a UTF-8
> -> pre-process.
- the compiler has no support for incremental (sub-file) compilation
- there is no recurrence of files passed to the compiler
On the other hand, programmers are doing the following:
- incremental source code changes
- passing the same file to the compiler
> Also, if the advertisement is that compilation is super-fast, it's
> cheating to offload 18.5% of compilation to a different program to
> "increase efficiency".
number 12345, you are going to enter it via keyboard by pressing "1",
"2", "3", "4" and "5". From this follows that something has to (at
least once) parse these 5 digits to decode the numeric value 12345.
The point of the idea I am talking about here is that in *typical*
scenarios a compiler will parse the very same number 12345 more than
once. Some source codes are being passed hundreds and thousands of
times to the compiler.
If you agree with me about what the typical use case is (that the same
source code is compiled many times during its "life span"), then you
cannot treat the offloading as cheating, because in such a case it is
not cheating - it actually increases efficiency.
Of course, if you have a file that you are going to pass to the
compiler exactly once, then the efficiency will be probably lower. But
I don't think this is a major drawback, because this is *not* the
typical use case.
> Efficiency in compiling (as done by compilers
> today) would be to make better code and make that code faster, going
> from a textual format to a machine-readable format.
>
Cory Mainwaring
needs to be fully recompiled, meaning that you have to do the
pre-compilation and then the compilation. If you're intending on doing
some sort of changelog to track changes in the file for the
pre-compiler and thus parsing only a bit of the code at a time, you're
still going to have to include that as part of compilation time when
comparing it to other languages.
A dictionary in the compiler might be useful (especially for files
sent multiple times and for files with lots of repetitive structure),
but you may as well keep it IN the compiler, rather than off-loading
it and making the compilation process that much more complicated (no
major languages use a pre-parser to get the code ready for the
compiler as a separate binary).
Keep it simple. Increase efficiency in the compiler. Don't just cut
the compiler apart to speed things up. Because then we can take each
step, call the shortest one the "compilation" step, and get times on
the order of nanoseconds! It will still take 5 seconds to get from
UTF-8 -> executable binary. Probably more, now that there are 30
binaries needed to run in order to compile.
⚛
> so having pre-compiled files, that's fine, but when a file changes, it
> needs to be fully recompiled, meaning that you have to do the
> pre-compilation and then the compilation. If you're intending on doing
> some sort of changelog to track changes in the file for the
> pre-compiler and thus parsing only a bit of the code at a time, you're
> still going to have to include that as part of compilation time when
> comparing it to other languages.
> A dictionary in the compiler might be useful (especially for files
> sent multiple times and for files with lots of repetitive structure),
> but you may as well keep it IN the compiler, rather than off-loading
> it and making the compilation process that much more complicated (no
> major languages use a pre-parser to get the code ready for the
> compiler as a separate binary).
by me) the compiler might try to uncover the repetitive structure of
files on its own. Although that is indeed possible, your suggestion
has a much higher computational complexity than mine. You are
essentially asking the compiler to perform a *compression* (diff) step
on each input file against its previous version. In contrast to this,
what I am suggesting has lower computational complexity: I am
suggesting that the incremental changes should be detected while the
file is being edited (with an editor that has support for this,
obviously). Such an editor knows *exactly* what is happening to the
source code (on a certain level), so for example if you delete a line
the editor knows which particular line has been deleted. In your case,
where the compiler performs a diff to find the changes, the compiler
would have to search through the whole file just to find which line
was deleted.
> Keep it simple. Increase efficiency in the compiler. Don't just cut
> the compiler apart to speed things up.
compiler, because the information about what has happened was lost
somewhere down the road and to recover that information might be very
computationally intensive. To get better efficiency, you have to
process the bits of information when that information is *available*,
or store it for later use. In certain cases, the needed information is
available outside of the compiler, so it *has* to be dealt with
outside of the compiler. There is no nice workaround here. The "keep
it simple" rule is good, but if the facts aren't simple, "keep it
simple" does not work.
> Because then we can take each
> step, call the shortest one the "compilation" step, and get times on
> the order of nanoseconds! It will still take 5 seconds to get from
> UTF-8 -> executable binary. Probably more, now that there are 30
> binaries needed to run in order to compile.
konrad
a vary large number of them are based on ambiguity in language and or
pronounciation. To sum it up if English was such a clear and way of
coveying instructions we'd all be writing our code in it. The entire
reason why we have programming languages is that natural languages
could not fulfill the task. And indeed form everything I have heard
ther more a lnaguage attempts to behave and look like a nuatural
language the more the moajority of programmers avoid it. Cobol anyone?
Every single project of any size has coding conventions, which really
are as good as each other. In my opinion picking one set for the
entirer language just makes things easier in the long run. But then
again I spend most of my time programming in Python so maybe I'm just
used to operating in an environment where code layout is largely fixed
and dictated by the compiler.
On Sep 24, 2:17 am, Eleanor McHugh <elea...@games-with-brains.com>
wrote:
> On 23 Sep 2010, at 14:19, Jay Sistar wrote:
>
> > Your argument looks to me (and I'm sure to other Go progrmmers) like an argument that multiple spellings or word orderings for the English language should be allowed. That allowance would cause mass confusion, and it would benefit nobody.
>
> It's a nice theory however your basic premise simply isn't true. British English (both colloquial and as codified in our much-ignored grammar textbooks) does allow both multiple spellings and extensive variation of word ordering without any particular loss of clarity. Indeed the ambiguity arising from these subtleties is often considered a positive benefit by many of its more advanced users and as a result is embraced in numerous literary works.
>
> Indeed the common usage of English is probably best summed up by a quote from Alice in Wonderland:
>
> "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less."
> "The question is, " said Alice, "whether you can make words mean so many different things."
> "The question is," said Humpty Dumpty. "which is to be master—that's all."
>
> As programmers it's the very nature of our avocation that we are the masters of words and not their servants, otherwise we wouldn't have the temerity to coin new usages on a daily basis. And if meaning is to be malleable to our needs then why should syntax be any less our tool?
>
> Ellie
>
> Eleanor McHugh
> Games With Brainshttp://feyeleanor.tel
Cory Mainwaring
save-time measure, in which you essentially did the diff and
pre-compile then, keeping it plain text before. Not opening a
semi-compiled program in an editor that would interpret the language
the entire time. I'm still thinking that'd be a rather heavy resource,
and it would be much simpler to keep the 18.5% in the compiler and
make the parser better.
If it can't speed up compilation at compile time, then it likely won't
increase the overall efficiency of the UTF-8 -> binary process, just
muddling things up. Perhaps an IDE that keeps a pre-processed form of
the opened files, but keeping the file itself in UTF-8 format?
chris dollin
Reformatters -- more flexible programs on the lines og gofmt.
The complication of that, of course, is pair programming; one step
at a time.
--
Chris "allusive" Dollin
Mue
> > situation? Or what's your solution to provide code formatted for a
> > large number of readers?
>
> Reformatters -- more flexible programs on the lines og gofmt.
>
> The complication of that, of course, is pair programming; one step
> at a time.
usage of platforms like Google Code or Git, where it's pretty simple
to search for code and look into it. Downloating and reformatting each
piece of code is additional and unneeded effort.
For me it's the difference between coding for one person (just me) or
many people (the community or just an internal team). Having only one
standard and a good tool assuring this is a great help for working in
communities.
mue
chris dollin
> Reformatters need to reformat the code every time. But how about the
> usage of platforms like Google Code or Git, where it's pretty simple
> to search for code and look into it. Downloating and reformatting each
> piece of code is additional and unneeded effort.
It's only "unneeded" if you're already committed to One Way.
(And I think that this price need be paid only by those who follow
Other Ways.)
> For me it's the difference between coding for one person (just me) or
> many people (the community or just an internal team). Having only one
> standard and a good tool assuring this is a great help for working in
> communities.
Should facilitation for communities force penalties on those working
on projects outside that community?
Mue
> It's only "unneeded" if you're already committed to One Way.
> (And I think that this price need be paid only by those who follow
> Other Ways.)
itself. "Hmm, I would like German keywords more, why can't I use
them?" For me there are language that fit to me (syntax, style,
community, environments, libraries), but other ones I dislike. The
first ones I'm using, the second ones not. Pretty simple.
Discussions like "this would look better so", "that should be named
so", or especially "language X has that feature, why can't we have it"
are so meta and only seldom lead to something. Building a programming
language is a hard job. Not only technologically but also due to the
discussions of what should be changed. Take a look at this discussion
here.
Coming back to Go: Sure, there are things I'm missing from Erlang or
Smalltalk. OTOH the Go developers have been able to create a clean
language, not bloated, powerful, with a neat type system and equipped
for the challenges of distributed multi-core environments. The
libraries are growing with each release, tools and documentation are
very good. That's a great result for a language introduced less than a
year ago.
> Should facilitation for communities force penalties on those working
> on projects outside that community?
drill, dowels, and screws for free. But you expected a hammer and a
nail. So the gratis drill is a penalty? Or should at least have the
ability to also hammer nails in? *smile*
Yes, language and environment force you to move inside their
boundaries. You could take this as a penalty. But as long as you
choose this environment and you're always free to leave it's only a
very small one.
mue
bflm
> Should facilitation for communities force penalties on those working
> on projects outside that community?
penalized for that. If *anyone* is willing to use Go outside the
community, [s]he is welcome for sure and even gets a exceptionally big
amount of help from the community here. But why the community should
twist itself to serve the ones deliberately being outside of it?
I hope for not having to read some wild political analogies on this
personal/subjective thought, which is all it is.
Eleanor McHugh
> Um. have yu ever heard of somthing called a joke?
> a vary large number of them are based on ambiguity in language and or
> pronounciation.
There is nothing intrinsic to programming languages which makes it impossible to tell jokes based on ambiguity, mispronunciation, absurdity - or for those working in the embedded sphere - lavatorial misfunction. Are these funny to the computer? No. But they can certainly be a source of amusement to the humans reading them or experiencing their consequences.
> To sum it up if English was such a clear and way of
> coveying instructions we'd all be writing our code in it.
And if it were such a bad way of describing the real world we'd not have made it this far up the pyramid of needs. Indeed the one thing that's been constant between all of the project specs I've encountered in the last two decades is that they were written in a human natural language.
> The entire reason why we have programming languages is that natural languages
> could not fulfill the task.
No, we have programming languages because humans are very bad at expressing their thoughts in machine code and most of them are equally as lost in assembly language - even those with a solid foundation in mathematical reasoning and formal logic. We therefore use naturalistic languages to try and close the conceptual gap between the models of reality we usually manipulate in our minds and the environment in which we wish to automate that manipulation.
> And indeed form everything I have heard
> ther more a lnaguage attempts to behave and look like a nuatural
> language the more the moajority of programmers avoid it. Cobol anyone?
Too often we ascribe to languages defects which are actually implicit in their community of users. Cobol and Java are both reasonable languages given the knowledge of their original creators, but how they evolved is very much down to the rigid, hierarchical, often bureaucratically non-sensensical biases of the organisations which embraced them.
> Every single project of any size has coding conventions, which really
> are as good as each other.
I've worked on a number of million-line projects during my career and the ones which tended to be successful - i.e. turn in a client-pleasing product on time and within budget - were all noticeably lacking in coding standards. What they did have in common though were small teams of coders with good interpersonal relationships who took a pride in their work, didn't attribute blame when things went wrong, and were keen to maintain similarly affectionate relationships with their clients. There's also tended to be a shared fondness for beer which may or may not have been a contributory factor.
> In my opinion picking one set for the
> entirer language just makes things easier in the long run. But then
> again I spend most of my time programming in Python so maybe I'm just
> used to operating in an environment where code layout is largely fixed
> and dictated by the compiler.
You probably are. Personally I find Python too rigid for my tastes, even though it's in other ways a beautiful language. The anarchic world of Ruby on the other hand feels very comfortable to me in a way that might well horrify you.
From what I can tell the single biggest conceptual divide between the Python and Ruby communities is that Python programmers respect the rule that there should generally be only one way to do each particular thing whilst Ruby programmers don't: we love variety and subtlety of inflection. That shows through in the very different attitudes of the two communities to ad hoc meta-programming and monkey patching, techniques which are fairly recent innovations in Python but which have been established in Ruby for a good decade or more.
Rails for example could not have been born in Python, just as I doubt Django could have been born in Ruby. Different mindsets, different tools, different results.
I understand why Python's economy of method may be seen as a good thing from a certain perspective, but to be honest I much prefer an ecosystem which leverages the power of natural selection. The Ruby approach does that admirably, even if along the way there may be many failures.
Failure's something you can fix, and usually it teaches you a whole bunch of new stuff you'd never have learnt otherwise. I consider that a win.
Alexey Gokhberg
On 25 Sep., 13:36, bflm <befelemepesev...@gmail.com> wrote:
> Go *is* a community project. *No one* is forced to use it nor is
> penalized for that. If *anyone* is willing to use Go outside the
> community, [s]he is welcome for sure and even gets a exceptionally big
> amount of help from the community here. But why the community should
> twist itself to serve the ones deliberately being outside of it?
>
of individuals and companies deliberately using the language outside
its initial community. We also should expect that these outsiders will
not just act as consumers of the community's effort, they most likely
will contribute significantly to the further development of the
language. Community, therefore, should be ready for the constructive
dialogue with the rest of the world. And I really mean dialogue here -
nobody requires community to twist itself to serve anyone's needs.
Alexey Gokhberg
experience is different, their goals and priorities are different too.
What is right for my colleague may appear unsuitable for you, and vice
versa.
> So while I'm sure your colleague believes that he is telling the truth,
> I am equally sure that he is mistaken. He could adapt if he had to, and
> in a short period of time he would be equally productive in whatever
> style he had to use.
don't know. Your personal experience, valuable as it is, cannot be
directly projected to other persons: software developers are all
different. But anyway, the question is: why should he adapt? As I
mentioned, neither him, nor his company would gain any slightest
benefit for the effort spent for adapting to some "standard" style.
>
> When working in Go there is only one style.
Indeed there exists a multitude of styles when working in Go. For
instance, I can (and actually do) use style like this:
// sum -- calculate sum of elements in the slice
func sum(v []int) int {
s := 0
for i := 0; i < len(v); i++ {
s += v[i];
}
return s
}
This is a valid fragment of Go code and the language specification
does not prevent me from using this style. I also don't need gofmt,
don't use use it and have no plans to use it in the future.
Furtunately, gofmt is just an additional tool and not a mandatory
element of Go language. (I actually cannot understand why some
reviewers claim that all Go source code must be passed through gofmt
before compilation.)
Steven
bflm
> If and when Go will gain in popularity, we should expect a multitude
> of individuals and companies deliberately using the language outside
> its initial community. We also should expect that these outsiders will
> not just act as consumers of the community's effort, they most likely
> will contribute significantly to the further development of the
> language. Community, therefore, should be ready for the constructive
> dialogue with the rest of the world. And I really mean dialogue here -
> nobody requires community to twist itself to serve anyone's needs.
development of the language" as part of the community and as no
outsiders any more. And dialog within the Go community is nothing that
have to be invented as it's going on right now and started from day 1,
isn't it?
Alexey Gokhberg
On 25 Sep., 23:26, Steven <steven...@gmail.com> wrote:
> You can do that in private all you want, but its not polite to subject other
> people to it.
I actually use this style for decades, until now no one of my
colleagues felt offended.
P.S. And, by the way, my point was that the Go language specification
allows for a multitude of styles. Don't you agree with this?
Alexey Gokhberg
On 26 Sep., 00:12, bflm <befelemepesev...@gmail.com> wrote:
> I see the "outsiders contributing significantly to the further
> development of the language" as part of the community and as no
> outsiders any more. And dialog within the Go community is nothing that
> have to be invented as it's going on right now and started from day 1,
> isn't it?
ready to deal with newcomers, some of whom may not share priorities
and goals of the original team. I don't think that in this case the
attitude "either you take it as it is, or you are free to leave"
expressed in the above posts would be really constructive.
Steven
Why do you think it is not polite?
On 25 Sep., 23:26, Steven <steven...@gmail.com> wrote:
> You can do that in private all you want, but its not polite to subject other
> people to it.
I actually use this style for decades, until now no one of my
colleagues felt offended.
P.S. And, by the way, my point was that the Go language specification
allows for a multitude of styles. Don't you agree with this?
konrad
Lets have a look at some large projects then.
The Linux Kernel -> http://lxr.linux.no/#linux+v2.6.35.5/Documentation/CodingStyle
Gnome -> http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html
GNU -> http://www.gnu.org/prep/standards/standards.html
Apache -> http://httpd.apache.org/dev/styleguide.html
Mozilla - > https://developer.mozilla.org/En/Developer_Guide/Coding_Style
All of them seem to have a coding style. Granted they vary in how
strongly they adhere to it. ranging from please use to your patches
will be rejected if you don't.
As to Projects specs, and other business writing. They tend to use a
very ridged from of English which is restricted in many, many ways.
Why, because it is too easy to write ambiguous and messy descriptions
otherwise. Even then many will end up resorting to some kind of formal
grammar or logical notation at some point, again to avoid the
ambiguity of English.
I have nothing against monkey patching per say, and I have even
employed it on occation, when it seemed to be the simplest way to get
things done. Invariable it has come back and bitten me several months
done the track when I'm tring to follow a stack trace and trying to
work out how the heck I ended up in some custom database cursor
definition ...
Clark Gaebel
standard? I haven't come across any, and I'm actually quite curious.
--
Regards,
-- Clark
bflm
> Then, once Go will gain popularity and community will explode, be
> ready to deal with newcomers, some of whom may not share priorities
> and goals of the original team. I don't think that in this case the
> attitude "either you take it as it is, or you are free to leave"
> expressed in the above posts would be really constructive.
it right now. In any case, deciding of what some others will want or
not want in the possible future scenario is IMO better left to them
when the scenario happens.
Eleanor McHugh
Dialogue is about engagement, and accepting that the views of another may differ but that this does not automatically mean they are your enemy. It is a basic premise of dialogue that all views can be offered freely, discussed without ire, and that where disagreement remains all parties accept this in a warm and friendly spirit.
When one or other of us takes the position that all people must subscribe to the same position without variance then no dialogue can be possible on that particular matter.
On a number of occasions during my involvement with the Go community I have voiced concerns about particular approaches which I personally believe are unfairly restricting of the freedom of individual programmers to craft code according to their preferences. I have always tried to do so politely and respectfully, after all Rob Pike and colleagues have put a lot of effort into developing what is in many ways a beautiful language - and one which has drawn me back into static typing after many years of frustration with more traditional approaches. It's their baby and within the confines of the existing implementation and its standard library they have every moral and ethical right to specify it just so.
In private correspondence with Rob I've discussed particular areas of the language that as an experienced user of dynamic languages for systems-level programming I believe could be improved. Sharing such real-world experience is something we all should do. I would have liked to have those conversations more publicly as I know there are others here who do share my views, but just look at this thread. With so many eager to berate a simple enquiry regarding a grammar rule - a rule which on the surface is quite nonsensical (and indeed against the backdrop of existing popular language grammars somewhat unusual) - where exactly is the sense that raising a more complex subject would result in dialogue?
There isn't one.
Perhaps I've become overly sensitive to these sorts of things. I've spent five years exclusively in the Ruby world where the culture is built on the shared principle of MINSWAN: Matz Is Nice So We Are Nice. We pride ourselves on being friendly and encouraging to novice Rubyists, of sharing our knowledge freely, and of accepting that there is always more than one way to achieve any goal. There is something approximating a Ruby coding style, but it's an organic outgrowth of the form the language has adopted and is not mandated by any tool or syntax restriction - indeed in a language where extensive meta-programming in a Lispish mould is the norm, there really is no way to enforce such a concept. That's one of the reasons Ruby is so good for developing DSLs compared to comparable languages.
Instead it is our shared desire to communicate with each other, to engage in a genuine dialogue, and that leads to shared aesthetic principles. Even when developers don't share those same aesthetics we have a fallback strategy, yet again codified in a simple phrase rather than in a style document or syntax restrictions: the Principle of Least Surprise (sometimes expressed as the Principle of Least Surprise to Matz) whereby we value code more highly if it expresses its intent clearly than if it's obfuscated.
Now I know that there's an intrinsic difference between the value systems of static and dynamic type systems, and this is a reflection of differences in experience and perspective between the developers who promote them. I'm a dynamic typing sort of person and always have been, generally ignoring languages which provide no room for such forms of expression.
Many of you here are static type enthusiasts - possibly even hardcore believers.
Well Go isn't a statically typed language. It's a reflected language and it has interface{}, so for all that you think it promotes one true way with no room for anarchic self-expression - semantically you couldn't be more wrong. The areas of doubt and uncertainty may be clearly defined, but they create wormholes of logic big enough to drive any arbitrarily-chosen passenger vehicle through anytime you like.
So is this obsession with one true representation of code really buying anything? If I produce a 1000 line, highly-optimised, monolithic function based on interface{} and reflection is being precise about the use of whitespace really going to make it appreciably easier to decipher?
Personally I think not. And as I wish to engage in a dialogue with the community over this I'm happy to accept that I may be in the minority and that my view may be discounted once a full discussion of the arguments for and against this position has occurred, but what I'm not happy to accept is a diktat "from on high" regarding how I use my tools. Because once they're in our hands that's precisely what they are, our tools to be used according to our knowledge and experience to craft the artefacts which we wish to craft.
Eleanor McHugh
> Just out of curiosity, what large project doesn't have a coding
> standard? I haven't come across any, and I'm actually quite curious.
In fifteen years of commercial coding I've worked on precisely one project that did have a coding standard. My average codebase size has varied from 100 KLOC to 1 MLOC, and many of the projects have been multi-generational with half-a-dozen distinct styles spread across a variety of implementation languages (but with a locus on C, assembler, VB and in recent years Ruby). The variation of styles was beneficial as it gave a good indication of the age of the code and provided interesting insights into both the mindset of its developer and the constraints operating at the time. And I will admit I'm atypical in that I enjoy reading other people's code. To me it's an interesting form of literature.
Until I became involved with web work about four years back I worked exclusively on hard-core safety-critical and mission-critical embedded systems with external certification requirements to meet: cockpit autopilots; transmission auditing; satellite comms and proprietary network infrastructure. All our code passed stringent empirical quality tests and I don't recall anyone from the CAA, FAA, etc. ever commenting on the lack of a fixed house style which I certainly would have done for the avionics work as I was responsible for the certification process as well as a substantial portion of the code.
Unlike the listed FOSS projects they didn't expect contributions from thousands of developers, but then again neither do the majority of FOSS projects which are more typically the work of small teams.
Clark Gaebel
actually important. As you've said yourself, if you have a thousand-line
monolithic function the brace location will minimally effect the code's
readability. However, _inconsistent_ brace style has a huge negative
effect on the code's readability. People can adapt to the majority of
brace styles, but it takes time. If it's constantly changing every 10
lines of code, people never get a chance to adapt to it and just get
frustrated.
Because of this, Go gives us "one true brace style". Although many don't
agree with it (I personally prefer braces getting their own line), it it
an elegant solution to the problem of "cowboy bracing". It took me a few
minutes to adjust to the new style, but once I did I found it no more or
less readable than my own, personal style.
When we have many debatable styles to choose from, it just turns into
yet another bikeshed that needs painting. Surely we have more important
things to discuss, no?
--
Regards,
-- Clark
Eleanor McHugh
> On 24 Sep., 16:04, Ian Lance Taylor <i...@google.com> wrote:
>> I'm sorry, but I don't buy it.
>
> You don't have to. Software developers are all different, their
> experience is different, their goals and priorities are different too.
> What is right for my colleague may appear unsuitable for you, and vice
> versa.
Very true. Anyone who's ever tried one-size-fits-all clothes will know they very rarely fit anyone particularly well.
>> So while I'm sure your colleague believes that he is telling the truth,
>> I am equally sure that he is mistaken. He could adapt if he had to, and
>> in a short period of time he would be equally productive in whatever
>> style he had to use.
>
> Of course, he can adapt. Would he retain his present performance? I
> don't know. Your personal experience, valuable as it is, cannot be
> directly projected to other persons: software developers are all
> different. But anyway, the question is: why should he adapt? As I
> mentioned, neither him, nor his company would gain any slightest
> benefit for the effort spent for adapting to some "standard" style.
In fact it'd probably be cheaper just to write an analogue to gofmt that translated their preferred style(s) into whatever happened to be the go house style at that time.
>>
>> When working in Go there is only one style.
>
> I'm sorry, but I don't buy it. :)
>
> Indeed there exists a multitude of styles when working in Go. For
> instance, I can (and actually do) use style like this:
>
> // sum -- calculate sum of elements in the slice
> func sum(v []int) int {
>
> s := 0
> for i := 0; i < len(v); i++ {
> s += v[i];
> }
> return s
> }
>
> This is a valid fragment of Go code and the language specification
> does not prevent me from using this style. I also don't need gofmt,
> don't use use it and have no plans to use it in the future.
> Furtunately, gofmt is just an additional tool and not a mandatory
> element of Go language. (I actually cannot understand why some
> reviewers claim that all Go source code must be passed through gofmt
> before compilation.)
>
Probably because there are those who wish that was the case. I also don't use gofmt, and the one thing it offers that I do want (text substitution so I can write a core type and produce several isomorphic types automagically) it handles sufficiently badly that I wrote my own equivalent tools. Really guys, one substitution text per step in the pipeline? What were you thinking? I know unix processes are cheap, but they're not _that_ cheap...
bflm
wrote:
> Dialogue is about engagement, and accepting that the views of another may
> differ but that this does not automatically mean they are your enemy.
before. Moreover, good dialogue is IMO about seriously thinking out
the other/opposing view, not necessarily accepting it afterwards.
> It is a basic premise of dialogue that all views can be offered freely,
> discussed without ire, and that where disagreement remains all parties accept
> this in a warm and friendly spirit.
aren't they?
> When one or other of us takes the position that all people must subscribe to
> the same position without variance then no dialogue can be possible on that
> particular matter.
team and many others have some IMO well reasoned opinion on the issue
but no one has to share that opinion. Why? Is there anyone disallowed
to disagree? On the other side, is the dev team somehow obligated to
follow/adopt the opinion which they don't agree with? Why?
There are many more interesting ideas in your long post which I would
love to comment, but I already feel quite guilty of prolonging this
thread which up to now generated some 300k+ mails to be transferred (#
of posts in this thread times the # of subscribers to this list) so I
will pick just one more.
> So is this obsession with one true representation of code really buying
> anything? If I produce a 1000 line, highly-optimised, monolithic function
> based on interface{} and reflection is being precise about the use of
> whitespace really going to make it appreciably easier to decipher?
care which Go styling is the recommended/enforced one as long as I
don't have to adapt/switch myself to different styles every time again
and again. So I'm ready to adopt your preferred style guide without
any complaint and to my own good. I'm not sure if this situation of us
is symmetric. There is no offence in this, honestly.
Eleanor McHugh
> I think you've missed the point. The location of the braces is not
> actually important. As you've said yourself, if you have a thousand-line
> monolithic function the brace location will minimally effect the code's
> readability. However, _inconsistent_ brace style has a huge negative
> effect on the code's readability. People can adapt to the majority of
> brace styles, but it takes time. If it's constantly changing every 10
> lines of code, people never get a chance to adapt to it and just get
> frustrated.
But I could quite happily vary my brace style every 10 lines with Go's currently spec and there's nothing there that could stop me. So whilst I agree with you that such a thing would hamper legibility, I have to question whether the point is actually central to this discussion.
> Because of this, Go gives us "one true brace style". Although many don't
> agree with it (I personally prefer braces getting their own line), it it
> an elegant solution to the problem of "cowboy bracing". It took me a few
> minutes to adjust to the new style, but once I did I found it no more or
> less readable than my own, personal style.
Personally I've never had to adjust: Go's typical bracing style is the same as the one I've been using since I first started with C back in 1988. But having met a lot of C hackers who have a very different view on brace placement to mine - many of whom have been vocal in telling me I should only use their style - I can imagine how Alexey might feel to be being told by all and sundry that his way is "the wrong way". It's not right and it's not wrong in any deep metaphysical sense, it's just different.
> When we have many debatable styles to choose from, it just turns into
> yet another bikeshed that needs painting. Surely we have more important
> things to discuss, no?
Conversely if we can't even discuss this as a community without a fair number of "take it or leave" responses, how can we productively discuss anything more interesting?
Eleanor McHugh
No, it isn't symmetric. I like my style and I don't intend to change it except as it naturally evolves in response to my work.
Conversely I have absolutely no desire for you to adopt my style, or anyone else's for that matter. Find your own style, shape it to suit the problems you tackle and the way you think. That will make me infinitely more happy than your trying to write in my style, both from the knowledge that you're expressing yourself the way you wish to and also from the delight I'll find in reading your code in the future.
Cory Mainwaring
The point is to write in your native language and have everyone learn
to read a single, common language. You never have to write in it, just
read it. It speeds everything up. A gofmt that converts code into your
personal language would be cooler, but somewhat impossible to do, as
that would require writing a gofmt for every individual developer who
uses go. Possibly with a crazed series of options or a special
scripting language for how things should be written out by the
formatter it could be done, but again, that's not as feasible as just
creating a single common language that everyone reads and translates
with.
If I hate someone's coding style, I run it through gofmt and arrive at
a sub-optimal, but generally not too terrible style that I can read.
Now if you can't STAND gofmt, you have to write your own, and I would
suggest you release your own so others who hate that format can use
your formatter instead of gofmt for translation.
If your coding style isn't translatable to gofmt style, file a bug or
a patch for it (for gofmt should likely fit in this purpose).
On 26 September 2010 10:05, Eleanor McHugh
Rob 'Commander' Pike
-rob
henrik Johansson
> The thing that bothers me about this thread is that there are brace brackets, also known as curly brackets, but the term "curly braces" is a pleonasm with no rhetorical value.
>
> -rob
>
Styles come and go with team members, that's never going to change.
I am happy to accept whatever style gofmt gives me as long as it is
somewhat reasonable which it already is.
Having a tool like this that all members of a team just use is so much more
valuable than having _the perfect style_. Anyone with some experience in merging
(knock knock) will agree that its a good thing.
/ Hank
Clark Gaebel
On 09/26/10 12:17, Rob 'Commander' Pike wrote:
> The thing that bothers me about this thread is that there are brace brackets, also known as curly brackets, but the term "curly braces" is a pleonasm with no rhetorical value.
>
> -rob
>
--
Regards,
-- Clark
Alexey Gokhberg
On 26 Sep., 18:17, "Rob 'Commander' Pike" <r...@google.com> wrote:
> The thing that bothers me about this thread is that there are brace brackets, also known as curly brackets, but the term "curly braces" is a pleonasm with no rhetorical value.
>
This would be not so easy to fix, I am afraid ...
- Alexey
Steven
Let's just call them mustachios then. :{
Regards,
-- Clark
Christophe de Dinechin
I noticed a reference to my blog in reply to Alexey. Just want to make
sure you don't confuse us. I believe that Alexey's preferences have
little to do with my own arguments.
Let me just address the two points you made in your post:
- The reference I (not Alexey) made to Orwell is to "Newspeak", which
aims at controlling how people think by controlling how they speak.
You wrote that it's not a matter of human rights, but I do believe
that languages restrictions limit how we can describe problems to
computers. So I'm trying to remove restrictions, and I don't like
adding unnecessary ones.
- Regarding "bogus syntactic reasons", I'm referring in particular to
http://golang.org/doc/effective_go.html#semicolons, which justifies
forcing the placement of curly braces by the "need" to hide
semicolons. Having designed a language which has no semicolons and no
braces, I know for a fact that the argument is rather weak.
Thanks
Christophe