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

71–80 of 140 posts

Re: Replacing Clever Code with Unremarkable Code in Go

#71

Post by discreteevent »

TikiTDO wrote: post #64
xaprb wrote: post #22

Earlier quoted context omitted.

It's tough to give examples of this in Perl without a lot of narrative (and sometimes a lot of code), but the technique I'm referring to is currying: programs that write programs, via functions that write functions. This, of course, is what you do all the time in LISP. It takes half the (Higher-Order Perl) book to illustrate the technique and its power. Which is kind of the point: shouldn't it be a commonplace thing…

> shouldn't it be a commonplace thing that doesn't take so much work to get around to explaining and using? Why? It's a reality of the world that more complex things take more time and more effort to learn. However, often that is because these more complex things allow you to do a lot of very useful things much more efficiently. I would prefer to drive over a bridge built by an engineer who learned all those difficul…

" I would prefer to drive over a bridge built by an engineer who learned all those difficult equations, material properties, and buildings codes as opposed to a high school kid with a few physics courses under his belt."

I think this kind of analogy is misleading. Those things are more like the equivalent of understanding data structures and algorithms, performance estimation, being able to use a profiler effectively etc. Civil eng is very conservative in terms of the kinds of language and graphics that can be used to express a design. Anyone doing the equivalent of currying or macros (making up ones own language) would be thrown out. I would think its probable that when programming is as old as engineering its modes of expression will be similarly limited/standardised.

Re: Replacing Clever Code with Unremarkable Code in Go

#72

Post by coldtea »

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…

>I have been productive in Go and haven't missed the ability to write generic code so far. Usually it turns out there is another way to achieve what you want without them.

Yes there is. Involving more code, less DRY, or loss of type safety.

Re: Replacing Clever Code with Unremarkable Code in Go

#73

Post by mkehrt »

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…

I'm super pro generics and love me some Haskell and ML. However, generics really do have a cost. Since the size of the objects in a generic container can vary, you either need to take the ML route of making everything a pointer (which add runtime cost) or the C++ (yeah, not really generics, but still) route of duplicating the code for every size object you store in the container. While I think Go made the wrong choice with generics, I understand their thought process.

Re: Replacing Clever Code with Unremarkable Code in Go

#74

Post by mc-lovin »

This article didn't make much sense to me. In particular, what was it about the problem that prevents having a "stage" object with a "do_stage" method, which takes the input object and returns the output object (or some error code etc.).

I feel like the answer has to do with concurrency but the description in the article was to vague to get a more precise idea.

Re: Replacing Clever Code with Unremarkable Code in Go

#75

Post by comex »

masklinn wrote: post #67
comex wrote: post #63

Earlier quoted context omitted.

Depends what you're comparing against. If it's a poor man's generic implementation in current Go using interface{}, then obviously there would be no extra runtime overhead if the compiler generated that for you in a type safe manner; but compared to manually specialized collections or the built-in generic collections, there is quite a lot of runtime overhead. Whether the compiler costs are manageable or not is up for…

The built-in collections can remain built-in if that gets you off. Same deal for manually specialized collections, except those aren't generic, so they remain not generic.

I think those are both rather bad solutions; I want generics precisely because they can provide equal performance to the built-in collections without the obvious drawbacks of a limited set of primitives or manually copying code. I'm just saying that "very little compiler costs and little to no runtime costs" is somewhat misleading, because there are significant runtime costs compared to those alternatives; Go needs code generation based generics, which are certainly doable, but incur significant complexity and runtime design issues.

Re: Replacing Clever Code with Unremarkable Code in Go

#76

Post by cgag »

It's so strange to me that people describe things like higher order functions and map/filter/reduce as being clever / complicated and think manual iteration and indexing into an array is "simple".

I hate to keep linking to this talk because I don't want to look like too much of a clojure fanboy, but I think a lot of people would benefit from re-examining their definition of simple: http://www.infoq.com/presentations/Simple-Made-Easy

Re: Replacing Clever Code with Unremarkable Code in Go

#77

Post by TikiTDO »

discreteevent wrote: post #71
TikiTDO wrote: post #64

Earlier quoted context omitted.

> shouldn't it be a commonplace thing that doesn't take so much work to get around to explaining and using? Why? It's a reality of the world that more complex things take more time and more effort to learn. However, often that is because these more complex things allow you to do a lot of very useful things much more efficiently. I would prefer to drive over a bridge built by an engineer who learned all those difficul…

" I would prefer to drive over a bridge built by an engineer who learned all those difficult equations, material properties, and buildings codes as opposed to a high school kid with a few physics courses under his belt." I think this kind of analogy is misleading. Those things are more like the equivalent of understanding data structures and algorithms, performance estimation, being able to use a profiler effectively…

> Civil eng is very conservative in terms of the kinds of language and graphics that can be used to express a design.

I would argue that programming is far more specific in terms of the kind of language can be used too. In fact each such language tends to be described in exhaustive specs.

> Anyone doing the equivalent of currying or macros (making up ones own language) would be thrown out. I would think its probable that when programming is as old as engineering its modes of expression will be similarly limited/standardised.

Both things are very broad when it comes to what can be made using those languages. A civil engineer may use his language to build a house, a sky-rise, and a nuclear power plant. Each of those will have different complexities, and a different requirements of knowledge and qualifications. In fact I imagine the Engineer working on the latter will know how to do a lot of things that the Engineer who works on the former would consider to be akin in complexity to currying and macros.

The situation is the same in programming. Some people may be working on projects currying, macros, and other techniques are a major benefit. These are after all extremely powerful tools. Just like with the Civil Engineer, the challenge is knowing how to use them properly.

Re: Replacing Clever Code with Unremarkable Code in Go

#78

Post by Osmium »

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.

Interesting essay, thanks for the link.

I found this part interesting, in contrast to his "expert amateurs" like Knuth:

> In contrast there are masters in the martial arts who learned their art as a means of survival and became masters in a realistic and hostile environment. We don’t have anyone like this in the programming profession, or at least I haven’t met any.

Any candidates spring to mind? John Carmack maybe? I'm sure there are loads though.

Re: Replacing Clever Code with Unremarkable Code in Go

#79

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

#80

Post by azth »

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…

> Whether by design or accident...

It seems to have been by accident, as they were originally designing it to be a "systems" programming language to take on C++. What eventually happened is that most(?) Go programmers came from Python, Ruby, and other scripting languages.

> 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 different language.

So much for it being a "systems" language then :)

Post reply on HN