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

101–110 of 153 posts

Re: John Carmack: Thoughts on Haskell [video]

#101

Post by chongli »

AlisdairO wrote: post #98
chongli wrote: post #26

Earlier quoted context omitted.

No, it's far more elegant than that. Datomic makes the entire database an immutable, persistent data structure. This means that anyone can grab the database as a value -- at any point in time, past or present -- and never have it change behind their back. There are no read transactions whatsoever and clients have the power to conduct their queries offline. This lets you easily scale read operations without limit. The…

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 be communicated to all clients and cached indefinitely; it will never change.

Datomic has no notion of mutation/destruction. Data is stored in the form of facts which are asserted or retracted. Retracted data can still be retrieved from an earlier moment in time, so it isn't really gone. In many ways, it has a lot in common with DVCSs such as git (though it has only a single authority with commit access: the transactor).

Re: John Carmack: Thoughts on Haskell [video]

#102

Post by tel »

derefr wrote: post #99
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…

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.

Re: John Carmack: Thoughts on Haskell [video]

#103

Post by tel »

boothead wrote: post #90
sseveran wrote: post #80

Earlier quoted context omitted.

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!

That's one of the nice things about the Haskell community. The experts tend to be much, much better than in other places. There's much more depth there than memorization of quirks and ability to hold large numbers of arbitrary, disconnected pieces in your head all at once.

So, while becoming an expert haskeller is enviable, intermediate still suggests an ability to tackle a Fantastic array of problems.

Re: John Carmack: Thoughts on Haskell [video]

#104

Post by tel »

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

While I agree with your philosophy of vocabulary here, I've read the Harper article too, it's valuable to state directly that everyone knows there's the _(Programming) article too and is simply disagreeing that its a "good" way to use the term. Anyone who isn't familiar with the distinction in terminology ought to consider what things a programming variable represents that a mathematics variable does not..

Re: John Carmack: Thoughts on Haskell [video]

#105

Post by tel »

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…

And Haskell's ST monad.

Re: John Carmack: Thoughts on Haskell [video]

#106

Post by boothead »

tel wrote: post #103
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!

That's one of the nice things about the Haskell community. The experts tend to be much, much better than in other places. There's much more depth there than memorization of quirks and ability to hold large numbers of arbitrary, disconnected pieces in your head all at once. So, while becoming an expert haskeller is enviable, intermediate still suggests an ability to tackle a Fantastic array of problems.

Indeed - it's definitely one of the best places to be if you like to be surrounded by incredibly talented, but also very humble folks.

In fact I'd go so far as to say that the pool of wicked smart people who would love to build stuff in Haskell represents a significant opportunity to start ups right now. How have you found hiring for your company?

Re: John Carmack: Thoughts on Haskell [video]

#107

Post by Symmetry »

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

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

Re: John Carmack: Thoughts on Haskell [video]

#108

Post by taeric »

sfvisser wrote: post #48
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…

> ...I don't see myself using much Haskell precisely because its tools for modularity seem limited. > Dynamic languages are naturally more modular Why is that? I'm pretty convinced pure and especially lazy languages allow for great modularity. See http://augustss.blogspot.nl/2011/05/more-points-for-lazy-eva... for an interesting view on this.

I would think it is because of how "modules" can effectively be "bolted" on top of existing things quite easily.

Consider putting a new "module" on a bicycle. If you were doing it statically, it would have to have the screws in the proper place to be able to attach as it needs. Dynamically, however, you just use a zip tie to hold your piece onto the bike.

To be sure, if you buy a nice bike, many of the common attachments have "static" points where things can be added. If you want to place a holder for a phone, however, you are much more likely to do something that is much more adaptable at fitting things on.

becomes much more easy to bolt on funct

Re: John Carmack: Thoughts on Haskell [video]

#109

Post by sseveran »

boothead wrote: post #90
sseveran wrote: post #80

Earlier quoted context omitted.

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!

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.

Re: John Carmack: Thoughts on Haskell [video]

#110

Post by tel »

boothead wrote: post #106
tel wrote: post #103

Earlier quoted context omitted.

That's one of the nice things about the Haskell community. The experts tend to be much, much better than in other places. There's much more depth there than memorization of quirks and ability to hold large numbers of arbitrary, disconnected pieces in your head all at once. So, while becoming an expert haskeller is enviable, intermediate still suggests an ability to tackle a Fantastic array of problems.

Indeed - it's definitely one of the best places to be if you like to be surrounded by incredibly talented, but also very humble folks. In fact I'd go so far as to say that the pool of wicked smart people who would love to build stuff in Haskell represents a significant opportunity to start ups right now. How have you found hiring for your company?

I asked around speculatively and got great response. Right now we've got exactly the team we need, and I'm not too worried about hiring in the future.
Post reply on HN