Earlier quoted context omitted.
Rob Pike's Go FAQ says that this is one of their favorite features about Go, and I agree; it's how I've been writing C code since 1995. So, I mean, if conformance to my C programming style guide matters, YOU LOSE THE ARGUMENT! :) I'd also contend that no language makes changing the visibility of a variable completely painless. You're fixating on the one case where you can change the token "private" to "public" and wr…
Actually, I find public->private is not a breaking change, because before I do a 'public->private' change, I first remove all the public calls. Therefore, all I have left to do is to check the in-class calls.
Google Go: The Good, the Bad, and the Meh
111–120 of 126 posts
Re: Google Go: The Good, the Bad, and the Meh
#112Earlier quoted context omitted.
It's not correct. He's making an allusion to lisp and imputing to it the notion that everything is a linked list, which is not true. The article is a comparative discussion of programming languages. Earlier, it calls critics of the focal language in the article "idiots". That was OK with me while the author had credibility. It simply lost credibility for me at the point where it asserted that Lisp programmers don't u…
> Earlier, it calls critics of the focal language in the article "idiots". No, he only calls critics of SPECIFIC aspects of the language (aspects inconsequential and prone to bike-shedding) idiots. > It simply lost credibility for me at the point where it asserted that Lisp programmers don't use hash tables. You weren't supposed to read his article as coming from a Lisp expert, seeing that Lisp wasn't the main focus…
Then why did he make snide, ignorant allusion to Lisp?
"You shouldn't hold that comment against him; he doesn't know what he's talking about and you shouldn't expect him to" is an odd defense.
Re: Google Go: The Good, the Bad, and the Meh
#113The initial quote is a good summary about the thing I find must annoying about Go. They constantly imply that programming research is useless in the real world or at least impractical, and use that to ignore the last several decades of progress. Then they try to turn ignoring research into a virtue! It essentially presents a false dichotomy between programming research and programming practice. This is particularly u…
I'm not sure who "they" are, but certainly not the core development team, and Samuel Tesla does not represent them. See for example Rob Pike saying how mind blowing and inspiring Tony Hoare's CSP paper is, how everyone should read it and how it inspired Go[1]. Another example is how Go's regexp implementation has a solid mathematical foundation[2]. Now, those are two examples of quite old programming research being u…
Re: Google Go: The Good, the Bad, and the Meh
#114Re: Google Go: The Good, the Bad, and the Meh
#115The programming language is called Go, NOT Google Go.
Re: Google Go: The Good, the Bad, and the Meh
#116Earlier quoted context omitted.
It's not correct. He's making an allusion to lisp and imputing to it the notion that everything is a linked list, which is not true. The article is a comparative discussion of programming languages. Earlier, it calls critics of the focal language in the article "idiots". That was OK with me while the author had credibility. It simply lost credibility for me at the point where it asserted that Lisp programmers don't u…
> Earlier, it calls critics of the focal language in the article "idiots". No, he only calls critics of SPECIFIC aspects of the language (aspects inconsequential and prone to bike-shedding) idiots. > It simply lost credibility for me at the point where it asserted that Lisp programmers don't use hash tables. You weren't supposed to read his article as coming from a Lisp expert, seeing that Lisp wasn't the main focus…
Re: Google Go: The Good, the Bad, and the Meh
#117Earlier quoted context omitted.
They mean syntax and semantic highlighting. It's mostly a generational thing that goes along with 80 column line widths on amber terminals.
I wonder how much of that is older programmers being used to not having highlighting, and how much is younger programmers having never tried programming without it. I think the default assumption is that it is all old people resisting change (hence the 80 columns amber terminals bit), but I'm a younger anti-highlighting example. I am not old, I learned to code with coloured syntax highlighting. I didn't realize how m…
Re: Google Go: The Good, the Bad, and the Meh
#118The initial quote is a good summary about the thing I find must annoying about Go. They constantly imply that programming research is useless in the real world or at least impractical, and use that to ignore the last several decades of progress. Then they try to turn ignoring research into a virtue! It essentially presents a false dichotomy between programming research and programming practice. This is particularly u…
Allow me to provide some context [1] for the quote. Shortly after the language was released, somebody was ranting [2] about how Go was not innovative at all in comparison to other modern languages. I was not suggesting that programming research is useless and that we should ignore several decades of progress. I was, rather, saying that Go was applying those several decades of progress to systems programming to produce a more modern version of C. Here is the whole paragraph that quote was lifted from:
"The point the author fails to see is that Go is not meant to innovate programming theory. It’s meant to innovate programming practice. This is an upgrade to C. It’s a language that applies the innovations of the last thirty years to the systems world, where the state of the art is still portable assembler. So no, the language isn’t introducing brilliant new ideas. It’s taking tested old ideas, and introducing them into a new arena."
[1] http://blog.alieniloquent.com/2009/12/15/newsflash-go-is-exp...
Re: Google Go: The Good, the Bad, and the Meh
#119Earlier quoted context omitted.
Apparently "operator overloading, function/method overloading, [and] keyword arguments" are "bad for performance" so it's OK that Go doesn't have them.
For performance of compilation . Go compiles crazy fast -- think two seconds for complete compiler and runtime on a notebook. This provides for rapid hack-compile-debug iterations. http://www.youtube.com/watch?feature=player_embedded&v=r...
/tmp/dmd2/src/phobos/std$ wc -l *.d | grep total
162688 total
/tmp/dmd2/src/phobos/std$ time dmd -c *.d > /dev/null
std.cpuid has been deprecated. It will be removed in January 2013. Please use core.cpuid instead.
std.md5 is scheduled for deprecation. Please use std.digest.md instead
std.perf has been deprecated. It will be removed in January 2013. Please use std.datetime instead.
Notice: As of Phobos 2.055, std.regexp has been deprecated. Please use std.regex instead.
real 0m1.210s
user 0m1.016s
sys 0m0.188s
1.2 second to compile 162k LOC. Not too shabby!Re: Google Go: The Good, the Bad, and the Meh
#120The programming language is called Go, NOT Google Go.
He only used it in the title... probably better as "Google's Go" or somesuch. I can see why he did it though. Go ironically has to be the least Googleable new language name since C++ (ok, until they changed the search syntax). It's the name of a popular board game, a less popular programming language (Go!), and an incredibly common verb.