yohanatan

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.

See: https://news.ycombinator.com/item?id=8605321

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).

http://www.paulgraham.com/avg.html

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).

Totally serious. And, it's not just the lack of generics-- that's just the tip of the iceberg.

Probably a combination of both really. I get the sense that the 'Commander' hasn't done the requisite reading.

Nope, nothing at all like that.

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.

I think a succinct way to put it is: on-the-fly "profile-guided optimization". A good JITter will do this automatically (as you said).

Downvoters: if you disagree, feel free to post an attempt at a refutation or somehow otherwise explain your vote.

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] :)

Downvoters: if you disagree, feel free to post an attempt at a refutation or somehow otherwise explain your vote.

But the reals are irrelevant as far as Incompleteness is concerned. He's obviously confused.

I'm not so sure that the pharaoh in the background was impressed.

It doesn't take 'infinite complexity' [your term] to encode the natural numbers. Rather it is only a handful of axioms. See: http://en.wikipedia.org/wiki/Primitive_recursive_arithmetic

Pretty much any system of logic worth looking at (including any which the sciences may be based on and the one running inside each human brain) is going to at least be as complex as this set of axioms.

Also, you really should read the JR Lucas material-- it explains this. And, I'd suggest Nagel & Newman's _Godel's Proof_ for a great introductory explanation of the Incompleteness Theorems.

That premise is definitely true. It is a result of Gödel's Incompleteness Theorems. 'Physics' certainly satisfies the constraint: 'of sufficient complexity to encode the natural numbers'.

See: http://users.ox.ac.uk/~jrlucas/Godel/implic.html [particularly "reality outruns knowledge"]

Rust is not your typical lower-level language though. It supports a lot of the features that functional programmers expect. It is an eagerly evaluated language that lets you drop to 'unsafe' code where necessary but in its natural form, it is surprisingly high level.

There are several languages targeting the JVM these days. And, what obviously sets Clojure apart from other JVM languages is its Lispiness (i.e., the JVM is constant across JVM languages).

Clojure is not married to the JVM either-- in fact, it has been hinted that it would jump ship if something better comes along or the current situation becomes less viable. Furthermore we already have a dialect of Clojure called ClojureScript which targets JavaScript/node/V8.

And, I look at the JVM as really merely a library/API/runtime. C++ has STL and stdio and such and they are not part of the language proper but rather merely libraries for interacting with the underlying operating system (in a platform independent way). The same is true for the JVM with respect to Clojure and Scala et al.

I think the same is true for F# and Scala.

> Even worse than the problem of uncommon concepts as monads

Just go ahead and learn the typeclass hierarchy and such-- it really is quite a useful higher level of abstraction in whatever language you choose. And it definitely will enter the mainstream (even more than is already has [Swift, Scala & C# all have monadic constructs]).

> Haskell's memory footprint is extremely hard to reason about.

And you'd probably want to also throw runtime in there as well.

I think this is relative-- it's not "extremely hard" for everyone. Also, many structured programmers found object orientation "extremely hard" but somehow the industry managed to progress through that era.

> I agree Haskell has had an important influence, but I don't see why people would necessarily "go directly" to it because of that.

I also said "or one of its direct descendants" (like Agda or Idris in all likeliness).

> To wit, Lisp never became mainstream

Clojure doesn't count? And the good parts of Perl, Ruby & Javascript are essentially Lisp without the homoiconicity.

> I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream.

I don't think it is at all obvious that Haskell won't become mainstream. It's already exerted a tremendous influence over many other mainstream languages and there's only so long that can happen before people just start going directly to the source of the innovations (or one of its direct descendants).

A hybrid multi-layer cache system would likely be more cost effective and still perform nearly as well as dedicated RAM (depending on how the data is structured/sharded/queried).

I have a similar idea where the cores are put to work optimizing the produced binaries (profile-guided optimization, genetic algorithms, SAT solvers/theorem proving, etc). You could of course also do static analysis and all forms of testing (generative, property-based, unit, integration, performance, etc.).