Swift and the Legacy of Functional Programming

https://realm.io/news/tryswift-rob-napier-swift-legacy-functional-programming/

by ckurose • 10 years ago

91 185 10 years ago

Yo, would be nice to have some functional programming language with decent syntax to program apple machines. Let's call it Dylan to honor the most recent winner of the Nobel prize for literature.

Just kidding. The bottomline of this page and talk is that Swift is still not functional. But you can do cool things with it.

ubertaco• 10 years ago

I dunno; I think the bottom line of this page is that functional programming is a set of approaches for solving problems, and some of those approaches can be done in Swift.

macintux2• 10 years ago

Haven't read the article yet, but the problem I find with this attitude generally is that the constraints found in FP are what I find valuable, and what are usually missing from languages which support functional approaches.

speg• 10 years ago

My take was that you can solve problems by breaking things down. In functional programming you do so with functions. In Swift you can do so with types.

carapace2• 10 years ago

https://en.wikipedia.org/wiki/Dylan_(programming_language)

(for those who didn't get the joke... ;-)

grabcocque• 10 years ago

Ask five programmers to define functional programming, get fifteen different answers.

galad87• 10 years ago

Same thing can be said for object-oriented programming, unfortunately.

greydius• 10 years ago

Most people would agree that in functional programming we can pass functions around as first class objects. What we disagree on is the definition of function.

gardenhead• 10 years ago

That's just one aspect of functional programming. By that definition, almost any modern language is functional.

lanna2• 10 years ago

No, wrong. You can pass pointers to functions in C.

Waterluvian• 10 years ago

I always thought FP == pure functions. I guess not?

_mhr_• 10 years ago

I would call a language like Haskell "purely functional" and a language like OCaml "impurely functional". A functional programming language to me is a programming language where functions are in charge of data. In a language like Java, data is in charge of functions (broadly speaking). In a language like Prolog, relations are in charge of data. It's all about what perspective the programmer has between the abstraction and the data.

lanna2• 10 years ago

If they are truly functional programmers, asking them will always return the same referentially transparent answer. Only side-effecting functions would return different answers at different times :-)

anonymouslee• 10 years ago

Seems to me that's because functional programming continues to evolve (which is great!) and newfangled properties and semantics get folded in.

To me the core is "no side effects" though (for pure FP). It's interesting to see what others consider to be the most salient feature(s).

shados2• 10 years ago

and if it was about OOP, you'd get a hierarchy of answers that no one can follow and is unsound ;)

pjmlp4• 10 years ago

It is the programming style I learned to program in Lisp and Caml Light, and when Haskell was still known as Mirada.

solidsnack90002• 10 years ago

The author of this article did reference a classic treatment, though: John Backus's lecture.

A compact definition of functional programming is using only expressions, never statements. This leads to the idea that the effect or meaning of every computation must be encoded in its return value.

lmkg• 10 years ago

The term "functional programming" is overloaded, but I think there's a sensible way to split the term into two halves.

"Purely functional programming" is writing programs to resemble mathematical functions, with referential transparency and absence of side-effects and so forth. Also know as "what Haskell does."

"Function-oriented programming" is writing programs using functions as your main tool for abstraction, encapsulation, defining interfaces, unit of code division, etc. This part of functional programming is more typified by the Lisp family.

Most languages that are considered functional generally encourage both of these aspects, partly because they work well together. The confusion over definition comes from these two halves getting tangled, and some languages or programmers emphasizing one half over the other.

Non-functional languages that are becoming "more functional" are generally importing features from the "function-oriented" side of things, and adopting the "purely functional" aspect as a best practice convention, if at all. It's probably more accurate to say that they enable a functional style of programming, rather than that the are functional.

js82• 10 years ago

Actually, both of those families come from lambda calculus, except in different way. Lisp comes from untyped lambda calculus (and adds things like car, cdr and eq on top of it), while Haskell (and ML) comes primarily from typed lambda calculus.

I offer a definition of "functional programming" as "based on semantics of lambda calculus".

bad_user8• 10 years ago

Your "function-oriented programming" has an older and more suitable term: https://en.wikipedia.org/wiki/Procedural_programming

You see, if a function isn't pure, then it isn't a (mathematical) function. But we tend to overload terms because of their marketability.

In the same way that some companies wanted to overload "open source". The general rule of thumb is that if something is desirable by the market, then it is going to get overloaded either by people not knowing what they are talking about or by sales people.

bad_user8• 10 years ago

There's only one definition that matters: functional programming is programming with mathematical (pure) functions.

As a consequence you get referential transparency and thus equational reasoning. But change this definition and the term becomes meaningless.

kibwen3• 10 years ago

Though by this definition, Lisp, the granddaddy of functional programming languages, is not a functional programming language.

seanalltogether• 10 years ago

I'm curious, does every else find this

    let persons = names
        .map(Person.init)
        .filter { $0.isValid }

easier to read than this?

    var persons: [Person] = []
    for name in names {
        let person = Person(name: name)
        if person.isValid {
            persons.append(person)
        }
    }

I understand and appreciate the value of compact code, but I find the first one harder to read. A lot of inferred/token based coding is harder for me to mentally parse.

pklausler2• 10 years ago

  let persons = [ p | n <- names
                    , p <- peopleNamed n
                    , isValid p ]

is even better, if your programming language has comprehensions.

aninhumer5• 10 years ago

Eh, maybe for more complicated examples, but I think that comprehension is a lot more complicated than:

  filter isValid (map peopleNamed names)

shados2• 10 years ago

its almost a wash in this case, but when you start having a very complicated flow, the first way becomes easier and easier in relation.

It also depends on the language obviously. In this example, the first example has special tokens for the filter. It doesn't have to be so.

macintux2• 10 years ago

The first is much more declarative. When everything in the language looks and acts like that, it's pretty easy to read.

When it's optional, well, sadness ensues.

virmundi• 10 years ago

I think part of the answer is that for many functional is a new hotness. The same thing happened with Scala (probably still does). With type inference and functional shortcuts, you can get a lot into one compact space. This is "impressive".

The other thing is that experience brings the ability to track what's going on. The formulation of the answer here is probably new to you. As you get use to this, or Streams for Java, or threading for Clojure, etc, you'll understand it by default.

melling2• 10 years ago

If you learn Haskell or OCaml, you'll prefer the first snippet. I took a couple of MOOCs and blogged how I incorporated what I learned into my Swift:

https://h4labs.wordpress.com/2016/09/30/functional-swift-usi...

niklasrde• 10 years ago

I think it depends what you're used to. I used to be a Scala programmer, then I moved to JS.

At the moment I'm working in Objective-C, and I literally just wrote a loop to filter an array and form a new array with the results like the one in the example - and god I wish there was an as straight-forward, easily understandable functional way in Obj-C to do it like in the Swift example.

I miss these 'nice' things - I don't need the fully functional Haskell package, but I like having some of the nice things Swift has, just because I got used to them and can actually write and read them better, and it is definitely more elegant!

antfarm2• 10 years ago

It's ugly, but possible:

  NSArray *filteredArray = [array filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(id object, NSDictionary *bindings) {
      return [object test];
  }]];

pjmlp4• 10 years ago

You mean something like:

    a  := #(1 2 3 4 5).
    Transcript show: (a printString); cr.
    b := a select: [:x | x \\ 2 == 0].
    Transcript show: (b printString); cr.

Sadly Objective-C isn't really Smalltalk.

donut2d• 10 years ago

I used to find the first example more difficult to read until I learned Haskell. Now I find it much more explicit about what's happening.

In the first example, because I know what "map" means, I know that `Person.init` is applied to each name. And then I know that only the valid `Person`s are returned by the `filter` call.

In the second example, I have to understanding the unique logic of the loop block to get to the same conclusion.

chc3• 10 years ago

Yes, I find the first one easier to read. It might be me being weird, but I suspect you just haven't built up the instincts to read the first one more quickly. There's no "magic" or anything tricky going on here — it's just a normal use of map and filter. Even good and useful things can seem less readable before you're used to reading them.

svachalek2• 10 years ago

I think if the second one is easier, you've more or less been taught to think like a microprocessor. That happens to most of us after a few years of writing imperative code. The more abstract functional approach is, however, conceptually simpler and more powerful at the same time. (For example, the first one is completely open to being performed in parallel.)

With a little experience, functional programming is quite straightforward. Practically everything comes down to map, filter, and fold, or whatever they're called in a given language.

ifdefdebug• 10 years ago

I can't help thinking like a microprocessor. Even when mixing functional style into my code, my brain tries to get a grasp on how it's going to be processed.

So the first example looks to me like two loops (hopefully the compiler does a better job on that), while the second one is obviously one loop.

I am already trying to guess how a compiler would parallelize that...

jkaptur• 10 years ago

For example, the first one is completely open to being performed in parallel

So what do you actually have to do to make this actually run in parallel? Or do you truly get it automatically?

pjmlp4• 10 years ago

Hence why "structure and interpretation of computer programs" is a very important read.

nickbauman• 10 years ago

For me the problem with Haskel (and, by extension, Swift) is the syntax is very complicated. The example above is better taught through a functional language that has almost no syntax like a Lisp.

  (filter (fn[p] (p :valid?)) 
    (map (fn[n] (Person n) names))

aninhumer5• 10 years ago

Haskell's syntax isn't actually that complicated. There are some common functions with operator names that can be hard to read if you're not used to them, but those are library defined. The syntax itself is actually fairly simple.

And incidentally, this would probably be something like (EDIT: made example more realistic):

  filter personIsValid (map initPerson names)

in Haskell. Which looks much cleaner than the lisp to me.

lispm3• 10 years ago

That you have to put parentheses around expressions does not make the syntax go away in Lisp. The 'has almost no syntax' is mostly a misconception. Syntax in Lisp is provided by special operators (LET, ...) and macros (DEFUN, ...).

Often people assume the relatively simple syntax for s-expressions is the syntax of the programming language Lisp. It isn't. Lisp syntax is defined on top of s-expression.

BrandonBradley• 10 years ago

Other than the $0, yes I do. Easier to read and think about in respect to operations on a collection.

hota_mazi• 10 years ago

It's a matter of habit more than code readability.

Five years ago, I would have found the second form easier to read. These days, not only do I find the first form much clearer but I find the second one a bit smelly because it mutates data.

It's actually surprising how quickly you get used to the first form of code once the language you use supports it.

jfoutz5• 10 years ago

In this case, it's unfortunate that there's no, "will this name create a valid person object?" predicate. much much better to filter the names, then make the objects.

In this case, as long as append is O(1), i think the imperative version has a big benefit, it avoids building the name size list of persons. If you've got a billion names and 2 valid person objects, the imperative version is a big win. Of course that predicate i mentioned is the right way to go though.

I think the right way to do it is with a fold. But that's not built in, so hard to expect of novices.

I see what you're saying about mutation, i guess i have a higher tolerance for mutating stuff that you have the only reference to. I'm not really sure doing a += [validPerson] is much of a win. (but i think would be the right answer in a fold)

ryanschneider• 10 years ago

Personally, I prefer the map/filter approach because people is now a let constant, but I work at a startup with people that don't come from a software development background that would have next to no idea what that line even means. So don't forget your code's target audience, I've personally had to back off some of the more functional styling in Swift just so I'm not the only one that can maintain our code base.

For that reason, I really wish Swift had list comprehensions, just because it's the first "slightly functional" exposure most non-developers get if they come from Python.

tekromancr• 10 years ago

I don't think it's THAT difficult to learn to understand functional style programming. I like to think that I would consider trying to show my team mates the joys and positive aspects of functional programming before I just wrote them off, were I in your situation.

Jtsummers2• 10 years ago

Practice will help make the former more readable.

It helps, for me, that I have more of a math background (academically) than CS (dual majors, but strongly preferred the math coursework).

For me, I see three ways to write, as an example, a summation:

  n
  Σ g(i)
  i=1

  vs.

  seq(1,n).map(g).sum() // or something similar

  vs.

  for(i = 1; i < n; i++)
    sum = g(i)

In my mind, the first is what I see, and is what shows up on paper. The second is what I want to write (and will in any language that lets me). The third is what I often have to write when a language requires that I be more explicit (like C).

baraah• 10 years ago

Shouldn't that be += in the third example?

antfarm2• 10 years ago

Or:

  (1...i).reduce(0) { $0 + g($1) }

solidsnack90002• 10 years ago

There is a certain straightforwardness about the second format, because it is general and plain. But at the same time, it could be anything -- it's much harder to tell at a glance that a for loop is a filter than it is to tell that `filter` is a filter.

benhoyt• 10 years ago

I definitely hear what you're saying. In this particular case I find the more succinct map/filter a little easier to grok, but as soon as you have a bunch more clauses with some flatMap() and reduce(), the "functional" way can get out of hand quickly. In simple cases, I prefer (Python's) list comprehensions. In more complex cases, I prefer the loop(s).

chc3• 10 years ago

I find Python's list comprehensions mind-numbing in many simple cases, such as [x for x in xs if some_condition(x)] rather than just xs.filter(some_condition). We're repeating the variable name three times and zero of those times convey any useful information, and we don't find out until the very end of the line that the everything except "[", "]" and "some_condition" was ignorable.

And in cases where a data-deriving loop has so much going on directly in the loop body that it makes map/filter/reduce hard to read, there's very often some refactoring that would improve either version.

Chris_Newton2• 10 years ago

In this particular case I find the more succinct map/filter a little easier to grok, but as soon as you have a bunch more clauses with some flatMap() and reduce(), the "functional" way can get out of hand quickly.

Funnily enough, I find exactly the opposite: for me, the functional style is significantly easier to work with when things get crazy. I think this is mostly because you tend to be composing recognisable patterns, which in turn means the only custom code you’re writing is the “interesting” parts, like deciding exactly which data to select or exactly how to combine each pair of elements. With lots of loops and conditionals and early exits, I also have to work out whether the code is really doing what it looks like or whether there are edge cases that work differently, and even the “what it looks like” part can wind up scattered across several places in the code that are some distance apart.

Some of the projects I work on do a lot of quite intricate manipulations of complicated data structures. Earlier incarnations were written in Python, but even there I found myself using a functional style for most of these situations as the code base grew in size and complexity. More recently, for various reasons including that one, I’ve been writing this sort of code in Haskell, a language designed for that programming style and therefore cleaner in both syntax and semantics. IMHO, it would be hard to overstate how much easier the newer code is both to write originally and to read, fix and extend later. Possibly the most striking thing is how much shorter the code is: the functional style combined with a language and libraries designed to support it really is remarkably expressive for data crunching work compared to the “longhand” form of writing out all of the loops and conditionals manually.

heisenbit• 10 years ago

I often wish it was only the reading. That may be a matter of getting used to it and there may be pluses to the functional style. But when it comes to using a debugger loops seem to be so much more approachable.

chocolatebunny• 10 years ago

With the map, you know, as soon as you see the map that you're making a new list based on an old list. With the for loop, you have to read and understand every single line of the for loop to understand what it's doing.

ebola1717• 10 years ago

I find it easier to read with the exception of the anonymous variables. In scala, I would write

    val persons = names
        .map { name => Person(name = name) }
        .filter { person => person.isValid }

virtualwhys• 10 years ago

Dunno, it's fairly obvious what you're working with, being explicit doesn't buy that much (for me at any rate).

    val persons =
      names.map(Person.apply).
      filter(_.isValid)

hinkley• 10 years ago

For me it's neutral, except for one critical difference.

I've been shepherding a bunch of front end Javascript tests, and recently had to go through fixing a systemic problem with how we were handling multiple promises.

The broken code didn't look too different from your second example, but the same three people made the same mistake repeatedly, leading to tests that generated empty lists and thus didn't verify anything.

Now, I'm not claiming this is a good pattern of testing. Indeed in all of the straightforward cases I removed the array entirely, and with great relish (especially since it also sped up the tests dramatically). And there are obviously some gaps in their theory of testing that they didn't notice the problem until I pointed it out.

But it did illustrate to me again that there are (alarmingly) a lot of people struggling with basic data manipulation, and if your language supports anything like list comprehensions, I think you should probably get used to using them. It keeps those gaps out, and makes people decompose the problem instead of mashing together a block of conditional code that reads like a Choose Your Own Adventure.

carapace2• 10 years ago

    persons = [person for person in (Person(name) for name in names) if person.isValid()]

This is Python.

contras1970• 10 years ago

i've been struggling with python incomprehensions since time immemorial. map/filter are a breeze.

naasking• 10 years ago

I don't see why either is more difficult. For the functional version, you just need understand the meaning map and filter, and for the imperative version, you need to understand the meaning of for loops and append.

wyager2• 10 years ago

No, but this shouldn't be taken as an indictment of FP general. I prefer

    persons = filter isValid (map init names)

to both. Swift just isn't really a functional language in any useful sense.

mikeash2• 10 years ago

I find the first one to be far easier to read. You can basically just read it from top to bottom and know exactly what it does. "Take names, turn each one into a Person, keep the ones that are valid."

The second one takes a lot more work. First, I have to read through the code and recognize that this is a loop that accumulates values into a new array. Then I have to pick it apart and see exactly where the accumulation takes place, and how that value is derived. It's not hard by any means, but the first one is far more straightforward.

skizm• 10 years ago

Is the first one two loops or one?

Nadya• 10 years ago

Pitching in with the sea of other voices: I prefer the first. Vastly.

In fact, while I still have issue reasoning about some aspects of functional programming when writing the code - it is magnitudes easier for me to read, maintain, modify, or extend the code.

erikpukinskis• 10 years ago

I think the readability is a bit of a wash.

But the second one is more debuggable than the first, which I think is even more important than readability.

In the first case, you need to rewrite the control structure to even be able to inspect anything:

    let allPersons = names.map(Person.init)
    {log allPersons[0].name}
    {breakpoint}
    let persons = allPersons.filter { $0.isValid }

There are lots of data structures in this style of programming that don't have any names. Who knows what kind of data structures map and filter create in order to do their work. Are we allocating 2 arrays? 1? None? In the procedural style, everything that exists in memory has a name.

It's also totally unclear what the order of operations is. Are Person.init and $0.isValid alternated? Is the `map` run in full before the `filter` starts? No way to know.

People talk shit about procedural programming, as if it's antiquated. But the core promise of functional programming—that you can stop thinking about the underlying procedures—never seems to fully pan out. So when you inevitably need to start digging under the hood to figure out what your declarative code actually means in practice, you end up having to think procedurally anyway. Now you're thinking procedurally, but your code is declarative, and the runtime is trying as hard as it can to prevent you from knowing what's exactly happening moment to moment.

I think there are specific cases where a declarative interface is the right abstraction. CSS is a good example. But these are narrowly defined domains with relatively clear semantics that get frequent use, so the time it takes to learn the semantics will pay off.

The idea of littering your entire codebase thickly with declarative APIs, each of which has unique control structures that must be understood in order to read code, is not a good approach in my opinion.

This is what Rails is, and it creates a situation where you are captive to your tools: you can do a lot very easily, but you cannot stray far beyond the declarations that your library author overlords have chosen for you, or you quickly find yourself in a space where in order to not shoot yourself in the foot you need to have a huge body of internals in your head.

catnaroek20• 10 years ago

But the second one is more debuggable than the first, which I think is even more important than readability.

The first is less likely to require debugging in the first place.

There are lots of data structures in this style of programming that don't have any names.

So you can only reason about things that have names? Now we know where idiomatic Java comes from.

Who knows what kind of data structures map and filter create in order to do their work.

In most reasonable implementations, the only data structure being created is the final result (a functorial value in map's case, a sequence in filter's case). For example, in SML:

    fun map _ nil = nil
      | map f (x :: xs) = f x :: map f xs

    fun filter _ nil = nil
      | filter p (x :: xs) =
        if p x then x :: filter p xs
        else filter p xs

> But the core promise of functional programming—that you can stop thinking about the underlying procedures—never seems to fully pan out.

Functional programming doesn't promise freedom from procedures. It promises (and delivers) freedom from physical object identities when you only care about logical values.

---

@banachtarski:

Code that's likely to require debugging (say, because it implements tricky algorithms) should be isolated from the rest anyway, regardless of whether your program is written in a functional style or not. Say, in Haskell:

Bad:

    filter (\x -> tricky_logic_1) $
    map    (\x -> tricky_logic_2) $ xs

Good:

    -- Now trickyFunction1 and trickyFunction2 can be
    -- tested in isolation. Or whatever.
    trickyFunction1 x = ...
    trickyFunction2 x = ...
    
    filter trickyFunction1 (map trickyFunction2 xs)

imh• 10 years ago

You're 100% right about debugability. It's the main reason I don't push to use haskell every day. That said, I think we really need to get clever and think of good tools to debug in spite of these difficulties. Most complex bugs are from interacting systems that can't be found by step debugging. For example, the following code is considered pythonic, and for good reason:

    fs = [f(x) for x in xs]

The other commenter's points about being cleaner and less prone to debugging are totally legit. If we can make e.g. list/set comprehensions debuggable, we can probably make other FP idioms debuggable and get the best of both worlds.

Kinda reminds me of microservices, actually. Tough to debug, but good in other ways.

partiallogic• 10 years ago

I find it easier to read but I'd struggle to come up with it myself from zero

louthy• 10 years ago

I find the first example much more intuitive. It declares intent, rather than the mechanics of delivery. And that's where we need to be heading as programmers.

RotsiserMho• 10 years ago

This. So much. Declaring intent (what) is much more useful than declaring the mechanics (how). I don't typically care about the "how", just the "what". And the more readable that is, the better.

bertiewhykovich2• 10 years ago

In Python, the only good language, this could be expressed as:

    [person for person in (Person(name) for name in names) if person.isValid()]

or:

    filter(lambda p: p.isValid, map(Person, names))

or:

    persons = []
    for name in names:
        person = Person(name)
        if person.isValid():
            persons.append(person)

harpocrates2• 10 years ago

So much for "There's Only One Way To Do It". :)

allengeorge• 10 years ago

I find it much easier. It might be a question of getting used to it.

lacampbell• 10 years ago

I found the first one easier to read up until I got to the lambda syntax. Map and Filter are intuitive to me, but I wasn't at all clear what { $0.isValid } was doing.

weaksauce• 10 years ago

Coming from ruby and using a lot of maps and functional constructs I personally think the first one is way easier to read.

lucio• 10 years ago

Me too. The first one is harder to read, and also the first one is harder to extend if the business rules change.

zmmmmm2• 10 years ago

There seem to be a lot of "pretend" functional languages around these days. I have recently been engaging with Scala. Having heard and read so much about how it embraces functional style I was kind of shocked to find the number of limitations and practical impediments to actually using it that way. I am starting to wonder if functional programming has finally fallen victim to the same problem that has afflicted all other methodologies - becoming too popular, part of the hype cycle and getting misinterpreted and misapplied everywhere as a consequence.

lmm• 10 years ago

Scala is about as functional as it gets - the only remotely mainstream language that's more so is Haskell, IME. What kind of issues did you have?

stingraycharles2• 10 years ago

This sounds pretty misinformed. There are plenty of choices in between Scala and Haskell; Clojure and Elixir are two other relatively popular languages that come to mind.

catnaroek20• 10 years ago

ML sits somewhere in between Scala and Haskell. Like Haskell, ML has typed mutable data (`foo` and `foo ref` are different types). Like Scala, ML doesn't distinguish between effectful and effect-free procedures.

Scala is similar to Lisp and other higher-order-but-not-quite-functional languages in that it's littered with unwanted object identities. All you need to do is use the `eq` method to see when two “equal” objects are really not the same.

zmmmmm2• 10 years ago

I didn't mean that the language itself isn't functional - it certainly wants to be. But when I tried to naively apply it using the idiomatic constructs that I found online I got a lot of performance and memory issues. In fact some code that I wrote in Groovy (which I thought would be slow) was much faster than the naive port I did to Scala (which is commonly said to hit nearly native java speed). When I dug into those by profiling it turned out that I needed to have a deep understanding of how the compiler was treating Scala constructs to avoid performance pitfalls. A good example is here:

https://issues.scala-lang.org/browse/SI-1338

Another is that I've almost never managed to use recursion in my algorithms because Scala seems to have very limited ability to successfully optimize tail recursive calls.

Another problem is all kinds of unexpected boxing, unboxing, and implicit conversions of collections that I wasn't expecting.

Again - all the language features are there, just in practice it isn't working out for me very well when I try to use them idiomatically. I'm still learning. But I also learned Haskell and the experience was very different - once I figured out the idiomatic way to do something it usually was also well optimized.

badsock• 10 years ago

RIP the term "Object Oriented" as Alan Kay defined it.

melling2• 10 years ago

The talk discusses how you can incorporate a few functional techniques (map, filter) but the speaker's main goal seems that he wants Swift to be changed to allow for a couple of other functional ideas to be brought into the language.

Where's the Swift proposal for the enhancements? Product and Sum support? Algebraic data types?

delegate• 10 years ago

I enjoyed the talk, thank you.

The part about "lifting" a type was an 'aha' moment for me and now I understand!*.

I mean, I did this intuitively, but now I know the name of the technique, which is really good.

Thank you, I've learned something new today!

Swift and the Legacy of Functional Programming

Related Stories