Hacker News new | comments | show | ask | jobs | submit login
Show HN: FunctionKit – Approachable functional concepts brought to Swift (github.com)
51 points by mpangburn 3 months ago | hide | past | web | favorite | 8 comments



Just reading the README.md makes me feel like I've leveled up my understanding of functional concepts, well done!

That said, pardon my ignorance on the subject -

> This seems nice, but we've introduced an inefficiency: in mapping over the array twice, we unnecessarily create an intermediate array.

Isn't this an optimisation that could/should be handled by the compiler (JIT evaluation or something like that)?


We call this type of optimisation "stream fusion".

In an ideal world, the compiler would always know to do this for us. In practice, it's very difficult (in most languages) to determine whether this optimisation is correct.

In the README example's case, the optimisation happens to be correct because both mapping functions are pure. If they had side effects, then stream fusion might create different results than the original code. Let's make this concrete with an example.

Say our array is `[1, 2]` and our functions are `function A(n) { print("A: "+n) }` and `function B(n) { print("B: "+n) }`. Then _without_ stream fusion, we would see the following output: ``` A: 1 A: 2 B: 1 B: 2 ```

_With_ stream fusion, we would see different output: ``` A: 1 B: 1 A: 2 B: 2 ```

Since the mapping functions have side effects, stream fusion is not valid here.

Some languages can do automatic implicit stream fusion. Haskell is a great example of this: it's able to determine when stream fusion is correct because the language has an _effect tracking system_ where functions with side effects are distinct from functions without side effects.


> In practice, it's very difficult (in most languages) to determine whether this optimisation is correct. > > [...] the optimisation happens to be correct because both mapping functions are pure. If they had side effects, [...]

TLDR: make all your functions pure. It'll make it so much simpler for you, your coworkers, but also the compiler(!) to reason about your code.

About half of the bugs and issues I come across in my $DAYJOB are because code that I use (through a third-party library) is not pure. If I had a penny every time I fixed a bug caused by impure code, I'd be rich.


> If I had a penny every time I fixed a bug caused by impure code, I'd be rich.

Ok, let’s be extremely optimistic and say you fix 25 functional purity bugs a day and you’ve been fixing impure code for twenty years.

$0.01/bug * 25 bugs/day * 250 working days/year * 20 years = $1,250.

I guess that $1,250 could be rich to some, but I do think making a quarter per full day of fixing bugs doesn’t seem like a great way to get there.


>Isn't this an optimisation that could/should be handled by the compiler (JIT evaluation or something like that)?

Interesting question, which i also asked myself every once in a while, but unfortunately couldn't find a clear answer so far. Maybe someone with deeper understanding of swiftc or aot compilers in general here could clarify?

ps.: To give my reply a meaning. JIT optimization in particular can not happen here, because swift is an ahead of time compiled language, which means the compiler produces machine code which runs directly on your CPU. JIT is a thing for languages which run in a virtual machine (e.g. Java or C#) or an interpreter (e.g. Javascript).


When the compiler handles this, it is usually called "automatic deforestation". One technique for this (that Haskell's compiler implements) is "stream fusion". A brief overview of stream fusion is given at https://stackoverflow.com/questions/578063/what-is-haskells-... and a lengthier paper is at http://fun.cs.tufts.edu/stream-fusion.pdf.


> That said, pardon my ignorance on the subject -

What is Functional Programming and why is it significant ?


This would likely pair well with this functional interface to uitableview.

https://github.com/Shopify/FunctionalTableData




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: