0

I am a Swift developer and am trying to adopt a functional / reactive style in my code. I have been using ReactiveCocoa in all my projects and I have started giving RAC 3.0 a try. One thing I have seen is that in project, there is heavy use of curried functions that have a global scope (i.e. not tied to an instance).

What I am keen to understand is why global functions is a good idea?

Is this something that is unique to curried functions or is it a general functional programming attribute?

2
  • Would you sow some code you are concerned about, to make sure we speak about the same?
    – User
    Jul 15, 2015 at 14:24
  • Well, I don't know who familiar you are with Reactive Cocoa but in RAC 3.0 all of the signal operators are not tied to the RACSignal or RACSignal classes but instead are free global curried functions.
    – villy393
    Jul 15, 2015 at 16:01

2 Answers 2

2

At it's purest, functional programming is about defining a set of data types, devoid of behaviour, and then defining a set of "free" functions over those data types, which can be freely extended as need arises. This usually comes with some sort of namespace/module mechanism, so despite the fact that the functions are free, they're not global in the sense that there's a single namespace for everything (note: I know next to nothing about Swift, so if it doesn't have a namespacing mechanism for free functions and if they indeed fall into a global namespace, then I would say it's something to be discouraged, and find the language lacking in that regard).

Now, assuming you have namespaces, is it a good idea? I suppose it's good enough, since it works for many people (and they will usually claim it works better than the alternative). It's a good way to model things in general, and it's usually a better way to model abstract concepts that would feel forced being squeezed into OO class hierarchies. That said, it has its shortcomings as illustrated by the expression problem, where FP falls squarely on the "easy to add functions, hard to add cases" side. Not coincidentally, this means that many things that are dos in FP are dont's in OO, and vice versa.

That's why the recent hybrid OO/FP languages, Swift one of them, are set on claiming some sort of middle ground between the two. But where this middle ground is, and what's just Haskell/Java written in another language will vary on a case by case basis.

5
  • "...FP falls squarely on the "easy to add functions, hard to add cases" side." Only if you don't use abstraction. That's analogous to using only structs and unions. As soon as you use abstract data types (which are roughly analogous to classes) or typeclasses (which are roughly analogous to interfaces) you're on the same side of the expression problem as OO languages. The real point of hybrid languages is interoperability with existing languages.
    – Doval
    Jul 18, 2015 at 15:31
  • @Doval: Typeclasses are also pretty much unique to Haskell. What I'm describing here are the bare-bones fundamentals of FP. Sure, FP languages are trying to solve expression problem in their own ways, just like OO languages are acquiring functional features to patch their shortcomings.
    – scrwtp
    Jul 18, 2015 at 16:30
  • @Doval: And I disagree on hybrid languages. The real point is to have a more expressive language. Seamless interoperability is just a good selling point. In the ideal world, there would be no "other" languages to interoperate with :)
    – scrwtp
    Jul 18, 2015 at 16:44
  • However, 1) abstract data types aren't unique to Haskell, 2) Standard ML/OCaml's functors provide comparable functionality to Typeclasses, and 3) you don't need either one to have something analogous to an interface. An interface is just a bunch of functions glued together in a container (usually a record), all of which take themselves as their first argument. Both paradigms (FP and OO) have comparable powers of abstraction. FP seeks strong static guarantees and to limit and control side effects; OO doesn't. There's not much to gain from mixing them other than interoperability.
    – Doval
    Jul 18, 2015 at 17:09
  • @Doval: I think the term would be "theoretically comparable". The elephant in the room is that when programming in the large, FP loses its edge rather quickly, while OO thrives. I would think a language only stands to gain if it adopts OO approaches at that level.
    – scrwtp
    Jul 18, 2015 at 22:48
-3

my knowledge about functional programming is very limited

In functional programing, calling a function only affect the instance calling it so you let the allow the function to be call from everywhere can't cause bug except in the module calling the function (which is the one having a buggy behaviour).

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.