We launched on January 29 of this year, and next month are approaching our one year anniversay. In that time we have released 41 episodes with over 19 hours of video (9 of which are free for all), published 25 blog posts, served over 36,000 unique visitors, and open sourced 8 (!) libraries from the topics covered in our episodes! We’re really proud of everything we produced for 2018, so join us for a quick review of some of our favorite highlights.
We produced 41 episodes this year, about one every 1.2 weeks. We covered a broad set of topics, from the foundational ideas that somehow come up again-and-again, to the more practical, down-to-earth ideas that you can immediately bring into your code base today. The balance of these two sides is important because without the practical episodes it is hard to see the forest from the trees, and without the abstract episodes we’d be stuck in an endless loop of adding superficial niceties to our code that don’t meaningfully improve it in a significant way.
Here’s a small selection of some of our favorite episodes from the past year:
We ended the year with a bang! We’ve spent nine whole episodes rethinking the community best-practice of “protocol-oriented programming”. We started our series on “protocol witnesses” by showing how many basic protocol features and functionality can be implemented using just concrete data types and functions. We even showed that this translation is completely mechanical: that given any protocol, there is a clear path to defining a data type equivalent (part 1, part 2).
We then dove into some of the more advanced features of protocols (part 1, part 2), some of which we only got recently, like conditional conformance. We saw how these features manifest in the “protocol witness” world as plain ole functions. With witnesses we we didn’t have to wait. We were able to take advantage of conditional conformance with the very first version of Swift.
We wrapped things up with four down-to-earth episodes where we tool a real-world library, abstracted it to work with protocols (part 1, part 2), reabstracted it to work with witnesses, and finally fixed a problem with the libary that prevented it from working on asynchronous values.
We spent several episodes diving deep into the zip function. While many of us are aware of zip on arrays and may have even reached for it on occasion, it may be surprising that zip appears on structures almost as often as map! The implications are perhaps even more interesting. We saw that zip on optionals mirrors optional sugar that we’re used to with if-let binding. We saw that zip on the result type made us question the structure of the result type itself. And we saw that zip on an asynchronous type was a natural way to think about parallelism.
Zip has popped up in a number of our open source libraries, including swift-overture and swift-validation.
The Tagged type provides a lightweight wrapper around any type so that you can safely distinguish between, say, an Int-based user id and an Int-based blog post id. It uses a phantom generic and some powerful Swift features, like conditional conformance, to make it easy to make your code safer.
We even open sourced our own implementation, swift-tagged, to make it easy to take advantage of in your code base. The Point-Free web site makes heavy use of Tagged, and it’s prevented quite a few bugs from going out in deploys! 😅
In our 3rd of 41 episodes we showed that composition was truly applicable to everyday code. It’s still one of our most popular episodes to date!
There are many different ways to combine and reuse styling logic for iOS views, but we showed that plain ole functions are the simplest solution.
Later on in the year we revisited UIKit styling using our swift-overture library, allowing us to introduce the concept of composing styling functions without the need for operators, and with the addition of some expressive setter functions using Swift key paths.
We’ve had several episodes on managing dependencies using Environment so far and we have more to come. It’s one of the easiest ways to understand where dependencies are lurking in your code and make these untestable parts of your code base fully testable.
Stephen further spread the word at a talk this year at NSSpain, which we made available in blog form soonafter.
We knew we wanted to do as much of Point-Free in the open as possible, so this very site has been open source from the very beginning. We built this site from first principles in a functional style, writing each component as open source along the way.
Since our launch, we even open sourced libraries from the content in our episodes: 8 in total! And 4 of these libraries has a home in the official Swift Source Compatibility Suite. Each of these libraries aims to solve a single problem in the simplest way possible in order to minimize the cost of bringing the dependency into your project.
Our open source work has accrued over 3,800 stars on GitHub! We’re so thankful that the community has expressed such an interest!
Our most recently open sourced library, swift-snapshot-testing, takes snapshot testing to the next level. It allows you to snapshot test any kind of data type into any kind of format. For example, you can snapshot test UIViews and UIViewControllers into an image format, which is typical of these kinds of libraries, but you can also snapshot those objects into a textual format so that you can see the whole view hierarchy. And this kind of snapshot testing isn’t limited to UI! You can snapshot any value into any format using a number of strategies that ship with the library, or you can define new strategies yourself!
The design of this library was covered in a whopping 9 episodes
Server-side Swift is still in its nascent stages, but there have been some promising developments in the field, such as the Swift NIO project. Currently the most popular way to render HTML pages in server-side Swift is with templating languages, but there are a lot of problems with templates. We open sourced the swift-html library to remedy these problems by providing a first-class data type to represent HTML and a way to render that data to an HTML string that can be sent to the browser. In fact, this library powers the HTML rendering of this very site!
The design of this library was covered in 4 episodes:
The two most popular server-side Swift frameworks are Kitura and Vapor, but both use templating languages as the default way to render HTML. Luckily each framework provides a way to use your own view layer, and so both swift-html-kitura and swift-html-vapor are small libraries to help you use our swift-html library in either framework.
Functional programming tends to make heavy use of custom operators, and this is because infix notation and associativity are a powerful way of reducing clutter in an expression and exposing some really interesting algebraic properties. But, it’s not for everyone. So, we open sourced swift-overture to be a simple library that gives you access to lots of interesting function composition tools, without the use of operators. We discussed this idea in the following episode:
After covering the Tagged type in an episode, we open sourced swift-tagged to make it easier for everyone to benefit from this powerful type.
An adage of functional programmers is “make invalid states unrepresentable”. This means that states of data that shouldn’t be allowed to happen should actually be provable by the compiler as being impossible. We achieve this by using concepts from algebraic data types in order to chisel away the invalid values from our types, and are hopefully only left with the valid states. Our swift-nonempty library applies these ideas to model a “non-empty collection” type, which allows you to transform any collection type into a non-empty version of itself. We covered the design of this library in 4 episodes:
Swift error handling is built around Optional, Result, and throws. These constructs allow us to write a sequence of failable instructions to Swift and return nil, failure, or throw an error to short-circuit things and bail out of the happy path.
This correspondence between Optional, Result, and throws is interesting on its own, but we spent several episodes exploring the zip function beyond its usualy definition on arrays, and we discovered something interesting: zip gives us the ability to accumulate multiple errors when more than one input is invalid, a common thing we want with form data, and something that short-circuiting throws can’t do.
To make this functionality available to everyone, we open sourced Validated, a Result-like type that can accumulate multiple errors.
Thanks for joining us on the first year of our journey! We have great material for 2019 and hope to see you then.
Until next year!