www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - One year of Go

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/

Andrei
Nov 12 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ibisr8$1vqr$2 digitalmars.com...

 http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/

 Andrei


Go is the Paris Hilton of programming languages. They keep getting buzz and 
attention not because of having ever demonstrated real merit, which they 
haven't, but because of being associated with recognizable names. Famous 
just simply for being famous. Pretty much the whole world has realized how 
useless they are, but they keep getting attention anyway.
Nov 12 2010
next sibling parent so <so so.do> writes:
 Go is the Paris Hilton of programming languages. They keep getting buzz  
 and
 attention not because of having ever demonstrated real merit, which they
 haven't, but because of being associated with recognizable names. Famous
 just simply for being famous. Pretty much the whole world has realized  
 how
 useless they are, but they keep getting attention anyway.


Sadly it is true, programmers no better, popularity means a lot.
Which brings also many positive things like tools, support, growth...
I remember another language backed up with again a big company, they'll  
eventually get to that level and that is it.
Though i hope they come up with something good at the end, which is by the  
look of the start and a few princibles, unlikely.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 12 2010
prev sibling parent Petr <janda.petr gmail.com> writes:
I haven't done any real Go programming, hell I haven't done any real D
programming
either, although I own the D programming language book, but from what I've seen
and read about Go, the language just doesn't cut it for any serious application
development where flexibility and power (both to the programmer and raw speed)
is
needed. We all know D evolved from C++, and I hope it stays true to those good
principles set out by C++, and leave the bad(template's that are often hard to
understand, lack of standard threading/locking library, and few others) ones and
provide BETTER substitute for them(which D does from what i've found so far).
Personally I don't care for garbage collection, although I think D should
provide
one because a GC is useful in many situations, but at the same time it should
retain the full capabilities of manual memory management that C and C++ offer.

D should not obstruct a programmer, it should enhance him/her.

Petr

PS Andrei: if you read this, then let me say BIG thanks for your participation
in
D. I'm slowly going through your Modern C++ through the past 6 months (yes im
busy, but it's also heavy reading at times, but definately great), you made me a
convert to functors and policy based class design.
Nov 12 2010
prev sibling next sibling parent jfd <jfd nospam.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 eaturbrainz
 Back in the day I was writing a kernel, and having to
 rewrite queues for every single type of thing I wanted
 to queue, or use type-casts to enforce strong typing
 of queue elements at runtime, was annoying as fuck.


 http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/
 Andrei


eaturbrainz's problem is what convinced me of the true value of generics.  I
had a
similar experience: In C, I had to rewrite a hashtable for every data type, so I
ended up with workarounds using struct with pointers to "worker functions",
like a
kind of poor man's "interface".  Generics is far more elegant.

I may be oversimplifying it, but it seems that the "interface" approach that I
consider to be a "workaround" is what Go is proposing to us.

I'm glad that D has true generics, and a more robust one at that.  It "fixes" a
lot of "issues" of C++ templates, and is more readable, less fragile, etc.,
etc...
than C++.  I applaud Walter for that. :)

Thank you for the post!
Nov 12 2010
prev sibling next sibling parent reply Pillsy <pillsbury gmail.com> writes:
jfd wrote:


 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article



 eaturbrainz
 Back in the day I was writing a kernel, and having to
 rewrite queues for every single type of thing I wanted
 to queue, or use type-casts to enforce strong typing
 of queue elements at runtime, was annoying as fuck.


 http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/





 eaturbrainz's problem is what convinced me of the true value of
 generics. 


At this point I'm mystified as to why language designers just keep on making
this same mistake by leaving support for generic programming out of their

languages after the fact; why ignore that?

Cheers,
Pillsy
Nov 12 2010
next sibling parent reply uriel_follower <wasteyourtime reddit.com> writes:
Pillsy Wrote:


 jfd wrote:
 

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article


 

 eaturbrainz
 Back in the day I was writing a kernel, and having to
 rewrite queues for every single type of thing I wanted
 to queue, or use type-casts to enforce strong typing
 of queue elements at runtime, was annoying as fuck.


 http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/




 

 eaturbrainz's problem is what convinced me of the true value of
 generics. 


 
 At this point I'm mystified as to why language designers just keep on making
this same mistake by leaving support for generic programming out of their

languages after the fact; why ignore that?


Can you please explain when have you missed them? Because after writing quite a
bit of Go code, and talking with other people that has written even more Go
code, almost nobody has found this to be an issue.
Specially now the new append() builtin has taken care of most of the remaining
cases where generics might have been marginally useful.

Saying "what if" is easy, I'm still curious about in what real circumstances
this "ifs" are satisfied, if you have run into any such cases while writing Go
code, I would love to hear about it.
Again, I'm not saying this doesn't happen, but that it is not as problematic in
practice as many people that have never used go seem to claim.

The question is: can you provide real world examples when that is a problem? I
can think of a few, but it is quite rare, and in those cases it is quite
painless to build your own data structures specific to whatever data you are
handling.

Because nobody ever reused any code in languages without generics!
Nov 12 2010
next sibling parent reply Pillsy <pillsbury gmail.com> writes:
uriel_follower wrote:


 Pillsy Wrote:


[...]

 At this point I'm mystified as to why language designers just keep
 on making this same mistake by leaving support for generic 

 had to graft generics onto their languages after the fact; why 
 ignore that?





 Can you please explain when have you missed them?


I haven't even bothered trying Go because lacking support for generics is so
obviously the Wrong Thing[tm]. 
[...]

 Specially now the new append() builtin has taken care of most of
 the remaining cases where generics might have been marginally 
 useful.


Wait, why did they need to introduce a *whole new builtin*? Why should this
have to be builtin *at all*?
[...]

 Because nobody ever reused any code in languages without 
 generics!


Re-using code in statically typed languages is harder if they don't have
generics. 

And after seeing people say, "Oh, yeah, you really don't need generics in our
language!" a few times only to sheepishly bolt them on a few years later
doesn't inspire much confidence this time around. 

Cheers,
Pillsy
Nov 12 2010
parent Seth Hoenig <seth.a.hoenig gmail.com> writes:
 Can you please explain when have you missed them? Because after writing
 quite a bit of Go code, and talking with other people that has written even
 more Go code, almost nobody has found this to be an issue.



This is such a crap argument, I don't even know how to counter. Perhaps
instead of trolling the D mailing list (and reddit and HN), you should put
that effort into fixing your [what I and many "other people" believe to be
an] inherently broken pet language.





On Fri, Nov 12, 2010 at 9:14 AM, Pillsy <pillsbury gmail.com> wrote:


 uriel_follower wrote:


 Pillsy Wrote:


 [...]

 At this point I'm mystified as to why language designers just keep
 on making this same mistake by leaving support for generic

 had to graft generics onto their languages after the fact; why
 ignore that?





 Can you please explain when have you missed them?


 I haven't even bothered trying Go because lacking support for generics is
 so obviously the Wrong Thing[tm].
 [...]

 Specially now the new append() builtin has taken care of most of
 the remaining cases where generics might have been marginally
 useful.


 Wait, why did they need to introduce a *whole new builtin*? Why should this
 have to be builtin *at all*?
 [...]

 Because nobody ever reused any code in languages without
 generics!


 Re-using code in statically typed languages is harder if they don't have
 generics.

 And after seeing people say, "Oh, yeah, you really don't need generics in
 our language!" a few times only to sheepishly bolt them on a few years later
 doesn't inspire much confidence this time around.

 Cheers,
 Pillsy
Nov 12 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/10 6:58 AM, uriel_follower wrote:

 Pillsy Wrote:


 jfd wrote:


 == Quote from Andrei Alexandrescu
 (SeeWebsiteForEmail erdani.org)'s article



 eaturbrainz Back in the day I was writing a kernel, and
 having to rewrite queues for every single type of thing I
 wanted to queue, or use type-casts to enforce strong typing
 of queue elements at runtime, was annoying as fuck.


 http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/












eaturbrainz's problem is what convinced me of the true value of

 generics.


 At this point I'm mystified as to why language designers just keep
 on making this same mistake by leaving support for generic

 had to graft generics onto their languages after the fact; why
 ignore that?


 Can you please explain when have you missed them? Because after
 writing quite a bit of Go code, and talking with other people that
 has written even more Go code, almost nobody has found this to be an
 issue.


I find this question extremely disingenuous, and that it is repeated so 
often reflects poorly on Go. It makes the asker look patronizing - like 
she considers potential Go users gullible beginners.

There's no need to "explain when generics are needed" or "provide an 
example when generics are useful". Generic code is everywhere to see for 
anyone who's not in denial. What should one do, paste some random code 
with generics in the response? Link to the STL or various other 
collection libraries? Sheesh.


Andrei



 Nov 12 2010



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"uriel_follower" <wasteyourtime reddit.com> wrote in message 
news:ibjknd$kr5$1 digitalmars.com...

 Pillsy Wrote:


 jfd wrote:


 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s 
 article



 eaturbrainz
 Back in the day I was writing a kernel, and having to
 rewrite queues for every single type of thing I wanted
 to queue, or use type-casts to enforce strong typing
 of queue elements at runtime, was annoying as fuck.


 http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/





 eaturbrainz's problem is what convinced me of the true value of
 generics.


 At this point I'm mystified as to why language designers just keep on 
 making this same mistake by leaving support for generic programming out 

 onto their languages after the fact; why ignore that?


 Can you please explain when have you missed them? Because after writing 
 quite a bit of Go code, and talking with other people that has written 
 even more Go code, almost nobody has found this to be an issue.
 Specially now the new append() builtin has taken care of most of the 
 remaining cases where generics might have been marginally useful.

 Saying "what if" is easy, I'm still curious about in what real 
 circumstances this "ifs" are satisfied, if you have run into any such 
 cases while writing Go code, I would love to hear about it.
 Again, I'm not saying this doesn't happen, but that it is not as 
 problematic in practice as many people that have never used go seem to 
 claim.


People who find generics worthwhile *don't use Go*. So of course the 
remaining Go users aren't going to miss them.


 Because nobody ever reused any code in languages without generics!


Sure they did. But they re-use a hell of a lot more *with* generics. (Or at 




 Nov 12 2010



  parent reply div0 <div0 sourceforge.net>  writes:


On 12/11/2010 21:42, Nick Sabalausky wrote:

 "uriel_follower"<wasteyourtime reddit.com>  wrote in message

 People who find generics worthwhile *don't use Go*. So of course the
 remaining Go users aren't going to miss them.


 Because nobody ever reused any code in languages without generics!


 Sure they did. But they re-use a hell of a lot more *with* generics. (Or at




before that experience, I'd have said that I don't do much template code 
and that using a language without them won't be a big deal.


being able to knock out some quick template code to sort out the 
repetitive bits. C#s version of generics is laughably crap.

You might not use templates every day, but when you need/want them 
absolutely nothing else comes close.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk



 Nov 12 2010



  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Fri, 12 Nov 2010 18:26:53 -0500, div0 <div0 sourceforge.net> wrote:


 On 12/11/2010 21:42, Nick Sabalausky wrote:

 "uriel_follower"<wasteyourtime reddit.com>  wrote in message

 People who find generics worthwhile *don't use Go*. So of course the
 remaining Go users aren't going to miss them.


 Because nobody ever reused any code in languages without generics!


 Sure they did. But they re-use a hell of a lot more *with* generics.  
 (Or at




 before that experience, I'd have said that I don't do much template code  
 and that using a language without them won't be a big deal.


 being able to knock out some quick template code to sort out the  
 repetitive bits. C#s version of generics is laughably crap.

 You might not use templates every day, but when you need/want them  
 absolutely nothing else comes close.




frustrated to no end (what I mean by use is write my own parameterized  
types with them).  Generics are really only good for containers.  Even if  
Go did add Generics, I think they are still missing the boat.

-Steve



 Nov 15 2010



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


uriel_follower wrote:

 Saying "what if" is easy, I'm still curious about in what real circumstances
 this "ifs" are satisfied, if you have run into any such cases while writing
 Go code, I would love to hear about it. Again, I'm not saying this doesn't
 happen, but that it is not as problematic in practice as many people that
 have never used go seem to claim.



It's easy to never need a feature that one has never used extensively before. 
It's hard to see the need or use of generics until one becomes fairly
proficient 
at them.



 Nov 12 2010



prev sibling next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


Pillsy wrote:

 At this point I'm mystified as to why language designers just keep on making
 this same mistake by leaving support for generic programming out of their

 languages after the fact; why ignore that?


My take on that is C++'s reputation for hard to use generics has given it a
stigma.



 Nov 12 2010



prev sibling next sibling parent  Boris Wang <kona.ming gmail.com>  writes:


Just about generic, I think, C no generic, so Go no generic, it's a good
enough reason.



2010/11/12 Pillsy <pillsbury gmail.com>


 jfd wrote:


 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s


 article


 eaturbrainz
 Back in the day I was writing a kernel, and having to
 rewrite queues for every single type of thing I wanted
 to queue, or use type-casts to enforce strong typing
 of queue elements at runtime, was annoying as fuck.






 http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/


 eaturbrainz's problem is what convinced me of the true value of
 generics.


 At this point I'm mystified as to why language designers just keep on
 making this same mistake by leaving support for generic programming out of

 their languages after the fact; why ignore that?

 Cheers,
 Pillsy





 Nov 12 2010



prev sibling  parent reply Russel Winder <russel russel.org.uk>  writes:


On Sat, 2010-11-13 at 09:07 +0800, Boris Wang wrote:

 Just about generic, I think, C no generic, so Go no generic, it's a
 good enough reason.


That may be the mindset, I do not know, we would have to ask Rob Pike
and Russ Cox.  However, if that is the argument then they have
definitely got it wrong if they want to work with complex homogeneous
data structures using static typing.

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



  parent  Jeff Nowakowski <jeff dilacero.org>  writes:


On 11/13/2010 03:17 AM, Russel Winder wrote:

 On Sat, 2010-11-13 at 09:07 +0800, Boris Wang wrote:

 Just about generic, I think, C no generic, so Go no generic, it's a
 good enough reason.


 That may be the mindset, I do not know, we would have to ask Rob Pike
 and Russ Cox.  However, if that is the argument then they have
 definitely got it wrong if they want to work with complex homogeneous
 data structures using static typing.


Boris's stated reason is terrible and wrong. If "good enough for C" was 
the design rationale, then there would be no need for another language 
outside of C.

Rob Pike stated in his first big talk about Go that there are no 
generics because they couldn't find a good way to make them fit in the 
language. He did say that there was less need for them in Go, but also 
left open the possibility that they could be added at a later time.



 Nov 13 2010



prev sibling next sibling parent 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:


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


(Scala, JavaScript) this has caused more problems than it solves.**

Any links to relevant research?



 Nov 13 2010



  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  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 next sibling parent reply "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



  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



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 reply Russel Winder <russel russel.org.uk>  writes:


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



  parent reply 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



  parent  Russel Winder <russel russel.org.uk>  writes:


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

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  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  parent reply Russel Winder <russel russel.org.uk>  writes:


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

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


=20

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


=20

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


=20

 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



 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 next sibling parent reply 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



  parent reply Russel Winder <russel russel.org.uk>  writes:


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



  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  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  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 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 Russel Winder <russel russel.org.uk>  writes:


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



  parent reply "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



 next sibling 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 reply 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



  parent reply 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



  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  parent  Russel Winder <russel russel.org.uk>  writes:


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 =


=20

 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  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  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 reply Sean Kelly <sean invisibleduck.org>  writes:


Russel Winder Wrote:

 
 I wonder if we need to leave the bike shed?


I'm perfectly okay with actively using a language I have issues with.  Heck,
that describes my relationship with ever language I've ever encountered.  A bit
of bike shedding may even help to improve the language.  It's when people can't
get past it that it's a problem.



 Nov 12 2010



  parent  Russel Winder <russel russel.org.uk>  writes:


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


 I'm perfectly okay with actively using a language I have issues with.
 Heck, that describes my relationship with ever language I've ever
 encountered.  A bit of bike shedding may even help to improve the
 language.  It's when people can't get past it that it's a problem.


Overall I like Go.  Sadly, on the mailing list there are times when the
development team show blind intransigence over some issues.  Over the
last couple of hours, we have, on this list, spotted two of them.
There is a third . . .=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 Sean Kelly <sean invisibleduck.org>  writes:


Jeff Nowakowski Wrote:


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


This issue with Go doesn't seem like a deliberate design decision so much as a
mistake that was for some reason documented instead of simply being fixed.  I
don't think it's in the same class as the D switch behavior.


 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.


To be honest, I haven't spent much time with Go because my cursory exposure to
the language hasn't shown it to solve the problems I care about better than the
languages I currently use.  I think Go is in the right ballpark with channels
though, and the rest is passable.  I'm trying to withhold my opinion about the
lack of generics and such and evaluate the language based on what's there.



 Nov 12 2010



  parent reply Graham Fawcett <fawcett uwindsor.ca>  writes:


On Fri, 12 Nov 2010 18:15:15 -0500, Sean Kelly wrote:

 
 To be honest, I haven't spent much time with Go because my cursory
 exposure to the language hasn't shown it to solve the problems I
 care about better than the languages I currently use. I think Go is
 in the right ballpark with channels though, and the rest is
 passable. I'm trying to withhold my opinion about the lack of
 generics and such and evaluate the language based on what's there.


Since you brought up channels...

One thing I very much like about Go (and Haskell, etc.) that I don't
think has a counterpart in Phobos is type-safe message passing. I like
the flexibility of the current "mailbox" design. But I'd really like
an alternative that could enforce type-safety on messages. I don't
think per-thread mailboxes could accommodate this, but Channel objects
could; e.g.:

struct Channel(T) { 
    T receive() { ... }
    void send(T val) { ... }
}

struct request { ... }
struct response { ... }

void worker(Channel!request inChan, Channel!response outChan) {
     while (true) {
        Request req = inChan.receive();
        Response resp = process(req);
        outChan.send(resp);
     }
}

Channel!Variant could be used to emulate thread mailboxes (though
without the per-thread limitation: multiple consumers could read from
the same channel.)

I think that type-safe channels would be a nice complement to the
current ad-hoc message-passing design. No reason I could see that they
couldn't coexist peacefully; having both would address a larger family
of possible concurrent designs, with different design trade-offs.

(I am guessing that tricks might have to be played to pass Channel
objects around as pure values across threads, but I'm also guessing
this is surmountable...)

Best,
Graham



 Nov 15 2010



  parent reply Sean Kelly <sean invisibleduck.org>  writes:


Graham Fawcett Wrote:


 On Fri, 12 Nov 2010 18:15:15 -0500, Sean Kelly wrote:

 
 To be honest, I haven't spent much time with Go because my cursory
 exposure to the language hasn't shown it to solve the problems I
 care about better than the languages I currently use. I think Go is
 in the right ballpark with channels though, and the rest is
 passable. I'm trying to withhold my opinion about the lack of
 generics and such and evaluate the language based on what's there.


 
 Since you brought up channels...
 
 One thing I very much like about Go (and Haskell, etc.) that I don't
 think has a counterpart in Phobos is type-safe message passing. I like
 the flexibility of the current "mailbox" design. But I'd really like
 an alternative that could enforce type-safety on messages. I don't
 think per-thread mailboxes could accommodate this, but Channel objects
 could; e.g.:
 
 struct Channel(T) { 
     T receive() { ... }
     void send(T val) { ... }
 }


It shouldn't be too difficult to wrap send/receive with such a design to
provide type safety.  In fact, it's one reason I wanted to use the flexible
model.  Of course, using channels would be a matter of convention, since both
would be available.


 (I am guessing that tricks might have to be played to pass Channel
 objects around as pure values across threads, but I'm also guessing
 this is surmountable...)


It should be possible to pass shared classes as well.  If the Channel is
non-shared then you'll have to do some casting in the implementation for
send/receive to allow it though.



 Nov 16 2010



  parent reply Graham Fawcett <fawcett uwindsor.ca>  writes:


Hi Sean,

On Tue, 16 Nov 2010 10:45:37 -0500, Sean Kelly wrote:


 Graham Fawcett Wrote:
 

 On Fri, 12 Nov 2010 18:15:15 -0500, Sean Kelly wrote:

 
 To be honest, I haven't spent much time with Go because my
 cursory exposure to the language hasn't shown it to solve the
 problems I care about better than the languages I currently use.
 I think Go is in the right ballpark with channels though, and the
 rest is passable. I'm trying to withhold my opinion about the
 lack of generics and such and evaluate the language based on
 what's there.


 
 Since you brought up channels...
 
 One thing I very much like about Go (and Haskell, etc.) that I
 don't think has a counterpart in Phobos is type-safe message
 passing. I like the flexibility of the current "mailbox" design.
 But I'd really like an alternative that could enforce type-safety
 on messages. I don't think per-thread mailboxes could accommodate
 this, but Channel objects could; e.g.:
 
 struct Channel(T) {
     T receive() { ... }
     void send(T val) { ... }
 }


 
 It shouldn't be too difficult to wrap send/receive with such a
 design to provide type safety. In fact, it's one reason I wanted to
 use the flexible model. Of course, using channels would be a matter
 of convention, since both would be available.


I don't have code at hand, but I remember getting frustrated trying to
put a type-safe wrapper around send/receive. I think the compiler was
failing to correctly type-check the delegates I was using to process
the messages against the types of messages I was trying to enforce.
But I was probably just doing it wrong, I'm still a D newbie.


 (I am guessing that tricks might have to be played to pass Channel
 objects around as pure values across threads, but I'm also guessing
 this is surmountable...)


 
 It should be possible to pass shared classes as well. If the Channel
 is non-shared then you'll have to do some casting in the
 implementation for send/receive to allow it though.


For fun, I whipped up a little type-safe channel implementation. It's
not stdlib quality, but it's fun to play with. :) As written below,
Chans can't be passed via spawn() or send(), although I suspect that
Chan could be turned into a shared class pretty easily. Ruthless
critiques are welcome!

Best,
Graham


/**
   A type-safe channel implementation. It's undoubtedly flawed, use with 
care.
   Author: Graham Fawcett <fawcett uwindsor.ca>
   License: <a href="http://www.boost.org/LICENSE_1_0.txt">Boost License 
1.0</a>.
*/

module chans;

import core.sync.condition;
import core.sync.mutex;
import core.thread : Thread;

class Chan(T) {

  alias immutable(T) IT;

  Mutex lock;
  Condition hasAny;
  IT[] queue;

  this() {
    lock = new Mutex;
    hasAny = new Condition(lock);
  }

  void send(IT val) {
    synchronized (lock) {
      queue ~= val;     // note, there's no upper bound on queue size.
      hasAny.notify();
    }
  }

  IT receive() {
    synchronized (lock) {
      while (true) {
        if (queue.length > 0) {
          IT val = queue[0];
          queue = queue[1..$];
          return val;
        } else {
          hasAny.wait();
        }
      }
    }
  }

  // a return type for receive(timeout).
  immutable struct maybeResult {
    bool timedOut;
    IT value;
  }

  maybeResult receive(long timeout) {
    // tip: timeout = seconds * 10_000_000
    synchronized (lock) {
      while (true) {
        if (queue.length > 0) {
          IT val = queue[0];
          queue = queue[1..$];
          return maybeResult(false, val);
        } else {
          bool timedOut = !hasAny.wait(timeout);
          if (timedOut) {
            return maybeResult(true);
          }
        }
      }
    }
  }
}


/* Testing: Start up a worker pool of N threads, all listening on a
common request channel. Each worker takes one request, calculates a
response (ooh, multiplication!) and sends the result to a common
response channel; then it exits. The main thread collects the results
and prints the sum of the answers. */

import std.stdio;

struct request { int payload; }
struct response { int result; }

void multiplier(Chan!request chan, Chan!response outChan) {
  auto req = chan.receive();
  writef("(%s<-%d) ", Thread.getThis().name, req.payload);
  stdout.flush();
  outChan.send(response(100 * req.payload));
}

void test1() {
  enum NUM_WORKERS = 100;
  auto chan = new Chan!request;
  auto outChan = new Chan!response;

  foreach(x; 0..NUM_WORKERS) {
    Thread t = new Thread(() { multiplier(chan, outChan); });
    t.name = std.string.format("T%d", x);
    t.isDaemon = true;
    t.start();
  }

  foreach(x; 0..NUM_WORKERS) {
    chan.send(request(x));
  }

  auto sum = 0;
  foreach(x; 0..NUM_WORKERS) {
    auto r = outChan.receive();
    sum += r.result;
  }
  writefln("\nsum of responses: %s", sum);
}

void main() {
  test1();
}



 Nov 18 2010



  parent  Sean Kelly <sean invisibleduck.org>  writes:


Graham Fawcett <fawcett uwindsor.ca> wrote:

 Hi Sean,
 
 On Tue, 16 Nov 2010 10:45:37 -0500, Sean Kelly wrote:
 

 Graham Fawcett Wrote:
 

 On Fri, 12 Nov 2010 18:15:15 -0500, Sean Kelly wrote:

 
 To be honest, I haven't spent much time with Go because my
 cursory exposure to the language hasn't shown it to solve the
 problems I care about better than the languages I currently use.
 I think Go is in the right ballpark with channels though, and the
 rest is passable. I'm trying to withhold my opinion about the
 lack of generics and such and evaluate the language based on
 what's there.


 
 Since you brought up channels...
 
 One thing I very much like about Go (and Haskell, etc.) that I
 don't think has a counterpart in Phobos is type-safe message
 passing. I like the flexibility of the current "mailbox" design.
 But I'd really like an alternative that could enforce type-safety
 on messages. I don't think per-thread mailboxes could accommodate
 this, but Channel objects could; e.g.:
 
 struct Channel(T) {
     T receive() { ... }
     void send(T val) { ... }
 }


 
 It shouldn't be too difficult to wrap send/receive with such a
 design to provide type safety. In fact, it's one reason I wanted to
 use the flexible model. Of course, using channels would be a matter
 of convention, since both would be available.


 
 I don't have code at hand, but I remember getting frustrated trying to
 put a type-safe wrapper around send/receive. I think the compiler was
 failing to correctly type-check the delegates I was using to process
 the messages against the types of messages I was trying to enforce.
 But I was probably just doing it wrong, I'm still a D newbie.


That's a compiler bug. spawn has the same problem.



 Nov 21 2010



prev sibling next sibling parent reply Kagamin <spam here.lot>  writes:


bearophile Wrote:


 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


How do you look at necessary curly braces in Go? Shouldn't they adopt python
syntax while keeping Go design?



 Nov 13 2010



  parent  bearophile <bearophileHUGS lycos.com>  writes:


Kagamin:


 How do you look at necessary curly braces in Go? Shouldn't they adopt python
syntax while keeping Go design?


I like Python syntax, but the features of a language must be all adapted to
each other, they form something like an ecology.

In general what I look for is a language syntax that is somehow resilient
against simple mistakes that mammals do all the time. So curly braces are
sometimes better than bug-prone alternatives.

Bye,
bearophile



 Nov 13 2010



prev sibling next sibling parent  Sean Kelly <sean invisibleduck.org>  writes:


retard Wrote:


 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.


... which is an interesting idea with some fundamental problems (possibly
solvable).  There was a series of articles on this in ACM Communications about
a year ago.  I'll have to dig up the articles for specifics though.



 Nov 13 2010



prev sibling  parent reply Kagamin <spam here.lot>  writes:


bearophile Wrote:


 Kagamin:
 

 How do you look at necessary curly braces in Go? Shouldn't they adopt python
syntax while keeping Go design?


 
 I like Python syntax, but the features of a language must be all adapted to
each other, they form something like an ecology.
 
 In general what I look for is a language syntax that is somehow resilient
against simple mistakes that mammals do all the time. So curly braces are
sometimes better than bug-prone alternatives.


Aren't curly braces the same redundancy as semicolons, serving the same purpose?



 Nov 13 2010



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Kagamin:


 Aren't curly braces the same redundancy as semicolons, serving the same
purpose?


The information represented by the curly braces is represented by the
indentation levels. The semicolons are not necessary to represent logical
nesting, and indeed some Python-style languages avoid them. The semicolons were
added by Guido V.R. because an usability test on the ABC language (that's the
base for Python) has shown they improve readability, they help the mammals that
write the program.

Bye,
bearophile



 Nov 13 2010



  parent reply Kagamin <spam here.lot>  writes:


bearophile Wrote:


 Kagamin:
 

 Aren't curly braces the same redundancy as semicolons, serving the same
purpose?


 
 The information represented by the curly braces is represented by the
indentation levels.


http://docs.python.org/py3k/reference/lexical_analysis.html#explicit-line-joining
If understood it correctly, physical lines don't obey the indentation rules and
can have any indentation, e.g. the same indentation as the return statement in
the example.



 Nov 13 2010



  parent  bearophile <bearophileHUGS lycos.com>  writes:


Kagamin:


 http://docs.python.org/py3k/reference/lexical_analysis.html#explicit-line-joining
 If understood it correctly, physical lines don't obey the indentation rules
and can have any indentation, e.g. the same indentation as the return statement
in the example.


Right. There are two exceptions to the rule: you may use the \ symbol to extend
a logical line, so here the indentation doesn't matter. And the same happens
inside a () [] or {}.

In practice the \ are uncommon in good Python programs, the programmer usually
just adds a ().

Bye,
bearophile



 Nov 13 2010