3 ms·

The ability to change value by ref is crucial to most real-world apps. This is not surprising, as those apps are modeled to represent a real, dynamic world. Fu

The ability to change value by ref is crucial to most real-world apps. This is not surprising, as those apps are modeled to represent a real, dynamic world. Functional languages tend to disregard this, and demand composition over mutation. While this works for some domains, it's a burdensome complication for others. Imperative languages are here to stay.

moomin 7y ago
This is rather heavily debunked already. You might want to investigate that.
- jaked89 7y ago
  You'd be more convincing providing a substantial response instead of referring me to "investigate". I've used FP extensively, and they all make mutation very hard, by design. Do you disagree with this premise? Do you disagree with my claim that the world is dynamic, and that FPs are limited in representing them? Please address my points specifically if you have anything meaningful to contribute.
  - moomin 7y ago
    I would be more convincing, but the whole point of my comment was that you need to do the work to get up to date with where the debate is. Don't ask other people to do the work for you. Anyway, FYI that's why you've been multiply downvoted. Not because there's some FP cabal who downvote pro-imperative comments.
    - jaked89 7y ago
      Didn't expect otherwise. You'd use a logical response if you had one. My comment is a direct response to the OP who implied FPs are going to "take over". I'm being downvoted probably by FP zealots who can't deal with the idea that their solutions aren't perfect or universal. BTW, I'm not "against" FP in general at all. I have used it in the past, and it has useful idioms to contribute to imperative languages, and it's perhaps useful on its own in some domains; I'm just pointing out its limitations.
willtim 7y ago
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 ;-)

moomin 7y ago

This is rather heavily debunked already. You might want to investigate that.

jaked89 7y ago
You'd be more convincing providing a substantial response instead of referring me to "investigate". I've used FP extensively, and they all make mutation very hard, by design. Do you disagree with this premise? Do you disagree with my claim that the world is dynamic, and that FPs are limited in representing them? Please address my points specifically if you have anything meaningful to contribute.
- moomin 7y ago
  I would be more convincing, but the whole point of my comment was that you need to do the work to get up to date with where the debate is. Don't ask other people to do the work for you. Anyway, FYI that's why you've been multiply downvoted. Not because there's some FP cabal who downvote pro-imperative comments.
  - jaked89 7y ago
    Didn't expect otherwise. You'd use a logical response if you had one. My comment is a direct response to the OP who implied FPs are going to "take over". I'm being downvoted probably by FP zealots who can't deal with the idea that their solutions aren't perfect or universal. BTW, I'm not "against" FP in general at all. I have used it in the past, and it has useful idioms to contribute to imperative languages, and it's perhaps useful on its own in some domains; I'm just pointing out its limitations.

willtim 7y ago

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 ;-)