Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.
To be fair he was probably saying in his own way that he really liked what the STL does for him in C++. For the purpose of argument, though, let's take his claim at face value.
What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.
But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.
That's the detail that sticks with me.
Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.
My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy. And you know what? Type hierarchies are just taxonomy. You need to decide what piece goes in what box, every type's parent, whether A inherits from B or B from A. Is a sortable array an array that sorts or a sorter represented by an array? If you believe that types address all design issues you must make that decision.
He seems to be vulnerable (as so many of us are!) to forgetting that his current set of applications isn't the whole world.
I always assume that Rob just forgot to include the words "Google backend" in front of "systems language".What else do you want? We are in the age of cloud computing.
Like that time he said you don't need to care about endianness because only compiler writers like himself need to know about it.
uint8_t *lebuf;
uint32_t val;
val = 0
| (lebuf[0] << 0)
| (lebuf[1] << 8)
| (lebuf[2] << 16)
| (lebuf[3] << 24);val = *(uint32_t *) lebuf;Show me a modern codec that doesn't care about endianness.
Like that time he said you don't need to care about endianness because only compiler writers like himself need to know about it.Yeah. Values with matching endianness can save you 4x time, so you can just pixel = pixels[XY]
I'd hope that any endianess issues would be handled in the format demux code
Suppose: the raw stream is in memory, the CPU clock rate is in the low/mid tens of MHz with memory clocked to match, memory is not byte-addressable, the cache is write-through and there are two three other processors talking to RAM. Demux will still be pretty quick in isolation, by using something like 4-8x as much memory bandwidth.
The point was Pike didn't make it in the spirit of kindness. He granted exception to exactly one class of person, one he finds himself in. He pulls this shit all the time. When people didn't flock to Go in big enough droves, he complained that the hangers-on were stupid/ignorant/whatever.
Contrived statistically insignificant examples much?
where the compiler isn't smart enough, tweaking the source isn't always the best answer.
<vanila> yeah I don't think you guys have understood what I'm suggesting, that would explain Tv` who is normally intelligent calling me a trollHello, vanila.
Tv`!*@* added to ignore list.
Is this some sort of imageboard thing?Yes