digitalmars.D - "In praise of Go" discussion on ycombinator
- Andrei Alexandrescu (2/2) Nov 16 2010 http://news.ycombinator.com/item?id=1912728
- Steven Schveighoffer (5/7) Nov 16 2010 "I like go because every single feature go has is the best ever!"
- Andrei Alexandrescu (4/12) Nov 16 2010 I'm curious what the response to my example will be. So far I got one
- Steven Schveighoffer (11/26) Nov 16 2010 It's possible that you left your point as an exercise for the reader, so...
- Andrei Alexandrescu (4/31) Nov 16 2010 I think as soon as that defect registers at Go's creators, they will
- Jay Byrd (8/39) Nov 16 2010 The problem pointed out can readily be fixed by requiring statements to
- so (7/12) Nov 17 2010 Since you are trying to fix it, you agree it is a design error.
- Steven Schveighoffer (34/74) Nov 17 2010 Yes, but instead of that, they decided to point it out in the tutorial a...
- Matthias Pleh (4/5) Nov 17 2010 i++
- Simen kjaeraas (7/10) Nov 17 2010 Surely you mean:
- ponce (3/6) Nov 17 2010 That was a good point and it's a deal-killer for me too.
- Rainer Deyke (22/24) Nov 16 2010 I really don't see the problem with requiring that '{' goes on the same
- Jonathan M Davis (12/39) Nov 16 2010 Personally, I _hate_ the style of putting the brace on the same line, so...
- Jay Byrd (5/33) Nov 17 2010 It *isn't* required. But if you don't put it there, *you get the wrong
- Andrei Alexandrescu (6/17) Nov 17 2010 Exactly, that comes as a big surprise to me, too, in that discussion. I
- Nick Sabalausky (7/25) Nov 17 2010 Sad as it may be, most people, and worse still, most programmers, have n...
- bearophile (6/7) Nov 17 2010 This is an interesting topic, there is a lot to say about it. Bugs and e...
- so (3/5) Nov 17 2010 You didn't mean that, did you?
- so (3/6) Nov 17 2010 Oh you did! and i agree.
- Daniel Gibson (8/27) Nov 17 2010 What about
- Daniel Gibson (3/31) Nov 17 2010 "someOtherThing.color = COLORS.Octarine" was supposed to be
- Rainer Deyke (28/45) Nov 17 2010 At first glance, it looks like two statements to me. The intended
- Bruno Medeiros (12/14) Nov 30 2010 I have to agree. The issue itself is a fairly minor one. For starters
http://news.ycombinator.com/item?id=1912728 Andrei
Nov 16 2010
On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:http://news.ycombinator.com/item?id=1912728 Andrei"I like go because every single feature go has is the best ever!" yawn... -Steve
Nov 16 2010
On 11/16/10 9:21 PM, Steven Schveighoffer wrote:On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:I'm curious what the response to my example will be. So far I got one that doesn't even address it. Andreihttp://news.ycombinator.com/item?id=1912728 Andrei"I like go because every single feature go has is the best ever!" yawn... -Steve
Nov 16 2010
On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:On 11/16/10 9:21 PM, Steven Schveighoffer wrote:It's possible that you left your point as an exercise for the reader, so it may be lost. But it's not important. It's unlikely that you will convince goers that the language deficiencies are not worth the advantages. Only time will tell how popular/useful it will be. That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that). (cue retard's comment about D zealots not having any open mindedness) -SteveOn Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:I'm curious what the response to my example will be. So far I got one that doesn't even address it.http://news.ycombinator.com/item?id=1912728 Andrei"I like go because every single feature go has is the best ever!" yawn... -Steve
Nov 16 2010
On 11/16/10 9:58 PM, Steven Schveighoffer wrote:On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:I think as soon as that defect registers at Go's creators, they will scramble to fix it one way or another. It's a blatant syntax design mistake. AndreiOn 11/16/10 9:21 PM, Steven Schveighoffer wrote:It's possible that you left your point as an exercise for the reader, so it may be lost. But it's not important. It's unlikely that you will convince goers that the language deficiencies are not worth the advantages. Only time will tell how popular/useful it will be. That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that). (cue retard's comment about D zealots not having any open mindedness) -SteveOn Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:I'm curious what the response to my example will be. So far I got one that doesn't even address it.http://news.ycombinator.com/item?id=1912728 Andrei"I like go because every single feature go has is the best ever!" yawn... -Steve
Nov 16 2010
On Wed, 17 Nov 2010 00:58:28 -0500, Steven Schveighoffer wrote:On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:The problem pointed out can readily be fixed by requiring statements to have at least one token. go has much more severe problems than that. And there are plenty of bugs and mistakes in D, harder to fix, that could be deemed "deal-killers" by someone with an axe to grind. It's not an intellectually honest approach.On 11/16/10 9:21 PM, Steven Schveighoffer wrote:It's possible that you left your point as an exercise for the reader, so it may be lost. But it's not important. It's unlikely that you will convince goers that the language deficiencies are not worth the advantages. Only time will tell how popular/useful it will be. That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that).On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:I'm curious what the response to my example will be. So far I got one that doesn't even address it.http://news.ycombinator.com/item?id=1912728 Andrei"I like go because every single feature go has is the best ever!" yawn... -Steve(cue retard's comment about D zealots not having any open mindedness) -SteveNo zealots are open minded. That's why I'm a supporter of various things but not a zealot about anything.
Nov 16 2010
The problem pointed out can readily be fixed by requiring statements to have at least one token. go has much more severe problems than that. And there are plenty of bugs and mistakes in D, harder to fix, that could be deemed "deal-killers" by someone with an axe to grind. It's not an intellectually honest approach.Since you are trying to fix it, you agree it is a design error. For the "bugs and mistakes in D": Bugs are bugs, what you say is just nonsense. With mistakes i take you mean mistakes in D design, and you said there are many of them, you need to elaborate that one a bit. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 17 2010
On Wed, 17 Nov 2010 02:56:09 -0500, Jay Byrd <JayByrd rebels.com> wrote:On Wed, 17 Nov 2010 00:58:28 -0500, Steven Schveighoffer wrote:Yes, but instead of that, they decided to point it out in the tutorial and documentation, it's on you to not make the mistake, not them. Makes you feel like they said "yes, we noticed that you can have that problem, but we don't think it's a big deal, just remember to be careful." Being someone who likes the "brace-on-its-own-line" style, I can't really see myself getting past that part. And I don't really have any other complaints about Go, I've never used it. This one issue needs to be fixed for Go to be considered a serious language. Hopefully they realize this. When a language has an error-prone issue, one that allows you to write valid code that is never desired, but looks completely correct, it results in buggy code, period. An instance of this in D was the precedence for logic operators and comparison operators. x | y == 5 was interpreted as x | (y == 5). This was thankfully fixed, and it's a very similar issue to Go's mistake. With all the experience people have with designing languages and code analysis by compilers, there are no excuses to have something like this get into a new language. The best thing to teach Go's creators about how bad this is is to make the change you suggest and see how their standard library fares. This has been instrumental in having such changes made to D (for example, the logic operator thing found about 6 cases in phobos where the code was incorrect).On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:The problem pointed out can readily be fixed by requiring statements to have at least one token.On 11/16/10 9:21 PM, Steven Schveighoffer wrote:It's possible that you left your point as an exercise for the reader, so it may be lost. But it's not important. It's unlikely that you will convince goers that the language deficiencies are not worth the advantages. Only time will tell how popular/useful it will be. That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that).On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:I'm curious what the response to my example will be. So far I got one that doesn't even address it.http://news.ycombinator.com/item?id=1912728 Andrei"I like go because every single feature go has is the best ever!" yawn... -Stevego has much more severe problems than that. And there are plenty of bugs and mistakes in D, harder to fix, that could be deemed "deal-killers" by someone with an axe to grind. It's not an intellectually honest approach.I agree that D has hard to fix mistakes. The glaring one IMO is lack of tail-const for classes. It's a huge hole in the const feature set and I can see people being turned off by it. Another is lack of runtime introspection, or the conservative GC. That doesn't mean D is worse or better than Go. It's just that Go is a non-starter (at least for me) without fixing that mistake. If they fixed it, would I start using Go? Probably not, I have too much other things to do. But if Go was around when I was looking for a language to switch to from C++ 4 years ago, that one issue makes the decision a no-brainer.I consider myself not to be a zealot either (but definitely biased). The comment was a friendly dig at retard, that's all ;) -Steve(cue retard's comment about D zealots not having any open mindedness) -SteveNo zealots are open minded. That's why I'm a supporter of various things but not a zealot about anything.
Nov 17 2010
Am 17.11.2010 14:55, schrieb Steven Schveighoffer:Being someone who likes the "brace-on-its-own-line" stylei++ greets Matthias
Nov 17 2010
Matthias Pleh <sufu alter.com> wrote:Am 17.11.2010 14:55, schrieb Steven Schveighoffer:Surely you mean: i ++ ; -- SimenBeing someone who likes the "brace-on-its-own-line" stylei++
Nov 17 2010
That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that).That was a good point and it's a deal-killer for me too. It's too much similar to the Javascript object literal syntax http://stackoverflow.com/questions/3641519/why-results-varies-upon-placement-of-curly-brace -in-javascript-code
Nov 17 2010
On 11/16/2010 22:24, Andrei Alexandrescu wrote:I'm curious what the response to my example will be. So far I got one that doesn't even address it.I really don't see the problem with requiring that '{' goes on the same line as 'if'. It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think. It could be correct code written in another style, or it could be code that has been mangled during editing and now needs to be fixed. In Go, I /know/ it's mangled code, and I'm far less likely to encounter it, so I can find mangled code much more easily. A compiler error would be even better, but Go's syntax is already an improvement over C/C++/D. There are huge problems with Go that will probably keep me from ever using the language. This isn't one of them. -- Rainer Deyke - rainerd eldwood.com
Nov 16 2010
On Tuesday 16 November 2010 22:55:42 Rainer Deyke wrote:On 11/16/2010 22:24, Andrei Alexandrescu wrote:Personally, I _hate_ the style of putting the brace on the same line, so I'm instantly biased as far as that goes, but the fact that the language does not actually require that you put the braces in a particular place and yet you have to to make it work properly is definitely a big problem. It's one that can be gotten around easily enough with strict formatting guidelines, but C-based languages are supposed to be pretty much freely formattable (otherwise why even make it optional), so it's a definite faux pas on their part. It's one that they should be able to fix without too much trouble, so hopefully it won't really be an issue in the long run, but it's definitely troubling. At least with a language like Python, it's extremely clear that formatting matters. - Jonathan M DavisI'm curious what the response to my example will be. So far I got one that doesn't even address it.I really don't see the problem with requiring that '{' goes on the same line as 'if'. It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think. It could be correct code written in another style, or it could be code that has been mangled during editing and now needs to be fixed. In Go, I /know/ it's mangled code, and I'm far less likely to encounter it, so I can find mangled code much more easily. A compiler error would be even better, but Go's syntax is already an improvement over C/C++/D. There are huge problems with Go that will probably keep me from ever using the language. This isn't one of them.
Nov 16 2010
On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:On 11/16/2010 22:24, Andrei Alexandrescu wrote:It *isn't* required. But if you don't put it there, *you get the wrong result*. I really don't understand why the problem with Andrei's example isn't blatantly obvious to everyone, but I would not want to use any product of anyone for whom it isn't.I'm curious what the response to my example will be. So far I got one that doesn't even address it.I really don't see the problem with requiring that '{' goes on the same line as 'if'.It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think. It could be correct code written in another style, or it could be code that has been mangled during editing and now needs to be fixed. In Go, I /know/ it's mangled code, and I'm far less likely to encounter it, so I can find mangled code much more easily. A compiler error would be even better, but Go's syntax is already an improvement over C/C++/D. There are huge problems with Go that will probably keep me from ever using the language. This isn't one of them.
Nov 17 2010
On 11/17/10 12:00 AM, Jay Byrd wrote:On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:Exactly, that comes as a big surprise to me, too, in that discussion. I can only hypothesize that some readers just glaze over the example thinking "ah, whatever... a snippet trying to support some naysay", and they reply armed with that presupposition. AndreiOn 11/16/2010 22:24, Andrei Alexandrescu wrote:It *isn't* required. But if you don't put it there, *you get the wrong result*. I really don't understand why the problem with Andrei's example isn't blatantly obvious to everyone, but I would not want to use any product of anyone for whom it isn't.I'm curious what the response to my example will be. So far I got one that doesn't even address it.I really don't see the problem with requiring that '{' goes on the same line as 'if'.
Nov 17 2010
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message news:ic03ui$gjg$1 digitalmars.com...On 11/17/10 12:00 AM, Jay Byrd wrote:Sad as it may be, most people, and worse still, most programmers, have no qualms about "safety by convention". That's why they don't see this as a big problem. Safety-by-convention is one of those things that's only recognized as a real problem by people with enough self-discipline and people who have actually been burned enough by dong it wrong.On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:Exactly, that comes as a big surprise to me, too, in that discussion. I can only hypothesize that some readers just glaze over the example thinking "ah, whatever... a snippet trying to support some naysay", and they reply armed with that presupposition.On 11/16/2010 22:24, Andrei Alexandrescu wrote:It *isn't* required. But if you don't put it there, *you get the wrong result*. I really don't understand why the problem with Andrei's example isn't blatantly obvious to everyone, but I would not want to use any product of anyone for whom it isn't.I'm curious what the response to my example will be. So far I got one that doesn't even address it.I really don't see the problem with requiring that '{' goes on the same line as 'if'.
Nov 17 2010
Nick Sabalausky:Sad as it may be, most people, and worse still, most programmers, have no qualms about "safety by convention".<This is an interesting topic, there is a lot to say about it. Bugs and errors have many sources, and you need to balance different and sometimes opposed needs to minimize them. Some of the sources of those troubles are not intuitive at all. In some situations "safety by convention" is the less bad solution. You are used to C-like languages, and probably you don't see the very large amounts of "safety by convention" things they do or ask to do. If you look at safer languages (like SPARK, a safer variant of Ada) you see a large amount of things you never want to do in normal programs. And I am now aware that even SPARK contains big amounts of things that are safe just because the programmer is supposed to do them in the right way. If you start piling more and more constraints and requirements on the work of the programmer you don't produce a safer language, but a language that no one is able to use or no one has enough time and resources to use (unless the program is critically important). This is a bit like the "worse is better" design strategy, sometimes to maximize the safety you have to leave the program some space to do things that don't look safe at all. Designing a good language some things wrong (like using + to concat strings, or much worse http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covariance-and-contravariance-in-c-part-two-a ray-covariance.aspx ). Bye, bearophile
Nov 17 2010
It *isn't* required. But if you don't put it there, *you get the wrong result*.You didn't mean that, did you? -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 17 2010
Oh you did! and i agree. -- Using Opera's revolutionary email client: http://www.opera.com/mail/It *isn't* required. But if you don't put it there, *you get the wrong result*.You didn't mean that, did you?
Nov 17 2010
Rainer Deyke schrieb:On 11/16/2010 22:24, Andrei Alexandrescu wrote:What about if( (blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color = COLORS.Octarine ) { x++; }I'm curious what the response to my example will be. So far I got one that doesn't even address it.I really don't see the problem with requiring that '{' goes on the same line as 'if'. It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think.
Nov 17 2010
Daniel Gibson schrieb:Rainer Deyke schrieb:"someOtherThing.color = COLORS.Octarine" was supposed to be "someOtherThing.color == COLORS.Octarine" of course.On 11/16/2010 22:24, Andrei Alexandrescu wrote:What about if( (blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color = COLORS.Octarine ) { x++; }I'm curious what the response to my example will be. So far I got one that doesn't even address it.I really don't see the problem with requiring that '{' goes on the same line as 'if'. It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think.
Nov 17 2010
On 11/17/2010 03:26, Daniel Gibson wrote:Rainer Deyke schrieb:At first glance, it looks like two statements to me. The intended meaning could have been this: if ((blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color == COLORS.Octarine) { ++x; } Or this: if((blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color == COLORS.Octarine) {} { ++x; } The latter seems extremely unlikely, so it was probably the former. Still, I have to stop and think about it. There is also the third possibility that the intended meaning of the statement is something else entirely, and the relevant parts have been lost or have not yet been written. Language-enforced coding standards are a good thing, because they make foreign code easier to read. For this purpose, it doesn't matter if the chosen style is your usual style or if you subjectively like it. Even a bad coding standard is better than no coding standard. -- Rainer Deyke - rainerd eldwood.comLet's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think.What about if( (blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color = COLORS.Octarine ) { x++; }
Nov 17 2010
On 17/11/2010 06:55, Rainer Deyke wrote:There are huge problems with Go that will probably keep me from ever using the language. This isn't one of them.I have to agree. The issue itself is a fairly minor one. For starters because it is trivial to fix: if this ever becomes a more important issue in the community of Go users (which likely it will), then the creators will just change it. It won't have a significant impact on language design, unlike generics or plenty of other stuff, which can be quite cumbersome to add if not designed from the beginning. You can say that the issue is somewhat telling of the design principles of the language creators, but otherwise I doubt it will make much difference. -- Bruno Medeiros - Software Engineer
Nov 30 2010