Re: [go-nuts] No Allman-Style, No go!

[eric . pelzer]

2013/9/21, Michael Daconta : 
> I assume you say this with tongue-in-cheek; however, I cannot believe 
this 
> design decision was made.  For something to borrow so liberally from C 
only 
> 
> to enforce "one-true" bracing style is frankly ridiculous. 
> When someone has coded for a long time using their favorite bracing 
style, 
> the numerous hours of frustration to learn this new language become not 
> worth it.  Just due to inadvertent, habitually return to a bracing style 
> the language designers deemed improper - which, in fact, is actually due 
to 
> 
> the laziness of their compiler.  I believe they could improve the 
compiler 
> to correct this.  So, while I could write my own compiler for this - 
there 
> is actually an easier solution, just ignore this language until the 
> language designers do the right thing.  And if not, ignore it all 
together. 

Thanks to Lockrecv for having indirectly reminded us that perfect post. 
Everything is in it.

And Ian has told us that this design decision some of us regret will never 
be fixed, and I'm grateful to him for his great honesty.

Moreover, everybody here now knows that there is no "best" indentation 
style. 

K favors compactness, Allman favors alignment.

Both are fine, as long as you and your team choose it, and stick to it.

Almost all the other languages of the C-family allow that, so I finally 
agree we should stop blaming Go for being the one who decided to enforce 
the "one true style" at the compiler level.

And yes, there is no genericity. Yes, there is no argument polymorphism. 
Etc etc.

But Go is an eye opened. Without it, I wouldn't know about alternative 
languages like D, etc.

And I would also like to point out that Go is by far one of the best 
possible target for transpilers. 

It immediately give us everything we would ever need, including the GC, a 
standard library etc. 

So much better and easier than C, LLVM, etc.

So once again, I want to say that I'm grateful to the Go designers, 
including Ian, to have given us Go as an open source tool we can all use 
for free. 

It's not only a great language, and also a fantastic target.

And thus I think we should all agree that despite its idiosyncrasies, Go is 
really excellent, in a way or another :)

Le lundi 31 juillet 2017 17:15:18 UTC+1, lockrecv a écrit :
>
> You like radish, we like meat.
>
> 在 2013年9月21日星期六 UTC+8下午10:04:09，Michael Daconta写道：
>>
>> Hi Remy,
>>
>> So, in the original program, to test the exact theory you mention, I 
>> added all the semi-colons myself.
>> Like so:
>>
>> package main;
>>
>> import "fmt";
>>
>> func main() 
>> {
>> fmt.Printf("hello, world!\n");
>> }
>>
>> As you can see, the code has semi-colons in each required location.  So, 
>> I ask you - why is the above code illegal?
>> All I've heard so far, is that "it is because the automatic insertion of 
>> semi-colons requires this stupid behavior".  Given the above code should 
>> require NO automatic insertion of semi-colons - why the stupid behavior?
>>
>> As for the folks on the thread saying "get over it" - sorry, I would turn 
>> the question back to you and say - why are you blindly accepting something 
>> so foolish?  There are things in a programming language that MUST be 
>> enforced, this should not be one of them.  So, either the language 
>> designers must admit their language is poorly designed, or they need to fix 
>> the problem!  Ignoring the problem or flippantly asserting there is no 
>> problem, is the worst thing they can do as it goes against the very reasons 
>> you design a new language for in the first place.
>>
>> - Mike
>>
>> On Saturday, September 21, 2013 9:49:42 AM UTC-4, Rémy Oudompheng wrote:
>>>
>>> Compiler laziness is a minor argument. Humans must also understand 
>>> semicolon insertion rules, justifying the choice of simple rules. 
>>>
>>> The choice of a standard formatting also makes the use of grep easier. 
>>>
>>>
>>> 2013/9/21, Michael Daconta : 
>>> > I assume you say this with tongue-in-cheek; however, I cannot believe 
>>> this 
>>> > design decision was made.  For something to borrow so liberally from C 
>>> only 
>>> > 
>>> > to enforce "one-true" bracing style is frankly ridiculous. 
>>> > When someone has coded for a long time using their favorite bracing 
>>> style, 
>>> > the numerous hours of frustration to learn this new language become 
>>> not 
>>> > worth it.  Just due to inadvertent, habitually return to a bracing 
>>> style 
>>> > the language designers deemed improper - which, in fact, is actually 
>>> due to 
>>> > 
>>> > the laziness of their compiler.  I believe they could improve the 
>>> compiler 
>>> > to correct this.  So, while I could write my own compiler for this - 
>>> there 
>>> > is actually an easier solution, just ignore this language until the 
>>> > language designers do the right thing.  And if not, ignore it all 
>>> together. 
>>> > 
>>> > Though I like many features of 

Re: [go-nuts] No Allman-Style, No go!

[lockrecv]

You like radish, we like meat.

在 2013年9月21日星期六 UTC+8下午10:04:09，Michael Daconta写道：
>
> Hi Remy,
>
> So, in the original program, to test the exact theory you mention, I added 
> all the semi-colons myself.
> Like so:
>
> package main;
>
> import "fmt";
>
> func main() 
> {
> fmt.Printf("hello, world!\n");
> }
>
> As you can see, the code has semi-colons in each required location.  So, I 
> ask you - why is the above code illegal?
> All I've heard so far, is that "it is because the automatic insertion of 
> semi-colons requires this stupid behavior".  Given the above code should 
> require NO automatic insertion of semi-colons - why the stupid behavior?
>
> As for the folks on the thread saying "get over it" - sorry, I would turn 
> the question back to you and say - why are you blindly accepting something 
> so foolish?  There are things in a programming language that MUST be 
> enforced, this should not be one of them.  So, either the language 
> designers must admit their language is poorly designed, or they need to fix 
> the problem!  Ignoring the problem or flippantly asserting there is no 
> problem, is the worst thing they can do as it goes against the very reasons 
> you design a new language for in the first place.
>
> - Mike
>
> On Saturday, September 21, 2013 9:49:42 AM UTC-4, Rémy Oudompheng wrote:
>>
>> Compiler laziness is a minor argument. Humans must also understand 
>> semicolon insertion rules, justifying the choice of simple rules. 
>>
>> The choice of a standard formatting also makes the use of grep easier. 
>>
>>
>> 2013/9/21, Michael Daconta : 
>> > I assume you say this with tongue-in-cheek; however, I cannot believe 
>> this 
>> > design decision was made.  For something to borrow so liberally from C 
>> only 
>> > 
>> > to enforce "one-true" bracing style is frankly ridiculous. 
>> > When someone has coded for a long time using their favorite bracing 
>> style, 
>> > the numerous hours of frustration to learn this new language become not 
>> > worth it.  Just due to inadvertent, habitually return to a bracing 
>> style 
>> > the language designers deemed improper - which, in fact, is actually 
>> due to 
>> > 
>> > the laziness of their compiler.  I believe they could improve the 
>> compiler 
>> > to correct this.  So, while I could write my own compiler for this - 
>> there 
>> > is actually an easier solution, just ignore this language until the 
>> > language designers do the right thing.  And if not, ignore it all 
>> together. 
>> > 
>> > Though I like many features of the language from looking at the "go 
>> tour", 
>> > I can take it or leave it. 
>> > 
>> > While I new this post could be flame bait, I actually had to post it 
>> > because I was so shocked that Google would make such a foolish error. 
>> > Really, lose adoption over compiler laziness?  Give me a break... 
>> > 
>> > - Mike 
>> > 
>> > On Saturday, September 21, 2013 12:45:58 AM UTC-4, Dave Cheney wrote: 
>> >> 
>> >> I, For One, welcome the One True Brace style. 
>> >> 
>> >> On Sat, Sep 21, 2013 at 11:58 AM, Michael Daconta 
>> >>  wrote: 
>> >> > Hi Go fans, 
>> >> > 
>> >> > I frankly was shocked to learn that a program like: 
>> >> > 
>> >> > package main; 
>> >> > 
>> >> > import "fmt"; 
>> >> > 
>> >> > func main() 
>> >> > { 
>> >> > fmt.Printf("hello, world!\n"); 
>> >> > } 
>> >> > 
>> >> > ... is currently illegal in go with the error: 
>> >> > 
>> >> > # command-line-arguments 
>> >> > .\hello.go:6: syntax error: unexpected semicolon or newline before { 
>> >> > 
>> >> > From reading the newsgroups, I see that this is illegal due to the 
>> >> automatic 
>> >> > insertion of semi-colons; however, what if I added my own 
>> semi-colons 
>> >> into 
>> >> > the code as in the above.  From a language perspective the above 
>> should 
>> >> > 
>> >> be 
>> >> > legal Go code.  To me, it seems like a hack for convenience (making 
>> >> > semi-colons optional) has forced a K style on everyone. 
>> >> > For me, this is a show-stopper.  Frankly, I am surprised that Google 
>> >> would 
>> >> > enforce a coding style (K) while saying that "go fmt" frees you 
>> from 
>> >> > worrying about divergent coding styles.  Sorry, google - you cannot 
>> have 
>> >> > 
>> >> it 
>> >> > both ways.  Unless the Allman-style code above is illegal in the 
>> >> language 
>> >> > (which makes no sense from a language semantics point of view) - get 
>> the 
>> >> > 
>> >> > compiler to accept it. Period. 
>> >> > 
>> >> > Yes, I know I can write my own translator - but why?  Heck, I can 
>> just 
>> >> stick 
>> >> > with Java... 
>> >> > 
>> >> > C'mon Google, when trying to pitch a new language, you can (and 
>> should) 
>> >> > 
>> >> do 
>> >> > better than this... 
>> >> > 
>> >> > - Mike 
>> >> > 
>> >> > -- 
>> >> > You received this message because you are subscribed to the Google 
>> >> Groups 
>> >> > "golang-nuts" group. 
>> >> > To unsubscribe from this group 

Re: [go-nuts] No Allman-Style, No go!

[me]

On Thursday, July 27, 2017 at 7:40:20 PM UTC-6, Bakul Shah wrote:
>
> I have to disagree somewhat with me(!). Programming is much more an 
> engineering discipline than a creative process. 
>

I think it is both, or when I was on a holiday and at a hotel and there was 
a Trinity pamphlet in the main hotel area I came up with an idea that 
programming is a trinity of three things:

- Mathematics
- Engineering
- Science

And is neither of each alone but all of the above combined.

Just that there are some things in programming you cannot do in a 
completely disciplined state and must do with all your creativity, but when 
writing code that others will use, it is better to write dumb easy to read 
perfectly formatted code than to go off on a creative tangent - that's the 
way I try to write code - simple short procedures using as few tricks as 
possible. Which Lisp is the opposite of, IMO, and is full of tricks - but 
allows creative spirits to flow ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] No Allman-Style, No go!

[Andy Balholm]

I’ve always considered the lexer to be part of the compiler, and apparently 
Ecstatic Coder does too, considering his complaint.

Andy

> On Jul 29, 2017, at 2:58 PM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Sat, Jul 29, 2017 at 10:43 PM Andy Balholm  > wrote:
> 
> > It’s not quite true that the compiler doesn’t care about white space. The 
> > lexer is part of the compiler, and it does care about white space. The 
> > semicolon insertion rule, in particular, pays attention to newlines. So, 
> > while the compiler doesn’t care about indentation at all, there are some 
> > brace/indentation styles that it will not accept. One of those is Allman 
> > style.
> 
> That's why it was compared to the processing according to the C 
> specification. Only at phase 7 is "The resulting tokens are syntactically and 
> semantically analyzed and translated as a translation unit." performed. The 
> previous 6 phases used to be actually a separate program/programs running 
> before the compiler (phase 7) was invoked. Putting it all in one black box 
> does not necessarily blur the conceptual separation. Most compilers _can_ 
> work without a lexer, they could directly consume token sequences just 
> happily. It's just no more practical to separate the pieces.
> 
> -- 
> -j
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] No Allman-Style, No go!

[Jan Mercl]

On Sat, Jul 29, 2017 at 10:43 PM Andy Balholm  wrote:

> It’s not quite true that the compiler doesn’t care about white space. The
lexer is part of the compiler, and it does care about white space. The
semicolon insertion rule, in particular, pays attention to newlines. So,
while the compiler doesn’t care about indentation at all, there are some
brace/indentation styles that it will not accept. One of those is Allman
style.

That's why it was compared to the processing according to the C
specification. Only at phase 7 is "The resulting tokens are syntactically
and semantically analyzed and translated as a translation unit." performed.
The previous 6 phases used to be actually a separate program/programs
running before the compiler (phase 7) was invoked. Putting it all in one
black box does not necessarily blur the conceptual separation. Most
compilers _can_ work without a lexer, they could directly consume token
sequences just happily. It's just no more practical to separate the pieces.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] No Allman-Style, No go!

[Andy Balholm]

It’s not quite true that the compiler doesn’t care about white space. The lexer 
is part of the compiler, and it does care about white space. The semicolon 
insertion rule, in particular, pays attention to newlines. So, while the 
compiler doesn’t care about indentation at all, there are some 
brace/indentation styles that it will not accept. One of those is Allman style.

> On Jul 29, 2017, at 1:13 PM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Sat, Jul 29, 2017 at 7:36 PM  > wrote:
> 
> > But as Gofmt can ALREADY enforces this common coding style, and can be run 
> > at any time, including before committing code on the depots, why should it 
> > be enforced by the COMPILER too ?
> 
> Let me pick just one misconception. The compiler does not care about 
> formatting style at all - because it cannot see it! Token sequences have no 
> style as they contain no white space or any other kind of token separators. 
> It's just tokens. All the way down.
> 
> The specification prescribes how the source code text is transformed into the 
> token sequence the compiler only cares about. It's different in details, but 
> conceptually it's just a transformation stage in the sense of what the 
> specification of the, for example, C language prescribes.
> 
> You may dislike the specification, but you can hardly argue it's not well 
> thought out and reasonable as a trade-off between mandatory semicolons (pre 
> Go 1 had them) and almost no need to write them in exchange for adjusting to 
> the implications and/or costs of that comfort.
> 
> If Go changed its specification such that the left brace of a statement block 
> must be on its own line, it'll take me probably just a few minutes to adapt 
> and forget about it completely, because it's such an unimportant detail 
> compared to what I love about Go. Why some others cannot do the same is 
> beyond my comprehension, but that's by definition my fault, admitted.
> 
> -- 
> -j
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] No Allman-Style, No go!

[Bakul Shah]

I have to disagree somewhat with me(!). Programming is much more an engineering 
discipline than a creative process. A case in point: the earlier thread today 
about 10x latency spike. If the latency spikes don't meet user expectation (or 
a formal requirement), the program is not "done". Replacing map[int]slice with 
map[int](base, limit) is a tradeoff (one among many). Making such tradeoffs is 
just part of the engineering process.

If your program has to handle a certain level of load, it should be tested with 
such load (or scaled down load that can be extrapolated to full scale) and make 
the changes necessary to achieve that. If it has to have 99.95% uptime, you 
will need redundancy. If it has to quickly recover from a crash without loss of 
data, that may require using atomic transactions. Add security as well! All 
these requirements will change your "beautiful" masterpiece into something 
potentially ugly and boring.

A high level language makes this engineering process easier but you, the 
programmer (team), still have to design, build, test and tweak a solution until 
it meets your requirements; you can't expect the compiler to do all the heavy 
lifting (which is almost always specific to a problem).

You can still employ your skill and creativity in fit & finish and design & 
clarity of your code and occasionally coming up with a brilliant new algorithm. 
None of that will be stifled just because you can't format your Go code in your 
favorite C style!

> On Jul 27, 2017, at 3:40 PM, me  wrote:
> 
> As for comparing programming to driving on the road: Okay but programming is 
> and extremely creative effort, sort of like writing a novel with mathematics 
> in it. The argument is that you take away people's creativity, with tools 
> like GoFmt, in the same way forcing a super creative person to write a poem a 
> certain way, or forcing someone to use a certain style of mathematics in a 
> paper (which, could be a good thing depending on the case - but if it is a 
> really creative looney mathematician, you will want him to write like a wild 
> stallion, free as can be and let him create his masterpiece) 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] No Allman-Style, No go!

['Eric Johnson' via golang-nuts]

On Saturday, September 21, 2013 at 7:04:09 AM UTC-7, Michael Daconta wrote:
>
> As you can see, the code has semi-colons in each required location.  So, I 
> ask you - why is the above code illegal?
>

Why is breaking the speed limit illegal? On many roads, it is set 
arbitrarily low because that's the way the neighbors want it, with no 
evidence that it makes anyone safer. In the case of Go, the spec defines it 
that way, that's why it is illegal. If you've ever written bash scripts, 
you likely know there are some very weird choices in that language too. 
That doesn't keep people from using it.
 

> All I've heard so far, is that "it is because the automatic insertion of 
> semi-colons requires this stupid behavior".  Given the above code should 
> require NO automatic insertion of semi-colons - why the stupid behavior?
>

Calling the behavior stupid will not win anyone over to your side.
 

> As for the folks on the thread saying "get over it" - sorry, I would turn 
> the question back to you and say - why are you blindly accepting something 
> so foolish?  There are things in a programming language that MUST be 
> enforced, this should not be one of them.
>

I've spent several decades programming. Brace style has never affected my 
ability to code effectively, and I've always needed to be flexible, in 
order to adopt to the tastes of the people I work with. So in that sense, 
it doesn't matter. Indeed, given a choice, I mostly prefer something that 
conserves on vertical space, since the view in my editor is a critical 
constraint, thus preferring to have braces on the same line. Python goes 
one step further and eliminates both braces, which is a step too far, for 
me. Entirely a personal preference, from what I can tell. As for having Go 
enforce a particular format, it turns out to be very valuable, because it 
means that looking at diffs in source control never has the problem of 
showing just changes to spaces, and you can look at anyone else's code, and 
see the exact same style. THAT was a very valuable design choice.

As for accepting something so foolish, *every* language has design 
trade-offs. I do not accept them blindly, but accept them deliberately.
 

>   So, either the language designers must admit their language is poorly 
> designed,
>

Nope - they just made a design trade-off that you happen to disagree with.
 

> or they need to fix the problem!
>

The Go community seems to be *very* pragmatic, and evidence driven. The 
language doesn't have features unless their needed. Can you define and 
demonstrate the problem? Can you show the brace style gets in the way of 
effective Go programming? If you can come up with relevant evidence, then 
you probably stand a chance of convincing people that the language at least 
needs to allow for braces on the next line, even if it isn't the default. 
Given that the industry has been chasing this question for decades, though, 
I don't think you'll find the evidence.
 

>   Ignoring the problem or flippantly asserting there is no problem,
>

The language designers used their combined decades of experience and made a 
choice. The community has accepted this design trade-off. Whereas, you 
assert there is a problem, but provide no data. That's the source of the 
skepticism.
 

> is the worst thing they can do as it goes against the very reasons you 
> design a new language for in the first place.
>

On the contrary, they made the language to suit their needs, and their 
background. Your mileage may vary.

Eric. 
 

>
> - Mike
>
> On Saturday, September 21, 2013 9:49:42 AM UTC-4, Rémy Oudompheng wrote:
>>
>> Compiler laziness is a minor argument. Humans must also understand 
>> semicolon insertion rules, justifying the choice of simple rules. 
>>
>> The choice of a standard formatting also makes the use of grep easier. 
>>
>>
>> 2013/9/21, Michael Daconta : 
>> > I assume you say this with tongue-in-cheek; however, I cannot believe 
>> this 
>> > design decision was made.  For something to borrow so liberally from C 
>> only 
>> > 
>> > to enforce "one-true" bracing style is frankly ridiculous. 
>> > When someone has coded for a long time using their favorite bracing 
>> style, 
>> > the numerous hours of frustration to learn this new language become not 
>> > worth it.  Just due to inadvertent, habitually return to a bracing 
>> style 
>> > the language designers deemed improper - which, in fact, is actually 
>> due to 
>> > 
>> > the laziness of their compiler.  I believe they could improve the 
>> compiler 
>> > to correct this.  So, while I could write my own compiler for this - 
>> there 
>> > is actually an easier solution, just ignore this language until the 
>> > language designers do the right thing.  And if not, ignore it all 
>> together. 
>> > 
>> > Though I like many features of the language from looking at the "go 
>> tour", 
>> > I can take it or leave it. 
>> > 
>> > While I new this post could be flame bait, I