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

121–130 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#121

Post by sseveran »

orclev wrote: post #114
sseveran wrote: post #109

Earlier quoted context omitted.

Well while I can produce large swaths of elegant code when I need crazy instances I usually call upon my colleague for his invaluable assistance. I don't claim to be an expert in the language. Many people know much more about it than me.

I've been trying to come up with a general way to rank Haskell experience, and so far I've got: Beginner: Can read the basic syntax, knows about E.G. Monads and folds Intermediate: Understands and can use the more advanced classes like Applicative, Arrow, lenses, and how to use things like fix Advanced: ??? Makes new powerful classes/libraries like Pipe, Conduit, or Netwire? Can easily translate a problem domain into…

Well I don't claim to understand the mathematical basis of Monads, and I don't use arrows and just started using applicative more often. Lenses rock and I have used those for a long time. I do build my own Monad Transformers so maybe I am still a beginning with intermediate tendencies. :-)

Re: John Carmack: Thoughts on Haskell [video]

#122

Post by dllthomas »

argv_empty wrote: post #118
fulafel wrote: post #117

Earlier quoted context omitted.

you can't sprinkle debug prints in Haskell? really? (honest question)

Short answer: No, you can't. Long answer: You can, but Haskell is very serious about keeping pure code separate from impure code. Any function which performs I/O is impure, so its output must be an IO Thing instead of just a Thing. This means anything that uses its output must accept an IO Thing instead of an ordinary Thing, and so on. Of course, the way I/O works means that a 'Type1 -> Type2' function into can be tr…

Your long answer is correct. I think I disagree with your short answer.

You can, and this is not just a technicality - it can be useful in debugging.

It's certainly true that laziness means that when things print will be unintuitive if your intuition is trained on strict languages, so any short answer conveying as little information as just "yes" or "no" is liable to be confusing, though...

Re: John Carmack: Thoughts on Haskell [video]

#123

Post by aryastark »

MLR wrote: post #71
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…

I can understand saying he isn't an expert on languages, but to say he isn't an expert programmer is honestly just condescending.

What I meant by that is that he doesn't use what most people qualify as "best practices" today. At least per the language he uses. If you look at his (or id Software's, rather) C++, it doesn't follow anything resembling standards in that area. They don't use design patterns, there are straight C (stdio, for example) calls in C++, etc.

I'm not saying that's bad. But it's obvious he doesn't keep on top of trends that well. Or languages, for that matter.

Re: John Carmack: Thoughts on Haskell [video]

#124

Post by dllthomas »

fulafel wrote: post #117
SilasX wrote: post #87

Earlier quoted context omitted.

Well, it helps to be able to inspect your code at various stages to isolate which part of it isn't working right. In the pure functional paradigm, my programs are typically the composition of numerous functions. Now what if my program isn't doing what it should? (Contra FP advocates, it's possible for this to happen even if your program successful compiles.) You could have it output the value after each function is a…

you can't sprinkle debug prints in Haskell? really? (honest question)

http://www.haskell.org/ghc/docs/latest/html/libraries/base/D...

As mentioned, it'll only print when the wrapped value is actually evaluated, which won't always correspond to it's position very well.

However, it's very much worth noting: if you're in IO then you can just sprinkle debug statements. If you're not in IO, then your function isn't effect-full and you can run it (or pieces of it) safely with whatever args you care about (also, quickcheck is amazing).

Re: John Carmack: Thoughts on Haskell [video]

#125

Post by detrino »

orclev wrote: post #116
cgag wrote: post #67

Earlier quoted context omitted.

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

That's a good point. People don't understand that functional purity in Haskell, while a nice goal, isn't a law, you can break it if you have a good reason to. IO is sort of the canonical example, it isn't there to prevent you from doing IO, it's there to act as a giant warning sign that either this function, or one of the functions it uses isn't pure. Likewise mutable data structures while not the default, can be imp…

The problem is that "all things being equal" never happens because immutable data structures have worse performance if not used in a way that benefits from persistence. IMO, that makes them a poor default.

Re: John Carmack: Thoughts on Haskell [video]

#126

Post by marshray »

seanmcdirmid wrote: post #95
nightski wrote: post #84

Earlier quoted context omitted.

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

Some people like to think in terms of 'proofs', it seems reasonable to me that they would think of a compiler as a tool for 'solving problems' in those terms. But most of us seem to be more empirical.

Interestingly the best reverse engineers I've ever met, who are total descriptivists with a debugger, are also some of the most pedantic prescriptivists when it comes to writing actual code. It comes full circle, I think because they understand the reasoning behind the API contracts better than the API documentation tells.

Re: John Carmack: Thoughts on Haskell [video]

#127

Post by marshray »

tel wrote: post #102
derefr wrote: post #99

Earlier quoted context omitted.

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

I disagree with that. Used correctly types are exactly a lightweight simulation layer. Values are not always what you need to know about and, again used correctly, types can reveal a lot of interesting emergent dtructure of your code.

assert()s prove that something isn't happening.

Types prove that something cannot happen.

Re: John Carmack: Thoughts on Haskell [video]

#128

Post by cgag »

detrino wrote: post #125
orclev wrote: post #116

Earlier quoted context omitted.

That's a good point. People don't understand that functional purity in Haskell, while a nice goal, isn't a law, you can break it if you have a good reason to. IO is sort of the canonical example, it isn't there to prevent you from doing IO, it's there to act as a giant warning sign that either this function, or one of the functions it uses isn't pure. Likewise mutable data structures while not the default, can be imp…

The problem is that "all things being equal" never happens because immutable data structures have worse performance if not used in a way that benefits from persistence. IMO, that makes them a poor default.

Pretty much everything except performance benefits from immutability and persistence, which is why using anything else as the default seems insane to me.

Re: John Carmack: Thoughts on Haskell [video]

#129

Post by seanmcdirmid »

nightski wrote: post #120
seanmcdirmid wrote: post #95

Earlier quoted context omitted.

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

I actually agree with you. My point was that types are a much better tool than hacking code and debugging. Once the types are embraced and used as a tool, instead of thought of as a straitjacket that is where the real power lies.

Types, especially with some good inference, don't necessarily get in the way of exploration, but purity most certainly does. Not being able to take shortcuts and being expected to have a pre-well elegant understanding of your problem can be a big blocker.

But types are fairly conservative, dynamic languages still provide quicker turn around times even if semantic feedback can't be provided. One of my research projects is focusing on getting the benefits of both.

Re: John Carmack: Thoughts on Haskell [video]

#130

Post by AlisdairO »

chongli wrote: post #101
AlisdairO wrote: post #98

Earlier quoted context omitted.

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?

There are no snapshots (or you could say that everything is a snapshot); you can get a value of the database from any moment in time, stretching all the way back to the creation of the database. All transactions are performed against a stable view of the database (its value at a moment in time) and either succeed or fail entirely (they are atomic). Once a transaction is validated and sent to storage the new data can…

I would rather say that everything is a snapshot - presumably I am working at a particular timestamp level - i.e. I won't get some facts that were valid at Timestamp A and some that were valid at Timestamp B.

My question is if/how you do conditional updates. Say I'm storing some particular concept C as a collection of facts, and I want to update fact C-1 to '15' if fact C-2 is '0'. In an RDBMS I might select for update fact C-2 to make sure it didn't concurrently change underneath me while I'm making the change - is there an equivalent in Datomic? I understand that under normal circumstances reads are completely decoupled from writes, but what if I want to make a write if and only if a certain state holds?

Post reply on HN