Re: [go-nuts] Re: Semicolons in Go

[john . deighan]

Ian, thank you for the thoughtful reply. I realized that my last post might 
have sounded like I was criticizing your post and that definitely wasn't 
the intention. My apologies.

On Monday, April 24, 2017 at 10:48:25 AM UTC-4, Ian Davis wrote:
>
> With respect, you are tilting at windmills. You replied to an 8 year old 
> post from the design phase of the language. It's now 2017 and no-one wants 
> to step back in time to change what has turned out to be a very successful 
> design.
>
> You stated in your first message that you "simply won't use the language" 
> because it doesn't conform to your learned preferences. I hope you 
> reconsider and adapt to what is ultimately a minor part of learning a new 
> language.
>
> Ian
>
>
> On Mon, 24 Apr 2017, at 03:42 PM, john.d...@gmail.com  wrote:
>
> One of the things that I learned early in life is to recognize B.S. when I 
> see it. My B.S. flag went up first when I read where someone claimed that 
> "artifacts" are bad and detract from the readability of code. A compact and 
> well-defined artifact, like the semicolon, makes code *more* readable 
> because the programmer's intent is crystal clear, whereas removing them 
> leaves one guessing exactly where a line ends. The rules are considerably 
> more complex - not to mention vary across languages, than the simple "it 
> ends at the semicolon" rule.
>
> Now I read that the programmer's preference is irrelevant (I hope that we 
> can agree that the programming community consists of individual 
> programmers!). Well, that flag just shot up again. There's no reason that 
> an individual's preference can't be respected when he's editing code, even 
> if way that the code is stored on disk is the same. That's why I 
> exclusively use TAB characters for indentation - some people prefer to see 
> 2 spaces per level of structure, I prefer 3 spaces and someone at my 
> company prefers 8. We get to see what we prefer without requiring any 
> changes to the code itself.
>
> So, here's my current thinking about long lines/continuation lines, take 
> it for what it's worth. There should be no such thing in a language. A long 
> line should just be a long line, without limit, in the source file. After 
> all, it's not the compiler that wants to split long lines so that they are 
> more readable - it's the programmer when using a text editor or code 
> viewer. Think how much simpler a compiler would be if it could just assume 
> that a simple (i.e. non-compound) statement always exists on a single line! 
> It's the editor that should display a single simple statement on multiple 
> lines on the screen. In fact, the editor could provide visual cues that a 
> single statement is being displayed on multiple lines on the screen, such 
> as a light gray background color, underlining, box around it, whatever. The 
> point is that the individual programmer's personal preference would be used 
> without affecting the saved format of the code.
>
> For that to work well, the editor would probably have to understand the 
> syntax of a statement so that the line splitting will result in something 
> that the programmer finds readable. I don't know if a current editor that 
> can do that. But line splitting is something that the compiler should *not* 
> have to deal with. After all, it's the programmer using an editor that 
> cares about making long lines readable, not the compiler.
>
>
> --
> 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...@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: Semicolons in Go

[David Peacock]

Please don't feed this troll.

On Mon, Apr 24, 2017 at 10:42 AM,  wrote:

> One of the things that I learned early in life is to recognize B.S. when I
> see it. My B.S. flag went up first when I read where someone claimed that
> "artifacts" are bad and detract from the readability of code. A compact and
> well-defined artifact, like the semicolon, makes code *more* readable
> because the programmer's intent is crystal clear, whereas removing them
> leaves one guessing exactly where a line ends. The rules are considerably
> more complex - not to mention vary across languages, than the simple "it
> ends at the semicolon" rule.
>
> Now I read that the programmer's preference is irrelevant (I hope that we
> can agree that the programming community consists of individual
> programmers!). Well, that flag just shot up again. There's no reason that
> an individual's preference can't be respected when he's editing code, even
> if way that the code is stored on disk is the same. That's why I
> exclusively use TAB characters for indentation - some people prefer to see
> 2 spaces per level of structure, I prefer 3 spaces and someone at my
> company prefers 8. We get to see what we prefer without requiring any
> changes to the code itself.
>
> So, here's my current thinking about long lines/continuation lines, take
> it for what it's worth. There should be no such thing in a language. A long
> line should just be a long line, without limit, in the source file. After
> all, it's not the compiler that wants to split long lines so that they are
> more readable - it's the programmer when using a text editor or code
> viewer. Think how much simpler a compiler would be if it could just assume
> that a simple (i.e. non-compound) statement always exists on a single line!
> It's the editor that should display a single simple statement on multiple
> lines on the screen. In fact, the editor could provide visual cues that a
> single statement is being displayed on multiple lines on the screen, such
> as a light gray background color, underlining, box around it, whatever. The
> point is that the individual programmer's personal preference would be used
> without affecting the saved format of the code.
>
> For that to work well, the editor would probably have to understand the
> syntax of a statement so that the line splitting will result in something
> that the programmer finds readable. I don't know if a current editor that
> can do that. But line splitting is something that the compiler should *not*
> have to deal with. After all, it's the programmer using an editor that
> cares about making long lines readable, not the compiler.
>
> --
> 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: Semicolons in Go

[John Deighan]

I won't. I'm done with this thread.

On Mon, Apr 24, 2017 at 10:52 AM David Peacock 
wrote:

> Please don't feed this troll.
>
> On Mon, Apr 24, 2017 at 10:42 AM,  wrote:
>
>> One of the things that I learned early in life is to recognize B.S. when
>> I see it. My B.S. flag went up first when I read where someone claimed that
>> "artifacts" are bad and detract from the readability of code. A compact and
>> well-defined artifact, like the semicolon, makes code *more* readable
>> because the programmer's intent is crystal clear, whereas removing them
>> leaves one guessing exactly where a line ends. The rules are considerably
>> more complex - not to mention vary across languages, than the simple "it
>> ends at the semicolon" rule.
>>
>> Now I read that the programmer's preference is irrelevant (I hope that we
>> can agree that the programming community consists of individual
>> programmers!). Well, that flag just shot up again. There's no reason that
>> an individual's preference can't be respected when he's editing code, even
>> if way that the code is stored on disk is the same. That's why I
>> exclusively use TAB characters for indentation - some people prefer to see
>> 2 spaces per level of structure, I prefer 3 spaces and someone at my
>> company prefers 8. We get to see what we prefer without requiring any
>> changes to the code itself.
>>
>> So, here's my current thinking about long lines/continuation lines, take
>> it for what it's worth. There should be no such thing in a language. A long
>> line should just be a long line, without limit, in the source file. After
>> all, it's not the compiler that wants to split long lines so that they are
>> more readable - it's the programmer when using a text editor or code
>> viewer. Think how much simpler a compiler would be if it could just assume
>> that a simple (i.e. non-compound) statement always exists on a single line!
>> It's the editor that should display a single simple statement on multiple
>> lines on the screen. In fact, the editor could provide visual cues that a
>> single statement is being displayed on multiple lines on the screen, such
>> as a light gray background color, underlining, box around it, whatever. The
>> point is that the individual programmer's personal preference would be used
>> without affecting the saved format of the code.
>>
>> For that to work well, the editor would probably have to understand the
>> syntax of a statement so that the line splitting will result in something
>> that the programmer finds readable. I don't know if a current editor that
>> can do that. But line splitting is something that the compiler should *not*
>> have to deal with. After all, it's the programmer using an editor that
>> cares about making long lines readable, not the compiler.
>>
> --
>>
> 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: Semicolons in Go

[Ian Davis]

With respect, you are tilting at windmills. You replied to an 8 year old
post from the design phase of the language. It's now 2017 and no-one
wants to step back in time to change what has turned out to be a very
successful design.
You stated in your first message that you "simply won't use the
language" because it doesn't conform to your learned preferences. I hope
you reconsider and adapt to what is ultimately a minor part of learning
a new language.
Ian


On Mon, 24 Apr 2017, at 03:42 PM, john.deig...@gmail.com wrote:
> One of the things that I learned early in life is to recognize B.S.
> when I see it. My B.S. flag went up first when I read where someone
> claimed that "artifacts" are bad and detract from the readability of
> code. A compact and well-defined artifact, like the semicolon, makes
> code *more* readable because the programmer's intent is crystal clear,
> whereas removing them leaves one guessing exactly where a line ends.
> The rules are considerably more complex - not to mention vary across
> languages, than the simple "it ends at the semicolon" rule.> 
> Now I read that the programmer's preference is irrelevant (I hope that
> we can agree that the programming community consists of individual
> programmers!). Well, that flag just shot up again. There's no reason
> that an individual's preference can't be respected when he's editing
> code, even if way that the code is stored on disk is the same. That's
> why I exclusively use TAB characters for indentation - some people
> prefer to see 2 spaces per level of structure, I prefer 3 spaces and
> someone at my company prefers 8. We get to see what we prefer without
> requiring any changes to the code itself.> 
> So, here's my current thinking about long lines/continuation lines,
> take it for what it's worth. There should be no such thing in a
> language. A long line should just be a long line, without limit, in
> the source file. After all, it's not the compiler that wants to split
> long lines so that they are more readable - it's the programmer when
> using a text editor or code viewer. Think how much simpler a compiler
> would be if it could just assume that a simple (i.e. non-compound)
> statement always exists on a single line! It's the editor that should
> display a single simple statement on multiple lines on the screen. In
> fact, the editor could provide visual cues that a single statement is
> being displayed on multiple lines on the screen, such as a light gray
> background color, underlining, box around it, whatever. The point is
> that the individual programmer's personal preference would be used
> without affecting the saved format of the code.> 
> For that to work well, the editor would probably have to understand
> the syntax of a statement so that the line splitting will result in
> something that the programmer finds readable. I don't know if a
> current editor that can do that. But line splitting is something that
> the compiler should *not* have to deal with. After all, it's the
> programmer using an editor that cares about making long lines
> readable, not the compiler.> 


> --
>  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: Semicolons in Go

[john . deighan]

One of the things that I learned early in life is to recognize B.S. when I 
see it. My B.S. flag went up first when I read where someone claimed that 
"artifacts" are bad and detract from the readability of code. A compact and 
well-defined artifact, like the semicolon, makes code *more* readable 
because the programmer's intent is crystal clear, whereas removing them 
leaves one guessing exactly where a line ends. The rules are considerably 
more complex - not to mention vary across languages, than the simple "it 
ends at the semicolon" rule.

Now I read that the programmer's preference is irrelevant (I hope that we 
can agree that the programming community consists of individual 
programmers!). Well, that flag just shot up again. There's no reason that 
an individual's preference can't be respected when he's editing code, even 
if way that the code is stored on disk is the same. That's why I 
exclusively use TAB characters for indentation - some people prefer to see 
2 spaces per level of structure, I prefer 3 spaces and someone at my 
company prefers 8. We get to see what we prefer without requiring any 
changes to the code itself.

So, here's my current thinking about long lines/continuation lines, take it 
for what it's worth. There should be no such thing in a language. A long 
line should just be a long line, without limit, in the source file. After 
all, it's not the compiler that wants to split long lines so that they are 
more readable - it's the programmer when using a text editor or code 
viewer. Think how much simpler a compiler would be if it could just assume 
that a simple (i.e. non-compound) statement always exists on a single line! 
It's the editor that should display a single simple statement on multiple 
lines on the screen. In fact, the editor could provide visual cues that a 
single statement is being displayed on multiple lines on the screen, such 
as a light gray background color, underlining, box around it, whatever. The 
point is that the individual programmer's personal preference would be used 
without affecting the saved format of the code.

For that to work well, the editor would probably have to understand the 
syntax of a statement so that the line splitting will result in something 
that the programmer finds readable. I don't know if a current editor that 
can do that. But line splitting is something that the compiler should *not* 
have to deal with. After all, it's the programmer using an editor that 
cares about making long lines readable, not the compiler.

-- 
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: Semicolons in Go

[roger peppe]

On 22 April 2017 at 02:59, Matt Harden  wrote:
> a = ( b
>   + c
>   + d
>   * e
>   )

That doesn't work:
https://play.golang.org/p/z6HFDK3XRT

The usual Go idiom is to leave the operators at the end of the lines:

a = b +
c +
d*
e

Note that extra-level of identation at the end - the original
expression is misleading - at a casual glance, you might
think that b+c+d is multiplied by e, but precedence rules means that
it doesn't.

a = b +
c +
d +
e

It's still almost as easy to add or remove a single line - with the exception
of the first and last lines.

It's kind of a pity that Go produces this an extra level of indent on
this though:

  a =
b +
c +
d +
e

It would be nice if it produced:

a =
b +
c +
d +
e

There's probably a good reason why it doesn't though, and
you can always work around it:

a = 0 +
b +
c +
d +
e

  cheers,
rog.

>
> On Thu, Apr 20, 2017 at 1:24 PM John McKown 
> wrote:
>>
>> On Thu, Apr 20, 2017 at 12:20 PM, Michael Jones 
>> wrote:
>>>
>>>
>>> On Thu, Apr 20, 2017 at 8:27 AM,  wrote:

 If I can't format my programs the way I want, and I much prefer putting
 operators at the beginning of continuation lines for reasons mentioned on
 this page, and "Perl Best Practices", I simply won't use the language - at
 least not without implementing a pre-processor. Automatic semicolon
 inserting is the worst thing about JavaScript. Please make it optional in
 some way.
>>>
>>>
>>> The die has been cast. It usually takes two weeks for personal preference
>>> here to be forgotten. Hope you give it a good chance, as you'll have many
>>> positive benefits.
>>>
>>
>> I understand that it is oft-time better to approach a new language on its
>> own merits. Just like with a "human" language. You'll never learn language
>> ABC if you keep thinking in language DEF. I.e. think in DEF then translate
>> to ABC. You'll always end up doing something wrong because each language has
>> a different "mind set" or "world view".
>>
>> Having said the above, this "auto insertion" of a semi-colon is a bother
>> to me too. Mainly because I like to write C code something like:
>>
>> a = b
>>  + c
>>  + d
>>  * e
>>  ;
>>
>> So that I can easily insert or remove a single line. This may well be due
>> to my advanced age (64!) and the fact that my original language was FORTRAN
>> which was punched onto 80 column card stock. The above did waste cards, but
>> made program changes very easy. In today's world of "full screen" editors
>> which can reformat and even refactor code upon demand, it is a relic of a
>> bygone era.
>>
>>
>>
>> --
>> "Irrigation of the land with seawater desalinated by fusion power is
>> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>>
>> 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.
>
> --
> 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: Semicolons in Go

[Matt Harden]

a = ( b
  + c
  + d
  * e
  )

On Thu, Apr 20, 2017 at 1:24 PM John McKown 
wrote:

> On Thu, Apr 20, 2017 at 12:20 PM, Michael Jones 
> wrote:
>
>>
>> On Thu, Apr 20, 2017 at 8:27 AM,  wrote:
>>
>>> If I can't format my programs the way I want, and I much prefer putting
>>> operators at the beginning of continuation lines for reasons mentioned on
>>> this page, and "Perl Best Practices", I simply won't use the language - at
>>> least not without implementing a pre-processor. Automatic semicolon
>>> inserting is the worst thing about JavaScript. Please make it optional in
>>> some way.
>>
>>
>> The die has been cast. It usually takes two weeks for personal preference
>> here to be forgotten. Hope you give it a good chance, as you'll have many
>> positive benefits.
>>
>>
> ​I understand that it is oft-time better to approach a new language on its
> own merits. Just like with a "human" language. You'll never learn language
> ABC if you keep thinking in language DEF. I.e. think in DEF then translate
> to ABC. You'll always end up doing something wrong because each language
> has a different "mind set" or "world view".
>
> Having said the above, this "auto insertion" of a semi-colon is a bother
> to me too. Mainly because I like to write C code something like:
>
> a = b
>  + c ​
>  + d
>  * e
>  ;
>
> So that I can easily insert or remove a single line. This may well be due
> to my advanced age (64!) and the fact that my original language was FORTRAN
> which was punched onto 80 column card stock. The above did waste cards, but
> made program changes very easy. In today's world of "full screen" editors
> which can reformat and even refactor code upon demand, it is a relic of a
> bygone era.
>
>
>
> --
> "Irrigation of the land with seawater desalinated by fusion power is
> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>
> 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.
>

-- 
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: Semicolons in Go

[John McKown]

On Thu, Apr 20, 2017 at 12:20 PM, Michael Jones 
wrote:

>
> On Thu, Apr 20, 2017 at 8:27 AM,  wrote:
>
>> If I can't format my programs the way I want, and I much prefer putting
>> operators at the beginning of continuation lines for reasons mentioned on
>> this page, and "Perl Best Practices", I simply won't use the language - at
>> least not without implementing a pre-processor. Automatic semicolon
>> inserting is the worst thing about JavaScript. Please make it optional in
>> some way.
>
>
> The die has been cast. It usually takes two weeks for personal preference
> here to be forgotten. Hope you give it a good chance, as you'll have many
> positive benefits.
>
>
​I understand that it is oft-time better to approach a new language on its
own merits. Just like with a "human" language. You'll never learn language
ABC if you keep thinking in language DEF. I.e. think in DEF then translate
to ABC. You'll always end up doing something wrong because each language
has a different "mind set" or "world view".

Having said the above, this "auto insertion" of a semi-colon is a bother to
me too. Mainly because I like to write C code something like:

a = b
 + c ​
 + d
 * e
 ;

So that I can easily insert or remove a single line. This may well be due
to my advanced age (64!) and the fact that my original language was FORTRAN
which was punched onto 80 column card stock. The above did waste cards, but
made program changes very easy. In today's world of "full screen" editors
which can reformat and even refactor code upon demand, it is a relic of a
bygone era.



-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: Semicolons in Go

[Michael Jones]

On Thu, Apr 20, 2017 at 8:27 AM,  wrote:

> If I can't format my programs the way I want, and I much prefer putting
> operators at the beginning of continuation lines for reasons mentioned on
> this page, and "Perl Best Practices", I simply won't use the language - at
> least not without implementing a pre-processor. Automatic semicolon
> inserting is the worst thing about JavaScript. Please make it optional in
> some way.


The die has been cast. It usually takes two weeks for personal preference
here to be forgotten. Hope you give it a good chance, as you'll have many
positive benefits.

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