A video of my iOSCon 2017 talk, where I develop a basic FRP system in Swift, is now online.
Do-It-Yourself Functional Reactive Programming @ iOSCon in London
End of this month, I will talk at iOSCon 2017 in London (30 & 31 March). I am very much looking forward to get to know the vibrant iOS dev community in London as well as to meet the other speakers. The line up of talks looks awesome, promising plenty of both breadth and depth.
In my own talk, I will deconstruct functional reactive programming (FRP) to show that it is based on a few simple ideas and holds the potential to improve the architecture of iOS apps. We will discuss questions, such as what is the purpose of FRP, how do you use it to structure your application, and how can you implement it yourself?
One of the things that I love about Swift is that it enables us to conveniently use functional programming concepts to write clearer and more robust code. The ease with which we can implement and use FRP is a great example of that capability.
See you in London @ iOSCon 2017!
Streaming Irregular Arrays
In the new draft paper Streaming Irregular Arrays, we extend the high-performance array library Accelerate for Haskell with support for irregular streams of multidimensional arrays. We discuss why this is useful to work with large datasets on memory-constrained devices, such as GPUs, and how it widens the range of applications for which we achieve portable parallelism with Accelerate. The paper explains how we compile these programs and what runtime mechanisms we need for execution. Moreover, it includes a range of benchmarks to evaluate the performance of the resulting code.
Here is the video of my talk “A Type is Worth a Thousand Tests” presented at Sydney CocoaHeads, November 2016 (you can also get the slides) — I previously presented this talk at YOW! Connected, Melbourne, and an earlier version at Curry On in Rome.
In this talk, I argue that types are a design tool that, if applied correctly, reduces the need for tests. I illustrate this at the example of the design of a simple iPhone app in Swift whose source code is available on GitHub.
This is the video of my Compose :: Melbourne keynote. I am making the case for purely functional graphics programming with Haskell playgrounds, including live programming a little game (for the second half of the talk).
Some of the code is hard to read in the video; you may like to refer to the slides.
Learning Haskell
We just published the seventh chapter of our new tutorial for Learning Haskell. The tutorial combines clear explanations with sceencasts reinforcing new concepts with live coding. Several chapters use graphics programming to make for more engaging coding examples.
Static versus dynamic
In the transition from Objective-C to Swift, the iOS and Mac developer community struggles with a question: What is better? Static or dynamic languages?
To answer this question, we have to ask a few more. What is a static language? What is a dynamic language? More fundamentally, what is a programming language?
Every programming language is what computer scientists call a formal language. It is a rigorously defined construct including (1) a formal grammar (its syntactic formation rules) and (2) a formal semantics (the meaning of syntactically well-formed programs). This is always the case, irrespective of whether the creators of the programming language designed the language with those components in mind. As soon as they implement the language (by writing an interpreter or compiler), they indirectly commit to a formal grammar and a formal semantics. In other words, by implementing the language, the language creators fix what happens if you run and maybe compile programs in that new language. They fix that with the utmost precision, as otherwise no computer would be able to run these programs — hence, we call them formal.
For our discussion, the most interesting component is the language semantics, which we can, again, split into two components: the static semantics and the dynamic semantics. The static semantics are those aspects of a program that we can reason about without executing the program. A prime example of the static semantics is scoping: if I use a variable x, which declaration does that x refer to. Another aspect of the static semantics is the (static) type system.
In contrast, the dynamic semantics characterises the execution of programs. It determines what the computer does when it processes a particular language construct.
Every language has both a static and a dynamic semantics. Without a static semantics, we wouldn’t know which declarations the use of variables, functions, and so forth refer to and, without a dynamic semantics, we cannot run a program. Nevertheless, the static and dynamic semantics of different languages can surely be of varying levels of expressiveness. For example, the expressiveness of the static semantics varies with the capabilities of the type system, and the expressiveness of the dynamic semantics depends on whether the language includes advanced runtime capabilities, such as exceptions, first-class functions, reflection, or dynamic method dispatch.
When people talk about “dynamic” versus “static” languages, they suggest that the languages designers put a particular emphasis on either the dynamic or static semantics of the language. For example, Smalltalk and Lisp, as representatives of dynamic languages, lack a static type system, but come with strong support for reflection and meta-programming. In contrast, Java, a popular static language, lacks strong support for meta-programming, but employs a strong static type system.
Unfortunately, this characterisation is increasingly inaccurate. Modern languages with a strong static semantics also support features requiring an advanced dynamic semantics. For example, meta-programming is a common theme in C++, ML dialects, and Haskell. Moreover, work on flow types, contracts, and gradual typing can be regarded as enhancing the static semantics of Lisp dialects, JavaScript, and others.
All in all, it is not an either-or proposition. Just because a language has a strong static semantics does not mean that it cannot also have a strong dynamic semantics. If languages often start out falling into one camp, this is because language design requires much hard work and you get something working more quickly by limiting the scope of your aspiration. Moreover, it took programming language researchers a while to understand the static properties of advanced runtime behaviour. In any case, it is about time to retire this outdated bifurcation of programming languages.
So, what is better? A static or a dynamic language? It is certainly best —but also a lot of work— to have a language with both a strong static and a strong dynamic semantics. Looking at the development of Swift, it surely shapes up to be strong in both areas.
Update: Added dynamic method dispatch to the list of examples of features of the dynamic semantics as a response to this discussion: https://twitter.com/irrequietus/status/760812875128664064
Video of Functional Programming in a Stateful World
Earlier this year, at YOW! Lambda Jam (in Brisbane), I gave a talk about developing a Mac app in Swift. More precisely, I described my take on how to best apply functional programming principles when writing Cocoa (Touch) apps in Swift. The video for the talk “Functional Programming in a Stateful World” is now online (and the slides are on Speaker Deck).
Don’t fight the system; exploit it!
Of course, I’m talking about the type system. A common opinion expressed by developers who are not used to languages that include strong static typing is that “types solve a problem I don’t have”, “they just get into my way”, and “the bugs crashing my shipping apps wouldn’t have been caught by a type checker anyway.”
Since the announcement of Swift about a year ago, I have heard a fair number of Objective-C programmers express that same opinion. Hence, it is interesting to listen to those who have made a leap of faith and tried to embrace types in their development process. A recent example is Ole Begemann’s Swift’s Type System. What stood out to me in Ole’s post is that he actually went to the trouble of looking at how programmers in languages, such as Haskell, ML, and Scala, work.
His take away was that types become useful if you allow them to help you write the program (as opposed to trying to impose them on the program you would have written without types). Then, the type system becomes a design tool, not an obstacle.
This idea, although born and explored in the communities around typed functional programming, is also powerful in object-oriented languages like Java, as explored in this two part post on More Typing, Less Testing. In fact, replacing tests by types is the mantra I repeated in my talk on Adopting Functional Programming in Swift (video) at Sydney CocoaHeads last year.
In summary, it is worthwhile using types to guide your program design. Moreover, to harness the power of functional programming in Swift, study how experienced programmers work in languages like Haskell, ML, Scala, F#, and so on. And finally, it occurs to me that the typed functional programming community hasn’t been very successful at communicating these ideas. We need to get better at that!
Type-safe Runtime Code Generation: Accelerate to LLVM
The purely functional, high-performance array language Accelerate has gained an LLVM-based backend targeting both multicore CPUs and GPUs that uses Haskell’s advanced type system to statically assure a range of safety properties. In the final version of our paper at the forthcoming 2015 Haskell Symposium, we describe (1) how we ensure these safety properties using GADTs and type families, (2) we outline the architecture of the LLVM backend (including a richly typed interface to LLVM), and (3) we provide benchmarks supporting our claim that we are able to produce competitive code.
Shoutout to the awesome Trevor McDonell who did all the hard work.
