prospero

You can maybe create propagation operators that make these relationships explicit, but that would require either eschewing the bare take/put methods, or making sure the take/put behavior is in sync with whatever metadata you use to describe it.

That being said, I'm not clear if any of these differences are important to most people's use cases. I suspect that Lamina channels can behave like a core.async channel without much trouble, so it wouldn't bother me much if core.async became the primary interface for these sorts of things. If someone cares a lot about throughput or other distinguishing factors, they can just look under the covers.

I am, however, a little curious how well the goroutine mechanism works in terms of being able to sample the state of the various tasks. Without some equivalent for "jstack", they become something of a black box.

http://clojure.com/blog/2012/05/08/reducers-a-library-and-mo...

EDIT: and my response is just a little redundant now

The system as a whole behaves more and more like a random router as the number of intelligent bamboo routing nodes increases

The point is that this process was gradual and implicit, so there's no point at which the intelligence was explicitly "deprecated". That doesn't excuse how things ended up, but it does explain it to some degree.

https://github.com/ztellman/aleph

I didn't know about the latter example, though, thanks for tracking that all down.

    (:keyword m)

    (get m :keyword)

Because Steve and me, see, we were like peas in a pod. He would have run this whole iPad Mini thing past me first.

Some of the design decisions are discussed in detail at http://ideolalia.com/creating-a-simple-game-in-clojure

I'll repeat that again: it's not the approach that's homogeneous, it's the quality.

You can see this with Apple, too. Their devices aren't limited to some set number of use-cases, it provides an API and ecosystem for creating new, domain-specific applications. You mention Objective-C in your response, which is kind of missing the point; we're talking about domain-specific applications, not domain-specific languages. LightTable will presumably be very consistent and general at the API level, and uses Clojure, which is a general-purpose language as well.

As for Amazon, their offerings span the entire spectrum from general to domain-specific. You can get an empty VM, but you can also get something like Elastic MapReduce. Amazon will happily develop domain-specific products on top of their platform as long as there's a large enough market.

Finally, look at Rails, which is a framework specifically for creating web apps. It doesn't help me write a new NoSQL server, it doesn't help me write a new AAA video game, it seems to be doing okay all the same. It's used because it's a really effective lever in certain, specific cases. If we can have a development environment which is a similarly large lever across a wide range of cases, how could that ever be a bad thing?

That's precisely what is being proposed here: a platform for creating a development environment that is more than the sum of its parts. Something that gives you composable pieces that can be fit together into something that maps directly onto your problem space.

Is this really so unclear? I can't picture the hypothetical product that you're arguing against.

If the core programming model for node.js doesn't help them in any way, and the ecosystem is less mature, then it kind of misses the point to say that everything is doable in node.js. Whether something can be accomplished is not a good metric for whether a platform is productive.

There are undoubtedly tradeoffs no matter what you use, but this seems like an eminently practical decision.

Also, if you google "factual api", you get http://developer.factual.com/display/docs/Factual+Developer+... as the top result. Unless you're faulting them for not releasing wrappers in all languages simultaneously, I don't really understand your point.