www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: One year of Go

reply Sean Kelly <sean invisibleduck.org> writes:
I got about halfway through the Go tutorial and was stopped by this:

"You might have noticed that our program has no semicolons. In Go code, the
only place you typically see semicolons is separating the clauses of for loops
and the like; they are not necessary after every statement. . . This approach
makes for clean-looking, semicolon-free code. The one surprise is that it's
important to put the opening brace of a construct such as an if statement on
the same line as the if; if you don't, there are situations that may not
compile or may give the wrong result. The language forces the brace style to
some extent."

To me, what they're saying is that their syntax is broken and so it forces a
convention upon the users to deal with the issue.  I know this is just a bike
shed issue, but seeing something like this in the beginning of the tutorial
makes it difficult for me to take them seriously.
Nov 12 2010
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sean,

On Fri, 2010-11-12 at 11:29 -0500, Sean Kelly wrote:


 To me, what they're saying is that their syntax is broken and so it
 forces a convention upon the users to deal with the issue.  I know
 this is just a bike shed issue, but seeing something like this in the
 beginning of the tutorial makes it difficult for me to take them
 seriously.



If I remember correctly, they used to enforce semicolons as line
terminators -- and indeed you can still use semicolons as statement
terminators if you want.  However, all the folk who had used any of the
"semicolon free" languages started grumbling loudly and at great length
-- and quite right to, semicolons are an eyesore! ;-)

The Go developers then realized that due to their enforcement of a
single brace and newline policy -- i.e. they are formatting fascists
compared to other curly bracket languages -- they could actually
dispense with semicolons in the input source code and reinsert them for
the parser during the lexing.  So the parsed language has semicolon
statement terminators, even if the input source does not.

Now you can treat this as a stupidity, or an evil hack, or pragmatism, I
am going to steadfastly sit on the fence of any emotional argument on
this, but I have to say I quite like not having to have semicolon
statement terminators.  And the enforced formatting is not actually too
brain dead.

So all in all whether it is a serious issue or not, it doesn't actually
matter than much when writing Go code.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 12 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Russel Winder:


 I have to say I quite like not having to have semicolon
 statement terminators.



I too don't like to add the semicolon at the end of lines, I like to write
Python code that doesn't need them, but in some languages (Scala, JavaScript)
this has caused more problems than it solves. So the language needs to be
designed to never require them at the end of lines and to have a not error
prone syntax.

Bye,
bearophile
Nov 12 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/10 9:44 AM, bearophile wrote:

 Russel Winder:


 I have to say I quite like not having to have semicolon
 statement terminators.



 I too don't like to add the semicolon at the end of lines, I like to write
Python code that doesn't need them, but in some languages (Scala, JavaScript)
this has caused more problems than it solves. So the language needs to be
designed to never require them at the end of lines and to have a not error
prone syntax.

 Bye,
 bearophile



Same here. The problem is I don't want to remember arcana about the 
necessity of sometimes doing this and sometimes doing that. I first met 
optional semicolon in the Cecil language, where the last expression in a 
function would determine the result. So one would write:

method fun() { 42 }

to return an integer, and

method fun() { 42; }

to return void. This turned out to be a huge hassle, so I vaguely recall 
the rule was changed such that ";" at the end of the function was always 
ignored, thus making it difficult to write functions that return void.

Then I met it in Javascript, where the rule was confusing in similar 
ways; a sensible piece of advice that I followed was to always use 
semicolons. Finally, Go has yet other issues with the matter.

I guess only Python got that one right...


Andrei
Nov 12 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 So one would write:
 
 method fun() { 42 }
 
 to return an integer, and
 
 method fun() { 42; }
 
 to return void.




I've seen this proposed for both C++ function literals and for D function 
literals. I'm surprised any language followed through with it. It's awful.
Nov 12 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
retard:


 Any links to relevant research?



If your JavaScript function ends with this, what kind of errors or return value
does it generate?

return
    2 + 2;

Found in this thread:
http://stackoverflow.com/questions/1995113/strangest-language-feature

Bye,
bearophile
Nov 13 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ibm3n8$b22$1 digitalmars.com...

 retard:


 Any links to relevant research?



 If your JavaScript function ends with this, what kind of errors or return 
 value does it generate?

 return
    2 + 2;

 Found in this thread:
 http://stackoverflow.com/questions/1995113/strangest-language-feature



Great thread there. These are a couple of really interesting ones mentined 
there:

try {
    return true;
} finally {
    return false;
}


try {
    throw new AssertionError();
} finally {
    return false;
}

I wonder how D handles those (On my way out the door so don't have a chance 
to try them ATM...)
Nov 13 2010
prev sibling parent Kagamin <spam here.lot> writes:
bearophile Wrote:


 retard:
 

 Any links to relevant research?



 If your JavaScript function ends with this, what kind of errors or return
value does it generate?
 
 return
     2 + 2;



Holy shit!
Hmm... I knew, js is soft in this regard, I had not a single thought to use
this bug, it's unacceptable, though the first language I learned was basic and
I had no issues with it.
Nov 13 2010
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Russel Winder Wrote:

 
 So all in all whether it is a serious issue or not, it doesn't actually
 matter than much when writing Go code.



What got me was "if you don't, there are situations that ... may give the wrong
result."  I'm fine with eliminating semicolons, but why is this syntax allowed
if it silently produces surprising results?  It seems like a trivial change to
require the proper syntax, and not doing so makes me wonder if there are other
such flaws as well.
Nov 12 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/10 10:41 AM, Russel Winder wrote:

 On Fri, 2010-11-12 at 13:28 -0500, Sean Kelly wrote:
 [ . . . ]

 What got me was "if you don't, there are situations that ... may give
 the wrong result."  I'm fine with eliminating semicolons, but why is
 this syntax allowed if it silently produces surprising results?  It
 seems like a trivial change to require the proper syntax, and not
 doing so makes me wonder if there are other such flaws as well.



 I understand.  I can't say I view the the situation with total
 happiness.  There are situations where the core Go development team
 stick to what can only be seen as blind prejudice.  It has to be said
 though that this is true of all language developments.

 I wonder if we need to leave the bike shed?



Is the example I just gave a bikeshed issue?

package main

import "fmt"

func blah() bool {
    return false
}

func main() {
   x := 5
   if(blah())
   {
     x++;
   }
   fmt.Printf("%d\n", x)
}

Again, to drive the point home: this program compiles flag free and runs 
printing 6.


Andrei
Nov 12 2010
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 11/12/2010 11:29 AM, Sean Kelly wrote:

 To me, what they're saying is that their syntax is broken and so it
 forces a convention upon the users to deal with the issue.  I know
 this is just a bike shed issue, but seeing something like this in the
 beginning of the tutorial makes it difficult for me to take them
 seriously.



Yes, semicolons are a bike shed issue, and dismissing the whole language 
because of that is petty. Walter has made a point in the past about 
people who will look for one reason to dismiss something.

There are ideas worth looking at in Go, whether you decide to use the 
language or not.
Nov 12 2010
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Jeff Nowakowski Wrote:


 On 11/12/2010 11:29 AM, Sean Kelly wrote:

 To me, what they're saying is that their syntax is broken and so it
 forces a convention upon the users to deal with the issue.  I know
 this is just a bike shed issue, but seeing something like this in the
 beginning of the tutorial makes it difficult for me to take them
 seriously.



 Yes, semicolons are a bike shed issue, and dismissing the whole language 
 because of that is petty. Walter has made a point in the past about 
 people who will look for one reason to dismiss something.



I haven't dismissed Go because it clearly has done a lot of things right.  But
stumbling across something like this in my first 5 minutes with the language
doesn't instill a lot of confidence.
Nov 12 2010
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 11/12/2010 01:31 PM, Sean Kelly wrote:

 I haven't dismissed Go because it clearly has done a lot of things
 right.  But stumbling across something like this in my first 5
 minutes with the language doesn't instill a lot of confidence.



There are dozens of design decisions to make in a language, and they 
chose one poorly. They certainly aren't the first with regards to 
semicolons, and D has plenty of similar issues (like not taking the 
opportunity to fix C's case fallthrough).

It's hard to reconcile that you think they did a lot of things right 
with statements like "seeing something like this in the beginning of the 
tutorial makes it difficult for me to take them seriously". You never 
mentioned anything positive in your original post; it certainly sounded 
like you just dismissed the language.

The lack of generics and dangerous concurrency are much bigger issues. 
If D can actually be shown to be a useful concurrent language, instead 
of the buggy and incomplete mess it is now, then it might have something 
to crow about.
Nov 12 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jeff Nowakowski:


 and D has plenty of similar issues (like not taking the 
 opportunity to fix C's case fallthrough).



Right. But Walter may have accepted the idea (proposed by some people,
including me) to require some kind of control flow in switch cases. If this is
true, then the problem with C fallthrough is mostly solved (badly solved, but
solved).



 If D can actually be shown to be a useful concurrent language, instead 
 of the buggy and incomplete mess it is now, then it might have something 
 to crow about.



At the current rhythm of bug fixing in two-three years DMD might have a low
enough number of bugs. D doesn't have resources and sizeable development groups
as for example C# has, so a slower development speed is expected. D has about
ten years already, but you need several years to develop a C++-class language
with a so little design&development group.

So even thousand bugs aren't the main problem, the problem is more in the
development style (how much people around think it is OpenSource and how much
good is the main developer in recruiting and managing people. For example
Walter is probably a much better programmer than Giudo V.R. of Python, but the
community management skills of Guido are much better than Walter ones. The good
thing is that Walter keeps improving and moving forward, so lately things are
getting better, Phobos is slowly becoming more and more like an open source
project), if it has a killer app, if people like it enough, if its design
doesn't have too many traps and holes, and so on.

Bye,
bearophile
Nov 12 2010
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 13.11.2010 08:53, schrieb Russel Winder:

 On Fri, 2010-11-12 at 15:07 -0500, Jeff Nowakowski wrote:
 [ . . . ]

  The lack of generics and dangerous concurrency are much bigger issues.
  If D can actually be shown to be a useful concurrent language, instead
  of the buggy and incomplete mess it is now, then it might have something
  to crow about.



 What do you see as wrong with the Go model for concurrency?

 I find the process/message-passing approach infinitely easier than
 shared-memory multithreading with all its needs for locks, monitors,
 semaphores or lock-free programming.  True operating systems will need
 these latter techniques, but surely they are operating system level ones
 and should never have to appear in application code?



...True operating systems will need these latter techniques...

gain speed and very granular control by introducing more risky technics: 
that not only a need for True operating systems, Ds approach is to allow 
(i hope better/less risky) both
Nov 12 2010
prev sibling parent Jeff Nowakowski <jeff dilacero.org> writes:
On 11/13/2010 02:53 AM, Russel Winder wrote:

 What do you see as wrong with the Go model for concurrency?



Andrei explained it to you in the "GO Vs D" thread:

http://groups.google.com/group/golang-nuts/browse_thread/thread/f24e7d46091e27ab/e30994ff3d3b32ca#e30994ff3d3b32ca

The short answer is that data can be shared by accident.
Nov 13 2010
prev sibling next sibling parent so <so so.do> writes:
 There are dozens of design decisions to make in a language, and they  
 chose one poorly. They certainly aren't the first with regards to  
 semicolons, and D has plenty of similar issues (like not taking the  
 opportunity to fix C's case fallthrough).



That special case bugs me as well.
I suppose for low level coders, switch/case statements mean/feel something  
other than what we usually think, since they eagerly defend it.
i got bitten by that many times and i loved it seeing it in Go.
Nov 12 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2010-11-12 at 15:07 -0500, Jeff Nowakowski wrote:
[ . . . ]

 The lack of generics and dangerous concurrency are much bigger issues.=




 If D can actually be shown to be a useful concurrent language, instead=




 of the buggy and incomplete mess it is now, then it might have something=




 to crow about.



What do you see as wrong with the Go model for concurrency?

I find the process/message-passing approach infinitely easier than
shared-memory multithreading with all its needs for locks, monitors,
semaphores or lock-free programming.  True operating systems will need
these latter techniques, but surely they are operating system level ones
and should never have to appear in application code?
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 12 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 12 Nov 2010 11:54:35 -0500, Jeff Nowakowski wrote:


 On 11/12/2010 11:29 AM, Sean Kelly wrote:

 To me, what they're saying is that their syntax is broken and so it
 forces a convention upon the users to deal with the issue.  I know this
 is just a bike shed issue, but seeing something like this in the
 beginning of the tutorial makes it difficult for me to take them
 seriously.



 Yes, semicolons are a bike shed issue, and dismissing the whole language
 because of that is petty. Walter has made a point in the past about
 people who will look for one reason to dismiss something.



That argument of course only applies when looking at D. Walter thinks all 
other competitive languages are pure shit.
Nov 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 13 Nov 2010 07:53:14 +0000, Russel Winder wrote:


 On Fri, 2010-11-12 at 15:07 -0500, Jeff Nowakowski wrote: [ . . . ]

 The lack of generics and dangerous concurrency are much bigger issues.
 If D can actually be shown to be a useful concurrent language, instead
 of the buggy and incomplete mess it is now, then it might have
 something to crow about.



 What do you see as wrong with the Go model for concurrency?
 
 I find the process/message-passing approach infinitely easier than
 shared-memory multithreading with all its needs for locks, monitors,
 semaphores or lock-free programming.  True operating systems will need
 these latter techniques, but surely they are operating system level ones
 and should never have to appear in application code?



There's also the software transactional memory technology.
Nov 13 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2010-11-13 at 08:51 +0000, retard wrote:
[ . . . ]

 There's also the software transactional memory technology.



I am ambivalent about STM.  Haskell has it, Clojure has it, Intel have a
variant for C and C++ but are trying to quietly ignore it.  Sun even
tried to put hardware support for transactional memory into a chip --
but the sale of Sun to Oracle has terminated that work.

On the one hand STM is just a sticking plaster trying to allow shared
memory multithreading to work as though there was no need for
synchronization and care on the part of the programmer.   On the other
hand it makes shared-memory multithreading less full of locks,
semaphores and monitors.

All in all, unless STM gets picked up and widely used in C, C++, Java
and Scala -- also D of course :-) -- I don't see it going anywhere.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 13 2010
prev sibling parent retard <re tard.com.invalid> writes:
Sat, 13 Nov 2010 10:48:00 +0000, Russel Winder wrote:


 On Sat, 2010-11-13 at 08:51 +0000, retard wrote: [ . . . ]

 There's also the software transactional memory technology.



 I am ambivalent about STM.  Haskell has it, Clojure has it, Intel have a
 variant for C and C++ but are trying to quietly ignore it.  Sun even
 tried to put hardware support for transactional memory into a chip --
 but the sale of Sun to Oracle has terminated that work.
 
 On the one hand STM is just a sticking plaster trying to allow shared
 memory multithreading to work as though there was no need for
 synchronization and care on the part of the programmer.   On the other
 hand it makes shared-memory multithreading less full of locks,
 semaphores and monitors.
 
 All in all, unless STM gets picked up and widely used in C, C++, Java
 and Scala -- also D of course :-) -- I don't see it going anywhere.



Certainly. But it does solve the problem in many cases, right? At least 
I'm willing to use technologies that solve the problem. The popularity 
doesn't matter that much.

The fact that the Sun's project was terminated might have more to do with 
politics and how it could bring profit to Oracle. Many good projects have 
been abandoned. The STM causes some overhead and the hardware could be 
used to mitigate that.
Nov 13 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Nov 2010 11:29:15 -0500, Sean Kelly <sean invisibleduck.org>  
wrote:


 I got about halfway through the Go tutorial and was stopped by this:

 "You might have noticed that our program has no semicolons. In Go code,  
 the only place you typically see semicolons is separating the clauses of  
 for loops and the like; they are not necessary after every statement. .  
 . This approach makes for clean-looking, semicolon-free code. The one  
 surprise is that it's important to put the opening brace of a construct  
 such as an if statement on the same line as the if; if you don't, there  
 are situations that may not compile or may give the wrong result. The  
 language forces the brace style to some extent."

 To me, what they're saying is that their syntax is broken and so it  
 forces a convention upon the users to deal with the issue.  I know this  
 is just a bike shed issue, but seeing something like this in the  
 beginning of the tutorial makes it difficult for me to take them  
 seriously.



As discussed previously:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=110968
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=110884

What they say is this:

if(x)
{
    g(x)
}

is interpreted as this:

if(x);
{
    g(x);
}

Absolutely, 100% wrong decision.  Go will never recover from that IMO.

-Steve
Nov 12 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:


 If that is invalid code, then I stand corrected.  If it compiles, then  
 it's a serious flaw that is inexcusable.



You need more time to try it on the site that Walter thinks is useless:
http://ideone.com/Ju80U

This Go code:

package main
 
import "fmt"
 
func main() {
  x := 5
  if(x == 6)
  {
    x++;
  }
  fmt.Printf("%d\n", x)
}


Produces this compilation error (gc-2010-07-14):
prog.go:7: x == 6 not used

The interactive compiler on the Go site produces the same outcome:
http://golang.org/

Bye,
bearophile
Nov 12 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/10 10:33 AM, bearophile wrote:

 Steven Schveighoffer:


 If that is invalid code, then I stand corrected.  If it compiles, then
 it's a serious flaw that is inexcusable.



 You need more time to try it on the site that Walter thinks is useless:
 http://ideone.com/Ju80U

 This Go code:

 package main

 import "fmt"

 func main() {
    x := 5
    if(x == 6)
    {
      x++;
    }
    fmt.Printf("%d\n", x)
 }


 Produces this compilation error (gc-2010-07-14):
 prog.go:7: x == 6 not used

 The interactive compiler on the Go site produces the same outcome:
 http://golang.org/

 Bye,
 bearophile



Try this then:

package main

import "fmt"

func blah() bool {
    return false
}

func main() {
   x := 5
   if(blah())
   {
     x++;
   }
   fmt.Printf("%d\n", x)
}

which evaluates x++ and prints 6 regardless of blah's result.

Ouch.

So Sean was right - it _did_ take him five minutes to find a fatal flaw.


Andrei
Nov 12 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 So Sean was right - it _did_ take him five minutes to find a fatal flaw.



You are right. But in this case the language may just disallow empty bodies for
if(), for(), etc.

Bye,
bearophile
Nov 12 2010
parent Sean Kelly <sean invisibleduck.org> writes:
bearophile Wrote:


 Andrei:
 

 So Sean was right - it _did_ take him five minutes to find a fatal flaw.



 You are right. But in this case the language may just disallow empty bodies
for if(), for(), etc.



Making the current broken behavior an error would be trivial and wouldn't break
any existing Go programs.  That's why it seems so weird to me that this
behavior was documented instead of simply fixed, and why I imagine it will be
fixed at some point regardless.
Nov 12 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/10 10:57 AM, so wrote:

 Oh it is so brave to enforce that kind of thing, even as an individual i
 don't have a rule for that.


 if(...)
 {
 ...
 }




 if(...) {
 ...
 }



 You can see both in my code and i have never thought that would offend
 someone.
 Sometimes one of them looks cuter than the other, depending on the
 context :P



Yah, the problem is they do different things. Try this:

package main
import "fmt"
func blah() bool {
    return false
}
func main() {
   x := 5
   if(blah()) {
     x++;
   }
   fmt.Printf("%d\n", x)
}

(which prints 5) and then this:

package main
import "fmt"
func blah() bool {
    return false
}
func main() {
   x := 5
   if(blah())
   {
     x++;
   }
   fmt.Printf("%d\n", x)
}

(which prints 6). Looks like a major problem to me. Comparing this with 
the meager advantage of eliminating semicolons, it seems that things 
took a wrong turn somewhere.


Andrei
Nov 12 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2010-11-12 at 11:59 -0500, Steven Schveighoffer wrote:
[ . . . ]


 if(x)
 {
     g(x)
 }
=20
 is interpreted as this:
=20
 if(x);
 {
     g(x);
 }
=20
 Absolutely, 100% wrong decision.  Go will never recover from that IMO.



Possibly but the formatting standard of Go *requires*:

if ( x ) {
    g ( x )
}

anyway, so as Sean said this is a moot point -- assuming that is what
"bike shedding" means.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 12 2010
prev sibling next sibling parent jfd <jfd nospam.com> writes:
== Quote from Sean Kelly (sean invisibleduck.org)'s article

 In Go code, the only place you typically see semicolons is
 separating the clauses of for loops and the like; they are not
 necessary after every statement







 To me, what they're saying is that their syntax is broken and so it
 forces a convention upon the users to deal with the issue.



Also, doesn't semicolon also help recover from bad syntax, by skipping to next
semicolon, or it not necessary any more?
Nov 12 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Nov 2010 12:09:15 -0500, Russel Winder <russel russel.org.uk>  
wrote:


 On Fri, 2010-11-12 at 11:59 -0500, Steven Schveighoffer wrote:
 [ . . . ]


 if(x)
 {
     g(x)
 }

 is interpreted as this:

 if(x);
 {
     g(x);
 }

 Absolutely, 100% wrong decision.  Go will never recover from that IMO.



 Possibly but the formatting standard of Go *requires*:

 if ( x ) {
     g ( x )
 }

 anyway, so as Sean said this is a moot point -- assuming that is what
 "bike shedding" means.



If that is invalid code, then I stand corrected.  If it compiles, then  
it's a serious flaw that is inexcusable.

-Steve
Nov 12 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2010-11-12 at 13:06 -0500, Steven Schveighoffer wrote:


 if(x)
 {
     g(x)
 }










 If that is invalid code, then I stand corrected.  If it compiles, then =




 it's a serious flaw that is inexcusable.



I think there is element of "more by luck than judgement" here.  In the
example I tried:

        package main
       =20
        import "fmt"
       =20
        func main ( ) {
        	x :=3D false
        	if ( x )
        	{
        		fmt.Printf ( "Hello World." )
        	}
        }


I got the error:

... 7: x not used

So all in all, not entirely satisfactory :-(

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 12 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2010-11-12 at 13:28 -0500, Sean Kelly wrote:
[ . . . ]

 What got me was "if you don't, there are situations that ... may give
 the wrong result."  I'm fine with eliminating semicolons, but why is
 this syntax allowed if it silently produces surprising results?  It
 seems like a trivial change to require the proper syntax, and not
 doing so makes me wonder if there are other such flaws as well.



I understand.  I can't say I view the the situation with total
happiness.  There are situations where the core Go development team
stick to what can only be seen as blind prejudice.  It has to be said
though that this is true of all language developments.

I wonder if we need to leave the bike shed?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 12 2010
prev sibling next sibling parent so <so so.do> writes:
Oh it is so brave to enforce that kind of thing, even as an individual i  
don't have a rule for that.


 if(...)
 {
 	...
 }




 if(...) {
 	...
 }



You can see both in my code and i have never thought that would offend  
someone.
Sometimes one of them looks cuter than the other, depending on the context  
:P

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 12 2010
prev sibling next sibling parent so <so so.do> writes:
 Yah, the problem is they do different things. Try this:

 package main
 import "fmt"
 func blah() bool {
     return false
 }
 func main() {
    x := 5
    if(blah()) {
      x++;
    }
    fmt.Printf("%d\n", x)
 }

 (which prints 5) and then this:

 package main
 import "fmt"
 func blah() bool {
     return false
 }
 func main() {
    x := 5
    if(blah())
    {
      x++;
    }
    fmt.Printf("%d\n", x)
 }

 (which prints 6). Looks like a major problem to me. Comparing this with  
 the meager advantage of eliminating semicolons, it seems that things  
 took a wrong turn somewhere.


 Andrei



If they have gone this far, why not pop an error and be done with it...

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 12 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2010-11-12 at 10:52 -0800, Andrei Alexandrescu wrote:
[ . . . ]

 Is the example I just gave a bikeshed issue?



Hummm . . .   :-)

I think the real problem here is not the semicolon reinsertion, but it
is the demand that "if you don't obey the official language formatting
rules, then you are on your own, goodbye".

Whilst I like Go a lot, generics and semicolon reinsertion are two
obvious glitches that really need to be addressed rather than swept
under the carpet.

Of course this is the D list . . .=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 12 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Sean Kelly" <sean invisibleduck.org> wrote in message 
news:ibjq0r$12ki$1 digitalmars.com...

I got about halfway through the Go tutorial and was stopped by this:

 "You might have noticed that our program has no semicolons. In Go code, 
 the only place you typically see semicolons is separating the clauses of 
 for loops and the like; they are not necessary after every statement. . . 
 This approach makes for clean-looking, semicolon-free code. The one 
 surprise is that it's important to put the opening brace of a construct 
 such as an if statement on the same line as the if; if you don't, there 
 are situations that may not compile or may give the wrong result. The 
 language forces the brace style to some extent."

 To me, what they're saying is that their syntax is broken and so it forces 
 a convention upon the users to deal with the issue.  I know this is just a 
 bike shed issue, but seeing something like this in the beginning of the 
 tutorial makes it difficult for me to take them seriously.



Semicolons are normally a bikeshed issue, but if optional-semicolons are 
done in a way that means accidentally putting '{' on the wrong line results 
in silently modified behavior, then that's not a bikeshed, that's just a 
broken language design.
Nov 12 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 Semicolons are normally a bikeshed issue, but if optional-semicolons are 
 done in a way that means accidentally putting '{' on the wrong line results 
 in silently modified behavior, then that's not a bikeshed, that's just a 
 broken language design.



I agree that the sometimes lines are significant and sometimes not is, in the 
end, more confusing than enlightening.

Especially when, as in Andrei's example, *very* common forms compile without 
error and produce unexpected results.
Nov 12 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 12 Nov 2010 12:44:37 -0500, bearophile wrote:


 Russel Winder:
 

 I have to say I quite like not having to have semicolon statement
 terminators.



 I too don't like to add the semicolon at the end of lines, I like to
 write Python code that doesn't need them, **but in some languages 




Any links to relevant research?
Nov 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 13 Nov 2010 08:27:04 -0500, bearophile wrote:


 retard:
 

 Any links to relevant research?



 If your JavaScript function ends with this, what kind of errors or
 return value does it generate?
 
 return
     2 + 2;
 
 Found in this thread:
 http://stackoverflow.com/questions/1995113/strangest-language-feature



You also mentioned Scala. In Scala you need to write the return type to 
the function signature when explicitly using 'return'. The only case 
where this can fail in Scala is when the return type is Unit. Would be 
strange to try to return 2+2 in that case.

Andrei also mentioned this:


 method fun() { 42 }
   to return an integer, and
 method fun() { 42; }
   to return void.



in Scala both


 def fun = { 42; }
 def fun = { 42 }



return the same function.

The only cases in Scala when the expression fails is when you write a 
multiline expression and forget to surround the expression with braces or 
parentheses.
Nov 13 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Nick Sabalausky <a a.a> wrote:


 try {
     return true;
 } finally {
     return false;
 }


 try {
     throw new AssertionError();
 } finally {
     return false;
 }

 I wonder how D handles those



Error: return statements cannot be in finally, scope(exit) or
scope(success) bodies

-- 
Simen
Nov 13 2010