Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

John Carmack: Thoughts on Haskell [video]

functionaltalks.org

Post reply on HN
Print view View original

11–20 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#11

Post by Tuna-Fish »

ExpiredLink wrote: post #2

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

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.

Re: John Carmack: Thoughts on Haskell [video]

#12

Post by TylerE »

chrismonsanto wrote: post #10
ExpiredLink wrote: post #2

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

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.

Re: John Carmack: Thoughts on Haskell [video]

#13

Post by Fishkins »

chrismonsanto wrote: post #10
ExpiredLink wrote: post #2

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

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?

He's just saying that, in pure functional code, "updating" a data structure means creating a new copy of it with the desired changes instead of actually changing the structure in place. Of course, since the structures are immutable, large parts of them can often be reused. That's not how it's presented to the language user, though.

Re: John Carmack: Thoughts on Haskell [video]

#14

Post by evincarofautumn »

thirsteh wrote: post #8
kybernetyk wrote: post #4

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.

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…

Have you tried .hs-boot files for separate compilation with circular dependencies? It’s not bad, but it does lead to some extra crapwork when changing interfaces, much like with C++ headers.

Re: John Carmack: Thoughts on Haskell [video]

#15

Post by __alexs »

Tuna-Fish wrote: post #11
ExpiredLink wrote: post #2

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

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?

Re: John Carmack: Thoughts on Haskell [video]

#16

Post by trevorhartman »

TylerE wrote: post #12
chrismonsanto wrote: post #10

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

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

Re: John Carmack: Thoughts on Haskell [video]

#17

Post by thirsteh »

evincarofautumn wrote: post #14
thirsteh wrote: post #8

Earlier quoted context omitted.

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…

Have you tried .hs-boot files for separate compilation with circular dependencies? It’s not bad, but it does lead to some extra crapwork when changing interfaces, much like with C++ headers.

I haven't, and it does look pretty cumbersome. So far a couple of Types.hs, i.e. for functionally separate components, have worked out fine, but I'll check it out if that becomes unwieldy.

Re: John Carmack: Thoughts on Haskell [video]

#18

Post by chrismonsanto »

TylerE wrote: post #12
chrismonsanto wrote: post #10

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

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.

Re: John Carmack: Thoughts on Haskell [video]

#19

Post by tych0 »

TylerE wrote: post #12
chrismonsanto wrote: post #10

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

While I agree that a functional implementation of something usually copies more, it's a little disingenuous to say that most algorithms return a "fresh copy" of a structure. Most of the collections in most of the functional runtimes use clever tricks (hash array mapped tries, hash consing, etc.) to avoid copying the whole structure.

In the face of these techniques (and others, e.g. re-structuring things to use zippers and being clever manually or whatever), I suspect the actual amount of redundant data might be quite a bit less than you might think.

Re: John Carmack: Thoughts on Haskell [video]

#20

Post by TylerE »

chrismonsanto wrote: post #18
TylerE wrote: post #12

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

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 will be made afresh, since the balancing will change.
Post reply on HN