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

61–70 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#61

Post by detrino »

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?

It's not so black and white, if you don't actually need multiple versions of a data structure, then you are strictly copying more. There are scenarios where you do want versioning, of course, but this is why its good to have choices.

Re: John Carmack: Thoughts on Haskell [video]

#62

Post by Dewie »

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…

An outside perspective is valuable in its own right, and especially when it comes from a widely respected programmer. I think it's valuable to have both long time expert users, intermediate users and relatively new users chime in on issues: the experts often lack a certain perspective, since it was so long ago that they were novices themselves. And of course the intermediate and novice users lack experience. Together they can hopefully complement each other.

Re: John Carmack: Thoughts on Haskell [video]

#63

Post by Aqueous »

pohl wrote: post #36

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…

While i can see his point, I'm not entirely sure this is the case. A text-book example of a multi-paradigm language is Scala. And yet with Scala, the more I've learned about the functional side of things, the more tempting it is just to avoid any imperative or object-oriented idioms or patterns and just go functional all the way. it's almost as if the designers of scala knew if they could convert java programmers over, the temptation to do bad things would go away if only because functional is so much more elegant that it doesn't make sense not to use it as much as possible.

Re: John Carmack: Thoughts on Haskell [video]

#64

Post by strager »

TylerE wrote: post #20
chrismonsanto wrote: post #18

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

Of course, there's Data.HashMap.HashMap[1], which is just a Data.IntMap.{Lazy,Strict}.IntMap[2], whose "implementation is based on big-endian patricia trees".

> Many operations have a worst-case complexity of O(min(n,W)). This means that the operation can become linear in the number of elements with a maximum of W -- the number of bits in an Int (32 or 64).

[1] http://hackage.haskell.org/packages/archive/hashmap/1.3.0.1/... [2] http://hackage.haskell.org/packages/archive/containers/lates...

Re: John Carmack: Thoughts on Haskell [video]

#65

Post by chebert »

robrenaud wrote: post #46
aryastark wrote: post #43

Earlier quoted context omitted.

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…

To me, that is a great reason to listen to him. He builds big and complicated programs that people actually use.

Agreed. I listen to him because I want to know what's practical, not necessarily what's theoretically stimulating.

Re: John Carmack: Thoughts on Haskell [video]

#66

Post by TylerE »

alipang wrote: post #51
TylerE wrote: post #29

Earlier quoted context omitted.

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.

It is rebound. It is improper to call it a "variable" because in any given lifetime, it's value cannot vary. That's the point. It is possible to create a new binding with the same name, but any code holding on to the old instance keeps the old value. Subtle but important difference.

Re: John Carmack: Thoughts on Haskell [video]

#67

Post by cgag »

detrino wrote: post #60
cgag wrote: post #24

Earlier quoted context omitted.

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?

I'm sure there is a difference, I just don't care. They're still damn fast and the semantics of immutability would be worth quite a large speed difference to me.

If you do happen to be doing something where the difference is truly going to matter, or you're writing a library anticipating needing that kind of performance, using mutability internally in your functions isn't discouraged as long as they remain referentially transparent: http://clojure.org/transients

Re: John Carmack: Thoughts on Haskell [video]

#68

Post by marssaxman »

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.

This seems like splitting hairs.

Re: John Carmack: Thoughts on Haskell [video]

#69

Post by teamonkey »

agumonkey wrote: post #49
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…

Already mentioned in previous threads, but Tim Sweeney (Epic Games), who made a long presentations about the benefits of FP around 2006, is presenting a paper about a formalism related to dependent typing http://lambda-the-ultimate.org/node/4791

Here's one of the presentations comparing C++ to Haskell http://lambda-the-ultimate.org/node/1277

http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-... (PDF)

Re: John Carmack: Thoughts on Haskell [video]

#70

Post by aryastark »

robrenaud wrote: post #46
aryastark wrote: post #43

Earlier quoted context omitted.

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…

To me, that is a great reason to listen to him. He builds big and complicated programs that people actually use.

> He builds big and complicated programs that people actually use.

That's kind of an insult to, well, every working programmer.

Post reply on HN