4 ms·

I see this persona a lot. Functional programming just has something magical about it that really draws certain kinds of people in. I wonder if it has to do wi

I see this persona a lot. Functional programming just has something magical about it that really draws certain kinds of people in. I wonder if it has to do with the fact that, when you play inside the boundaries of what a functional programming language can do, everything feels so neat. So tidy. Like a game. Or using lego bricks. It almost feels insane to do things any other way. But then again, most problems live in the real world, where things are not neat, or tidy, or like a game. I wonder if this is why you tend not to see functional programming languages more broadly used...?

DarkNova6 2y ago
It strikes me that some people think in data, others in processes. Personally, I need transparency and understand everything step by step. But there are those that threat a function/process like a blackbox and just build pipes based on some defined axiomes. The latter also seems to do quite well in math.
- utensil4778 2y ago
  I like OOP precisely because you can just treat any object like a black box. You don't need to fully understand what the object does at all times. The way my brain works is by turning all problems into spatial problems. Programs take the form of a large graph with a function or other operation at each node. Generally, I'm modeling data flow through the graph. I can keep a fair amount of detail associated with any node, but it takes effort. There's a lot of information floating around. OOP just kind of naturally falls out of this kind of thinking. By collecting parts of the program into discrete objects that do their own thing, large parts of the graph can be collapsed into a single node. Data flows into an object, data flows out. No need to spend the mental effort of knowing what happens inside the box. I can just simply trust that I wrote an object to do what it says it does. Of course this approach often fails and I have to be much more thorough. If I can focus on a small section of the program, the graph becomes almost an arbitrary syntax tree. The past couple of weeks I've been way in the weeds with a microcontroller. At some point I've started modeling parts of the program in terms of assembly instructions and CPU implementation details.
IshKebab 2y ago
My theory is two-fold: 1. Until now most functional programming languages have had abysmal syntax. I'm sure I will get downvoted for this but have you seen Lisp? I do not want to program in raw AST. ML is also pretty bad. Honestly the hardest thing learning OCaml was figuring out where to put the brackets and semicolons. I am 100% serious. (Well, that and fighting OPAM bugs.) Rust is functional but the syntax is 10 times easier to read and write. I think other languages will follow. 2. Functional programming has been synonymous with pure functional programming due to Haskell. Honestly I didn't even realise there were impure functional languages until relatively recently. I thought to be "functional" a language had to be pure. Again Rust is functional and impure. So I think it's really that most "practical" or "engineering" languages just happened to be not functional until now because the idea of functional programming was hidden in weird and difficult to read academic languages. There's clearly nothing intrinsic to the functional paradigm that would mean it can't be used in the real world (otherwise Rust wouldn't be so popular).
- Ancapistani 2y ago
  > I'm sure I will get downvoted for this but have you seen Lisp? How much time have you spent writing in lisps? I'm definitely an OOP person, but I spent a couple of years writing Clojure. After a few hours of working in it, the syntax just... disappears. I installed two tools in vim to help: one colored parentheses to match corresponding pairs, and the other inferred parentheses from indentation. After a week, I removed the first because I realized I literally never looked at them. Ever. The reason I didn't fall in love with lisps is because it's just hard for me to work in them. Yes, I'm _very_ productive once I get into flow state - but it took about a half hour each session before I got there. There were many days where I never got into that state for more than a few minutes here and there. It was a terrible experience as a result. With Python - and other OO languages - I can look at some code and almost immediately know what it does. It's just not like that for me in lisp.
  - kazinator 2y ago
    What did you install in Vim for inferring parens from indentation? I use an adaptation of parinfer I found in github. It required a bit of tweaking , including adding a keybinding to turn it off, because sometimes it fights what you are trying to do. Its opposite mode (indentation from parens) does not work at all. > hour each session before I got there That could just be the Clojure, doing everything with immutable sequences. If the obvious way (at least to you, if not generally) to express something is OOP with mutable classes, then you have to solve a puzzle before things start to flow.
bsder 2y ago
> I wonder if this is why you tend not to see functional programming languages more broadly used...? The overarching problem is that functional programming trades extra thought now for extra benefit later. Inexperienced programmers hate functional programming because they like "magic". They are having a tough enough time just getting the task at hand finished and the more stuff done for them without thinking, the better. Inexperienced programmers don't want to think about multiple threads. They don't want to think about the event loop or sockets. They don't want to think about the state of the protocol and why it shouldn't update multiple steps. etc. The only way for that kind of magic to happen is to have a bunch of implicit state that sits invisibly in the background. It's either global or part of a single mega-struct that might as well be global. However, if an inexperienced programmer sticks around long enough they eventually run into a Heisenbug that is difficult to replicate. In order to run down the bug, they start having to isolate everything. Suddenly, the words of the old greybreard start coming back: "Immutable is good" "Time needs to be an explicit part of your state" and "bytes in, bytes out--putting the bytes on the wire is a different function" and ... At that moment, they become an acolyte of functional programming and now qualify as an experienced programmer.
- trealira 2y ago
  Not all experienced programmers become functional acolytes. See: Ken Thompson, Donald Knuth. They like procedural programming and prefer to model programs with imperative, mutable state, rather than pure functions that map one type to another.
  - desumeku 2y ago
    Neither is Richard Stallman.
    - slowmovintarget 2y ago
      Richard Stallman is known more for his clarity of thinking about individual freedom and its likely abridgements that can arise as a result of using commercial software, than his chops as a coder. I could be mistaken, though.
m463 2y ago
Personally, I think this way: problem : solution and I think sometimes certain languages fit the solution space better than others. I think it might have to do with expressiveness. If I want to write a CLI program and parse a bunch of arguments in different ways, I think python + argparse is a pretty effective way to do that. At one point, I think perl was the most generally expressive language I'd ever used. I could think of something, and then dump what was in my head into perl with little or no friction. do until! unless! (of course, the practical aspect of that was that if it is expressive that way for everyone, you will have to understand how someone else thinks to understand their perl program)

DarkNova6 2y ago

It strikes me that some people think in data, others in processes. Personally, I need transparency and understand everything step by step. But there are those that threat a function/process like a blackbox and just build pipes based on some defined axiomes. The latter also seems to do quite well in math.

utensil4778 2y ago
I like OOP precisely because you can just treat any object like a black box. You don't need to fully understand what the object does at all times. The way my brain works is by turning all problems into spatial problems. Programs take the form of a large graph with a function or other operation at each node. Generally, I'm modeling data flow through the graph. I can keep a fair amount of detail associated with any node, but it takes effort. There's a lot of information floating around. OOP just kind of naturally falls out of this kind of thinking. By collecting parts of the program into discrete objects that do their own thing, large parts of the graph can be collapsed into a single node. Data flows into an object, data flows out. No need to spend the mental effort of knowing what happens inside the box. I can just simply trust that I wrote an object to do what it says it does. Of course this approach often fails and I have to be much more thorough. If I can focus on a small section of the program, the graph becomes almost an arbitrary syntax tree. The past couple of weeks I've been way in the weeds with a microcontroller. At some point I've started modeling parts of the program in terms of assembly instructions and CPU implementation details.

IshKebab 2y ago

My theory is two-fold: 1. Until now most functional programming languages have had abysmal syntax. I'm sure I will get downvoted for this but have you seen Lisp? I do not want to program in raw AST. ML is also pretty bad. Honestly the hardest thing learning OCaml was figuring out where to put the brackets and semicolons. I am 100% serious. (Well, that and fighting OPAM bugs.) Rust is functional but the syntax is 10 times easier to read and write. I think other languages will follow. 2. Functional programming has been synonymous with pure functional programming due to Haskell. Honestly I didn't even realise there were impure functional languages until relatively recently. I thought to be "functional" a language had to be pure. Again Rust is functional and impure. So I think it's really that most "practical" or "engineering" languages just happened to be not functional until now because the idea of functional programming was hidden in weird and difficult to read academic languages. There's clearly nothing intrinsic to the functional paradigm that would mean it can't be used in the real world (otherwise Rust wouldn't be so popular).

Ancapistani 2y ago
> I'm sure I will get downvoted for this but have you seen Lisp? How much time have you spent writing in lisps? I'm definitely an OOP person, but I spent a couple of years writing Clojure. After a few hours of working in it, the syntax just... disappears. I installed two tools in vim to help: one colored parentheses to match corresponding pairs, and the other inferred parentheses from indentation. After a week, I removed the first because I realized I literally never looked at them. Ever. The reason I didn't fall in love with lisps is because it's just hard for me to work in them. Yes, I'm _very_ productive once I get into flow state - but it took about a half hour each session before I got there. There were many days where I never got into that state for more than a few minutes here and there. It was a terrible experience as a result. With Python - and other OO languages - I can look at some code and almost immediately know what it does. It's just not like that for me in lisp.
- kazinator 2y ago
  What did you install in Vim for inferring parens from indentation? I use an adaptation of parinfer I found in github. It required a bit of tweaking , including adding a keybinding to turn it off, because sometimes it fights what you are trying to do. Its opposite mode (indentation from parens) does not work at all. > hour each session before I got there That could just be the Clojure, doing everything with immutable sequences. If the obvious way (at least to you, if not generally) to express something is OOP with mutable classes, then you have to solve a puzzle before things start to flow.

bsder 2y ago

> I wonder if this is why you tend not to see functional programming languages more broadly used...? The overarching problem is that functional programming trades extra thought now for extra benefit later. Inexperienced programmers hate functional programming because they like "magic". They are having a tough enough time just getting the task at hand finished and the more stuff done for them without thinking, the better. Inexperienced programmers don't want to think about multiple threads. They don't want to think about the event loop or sockets. They don't want to think about the state of the protocol and why it shouldn't update multiple steps. etc. The only way for that kind of magic to happen is to have a bunch of implicit state that sits invisibly in the background. It's either global or part of a single mega-struct that might as well be global. However, if an inexperienced programmer sticks around long enough they eventually run into a Heisenbug that is difficult to replicate. In order to run down the bug, they start having to isolate everything. Suddenly, the words of the old greybreard start coming back: "Immutable is good" "Time needs to be an explicit part of your state" and "bytes in, bytes out--putting the bytes on the wire is a different function" and ... At that moment, they become an acolyte of functional programming and now qualify as an experienced programmer.

trealira 2y ago
Not all experienced programmers become functional acolytes. See: Ken Thompson, Donald Knuth. They like procedural programming and prefer to model programs with imperative, mutable state, rather than pure functions that map one type to another.
- desumeku 2y ago
  Neither is Richard Stallman.
  - slowmovintarget 2y ago
    Richard Stallman is known more for his clarity of thinking about individual freedom and its likely abridgements that can arise as a result of using commercial software, than his chops as a coder. I could be mistaken, though.

m463 2y ago

Personally, I think this way: problem : solution and I think sometimes certain languages fit the solution space better than others. I think it might have to do with expressiveness. If I want to write a CLI program and parse a bunch of arguments in different ways, I think python + argparse is a pretty effective way to do that. At one point, I think perl was the most generally expressive language I'd ever used. I could think of something, and then dump what was in my head into perl with little or no friction. do until! unless! (of course, the practical aspect of that was that if it is expressive that way for everyone, you will have to understand how someone else thinks to understand their perl program)