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.
Replacing Clever Code with Unremarkable Code in Go
31–40 of 140 posts
Re: Replacing Clever Code with Unremarkable Code in Go
#32Earlier quoted context omitted.
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…
Looks like you can use STM in Haskell: http://stackoverflow.com/questions/5879128/a-way-to-form-a-s...
Thanks for posting this. I found something similar but on first blush didn't think it was quite right as I was mistakenly thinking that you could only do this for TChans with the same type. Looks like it might be just what I'm after! When I think about it, STM seems like it makes sense here, since you probably want the ability to cancel/rollback the blocking gets that didn't return.
EDIT: Actually, this isn't right. The example linked does "if get from channel 1 fails, get from channel 2". I'm looking for "select" on multiple channels, where the result is based on the first channel to return.
EDIT again: Apparently I can't read, and this does achieve what I'm looking for, I just have no basic experience with STM. Awesome, will try this later!
Re: Replacing Clever Code with Unremarkable Code in Go
#33Hmm, up till now I though Go wasn't anything special, but now I'm certain I will check it out.
Re: Replacing Clever Code with Unremarkable Code in Go
#34I 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.
That's only true in a language with type inference and type aliases.
In Java, generics make your code completely unreadable, as content is buried in boilerplate. Map,ReadyState ops; for (Entry,ReadyState e: ops.entrySet()) { ...
In Go, generics would be an unqualified win for the author/reader. No one disputes that. The only dispute is over the compiler and runtime costs.
Re: Replacing Clever Code with Unremarkable Code in Go
#35I 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…
>This line of argument is flawed
I don't think you intended that as a preface to your flawed argument, but it worked out well. No, the lack of parametric polymorphism is not a good thing. You are losing simplicity, not gaining it.
Re: Replacing Clever Code with Unremarkable Code in Go
#36I 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.
That is not true in C++. std::vector is not really what you would have expected.
Re: Replacing Clever Code with Unremarkable Code in Go
#37http://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'm not sure what your point is, whether you think go is simple and powerful like lisp, or the new java, but simply quoting "The Blub Paradox" makes you sound pretentious (on a site where the largest percentage of readers are probably already familiar with said essay nonetheless). I don't think this is really applicable to the article anyway, since it's an article commenting on two very different languages and progra…
>I'm not sure what your point is, whether you think go is simple and powerful like lisp, or the new java
Really? I find it hard to believe you can't tell what is intended. It certainly is applicable to the article, as the article can be summarized as "I've moved up a language on the blub line, and now my old perfect language is clearly inferior, but my new blub is perfection incarnate".
Re: Replacing Clever Code with Unremarkable Code in Go
#38Earlier 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.
That's only true in a language with type inference and type aliases. In Java, generics make your code completely unreadable, as content is buried in boilerplate. Map ,ReadyState ops; for (Entry ,ReadyState e: ops.entrySet()) { ... In Go, generics would be an unqualified win for the author/reader. No one disputes that. The only dispute is over the compiler and runtime costs.
Generics (outside of C++'s templates which are a pretty odd duck[1]) generate very little compiler costs and little to no runtime costs (depending whether they're erased or reified), unless you decide to (optionally) trade some added compiler costs for some runtime improvements by generating type-specialized collections behind the scenes.
[1] and their cost is seriously compounded by the rest of C++, D has C++-style generics with a far lower compilation cost
Re: Replacing Clever Code with Unremarkable Code in Go
#39Earlier quoted context omitted.
Really? I thought the reason Go didn't have generics is because they couldn't decide on an implementation that met their goals? That is, was quick and didn't emit a ton of code.
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
Re: Replacing Clever Code with Unremarkable Code in Go
#40Earlier 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.
That is not true in C++. std::vector is not really what you would have expected.
C++ templates aren't generic (or more specifically, aren't parametric) for a few reasons, one of which being that they contain a hidden overloading mechanism.