> A launch title like Half-life 3 (seems unlikely with the circle + circle logo implying you need multiple SteamOS instances).
I think Left 4 Dead 3 (long rumored) is more likely.
367 karma · joined February 10, 2012
I think Left 4 Dead 3 (long rumored) is more likely.
I don't think so: http://en.wikipedia.org/wiki/List_(abstract_data_type)
That post discusses six languages but others can be easily added.
However, in other situations the Haskell approach is much better. Say you have a Java class with five fields, three of them are nullable (i.e. have a sensible notion of being null) and two are not (have to be non-null unless there is a programming error). There are tons of places where you can mess up: assign null to an invalid variable, assign "x = f()" not noticing f can return null, call "y.f()" forgetting that y can be null etc. However, if your type system handles nullability, you will get a compile-time error on each of them. More: if you change nullability of a field, compiler errors will point out places that have to be changed.
By throwing an exception when you "know" an element in the hashmap has to be there, you resign from safety offered by the compiler. In Haskell this is a code smell; Haskellers are less content with such hacks and might try to redesign the structure so that the invariants are enforced by the type system.
Source: http://www.quora.com/Computer-Keyboards/What-is-the-origin-o...
[1] https://twitter.com/NewsBreaker/status/348800297700835328
However, in absence of a preprint, it's IMO too soon to make announcements.
You can't be helped by using "my own words"; my own word for "polynomial" is "polynomial", it is commonly accepted and understood by the computer science community. It can't be dumbed down.
First of all, P=NP is not a "theory"; it's a _question_. We do not know whether the answer is "yes" or "no"; most experts suspect that the answer is "no", i.e. P is not NP. There were attempts to prove it both ways, none successful or even remotely close. The theory encompassing the question is called computational complexity. It is a relatively new field (foundation is often taken to be ~1965), and many questions are open. However, we do make progress and each year there are breakthroughs. People hope to solve it some day - history shows that many open problems in mathematics resisted for long, but they were finally solved after centuries of thinking.
"I want it in simple words so it is easy to understand"
The definition of P and NP uses things such as "decision problem", "polynomial running time", "nondeterministic" algorithm or Turing machine etc. You need effort to understand them. You have to read about those prerequisites, internalize them in your mind, and only then it will become understandable. "Simple words" won't help in overcoming that. You might have heard lots of intuitive musings about P=NP and are not satisfied. The only cure is rigor.
I hope you will not take my words as condescending, but it is not helpful when you say "it makes no sense to me"; it's like someone told you "the program does not work", how are you going to help that person? You need to have a leg to stand on. What you do understand from explanations, what do you not understand from them?
The point of subtyping is implicit coercions: using a type T1 when T2 is expected, without extra conversion. Dynamic and existentials are not subtypes (you need fromDyn or the data constructor introducing the existential). OOHaskell is as far as I know a failed and abandoned experiment. Who uses it? I don't know HList enough to comment, but it's based on GHC's constraint system and very much unlike subtyping in Scala. I agree with you that OOP is not the same as subtyping.
Here's how variance complicates stuff in Scala: http://www.reddit.com/r/haskell/comments/zxcks/haskell_vs_f_...
>> The ecosystem matters the least when learning for learning sake.
> Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular [...]
No, the comparison with Python is not fair. Python is a polar opposite of Haskell.
People learn Python as a scripting language. You can learn the basics of the language extremely fast. There's little didactic value in Python the language once you know imperative programming. Then real work comes by learning libraries, frameworks, APIs etc.
People learn Haskell as a way to broaden horizons, see a different paradigm. GHC, with standard library only (covering a lot less than Python's batteries) gives enough material to experiment for months if not years. It takes a while to understand GADTs, type classes, kinds, higher-order types, type families etc.
Learning Haskell is much closer to learning proofs/doing puzzles than software engineering. The fact that you made your program compile after two hours is rewarding like solving a puzzle.
I have seen people attempting to build a concurrent web server in Haskell in first week, not knowing how laziness or class instances work and blaming Haskell for making things weird and unintuitive. The practical mindset of Python does not pay off in Haskell. So I agree with OP - the ecosystem is least concern when learning FP for learning sake.
Aumann's agreement theorem [1] states this is not the case.