snprbob86

You can mimic selective receive using a router process. Essentially, you could generate one channel for every branch of the pattern match, then generate a process which reads from the input channel and deals the message to the appropriate branching channel.

In fact, that seems preferable to me.

You can build analogous versions of map/filter/etc on top of channels. The core.async team is still focused on the primitives, but surely some higher order operations will follow in the not too distant future. I suspect we'll need to wait and see what patterns develop, since they will surely differ from Go a little bit, due to the functional emphasis on Clojure.

I should also mention a key difference between channels and Rx/Observables: The fundamental operations for observable sequences are subscribe & unsubscribe. The fundamental operations for channels are put and take. In the push sequence model, the consumer must give a pointer to itself to the publisher, which couples the two processes and introduces resource management burdon (ie IDisposable).

You can think of a pipeline from A to B in the following ways:

Sequences: B pulls from A

Observables: A pushes to B

Channels: Some process pulls from A and pushes to B

That extra process enables some critical decoupling!

Mutually incompatible, vendor-specific, proprietary anything is an inevitability. #1 isn't about that. That's what #2 and #3 are about.

#1 is about planning for extensibility. Just look at the hackery with JS where lonely, otherwise ignored, strings are used for things like "use strict" and "use asm". Or where Microsoft added "conditional comments", which quite frankly, was essential to the development of Outlook Web Access, which basically gave us Ajax. Or all the absurd vendor prefixes on CSS tag names. Or one of 100 other little hacks that browser vendors have invented to try to innovate past the standard. Pushing pass the standard, by the way, is the only way forward. We've learned that lesson by now, so we should plan for extensibility.

I dunno... Allowing the language to be selected like a video codec or image file format seems like a reasonable request.

There are three issues:

1) Language pluggable?

2) Spec-ed shader languages

3) Mandatory languages

The proposal was:

1) No

2 & 3) GL SL ES

Microsoft proposed:

1) Yes

2) GL SL ES

3) None

The perfectly reasonable compromise would have been:

1) Yes

2 & 3) GL SL ES

> This is a pretty good article

Thanks!

> he states 5, I bet it is closer to 20

I think it varies greatly with many factors, but agree that it's probably closer to 20. I'm just trying to avoid selling silver bullets.

> Has anyone ever measured a Reading Comprehension score for languages?

While language is a huuuge component of that constant factor, there are certainly other components. For example, if you want to write a sudoku solver, you should start by writing a backtracking constraint solver and then implement the constraint solver on top of it. You'll write less code than trying to solve sudoku directly, but that code will certainly be slower to read. This applies within a language just as much as it does across languages.

> There may be situations where you want the entire history of your development to be included on your live server, but often this just isn't appropriate.

Are you concerned about being wasteful with disk space? Or is there some other concern here? Some security issue perhaps?

> If more developers cared about versioning their software appropriately based on incompatible changes or stability guarantees

But they don't. And you're not going to be able to make them. And even if you did, people would disagree about what constitutes compatibility, stability, and engineering disciplin. One man's "breaking change" is another man's "that was an implementation detail". It's not possible to get this right, since first you need to define "right". That's why versioning is folly.

Steam itself is sort of a package manager, so that's an interesting edge case...

However, I think that there are basically three categories of application data

1) Documents -- These should never be deleted and are not invisible 2) Settings & other small data not worth deleting, probably nice to keep around in case you ever re-install. Most stuff. 3) Large semi-temporary files, like samples and other downloaded add ons that are optional parts of the application

I think OSX handles 1 & 2 well, but you're right, it needs a way to handle #3 too. However, I think that #2 is a much better default than #3.