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

[ecstatic . coder]

D being rather unpopular (#23 at the TIOBE index of July 2017) at the 
moment compared to Google's Go, which is impressively climbing the charts 
at high speed, then I think we shouldn't worry too much about D's 
decline... ;)

On Tuesday, August 1, 2017 at 10:18:21 AM UTC+1, Russel Winder wrote:
>
> On Mon, 2017-07-31 at 12:21 -0500, John McKown wrote: 
> > 
> […] 
> > An excellent approach to all languages. If someone doesn't like "go", 
> > then use a different language. Or be like some people and invent your 
> own 
> > to address the perceived problems with all the other languages in 
> existence. 
> > 
>
> Once a programming language goes into production and invokes "backward 
> compatibility" it rarely improves by evolution. cf. Fortran, Java. 
> Invariably, 
> improvement in programming happens by new programming languages arriving 
> on 
> the scene and being picked up (or not). Each programming language that 
> gains 
> traction invariably goes into decline as new languages pop up to replace 
> it. 
>
> But remember COBOL, FORTRAN, Fortran, and C still have large codebases in 
> place even though very few people would consider writing new code in those 
> languages. Go, Rust, D, etc. will travel the same path after their period 
> of 
> being very popular. 
>
> > 
> -- 
> Russel. 
> = 
>
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russ...@ekiga.net 
>  
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk 
>  
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
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] Re: No Allman-Style, No go!

[Russel Winder]

On Mon, 2017-07-31 at 12:21 -0500, John McKown wrote:
> 
[…]
> An excellent approach to all languages. If someone doesn't like "go",
> then use a different language. Or be like some people and invent your own
> to address the perceived problems with all the other languages in existence.
> 

Once a programming language goes into production and invokes "backward
compatibility" it rarely improves by evolution. cf. Fortran, Java. Invariably,
improvement in programming happens by new programming languages arriving on
the scene and being picked up (or not). Each programming language that gains
traction invariably goes into decline as new languages pop up to replace it.

But remember COBOL, FORTRAN, Fortran, and C still have large codebases in
place even though very few people would consider writing new code in those
languages. Go, Rust, D, etc. will travel the same path after their period of
being very popular.

> 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
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.


signature.asc
Description: This is a digitally signed message part

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

[John McKown]

On Mon, Jul 31, 2017 at 12:12 PM, Ian Lance Taylor  wrote:

> ​
>
>
>
> I think it's time to let this thread go back to sleep again.  I think
> that every possible point of view has already been expressed.
>

​I agree. Not that anyone is impressed by that. [grin]


>
> The language is not going to change.  It is what it is.
>

​An excellent approach to all languages. ​If someone doesn't like "go",
then use a different language. Or be like some people and invent your own
to address the perceived problems with all the other languages in existence.



>
> Ian
>
> ​​



-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

-- 
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] Re: No Allman-Style, No go!

[Ian Lance Taylor]

On Mon, Jul 31, 2017 at 10:10 AM, Hrobjartur Thorsteinsson
 wrote:
> Hi Mr. Bushnell,
> The code block identifier, in Go are  { }. They are already part of the
> syntax if I'm not mistaken.
> Go proudly aiming to be a simplifying,  lowest common denominator language
> makes sense to me.
> In that sense, the { signs tightly bound to declarations and control
> statements is redundant.
> In go { identifies a beginning of a code block, except where you have
> control statements of declarations.
>
> It could be reasonably argued that this is redundant, and therefore not
> common lowest denominator.





I think it's time to let this thread go back to sleep again.  I think
that every possible point of view has already been expressed.

The language is not going to change.  It is what it is.

Ian



> On Mon, Jul 31, 2017 at 4:48 PM, Thomas Bushnell, BSG 
> wrote:
>>
>> On Sat, Jul 29, 2017 at 10:36 AM  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 ?
>>
>>
>> The compiler does not enforce the use of gofmt.
>>
>> What you're complaining about is that the syntax of the language does not
>> permit a particular thing which the syntax of C does. It also doesn't permit
>> "a = b++" and many other things which C does.
>>
>> Thomas
>>
>
>
> --
> 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] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

Hi Mr. Bushnell,
The code block identifier, in Go are  { }. They are already part of the
syntax if I'm not mistaken.
Go proudly aiming to be a simplifying,  lowest common denominator language
makes sense to me.
In that sense, the { signs tightly bound to declarations and control
statements is redundant.
In go { identifies a beginning of a code block, except where you have
control statements of declarations.

It could be reasonably argued that this is redundant, and therefore not
common lowest denominator.


On Mon, Jul 31, 2017 at 4:48 PM, Thomas Bushnell, BSG 
wrote:

> On Sat, Jul 29, 2017 at 10:36 AM  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 ?
>>
>
> The compiler does not enforce the use of gofmt.
>
> What you're complaining about is that the syntax of the language does not
> permit a particular thing which the syntax of C does. It also doesn't
> permit "a = b++" and many other things which C does.
>
> Thomas
>
>

-- 
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] Re: No Allman-Style, No go!

['Thomas Bushnell, BSG' via golang-nuts]

On Sat, Jul 29, 2017 at 10:36 AM  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 ?
>

The compiler does not enforce the use of gofmt.

What you're complaining about is that the syntax of the language does not
permit a particular thing which the syntax of C does. It also doesn't
permit "a = b++" and many other things which C does.

Thomas

-- 
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] Re: No Allman-Style, No go!

[eric . pelzer]

As I said, I perfecly understand you decision, and the context in which it 
was made.

Anyway, many people here have *strongly* suggested that I must fork the Go 
compiler source code and fix it by myself, so I guess I'll have to do it, 
and find a way to add a pragma which allows to disable the semi-colon 
insertion algorithm, as I actually don't mind at all having to use 
semi-colons, which I do anyway in D and C++...

Le lundi 31 juillet 2017 03:18:09 UTC+1, Ian Lance Taylor a écrit :
>
> On Sat, Jul 29, 2017 at 10:36 AM,  > 
> 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 ? 
> > 
> > Really, that's the one particular engineer decision I regret. Just one. 
> But 
> > that's a big one. Because sometimes, almost ENTIRE teams prefer the 
> Allman 
> > style. That's not just a personal affair. All that because maybe 2 or 3 
> > languages designers have decided so, moreover to make it easy to 
> > automatically add the semi-colons. 
> > 
> > And it doesn't even work well, we are now force to put a useless comma 
> after 
> > the last parameter of a function to be allowed to split the arguments on 
> > several lines. Please don't insult me by telling there wasn't any other 
> > possible solution. 
> > 
> > For instance, in Javascript, the semi-colon are also optional, but the 
> > compiler lets you use whatever coding style you want. 
>
> I'll note that there is a lot of discussion on the web about problems 
> with semicolons in Javascript.  When we were discussing the 
> possibility of a lexical semicolon insertion rule shortly after the Go 
> open source release, Javascript was considered to be an example of how 
> not to do it. 
>
> Historically speaking, gofmt came before lexical semicolon insertion. 
> The existence of gofmt made it possible to seriously consider lexical 
> semicolon insertion.  Implementing it did require, yes, that you must 
> put a comma after a parameter name in order to split a line and, yes, 
> that you must put the '{' on the same line as the function definition 
> or if/for/switch statement, etc.  We considered that to be an 
> acceptable drawback to get a simple rule, knowing that gofmt would 
> handle all such issues anyhow. 
>
> Ian 
>

-- 
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] Re: No Allman-Style, No go!

[ecstatic . coder]

The irony is that I don't even use the automatic semi-colon insertion 
feature. 

I'm used to add them manually anyway, even in Go, as whenever possible I 
tend to program in a less idiomatic way (for loops, semi-colons, etc) which 
allows me to easily port substantial parts of my code from one language to 
another.

For instance, several tools on my github account were initially implemented 
using Node.js, but I could very quickly port them to D.

But I know that this particular inclination makes me belong to an 
ultra-minority, once again... ;)

On Monday, July 31, 2017 at 3:18:09 AM UTC+1, Ian Lance Taylor wrote:
>
> On Sat, Jul 29, 2017 at 10:36 AM,  > 
> 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 ? 
> > 
> > Really, that's the one particular engineer decision I regret. Just one. 
> But 
> > that's a big one. Because sometimes, almost ENTIRE teams prefer the 
> Allman 
> > style. That's not just a personal affair. All that because maybe 2 or 3 
> > languages designers have decided so, moreover to make it easy to 
> > automatically add the semi-colons. 
> > 
> > And it doesn't even work well, we are now force to put a useless comma 
> after 
> > the last parameter of a function to be allowed to split the arguments on 
> > several lines. Please don't insult me by telling there wasn't any other 
> > possible solution. 
> > 
> > For instance, in Javascript, the semi-colon are also optional, but the 
> > compiler lets you use whatever coding style you want. 
>
> I'll note that there is a lot of discussion on the web about problems 
> with semicolons in Javascript.  When we were discussing the 
> possibility of a lexical semicolon insertion rule shortly after the Go 
> open source release, Javascript was considered to be an example of how 
> not to do it. 
>
> Historically speaking, gofmt came before lexical semicolon insertion. 
> The existence of gofmt made it possible to seriously consider lexical 
> semicolon insertion.  Implementing it did require, yes, that you must 
> put a comma after a parameter name in order to split a line and, yes, 
> that you must put the '{' on the same line as the function definition 
> or if/for/switch statement, etc.  We considered that to be an 
> acceptable drawback to get a simple rule, knowing that gofmt would 
> handle all such issues anyhow. 
>
> Ian 
>

-- 
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] Re: No Allman-Style, No go!

[Ian Lance Taylor]

On Sat, Jul 29, 2017 at 10:36 AM,   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 ?
>
> Really, that's the one particular engineer decision I regret. Just one. But
> that's a big one. Because sometimes, almost ENTIRE teams prefer the Allman
> style. That's not just a personal affair. All that because maybe 2 or 3
> languages designers have decided so, moreover to make it easy to
> automatically add the semi-colons.
>
> And it doesn't even work well, we are now force to put a useless comma after
> the last parameter of a function to be allowed to split the arguments on
> several lines. Please don't insult me by telling there wasn't any other
> possible solution.
>
> For instance, in Javascript, the semi-colon are also optional, but the
> compiler lets you use whatever coding style you want.

I'll note that there is a lot of discussion on the web about problems
with semicolons in Javascript.  When we were discussing the
possibility of a lexical semicolon insertion rule shortly after the Go
open source release, Javascript was considered to be an example of how
not to do it.

Historically speaking, gofmt came before lexical semicolon insertion.
The existence of gofmt made it possible to seriously consider lexical
semicolon insertion.  Implementing it did require, yes, that you must
put a comma after a parameter name in order to split a line and, yes,
that you must put the '{' on the same line as the function definition
or if/for/switch statement, etc.  We considered that to be an
acceptable drawback to get a simple rule, knowing that gofmt would
handle all such issues anyhow.

Ian

-- 
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] Re: No Allman-Style, No go!

[me]

On Saturday, July 29, 2017 at 5:50:55 PM UTC-6, Hrobjartur Thorsteinsson 
wrote:
>
> This confusing coding style with syntax in Go can be fixed by forking and 
> applying a rediculously small patch.
>
>
Forking is easy, but to get people to actually use a fork, support it, and 
embrace it, is a whole other issue.

Easier said than done. I mean, github makes it pretty easy to fork but, who 
is going to use the forked code, in quantity?  

-- 
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] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

actually python is very normal, in that it does not confuse encapsulation
with syntax. Go has the credit for exploring this exciting new frontier I
think.

31. júl. 2017 12:08 f.h. skrifaði "Florin Pățan" :

> This thread was dead for three years, but thanks for keeping the dream
> alive.
>
> Hate Go's style as much as you want, avoid Go because of this, it doesn't
> matter.
>
> gofmt's only purpose is so that by having the uniformity of the source
> code, everyone that can write Go code can do so anywhere. You instantly
> read the same layout in your code, in your old company's code and, even
> more important, in Go's own code.
>
> Let this sink in. You can just focus on understanding the code because you
> don't have to waste time with different formats of the same language.
>
> And that's a magnificent thing. You can literally jump between all Go code
> bases and in the world and it reads all the same. Aside from Python
> (probably) you can't do that with any other language.
>
> So please, stop this nonsense already.
>
> On a more serious note, is there no way to just close the thread as an
> admin? If it is, please do so.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: No Allman-Style, No go!

[Florin Pățan]

This thread was dead for three years, but thanks for keeping the dream alive. 

Hate Go's style as much as you want, avoid Go because of this, it doesn't 
matter.

gofmt's only purpose is so that by having the uniformity of the source code, 
everyone that can write Go code can do so anywhere. You instantly read the same 
layout in your code, in your old company's code and, even more important, in 
Go's own code.

Let this sink in. You can just focus on understanding the code because you 
don't have to waste time with different formats of the same language.

And that's a magnificent thing. You can literally jump between all Go code 
bases and in the world and it reads all the same. Aside from Python (probably) 
you can't do that with any other language.

So please, stop this nonsense already.

On a more serious note, is there no way to just close the thread as an admin? 
If it is, please do so.

-- 
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] Re: No Allman-Style, No go!

[ecstatic . coder]

Indeed everybody can do whatever he wants with his company. And I don't 
agree with every Google decision, as you know ;)

And yes, coding standards will never make good developers, who design well 
and program clear readable code that is both efficient and easy to maintain.

Their goal is simply to make sure that everybody develops the same code in 
the same way, so that you can "enjoy" working on/with the code of your 
collegues, instead of "suffering" from it. You simply should not be able to 
guess who has developed the code you are working on/with.

On Sunday, July 30, 2017 at 8:22:37 PM UTC+1, Drew Derbyshire wrote:
>
> "And thirdly, the code is more what you'd call "guidelines" than actual 
> rules."  -- Captain Hector Barbossa
>
> On Saturday, July 29, 2017 at 10:37:11 AM UTC-7, ecstati...@gmail.com 
> wrote:
>>
>> Sorry to repeat myself, but I think I wasn't clear enough, as many people 
>> on this forum still don't understand my point at all. 
>>
>> Google, as ANY company, MUST force its employees to use exactly the same 
>> standards.
>>
>>
> This is flat out incorrect.  In particular, by using "ANY", "MUST" "force" 
> and "exactly", your directive is invalidated by a single company that 
> doesn't follow your directive succeeding. I've been at several such 
> companies.  
>
> Google has some of the strictest (and in some cases, flawed) coding 
> standards I've seen in my three plus decades in the industry.  Those 
> standards didn't make the code better than companies I've been at with 
> loose or even non-existent coding standards.
>
> I'd compare Google coding standards to Google management's belief that 
> open floor plans are more productive; that office layout is only a boon to 
> real-estate services's budget. I spent over a third of my career in 
> environments where I had a private office or at least sufficient space to 
> have minimum disruptions, and I can say the Google philosophy (and it's 
> interruption filled side-effects) is truly flawed.
>
> But neither Google's office layout nor their coding standards are fatal 
> flaws.
>
> I would stress proper documentation, good tests and diligent code reviews 
> far more than blind adherence to a coding standard.
>
> Good coders write good code, including being consistent with the code 
> base. 
>
> OCD coding standards don't make bad coders good coders.  Never did, never 
> will.
>
>

-- 
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] Re: No Allman-Style, No go!

[Drew Derbyshire]

"And thirdly, the code is more what you'd call "guidelines" than actual 
rules."  -- Captain Hector Barbossa

On Saturday, July 29, 2017 at 10:37:11 AM UTC-7, ecstati...@gmail.com wrote:
>
> Sorry to repeat myself, but I think I wasn't clear enough, as many people 
> on this forum still don't understand my point at all. 
>
> Google, as ANY company, MUST force its employees to use exactly the same 
> standards.
>
>
This is flat out incorrect.  In particular, by using "ANY", "MUST" "force" 
and "exactly", your directive is invalidated by a single company that 
doesn't follow your directive succeeding. I've been at several such 
companies.  

Google has some of the strictest (and in some cases, flawed) coding 
standards I've seen in my three plus decades in the industry.  Those 
standards didn't make the code better than companies I've been at with 
loose or even non-existent coding standards.

I'd compare Google coding standards to Google management's belief that open 
floor plans are more productive; that office layout is only a boon to 
real-estate services's budget. I spent over a third of my career in 
environments where I had a private office or at least sufficient space to 
have minimum disruptions, and I can say the Google philosophy (and it's 
interruption filled side-effects) is truly flawed.

But neither Google's office layout nor their coding standards are fatal 
flaws.

I would stress proper documentation, good tests and diligent code reviews 
far more than blind adherence to a coding standard.

Good coders write good code, including being consistent with the code base. 

OCD coding standards don't make bad coders good coders.  Never did, never 
will.

-- 
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] Re: No Allman-Style, No go!

[me]

On Thursday, July 27, 2017 at 6:20:00 PM UTC-6, Matt Harden wrote:
>
> "me": regarding purely functional programs, they can exist, but they can't 
> actually "do" anything, since by definition, "doing" means altering some 
> state in the outside world. 
>

Then are they even a program? That sounds more like a math proof, not a 
program... what is a program? Something that does something, programs 
something... IMO..
 

> But reasoning as much as possible in a functional way, and expressing your 
> programs in this way (again as much as possible), turns out to be very 
> effective, because reasoning about a virtually limitless amount of shared 
> state is extraordinarily difficult, especially in a concurrent program.
>

Unless there was no need for concurrency and in 1200 years or  50 years 
there is a computer that can take any program designed in a non concurrent 
way and run it in a millisecond.  I don't know the future of computing, 
though, so concurrency could win the battle. An interesting area of 
research would be whether quantum computer programs will be designed in a 
concurrent way, or some other way altogether.

-- 
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] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

its luxury that sudden support for allman style would be backwards
compatible and future proof. No airplanes would crash.

30. júl. 2017 12:35 skrifaði "Jan Mercl" <0xj...@gmail.com>:

On Sun, Jul 30, 2017 at 2:06 PM  wrote:

> Personally I'd prefer a simple compiler option :)

You must be kidding, aren't you?

It would be a horrible decision to introduce such compiler option.
Keywords: Python 3.

The debate about semicolon injection was relevant about 7 or 8 years ago,
IIRC. What's youe point actually nowadays? Do you expect to convince the
community of few hundred thousands Go programmers to adjust to the few
dozens complaining about the semicolon injection trade-offs and push a
specification change breaking the Go 1 backward compatibility guarantee? I
don't believe so. But then again, what's the goal? Honest question.

-- 

-j

-- 
You received this message because you are subscribed to a topic in the
Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
To unsubscribe from this group and all its topics, 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] Re: No Allman-Style, No go!

[Jan Mercl]

On Sun, Jul 30, 2017 at 2:06 PM  wrote:

> Personally I'd prefer a simple compiler option :)

You must be kidding, aren't you?

It would be a horrible decision to introduce such compiler option.
Keywords: Python 3.

The debate about semicolon injection was relevant about 7 or 8 years ago,
IIRC. What's youe point actually nowadays? Do you expect to convince the
community of few hundred thousands Go programmers to adjust to the few
dozens complaining about the semicolon injection trade-offs and push a
specification change breaking the Go 1 backward compatibility guarantee? I
don't believe so. But then again, what's the goal? Honest question.

-- 

-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] Re: No Allman-Style, No go!

['Axel Wagner' via golang-nuts]

Can we please, collectively, decide that this thread serves no productive
purpose anymore and abandon it? The only thing it is doing is inviting
ad-hominem attacks and hostile behaviors from all sides of the debate. No
matter where you stand on this, please abide by the spirit of the community
CoC  to create a warm, welcoming community
where people can enjoy participating. This question, no matter how invested
you are in it, isn't worth giving that up for it.
(yes, I know I don't always do that myself. Please call me out, if I do).

Please be excellent to each other :)

On Sun, Jul 30, 2017 at 2:06 PM,  wrote:

> Personally I'd prefer a simple compiler option :)
>
> On Sunday, July 30, 2017 at 12:50:55 AM UTC+1, Hrobjartur Thorsteinsson
> wrote:
>>
>> Dude, you are right. This confusing coding style with syntax in Go can be
>> fixed by forking and applying a rediculously small patch. Jeez, lets stop
>> complaining as u rightfully suggested.
>>
>> 29. júl. 2017 10:43 e.h. skrifaði "Wojciech S. Czarnecki" <
>> oh...@fairbe.org>:
>>
>>> On Sat, 29 Jul 2017 10:36:42 -0700 (PDT)
>>> ecstati...@gmail.com wrote:
>>>
>>> [APM]
>>> [Ad Personam mode on, I humbly apologize to bystanders]
>>>
>>> Enough is enough!
>>>
>>> > Really, that's the one particular engineer decision I regret. Just
>>> one. But
>>> > that's a big one. Because sometimes, almost ENTIRE teams prefer the
>>> Allman
>>> > style. That's not just a personal affair.
>>>
>>> This is yours strictly personal affair. Through this all thread you
>>> *demand*
>>> from the go team and the community to design, write and maintain tools
>>> for
>>> functionality *only you personally* deem important. More - you *demand*
>>> from
>>> us __thousands and millions of hours of compile time__ because *you* want
>>> your tastes satisfied.
>>>
>>> Stop whining and *do instrument* your editor with s/(\S\s*)}\s*$/\1\n}/.
>>> In C++ or java or ecmascript or...
>>> It is You who need this style so make your environment allow it. Its
>>> easy.
>>> (It was common in times we were paid by LOC but had 22 usable screen
>>> lines).
>>>
>>> If above instrumentation is beyond your allman-loving team competence why
>>> and *HOW* do you want to program anything usable to others?
>>>
>>> > All that because maybe 2 or 3 languages designers have decided so,
>>> > moreover to make it easy to automatically add the semi-colons.
>>>
>>> They gave it to you for free. It is open source. So
>>>
>>>  *FORK*
>>>
>>>   Tailor to your tastes! Make ponies dance!
>>>
>>>  > And it doesn't even work well, we are now force to put a useless comma
>>> > after the last parameter of a function to be allowed to split the
>>> arguments
>>> > on several lines. Please don't insult me by telling there wasn't any
>>> other
>>> > possible solution.
>>>
>>> *FORK* !!! Do better.
>>>
>>> [\APM]
>>>
>>> --
>>> Wojciech S. Czarnecki
>>>  << ^oo^ >> OHIR-RIPE
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/golang-nuts/rzLzp_Z74ik/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts...@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.
>

-- 
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] Re: No Allman-Style, No go!

[ecstatic . coder]

Anyway, even if I was a bit angry by the "ad personam" attack, I want to 
say that  even if the Go compiler maintainers don't or can't fix this 
because of their semi-colon insertion algorithm, it's not a problem for me 
to use Go as it is.

As I develop in Helix, now I don't care about that anymore, and this 
language only exists because Go is such a fantastic compilation target for 
language compilers and preprocessors.

As I said, I'm really grateful to Google and its management to have 
open-sourced their internal technology, which I appreciate a lot, even if I 
don't agree with every decision they made.

I know why they did it, as they have explained it (hiring young engineers, 
etc), and I understand their decision, even if I regret they didn't make it 
optional for the rest of the planet.

Moreover, it's because of these little "details" that I looked for an 
alternative, and started using D, which is a kind of "Go done well" for me, 
even if I clearly see that as a community project without any financial 
funding, D will never be able to compete on the same grounds as Go.

So again, thanks to Google for their great job with Go, and also for their 
nice open-source policy. 

On Sunday, July 30, 2017 at 9:36:26 AM UTC+1, ohir wrote:
>
> On Sat, 29 Jul 2017 16:56:05 -0700 (PDT) 
> ecstati...@gmail.com  wrote: 
>
> > Anyway, thanks for the fun. Where is the popcorn ? LOL 
>
>Q.E.D. 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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] Re: No Allman-Style, No go!

[ecstatic . coder]

Personally I'd prefer a simple compiler option :)

On Sunday, July 30, 2017 at 12:50:55 AM UTC+1, Hrobjartur Thorsteinsson 
wrote:
>
> Dude, you are right. This confusing coding style with syntax in Go can be 
> fixed by forking and applying a rediculously small patch. Jeez, lets stop 
> complaining as u rightfully suggested.
>
> 29. júl. 2017 10:43 e.h. skrifaði "Wojciech S. Czarnecki" <
> oh...@fairbe.org >:
>
>> On Sat, 29 Jul 2017 10:36:42 -0700 (PDT)
>> ecstati...@gmail.com  wrote:
>>
>> [APM]
>> [Ad Personam mode on, I humbly apologize to bystanders]
>>
>> Enough is enough!
>>
>> > Really, that's the one particular engineer decision I regret. Just one. 
>> But
>> > that's a big one. Because sometimes, almost ENTIRE teams prefer the 
>> Allman
>> > style. That's not just a personal affair.
>>
>> This is yours strictly personal affair. Through this all thread you 
>> *demand*
>> from the go team and the community to design, write and maintain tools for
>> functionality *only you personally* deem important. More - you *demand* 
>> from
>> us __thousands and millions of hours of compile time__ because *you* want
>> your tastes satisfied.
>>
>> Stop whining and *do instrument* your editor with s/(\S\s*)}\s*$/\1\n}/.
>> In C++ or java or ecmascript or...
>> It is You who need this style so make your environment allow it. Its easy.
>> (It was common in times we were paid by LOC but had 22 usable screen
>> lines).
>>
>> If above instrumentation is beyond your allman-loving team competence why
>> and *HOW* do you want to program anything usable to others?
>>
>> > All that because maybe 2 or 3 languages designers have decided so,
>> > moreover to make it easy to automatically add the semi-colons.
>>
>> They gave it to you for free. It is open source. So
>>
>>  *FORK*
>>
>>   Tailor to your tastes! Make ponies dance!
>>
>>  > And it doesn't even work well, we are now force to put a useless comma
>> > after the last parameter of a function to be allowed to split the 
>> arguments
>> > on several lines. Please don't insult me by telling there wasn't any 
>> other
>> > possible solution.
>>
>> *FORK* !!! Do better.
>>
>> [\APM]
>>
>> --
>> Wojciech S. Czarnecki
>>  << ^oo^ >> OHIR-RIPE
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@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] Re: No Allman-Style, No go!

[ecstatic . coder]

LOL ;)

On Sunday, July 30, 2017 at 9:36:26 AM UTC+1, ohir wrote:
>
> On Sat, 29 Jul 2017 16:56:05 -0700 (PDT) 
> ecstati...@gmail.com  wrote: 
>
> > Anyway, thanks for the fun. Where is the popcorn ? LOL 
>
>Q.E.D. 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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] Re: No Allman-Style, No go!

[Wojciech S. Czarnecki]

On Sat, 29 Jul 2017 16:56:05 -0700 (PDT)
ecstatic.co...@gmail.com wrote:

> Anyway, thanks for the fun. Where is the popcorn ? LOL

   Q.E.D.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] Re: No Allman-Style, No go!

[ecstatic . coder]

Ok, I can agree with you.

But the only problem is that often, the reason why many developers *decide* 
to switch from the K&R to Allman at some point in their career (like me) is 
because they think that sparing these few lines in code height to the price 
of breaking the blocks natural alignment actually hurts the code 
readability.

If there are roughly as many Allman style coders as K&R style coders, this 
means that there are also roughly as many people who think that K&R harms 
the readability by breaking the block alignment than people who think it 
improves the readability by compacting the code. 

Even if you think this is questionable, please at least respect the half of 
us who think that readability is improved by this alternative style.

Because, if this style had no readability advantage for us, why would we 
want so much to use it, you really think we are that stupid, seriously ?

On Saturday, July 29, 2017 at 9:14:50 PM UTC+1, Jan Mercl 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.

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

[ecstatic . coder]

Without apologies, I am linking to the official Google survey... LOL

What changes would improve Go most ?
#1. 572 (16%) generics

(https://blog.golang.org/survey2016-results)

Whoops ;)

So you mean that 16% of us are so stupid we don't want to copy paste the 
code and adjust it, or use slowinterfaces ?

Btw, just a silly question, but I wrongly assumed that a direct call to 
instantiated type-specific code was much faster than an indirect call to an 
interface. 

So you mean that  the following code is much faster than type-specific 
code, right, and therefore this is the adviced way to format variables ?

var i interface{} = 23
fmt.Printf("%v\n", i)

(https://golang.org/pkg/fmt/)

OMG, that's really great, thanks !!! Because it was quite error prone to 
copy-paste the repeated code and adjust it manually. Thank you so much, you 
made my day :)

I was so stupid, thanks for showing my the right way to optimize reused 
code.

On Sunday, July 30, 2017 at 12:02:04 AM UTC+1, Shawn Milochik wrote:

Without apologies, I am linking to a post I wrote seconds ago regarding 
> generics. 
>
> It applies here equally. Perhaps more so, since the percentage of 
> brace-complainers is a tiny fraction of the percentage of generics-whiners:
> https://groups.google.com/d/msg/golang-nuts/hQiZsd1ZRdA/DSgV7CX7BwAJ
>
>
>

-- 
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] Re: No Allman-Style, No go!

[ecstatic . coder]

LOL, obviously you haven't read my previous posts ;)

Ok, I'll repeat it then, no problem. I'm actually the developer of an open 
source preprocessor (Genesis) that can also be used to add Allman style and 
pseudo-generics to Go.

And internally I also use a templating language similar to PHP (Helix) 
which emit Go code in a way similar to my Phoenix language.

Anyway, thanks for the fun. Where is the popcorn ? LOL

On Saturday, July 29, 2017 at 11:43:52 PM UTC+1, ohir wrote:
>
> On Sat, 29 Jul 2017 10:36:42 -0700 (PDT) 
> ecstati...@gmail.com  wrote: 
>
> [APM] 
> [Ad Personam mode on, I humbly apologize to bystanders] 
>
> Enough is enough! 
>
> > Really, that's the one particular engineer decision I regret. Just one. 
> But 
> > that's a big one. Because sometimes, almost ENTIRE teams prefer the 
> Allman 
> > style. That's not just a personal affair. 
>
> This is yours strictly personal affair. Through this all thread you 
> *demand* 
> from the go team and the community to design, write and maintain tools for 
> functionality *only you personally* deem important. More - you *demand* 
> from 
> us __thousands and millions of hours of compile time__ because *you* want 
> your tastes satisfied. 
>
> Stop whining and *do instrument* your editor with s/(\S\s*)}\s*$/\1\n}/. 
> In C++ or java or ecmascript or... 
> It is You who need this style so make your environment allow it. Its easy. 
> (It was common in times we were paid by LOC but had 22 usable screen 
> lines). 
>
> If above instrumentation is beyond your allman-loving team competence why 
> and *HOW* do you want to program anything usable to others? 
>
> > All that because maybe 2 or 3 languages designers have decided so, 
> > moreover to make it easy to automatically add the semi-colons. 
>
> They gave it to you for free. It is open source. So 
>
>  *FORK* 
>
>   Tailor to your tastes! Make ponies dance! 
>
>  > And it doesn't even work well, we are now force to put a useless comma 
> > after the last parameter of a function to be allowed to split the 
> arguments 
> > on several lines. Please don't insult me by telling there wasn't any 
> other 
> > possible solution. 
>
> *FORK* !!! Do better. 
>
> [\APM] 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

Dude, you are right. This confusing coding style with syntax in Go can be
fixed by forking and applying a rediculously small patch. Jeez, lets stop
complaining as u rightfully suggested.

29. júl. 2017 10:43 e.h. skrifaði "Wojciech S. Czarnecki" :

> On Sat, 29 Jul 2017 10:36:42 -0700 (PDT)
> ecstatic.co...@gmail.com wrote:
>
> [APM]
> [Ad Personam mode on, I humbly apologize to bystanders]
>
> Enough is enough!
>
> > Really, that's the one particular engineer decision I regret. Just one.
> But
> > that's a big one. Because sometimes, almost ENTIRE teams prefer the
> Allman
> > style. That's not just a personal affair.
>
> This is yours strictly personal affair. Through this all thread you
> *demand*
> from the go team and the community to design, write and maintain tools for
> functionality *only you personally* deem important. More - you *demand*
> from
> us __thousands and millions of hours of compile time__ because *you* want
> your tastes satisfied.
>
> Stop whining and *do instrument* your editor with s/(\S\s*)}\s*$/\1\n}/.
> In C++ or java or ecmascript or...
> It is You who need this style so make your environment allow it. Its easy.
> (It was common in times we were paid by LOC but had 22 usable screen
> lines).
>
> If above instrumentation is beyond your allman-loving team competence why
> and *HOW* do you want to program anything usable to others?
>
> > All that because maybe 2 or 3 languages designers have decided so,
> > moreover to make it easy to automatically add the semi-colons.
>
> They gave it to you for free. It is open source. So
>
>  *FORK*
>
>   Tailor to your tastes! Make ponies dance!
>
>  > And it doesn't even work well, we are now force to put a useless comma
> > after the last parameter of a function to be allowed to split the
> arguments
> > on several lines. Please don't insult me by telling there wasn't any
> other
> > possible solution.
>
> *FORK* !!! Do better.
>
> [\APM]
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: No Allman-Style, No go!

[Shawn Milochik]

Without apologies, I am linking to a post I wrote seconds ago regarding
generics.

It applies here equally. Perhaps more so, since the percentage of
brace-complainers is a tiny fraction of the percentage of generics-whiners:
https://groups.google.com/d/msg/golang-nuts/hQiZsd1ZRdA/DSgV7CX7BwAJ

-- 
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] Re: No Allman-Style, No go!

[Wojciech S. Czarnecki]

On Sat, 29 Jul 2017 10:36:42 -0700 (PDT)
ecstatic.co...@gmail.com wrote:

[APM]
[Ad Personam mode on, I humbly apologize to bystanders]

Enough is enough!

> Really, that's the one particular engineer decision I regret. Just one. But 
> that's a big one. Because sometimes, almost ENTIRE teams prefer the Allman 
> style. That's not just a personal affair.

This is yours strictly personal affair. Through this all thread you *demand*
from the go team and the community to design, write and maintain tools for
functionality *only you personally* deem important. More - you *demand* from
us __thousands and millions of hours of compile time__ because *you* want
your tastes satisfied.

Stop whining and *do instrument* your editor with s/(\S\s*)}\s*$/\1\n}/.
In C++ or java or ecmascript or... 
It is You who need this style so make your environment allow it. Its easy.
(It was common in times we were paid by LOC but had 22 usable screen
lines).

If above instrumentation is beyond your allman-loving team competence why
and *HOW* do you want to program anything usable to others?

> All that because maybe 2 or 3 languages designers have decided so,
> moreover to make it easy to automatically add the semi-colons.

They gave it to you for free. It is open source. So

 *FORK* 

  Tailor to your tastes! Make ponies dance!

 > And it doesn't even work well, we are now force to put a useless comma 
> after the last parameter of a function to be allowed to split the arguments 
> on several lines. Please don't insult me by telling there wasn't any other 
> possible solution.

*FORK* !!! Do better.

[\APM]

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] Re: No Allman-Style, No go!

[Jan Mercl]

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.

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

[Michael Jones]

I understand you now.

On Sat, Jul 29, 2017 at 10:36 AM  wrote:

> Sorry to repeat myself, but I think I wasn't clear enough, as many people
> on this forum still don't understand my point at all.
>
> Google, as ANY company, MUST force its employees to use exactly the same
> standards.
>
> I've done the same with the engineers in my company. And they used my own
> code formatting tool.
>
> And I'm glad to Google that their management decided to let us use their
> compiler and their other internal tools, including Gofmt.
>
> 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 ?
>
> Really, that's the one particular engineer decision I regret. Just one.
> But that's a big one. Because sometimes, almost ENTIRE teams prefer the
> Allman style. That's not just a personal affair. All that because maybe 2
> or 3 languages designers have decided so, moreover to make it easy to
> automatically add the semi-colons.
>
> And it doesn't even work well, we are now force to put a useless comma
> after the last parameter of a function to be allowed to split the arguments
> on several lines. Please don't insult me by telling there wasn't any other
> possible solution.
>
>
> For instance, in Javascript, the semi-colon are also optional, but the
> compiler lets you use whatever coding style you want.
>
> You can then use a tool like Gofmt to fix it automatically. There is one
> such tool on my github account btw.
>
> On Friday, July 28, 2017 at 6:14:01 AM UTC+1, Ian Lance Taylor wrote:
>
>> On Thu, Jul 27, 2017 at 6:35 PM, Hrobjartur Thorsteinsson
>>
>  wrote:
>> >
>> > Do you realize that the Go lang devs themselves are not actually in
>> > agreement about the original motivations for constraining the language
>> in
>> > this way. Some quote some one true K&R style, while it is in fact this
>> is
>> > not K&R style, other quote some dubious statistics on programmer
>> habbits
>> > with code blocks, and yet other quote that it's just to help the
>> Go-lang
>> > compiler meta-compile statement delimiters ";".  All this confusion and
>> > effort for nothing, and all the while ignoring some real bad
>> programming
>> > habits, I guess in the name of liberty... or one day they will
>> eventually
>> > arbitrate what is good and bad in those areas too.
>> >
>> > Could it be that Go lang devs created an inflexibility, a storm in a
>> > tea-cup, for no real good reason. Such things have happened in software
>> > before.
>>
>> I doubt there is any significant disagreement among the core Go
>> developers about the gofmt choices for brace placements.  The reasons
>> are 1) it doesn't matter, gofmt just has to make a choice; 2) the
>> choice works well with lexical semicolon insertion.
>>
>> Ian
>>
> --
> 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.
>
-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
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] Re: No Allman-Style, No go!

[ecstatic . coder]

Sorry to repeat myself, but I think I wasn't clear enough, as many people 
on this forum still don't understand my point at all. 

Google, as ANY company, MUST force its employees to use exactly the same 
standards.

I've done the same with the engineers in my company. And they used my own 
code formatting tool.

And I'm glad to Google that their management decided to let us use their 
compiler and their other internal tools, including Gofmt.

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 ?

Really, that's the one particular engineer decision I regret. Just one. But 
that's a big one. Because sometimes, almost ENTIRE teams prefer the Allman 
style. That's not just a personal affair. All that because maybe 2 or 3 
languages designers have decided so, moreover to make it easy to 
automatically add the semi-colons.

And it doesn't even work well, we are now force to put a useless comma 
after the last parameter of a function to be allowed to split the arguments 
on several lines. Please don't insult me by telling there wasn't any other 
possible solution.

For instance, in Javascript, the semi-colon are also optional, but the 
compiler lets you use whatever coding style you want.

You can then use a tool like Gofmt to fix it automatically. There is one 
such tool on my github account btw.

On Friday, July 28, 2017 at 6:14:01 AM UTC+1, Ian Lance Taylor wrote:
>
> On Thu, Jul 27, 2017 at 6:35 PM, Hrobjartur Thorsteinsson 
> > wrote: 
> > 
> > Do you realize that the Go lang devs themselves are not actually in 
> > agreement about the original motivations for constraining the language 
> in 
> > this way. Some quote some one true K&R style, while it is in fact this 
> is 
> > not K&R style, other quote some dubious statistics on programmer habbits 
> > with code blocks, and yet other quote that it's just to help the Go-lang 
> > compiler meta-compile statement delimiters ";".  All this confusion and 
> > effort for nothing, and all the while ignoring some real bad programming 
> > habits, I guess in the name of liberty... or one day they will 
> eventually 
> > arbitrate what is good and bad in those areas too. 
> > 
> > Could it be that Go lang devs created an inflexibility, a storm in a 
> > tea-cup, for no real good reason. Such things have happened in software 
> > before. 
>
> I doubt there is any significant disagreement among the core Go 
> developers about the gofmt choices for brace placements.  The reasons 
> are 1) it doesn't matter, gofmt just has to make a choice; 2) the 
> choice works well with lexical semicolon insertion. 
>
> Ian 
>

-- 
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] Re: No Allman-Style, No go!

[Ian Lance Taylor]

On Thu, Jul 27, 2017 at 6:35 PM, Hrobjartur Thorsteinsson
 wrote:
>
> Do you realize that the Go lang devs themselves are not actually in
> agreement about the original motivations for constraining the language in
> this way. Some quote some one true K&R style, while it is in fact this is
> not K&R style, other quote some dubious statistics on programmer habbits
> with code blocks, and yet other quote that it's just to help the Go-lang
> compiler meta-compile statement delimiters ";".  All this confusion and
> effort for nothing, and all the while ignoring some real bad programming
> habits, I guess in the name of liberty... or one day they will eventually
> arbitrate what is good and bad in those areas too.
>
> Could it be that Go lang devs created an inflexibility, a storm in a
> tea-cup, for no real good reason. Such things have happened in software
> before.

I doubt there is any significant disagreement among the core Go
developers about the gofmt choices for brace placements.  The reasons
are 1) it doesn't matter, gofmt just has to make a choice; 2) the
choice works well with lexical semicolon insertion.

Ian

-- 
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] Re: No Allman-Style, No go!

[Dan Kortschak]

Lovely post, Michael, as usual.

http://photobucket.com/gallery/user/Clayskater/media/bWVkaWFJZDoxNzA1MjQzMDM=/

I ran out of pop-corn for this thread some years ago. Does anyone know
where I can get some more? It must be butter soaked, cooked over coals
and served in a silver tureen, otherwise I won't touch it.

On Thu, 2017-07-27 at 13:38 -0700, Michael Jones wrote:
> Ecstatic, based on what you said here (*"some people will never be
> forced...

-- 
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] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

This suggestion the funniest I have seen in any language:

/*--*/

if x < 0 {
{
return sqrt(-x) + "i"
}}

/*-*/

Credit is "Neutrino" posted in 2014 on Stackoverflow. This is what I
was looking for!
Thank you Neutrino, both Go-style and Allman style fetished devs can
now live in harmony.


On Fri, Jul 28, 2017 at 2:06 AM, John Souvestre  wrote:

> Cognitive dissonance  J
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> *On Behalf Of *Michael Jones
> *Sent:* 2017 July 27, Thu 15:38
> *To:* Rob Pike
> *Cc:* Ecstatic Coder; golang-nuts
> *Subject:* Re: [go-nuts] Re: No Allman-Style, No go!
>
>
>
> Ecstatic, based on what you said here (*"some people will never be forced
> to change"* and *"because Google engineers have decided"*), I believe
> there are a few ideas you may profitably consider about the formatting
> topic--ideas that you probably have not yet considered and which may ease
> your concerns.
>
>
>
> FIRSTLY, there are probably people who would absolutely refuse to visit
> the United Kingdom because *"they will never be forced to drive on the
> wrong side of the road."* Or perhaps, they would visit, but would drive
> on *"the right side show those silly UK people see how we do it at home."* 
> Some,
> but not many, because most people understand that being in a society of
> people who drive on one side of the road is best embraced by sharing that
> same side. This has nothing to do with anyone's opinion about which side is
> truly and naturally the best and wisest side to drive on. It is instead
> about driving effectively as an ensemble rather than alone as an isolated
> individual.
>
>
>
> As surprising as it may be, this is a very similar to the situation with
> the style gofmt implements (*which side of the road*) and the reason that
> whatever style it is is considered important by other developers (*the
> other drivers*). Now, this is all in the context of more than one
> developer (one car/one driver). If you build a private road at your estate
> than you're surely welcome to drive on either side, down the middle, or
> even to weave back and forth in a sinusoidal pattern. Whatever makes you
> happy. Whatever you see as the "one true way." The idea of fitting in for
> the purpose of mutual survival or efficiency is not at play when you are
> alone.
>
>
>
> Maybe you program alone. Maybe nobody else sees your code. Maybe you do
> not wish to import and examine the code of others nor export code of your
> own. If so, this entire thread is not really meant for you. However...
>
>
>
> SECONDARIALY, one of the most important aspects of being a Google
> [software] engineer is the reality of working in a multi-hundred million
> line source code, with 10,000+ other programmers, and having every line of
> code reviewed by other developers before checkin. (Important, but not
> unique--same at IBM, Oracle, Microsoft, Apple, ...) In this kind of
> professional team development environment, the efficiency of code reuse, of
> quickly understanding the code of others, and of avoiding false source code
> deltas based in stylistic changes is paramount. Google started in a garage,
> but did not stay there. This attention to working as a team, grew with the
> company as it does in other large, effective software teams.
>
>
>
> To the extent that a "common style has been forced because Google
> engineers decided," it is actually the case that "Google engineers were
> forced by scale to accept a common format." Not that they are victims, just
> that like drivers and modern society, they grew weary of needless traffic
> jams, accidents, and injuries. I've travelled very long distances in India,
> for example, where there are often no lane markers on roads and people
> drive on whatever part they like. With such kind people it works well in
> the country, but in the cities where congestion reaches a critical mass, it
> seems to work spectacularly poorly.
>
>
>
> The rigidity that frustrates you is the price of society, of easy code
> review and understanding; it is not, as some presume, a declaration of a
> "best" way to indent. Rather it is an example of a "best way to collaborate
> at scale" which is just the kind of situation where Go intends to solve
> existing problems.
>
>
>
> My views, not Google's.
>
>
>
>
>
>
>
> On Thu, Jul 27, 2017 at 5:34 AM, Rob Pike  wrote:
>
> Very few, though. Very few.
>
>
>
> As the proverb says:
>
>
&

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

[John Souvestre]

Cognitive dissonance  J

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Michael Jones
Sent: 2017 July 27, Thu 15:38
To: Rob Pike
Cc: Ecstatic Coder; golang-nuts
Subject: Re: [go-nuts] Re: No Allman-Style, No go!

 

Ecstatic, based on what you said here ("some people will never be forced to 
change" and "because Google engineers have decided"), I believe there are a few 
ideas you may profitably consider about the formatting topic--ideas that you 
probably have not yet considered and which may ease your concerns.

 

FIRSTLY, there are probably people who would absolutely refuse to visit the 
United Kingdom because "they will never be forced to drive on the wrong side of 
the road." Or perhaps, they would visit, but would drive on "the right side 
show those silly UK people see how we do it at home." Some, but not many, 
because most people understand that being in a society of people who drive on 
one side of the road is best embraced by sharing that same side. This has 
nothing to do with anyone's opinion about which side is truly and naturally the 
best and wisest side to drive on. It is instead about driving effectively as an 
ensemble rather than alone as an isolated individual.

 

As surprising as it may be, this is a very similar to the situation with the 
style gofmt implements (which side of the road) and the reason that whatever 
style it is is considered important by other developers (the other drivers). 
Now, this is all in the context of more than one developer (one car/one 
driver). If you build a private road at your estate than you're surely welcome 
to drive on either side, down the middle, or even to weave back and forth in a 
sinusoidal pattern. Whatever makes you happy. Whatever you see as the "one true 
way." The idea of fitting in for the purpose of mutual survival or efficiency 
is not at play when you are alone.

 

Maybe you program alone. Maybe nobody else sees your code. Maybe you do not 
wish to import and examine the code of others nor export code of your own. If 
so, this entire thread is not really meant for you. However...

 

SECONDARIALY, one of the most important aspects of being a Google [software] 
engineer is the reality of working in a multi-hundred million line source code, 
with 10,000+ other programmers, and having every line of code reviewed by other 
developers before checkin. (Important, but not unique--same at IBM, Oracle, 
Microsoft, Apple, ...) In this kind of professional team development 
environment, the efficiency of code reuse, of quickly understanding the code of 
others, and of avoiding false source code deltas based in stylistic changes is 
paramount. Google started in a garage, but did not stay there. This attention 
to working as a team, grew with the company as it does in other large, 
effective software teams.

 

To the extent that a "common style has been forced because Google engineers 
decided," it is actually the case that "Google engineers were forced by scale 
to accept a common format." Not that they are victims, just that like drivers 
and modern society, they grew weary of needless traffic jams, accidents, and 
injuries. I've travelled very long distances in India, for example, where there 
are often no lane markers on roads and people drive on whatever part they like. 
With such kind people it works well in the country, but in the cities where 
congestion reaches a critical mass, it seems to work spectacularly poorly.

 

The rigidity that frustrates you is the price of society, of easy code review 
and understanding; it is not, as some presume, a declaration of a "best" way to 
indent. Rather it is an example of a "best way to collaborate at scale" which 
is just the kind of situation where Go intends to solve existing problems.

 

My views, not Google's.

 

 

 

On Thu, Jul 27, 2017 at 5:34 AM, Rob Pike  wrote:

Very few, though. Very few.

 

As the proverb says:

 


 <https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s> Gofmt's style is no 
one's favorite, yet gofmt is everyone's favorite.


 

-rob

 

 

On Thu, Jul 27, 2017 at 6:49 PM, Ecstatic Coder  
wrote:

Btw please don't take it personally. What I'm saying is that indeed some people 
(including me as you see) WILL NEVER agree to be forced to change their coding 
style because Google engineers have decided so, but that doesn't mean we should 
stay away from go just because of our mental incapacity to agree on that.

 

On Thu, Jul 27, 2017 at 9:32 AM,  wrote:

I don't know if you have read this post above :

"BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K&R and allows genericity by 
parametric instantiation.

https://github.com/sense

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

[Hrobjartur Thorsteinsson]

That's true, so it would be more useful in C than in Go.
However, please everybody stop calling it K&R style, because it is not.

On Fri, Jul 28, 2017 at 1:54 AM, John Souvestre  wrote:

> Ø  Btw here are the result of a small internet poll on indentation styles
> :
>
> - Allman : 7450 votes
> - K&R style : 5514 votes
>
> Ø  …
>
>
>
> I have to wonder if a person’s choice of style might depend on which
> language they are using.  For example, I might prefer Allman while working
> in C but K&R while working in Go.  The deciding factor being that Go always
> uses a block for if’s, while C (if memory serves) uses either a single
> statement or a block.  Thus, when scanning the code quickly, seeing the
> opening brace doesn’t add any info to my understanding of what takes place
> in Go while it would in C.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> *On Behalf Of *ecstatic.co...@gmail.com
> *Sent:* 2017 July 27, Thu 03:33
> *To:* golang-nuts
> *Cc:* yout...@z505.com
> *Subject:* Re: [go-nuts] Re: No Allman-Style, No go!
>
>
>
> I don't know if you have read this post above :
>
> "BTW, I've just released Genesis, an open source generic preprocessor
> which automatically converts Allman style code into K&R and allows
> genericity by parametric instantiation.
>
> https://github.com/senselogic/GENESIS
>
> Better late than never... ;)"
>
> Obviously, I don't like AT ALL the K&R style, to which I prefer the Allman
> style, for not only personal but also OBJECTIVE reasons.
>
> And yet I've learned Go and enjoy a lot to use this language, despite this
> implies using an external tool to add genericity and fix the code
> indentation.
>
> Btw here are the result of a small internet poll on indentation styles :
>
> - Allman : 7450 votes
> - K&R style : 5514 votes
> - Whitesmith : 455
> - GNU : 422
> - Horstman : 131
> - Pico : 93
> - Banner : 243
>
> (http://www.terminally-incoherent.com/blog/2009/04/
> 10/the-only-correct-indent-style)
>
> Even if these 14000 votes are obviously not enough to reflect the whole
> development community, at least you can see here that many developers
> prefer the Allman style to the K&R style.
>
> So sorry, but I completely disagree with your advice to stay away from Go
> if you don't like its forced indentation style policy.
>
> It's not only too radical, but also not needed, as there are already tools
> to fix that issue.
>
> On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>
> I propose a new rule for our Code of Conduct: Before posting to the "No
> Allman-Style, No go!" thread, you shall read and understand all previous
> posts in the aforementioned thread.
>
>
>
> Justo to be clear: Go indentation style is a time saver. It was carefuly
> crafted to piss some people off.  As you can see, it works wonders. If
> someone can't handle a simple change in indentation style, then she has no
> business trying to learn Go, so she quits, thus saving time.
>
> --
> 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 a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: No Allman-Style, No go!

[John Souvestre]

Ø  Btw here are the result of a small internet poll on indentation styles :

- Allman : 7450 votes
- K&R style : 5514 votes

Ø  …

 

I have to wonder if a person’s choice of style might depend on which language 
they are using.  For example, I might prefer Allman while working in C but K&R 
while working in Go.  The deciding factor being that Go always uses a block for 
if’s, while C (if memory serves) uses either a single statement or a block.  
Thus, when scanning the code quickly, seeing the opening brace doesn’t add any 
info to my understanding of what takes place in Go while it would in C.

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of ecstatic.co...@gmail.com
Sent: 2017 July 27, Thu 03:33
To: golang-nuts
Cc: yout...@z505.com
Subject: Re: [go-nuts] Re: No Allman-Style, No go!

 

I don't know if you have read this post above :

"BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K&R and allows genericity by 
parametric instantiation.

https://github.com/senselogic/GENESIS

Better late than never... ;)"

Obviously, I don't like AT ALL the K&R style, to which I prefer the Allman 
style, for not only personal but also OBJECTIVE reasons.

And yet I've learned Go and enjoy a lot to use this language, despite this 
implies using an external tool to add genericity and fix the code indentation.

Btw here are the result of a small internet poll on indentation styles :

- Allman : 7450 votes
- K&R style : 5514 votes
- Whitesmith : 455
- GNU : 422
- Horstman : 131
- Pico : 93
- Banner : 243

(http://www.terminally-incoherent.com/blog/2009/04/10/the-only-correct-indent-style)

Even if these 14000 votes are obviously not enough to reflect the whole 
development community, at least you can see here that many developers prefer 
the Allman style to the K&R style.

So sorry, but I completely disagree with your advice to stay away from Go if 
you don't like its forced indentation style policy.

It's not only too radical, but also not needed, as there are already tools to 
fix that issue.

On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:

I propose a new rule for our Code of Conduct: Before posting to the "No 
Allman-Style, No go!" thread, you shall read and understand all previous posts 
in the aforementioned thread.

 

Justo to be clear: Go indentation style is a time saver. It was carefuly 
crafted to piss some people off.  As you can see, it works wonders. If someone 
can't handle a simple change in indentation style, then she has no business 
trying to learn Go, so she quits, thus saving time.

-- 
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] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

but, I have to say, wow,
I never realized that curly bracket placement was that important and solved
so many of the problems for Google!

Do you realize that the Go lang devs themselves are not actually in
agreement about the original motivations for constraining the language in
this way. Some quote some one true K&R style, while it is in fact this is
not K&R style, other quote some dubious statistics on programmer habbits
with code blocks, and yet other quote that it's just to help the Go-lang
compiler meta-compile statement delimiters ";".  All this confusion and
effort for nothing, and all the while ignoring some real bad programming
habits, I guess in the name of liberty... or one day they will eventually
arbitrate what is good and bad in those areas too.

Could it be that Go lang devs created an inflexibility, a storm in a
tea-cup, for no real good reason. Such things have happened in software
before.

On Fri, Jul 28, 2017 at 12:19 AM, Matt Harden  wrote:

> "me": regarding purely functional programs, they can exist, but they can't
> actually "do" anything, since by definition, "doing" means altering some
> state in the outside world. But reasoning as much as possible in a
> functional way, and expressing your programs in this way (again as much as
> possible), turns out to be very effective, because reasoning about a
> virtually limitless amount of shared state is extraordinarily difficult,
> especially in a concurrent program.
>
> Your argument about the super creative programmer may be valid when you're
> talking about a single programmer. Good luck getting that programmer to
> operate as part of a team, especially if you expect everyone else on the
> team to behave the same way, *especially* if it is a large team. Even if
> they create their masterpiece in solitude, they're certain to tire of it
> later and leave it to someone else to maintain. Luckily we have gofmt, so
> we can reformat it when the team takes over, and they can effectively
> cooperate to maintain and improve the code. The maestro will gnash his
> teeth at this, but they will have more important things to work on by that
> point.
>
> Even the best, most creative architects must operate within bounds -
> buildings need to be safe; they need to satisfy government regulations;
> they need to be made using existing materials.
>
> Anyway, style has nothing to do with the actual program *content*. We're
> talking about elements that don't affect the behavior of the program. As
> has been pointed out, your super-creative programmer can write their own
> tool (in whatever style or language they want!) to translate programs from
> gofmt-formatted to their preferred style. Nobody even needs to know!
>
> On Thu, Jul 27, 2017 at 3:40 PM me  wrote:
>
>>
>> On Thursday, July 27, 2017 at 3:08:08 PM UTC-6, Jan Mercl wrote:
>>>
>>>
>>> Isn't it strange, that we, programmers, well used to model the problem
>>> once in term of CPU registers and raw memory, then in a pure functional
>>> style
>>>
>>
>> I don't know that purely functional actually exists: I have been trying
>> to crack this problem for ages: what exactly is pure functional?
>> As soon as a functional program has state (a println/print/puts statement
>> is the first warning), it is no longer purely functional IMO..
>>
>> But, it's a little off topic for this list... still, some functional
>> programming techniques exist in all programming languages, so still on
>> topic to some extent.
>>
>> 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)
>>
>> Still I like GoFmt - always provide a contrarian position
>>
>> --
>> 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 a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, 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 g

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

[Matt Harden]

"me": regarding purely functional programs, they can exist, but they can't
actually "do" anything, since by definition, "doing" means altering some
state in the outside world. But reasoning as much as possible in a
functional way, and expressing your programs in this way (again as much as
possible), turns out to be very effective, because reasoning about a
virtually limitless amount of shared state is extraordinarily difficult,
especially in a concurrent program.

Your argument about the super creative programmer may be valid when you're
talking about a single programmer. Good luck getting that programmer to
operate as part of a team, especially if you expect everyone else on the
team to behave the same way, *especially* if it is a large team. Even if
they create their masterpiece in solitude, they're certain to tire of it
later and leave it to someone else to maintain. Luckily we have gofmt, so
we can reformat it when the team takes over, and they can effectively
cooperate to maintain and improve the code. The maestro will gnash his
teeth at this, but they will have more important things to work on by that
point.

Even the best, most creative architects must operate within bounds -
buildings need to be safe; they need to satisfy government regulations;
they need to be made using existing materials.

Anyway, style has nothing to do with the actual program *content*. We're
talking about elements that don't affect the behavior of the program. As
has been pointed out, your super-creative programmer can write their own
tool (in whatever style or language they want!) to translate programs from
gofmt-formatted to their preferred style. Nobody even needs to know!

On Thu, Jul 27, 2017 at 3:40 PM me  wrote:

>
> On Thursday, July 27, 2017 at 3:08:08 PM UTC-6, Jan Mercl wrote:
>>
>>
>> Isn't it strange, that we, programmers, well used to model the problem
>> once in term of CPU registers and raw memory, then in a pure functional
>> style
>>
>
> I don't know that purely functional actually exists: I have been trying to
> crack this problem for ages: what exactly is pure functional?
> As soon as a functional program has state (a println/print/puts statement
> is the first warning), it is no longer purely functional IMO..
>
> But, it's a little off topic for this list... still, some functional
> programming techniques exist in all programming languages, so still on
> topic to some extent.
>
> 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)
>
> Still I like GoFmt - always provide a contrarian position
>
> --
> 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] Re: No Allman-Style, No go!

[me]

On Thursday, July 27, 2017 at 3:08:08 PM UTC-6, Jan Mercl wrote:
>
>
> Isn't it strange, that we, programmers, well used to model the problem 
> once in term of CPU registers and raw memory, then in a pure functional 
> style 
>

I don't know that purely functional actually exists: I have been trying to 
crack this problem for ages: what exactly is pure functional?
As soon as a functional program has state (a println/print/puts statement 
is the first warning), it is no longer purely functional IMO..

But, it's a little off topic for this list... still, some functional 
programming techniques exist in all programming languages, so still on 
topic to some extent.

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) 

Still I like GoFmt - always provide a contrarian position 

-- 
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] Re: No Allman-Style, No go!

[ojucie]

Ecstatic Coder, I won't take it personally, of course. Feel free to say 
anything you want to.

Michael, great post, as always. The driver illustration is perfect.

On Thursday, July 27, 2017 at 5:50:05 AM UTC-3, Ecstatic Coder wrote:
>
> Btw please don't take it personally. 
>

-- 
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] Re: No Allman-Style, No go!

[Jan Mercl]

On Thu, Jul 27, 2017 at 10:39 PM Michael Jones 
wrote:

> Ecstatic, ...

Excellent post!

Isn't it strange, that we, programmers, well used to model the problem once
in term of CPU registers and raw memory, then in a pure functional style
and then again in some imperative PL, to name just a few cases, can
sometime become so inflexible when it comes to such a minor detail as
indentation style? Even just the different grammars of different languages
are in orders of magnitude more complex to switch between - but we are
nearly universally able to do that almost instantly.


-- 

-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] Re: No Allman-Style, No go!

[Michael Jones]

Ecstatic, based on what you said here (*"some people will never be forced
to change"* and *"because Google engineers have decided"*), I believe there
are a few ideas you may profitably consider about the formatting
topic--ideas that you probably have not yet considered and which may ease
your concerns.

FIRSTLY, there are probably people who would absolutely refuse to visit the
United Kingdom because *"they will never be forced to drive on the wrong
side of the road."* Or perhaps, they would visit, but would drive on *"the
right side show those silly UK people see how we do it at home."* Some, but
not many, because most people understand that being in a society of people
who drive on one side of the road is best embraced by sharing that same
side. This has nothing to do with anyone's opinion about which side is
truly and naturally the best and wisest side to drive on. It is instead
about driving effectively as an ensemble rather than alone as an isolated
individual.

As surprising as it may be, this is a very similar to the situation with
the style gofmt implements (*which side of the road*) and the reason that
whatever style it is is considered important by other developers (*the
other drivers*). Now, this is all in the context of more than one developer
(one car/one driver). If you build a private road at your estate than
you're surely welcome to drive on either side, down the middle, or even to
weave back and forth in a sinusoidal pattern. Whatever makes you happy.
Whatever you see as the "one true way." The idea of fitting in for the
purpose of mutual survival or efficiency is not at play when you are alone.

Maybe you program alone. Maybe nobody else sees your code. Maybe you do not
wish to import and examine the code of others nor export code of your own.
If so, this entire thread is not really meant for you. However...

SECONDARIALY, one of the most important aspects of being a Google
[software] engineer is the reality of working in a multi-hundred million
line source code, with 10,000+ other programmers, and having every line of
code reviewed by other developers before checkin. (Important, but not
unique--same at IBM, Oracle, Microsoft, Apple, ...) In this kind of
professional team development environment, the efficiency of code reuse, of
quickly understanding the code of others, and of avoiding false source code
deltas based in stylistic changes is paramount. Google started in a garage,
but did not stay there. This attention to working as a team, grew with the
company as it does in other large, effective software teams.

To the extent that a "common style has been forced because Google engineers
decided," it is actually the case that "Google engineers were forced by
scale to accept a common format." Not that they are victims, just that like
drivers and modern society, they grew weary of needless traffic jams,
accidents, and injuries. I've travelled very long distances in India, for
example, where there are often no lane markers on roads and people drive on
whatever part they like. With such kind people it works well in the
country, but in the cities where congestion reaches a critical mass, it
seems to work spectacularly poorly.

The rigidity that frustrates you is the price of society, of easy code
review and understanding; it is not, as some presume, a declaration of a
"best" way to indent. Rather it is an example of a "best way to collaborate
at scale" which is just the kind of situation where Go intends to solve
existing problems.

My views, not Google's.



On Thu, Jul 27, 2017 at 5:34 AM, Rob Pike  wrote:

> Very few, though. Very few.
>
> As the proverb says:
>
> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
> 
>
> -rob
>
>
> On Thu, Jul 27, 2017 at 6:49 PM, Ecstatic Coder 
> wrote:
>
>> Btw please don't take it personally. What I'm saying is that indeed some
>> people (including me as you see) WILL NEVER agree to be forced to change
>> their coding style because Google engineers have decided so, but that
>> doesn't mean we should stay away from go just because of our mental
>> incapacity to agree on that.
>>
>> On Thu, Jul 27, 2017 at 9:32 AM,  wrote:
>>
>>> I don't know if you have read this post above :
>>>
>>> "BTW, I've just released Genesis, an open source generic preprocessor
>>> which automatically converts Allman style code into K&R and allows
>>> genericity by parametric instantiation.
>>>
>>> https://github.com/senselogic/GENESIS
>>>
>>> Better late than never... ;)"
>>>
>>> Obviously, I don't like AT ALL the K&R style, to which I prefer the
>>> Allman style, for not only personal but also OBJECTIVE reasons.
>>>
>>> And yet I've learned Go and enjoy a lot to use this language, despite
>>> this implies using an external tool to add genericity and fix the code
>>> indentation.
>>>
>>> Btw here are the result of a small internet poll on indentation styles :
>>>
>>> - Allman : 7450 votes
>>> - K&R style : 55

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

[Rob Pike]

Very few, though. Very few.

As the proverb says:

Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.


-rob


On Thu, Jul 27, 2017 at 6:49 PM, Ecstatic Coder 
wrote:

> Btw please don't take it personally. What I'm saying is that indeed some
> people (including me as you see) WILL NEVER agree to be forced to change
> their coding style because Google engineers have decided so, but that
> doesn't mean we should stay away from go just because of our mental
> incapacity to agree on that.
>
> On Thu, Jul 27, 2017 at 9:32 AM,  wrote:
>
>> I don't know if you have read this post above :
>>
>> "BTW, I've just released Genesis, an open source generic preprocessor
>> which automatically converts Allman style code into K&R and allows
>> genericity by parametric instantiation.
>>
>> https://github.com/senselogic/GENESIS
>>
>> Better late than never... ;)"
>>
>> Obviously, I don't like AT ALL the K&R style, to which I prefer the
>> Allman style, for not only personal but also OBJECTIVE reasons.
>>
>> And yet I've learned Go and enjoy a lot to use this language, despite
>> this implies using an external tool to add genericity and fix the code
>> indentation.
>>
>> Btw here are the result of a small internet poll on indentation styles :
>>
>> - Allman : 7450 votes
>> - K&R style : 5514 votes
>> - Whitesmith : 455
>> - GNU : 422
>> - Horstman : 131
>> - Pico : 93
>> - Banner : 243
>>
>> (http://www.terminally-incoherent.com/blog/2009/04/10/the-
>> only-correct-indent-style)
>>
>> Even if these 14000 votes are obviously not enough to reflect the whole
>> development community, at least you can see here that many developers
>> prefer the Allman style to the K&R style.
>>
>> So sorry, but I completely disagree with your advice to stay away from Go
>> if you don't like its forced indentation style policy.
>>
>> It's not only too radical, but also not needed, as there are already
>> tools to fix that issue.
>>
>>
>> On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>>>
>>> I propose a new rule for our Code of Conduct: Before posting to the "No
>>> Allman-Style, No go!" thread, you shall read and understand all previous
>>> posts in the aforementioned thread.
>>>
>>> Justo to be clear: Go indentation style is a time saver. It was carefuly
>>> crafted to piss some people off.  As you can see, it works wonders. If
>>> someone can't handle a simple change in indentation style, then she has no
>>> business trying to learn Go, so she quits, thus saving time.
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/golang-nuts/rzLzp_Z74ik/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>

-- 
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] Re: No Allman-Style, No go!

[Ecstatic Coder]

Btw please don't take it personally. What I'm saying is that indeed some
people (including me as you see) WILL NEVER agree to be forced to change
their coding style because Google engineers have decided so, but that
doesn't mean we should stay away from go just because of our mental
incapacity to agree on that.

On Thu, Jul 27, 2017 at 9:32 AM,  wrote:

> I don't know if you have read this post above :
>
> "BTW, I've just released Genesis, an open source generic preprocessor
> which automatically converts Allman style code into K&R and allows
> genericity by parametric instantiation.
>
> https://github.com/senselogic/GENESIS
>
> Better late than never... ;)"
>
> Obviously, I don't like AT ALL the K&R style, to which I prefer the Allman
> style, for not only personal but also OBJECTIVE reasons.
>
> And yet I've learned Go and enjoy a lot to use this language, despite this
> implies using an external tool to add genericity and fix the code
> indentation.
>
> Btw here are the result of a small internet poll on indentation styles :
>
> - Allman : 7450 votes
> - K&R style : 5514 votes
> - Whitesmith : 455
> - GNU : 422
> - Horstman : 131
> - Pico : 93
> - Banner : 243
>
> (http://www.terminally-incoherent.com/blog/2009/04/
> 10/the-only-correct-indent-style)
>
> Even if these 14000 votes are obviously not enough to reflect the whole
> development community, at least you can see here that many developers
> prefer the Allman style to the K&R style.
>
> So sorry, but I completely disagree with your advice to stay away from Go
> if you don't like its forced indentation style policy.
>
> It's not only too radical, but also not needed, as there are already tools
> to fix that issue.
>
>
> On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>>
>> I propose a new rule for our Code of Conduct: Before posting to the "No
>> Allman-Style, No go!" thread, you shall read and understand all previous
>> posts in the aforementioned thread.
>>
>> Justo to be clear: Go indentation style is a time saver. It was carefuly
>> crafted to piss some people off.  As you can see, it works wonders. If
>> someone can't handle a simple change in indentation style, then she has no
>> business trying to learn Go, so she quits, thus saving time.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: No Allman-Style, No go!

[ecstatic . coder]

I don't know if you have read this post above :

"BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K&R and allows genericity by 
parametric instantiation.

https://github.com/senselogic/GENESIS

Better late than never... ;)"

Obviously, I don't like AT ALL the K&R style, to which I prefer the Allman 
style, for not only personal but also OBJECTIVE reasons.

And yet I've learned Go and enjoy a lot to use this language, despite this 
implies using an external tool to add genericity and fix the code 
indentation.

Btw here are the result of a small internet poll on indentation styles :

- Allman : 7450 votes
- K&R style : 5514 votes
- Whitesmith : 455
- GNU : 422
- Horstman : 131
- Pico : 93
- Banner : 243

(http://www.terminally-incoherent.com/blog/2009/04/10/the-only-correct-indent-style)

Even if these 14000 votes are obviously not enough to reflect the whole 
development community, at least you can see here that many developers 
prefer the Allman style to the K&R style.

So sorry, but I completely disagree with your advice to stay away from Go 
if you don't like its forced indentation style policy.

It's not only too radical, but also not needed, as there are already tools 
to fix that issue.

On Wednesday, July 26, 2017 at 12:01:19 AM UTC+1, JuciÊ Andrade wrote:
>
> I propose a new rule for our Code of Conduct: Before posting to the "No 
> Allman-Style, No go!" thread, you shall read and understand all previous 
> posts in the aforementioned thread.
>
> Justo to be clear: Go indentation style is a time saver. It was carefuly 
> crafted to piss some people off.  As you can see, it works wonders. If 
> someone can't handle a simple change in indentation style, then she has no 
> business trying to learn Go, so she quits, thus saving time.
>

-- 
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] Re: No Allman-Style, No go!

[ojucie]

I propose a new rule for our Code of Conduct: Before posting to the "No 
Allman-Style, No go!" thread, you shall read and understand all previous 
posts in the aforementioned thread.

Justo to be clear: Go indentation style is a time saver. It was carefuly 
crafted to piss some people off.  As you can see, it works wonders. If 
someone can't handle a simple change in indentation style, then she has no 
business trying to learn Go, so she quits, thus saving time.

-- 
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] Re: No Allman-Style, No go!

[Hrobjartur Thorsteinsson]

On this last comment, I would like to comment,

Overall I agree with last commenter, the coolest programmer is the one that
does not have any quarrels about style, just gets along with the group and
helps get the job done.

That being said, golangs approach to braces a part of logical syntax is
unusual in comparison to other languages that use braces to encapsulate
code blocks.

Regarding source control diffs and spaces - I can in fact add loads of
spaces and newlines into my go code, and indeed it compiles and it does
show up in source diffs. I like spaces in my code in a similar way to how I
like to have paragraphs in essays I write. I would argue that everyone
likes to use spaces for clarity.

Python does not help the argument for the golang style in my opinion,
because Python encapsulates code blocks using indent, and just like other
languages you are allowed to put your new lines and white spaces wherever
you feel it helps. If you like add loads of silly new lines after you
conditionals, Python don't care, but pylint does. In python you can alo put
your code in a one-liner, or on a new line..., or spread a statement
between many lines. So I don't see that Python makes code encapsulation
syntactically a part of the conditional syntax like golang does.




On Sun, Jul 23, 2017 at 5:12 PM, me  wrote:

>
>
> On Saturday, July 22, 2017 at 4:59:04 AM UTC-6, ohir wrote:
>>
>>
>> Every development team has right to reformat source to their tastes on
>> the editor openfile then reformat to compiler taste on savefile.
>>
>
> Except, that some people are minimalists and don't use fancy editors that
> have all these bells and whistles...
>
> I find when you have an editor doing all kinds of tricks, it means the
> code is too hard to write and your editor is giving you a warning sign that
> what you are doing requires editor tricks, and that's bad.
>
> For example, if you are making your editor type out the word FUNCTION for
> you every time you hit "F" then maybe it would be better to change the
> language you are using, to make FUNCTION become "fn" or 'func"... so that
> you don't have to have your editor doing so many tricks.
>
> For the case of GoLang, one thing I do find annoying about gofmt is that
> very short IF ELSE blocks span multiple lines..
>
> if a
> x
> else
> y
>
> instead of on a single line. But, that's what gofmt is supposed to stop:
> debates about this.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/rzLzp_Z74ik/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: No Allman-Style, No go!

[me]

On Saturday, July 22, 2017 at 4:59:04 AM UTC-6, ohir wrote:
>
>
> Every development team has right to reformat source to their tastes on 
> the editor openfile then reformat to compiler taste on savefile. 
>
 
Except, that some people are minimalists and don't use fancy editors that 
have all these bells and whistles...

I find when you have an editor doing all kinds of tricks, it means the code 
is too hard to write and your editor is giving you a warning sign that what 
you are doing requires editor tricks, and that's bad.

For example, if you are making your editor type out the word FUNCTION for 
you every time you hit "F" then maybe it would be better to change the 
language you are using, to make FUNCTION become "fn" or 'func"... so that 
you don't have to have your editor doing so many tricks.

For the case of GoLang, one thing I do find annoying about gofmt is that 
very short IF ELSE blocks span multiple lines..

if a
x
else
y

instead of on a single line. But, that's what gofmt is supposed to stop: 
debates about this.

-- 
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] Re: No Allman-Style, No go!

[ecstatic . coder]

Nice idea, but unfortunately that was not easy to do with my favorite code 
editor (Geany).

That's why I've implemented a preprocessor (Genesis) which converts my 
Allmann-style files to Golang-style.

On Saturday, July 22, 2017 at 11:59:04 AM UTC+1, ohir wrote:
>
>
> Every development team has right to reformat source to their tastes on 
> the editor openfile then reformat to compiler taste on savefile. 
>

-- 
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] Re: No Allman-Style, No go!

[Wojciech S. Czarnecki]

On Fri, 21 Jul 2017 10:29:18 -0700 (PDT)
ecstatic.co...@gmail.com wrote:

> Every development team should have the right to freely choose which coding 
> standard they will enforce.

Every development team has right to reformat source to their tastes on
the editor openfile then reformat to compiler taste on savefile.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] Re: No Allman-Style, No go!

[Michael Jones]

This is a popular point of view in general (programming tools serve
programmers) and the natural and most free spirit of free-form programming
languages.

It turns out that there is a good argument--an evidence-based theory of
software development--that you might want to think about as you form your
opinion on the topic:

a. Programmers spend more time looking at other people's code than creating
their own. Naturally this is based on the kind of programmer. Single person
building single-use programs (such as school assignments) would not have
this character, but multiperson teams are like this and even single-person
code looks foreign after a few years.

b. Programmers spend more time studying API interface documentation than
coding. Again, true at Goolge, IBM, SAP, etc., maybe not so much at home or
school.

c. Programmers spend much time debugging; this time is controlled by the
presence of comprehensive large and small scale tests and the effort needed
to operate and interpret them. Same idea of who the programmer is here as
well...a professional person part of a team is the model.

The data for a-c comes from universal experience in large teams and large
companies. It is possible to design a programming language, documentation
system, and test infrastructure to address these issues and make them
easier, simpler, more uniform, and in the limit, to design/tool around the
problem in the first place; that design is called Go.

That's the good. The price you pay is that it casts Go as a Language WIth
an Attitude (TM) (Rob Pike). That plays out as follows:

A. Since you'll be looking at the code of others, the best thing for you is
if the code all looks "your way" stylistically. Since you will be using GIT
or some other SCM system, then the code that looks "your way" needs to be
unchanging. The solution? Define a common way and tools for that. Go
implements this. Looks like you did not win the lottery on this point--the
common way is not your personal preference. Not mine either. There is good
news though...it only takes a week or so before you don't even notice. The
benefits hugely outweigh the cost so it is firmly seen as a win for Go by
most everyone.

B. The documentation is generated from the code (so comprehensive) and
includes examples (formatted consistently as well.)

C. The testing infrastructure is not "in" the language but is built as a
peer of the language. It does not really implicate the formatting but it is
at the same level of "do everything consistently" as the indentation and
layout. The argument for consistency here is that secondary tools can read
the output of the tests and build aggregate reports. Because of this, the
formatting of the tests is also fixed so that the tools people build are
not broken by subtle output formatting. This is much like the indentation
argument, except that it serves programs rather than programmers.

Hopefully you will give these ideas some thought. Maybe they will help you
find peace with style choices that are not your favorite.

On Thu, Mar 9, 2017 at 7:07 AM,  wrote:

> I see this as an opportunity for a smart ide dev to solve a problem.
>
> This argument/divide/preference should not exist. We're talking about
> tokens that are interpreted by a machine - how those tokens are display on
> screen in an editor should never have depended on the damn white space/tabs
> etc saved in the text file. They're literally meaningless and should all be
> standardised on file save.
>
> We could strip all meaningless white space characters on save but we
> probably want to enforce a single standard to aid in unassisted reading of
> the code in non-code aware editors.
>
> However, If an individual has a preference for formatting style then the
> code editor should transparently transform their display of the code like
> CSS transforms HTML. Then there's no need for this colossal thread -
> individuals can have whatever style they want, the underlying source is the
> same for everyone.
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
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] Re: No Allman-Style, No go!

[Sam Whited]

> No Allman-Style, No go!

It's worth noting that the difference between tabs and spaces is
cosmetic and you're right, your editor could handle that for you, but
Allman-style is more complex.

Having opening braces on the same line is a matter of *syntax* in Go,
not style; if you were to write the following:

```
func test()
{
}
```

the lexer would add semi-colons like so:

```
func test();
{
}
```

breaking your code.

An IDE could of course try very hard to work around this and fix the
file on save, but having an IDE transform the syntax is probably a bit
different than having it transform minor cosmetic issues, and I'd
argue it should be avoided.

—Sam

-- 
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.