Only if you are inside the cult could you possibly believe that. Do you also think that Jim Jones was an expert on the New Testament teachings? If you take his word for it, of course he was.
Only if you are inside the cult could you possibly have that opinion. Do you also think that Jim Jones was an expert on the New Testament teachings? If you take his word for it, of course he was.
I think the right way to think about that is: "what solutions has lack of generics prevented me from writing?". From the expressive end of the power continuum, Go is way down there (somewhere below Blub probably).
The portion of that material which is requisite is obviously a strict subset of the entirety of the material. But, for one to flippantly say "I've read it" without even establishing what "it" is, seems a bit dismissive and duplicitous to me. Regardless it is obvious to anyone who is knowledgeable that Rob Pike has not read what most who are in the know would consider "requisite".
Also, if you take a look at the thread I posted, his attitude and approach re: map, filter & reduce doesn't come across as the most academic or well thought out.
If this area is going to be marked off, then I would appreciate my mod points being restored as well. If you look at my original response, it was pointing out the fallacy in a very particular claim (and nothing resembling a 'flame war').
To the siblings to this post: it seems rather unlikely as the research is being generated at a rate that far exceeds any one person's ability to read it (especially when they are already busy marrying C and CSP [which is easy to build as a library or add-on to any other existing language] & type theory isn't their specialty).
Which will have no bearing on the case of Go. Go has already been relegated to the bottom of the quality bin for my purposes by its designer(s)' ignorance of the last 30 years of type system research and hostility towards the functional style.
There is an encoding supporting that level of abstraction (perhaps though not as straightforward as you'd prefer); namely using interfaces (which are first-class) to encode module signatures. See: https://gist.github.com/t0yv0/192353
We don't have to encode arbitrarily large natural numbers. Rather we have to encode the rules that allow us to construct them (which is quite simple actually). And, I think 'digital physics' is more compatible with Incompleteness implications than the alternatives; not less.
I see this as a last ditch attempt by Microsoft to stay semi-relevant. Of course this was the great promise of .NET to begin with, but it seems rather late to exercise the option now (some 15 years or so after .NET was created)-- a very desperate move by a dying empire.
> F# has a number of these specific implementations but they're kind of "hard-coded" in the language rather than fully extensible.
That's not true. You can extend the language yourself with "computation expressions" (and that's in fact how the 'async', 'let!' et al keywords are implemented).
The operators on collections always have alternate named forms. I actually instinctively skip over the operators when perusing the documentation and have no trouble at all finding what I need.
Not to be 'that guy'TM but I think your last sentence is missing at least a word. Also, there are comma splices throughout. :) [Maybe that was the real reason you had trouble finding a job writing]. [just kidding] :)