7 ms·

> Imperative programming is like building assembly lines, which take some initial global state as raw material, apply various specific transformations, mutation

> Imperative programming is like building assembly lines, which take some initial global state as raw material, apply various specific transformations, mutations to it as this material is pushed through the line, and at the end comes off the end product, the final global state, that represents the result of the computation. This isn't the best analogy as functional and imperative languages are both often used in a procedural fashion. If I simply replaced "global state" with "immutable arguments", this analogy fits functional programming as well. The fact that the arguments would be copied, however, would be implied. > Each step needs to change, rotate, massage the workpiece precisely one specific way, so that it is prepared for subsequent steps downstream. Every step downstream depend on every previous step, and their order is therefore fixed and rigid. This is more about tight coupling than imperative vs. functional paradigms. In general, imperative methods can be just as loosely coupled as functional methods. It basically comes down to what sort of data you're handling. > Because of these dependencies, an individual computational step has not much use and meaning in itself, but only in the context of all the others, and to understand it, one must understand how the whole line works. This, again, can be true of functional languages as well. You cannot always guarantee that a method is individually useful given the data at hand.

austincheney 9y ago
There is some faulty assumption that functional programming is never imperative. Functional programming has nothing to do with declarative/imperative programming styles. The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together. If you need to compare functional programming against something contrast it against OOP, which is a different architectural approach.
- jackmott 9y ago
  >Functional programming has nothing to do with declarative/imperative programming styles. nothing!? >The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together. No idea what this means.
  - hhandoko 9y ago
    > Functional programming has nothing to do with declarative/imperative programming styles. > The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together. I think it means a code can be functional but looks imperative. One example is the for-comprehension in Scala: val aFuture = future(a) val bFuture = future(b) (for { a <- aFuture b <- bFuture c <- futureC(a, b) } yield c) This is just a contrived example for working with `Future[T]`, but it can be applied to other monadic types. For an example library that can be used with a few different styles, have a look at this: http://jsuereth.com/scala-arm/usage.html http://jsuereth.com/scala-arm/usage.html
developer2 9y ago
>> functional and imperative languages are both often used in a procedural fashion Exactly. The most common ELI5 definition of functional programming I get from other developers is that you're piping multiple statements together into a single chain of processing [input(s) > multiple levels of processing > output(s)], without having to explicitly declare variables to hold the temporary inputs and outputs between each sub-statement within the chain. I know just enough to understand that this isn't the "proper definition", but that workflow is true enough that it's what many people associate functional programming with. The problem with that particular definition is that it tries to make the primary benefit of functional languages seem to be this piping/chaining mechanism. Yet these languages are still written procedurally, executing multiple such pipes in sequence. You still have variables holding the inputs and outputs of each chain, so you can pass them to other unrelated chains. It reduces the overall number of statements and the manual variable/memory management required, but each statement is simply a compressed version of multiple statements merged into one, enforcing "fake immutable" variables for the inputs/outputs within the chain. You don't really have "immutability"; you simply have automatic variable management between sub-statements in a chain. Now, show me a functional language where the entire program is written as a single piped chain, and I would classify that as its own genre. Literally, the entire program would have to be written top-down as a single block of code that chains every single required input from the top-level, all the way down to a single output, without using a single explicitly declared variable. Only the first line of code would be unindented at the first column, with all other lines having to be indented as part of that primary block. Now that would satisfy me as being "unique" or "different than procedural". What is the primary metric of a functional language? Is it to write write golf code[1] that folds 10 "procedural statements" into a single 3-line "functional block"? To me that's not "functional programming"; that's just writing less code by chaining multiple operations into smaller blocks, reducing the complexity of having to explicitly declare more global or widely scoped variables. Random thought association: is perl's well-known Schwartzian transform (@sorted = map { ... } sort { ... } map { ... } @unsorted), applied as a concept to an entire language, what makes a "functional language"? To me, that doesn't seem like enough of a scope change to warrant a different language "type". [1] https://en.wikipedia.org/wiki/Code_golf https://en.wikipedia.org/wiki/Code_golf
- 9y ago

austincheney 9y ago

There is some faulty assumption that functional programming is never imperative. Functional programming has nothing to do with declarative/imperative programming styles. The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together. If you need to compare functional programming against something contrast it against OOP, which is a different architectural approach.

jackmott 9y ago
>Functional programming has nothing to do with declarative/imperative programming styles. nothing!? >The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together. No idea what this means.
- hhandoko 9y ago
  > Functional programming has nothing to do with declarative/imperative programming styles. > The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together. I think it means a code can be functional but looks imperative. One example is the for-comprehension in Scala: val aFuture = future(a) val bFuture = future(b) (for { a <- aFuture b <- bFuture c <- futureC(a, b) } yield c) This is just a contrived example for working with `Future[T]`, but it can be applied to other monadic types. For an example library that can be used with a few different styles, have a look at this: http://jsuereth.com/scala-arm/usage.html http://jsuereth.com/scala-arm/usage.html

developer2 9y ago

>> functional and imperative languages are both often used in a procedural fashion Exactly. The most common ELI5 definition of functional programming I get from other developers is that you're piping multiple statements together into a single chain of processing [input(s) > multiple levels of processing > output(s)], without having to explicitly declare variables to hold the temporary inputs and outputs between each sub-statement within the chain. I know just enough to understand that this isn't the "proper definition", but that workflow is true enough that it's what many people associate functional programming with. The problem with that particular definition is that it tries to make the primary benefit of functional languages seem to be this piping/chaining mechanism. Yet these languages are still written procedurally, executing multiple such pipes in sequence. You still have variables holding the inputs and outputs of each chain, so you can pass them to other unrelated chains. It reduces the overall number of statements and the manual variable/memory management required, but each statement is simply a compressed version of multiple statements merged into one, enforcing "fake immutable" variables for the inputs/outputs within the chain. You don't really have "immutability"; you simply have automatic variable management between sub-statements in a chain. Now, show me a functional language where the entire program is written as a single piped chain, and I would classify that as its own genre. Literally, the entire program would have to be written top-down as a single block of code that chains every single required input from the top-level, all the way down to a single output, without using a single explicitly declared variable. Only the first line of code would be unindented at the first column, with all other lines having to be indented as part of that primary block. Now that would satisfy me as being "unique" or "different than procedural". What is the primary metric of a functional language? Is it to write write golf code[1] that folds 10 "procedural statements" into a single 3-line "functional block"? To me that's not "functional programming"; that's just writing less code by chaining multiple operations into smaller blocks, reducing the complexity of having to explicitly declare more global or widely scoped variables. Random thought association: is perl's well-known Schwartzian transform (@sorted = map { ... } sort { ... } map { ... } @unsorted), applied as a concept to an entire language, what makes a "functional language"? To me, that doesn't seem like enough of a scope change to warrant a different language "type". [1] https://en.wikipedia.org/wiki/Code_golf https://en.wikipedia.org/wiki/Code_golf

9y ago