HN Theater @HNTheaterMonth

⬐ cordite

I watched it, it reminded me a lot of opa [1].

The problem with opa was it generated a gigantic load of code and when I tried running a basic app I made (to learn the language), it set off alarms on dotCloud's system (as if I were bitcoin mining or something) even though I was the only person using it for 5 minutes.

I foresee similar problems with any other system that attempts to make the client and server a system on continuations.

Secondly.. yeah, creating disjoint systems can be frustrating to maintain together, but thinking a web browser is the only platform that will be supported can be really limiting in future developments.

[1]: http://opalang.org

⬐ lukeholder

seems like this would work with react[0] since react manages its own virtual DOM and its components combine js and html into a single unit.

[0] http://facebook.github.io/react/

⬐ skore

I don't know that much about Haskell and I don't consider myself strong enough to make judgement calls on the theory side of systems architecture. That being said, here is what I was scratching my head about:

1. ("form over content comment", sorry) Not necessarily a criticism of the speaker as this is mostly a typical room mic issue, but the volume differences made this rather hard to follow. But in the delivery, it often seemed like the filler language was very loud and more in-depth details were mumbled into the screen.

2. I keep wondering "why?". It was just brushed over in the beginning, but I did not hear a compelling reason being presented on doing everything in Haskell. I do get that it is questionable to build this ever-growing API that does nothing but glue the client (javascript app) and server side to eachother. But isn't that what the internet is about? Having contained nodes that communicate?

And how is basically automatically generating the same sort of API... but now instead of a growing list of named end points (paths and maybe even GET variables), you have an RPC style protocol that directly adresses the internal code via the tree it sends back as part of the request ... better?

Later (around the 48 minute mark) the very valid question is brought up - isn't binding UI updates to server interaction very, very expensive? Expensive in such a way that encouraging it as a basic part of the systems design is a bad idea. And the speaker kind of makes a joke of it and says we can just throw more servers at it. Well maybe, but that seems to be a rather substantial error in the entire system design. It might solve some other problem and the problem created may have a simple solution, but... I just don't get how all that sums up to being a great idea.

3. Is this, in some sense, about avoiding to write an application in javascript? Because I have found a lot of people doing that - building the most incredibly colorful systems only to avoid to finally let go and just build a javascript application already.

In this particular instance, it seemed to be about trying - as much as you can - to do everything in Haskell. I have also seen people build frameworks on the idea of writing everything in XML files and interpreting them at runtime in PHP. It's possible and you can conjur up advantages, but at the end of the day, it's still not a good idea.

Nor is it compelling to other devs to join in, which brings it back to the LISP problem: an incredible potential for flexibility, but at the end of the day, it's just not very social. And thus, no matter how much nerds despise that conclusion, doomed to obscurity.

4. How can this ever "upgrade seamlessly"? It seems like this pushes the syncing issues down to the code level. I'm not sure that is an advantage to having syncing issues on the data level.