8 ms·

'Purity' is advisable for the same reason that 'not using goto', 'hygienic macros' or 'structured programming' are highly recommended (to the point that nowaday

'Purity' is advisable for the same reason that 'not using goto', 'hygienic macros' or 'structured programming' are highly recommended (to the point that nowadays they are taught as THE way to program, and nobody would think to ignore them without a good reason). Sure you can create good programs without them, and the first developers often did; but nowadays a good programmer is expected to understand why those techniques are relevant and what kind of problems appear if you decide to ignore them on purpose. For complex modern programs, specially on the web, the 'pure functional core with iterative shell' (possibly imperative, but it can also be funcional reactive) is an increasingly common architecture that the most popular frameworks are converging to.

c_crank 3y ago
Not mentioning any of the complexity in the abstractions needed to ensure purity makes one a dishonest salesman, much like the OO consultants of the past did with Java and the Java frameworks. The ills of goto and poor scoping were solved with compiler rules and very simple expressions that could be added to any language. The alleged ills of mutation as described by academic groups made up of mathematicians whose jobs very infrequently have to do with creating actually useful software often do not match the reality of coding, nor have they ever been so bad as to demand alternative solutions. The vast majority of languages had no problem eliminating GOTO; that only a small fraction have implemented purity puts it on the same level as hardcore OO, which also is only a small fraction of the market, and about as useful.
- TuringTest 3y ago
  Claiming that functional programming is inherently more complex than imperative is also dishonest. Industry developers that criticise it without understanding the value and strengths of referential transparency are no better than your hypothetical academic groups. All abstractions introduce complexity in terms of indirection and the need to particularise to different instances. Imperative and functional simply happen to have a different approach to where they place complexity and what parts they simplify. Imperative makes it easy to update state, but then it forces you to keep in your mind every remote part of the program where your symbols may be modified (which is way harder than most developers recognize). Functional requires more work to keep track of state, but on the other hand it allows much better control of program composition and deep complex hierarchical data transformations. As they say, use the best tool for each job. It makes no sense to deride a key wrench for being more complex than a hammer and being worse at hitting nails.
  - c_crank 3y ago
    Imperative programming with state is as simple as functional programming without state. Functional programming that introduces or models state requires more abstraction, and then complexity. >Imperative makes it easy to update state, but then it forces you to keep in your mind every remote part of the program where your symbols may be modified (which is way harder than most developers recognize) Scoping inherently reduces the extent to which state is considered. Any imperative programmer worth their salt knows to minimize reliance on global variables - functional programming salesmen claiming a significant advantage by eliminating bugs involving them can't help but come off as more than a little condescending by belaboring this point. >As they say, use the best tool for each job. This is a big step down from "All programmers should know and implement purity by default because mutability is the next goto."
    - TuringTest 3y ago
      > This is a big step down from "All programmers should know and implement purity by default because mutability is the next goto." Not something I said. I explicitly mentioned the functional core, iterative shell architecture, and explained how you need to understand functional enough to know when it's a good time to not use it. At this point your posts look like someone making fun of a complex technology they do not understand, without really approaching any valid criticism of its real shortcomings, because such criticism require a thorough understanding of the thing being criticised. > Functional programming that introduces or models state requires more abstraction, and then complexity. I'm pretty sure I've said exactly that. Good thing we agree on it. But you don't seem to realize that this fact is only true for handling state, and not for other aspects of programming. > Imperative programming with state is as simple as functional programming without state. You've never tried to compose multiple asynchronous event streams of complex data types from different subsystems into one single user-facing unified presentation, have you? Your assertion is simply not true. Such feat is way simpler in functional reactive style, and a true nightmare in an imperative multithreaded program. That's why web frameworks are evolving to handle more and more reactive functional patterns for compositional asynchronous tasks.
      - 3y ago

c_crank 3y ago

Not mentioning any of the complexity in the abstractions needed to ensure purity makes one a dishonest salesman, much like the OO consultants of the past did with Java and the Java frameworks. The ills of goto and poor scoping were solved with compiler rules and very simple expressions that could be added to any language. The alleged ills of mutation as described by academic groups made up of mathematicians whose jobs very infrequently have to do with creating actually useful software often do not match the reality of coding, nor have they ever been so bad as to demand alternative solutions. The vast majority of languages had no problem eliminating GOTO; that only a small fraction have implemented purity puts it on the same level as hardcore OO, which also is only a small fraction of the market, and about as useful.

TuringTest 3y ago
Claiming that functional programming is inherently more complex than imperative is also dishonest. Industry developers that criticise it without understanding the value and strengths of referential transparency are no better than your hypothetical academic groups. All abstractions introduce complexity in terms of indirection and the need to particularise to different instances. Imperative and functional simply happen to have a different approach to where they place complexity and what parts they simplify. Imperative makes it easy to update state, but then it forces you to keep in your mind every remote part of the program where your symbols may be modified (which is way harder than most developers recognize). Functional requires more work to keep track of state, but on the other hand it allows much better control of program composition and deep complex hierarchical data transformations. As they say, use the best tool for each job. It makes no sense to deride a key wrench for being more complex than a hammer and being worse at hitting nails.
- c_crank 3y ago
  Imperative programming with state is as simple as functional programming without state. Functional programming that introduces or models state requires more abstraction, and then complexity. >Imperative makes it easy to update state, but then it forces you to keep in your mind every remote part of the program where your symbols may be modified (which is way harder than most developers recognize) Scoping inherently reduces the extent to which state is considered. Any imperative programmer worth their salt knows to minimize reliance on global variables - functional programming salesmen claiming a significant advantage by eliminating bugs involving them can't help but come off as more than a little condescending by belaboring this point. >As they say, use the best tool for each job. This is a big step down from "All programmers should know and implement purity by default because mutability is the next goto."
  - TuringTest 3y ago
    > This is a big step down from "All programmers should know and implement purity by default because mutability is the next goto." Not something I said. I explicitly mentioned the functional core, iterative shell architecture, and explained how you need to understand functional enough to know when it's a good time to not use it. At this point your posts look like someone making fun of a complex technology they do not understand, without really approaching any valid criticism of its real shortcomings, because such criticism require a thorough understanding of the thing being criticised. > Functional programming that introduces or models state requires more abstraction, and then complexity. I'm pretty sure I've said exactly that. Good thing we agree on it. But you don't seem to realize that this fact is only true for handling state, and not for other aspects of programming. > Imperative programming with state is as simple as functional programming without state. You've never tried to compose multiple asynchronous event streams of complex data types from different subsystems into one single user-facing unified presentation, have you? Your assertion is simply not true. Such feat is way simpler in functional reactive style, and a true nightmare in an imperative multithreaded program. That's why web frameworks are evolving to handle more and more reactive functional patterns for compositional asynchronous tasks.
    - 3y ago