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

Replacing Clever Code with Unremarkable Code in Go

vividcortex.com

Post reply on HN
Print view View original

41–50 of 140 posts

Re: Replacing Clever Code with Unremarkable Code in Go

#41

Post by masklinn »

itsmonktastic wrote: post #24
JulianMorrison wrote: post #11

Earlier quoted context omitted.

Like this, I presume: go func(){ for { select { case

Nice. I still haven't given Go much time, but I really like this form, where you can switch on multiple blocking calls. I've definitely wanted this in other languages where I'm using thread safe queues for communication, and had to do manual multiplexing into a new queue whenever I wanted to do a blocking get on multiple queues. Does anyone know of a convenient way to do this when handling multiple instances of pytho…

njs12345 answered for Haskell, I don't remember seeing a way to do this in Python though depending on the situation you could just use a single queue for everything of course.

FWIW there's no primitive letting you wait on multiple conditions in threading, and Queue is implemented in terms of a pair of conditions.

Re: Replacing Clever Code with Unremarkable Code in Go

#42

Post by stcredzero »

> A straightforward solution of the problem is superior to one that makes you feel like a high priest for having discovered it.

It is also much better for the team and the company. Beginning musicians are just trying to play. Intermediate musicians are try to play as fancy as they can. Master musicians play what's needed by the tune.

It takes somebody who's past all the ego issues to devote their intelligence to making code look simple. It takes great intelligence to solve a complex problem in a way that looks simple and straightforward.

Re: Replacing Clever Code with Unremarkable Code in Go

#43

Post by shurcooL »

JulianMorrison wrote: post #11
xaprb wrote: post #2

I didn't put much code into the article, but ask me if you'd like more details on exactly what I'm talking about -- in terms of real code.

Like this, I presume: go func(){ for { select { case

What would the equivalent C++ code be?

How would you do a select on multiple blocking calls and send values across channels?

Re: Replacing Clever Code with Unremarkable Code in Go

#44

Post by NullSet »

gypsobelum wrote: post #16

http://www.paulgraham.com/avg.html Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language. And in fact, our hypothetical Blub programmer w…

I think this basically nails the attitude of every single go convert that I have spoken to. I am starting to get tired of hearing lines like "that lisp stuff is too complicated, I am a go programmer" or "why would you do x in y way, it's so much better in go".

I don't think I have ever seen such unrelenting fanboyism in a programming language. It very well may be a fantastic language but its not an end all be all, we would do well to remember that.

Re: Replacing Clever Code with Unremarkable Code in Go

#45

Post by masklinn »

aodin wrote: post #39
peterwaller wrote: post #14

Earlier quoted context omitted.

I don't claim that was their goal. I think it's just a nice side-effect.

Russ Cox, one of programmers working on Go, described the dilemma as: "do you want slow programmers, slow compilers and bloated binaries, or slow execution times?" He expanded on this dilemma with examples from major languages: http://research.swtch.com/generic

> He expanded on this dilemma with examples from major languages: http://research.swtch.com/generic

My god, this is such completely dishonest bullshit strawman I'm impressed he had the balls to post that garbage. Java's boxing does not come from its generics, it's the other way around (java's non-Array collections have never been able to hold unboxed values), and C++'s template are pretty much unique in their complexity (and definitely not what PL people think about when talking about generics) and compounded by all the rest of C++'s baggage (D has C++-style templates and is nowhere as slow to compile).

And his reaction to comments (that is, his complete failure to acknowledge how huge a strawman his original post is, and complete absence of response to any mention of C#, Eiffel, Ada, Haskell, MLs and others)... that is supposed to be a defense of goteam's thought process?

Re: Replacing Clever Code with Unremarkable Code in Go

#46

Post by shurcooL »

stcredzero wrote: post #42

> A straightforward solution of the problem is superior to one that makes you feel like a high priest for having discovered it. It is also much better for the team and the company. Beginning musicians are just trying to play. Intermediate musicians are try to play as fancy as they can. Master musicians play what's needed by the tune. It takes somebody who's past all the ego issues to devote their intelligence to maki…

It's better for everyone who will use/reuse/maintain/improve that code in the future (including the person who wrote it). But of course it's not easy, and takes extra time.

Personally, at this time, I feel a lot more satisfaction when I'm able to truly understand the problem I'm working with, and refactor complicated/hacky/duplicated code into a functionally equivalent but simple and elegant code. Smart/complex code that works is a great intermediate step though, it's way better than no code. :)

Rob Pike has a very relevant article [1] on this topic.

[1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...

Re: Replacing Clever Code with Unremarkable Code in Go

#47

Post by masklinn »

NullSet wrote: post #44
gypsobelum wrote: post #16

http://www.paulgraham.com/avg.html Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language. And in fact, our hypothetical Blub programmer w…

I think this basically nails the attitude of every single go convert that I have spoken to. I am starting to get tired of hearing lines like "that lisp stuff is too complicated, I am a go programmer" or "why would you do x in y way, it's so much better in go". I don't think I have ever seen such unrelenting fanboyism in a programming language. It very well may be a fantastic language but its not an end all be all, we…

> I don't think I have ever seen such unrelenting fanboyism in a programming language.

It's died down, but discussions involving C# used to be rough, take pretty much any PL feature added since 1.0 (generics, lambdas, local type inference, etc...) and any time they were suggested before their official blessing and addition by Microsoft would be met with charges of useless fancy-pants PL wankery of no use to Real Programmers in the Real World who were Very Productive and this was Abstract Useless Stuff for CS Undegrads Who Didn't Work In The Real World.

Re: Replacing Clever Code with Unremarkable Code in Go

#48

Post by [deleted] »

stcredzero wrote: post #42

> A straightforward solution of the problem is superior to one that makes you feel like a high priest for having discovered it. It is also much better for the team and the company. Beginning musicians are just trying to play. Intermediate musicians are try to play as fancy as they can. Master musicians play what's needed by the tune. It takes somebody who's past all the ego issues to devote their intelligence to maki…

[deleted]

Re: Replacing Clever Code with Unremarkable Code in Go

#49

Post by mwcampbell »

stcredzero wrote: post #42

> A straightforward solution of the problem is superior to one that makes you feel like a high priest for having discovered it. It is also much better for the team and the company. Beginning musicians are just trying to play. Intermediate musicians are try to play as fancy as they can. Master musicians play what's needed by the tune. It takes somebody who's past all the ego issues to devote their intelligence to maki…

Reminds me of this old Zed Shaw essay:

http://zedshaw.com/essays/master_and_expert.html

I think at least two of Go's designers, Ken Thompson and Rob Pike, are true programming masters.

Note: When I posted this comment before, I accidentally pasted the wrong URL.

Re: Replacing Clever Code with Unremarkable Code in Go

#50

Post by JeanPierre »

cwzwarich wrote: post #28
peterwaller wrote: post #4

I think this is one of the really great things about Go. Some detractors ask "There is so much to be gained by having generics! What would be lost if Go had generics? Nothing! Ergo, Go is wrong to not have generics". This line of argument is flawed. Go curbs the ability of people to write crazy (and ultimately mentally expensive) abstractions. The lack of generics in Go is very a good thing. Especially when it comes…

If anything, generics reduce the mental expense of reading code, because if a container has a generic value type I know that it isn't going to be doing something interesting to those values behind the scenes.

I would like to add on to this:

Generics may not be the correct solution, but I would really like a way to make collections which are general enough to be used by any datatype. As of now, I cannot do that without doing the typical `interface{}` approach.

The built-in data structures + channels are able to handle this, but if I just want a set of elements, what do I do? Make a `map[foo] bool`? If I see such a piece of code in an unfamiliar code base, I have no idea whether to test for key existence or whether I have to test whether the bool is true. A generic set would leave me puzzled and type unsafe[1]: What types could possibly exist in this set? A set of foos is not that hard to comprehend, and is in fact very much more straightforward to understand than a generic set, which in unfamiliar code may contain anything, or a mapping from foos to bools.

[1]: Rob Pike mentions in http://www.youtube.com/watch?feature=player_detailpage&v... that type safety is of high importance for Golang, but how does one achieve that if all the different datatypes I implement/need use `interface {}` where I have to cast all values afterwards? That seems very type unsafe, from where I stand.

Post reply on HN