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

131–140 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#131

Post by SilasX »

dllthomas wrote: post #124
fulafel wrote: post #117

Earlier quoted context omitted.

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

That doesn't help with debugging pure functions. Many times I've been in a position where something is going wrong in the composition of several functions and I want to know where the error is in all of that. Normally, I'd just append a print statement to each of the functions, but in haskell I'd have to rewrite the program to allow output at each stage or else break purity.

Again, QuickCheck doesn't help with that.

Re: John Carmack: Thoughts on Haskell [video]

#132

Post by [deleted] »

cgag wrote: post #128
detrino wrote: post #125

Earlier quoted context omitted.

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.

[deleted]

Re: John Carmack: Thoughts on Haskell [video]

#133

Post by iopq »

mbrock wrote: post #88
TylerE wrote: post #66

Earlier quoted context omitted.

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

Math doesn't have vars, only vals

Re: John Carmack: Thoughts on Haskell [video]

#134

Post by chongli »

AlisdairO wrote: post #130
chongli wrote: post #101

Earlier quoted context omitted.

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

Datomic lets you write a function and send it to the transactor. This is a pure function which runs against the database value (specified) and returns a new database value which becomes the result of the transaction (assuming it succeeds). Because Datomic is also a library in your application, you can run this function on the client side as a dry run (against a value of the database) before sending it to the transactor.

Re: John Carmack: Thoughts on Haskell [video]

#135

Post by [deleted] »

SilasX wrote: post #131
dllthomas wrote: post #124

Earlier quoted context omitted.

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

That doesn't help with debugging pure functions. Many times I've been in a position where something is going wrong in the composition of several functions and I want to know where the error is in all of that. Normally, I'd just append a print statement to each of the functions, but in haskell I'd have to rewrite the program to allow output at each stage or else break purity. Again, QuickCheck doesn't help with that.

[deleted]

Re: John Carmack: Thoughts on Haskell [video]

#136

Post by dllthomas »

SilasX wrote: post #131
dllthomas wrote: post #124

Earlier quoted context omitted.

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

That doesn't help with debugging pure functions. Many times I've been in a position where something is going wrong in the composition of several functions and I want to know where the error is in all of that. Normally, I'd just append a print statement to each of the functions, but in haskell I'd have to rewrite the program to allow output at each stage or else break purity. Again, QuickCheck doesn't help with that.

I'm not following your first sentence. What doesn't help with debugging pure functions? Debug.Trace is quite precisely for the situation you describe.

Another option would be to pull the file in question up in ghci and play directly with the components of the function - in pure code that should be safe in a way that it won't be in effect-full code.

I also dispute the assertion that QuickCheck doesn't help - if you're getting weird behavior, then hopefully you can characterize that weird behavior, and get some example failed values out of QuickCheck - and getting a picture of what values the function is failing for can absolutely be useful.

Re: John Carmack: Thoughts on Haskell [video]

#137

Post by kaonashi »

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.

They can also prevent programmers from making a certain subset of good programs. This is less useful.

Re: John Carmack: Thoughts on Haskell [video]

#138

Post by justinpombrio »

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)

You can. You use a function called `trace` in module Debug.Trace in the standard library.

For instance, if you defined

    f x y = g (x + y)
then you could instead write

    f x y = trace "calling f" (g (x + y))
to insert a debug statement.

(dllthomas linked to the library but didn't point out how it works, and unrealistically expected people to like, follow the link or something. argv_empty is correct that side effects cannot be obtained without either wrapping functions in the IO monad or calling unsafePerformIO. Debug.Trace.trace calls unsafePerformIO behind the scenes.)

Re: John Carmack: Thoughts on Haskell [video]

#139

Post by kazagistar »

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.

There is a reason Lua has taken over so decisively: speed, simplicity, and good support for both functional and oo programming.

Re: John Carmack: Thoughts on Haskell [video]

#140

Post by derefr »

marshray wrote: post #127
tel wrote: post #102

Earlier quoted context omitted.

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.

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 like quorum voting on the results of computations, with the ability to fail nodes experiencing problems) before you can be "sure." Ada wasn't enough for NASA; they needed redundant processors too.

CS is weird as a discipline: we get all the tools of mathematics (digital logic, proof-verification), and all the tools of engineering (rate-of-failure calculations, high-assurance systems)... and then it turns out that the problem-space (ensuring perfect automation over trillions of repetitions of a task) is so difficult that it requires both! Arguing types vs. asserts is a "rabbit-season, duck-season" debate. Anyone who isn't using both a type system and runtime checks, is working in the dark.

However, I can and should probably point out that useful runtime checks can be derived from static properties of your code--and a Sufficiently-Smart Compiler[1] would automatically insert them as it compiled your code.

---

[1] not all that rare these days, GHC's stream fusion goes way beyond "sufficiently smart"

Post reply on HN