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

51–60 of 140 posts

Re: Replacing Clever Code with Unremarkable Code in Go

#51

Post by [deleted] »

koenigdavidmj wrote: post #26
tome wrote: post #13

Earlier quoted context omitted.

Limiting power was the argument for making Java crippled too. On the topic of generics specifically, parametric polymorphism actually makes code simpler, see e.g. Haskell.

Whether by design or accident, Go is filling the use case of "you tried Python but performance wasn't good enough". People will bring up cases like "you can't write a generic map function, or tree data structures!", but Go isn't the language for those things. In Go, you would just use a for loop or a dictionary-based map. If your program gets to the point where that no longer cuts it, then it's time to move on to a d…

[deleted]

Re: Replacing Clever Code with Unremarkable Code in Go

#52

Post by papsosouid »

masklinn wrote: post #45
aodin wrote: post #39

Earlier quoted context omitted.

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

Unfortunately, that is their thought process. I find it hard to believe Rob, Russ, etc actually genuinely have never heard of ML, but everything they ever say on the issue suggests that is the case. And when people keep showing them "hey look, this problem was solved 30 years ago!" they just outright ignore them and don't acknowledge it.

Re: Replacing Clever Code with Unremarkable Code in Go

#54

Post by stcredzero »

shurcooL wrote: post #46
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…

> Smart/complex code that works is a great intermediate step though, it's way better than no code. :)

I'm totally with you on that. Often, the way to solve a problem is to first solve it wrong. In the process of doing that, you can see the way to solve it right. Trying to reach the endpoint in one fell swoop of envisioning and coding is actually another beginner move I've seen a bit.

What I'm totally not down with is complexity as an end goal. And yes, I've seen this mentality in programming.

Re: Replacing Clever Code with Unremarkable Code in Go

#55

Post by Dylan16807 »

VeejayRampay wrote: post #31

For the love of Thor, please provide a few code examples illustrating the content, hard to get an idea of how to simplify things with Go with mere words and ideas.

Definitely. I'm left with no idea how Go actually helps. You can trivially implement 'pipelines' in any language by making a handful of queue structures and using them to feed your functions. Why were there callbacks in the first place?

Re: Replacing Clever Code with Unremarkable Code in Go

#56

Post by fixxer »

Clever is not smart.

Consider this anecdote: I recently put together a DIY 3d printer. I didn't have the right tools to cut steel bar, so I made a clever jig and used a shitty Dremel without enough clearance. Clever? Yes -- it got the job done with limited resources. Smart? No -- dumb, actually. Smart would have been driving 15 minutes to Harbor Freight to buy a $20 cut-off saw.

Re: Replacing Clever Code with Unremarkable Code in Go

#57

Post by joe_the_user »

VeejayRampay wrote: post #31

For the love of Thor, please provide a few code examples illustrating the content, hard to get an idea of how to simplify things with Go with mere words and ideas.

Yeah,

It is quite hard to read a stream of text about programming without examples.

But reading it, it seems like his problem could be more with Perl, which certainly has a reputation of supporting and encouraging unnecessary complexity. But argument is so vague, you could write the same article with Python substituted for Go - at least as far as the knowledge the article gives one about Go goes.

Re: Replacing Clever Code with Unremarkable Code in Go

#58

Post by gngeal »

mwcampbell wrote: post #49
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.

I’d love someday to hear a young coder tell a story about someone they idolized like, “There was this guy I worked with who once optimized a complicated red- black tree getting 300% performance boost. I was baffled and ask, ‘How’d you do that? That’s impossible.’ To which he responded…”

“‘That’s my linked list my son.’”

I believe that this is exactly what Niklaus Wirth did in the Oberon compiler.

Re: Replacing Clever Code with Unremarkable Code in Go

#59

Post by henrybaxter »

fixxer wrote: post #56

Clever is not smart. Consider this anecdote: I recently put together a DIY 3d printer. I didn't have the right tools to cut steel bar, so I made a clever jig and used a shitty Dremel without enough clearance. Clever? Yes -- it got the job done with limited resources. Smart? No -- dumb, actually. Smart would have been driving 15 minutes to Harbor Freight to buy a $20 cut-off saw.

Smart might be to buy a cut-off saw. Brilliant would be to find a working cut-off saw with blade for $20!

Re: Replacing Clever Code with Unremarkable Code in Go

#60

Post by scarboy »

JeanPierre wrote: post #50
cwzwarich wrote: post #28

Earlier quoted context omitted.

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…

You should be using map[T]struct{} for sets instead of bool. struct{}s use 0 bytes and there will be no confusion as to what the value is for.
Post reply on HN