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

81–90 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#81

Post by vbs_redlof »

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

You should check out Real World Haskell, it's much more practically focused than other things.

This book is starting to show it's age, lots of the examples are broken.

Re: John Carmack: Thoughts on Haskell [video]

#82

Post by marshray »

nightski wrote: post #75
justinpombrio wrote: post #73

Earlier quoted context omitted.

"There is no programming language, no matter how structured, that will prevent programmers from making bad programs." - Larry Flon The same applies to programming paradigms.

There are many programming languages, specifically structured, to prevent programmers from making a certain subset of bad programs. This is incredibly useful.

Yeah, but these languages tend to be not a good fit for inherently complex problems. When one tries to express complex ideas in those languages, you end up code that's either absurdly verbose, or code that experts in that language's idioms would call "bad".

One can write simple, structured code for simple problems in any language. But complex problems require languages that don't attempt to babysit programmers.

(IMNSHX, YMMV)

Re: John Carmack: Thoughts on Haskell [video]

#83

Post by seanmcdirmid »

marshray wrote: post #82
nightski wrote: post #75

Earlier quoted context omitted.

There are many programming languages, specifically structured, to prevent programmers from making a certain subset of bad programs. This is incredibly useful.

Yeah, but these languages tend to be not a good fit for inherently complex problems. When one tries to express complex ideas in those languages, you end up code that's either absurdly verbose, or code that experts in that language's idioms would call "bad". One can write simple, structured code for simple problems in any language. But complex problems require languages that don't attempt to babysit programmers. (IMNS…

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 immediately hit production.

Scala is quite flexible and can accept good and bad code, which is good. I was only calling out FP abuses and its promotion as some sort of holy grail that is so much better than objects. If you compare Scala FP to Java OOP, ya, Scala FP is better, but if you compare Scala FP to Scala OOP, it's a much fairer battle and I put my faith in the latter (with the caveat that I can always use Scala FP when it makes sense to do so!).

Re: John Carmack: Thoughts on Haskell [video]

#84

Post by nightski »

seanmcdirmid wrote: post #83
marshray wrote: post #82

Earlier quoted context omitted.

Yeah, but these languages tend to be not a good fit for inherently complex problems. When one tries to express complex ideas in those languages, you end up code that's either absurdly verbose, or code that experts in that language's idioms would call "bad". One can write simple, structured code for simple problems in any language. But complex problems require languages that don't attempt to babysit programmers. (IMNS…

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 find writing code an attractive method for understanding a problem. I also find utilizing something like a type system to enforce invariants in code liberating - and actually conducive to solving problems.

Re: John Carmack: Thoughts on Haskell [video]

#85

Post by laureny »

chrismonsanto wrote: post #10
ExpiredLink wrote: post #2

> Error establishing a database connection Diabolic, stateful database connections blocking a Haskell treatise! They should have copied the database on each request instead.

I don't really get the joke. Generally functional languages will share more data than imperative languages, and therefore will copy less data. In an imperative language, it makes sense to copy whatever data you are working on, so your modifications don't inadvertently affect other parts of the program. In Haskell it doesn't. Explain?

> Generally functional languages will share more data than imperative languages, and therefore will copy less data.

It's the opposite: functional programs prefer immutable data and the only way to achieve this is to copy a lot more data than you would if you were just overwriting existing objects.

Re: John Carmack: Thoughts on Haskell [video]

#86

Post by Argorak »

sseveran wrote: post #79
aryastark wrote: post #70

Earlier quoted context omitted.

> He builds big and complicated programs that people actually use. That's kind of an insult to, well, every working programmer.

Most people don't build big and complicated programs.

Please qualify "most people".

Re: John Carmack: Thoughts on Haskell [video]

#87

Post by SilasX »

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…

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 applied, but that would either break purity (by having I/O) or, per the GP's point, be tedious to write. At this point, the Haskell community made the decision that in debugging, "screw purity", and the output is effectively untyped.

Certainly, you can use tests of expected invariants (eg QuickCheck), but that just tells you that the whole thing fails.

That is, I think, also the GP's point: that the same things that make your final code good in Haskell, also make it hard to write.

(No to say I don't like haskell; this is just a peeve,)

Re: John Carmack: Thoughts on Haskell [video]

#88

Post by mbrock »

TylerE wrote: post #66
alipang wrote: post #51

Earlier quoted context omitted.

What do the bindings bind then? So, no, even in pure functions like f x = x + 1 x is a bound variable. It doesn't 'vary' in the sense that the value it refers to can be mutated, as in a imperative language, but it varies between calls to the function f.

It is rebound. It is improper to call it a "variable" because in any given lifetime, it's value cannot vary. That's the point. It is possible to create a new binding with the same name, but any code holding on to the old instance keeps the old value. Subtle but important difference.

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."

Re: John Carmack: Thoughts on Haskell [video]

#89

Post by mbrock »

TylerE wrote: post #12
chrismonsanto wrote: post #10

Earlier quoted context omitted.

I don't really get the joke. Generally functional languages will share more data than imperative languages, and therefore will copy less data. In an imperative language, it makes sense to copy whatever data you are working on, so your modifications don't inadvertently affect other parts of the program. In Haskell it doesn't. Explain?

No, typically functional languages end up copying more , not less, since typical algorithms will e.g. return a fresh copy of the modified structure - the purists detest mutation. The benefits of data sharing, are, imo, overstated outside of a few niche, datastore-y type areas.

What kind of evidence do you have for this claim? The amount of copying in a functional or imperative program depends on how they're written, how they're optimized, and how they've compiled or evaluated.

For example, in programs with mutable state, it's not uncommon for modules to return deep copies of objects to avoid mutation-related bugs. Java's String objects are immutable precisely to avoid having to do this.

Re: John Carmack: Thoughts on Haskell [video]

#90

Post by boothead »

sseveran wrote: post #80
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…

As an intermediate haskeller (I use it for my business every day) his criticisms largely mirror mine. I found the quake codebase to be great in the 90s. I have also found him more than most other developers to admit when thing didn't work out, specifically that doom 3 was c++ in name only and he didn't fully understand it. A scheme based language would have been better for most modders than quakeC.

> As an intermediate haskeller

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

Post reply on HN