BTW, there's a broken link on your home page: /71of71 instead of /71objectives

Well, you post your thesis, I dig in :)

> Let me try to go over them.

Much appreciated, thanks for all your answers, I've read a good chunk of your thesis by now (that's hard work :) ), good stuff.

> We have no "deep copy" of the data. The data is simply mutated in place, for performance. The compiler knows in what order it has to update the datacells, so SolScript users don't notice any of this. If I say `b = a`, then `a` will be calculated before `b` uses it. (If you want the value of `a` before `a` is updated, you say `b = previous a`.)

Ok. That may cause some trouble when there are long chains of circular dependencies but I'm sure you're aware of that and that you have a solution in place (assuming circular dependencies are even allowed).

Again, thank you for all the answers and much good luck with your project, I'll be following your progress, it's super interesting what you are doing.

Considering Avionics domain, using Coq or ATS to prove the correctness of SolScript compiler will help boost confidence.

Duck typing refers to the ability of making shit up at runtime, as in the ability for functions, classes or code to manifest at runtime and to respond to user queries based on runtime info. It doesn't refer to a lack of explicit types in your code, since in a static language types are still there and still have to be something concrete and solvable at compile-time. It doesn't even refer to structural typing, because again, the types themselves have to be solvable at compile time.

I'm a static languages fan and I've also worked a lot with dynamic languages. The ability to make shit up at runtime is much more than the ability to call a method on an object without being explicit about the interface used. This is not about succinctness as as it about programming style. With an expressive static language used to its strengths, as a developer you want to write code that is as close to provably correct as possible, so even if the static language used is very expressive, the style is oriented around modeling the problem domain with types. In a dynamic language on the other hand, the focus is on the raw data that needs to be manipulated and code is written to make shit up on the fly (i.e. method_missing, eval, classes manifested at runtime by means of meta-programming, etc...).

Hence my opinion that duck typing shouldn't be used outside the context of dynamic languages, because people might get the wrong idea about it.

[1] http://dl.acm.org/citation.cfm?id=3988

Rx is a one trick pony that focuses exclusively on the duality between event streams and data streams. Management of time in any real sense is completely missing from the framework. No continuous bindings, control flow must all be buried as data flow, etc...

React is a much better solution for writing reactive programs than Rx.

And Rust? Does anyone dare basing production stuff on Rust like now? With breaking changes all the time?

"In Redmond, like a lot of people talk about code but don't write it, so I think Microsoft can only come back if, you know, they start writing more code."

> And I don't think he's being dismissive of reactive programming, he's dismissive of that definition, which is too broad.

The definition seems pretty reasonable to me. It immediately resonated with me; it described a principle I had been trying to achieve in some code I was writing recently. The idea of having changes automatically propagate through your model as a data-flow network is a pretty noticeable contrast to other ways of programming.

> He was one of the main proponents of Reactive programming inside Microsoft.

Yeah I guess I don't have this context. But without it, the talk just rubbed me wrong.

Curious to hear more.

If he has that much background I would expect him to know better than to give such a poor example when he's trying to make fun of a definition as "dilbert-esque."

Tongue-in-cheek is a fun style and I totally get that, but if you're taking unfair hyperbolic pot-shots I think it should be at your own expense, not other people's. But that's just me.

I think ISubject<I,O> has the interface for a pipe, with IObservable being a Producer equivalent, and IObserver being a Consumer equivalent. So there may be some cunning that could be done with your own implementations [to create an Effect]. (This is just wild brainstorming without looking at the code, so take all of this with a large pinch of salt).

Working within the Rx system, there'd be two ways of doing this:

The Observable has a mechanism for slowing down, but obviously it can't get instruction from observers - so it would have to make a judgment on what is 'too much'; a slow down would affect all observers. Definitely (well probably) not what you want.

The other way is to use the various buffering functions in Rx on the subscription, or roll your own function that has some intelligence. That localises the 'backing up' on a per observer basis, but doesn't slow down the observable itself.

To 'Stop' you could switch your subscription to Observable.Never<T> until you're ready to receive messages. Obviously you'll miss messages generated on the other stream whilst you were not listening.

It certainly seems possible to use Rx primitives to build more functionality, yes.

Though everyone will have to build this themselves (if, of course, they even need it), and they'll probably all build it differently, where other lib's have this concept baked in (i.e. Pipes).

IMHO, libraries shouldn't try to do everything anyway, and to that end, Rx does it's thing and does it well (unix philosophy), as it's based on these mathematical abstractions.