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

91–100 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#91

Post by oneandoneis2 »

rybosome wrote: post #39
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…

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.

As credit cards have shown, people are very bad at making good decisions when they don't have to pay for them until "tomorrow"

Re: John Carmack: Thoughts on Haskell [video]

#92

Post by nicolast »

ghc wrote: post #9
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.

I think it would be fair to say that Wolfenstein would qualify as a relatively small system in Haskell. Haskell's own compiler, GHC is a highly complex system and one of the most sophisticated compilers in existence. The source is free, so it's a great way to see what Haskell looks like when used for large applications in the hands of experts. If you want to see where Haskell is being used in industry, check the Hask…

> The source is free, so it's a great way to see what Haskell looks like when used for large applications in the hands of experts.

I tend to disagree with this. Yes, GHC is a large application and most certainly developed by experts, but it's also a project with a very long history, whilst Haskell (language, extension, conventions,...) have changed over the years, and this shows in several places.

Next to that, GHC code isn't very idiomatic at times (e.g. for performance reasons, or because it can't depend on too many external high-level libraries).

Re: John Carmack: Thoughts on Haskell [video]

#93

Post by nicolast »

mynameisme wrote: post #53
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…

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

Being an expert C++ programmer doesn't make you an expert Haskell programmer, or vice-versa ;-)

Re: John Carmack: Thoughts on Haskell [video]

#94

Post by bloodorange »

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 standards committee could not come to a complete agreement on hash tables and therefore it was not a part of C++03. Hash tables were in consideration along with the tree based map. However, maps made it in time but hash tables didn't. It was not one versus the other. They wanted to have both and only one was ready on time.

Eventually by the time they came to an agreement on hash tables (C++11), a lot of vendors had their own versions of it as non-standard additions to the library. To avoid conflicts with these existing hash tables, they named it "unordered_map".

Re: John Carmack: Thoughts on Haskell [video]

#95

Post by seanmcdirmid »

nightski wrote: post #84
seanmcdirmid wrote: post #83

Earlier quoted context omitted.

Some languages like Haskell put you in a purity (chastity?) belt; if you can code your solution there, you can code it anywhere. The problem is knowing your problem well enough to code it in Haskell...while a lot of time we are writing code to understand our problem (prototyping, experimentation). Some people live in a world where they understand their problems before writing code, and all their code is expected to i…

So what you are saying is that Haskell forces you to understand the problem for which you are implementing a solution, and this is bad because often that is too hard. Instead one should be able to just hack away until the code kind of does what they want (even though they can't prove anything about that piece of code) because that is the only way to really manage inherently complex problems? The older I get the less…

The computer is a tool I use to help me solve problems. Part of the process of solving problems, for me at least, is to write code that executes, and spend some time in the debugger to see if my assumptions were right. The computer is a tool for solving problems, dammit! It is ridiculous to think that you should solve the problem using pencil and paper (b/c computers no good for problem solving!?!), with various mathematical proofs (b/c we can and should prove everything?!?) and the computer is just an annoying end point for getting solutions out.

Programming is not just about implementing solutions, but also about finding solutions.

Re: John Carmack: Thoughts on Haskell [video]

#96

Post by bloodorange »

anonymoushn wrote: post #37
zorked wrote: post #32

Earlier quoted context omitted.

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.

unordered_map?

See my comment above https://news.ycombinator.com/item?id=6282310

Re: John Carmack: Thoughts on Haskell [video]

#97

Post by reycharles »

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.

What do you mean by O(log32 n)?

Re: John Carmack: Thoughts on Haskell [video]

#98

Post by AlisdairO »

chongli wrote: post #26
__alexs wrote: post #15

Earlier quoted context omitted.

Sounds a bit like SET ISOLATION LEVEL SERIALIZABLE?

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…

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?

Re: John Carmack: Thoughts on Haskell [video]

#99

Post by derefr »

nightski wrote: post #84
seanmcdirmid wrote: post #83

Earlier quoted context omitted.

Some languages like Haskell put you in a purity (chastity?) belt; if you can code your solution there, you can code it anywhere. The problem is knowing your problem well enough to code it in Haskell...while a lot of time we are writing code to understand our problem (prototyping, experimentation). Some people live in a world where they understand their problems before writing code, and all their code is expected to i…

So what you are saying is that Haskell forces you to understand the problem for which you are implementing a solution, and this is bad because often that is too hard. Instead one should be able to just hack away until the code kind of does what they want (even though they can't prove anything about that piece of code) because that is the only way to really manage inherently complex problems? The older I get the less…

I think what is being said is more, one of the things computers are best at, much better than humans, is simulation--following rigidly and repeatedly the consequences of a set of rules, through cause and effect, to see the eventual behaviors of a set of rules.

When constructing a set of rules in the first place (or when first formalizing an existing, but implicit, set of rules), the human can do the requirements gathering, design, bug-finding, etc. But humans are terrible at simulation--they can't foresee what each and every consequence a particular rule might have. When constructing a rule-set, a human's productivity is enhanced by the computer taking over the "simulation" part, to explore the consequences for them, where the human can then change the rules in response.

Type systems of all kinds, though, basically assume that the rules defining the code are invariant. They don't help with simulation at all.

Re: John Carmack: Thoughts on Haskell [video]

#100

Post by mercurial »

TylerE wrote: post #23
trevorhartman wrote: post #16

Earlier quoted context omitted.

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

Much is shared, yes, but compared to a traditional approach with static arrays, there is a _lot_ of copying in a typical FP approach.

Sure, but in Haskell, a lot of it will be deforested by the compiler.
Post reply on HN