Erik Meijer: Duality and the End of Reactive [video]

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.

Take a look on GitHub at all the projects with reactive in the name or descriptions; it's become a buzzword that people use to describe various things that don't have any relationship to the original.

Iterable is broken, as Erik said, because it has a hasNext() method, and a next() method, which is a problem because hasNext() causes side-effects to be evaluated.

Imagine if the implementation of the iterator has to execute a long running function, or wait for the next value in an observable to be pushed, like an event. So, if call hasNext() twice, then it may cause a side effect so that next() actually has a different result than it would without the side effect. Thus, it is not mathematically, a function, and can't really be used to build monads.

So, unfortunately, due to backwards compatibility, Java classes that implement Iterable/Iterator can't automatically get the benefits of list monads etc..., by simply defining a library of operators that take Iterable/Iterators, like C# could with IEnumerable/IEnumerator.

In C#, IE only has side effects in the MoveNext() method, which returns true or false if there's another element, and the effect is explicit in the name, which helps. However, more importantly, if you get the value from Current, there is no side effect, and you can do that as many times as you like.

With Iterable, if you call next() it moves to the next element. So, it is impossible to get the same value twice with a guarantee of no side effects, and impossible to guarantee mathematically sound composition of Iterables. The interface is broken, and changing it would break nearly every Java program.

My point was that if you were building user interfaces, react would get you much further than Rx, which is a hammer looking for a problem where it is actually better.

If you want the ability to deal with side effects, I'm working that in my own work while avoiding burying everything in data flow:

http://research.microsoft.com/apps/pubs/default.aspx?id=2112...

Ironically, I started this work while working for Martin with the goal of making the scala compiler more "reactive" (the ability to responsively react to change); I actually succeeded while making minimal changes to scalac. Like actors or FRP, Rx can't be applied to scalac either, which desperately needs to be reactive to fit into the IDE. Rx's idea of reactivity revolves around event streams, virtual, managed time and frameworks like react attack the problem of change directly. Erik is right about useless definitions, but one based around change really works.