Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift and the Legacy of Functional Programming

realm.io

Post reply on HN
Print view View original

31–40 of 188 posts

Re: Swift and the Legacy of Functional Programming

#31

Post by BrandonBradley »

seanalltogether wrote: post #16

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.

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

Re: Swift and the Legacy of Functional Programming

#32

Post by hota_mazi »

seanalltogether wrote: post #16

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.

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.

Re: Swift and the Legacy of Functional Programming

#33

Post by ryanschneider »

seanalltogether wrote: post #16

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.

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.

Re: Swift and the Legacy of Functional Programming

#34

Post by antfarm »

niklasrde wrote: post #23
seanalltogether wrote: post #16

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.

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 do…

It's ugly, but possible:

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

Re: Swift and the Legacy of Functional Programming

#35

Post by lmm »

zmmmmm wrote: post #26

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 o…

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?

Re: Swift and the Legacy of Functional Programming

#36

Post by pjmlp »

niklasrde wrote: post #23
seanalltogether wrote: post #16

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.

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 do…

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.

Re: Swift and the Legacy of Functional Programming

#37

Post by Jtsummers »

seanalltogether wrote: post #16

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.

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
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).

Re: Swift and the Legacy of Functional Programming

#38

Post by tekromancr »

ryanschneider wrote: post #33
seanalltogether wrote: post #16

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.

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…

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.

Re: Swift and the Legacy of Functional Programming

#39

Post by solidsnack9000 »

seanalltogether wrote: post #16

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.

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.

Re: Swift and the Legacy of Functional Programming

#40

Post by badsock »

zmmmmm wrote: post #26

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 o…

RIP the term "Object Oriented" as Alan Kay defined it.
Post reply on HN