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

111–120 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#111

Post by mbrock »

Symmetry wrote: post #107
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."

From http://en.wikipedia.org/wiki/Variable_%28programming%29 "The identifier in computer source code can be bound to a value during run time, and the value of the variable may thus change during the course of program execution. Variables in programming may not directly correspond to the concept of variables in mathematics."

It's wrong that it's "improper" to use the term "variable" for Haskell variables, since it is an established usage. This usage of "variable" occurs in the very first paragraph of Church's first paper on lambda calculus from 1931 in the motivation for the whole project!

Re: John Carmack: Thoughts on Haskell [video]

#112

Post by orclev »

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.

That was more or less my take away as well, it forces you to deal with most of your technical debt up front and not let it pile up to some indefinite point in the future.

Essentially brutal purity is a really strong anti-kruft coating. Since kruft can't stick to your code, it tends to stay nice and shiny well into the future, unlike the dirty impure code elsewhere that builds up a nice thick layer of kruft over time and eventually collapses under that weight (or else some poor soul ends up spending a bunch of time either scrapping all the kruft off, or just throws it out and builds a new one).

Re: John Carmack: Thoughts on Haskell [video]

#113

Post by orclev »

nicolast wrote: post #92
ghc wrote: post #9

Earlier quoted context omitted.

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

Since GHC is bootstrapped by a lower stage compiler I'd imagine there are some limitations to what kinds of language features at least parts of it can use as well. I haven't looked into all the details, but last time I did look into building GHC from scratch I remember there being an initial step where you built an initial minimal Haskell compiler that was written in I think C--, and then used that to build the rest of GHC.

Re: John Carmack: Thoughts on Haskell [video]

#114

Post by orclev »

sseveran wrote: post #109
boothead wrote: post #90

Earlier quoted context omitted.

> As an intermediate haskeller Are you serious?! If you're only intermediate - then there's no hope for me!

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 a concise and elegant type representation.

Maybe there needs to be some more layers in there, I don't know... also the advanced level feels weak to me. I'm still somewhere between beginner and intermediate myself.

Re: John Carmack: Thoughts on Haskell [video]

#115

Post by orclev »

Dewie wrote: post #62
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…

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…

I think that's part of why people are so interested in his opinion in this case. The games programming industry has some very unique challenges, and the focus on squeezing every last drop of performance out of the stuff you write tends to make it a pretty brutal environment for programming languages. From his background as a voice of authority in the games programming industry it's interesting to hear his feelings on the merits/drawbacks of something like Haskell specifically from that perspective.

The fact that he's not a long time user, or particularly a fan of functional programming, but a relative newcomer to it just adds more weight as he isn't some known fanboy that's going to praise FP no matter what. He's got extensive background in C, and at worst, average C++ skills if not considerably better than that, so he makes a fairly good case study of how practical it is for a non-functional programmer (but someone who's really experienced with imperative/OO programming) to pick up something like Haskell and actually do something useful with it.

It's also good to listen to the things he doesn't like about Haskell, E.G. debugging, and see if anything can be done to improve that.

Re: John Carmack: Thoughts on Haskell [video]

#116

Post by orclev »

cgag wrote: post #67
detrino wrote: post #60

Earlier quoted context omitted.

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 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 implemented in Haskell, they just have some caveats attached and shouldn't be used lightly. In other words, all things being equal, use the immutable data structure, but if you have a good reason to, you can use a mutable data structure instead, just be sure you know what you're getting into.

Re: John Carmack: Thoughts on Haskell [video]

#117

Post by fulafel »

SilasX wrote: post #87
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…

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)

Re: John Carmack: Thoughts on Haskell [video]

#118

Post by argv_empty »

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)

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 transformed into an 'IO Type1 -> IO Type2' or a 'Type1 -> IO Type2' function (this applies to many things other than I/O -- consult one of the many monad tutorials for more on that). Haskell even includes some special syntax for invoking these transformations that makes things look rather like an imperative language, but adding in a debug print still requires you to rewrite a lot more code than you would have to in another language. Alternatively, you could use unsafePerformIO (whose type is 'IO a -> a') to hide from the type system the fact that you've done some I/O, but you may run into trouble with the printing not behaving as you expect (due to Haskell's lazy evaluation).

Re: John Carmack: Thoughts on Haskell [video]

#119

Post by cgag »

reycharles wrote: post #97
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.

What do you mean by O(log32 n)?

Clojure's data structures are implemented using trees that have a 32-way branching factor, so each node has 32 children, instead of the 2 you'd see in a binary search tree. A lot of things you might expect to be O(1), like checking for membership in a set, or getting the nth element of a vector, actually take O(log_base_32(n)).

Re: John Carmack: Thoughts on Haskell [video]

#120

Post by nightski »

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…

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.
Post reply on HN