6 ms·

IMO a functional first language should be the first language people learn. Much easier to go from FP to OOP and even PP rather than the other direction.

iainmerrick 2y ago
How do you know it’s easier?
- bowsamic 2y ago
  There seems to be this weird notion going around that the only reason imperative languages seem easier to people is because they're taught them first, and that if we teach Haskell or Scheme to everyone first then they would find imperative programming unintuitive. I honestly think it's a load of rubbish. The fact that humans easily understand "a list of instructions executed one after the other" over monads and tail recursion is not because they are taught C first, but because that's just the basic instructions we communicate actions with. Recipes, directions, instructions for how to tie your shoe laces, etc. They're all imperative
  - agumonkey 2y ago
    It's a complex topic. The thing is that sequential mutable state doesn't scale, and you'll quickly have to introduce routines, modules, objects of whatever to have some control over side effects. The natural aspect of a list of instruction is exhilarating for many but is also rope to hang your self because you won't try to separate concepts and scopes since everything is accessible. So much stuff just doesn't happen when you don't use this paradigm. Instead of drowning in state variable improperly synchronised, you suddenly rise above and start rewriting trees.
    - knome 2y ago
      >you'll quickly have to introduce routines, modules, objects of whatever to have some control over side effects that claim seems absurd. all the functional languages I've come across also frequently use routines, modules, and 'objects of whatever' to manage the complexity of huge amounts of code. objects/entities are just a pattern for hiding complexity behind a simple interface. they can be useful in any language, regardless of mutability.
      - zogrodea 2y ago
        I think, because of the mention about controlling mutability/side-effects, "object" in that post means OOP-style objects which mutable state. It's not an issue with immutable objects/structs (or I guess "records" which is the term I'm used to with functional languages).
        knome 2y ago
        functional languages still have to deal with storing and manipulating changing value and state, and it is still often advantageous to hide the complexities of that storage and manipulation behind simple interfaces throughout the codebase, using opaque values with helper functions to manipulate them. OOP as a pattern, rather than a language construct. the great advantage here is that all manipulations are local. there is no spooky action at a distance in an immutable language. as long as you stay out of the IO monad, anyways.
        zogrodea 2y ago
        I just use simple tail-recursion in an event loop to help manage state. let rec eventLoop state = let input = getInput () let newState = update input state drawState state; eventLoop newState The update function takes an existing state and an input record (key events, etc.), returning a new state (which may have nested records within itself but it is all immutable). New state is kept by the recursion (passing new state to the same function). The only IO is getting input and drawing, which are inherently side-effecting operations. I do have nested records, but (at each stage) they get joined into a new parent record. No mutability there.
  - xigoi 2y ago
    Functional programming is not just about monads. I bet it’s easier to explain numbers.map(x => x * x) than let result = []; for (let i = 0; i < numbers.length; ++i) { result.push(numbers[i] * numbers[i]); }
    - bowsamic 2y ago
      Perhaps, but this is a somewhat contrived example. No side effects, no complicated data structures, etc. Sure, in the specific case of "parallelised" operations on an array it is simple. But anything more complicated and suddenly you're in a bad situation. For example, what if you now want to write to a log before each multiplication, or you want to time how long each multiplication takes? Suddenly, the latter seems far preferable.
      - xigoi 2y ago
        numbers.map(x => { console.log(x); return x * x; }) Still easier to understand than the for loop.
        bowsamic 2y ago
        Okay but now this is just imperative lol, it's no longer functional at all, since your function is now just a sequence of instructions, i.e. it's a procedure rather than a pure function. You've just proved my point
        xigoi 2y ago
        It’s a mix of functional and imperative style. Most functional languages (other than Haskell) allow you to easily write code like this.
        bowsamic 2y ago
        Yes I know but that's not the point of my original post, which is about people who claim that a pure functional style would be considered easier if it were taught first. I'm saying that falling back on imperative is almost always easier than sticking with pure functional
- LtWorf 2y ago
  He likes it more.
- Akronymus 2y ago
  Because I know what opinion I have.
- demi56 2y ago
  You don’t have to worry people have been saying this for more than a decade now and I see no action about it

iainmerrick 2y ago

How do you know it’s easier?

bowsamic 2y ago
There seems to be this weird notion going around that the only reason imperative languages seem easier to people is because they're taught them first, and that if we teach Haskell or Scheme to everyone first then they would find imperative programming unintuitive. I honestly think it's a load of rubbish. The fact that humans easily understand "a list of instructions executed one after the other" over monads and tail recursion is not because they are taught C first, but because that's just the basic instructions we communicate actions with. Recipes, directions, instructions for how to tie your shoe laces, etc. They're all imperative
- agumonkey 2y ago
  It's a complex topic. The thing is that sequential mutable state doesn't scale, and you'll quickly have to introduce routines, modules, objects of whatever to have some control over side effects. The natural aspect of a list of instruction is exhilarating for many but is also rope to hang your self because you won't try to separate concepts and scopes since everything is accessible. So much stuff just doesn't happen when you don't use this paradigm. Instead of drowning in state variable improperly synchronised, you suddenly rise above and start rewriting trees.
  - knome 2y ago
    >you'll quickly have to introduce routines, modules, objects of whatever to have some control over side effects that claim seems absurd. all the functional languages I've come across also frequently use routines, modules, and 'objects of whatever' to manage the complexity of huge amounts of code. objects/entities are just a pattern for hiding complexity behind a simple interface. they can be useful in any language, regardless of mutability.
    - zogrodea 2y ago
      I think, because of the mention about controlling mutability/side-effects, "object" in that post means OOP-style objects which mutable state. It's not an issue with immutable objects/structs (or I guess "records" which is the term I'm used to with functional languages).
      - knome 2y ago
        functional languages still have to deal with storing and manipulating changing value and state, and it is still often advantageous to hide the complexities of that storage and manipulation behind simple interfaces throughout the codebase, using opaque values with helper functions to manipulate them. OOP as a pattern, rather than a language construct. the great advantage here is that all manipulations are local. there is no spooky action at a distance in an immutable language. as long as you stay out of the IO monad, anyways.
        zogrodea 2y ago
        I just use simple tail-recursion in an event loop to help manage state. let rec eventLoop state = let input = getInput () let newState = update input state drawState state; eventLoop newState The update function takes an existing state and an input record (key events, etc.), returning a new state (which may have nested records within itself but it is all immutable). New state is kept by the recursion (passing new state to the same function). The only IO is getting input and drawing, which are inherently side-effecting operations. I do have nested records, but (at each stage) they get joined into a new parent record. No mutability there.
- xigoi 2y ago
  Functional programming is not just about monads. I bet it’s easier to explain numbers.map(x => x * x) than let result = []; for (let i = 0; i < numbers.length; ++i) { result.push(numbers[i] * numbers[i]); }
  - bowsamic 2y ago
    Perhaps, but this is a somewhat contrived example. No side effects, no complicated data structures, etc. Sure, in the specific case of "parallelised" operations on an array it is simple. But anything more complicated and suddenly you're in a bad situation. For example, what if you now want to write to a log before each multiplication, or you want to time how long each multiplication takes? Suddenly, the latter seems far preferable.
    - xigoi 2y ago
      numbers.map(x => { console.log(x); return x * x; }) Still easier to understand than the for loop.
      - bowsamic 2y ago
        Okay but now this is just imperative lol, it's no longer functional at all, since your function is now just a sequence of instructions, i.e. it's a procedure rather than a pure function. You've just proved my point
        xigoi 2y ago
        It’s a mix of functional and imperative style. Most functional languages (other than Haskell) allow you to easily write code like this.
        bowsamic 2y ago
        Yes I know but that's not the point of my original post, which is about people who claim that a pure functional style would be considered easier if it were taught first. I'm saying that falling back on imperative is almost always easier than sticking with pure functional
LtWorf 2y ago
He likes it more.
Akronymus 2y ago
Because I know what opinion I have.
demi56 2y ago
You don’t have to worry people have been saying this for more than a decade now and I see no action about it