31–40 of 40 posts
The authors of go come from my generation. Back in those days, the term "Systems Programming" meant something different than what wikipedia, and probably most everyone today thinks of it.
Systems Programming in those days meant writing compilers, text processors, unix command line programs. It did not then mean programming an operating system, or anything near hard real-time.
Not a very high quality article.
Earlier quoted context omitted.
I think you mean "declaring the variable name before the type ". So C is "int x" where Go is "x int". BASIC is typically more like "DIM x AS INTEGER".
For the record: as someone who started in the early '90s in C, I hate hate hate the Go declaration syntax. But the designers make a very compelling case for why it's the right syntax: C function pointers are needlessly convoluted.
It is weird at first, but you get used to it, like everything syntactic.
Earlier quoted context omitted.
I think you mean "declaring the variable name before the type ". So C is "int x" where Go is "x int". BASIC is typically more like "DIM x AS INTEGER".
For the record: as someone who started in the early '90s in C, I hate hate hate the Go declaration syntax. But the designers make a very compelling case for why it's the right syntax: C function pointers are needlessly convoluted.
Why hate something trivial that takes 2 minutes to adjust to and has benefits without any drawbacks whatsoever?
Earlier quoted context omitted.
For the record: as someone who started in the early '90s in C, I hate hate hate the Go declaration syntax. But the designers make a very compelling case for why it's the right syntax: C function pointers are needlessly convoluted.
> For the record: as someone who started in the early '90s in C, I hate hate hate the Go declaration syntax. Why hate something trivial that takes 2 minutes to adjust to and has benefits without any drawbacks whatsoever?
I'm sure `tptacek` will get over it :-)
It's worth noting that this post is from December 2009.
Ok, I will do this one more time. The authors of go come from my generation. Back in those days, the term "Systems Programming" meant something different than what wikipedia, and probably most everyone today thinks of it. Systems Programming in those days meant writing compilers, text processors, unix command line programs. It did not then mean programming an operating system, or anything near hard real-time. Not a v…
From a previous Go blog post by the same author: Go decided to use a foreign syntax to C++, C and Java programmers. They borrows forward declarations from BASIC (yep, you heard me right…BASIC), creating declarations that are backwards from what we’ve been using for close to 20 years "Yep, you heard me right... BASIC". Consider carefully how seriously you want to take this blog.
Go's declaration syntax has some benefits: http://blog.golang.org/2010/07/gos-declaration-syntax.html And they didn't borrow the declaration syntax from BASIC, but from Pascal: http://golang.org/doc/go_faq.html#ancestors At the time Pascal was invented BASIC distinguished variable types via name postfixes like % and $. Also, a "forward declaration" is not what the author seems to think: http://en.wikipedia.org/wiki/F…
Like Pascal/Ada/etc, Go uses a postfix type declaration syntax, but the former languages separate the variable from the type with a colon. This is both more readable—the colon acts as a highly visible marker for the type, whereas with the Go style, the variable and type end up sort of smudged together—and because of its long history, much more familiar.
Go-style: var foo, bar int
Pascal-style: var foo, bar : int
My suspicion is that Go originally did use a colon in declarations and they got rid of it at some point for some reason, because Go's "auto-declaration" syntax actually does use a colon, only without an explicit type: "x := expr" makes much more sense if the normal declaration syntax is "x : type = expr" ("just leave out the type and it will be deduced")....
There doesn't seem any particularly good reason to omit the colon, it's neither onerous to use nor particularly space-consuming. Neither is it likely it simply didn't occur to them, as the declaration syntax is probably consciously based on that of Pascal-family languages. Given that it seem to yield obvious benefits without any obvious problems, I'm mystified as to why it was omitted.
Unfortunately for all its obvious goodness in some areas Go also seems to have a number of these "WTF were they thinking" areas as well. The impression it leaves is of a rough draft, not something polished. Sadly, these quirks are pretty much set in stone now...
Earlier quoted context omitted.
It's worth reading http://commandcenter.blogspot.com/2012/06/less-is-exponentia... to get some idea of the motivation behind including less. If you believe that our software systems are increasingly complex and that some aspect of the problems we're solving are essentially complex, then the strongest path towards simplicity lies in minimizing complexity incidental to the problems we're solving. One facet of programmi…
> If you believe that our software systems are increasingly complex and that some aspect of the problems we're solving are essentially complex, then the strongest path towards simplicity lies in minimizing complexity incidental to the problems we're solving. One facet of programming which routinely introduces complexity is our tools, particularly our programming languages. That is true, but I'm not sure the correlati…
Also, simplicity, like security, is a trade-off. When performance is paramount, people will reach for C or assembly, and rightly so. Conversely if performance is not the #1 priority, developers feel free to use higher-level languages like Java or Ruby.
Earlier quoted context omitted.
It's worth reading http://commandcenter.blogspot.com/2012/06/less-is-exponentia... to get some idea of the motivation behind including less. If you believe that our software systems are increasingly complex and that some aspect of the problems we're solving are essentially complex, then the strongest path towards simplicity lies in minimizing complexity incidental to the problems we're solving. One facet of programmi…
> If you believe that our software systems are increasingly complex and that some aspect of the problems we're solving are essentially complex, then the strongest path towards simplicity lies in minimizing complexity incidental to the problems we're solving. One facet of programming which routinely introduces complexity is our tools, particularly our programming languages. That is true, but I'm not sure the correlati…
Honestly, I'm just repeating variations on http://www.infoq.com/presentations/Simple-Made-Easy.