5 ms·

> If you lean more towards the functional programming paradigm side of Scala then you’ll probably love the following about Rust’s type system Some of the more

> If you lean more towards the functional programming paradigm side of Scala then you’ll probably love the following about Rust’s type system Some of the more popular functional languages have advanced type systems, but not all functional languages are statically typed. Lisp, the granddaddy of all FP languages, is dynamically typed. So is Elixir. Can we stop conflating FP with static typing?

dlwh 9y ago
Sure, but the FP side of Scala is definitely firmly in the advanced static type system camp.
kod 9y ago
Probably not, at least until people stop conflating "has first class functions" with "avoids or tracks mutation".
swsieber 9y ago
I don't think they were. Static type systems can greatly hinder FP. Or to be more specific, language semantics and runtime behavior (encoded by the type system) can influence how powerful your FP is - and by "powerful", I mean how much boiler plate you need and how much you can generalize things. So yes, having certain characteristics of type systems do help with FP while not being core to FP. It can certainly make things more pleasant though.
kibwen 9y ago
> Can we stop conflating FP with static typing? I'm all for that, but first we probably need to actually define what "functional programming" means, which seems to be one of the great unresolveable debates of computer science. :P To wit, I can think of no reasonable definition of functional programming that includes Lisp, Scheme, ML, and Haskell that does not also include every popular language aside from C. Even Java has first-class functions these days, sort of...
- lmkg 9y ago
  I tend to use the term "function-oriented" rather than "functional" since I think it fits the spirit of the phrase better. You're right that language features alone won't distinguish enough, and that means that functional programming is more about culture and standard practices. Once you embrace that, it's a bit easier to wrangle out a definition. The definition I have in my head is something along the lines of "functions are the tool that the language prefers to address common software design concerns." So for example, Encapsulation is a big deal when designing software. Object-oriented languages will address this concern with their object system (via accessibility modifiers), while function-oriented languages tend to address this with functions, via lexical scoping and closures. OOP languages use their object system to achieve runtime-dynamic behavior through inheritance or composition or interfaces, while function-oriented languages will more often try to pass first-class functions as arguments. And so forth. It's not a 100% thing. Common Lips will solve some of its problems with macros or its module system, and ML will solve some of its problems with types. But you do find the languages (or communities) prefer functions over their object systems, while e.g. Python or Ruby prefer the reverse. Although, I do find myself wondering if Haskell should actually be considered a type-oriented language. Again, it's not just about the features of the type system, it's the fact that the type system is the main tool that it tries to use to solve every problem about designing software.
  - jholman 9y ago
    I strongly agree. We see a lot of definitions of functional bandied about, often conflating functional with Haskell or with Scala. Those definitions seem to ignore the history of functional programming, including Lisp, as qsymmachus noted. So that's silly. And conversely, one sees a lot of definitions of OO that appear to mean "Java" or "C++". Again, nonsensical when one considers Self, or to a lesser degree Smalltalk. I do like your conception wherein a language is function to the degree to which it prefers functions as its favourite tool for solving problems, and/or OO to the degree to which it prefers objects as its favourite tool. Regarding encapsulation as your particular example, OO is clearly fairly obsessed with encapsulation, being almost the definition of an object: a bundle of encapsulated state with the externally-facing behaviour that that object affords. I think that many functional communities/practitioners see this as a much less urgent issue, often going so far as to make no active effort toward encapsulation at all (i.e. not everyone bothers with the lexical-scopes-and-closures solution). Thus we get ideas like "smart functions, dumb data", an idea which makes no sense in OO land.
lacampbell 9y ago
I think it's a losing battle. How 'functional' something is in 2017 is pretty much 'how close is this to haskell?'.
nilved 9y ago
> Lisp, the granddaddy of all FP languages, is dynamically typed. Lisp is a multi-paradigm language of which FP is one of them. You're referring to Standard ML or Haskell and that should explain why people conflate FP with static typing.
daxfohl 9y ago
I think this was more to point out that for those who like the functional aspects of Scala's type system with respect to Java's, but don't like being hamstrung by the need for Java compatibility, Rust has the goods. I didn't read it as espousing static types for FP a priori.
flavio81 9y ago
I hear you brother. And I should add that I don't believe in static typing being a Great Thing to Have. Strict typing is a good thing, but Static typing? I feel Static typing is like those little wheels fitted to bicycles so kids don't fall down when riding a bike. Yes, you can never fall down when using those wheels, but (a) your cornering ability will be slower and (b) you still can crash against something, fall into a pit, etc...

dlwh 9y ago

Sure, but the FP side of Scala is definitely firmly in the advanced static type system camp.

kod 9y ago

Probably not, at least until people stop conflating "has first class functions" with "avoids or tracks mutation".

swsieber 9y ago

I don't think they were. Static type systems can greatly hinder FP. Or to be more specific, language semantics and runtime behavior (encoded by the type system) can influence how powerful your FP is - and by "powerful", I mean how much boiler plate you need and how much you can generalize things. So yes, having certain characteristics of type systems do help with FP while not being core to FP. It can certainly make things more pleasant though.

kibwen 9y ago

> Can we stop conflating FP with static typing? I'm all for that, but first we probably need to actually define what "functional programming" means, which seems to be one of the great unresolveable debates of computer science. :P To wit, I can think of no reasonable definition of functional programming that includes Lisp, Scheme, ML, and Haskell that does not also include every popular language aside from C. Even Java has first-class functions these days, sort of...

lmkg 9y ago
I tend to use the term "function-oriented" rather than "functional" since I think it fits the spirit of the phrase better. You're right that language features alone won't distinguish enough, and that means that functional programming is more about culture and standard practices. Once you embrace that, it's a bit easier to wrangle out a definition. The definition I have in my head is something along the lines of "functions are the tool that the language prefers to address common software design concerns." So for example, Encapsulation is a big deal when designing software. Object-oriented languages will address this concern with their object system (via accessibility modifiers), while function-oriented languages tend to address this with functions, via lexical scoping and closures. OOP languages use their object system to achieve runtime-dynamic behavior through inheritance or composition or interfaces, while function-oriented languages will more often try to pass first-class functions as arguments. And so forth. It's not a 100% thing. Common Lips will solve some of its problems with macros or its module system, and ML will solve some of its problems with types. But you do find the languages (or communities) prefer functions over their object systems, while e.g. Python or Ruby prefer the reverse. Although, I do find myself wondering if Haskell should actually be considered a type-oriented language. Again, it's not just about the features of the type system, it's the fact that the type system is the main tool that it tries to use to solve every problem about designing software.
- jholman 9y ago
  I strongly agree. We see a lot of definitions of functional bandied about, often conflating functional with Haskell or with Scala. Those definitions seem to ignore the history of functional programming, including Lisp, as qsymmachus noted. So that's silly. And conversely, one sees a lot of definitions of OO that appear to mean "Java" or "C++". Again, nonsensical when one considers Self, or to a lesser degree Smalltalk. I do like your conception wherein a language is function to the degree to which it prefers functions as its favourite tool for solving problems, and/or OO to the degree to which it prefers objects as its favourite tool. Regarding encapsulation as your particular example, OO is clearly fairly obsessed with encapsulation, being almost the definition of an object: a bundle of encapsulated state with the externally-facing behaviour that that object affords. I think that many functional communities/practitioners see this as a much less urgent issue, often going so far as to make no active effort toward encapsulation at all (i.e. not everyone bothers with the lexical-scopes-and-closures solution). Thus we get ideas like "smart functions, dumb data", an idea which makes no sense in OO land.

lacampbell 9y ago

I think it's a losing battle. How 'functional' something is in 2017 is pretty much 'how close is this to haskell?'.

nilved 9y ago

> Lisp, the granddaddy of all FP languages, is dynamically typed. Lisp is a multi-paradigm language of which FP is one of them. You're referring to Standard ML or Haskell and that should explain why people conflate FP with static typing.

daxfohl 9y ago

I think this was more to point out that for those who like the functional aspects of Scala's type system with respect to Java's, but don't like being hamstrung by the need for Java compatibility, Rust has the goods. I didn't read it as espousing static types for FP a priori.

flavio81 9y ago

I hear you brother. And I should add that I don't believe in static typing being a Great Thing to Have. Strict typing is a good thing, but Static typing? I feel Static typing is like those little wheels fitted to bicycles so kids don't fall down when riding a bike. Yes, you can never fall down when using those wheels, but (a) your cornering ability will be slower and (b) you still can crash against something, fall into a pit, etc...