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