These are the slides of the presentation I gave at the Tokyo F# meetup.
It was really good to see so many interested people and a real pleasure to connect with the technical crowd of Tokyo, which I never had the occasion before. As usual, Japan was top quality for the people, just like the rest !
Hopefully the event was useful to connect among the functional programmers of the industry and beyond.
Thinking functionally is useful even for imperative programmer : Just like @Bleis -san mentioned during the event, learning F# is an excellent way to take your C# to the next level.
It is also clear across the board that functional programming is a common theme among the next generation languages. The good news is that the ideas are universal and stand the trial of time, it never gets outdated by a new technology : the ideas you learn in one language are often true in another.
Of course FP can also be appreciated for its own beauty, as it is also a mathematical science which deals with universal truth.
So wether it is for real application or oxygen for the mind, practice your ラジオ体操 [Taiso, a popular morning exercise] for the mind, and collect the stamps, they will stay forever with you and help many around you.
A little note about projections using F# to illustrate QR
A very little note that can help remembering what Contravariance and Covariance is about.
In its course on functional programming principles in Scala, Martin Odersky talks about Huffman coding, which showcase a common recursion strategy in FP.
The succinct and nice syntax of F# make it quite simple to write, and we’ll use this as a preparation step to a future illustration of Shannon source coding theorem.
Commented F# code for the heap data structure, starting with the leftist tree heap, which exploits a clever recursive scheme.
The new iPhone is a good illustration of why Reactive Programming, meaning having a first class notion of stream, is important. Indeed, the new M7 is really doing just that :
It starts from multiple streams of data, namely acceleration, spatial orientation, and combines them into a higher level representation, to derive streams of activity, say walking, running, driving etc.. The key concept here is the combination, which is really what functional programming and reactive programming stands for.
Another important aspect is that those operations are not happening on a universal microprocessor, but are compiled down to hardware. This view of hardware as being a compiled down version of a function application is a very rich one.
One can indeed come with very precise equivalency rules to transform (in both ways) the functions performed by those reactive programs into a physical layout. cf Gérard Berry in his College de France lecture on Time and Computing for a no-nonsense lesson on this nice perspective (I recommend the french version for francophone..)
One can even express tradeoff between the size of the circuit and how long it will take to compute, and prove functional equivalency between those layouts. Far from being a just a fancy observation, this proves essential when it comes to putting a computer in command of your airplane or nuclear central, where proving the lack of bug is of definite value !
And here is also the key of the M7 chip : by having a hardware specific translation, one can lower the energy consumption of those operations to a minimum, which opens new applications… like a (ultra low power) wearable device !