Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Go: The Good, the Bad, and the Meh

blog.carlsensei.com

Post reply on HN
Print view View original

121–126 of 126 posts

Re: Google Go: The Good, the Bad, and the Meh

#121

Post by papsosouid »

benaiah wrote: post #105
papsosouid wrote: post #103

Earlier quoted context omitted.

>It was a non sequitur, and a straw man It was neither, and repetition is not an argument. Let me paraphrase the conversation in the desperate hope you will at least read this since you refuse to read the thread you are discussing: Me: if you are seeing 2x slower, then that seems like unusual uses of python. Him: I think some real world uses of python are 90% C libraries and 10% python Me: I feel the cases you are re…

> Let me paraphrase the conversation in the desperate hope you will at least read this since you refuse to read the thread you are discussing > ... your continued insistence that your arrogant and pointless accusation was correct is absurd. If you don't wish to read something, don't reply to it. I'm attempting to keep the conversation civil (I have even gone back and changed some of my more inflammatory phrasings), a…

Perhaps in the future, rather than accuse people of non-sequiturs and logical fallacies, you might consider alternative explanations like "I misunderstood what was said". I asked several people to read the post you misunderstood, and it was completely clear to them. You are still insisting that your misunderstanding is my fault, and that does not at all indicate that you are interested in engaging in discussion.

Re: Google Go: The Good, the Bad, and the Meh

#122

Post by TheMagicHorsey »

I don't think that the code the author listed for Paul Graham's Accumulator Challenge is correct. The challenge specifically states that its for a number not an integer, and its any incrementation, not addition. I'm not very familiar with Go, but it seems like the Go solution is not as general as the solutions in Lisp and other languages, where any operator and type can be used with the accumulator function.

I'm sure there is probably some way to implement the same thing in Go using duck typing. Just wanted to point out the difference though.

Re: Google Go: The Good, the Bad, and the Meh

#123

Post by earthboundkid »

stickfigure wrote: post #66
tptacek wrote: post #51

Earlier quoted context omitted.

The two major virtues of case-based visibility: 1. It creates a coherent syntax for making names visible that works both for member variables and package variables; you don't ever have to wonder how to expose something, because you always do it just by making the name uppercase. 2. It allows readers to see at a glance without thinking whether a value is public --- it's public if it's a proper name. In practice, Go st…

Please convince me this is a good idea. #1 does not seem to be a real issue. Most similar languages have the common, popularly understood, and easily-remembered keyword "public". Whereas capitalization is an exotic special rule that must be learned. If "you don't ever have to wonder how to expose something" is an important measure, I think Go is at a disadvantage here - especially if you want your code to be read by…

Some thoughts in defense of Go's use of capitalization. First of all, public/private are used in languages with classes. It would be misleading in Go, since visibility is at the package level.

Second, if Go didn't use capitalization and wanted to keep package level visibility (which I will strongly argue is the Right Thing), there would be choice of having both private and public as keywords and requiring one of the pair to be put before before all constants, package level variables, type declarations, struct members, functions, and methods -- creating an immense amount of noise -- or to have one of the two and make the other one the default. Probably it would make more sense to have everything private by default and public only when prefixed with public… But it would be really ugly and inconsistent.

Now it might be possible to get around this with some other convention. Maybe it could be like Python, where everything is public by default but private if it starts with _. Or it could use a different, shorter keyword like 'p' so there's less noise overall…

But I think that once you make the decision to have package level visibility, case is the most efficient way of expressing it.

Re: Google Go: The Good, the Bad, and the Meh

#124

Post by earthboundkid »

tptacek wrote: post #25
niggler wrote: post #16

Earlier quoted context omitted.

"quitting articles or conversations because of some remark" This is the problem with the internet and with political discourse in the 21st century: as soon as someone says something that seems off-kilter, even if it is technically correct, people stop listening/reading.

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…

(Author here.) Actually, the remark was a complaint about "Learn You a Haskell," which I have been working through, on the grounds that it's NOT Lisp, so they shouldn't pretend like head/tail are the holy grail of data structure design.

Re: Google Go: The Good, the Bad, and the Meh

#125

Post by earthboundkid »

kenko wrote: post #112
coldtea wrote: post #34

Earlier quoted context omitted.

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

"You weren't supposed to read his article as coming from a Lisp expert, seeing that Lisp wasn't the main focus at all." 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.

(Author here.) I find it odd that everyone thinks the remark is a criticism of Lisp. It's a criticism of Haskell. Lisp had a good excuse for focusing on linked lists back in the day. Then Clojure improved on it by promoting hashes to first class constructs. But Haskell is stuck in the past, at least as far as first class syntax goes.

Re: Google Go: The Good, the Bad, and the Meh

#126

Post by FreeFull »

earthboundkid wrote: post #125
kenko wrote: post #112

Earlier quoted context omitted.

"You weren't supposed to read his article as coming from a Lisp expert, seeing that Lisp wasn't the main focus at all." 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.

(Author here.) I find it odd that everyone thinks the remark is a criticism of Lisp. It's a criticism of Haskell. Lisp had a good excuse for focusing on linked lists back in the day. Then Clojure improved on it by promoting hashes to first class constructs. But Haskell is stuck in the past, at least as far as first class syntax goes.

The only thing that elevates lists above other data structures in Haskell syntax-wise is the "" and [] sugar for constructing them. Haskell's type system allows you very easily to construct your own data types. For example, an unbalanced binary tree would be defined as

data Tree a = Leaf a | Branch a (Tree a) (Tree a) deriving (Eq, Show)

I admit that the easiest way to construct a hashmap, using fromList [(key,value),(otherkey,othervalue)], isn't as pretty as Clojure's syntax.

Post reply on HN