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

51–60 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#51

Post by alipang »

TylerE wrote: post #29
SilasX wrote: post #27

Earlier quoted context omitted.

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.

What do the bindings bind then?

So, no, even in pure functions like

    f x = x + 1
x is a bound variable. It doesn't 'vary' in the sense that the value it refers to can be mutated, as in a imperative language, but it varies between calls to the function f.

Re: John Carmack: Thoughts on Haskell [video]

#52

Post by Aloisius »

groovy2shoes wrote: post #42
TylerE wrote: post #29

Earlier quoted context omitted.

Pure FP doesn't have variables. It has bindings.

Function parameters are variables even in pure FP. If your definition of variable requires assignment, then even mathematics doesn't have variables.

Sure it does. The summation sigma has a variable right under it. Though they like to call it the index of summation, it is a variable with assignment.

Re: John Carmack: Thoughts on Haskell [video]

#53

Post by mynameisme »

aryastark wrote: post #43
agentultra wrote: post #30

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 af…

I can't watch his talk right now, but at QuakeCon he recently discussed Scheme, and the potential for embedding it in a game. I think he also pondered what Quake would have been if QuakeC was based on Scheme instead. But my basic issue with talking about Carmack with respect to programming languages is that he never struck me as an expert on languages. Or even programming for that matter. The source code to Quake was…

If Carmack isn't an expert programmer, no one is. There are very few people with a comparable resume.

Re: John Carmack: Thoughts on Haskell [video]

#54

Post by pnathan »

bad_user wrote: post #38
agentultra wrote: post #30

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 af…

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…

Yeah, Carmack has weight due to his history of being incredibly technical and writing lots of incredibly useful code. Also, he has a huge profile in the industry.

He's been a heavyweight proponent of static typing for a while - 2-3 years IIRC - and so it doesn't totally surprise me that Haskell is up his alley. It's particularly notable that he prefers it as a technical lead as a low-pass filter on bugs.

Re: John Carmack: Thoughts on Haskell [video]

#55

Post by nightski »

Aloisius wrote: post #52
groovy2shoes wrote: post #42

Earlier quoted context omitted.

Function parameters are variables even in pure FP. If your definition of variable requires assignment, then even mathematics doesn't have variables.

Sure it does. The summation sigma has a variable right under it. Though they like to call it the index of summation, it is a variable with assignment.

Pretty sure summation definition is recursive. So no assignment/mutation is necessary.

Re: John Carmack: Thoughts on Haskell [video]

#56

Post by jerf »

bad_user wrote: post #38
agentultra wrote: post #30

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 af…

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…

Haskell's tools for modularity cut in a dimension you're not used to, and if you're not experienced with it, won't see. Percentage-wise in the last 15 years I haven't spent that much time in Haskell, but it's Haskell's tools I'm missing more often in imperative languages than the other way around. (And note the "more often"; it's not that I never miss more conventional tools in Haskell, it's just that I spend more time missing Haskell tools in other languages.)

Re: John Carmack: Thoughts on Haskell [video]

#57

Post by wtetzner »

thirsteh wrote: post #35
rybosome wrote: post #34

Earlier quoted context omitted.

You frequently mention nice things about Go in comparison to Haskell. I'm learning Go at the moment, and must admit that I find myself struggling to stay motivated. Given your background in FP (and apparent enjoyment), what do you find appealing about Go?

I like both Go and Haskell. They are wildly different languages, of course (even though some things are at least a little bit similar, like typeclasses and interfaces, cabal and go get, type signatures/inference, 'forkIO' and 'go', etc.) If it's just me making something, 99% of the time I'll pick Haskell, unless I know everything that I'm going to do is mutate a hash table or array, in which case I use Go. (Not that…

Any reason not to use, say, OCaml when working on a team? Its module system seems like it would make it well-suited to working with other people.

Re: John Carmack: Thoughts on Haskell [video]

#58

Post by thirsteh »

wtetzner wrote: post #57
thirsteh wrote: post #35

Earlier quoted context omitted.

I like both Go and Haskell. They are wildly different languages, of course (even though some things are at least a little bit similar, like typeclasses and interfaces, cabal and go get, type signatures/inference, 'forkIO' and 'go', etc.) If it's just me making something, 99% of the time I'll pick Haskell, unless I know everything that I'm going to do is mutate a hash table or array, in which case I use Go. (Not that…

Any reason not to use, say, OCaml when working on a team? Its module system seems like it would make it well-suited to working with other people.

Or F#. No particular reason, I/we just don't like them as much. (Haskell has many other unique qualities, e.g. proper STM.)

Re: John Carmack: Thoughts on Haskell [video]

#59

Post by detrino »

zorked wrote: post #32
TylerE wrote: post #20

Earlier quoted context omitted.

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…

Also, C++, which is the king of mutability, also implements map as a tree instead of a hash table, probably trying to avoid the worst-case linear search.

The C++ standard places a number of requirements (ordered, stable iterators/references, logarithmic operations) on std::map which really only lines up with balanced binary trees. As another poster pointed out, C++11 introduced std::unordered_map (A hash table).

Re: John Carmack: Thoughts on Haskell [video]

#60

Post by detrino »

cgag wrote: post #24
TylerE wrote: post #20

Earlier quoted context omitted.

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.

Have you profiled the difference? Do you use these containers in places where it matters?
Post reply on HN