Here's the video: http://youtu.be/1PhArSujR_A (the text on the page just introduces Carmack)
He starts talking about FP/Haskell at the 2:06 mark.
John Carmack: Thoughts on Haskell [video]
21–30 of 153 posts
Re: John Carmack: Thoughts on Haskell [video]
#22Very worth noting that Carmack here is talking much about "pure functional programming" above just functional programming.
Re: John Carmack: Thoughts on Haskell [video]
#23Earlier quoted context omitted.
No, typically functional languages end up copying more , not less, since typical algorithms will e.g. return a fresh copy of the modified structure - the purists detest mutation. The benefits of data sharing, are, imo, overstated outside of a few niche, datastore-y type areas.
They may appear to be returning a fresh copy, but internally much of the structure is shared rather than copied. See Persistent data structure: http://en.wikipedia.org/wiki/Persistent_data_structure
Much is shared, yes, but compared to a traditional approach with static arrays, there is a _lot_ of copying in a typical FP approach.
Re: John Carmack: Thoughts on Haskell [video]
#24Earlier quoted context omitted.
Functional languages generally encourage the use of persistent data structures. Algorithms that modify persistent data structures do not generally return 'fresh copies'. If you use the proper data structures in Haskell or Clojure your 'typical algorithms' will not return fresh copies. That being said, whether data sharing is a good thing or not depends on the situation. For example, copying to a cache can expose more…
You might be surprised just how much churn there is if you look at the source of, for instance, Haskell's Data.Map, which in the name of immutability is implemented as a balanced binary-tree representation, rather than the more common hash table. Many operations that are amortized O(1) with a hash table are O(log N) with a balanced B-tree, since for instance after an update a all the sub-trees around the update site…
Somehow the difference between O(1) and O(log32 n) has never actually been an issue for me in Clojure.
Re: John Carmack: Thoughts on Haskell [video]
#25I'm still waiting for his in depth article about his experiences while porting Wolfenstein to Haskell - mainly to see if it's worth learning Haskell. Beacause as he said in the video: Most examples in books (I guess that counts for evangelization blogs too) are toy examples. And I'd like to know how viable the language is for bigger systems.
This is highly anecdotal, but I've built and been part of very practical/non-theoretical, large Haskell projects (100k+ lines, which is a lot for Haskell). The only big complaint I have is that it's somewhat hard to do loose coupling, i.e. for something somewhere to reference a type without either redeclaring the type (when that's possible), or having a huge, centralized Types.hs that declares all the types that are…
How long does it take to compile the whole codebase? If you know.
Re: John Carmack: Thoughts on Haskell [video]
#26Earlier quoted context omitted.
Laugh as you might, but this is the interface of Datomic, the database system by Rich Hickey, the creator of Clojure. To perform a query, you connect to a database and request the present state of the database. This is an immutable representation of the database at that point in time, and you can query it however you like, or even hold on to it forever. Of course, the database isn't actually fully copied.
Sounds a bit like SET ISOLATION LEVEL SERIALIZABLE?
No, it's far more elegant than that. Datomic makes the entire database an immutable, persistent data structure. This means that anyone can grab the database as a value -- at any point in time, past or present -- and never have it change behind their back. There are no read transactions whatsoever and clients have the power to conduct their queries offline. This lets you easily scale read operations without limit. The only bottleneck in the system is a dedicated server known as the transactor which handles the coordination of all updates.
Re: John Carmack: Thoughts on Haskell [video]
#27Earlier quoted context omitted.
I don't really get the joke. Generally functional languages will share more data than imperative languages, and therefore will copy less data. In an imperative language, it makes sense to copy whatever data you are working on, so your modifications don't inadvertently affect other parts of the program. In Haskell it doesn't. Explain?
No, typically functional languages end up copying more , not less, since typical algorithms will e.g. return a fresh copy of the modified structure - the purists detest mutation. The benefits of data sharing, are, imo, overstated outside of a few niche, datastore-y type areas.
At the level of source code logic it appears to be copying and returning a new data structure. That doesn't mean the compiled, optimized code is performing all the copies that the the program appears to be doing.
Pure FP = don't mutate variables in the program. Of course the actual implementation can reuse memory blocks or else pure FPers would have to keep buying new memory!
Re: John Carmack: Thoughts on Haskell [video]
#28Earlier quoted context omitted.
Functional languages generally encourage the use of persistent data structures. Algorithms that modify persistent data structures do not generally return 'fresh copies'. If you use the proper data structures in Haskell or Clojure your 'typical algorithms' will not return fresh copies. That being said, whether data sharing is a good thing or not depends on the situation. For example, copying to a cache can expose more…
You might be surprised just how much churn there is if you look at the source of, for instance, Haskell's Data.Map, which in the name of immutability is implemented as a balanced binary-tree representation, rather than the more common hash table. Many operations that are amortized O(1) with a hash table are O(log N) with a balanced B-tree, since for instance after an update a all the sub-trees around the update site…
The balanced binary tree of Data.Map is nowhere near state of the art in terms of persistent data structures. Clojure (and Haskell's unordered-containers library) use Hash Array Mapped Tries (HAMTs) which have a much higher branching factor (32-ary) than binary trees. In practice, this is a neglible difference from constant-time.
Re: John Carmack: Thoughts on Haskell [video]
#29Earlier quoted context omitted.
No, typically functional languages end up copying more , not less, since typical algorithms will e.g. return a fresh copy of the modified structure - the purists detest mutation. The benefits of data sharing, are, imo, overstated outside of a few niche, datastore-y type areas.
At the level of source code logic it appears to be copying and returning a new data structure. That doesn't mean the compiled, optimized code is performing all the copies that the the program appears to be doing. Pure FP = don't mutate variables in the program. Of course the actual implementation can reuse memory blocks or else pure FPers would have to keep buying new memory!
Pure FP doesn't have variables. It has bindings.
Re: John Carmack: Thoughts on Haskell [video]
#30AFAICT he doesn't reach any particularly satisfying conclusions and just speculates that Haskell is an interesting avenue of research that may bear fruit for game development.
It doesn't seem like he has put the same amount of effort in experimenting with Lisp. He doesn't mention any attempt to port Wolfenstein over to Common Lisp. Instead he seems content speculating from the same position many Lisp doubters have after reading a few books and working on some exercises (which is ironic considering his impetus for the Haskell project). I hope he gave Lisp the same treatment as Haskell before he drew any conclusions but it doesn't seem like he has from this speech.
Lisp for game development could be an interesting avenue (and has precedent in AAA console development). The dynamic vs. static argument isn't the interesting feature. Personally I think the symbolic model of computation is far more compelling. I've read posts by programmers who've written a high-level language for writing financial trading algorithms in Common Lisp that compile down to optimized VHDL for running on FPGAs. Sure you don't have a static analyzer to tell you you've done something wrong before you run your programs but I've rarely seen that becoming an issue in practice at that level. There are plenty of Common Lisp libraries that have been around for a long time that don't require much maintenance which makes me wonder where this belief that dynamic languages don't produce solid, maintainable code comes from.
In my rather limited experience I find the over-specification required by statically typed language to be a impedance to writing robust, compose-able software (at least it's much more difficult and tends to lead to Greenspunning if you try to go that route).
Either way... a very interesting talk and it's cool to hear that he's experimenting with this stuff. Carmack is in a rare position to have such a breadth of experience and deep technical knowledge that even just messing around with this stuff might make waves throughout the industry.