John Carmack: Thoughts on Haskell [video]
functionaltalks.org
John Carmack: Thoughts on Haskell [video]
1–10 of 153 posts
Re: John Carmack: Thoughts on Haskell [video]
#2Diabolic, stateful database connections blocking a Haskell treatise! They should have copied the database on each request instead.
Re: John Carmack: Thoughts on Haskell [video]
#3Looks like we brought down another one. I was looking forwards to reading this too.
Re: John Carmack: Thoughts on Haskell [video]
#4Re: John Carmack: Thoughts on Haskell [video]
#5Re: John Carmack: Thoughts on Haskell [video]
#6The article is essentially just a link to the fourth part of his keynote at Quakecon ( http://www.youtube.com/watch?v=1PhArSujR_A )
Re: John Carmack: Thoughts on Haskell [video]
#7I'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.
Re: John Carmack: Thoughts on Haskell [video]
#8I'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 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.
Re: John Carmack: Thoughts on Haskell [video]
#9I'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.
If you want to see where Haskell is being used in industry, check the Haskell in Industry page out: http://www.haskell.org/haskellwiki/Haskell_in_industry
And if you really just want to see what it is like for game development, check out Frag: http://www.haskell.org/haskellwiki/Frag
Haskell is very well suited to large applications in my personal experience. My feeling is that it is actually worse for small-scale applications where you don't need the type system guarantees it provides.
Re: John Carmack: Thoughts on Haskell [video]
#10> Error establishing a database connection Diabolic, stateful database connections blocking a Haskell treatise! They should have copied the database on each request instead.
Explain?