snprbob86

I took a crack at this, if you're still interested:

https://github.com/brandonbloom/asyncx

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.

It's not quite clear what patterns will emerge with respect to UI event handlers, so there really isn't an ELI5 answer yet in the View layer. The backend advantages are well covered by the Go language community, so check out Rob Pike's talk [1]. As for other parts of the frontend, like the model layer, channels can lead to a major simplification for the callback hell involving multiple coordinated network requests or for transforming and processing events off a message socket, like that of Socket.io.

[1]: http://talks.golang.org/2012/concurrency.slide#1

The IoC threads work by converting park-able functions into Single-Static Assignment (SSA) form [1] and then compiled to a state machine. Essentially, each time a function is "parked", it returns a value indicating where to resume from. These little state machine functions are basically big switch statements that you don't need to write by hand. This design is inspired by C#'s async compilation strategy. See the EduAsync Series [2] on John Skeet's blog, and the compilation post [3] in particular. Once you have these little state machines, you just need some external code to turn the crank.

[1]: http://en.wikipedia.org/wiki/Static_single_assignment_form

[2]: http://msmvps.com/blogs/jon_skeet/archive/tags/Eduasync/defa...

[3]: http://msmvps.com/blogs/jon_skeet/archive/2011/05/20/eduasyn...

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.

> if you fork a project and it becomes incompatible with the upstream, rename it

I agree completely, but I'd like to take your idea further in a direction you likely didn't intend.

The fundamental observation of distributed version control systems, in my opinion, is: Every commit is essentially a fork.

When you combine these two ideas: 1) fork->rename and 2) change==fork, with the 3) identities & values from FP/Clojure/etc, you realize that version numbers are complete folly.

Coincidentally, I just wrote about this with respect to SemVer: http://www.brandonbloom.name/blog/2013/06/19/semver/

In short, if you have awesomelib and make an incompatible version, you can call it awesomelib2. Or you could call it veryawesomelib or whatever else you want. If you give up on the silly idea of being able to compare version numbers, then versioning and naming become equivalent.

What?! This is total nonsense.

Application uninstalls are as trivial as dragging the application to the trash bin. No, this will not eliminate the application's data from ~/Library, etc, but 98% of the time you don't want that anyway. If you know what you're doing, it's usually a quick `rm -rf ~/Library/...` and you're done. Some poorly behaved apps stick stuff in other places or otherwise muck with your system, but now with the app store, that's no longer an issue.

And, if you're absolutely anal about deleting every single trace of an app, there are tools that automate the process. For example: http://www.appzapper.com/ -- But really, it's probably a waste of your time unless you had a badly behaved app go rouge. In my many years of Mac ownership, I've installed and uninstalled hundreds of apps and the only time I ever had to bang my head against the wall was when I used to use MacPorts and a Postgres install went haywire because of the same sort of packaging nonsense that the article is talking about.

How fast will the connections be?

I think I'd actually find it quite distracting while I am typing.

Start with Mathematica's builtin documentation. The overview pages are actually quite good. They are also online [1].

Of course, given that the early drafts were written by Wolfram himself, you'll have to ignore absurd statements like this one: "Long viewed as an important theoretical idea, functional programming finally became truly convenient and practical with the introduction of Mathematica's symbolic language." [2]

See also: Pure [3]

[1] http://reference.wolfram.com/mathematica/tutorial/CoreLangua...

[2] http://reference.wolfram.com/mathematica/guide/FunctionalPro...

[3] http://purelang.bitbucket.org/

I'd like to see a rope-variant of the 2-3 finger tree.

2-3 finger trees are immutable/persistent and support access to both ends in amortized constant time and logarithmic concatenation and splitting.

The complicating factor being that for flyweight values, like characters, the interior nodes of the tree would be prohibitive for one leaf per character. Surely there must be a variant of 2-3 finger trees that addresses this.

I haven never tried to write a script or algorithm or anything in Mathematica. It's not useful for that (at least to me). I use it more to explore and to understand problems.

That's why I mentioned truth tables. Being able to quickly perform symbolic simplifications is awesome. If nothing else, learn how to do that!

For one thing, "An Introduction to Programming with Mathematica" is on his Clojure bookshelf: http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH

A quick Googling will show you that Rich has popped his head into a bunch of conversations where both Clojure and Mathematica are mentioned. He's also mentioned it in a talk or two.

I wrote a little bit about this on HN before: https://news.ycombinator.com/item?id=4844502

In short:

1) Term rewriting systems are a beautiful and powerful model of computation that a lot of people know nothing about.

2) The "everything is data" philosophy is life changing. This same philosophy can be seen in the Clojure community (there are more than a few Mathematica-isms that Rich has admitted being influenced by). Mathematica goes further to say that all data is expressions, which is really a subpoint of #1, but I think that data is the more fundamental important idea than expressions. Even though expressions have extremely wide applicability.

3) Having some mastery over the basics of Mathematica is like having a bunch of secret programming super powers. One time, I came across an exceedingly complex if/and/or/else clusterfuck and reduced it to a trivial truth table in only a few minutes of fiddling with Mathematica. There are lots of cases where experimenting in Mathematica was just a much faster way to understanding and solving a problem prior to implementation.

Mathematica is absolutely incredible and everyone who calls themselves a programmer should own a copy, learn how to use it, and internalize its philosophy.

However, I too find his self-aggrandizing intolerable.

Sentences like "Looking back at its documentation, SMP was quite an impressive system, especially given that I was only 20 years old when I started designing it." Just make me dislike him. Was his age really necessary there? He already mentioned his age a few paragraphs up in a sentence that was far less objectionable.

This comment is spot on.

However, my next question is: What can we do to make more companies be like Amazon?

Not every business needs to operate on razor thin margins, but I'd love to see more big companies playing the long game and continuously innovating. Wall Street invests in returns, not innovation. What can be done to help reset that balance a bit?

Heh, fixed mine to save somebody yet one more second. Wrote this comment to waste that second that I saved.

That said, I'm reading this paper now. It's absolutely fascinating and very approachable. Well worth checking out.

Saving somebody 10 seconds, here is Bacon's paper:

http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

This doesn't address your particular question, but I like to recommend Eric Koester's guides to term sheet newbies:

http://www.avvo.com/attorneys/20007-dc-eric-koester-1214516/...

There are several pages of articles & you might have to read and re-read a few times. It's dense, but clear.

Cool, but I'm mega lazy when testing new tools... The splash screen should have a big 1-click "Try Demo App" button :-)

Would be awesome if the demo app was baked into the download. I'd love to be able to try the UI instantly without even having to load up my own application.

C#'s stackalloc might be useful for some micro-optimizations, but I think it's main purpose is for interop with unmanaged code.

Temporarily ignoring all of Microsoft's specific problems (and there are many) and any other company's specific problems for that matter (every company has them)...

Nobody gets a product right on the first try. Full Stop.

The more interesting question here is this:

Why does Microsoft expose the first try to the public?