3 ms·

> FP aims to "start at the best and stay there" I'd say there's a difference between purely functional languages and functional concepts in general. Purely fun

by qsort 5y ago

> FP aims to "start at the best and stay there" I'd say there's a difference between purely functional languages and functional concepts in general. Purely functional languages have indeed remained relatively unpopular (I'm not really sure why, but I'd guess it's a convex combination of "it's not how the machine works", "it's relatively esoteric unless you have studied math or cs" and "not very much backing/support"), but we've also seen functional concepts "contaminate" traditional OO languages. Yes, I know, it's not really "functional" and diehard FP programmers will hate me, but I'd still say it's evidence that the functional paradigm can be (and in fact has been) used to "increment the goodness".

joe_the_user 5y ago
The other thing about functional programming is it involves a sort of tradeoff that's very different from object orientation. It makes functions into "first class (language) objects". Manipulating functions directly is a very power ability. As tradeoff, making functions pure and making variable immutable limits that power and makes your operations on functions understandable as well as powerful. Because if you take functions with side effects and manipulate these in various ways, you can quickly wind-up with a powerful but incomprehensible system. This means that "functional effects" do sometimes do best as something like subsystems called by the main system.
Jtsummers 5y ago
> Purely functional languages have indeed remained relatively unpopular (I'm not really sure why, but I'd guess it's a convex combination of "it's not how the machine works", "it's relatively esoteric unless you have studied math or cs" and "not very much backing/support") My intuition on this: Procedural/imperative thinking is more "natural" for most people. Asking someone to explain a process without any formal training in any formal language/modeling process on this (ie, a non-programmer) they'll give you a procedural/imperative description of what to do. OOP languages are, mostly, procedural/imperative languages with extra constructs. To varying degrees these constructs are organizational as much as actually substantive additions to the execution model. For instance, classes in Java are modules for collecting related behavior and controlling access to (usually) private data fields. They can be seen as "rich" structs: data objects + procedures for altering the data. Now, polymorphism actually adds a lot more and can be used to subsume other control flow mechanisms, I'm not saying that OOP is just procedural + organizational elements. But as a first pass, people can step into OOP by treating it as such and learn the rest as they continue. FP languages, by contrast, do not start off as procedural + first class functions or expressive type systems. In particular, the pure FP languages drop the imperative notions (or obscure them). This creates a major hurdle for many would-be learners. Their intuition doesn't apply to these languages. See also Prolog and relational programming for another area where people's natural tendency towards imperative thinking creates a major block on learning (or on using it to its potential).
- bcrosby95 5y ago
  Yep. This is also why people suck at OOP, because most "good" OOP isn't a series of instructions - it's an abstraction layer - e.g. "ask, don't tell". Lots and lots of "OOP" ends up bad and telling and digging into internals with train.wrecks.like.this. Really, most people would probably be more at home coding in something like a safer version of C.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]

by qsort 5y ago

joe_the_user 5y ago

The other thing about functional programming is it involves a sort of tradeoff that's very different from object orientation. It makes functions into "first class (language) objects". Manipulating functions directly is a very power ability. As tradeoff, making functions pure and making variable immutable limits that power and makes your operations on functions understandable as well as powerful. Because if you take functions with side effects and manipulate these in various ways, you can quickly wind-up with a powerful but incomprehensible system. This means that "functional effects" do sometimes do best as something like subsystems called by the main system.

Jtsummers 5y ago

> Purely functional languages have indeed remained relatively unpopular (I'm not really sure why, but I'd guess it's a convex combination of "it's not how the machine works", "it's relatively esoteric unless you have studied math or cs" and "not very much backing/support") My intuition on this: Procedural/imperative thinking is more "natural" for most people. Asking someone to explain a process without any formal training in any formal language/modeling process on this (ie, a non-programmer) they'll give you a procedural/imperative description of what to do. OOP languages are, mostly, procedural/imperative languages with extra constructs. To varying degrees these constructs are organizational as much as actually substantive additions to the execution model. For instance, classes in Java are modules for collecting related behavior and controlling access to (usually) private data fields. They can be seen as "rich" structs: data objects + procedures for altering the data. Now, polymorphism actually adds a lot more and can be used to subsume other control flow mechanisms, I'm not saying that OOP is just procedural + organizational elements. But as a first pass, people can step into OOP by treating it as such and learn the rest as they continue. FP languages, by contrast, do not start off as procedural + first class functions or expressive type systems. In particular, the pure FP languages drop the imperative notions (or obscure them). This creates a major hurdle for many would-be learners. Their intuition doesn't apply to these languages. See also Prolog and relational programming for another area where people's natural tendency towards imperative thinking creates a major block on learning (or on using it to its potential).

bcrosby95 5y ago
Yep. This is also why people suck at OOP, because most "good" OOP isn't a series of instructions - it's an abstraction layer - e.g. "ask, don't tell". Lots and lots of "OOP" ends up bad and telling and digging into internals with train.wrecks.like.this. Really, most people would probably be more at home coding in something like a safer version of C.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]