5 ms·

All the more reason to explicitly model time and not conflate it with the system runtime. As an example, banks have always added entries to a ledger such that t

All the more reason to explicitly model time and not conflate it with the system runtime. As an example, banks have always added entries to a ledger such that the time history of events is explicit and preserved. Functional programming models this very well. An imperative programmer would probably write the final balance on a post-it note in pencil so that it could be destructively updated. Some OOP programmers have actually tried to model banking like this, because their language encourages it. Another example might be a text editor buffer. Immutable persistent data structures allow one to get many features for free such as versioning, undo, lockless autosave. Memory is cheap now, there's less of a need to throw away some my edits with destructive updates. Even filesystems and databases have realised this is good idea. Destructive updates are bad for valuable data. Imperative programming is only better for writing low-level system code, which is full of state that ultimately no one in the real world cares about.

apalmer 7y ago
Your points are not 'wrong' but I think you are being overly broad in the conclusion you are drawing. Imperative programming is the dominant programming model that 99.99% of all real world code for the last 60 years has been programmed in. It very well may be due to be replaced, but certainly cant just be hand-waved away
- willtim 7y ago
  50 years ago 99.9% of computer programs were written in completely imperative assembly language programs, such that even arithmetic involved statements and temporary mutable variables. Fortran was a more mathematical higher-level language with boolean and arithmetic expressions. Functional programming just continues this trend, resulting in more mathematical, higher-level declarative languages, which as far as I am concerned, makes them more suitable for modelling real world business problems.
  - fiveminds 7y ago
    Turing has destroy everything what Alonzo Church did ;-)
jaked89 7y ago
FP didn't invent immutable data, or mathematical functions. It just makes it easier to use them for some domains, while complicating others. Imperative programs can have isolated, pure subsections of functionality which are based on composition and immutability, without having to deal with the "ideological" strictness of FP. You're considering only a minute aspect of large systems. Any real banking system has much more than a ledger to deal with. And most of it involves huge amounts of state, which you can't just pile on top of RAM, or waste CPU on. Anything that doesn't serve a real business/user purpose is just waste. And text editors don't need FP to support undo either. I'm not sure what point are you trying to make. The most successful editors in the market, supporting all the features you mentioned, do quite fine with imperative, and in fact, I'm not aware of any meaningful editor written in a FL. > Memory is cheap now Not really. This comment strikes me as if it comes from someone who never dealt with significant amount of data. FP can be extremely wasteful; take head-tail lists for example, which are the default container in many FPs. They waste object-container data, pointer data, and scatter the list items, causing cpu cache misses. Claiming that imperative is only better for low-level is extremely disconnected from reality. Try writing a game with FP, and I assure you no one will care for code "beauty" when FPS sucks. Sometimes, arguing with FP purists feels like debating socialists. Also: go ahead and downvote me, as apparently FP zealots can't tolerate questioning their religion.
- willtim 7y ago
  > Imperative programs can have isolated, pure subsections of functionality which are based on composition and immutability. And functional programming languages can support imperative programming and mutation, even Haskell. It's a question of what should be the default, which depends on the domain you are working in. > Any real banking system has much more than a ledger to deal with. Most banking systems are cobbled together from third-party components and libraries. Low-level languages aren't really needed. Many banks use Python, which is orders of magnitude slower than Haskell. > This comment strikes me as if it comes from someone who never dealt with significant amount of data. Actually I have a background in distributed computing, where functional programming abstractions have made processing large amounts of data much easier (MapReduce, Spark). > FP can be extremely wasteful; take head-tail lists for example, which are the default container in many FPs. This is a strawman. I can write inefficient code in any language. C++ code can be littered with pointer indirection and memory barriers. > Sometimes, arguing with FP purists feels like debating socialists. I am a socialist.

apalmer 7y ago

Your points are not 'wrong' but I think you are being overly broad in the conclusion you are drawing. Imperative programming is the dominant programming model that 99.99% of all real world code for the last 60 years has been programmed in. It very well may be due to be replaced, but certainly cant just be hand-waved away

willtim 7y ago
50 years ago 99.9% of computer programs were written in completely imperative assembly language programs, such that even arithmetic involved statements and temporary mutable variables. Fortran was a more mathematical higher-level language with boolean and arithmetic expressions. Functional programming just continues this trend, resulting in more mathematical, higher-level declarative languages, which as far as I am concerned, makes them more suitable for modelling real world business problems.
- fiveminds 7y ago
  Turing has destroy everything what Alonzo Church did ;-)

jaked89 7y ago

FP didn't invent immutable data, or mathematical functions. It just makes it easier to use them for some domains, while complicating others. Imperative programs can have isolated, pure subsections of functionality which are based on composition and immutability, without having to deal with the "ideological" strictness of FP. You're considering only a minute aspect of large systems. Any real banking system has much more than a ledger to deal with. And most of it involves huge amounts of state, which you can't just pile on top of RAM, or waste CPU on. Anything that doesn't serve a real business/user purpose is just waste. And text editors don't need FP to support undo either. I'm not sure what point are you trying to make. The most successful editors in the market, supporting all the features you mentioned, do quite fine with imperative, and in fact, I'm not aware of any meaningful editor written in a FL. > Memory is cheap now Not really. This comment strikes me as if it comes from someone who never dealt with significant amount of data. FP can be extremely wasteful; take head-tail lists for example, which are the default container in many FPs. They waste object-container data, pointer data, and scatter the list items, causing cpu cache misses. Claiming that imperative is only better for low-level is extremely disconnected from reality. Try writing a game with FP, and I assure you no one will care for code "beauty" when FPS sucks. Sometimes, arguing with FP purists feels like debating socialists. Also: go ahead and downvote me, as apparently FP zealots can't tolerate questioning their religion.

willtim 7y ago
> Imperative programs can have isolated, pure subsections of functionality which are based on composition and immutability. And functional programming languages can support imperative programming and mutation, even Haskell. It's a question of what should be the default, which depends on the domain you are working in. > Any real banking system has much more than a ledger to deal with. Most banking systems are cobbled together from third-party components and libraries. Low-level languages aren't really needed. Many banks use Python, which is orders of magnitude slower than Haskell. > This comment strikes me as if it comes from someone who never dealt with significant amount of data. Actually I have a background in distributed computing, where functional programming abstractions have made processing large amounts of data much easier (MapReduce, Spark). > FP can be extremely wasteful; take head-tail lists for example, which are the default container in many FPs. This is a strawman. I can write inefficient code in any language. C++ code can be littered with pointer indirection and memory barriers. > Sometimes, arguing with FP purists feels like debating socialists. I am a socialist.