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

141–150 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#141

Post by kyllo »

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…

Whoa, really? You have to use a monad just to print text to stdout in Haskell?

Re: John Carmack: Thoughts on Haskell [video]

#142

Post by kyllo »

marssaxman wrote: post #68
TylerE wrote: post #29

Earlier quoted context omitted.

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

This seems like splitting hairs.

When combined with lexically scoped closures, if you try to shadow your value bindings in a functional language and expect it to work the same way as mutating a variable does in an imperative language, you're in for a surprise.

Re: John Carmack: Thoughts on Haskell [video]

#143

Post by mbrock »

iopq wrote: post #133
mbrock wrote: post #88

Earlier quoted context omitted.

You're simply wrong. That's not how the term "variable" works. From http://en.wikipedia.org/wiki/Variable_(mathematics) : "Varying, in the context of mathematical variables, does not mean change in the course of time, but rather dependence on the context in which the variable is used."

Math doesn't have vars, only vals

That's a rather strange assertion, if you mean "variables" and "values." Math distinguishes between variables and values. Variables have different values. Values can be bound to variables. Sometimes we do math with mostly variables and few values -- that's called algebra.

Re: John Carmack: Thoughts on Haskell [video]

#144

Post by marshray »

derefr wrote: post #140
marshray wrote: post #127

Earlier quoted context omitted.

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

Types prove that something cannot happen in the formal system the program represents. In the real world, though, radiation can flip memory bits into impossible positions, drive blocks can fail and spit random garbage, IPC messages can get dropped on their way to the receiver, etc. Sadly, even when your system is pure and elegant and you've proven it all out, you still need runtime asserts (and more advanced things li…

Yeah I use strong typing, assert()s, and 'if (!x) throw ...' everywhere. Nevertheless, I figure if the biggest risk to my code comes from cosmic rays, then I'm doing pretty good.

Re: John Carmack: Thoughts on Haskell [video]

#145

Post by marssaxman »

kyllo wrote: post #142
marssaxman wrote: post #68

Earlier quoted context omitted.

This seems like splitting hairs.

When combined with lexically scoped closures, if you try to shadow your value bindings in a functional language and expect it to work the same way as mutating a variable does in an imperative language, you're in for a surprise.

Sure, you have to restrict the scope in which rebinding is legal, but I don't see how it's fundamentally any different than the use of a phi-node in SSA form.

Re: John Carmack: Thoughts on Haskell [video]

#146

Post by eli_gottlieb »

seanmcdirmid wrote: post #72
Aqueous wrote: post #63

Earlier quoted context omitted.

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

My experience with Scala was the opposite: it has great support for OO and imperative programming. The functional way of doing things often wasn't better, while on the other hand, traits are crazy flexible. I've seen people go crazy with functional code in Scala that is barely readable and impossible to debug; the JVM debugger is still optimize for imperative programs, while no one has really figured out a good debug…

Scala was actually the first language in which I've truly appreciated object-oriented programming. It's really quite simple when you get it: Objects Are Modules. You do not want or need an object for everything (looking at you, Java!), but when you want to abstract away some combination of behavior and data, you do in fact want OOP.

Re: John Carmack: Thoughts on Haskell [video]

#147

Post by PeterisP »

kyllo wrote: post #141
argv_empty wrote: post #118

Earlier quoted context omitted.

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…

Whoa, really? You have to use a monad just to print text to stdout in Haskell?

The concept is that affecting stdout isn't "just" - it requires a clear definition when (and if) that function will be executed, and in Haskell you don't do that if you can avoid that - it allows for lazy execution, actually running the function less (or 0) times depending on how it's result is used.

I.e., if your program needs top 3 results in a race, then you can safely use a function that returns all the results, but since you afterwards use only first three then the remainder aren't calculated, that code most likely isn't run and the order of any "embedded" print statements would be undefined.

That being said, standard Debug.Trace module allows simple adding of debug prints anywhere.

Re: John Carmack: Thoughts on Haskell [video]

#148

Post by PeterisP »

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.

I'd rather say that 'performance+ convenience/safety-' is a poor default - minute performance improvements matter only in the bottlenecks of your code, so it makes sense to use the varsatile though slightly slower implementations as the default, and have the 100%-speed option require some explicit code as they are needed only in a minority/exception segments of your program.

:) You could say that "all things being equal" never happens because mutable data structures have worse persistence if they're not used in a way that their performance matters. But also, different defaults make sense for different problem domains.

Re: John Carmack: Thoughts on Haskell [video]

#149

Post by jcsmnt0 »

sseveran wrote: post #78
bad_user wrote: post #38

Earlier quoted context omitted.

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…

Tim Sweeney (Unreal Engine) has also written about haskell and specifically STM ( http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-... ) and more recently on dependently typed languages ( http://arxiv.org/pdf/1307.5277v1.pdf ).

Thank you so much for that second link! I've been interested recently in how dependently typed languages can be made more natural for general-purpose programming, and this looks like a really good read. It gives me hope that it won't be too long before there's a dependently typed language comparable to Haskell in terms of community and ecosystem - in my (limited) experience, Agda and Idris are awesome for theorem proving and for small programs, but they're both a ways off from being usable for large, complex programs, and I feel like a big part of what they're lacking is just well-documented libraries for common operations.

Re: John Carmack: Thoughts on Haskell [video]

#150

Post by iopq »

mbrock wrote: post #143
iopq wrote: post #133

Earlier quoted context omitted.

Math doesn't have vars, only vals

That's a rather strange assertion, if you mean "variables" and "values." Math distinguishes between variables and values. Variables have different values. Values can be bound to variables. Sometimes we do math with mostly variables and few values -- that's called algebra.

I mean Scala vars can be changed during the program, while Scala vals can't.

    val y = Console.readInt
    var x = y + 1
    x = y + 2 //valid
    y = 5 //error, vals can't be changed in the same block
Post reply on HN