15 ms·

John Carmack: Thoughts on Haskell [video]

217 points by trevorhartman 13y ago

ExpiredLink 13y ago
> Error establishing a database connection Diabolic, stateful database connections blocking a Haskell treatise! They should have copied the database on each request instead.
- Tuna-Fish 13y ago
  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.
  - __alexs 13y ago
    Sounds a bit like SET ISOLATION LEVEL SERIALIZABLE?
    - chongli 13y ago
      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.
      - AlisdairO 13y ago
        Looks interesting. The docs make it sound like a temporal triple store which you can (lazily) make replicas of. How is consistency handling performed? Does it rely on knowing my snapshot version and checking for write conflicts (a la oracle SERIALIZED level), or is it based on explicit locking?
        chongli 13y ago
        There are no snapshots (or you could say that everything is a snapshot); you can get a value of the database from any moment in time, stretching all the way back to the creation of the database. All transactions are performed against a stable view of the database (its value at a moment in time) and either succeed or fail entirely (they are atomic). Once a transaction is validated and sent to storage the new data can be communicated to all clients and cached indefinitely; it will never change. Datomic has no notion of mutation/destruction. Data is stored in the form of facts which are asserted or retracted. Retracted data can still be retrieved from an earlier moment in time, so it isn't really gone. In many ways, it has a lot in common with DVCSs such as git (though it has only a single authority with commit access: the transactor).
        AlisdairO 13y ago
        I would rather say that everything is a snapshot - presumably I am working at a particular timestamp level - i.e. I won't get some facts that were valid at Timestamp A and some that were valid at Timestamp B. My question is if/how you do conditional updates. Say I'm storing some particular concept C as a collection of facts, and I want to update fact C-1 to '15' if fact C-2 is '0'. In an RDBMS I might select for update fact C-2 to make sure it didn't concurrently change underneath me while I'm making the change - is there an equivalent in Datomic? I understand that under normal circumstances reads are completely decoupled from writes, but what if I want to make a write if and only if a certain state holds?
        chongli 13y ago
        Datomic lets you write a function and send it to the transactor. This is a pure function which runs against the database value (specified) and returns a new database value which becomes the result of the transaction (assuming it succeeds). Because Datomic is also a library in your application, you can run this function on the client side as a dry run (against a value of the database) before sending it to the transactor.
  - ExpiredLink 13y ago
    > Of course, the database isn't actually fully copied. You mean, Hickey just fakes it? Now I'm deeply disappointed.
    - DanWaterworth 13y ago
      No, it's not faking it. From what I understand it's copied lazily.
- chrismonsanto 13y ago
  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?
  - TylerE 13y ago
    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.
    - trevorhartman 13y ago
      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 http://en.wikipedia.org/wiki/Persistent_data_structure
      - TylerE 13y ago
        Much is shared, yes, but compared to a traditional approach with static arrays, there is a _lot_ of copying in a typical FP approach.
        mercurial 13y ago
        Sure, but in Haskell, a lot of it will be deforested by the compiler.
    - chrismonsanto 13y ago
      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 memory parallelism in an application. I feel like you are taking this opportunity to take a jab at FP here ("the purists detest mutation"). While FP is my preferred paradigm of development, I wasn't trying to push it on anyone--I was merely making a technical point.
sirclueless 13y ago
> Database Error: Error establishing a database connection Looks like we brought down another one. I was looking forwards to reading this too.
kybernetyk 13y ago
I'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.
- steveklabnik 13y ago
  You should check out Real World Haskell, it's much more practically focused than other things.
  - vbs_redlof 13y ago
    This book is starting to show it's age, lots of the examples are broken.
- thirsteh 13y ago
  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 used in different places (to avoid cyclic imports.) (Contrast with e.g. Go or ML where you have interfaces/modules without 'implements'.) This isn't unique to Haskell by any means, but it's the only real complaint I have about Haskell as a language for non-toy projects. The benefits definitely make it my go-to language. It's hard to list them all, but by far the nicest feeling is the correctness: when your code compiles, 60% of the time your program works every time. (Not to imply that tests aren't necessary--QuickCheck is great for that.) It's an otherworldly feeling to write a program not in terms of what to do, but what kinds of filters you want to put on something, and have it just work (and either stay working, or break future compiles if something's changed!) after compiling 10 lines of code, when you would have written at least 50-70 and had to debug it in almost any other language. Edit: I'll add another complaint: Haskell is like C++ in that it's incredibly easy for a codebase to become completely unmanageable if your team doesn't have a common style/discipline. Go is a nicer language for "average"/"enterprise" teamwork, I think, since it almost forces you to write programs in a way everyone will understand. If you're in a team with good programmers that you trust not to abuse the language, this is a non-issue. Edit: Okay, another one: If you change your Types.hs, the recompilation can take a long time in a large codebase, similar to C++. But GHC/Cabal keep getting faster. Think that's it.
srl 13y ago
Here's the video: http://youtu.be/1PhArSujR_A http://youtu.be/1PhArSujR_A (the text on the page just introduces Carmack)
- haxorize 13y ago
  He starts talking about FP/Haskell at the 2:06 mark. http://www.youtube.com/watch?v=1PhArSujR_A#t=126 http://www.youtube.com/watch?v=1PhArSujR_A#t=126
Strilanc 13y ago
Google cache: http://www.google.ca/search?q=cache:functionaltalks.org/2013/08/26/john-carmack-thoughts-on-haskell/ http://www.google.ca/search?q=cache:functionaltalks.org/2013... The article is essentially just a link to the fourth part of his keynote at Quakecon ( http://www.youtube.com/watch?v=1PhArSujR_A http://www.youtube.com/watch?v=1PhArSujR_A )
tel 13y ago
Very worth noting that Carmack here is talking much about "pure functional programming" above just functional programming.
agentultra 13y ago
AFAICT 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.
- bad_user 13y ago
  If you'll go read his opinions, you'll see that he has been a strong advocate for static analysis. His position is very understandable since he spent a lot of time working on complex pieces of C/C++ code, encountering a lot of subtle accidental errors that could have been avoided with better tools for static analysis or with a better language. He also worked mostly on client side software, where the fail fast / fail hard strategy of projects built in dynamic languages doesn't work so well. Lisp vs ML vs others is a very subjective issue since languages involve different kinds of trade-offs, so optimal choices depend on the project or on personal style. Also, this is John Carmack. For me he was a God 10 years ago and he's still one of the best and most practical developers we have today. Seeing him talk about Haskell is amazing. BTW, I've been a big fan of Scala lately, and I don't see myself using much Haskell precisely because its tools for modularity seem limited. In Scala you can use OOP to build abstract modules, with the much hyped Cake pattern being based on that. Dynamic languages are naturally more modular, however I still prefer static languages.
pohl 13y ago
I like this quotation: Languages talk about being multi-paradigm as if it's a good thing, but multi-paradigm means you can always do the bad thing if you feel you really need to, and programmers are extremely bad at doing sort of the the time-scale integration of the cost of doing something that they know is negative. I mean everyone will know...it's like "this global flag: this is not a good thing, this a bad thing - but it's only a little bad thing" and they don't think about how, you know, the next five years how many times that little bad thing is going to effect things. So brutal purity: you have no choice. In particular, I like the bit about integrating your technical debt function with respect to time, over the time you have to live with the debt, and how bad programmers are at thinking in those terms. We tend to think about how much technical debt we have at a given fixed point in time, but the area under the curve is what bites you.
- rybosome 13y ago
  Reminds me of something a former boss used to say. "Pay me now, or pay me later; either way, there has to be a payment". It sounds like Carmack is saying that brutal purity always forces the "pay me now" approach since it's harder to write this code, but it is worth it in the long run.
  - oneandoneis2 13y ago
    As credit cards have shown, people are very bad at making good decisions when they don't have to pay for them until "tomorrow"
  - orclev 13y ago
    That was more or less my take away as well, it forces you to deal with most of your technical debt up front and not let it pile up to some indefinite point in the future. Essentially brutal purity is a really strong anti-kruft coating. Since kruft can't stick to your code, it tends to stay nice and shiny well into the future, unlike the dirty impure code elsewhere that builds up a nice thick layer of kruft over time and eventually collapses under that weight (or else some poor soul ends up spending a bunch of time either scrapping all the kruft off, or just throws it out and builds a new one).
deleted 13y ago
[deleted]

217 points by trevorhartman 13y ago

> Error establishing a database connection Diabolic, stateful database connections blocking a Haskell treatise! They should have copied the database on each request instead.

Tuna-Fish 13y ago
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.
- __alexs 13y ago
  Sounds a bit like SET ISOLATION LEVEL SERIALIZABLE?
  - chongli 13y ago
    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.
    - AlisdairO 13y ago
      Looks interesting. The docs make it sound like a temporal triple store which you can (lazily) make replicas of. How is consistency handling performed? Does it rely on knowing my snapshot version and checking for write conflicts (a la oracle SERIALIZED level), or is it based on explicit locking?
      - chongli 13y ago
        There are no snapshots (or you could say that everything is a snapshot); you can get a value of the database from any moment in time, stretching all the way back to the creation of the database. All transactions are performed against a stable view of the database (its value at a moment in time) and either succeed or fail entirely (they are atomic). Once a transaction is validated and sent to storage the new data can be communicated to all clients and cached indefinitely; it will never change. Datomic has no notion of mutation/destruction. Data is stored in the form of facts which are asserted or retracted. Retracted data can still be retrieved from an earlier moment in time, so it isn't really gone. In many ways, it has a lot in common with DVCSs such as git (though it has only a single authority with commit access: the transactor).
        AlisdairO 13y ago
        I would rather say that everything is a snapshot - presumably I am working at a particular timestamp level - i.e. I won't get some facts that were valid at Timestamp A and some that were valid at Timestamp B. My question is if/how you do conditional updates. Say I'm storing some particular concept C as a collection of facts, and I want to update fact C-1 to '15' if fact C-2 is '0'. In an RDBMS I might select for update fact C-2 to make sure it didn't concurrently change underneath me while I'm making the change - is there an equivalent in Datomic? I understand that under normal circumstances reads are completely decoupled from writes, but what if I want to make a write if and only if a certain state holds?
        chongli 13y ago
        Datomic lets you write a function and send it to the transactor. This is a pure function which runs against the database value (specified) and returns a new database value which becomes the result of the transaction (assuming it succeeds). Because Datomic is also a library in your application, you can run this function on the client side as a dry run (against a value of the database) before sending it to the transactor.
- ExpiredLink 13y ago
  > Of course, the database isn't actually fully copied. You mean, Hickey just fakes it? Now I'm deeply disappointed.
  - DanWaterworth 13y ago
    No, it's not faking it. From what I understand it's copied lazily.
chrismonsanto 13y ago
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?
- TylerE 13y ago
  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.
  - trevorhartman 13y ago
    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 http://en.wikipedia.org/wiki/Persistent_data_structure
    - TylerE 13y ago
      Much is shared, yes, but compared to a traditional approach with static arrays, there is a _lot_ of copying in a typical FP approach.
      - mercurial 13y ago
        Sure, but in Haskell, a lot of it will be deforested by the compiler.
  - chrismonsanto 13y ago
    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 memory parallelism in an application. I feel like you are taking this opportunity to take a jab at FP here ("the purists detest mutation"). While FP is my preferred paradigm of development, I wasn't trying to push it on anyone--I was merely making a technical point.

sirclueless 13y ago

> Database Error: Error establishing a database connection Looks like we brought down another one. I was looking forwards to reading this too.

kybernetyk 13y ago

I'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.

steveklabnik 13y ago
You should check out Real World Haskell, it's much more practically focused than other things.
- vbs_redlof 13y ago
  This book is starting to show it's age, lots of the examples are broken.
thirsteh 13y ago
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 used in different places (to avoid cyclic imports.) (Contrast with e.g. Go or ML where you have interfaces/modules without 'implements'.) This isn't unique to Haskell by any means, but it's the only real complaint I have about Haskell as a language for non-toy projects. The benefits definitely make it my go-to language. It's hard to list them all, but by far the nicest feeling is the correctness: when your code compiles, 60% of the time your program works every time. (Not to imply that tests aren't necessary--QuickCheck is great for that.) It's an otherworldly feeling to write a program not in terms of what to do, but what kinds of filters you want to put on something, and have it just work (and either stay working, or break future compiles if something's changed!) after compiling 10 lines of code, when you would have written at least 50-70 and had to debug it in almost any other language. Edit: I'll add another complaint: Haskell is like C++ in that it's incredibly easy for a codebase to become completely unmanageable if your team doesn't have a common style/discipline. Go is a nicer language for "average"/"enterprise" teamwork, I think, since it almost forces you to write programs in a way everyone will understand. If you're in a team with good programmers that you trust not to abuse the language, this is a non-issue. Edit: Okay, another one: If you change your Types.hs, the recompilation can take a long time in a large codebase, similar to C++. But GHC/Cabal keep getting faster. Think that's it.

srl 13y ago

Here's the video: http://youtu.be/1PhArSujR_A http://youtu.be/1PhArSujR_A (the text on the page just introduces Carmack)

haxorize 13y ago
He starts talking about FP/Haskell at the 2:06 mark. http://www.youtube.com/watch?v=1PhArSujR_A#t=126 http://www.youtube.com/watch?v=1PhArSujR_A#t=126

Strilanc 13y ago

Google cache: http://www.google.ca/search?q=cache:functionaltalks.org/2013/08/26/john-carmack-thoughts-on-haskell/ http://www.google.ca/search?q=cache:functionaltalks.org/2013... The article is essentially just a link to the fourth part of his keynote at Quakecon ( http://www.youtube.com/watch?v=1PhArSujR_A http://www.youtube.com/watch?v=1PhArSujR_A )

tel 13y ago

Very worth noting that Carmack here is talking much about "pure functional programming" above just functional programming.

agentultra 13y ago

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

bad_user 13y ago
If you'll go read his opinions, you'll see that he has been a strong advocate for static analysis. His position is very understandable since he spent a lot of time working on complex pieces of C/C++ code, encountering a lot of subtle accidental errors that could have been avoided with better tools for static analysis or with a better language. He also worked mostly on client side software, where the fail fast / fail hard strategy of projects built in dynamic languages doesn't work so well. Lisp vs ML vs others is a very subjective issue since languages involve different kinds of trade-offs, so optimal choices depend on the project or on personal style. Also, this is John Carmack. For me he was a God 10 years ago and he's still one of the best and most practical developers we have today. Seeing him talk about Haskell is amazing. BTW, I've been a big fan of Scala lately, and I don't see myself using much Haskell precisely because its tools for modularity seem limited. In Scala you can use OOP to build abstract modules, with the much hyped Cake pattern being based on that. Dynamic languages are naturally more modular, however I still prefer static languages.

pohl 13y ago

I like this quotation: Languages talk about being multi-paradigm as if it's a good thing, but multi-paradigm means you can always do the bad thing if you feel you really need to, and programmers are extremely bad at doing sort of the the time-scale integration of the cost of doing something that they know is negative. I mean everyone will know...it's like "this global flag: this is not a good thing, this a bad thing - but it's only a little bad thing" and they don't think about how, you know, the next five years how many times that little bad thing is going to effect things. So brutal purity: you have no choice. In particular, I like the bit about integrating your technical debt function with respect to time, over the time you have to live with the debt, and how bad programmers are at thinking in those terms. We tend to think about how much technical debt we have at a given fixed point in time, but the area under the curve is what bites you.

rybosome 13y ago
Reminds me of something a former boss used to say. "Pay me now, or pay me later; either way, there has to be a payment". It sounds like Carmack is saying that brutal purity always forces the "pay me now" approach since it's harder to write this code, but it is worth it in the long run.
- oneandoneis2 13y ago
  As credit cards have shown, people are very bad at making good decisions when they don't have to pay for them until "tomorrow"
- orclev 13y ago
  That was more or less my take away as well, it forces you to deal with most of your technical debt up front and not let it pile up to some indefinite point in the future. Essentially brutal purity is a really strong anti-kruft coating. Since kruft can't stick to your code, it tends to stay nice and shiny well into the future, unlike the dirty impure code elsewhere that builds up a nice thick layer of kruft over time and eventually collapses under that weight (or else some poor soul ends up spending a bunch of time either scrapping all the kruft off, or just throws it out and builds a new one).

deleted 13y ago

[deleted]