Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prismatic's "Graph" at Strange Loop

blog.getprismatic.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Prismatic's "Graph" at Strange Loop

#31

Post by tlrobinson »

programnature wrote: post #11
a-priori wrote: post #2

Very interesting, needs more examples though. It seems like this fits a similar purpose to Nathan Marz' Storm framework. Could you do a bit of a compare/contrast thing between Graph and Storm?

Graph is not distributed, at least not in the way that Storm is. Notice the post doesn't talk about assigning individual components to individual machines. AFAICT its intended to run on a beefy box, and then horizontally scaled.

You could probably write a higher order function (like "observe-graph" in their example) to distribute the work across multiple machines. Maybe even map it onto a Storm cluster automatically.

Re: Prismatic's "Graph" at Strange Loop

#33

Post by mattdeboard »

tel wrote: post #32

This feels like lazy evaluation bolted on to Clojure (cool!). There's further benefit since you get some dataflow abstraction—which then reminds me of the Par monad. http://community.haskell.org/~simonmar/par-tutorial.pdf

There's no need to "bolt on" lazy evaluation since (future) and (delay) are parts of the core language (not to mention lazy seqs)

Re: Prismatic's "Graph" at Strange Loop

#34

Post by grayrest »

w01fe wrote: post #27
grayrest wrote: post #26

Earlier quoted context omitted.

You can do it in any language with first class functions and reflection. Here's a stupid simple js implementation of their example: https://gist.github.com/3874826 Edit: Loaded the page and got interrupted by lunch. Shows me for not refreshing.

That's awesome -- thanks for posting

Thanks for writing it up. I've thought about dataflow programming before but building the dependency graph up was always annoying and the idea of sticking everything in a map and building the dep chains by introspecting the argument names hadn't occurred to me. With the ease of use solved this is handy enough that I'll probably turn it into a real promise-based utility.

Re: Prismatic's "Graph" at Strange Loop

#35

Post by dmix »

janaboruta wrote: post #20
salimmadjd wrote: post #16

I love reading prismatic's blog. You have some really smart people there. However, it seems like you're trying to solve everything from a purist view and I think your product is suffering as a result. I have made the same suggestion consistently that would make me use it more without any reply. Basically, I've stopped using the product as the UX does not match the reason I would want to use the product.

I'm sorry about that. If you're still interested in giving us UX feedback send us an email feedback@getprismatic.com. I'll personally respond to it. Please understand that we're still a small team and we get a lot of emails on a daily basis. :-)

I agree with the author, the UX is definitely under-developed and I've also given many feedback msgs.

We only say this because we care :)

Re: Prismatic's "Graph" at Strange Loop

#39

Post by moomin »

This is great, but I wish they'd take it one stage further. At the moment, the first example they give (monolithic let) is pretty idiomatic and readable. The transformation from one to the other is pretty automatable. So for most cases, why not just put a macro on top? e.g. defgraph-asfn

Storm requires some manual intervention because you need direct control over how things are distributed.

Re: Prismatic's "Graph" at Strange Loop

#40

Post by moomin »

mattdeboard wrote: post #33
tel wrote: post #32

This feels like lazy evaluation bolted on to Clojure (cool!). There's further benefit since you get some dataflow abstraction—which then reminds me of the Par monad. http://community.haskell.org/~simonmar/par-tutorial.pdf

There's no need to "bolt on" lazy evaluation since (future) and (delay) are parts of the core language (not to mention lazy seqs)

Well, future, delay and lazy sequences are bolt ons to an eagerly evaluated language. I'm not convinced the laziness is Haskell is worth it, tbh, but its true that you really wouldn't need this project.
Post reply on HN