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

71–80 of 188 posts

Re: Swift and the Legacy of Functional Programming

#71

Post by junke »

eridius wrote: post #58
junke wrote: post #44

Earlier quoted context omitted.

Take it from the other side: why would a language that allows to create higher-order functions/closures not be called functional?

Because that makes the term meaningless. You may as well ask "why don't we call any language that lets you do two actions in sequence 'procedural'?"

A term does not necessarily become meaningless when it applies to a lot of things. "Functional" might be a broad category after all, not the exclusive name of a subset of functional languages. And if your language allows different paradigms, it will be called "functional and imperative and object-oriented... ". At best, if a property is so common that most language have it, it can be assumed to be satisfied by default. As for "procedural", the definition on wikipedia is a little more precise and does not apply to all languages: https://en.wikipedia.org/wiki/Procedural_programming.

Re: Swift and the Legacy of Functional Programming

#72

Post by prodigal_erik »

Scriptor wrote: post #64
wyager wrote: post #63

Earlier quoted context omitted.

Huh? No, anyone who writes it in Haskell would not use those lambda abstractions. You would just use "filter isValid (map Person names)".

I'm assuming Person is a record constructor, is isValid here a field in that record or another function?

Haskell doesn't distinguish the two. If you define Person with named fields including isValid, you automatically get a function named isValid that returns that field, or you can write your own isValid function that examines the whole Person.

Re: Swift and the Legacy of Functional Programming

#73

Post by bad_user »

stingraycharles wrote: post #43
lmm wrote: post #35

Earlier quoted context omitted.

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?

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.

You might have fallen victim to misinformation yourself.

In general, functional programming in Scala tends to be more FP, with code tending to be more pure than in Clojure and I have no experience with Elixir, but I have some experience with Erlang and FP code in Scala tends to be held at a higher standard than in Erlang.

Of course, you've picked 2 dynamic languages as examples and FP in dynamic languages is different than that practiced in static languages like Haskell or Scala. LISP developers for example don't think so much about monads or other abstractions with mathematical foundations, because LISP developers tend to work around such needs by doing macros (which then have composability problems) or by bending the rules a little, or in other words I've seen no LISP to make a serious attempt at reasoning about I/O in a pure way.

And IMO code in static languages tends to be more pure because of the types, because by having an expressive type system, the developers then want that type system to explain everything. Or in other words, dynamic languages are cool for your day job, but if you want to actually feel what FP is all about, you're better off going for a static languages like Haskell, or even Scala or OCaml.

PS: http://typelevel.org/

Re: Swift and the Legacy of Functional Programming

#74

Post by catnaroek »

lmm wrote: post #35
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?

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.

Re: Swift and the Legacy of Functional Programming

#75

Post by bad_user »

grabcocque wrote: post #4

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

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.

Re: Swift and the Legacy of Functional Programming

#76

Post by Nadya »

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.

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.

Re: Swift and the Legacy of Functional Programming

#77

Post by bad_user »

lmkg wrote: post #42
grabcocque wrote: post #4

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

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, enca…

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.

Re: Swift and the Legacy of Functional Programming

#78

Post by junke »

eridius wrote: post #59
Someone wrote: post #53

Earlier quoted context omitted.

It is a bit snarky, but also has a ground truth: pointers to functions aren't functions. More importantly, you cannot make functions in C. For example, one cannot write a function that, given pointers to functions that compute 1/x and sin(x) , returns a pointer to a function that returns 1/sin(x)

That's not a function, that's a closure. And you can simulate that in C by creating a struct that contains the function pointer and the set of captured data (and then when you invoke the function you pass the struct to it as a parameter).

Yes, hence the distinction between first-class features and others, which you have to implement yourself.

Re: Swift and the Legacy of Functional Programming

#79

Post by catnaroek »

js8 wrote: post #69
lmkg wrote: post #42

Earlier quoted context omitted.

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, enca…

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

Here are some features that the lambda calculus doesn't have: n-ary functions for n other than 1, macros (or any other means to analyze its own syntax), dynamically scoped variables, physical object identities, etc. In the untyped lambda calculus, any two alpha-equivalent terms are internally indistinguishable - in fact, you can even make them externally indistinguishable using a nameless representation of syntax like “de Bruijn indices”.

So much for “Lisp comes from [the] untyped lambda calculus”.

Re: Swift and the Legacy of Functional Programming

#80

Post by kibwen »

bad_user wrote: post #75
grabcocque wrote: post #4

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

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.

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