4 ms·

> Concepts that have a strong theory behind them tend to last longer. The programming paradigms (functional, imperative, declarative) as implemented generally

by roenxi 1y ago

> Concepts that have a strong theory behind them tend to last longer. The programming paradigms (functional, imperative, declarative) as implemented generally don't have strong theories behind them. We have no sharp line to detect when a language sits in any of those categories for any major language apart from SQL. One can write something that is recognised as functional in an imperative language for example. And even the best example of purity, SQL, in practice needs to be hosted in an imperative or functional environment to get useful results. The declarative part of the language isn't competent at getting complex performance-friendly results. One of the interesting things about being a member of the functional programming community is I genuinely can't tell what the claim to fame of the community actually is beyond a sort of club-like atmosphere where people don't like mutability. Are we claiming that C++ programmers don't know how to write pure functions? I hope not, they clearly know. Many are good at it.

ux266478 1y ago
I see this misconception a lot. Functional programming has nothing to do with mutability or immutability. Just like product types (or associative arrays) don't make for object oriented programming, the paradigm is about the patterns you use and the total structure of the program. In the case of functional programming, it's that your entire program is built around function composition and folds. This changes how you build your program on a fundamental level. Additionally, functional programming does have a strong theory behind it. That of the lambda calculus. Everything is formalization and constructions built on top of that. We don't have a "hard line" to detect if a language is "functional" because it's not a language paradigm, but a property of the code itself. Grammar is orthogonal to this stuff. You can, however, make a pretty good guess by looking at the standard library of a language. There is no ambiguity that Idris or Haskell are a languages designed for functional programming, for example. I think this stems from a problem that there are a lot of programmers, who through no fault of their own, have engaged with tools for functional programming, but skipped building things using the alien and weird stuff so in the end there's no actual learning of functional programming itself. Every new programming paradigm is a shift of your core perspective, they require you to relearn programming from the ground up. It shouldn't feel like "this is just ABC with XYZ", you are only truly beginning to learn when you are put back into your shoes as a middle schooler unlocking the power of nested conditionals. If you don't get that feeling, you're just learning a different language and not a programming paradigm. > And even the best example of purity, SQL Purity is not a claim of functional programming. Also SQL is not anywhere close to being a functional language, it's not only a non-programming language, but even if it were (and it can be with extensions) its paradigm is far more in line with logic programming.
- motorest 1y ago
  > This changes how you build your program on a fundamental level. I think this manifestation of cargo cult mentality should be put to rest. For each paradigm we heard the same story, but we still see programs in ${LANGUAGE_A} not even following idiomatic styles and looking instead like programs transcoded from ${LANGUAGE_B}. You do not change the way you build programs by rewriting projects in a specific language or even style. You just get the same people implementing the same programs according to the same mental model. The key factor is experience and familiarity, and you don't build any of that by marketing a particular programming style. Moreso when which framework of library was adopted by a project. The hard truth is that experience and familiarity derive from problems a developer faced and the solutions that worked, and quite bluntly after all these decades functional programming isn't living up to the hype created by it's fans. It's the curse of LISP all over again.
  - ux266478 1y ago
    I'm not sure that your objection puts anything to rest, least of all a "cargo cult mentality". You re-assert exactly what I say just to disagree and miss the rest of the post. Codebases which are not written in a functional style are not functional programming, no matter the language being used. The overwhelming majority of programmers did not learn to program in a functional style, and without the long haul learning process of thinking about program construction in terms of function composition and application, they will program according to whatever they've always used. They can't program or use a mental framework that they don't know. Languages are languages. The syntax and grammar of a language has (virtually) no effect on a programming paradigm. There's nothing in the grammar stopping you from using Haskell as an imperative language. That's a knock-on effect of being a turing complete grammar, no more, no less. Given these facts which are absolutely not up for debate, some statistical sample of codebases which are just some unstructured hodge-podge mudball in any given language isn't particularly meaningful. Somebody who spent 2 weeks reading Haskell tutorials in their off-time isn't going to be writing functional programs in Haskell. Hell, somebody who has been writing mudball Haskell programs for years isn't going to be writing functional programs. > and quite bluntly after all these decades functional programming isn't living up to the hype created by it's fans Perhaps your problem is that you are looking through such a lens that "hype" even registers on your radar. And that's why I'm sure you can't name a single weakpoint of functional programming off the top of your head besides the ever popular, ever erroneous complaint about "performance" by people who think functional programming is immutability, purity and function pointers. If all you care about is the social baggage with a working discipline and its tools, how can you possibly have anything but the most trivial, surface-level and, to put it bluntly, ignorant view of things? There is no substance to that nonsense, don't kid yourself. Until you change that you will never receive any signal, just noise. The heterogeneity of programming as a discipline will continue to frustrate you to no end. "All over again" Lisp is a tool explicitly designed for functional programming ;-)

by roenxi 1y ago

ux266478 1y ago

I see this misconception a lot. Functional programming has nothing to do with mutability or immutability. Just like product types (or associative arrays) don't make for object oriented programming, the paradigm is about the patterns you use and the total structure of the program. In the case of functional programming, it's that your entire program is built around function composition and folds. This changes how you build your program on a fundamental level. Additionally, functional programming does have a strong theory behind it. That of the lambda calculus. Everything is formalization and constructions built on top of that. We don't have a "hard line" to detect if a language is "functional" because it's not a language paradigm, but a property of the code itself. Grammar is orthogonal to this stuff. You can, however, make a pretty good guess by looking at the standard library of a language. There is no ambiguity that Idris or Haskell are a languages designed for functional programming, for example. I think this stems from a problem that there are a lot of programmers, who through no fault of their own, have engaged with tools for functional programming, but skipped building things using the alien and weird stuff so in the end there's no actual learning of functional programming itself. Every new programming paradigm is a shift of your core perspective, they require you to relearn programming from the ground up. It shouldn't feel like "this is just ABC with XYZ", you are only truly beginning to learn when you are put back into your shoes as a middle schooler unlocking the power of nested conditionals. If you don't get that feeling, you're just learning a different language and not a programming paradigm. > And even the best example of purity, SQL Purity is not a claim of functional programming. Also SQL is not anywhere close to being a functional language, it's not only a non-programming language, but even if it were (and it can be with extensions) its paradigm is far more in line with logic programming.

motorest 1y ago
> This changes how you build your program on a fundamental level. I think this manifestation of cargo cult mentality should be put to rest. For each paradigm we heard the same story, but we still see programs in ${LANGUAGE_A} not even following idiomatic styles and looking instead like programs transcoded from ${LANGUAGE_B}. You do not change the way you build programs by rewriting projects in a specific language or even style. You just get the same people implementing the same programs according to the same mental model. The key factor is experience and familiarity, and you don't build any of that by marketing a particular programming style. Moreso when which framework of library was adopted by a project. The hard truth is that experience and familiarity derive from problems a developer faced and the solutions that worked, and quite bluntly after all these decades functional programming isn't living up to the hype created by it's fans. It's the curse of LISP all over again.
- ux266478 1y ago
  I'm not sure that your objection puts anything to rest, least of all a "cargo cult mentality". You re-assert exactly what I say just to disagree and miss the rest of the post. Codebases which are not written in a functional style are not functional programming, no matter the language being used. The overwhelming majority of programmers did not learn to program in a functional style, and without the long haul learning process of thinking about program construction in terms of function composition and application, they will program according to whatever they've always used. They can't program or use a mental framework that they don't know. Languages are languages. The syntax and grammar of a language has (virtually) no effect on a programming paradigm. There's nothing in the grammar stopping you from using Haskell as an imperative language. That's a knock-on effect of being a turing complete grammar, no more, no less. Given these facts which are absolutely not up for debate, some statistical sample of codebases which are just some unstructured hodge-podge mudball in any given language isn't particularly meaningful. Somebody who spent 2 weeks reading Haskell tutorials in their off-time isn't going to be writing functional programs in Haskell. Hell, somebody who has been writing mudball Haskell programs for years isn't going to be writing functional programs. > and quite bluntly after all these decades functional programming isn't living up to the hype created by it's fans Perhaps your problem is that you are looking through such a lens that "hype" even registers on your radar. And that's why I'm sure you can't name a single weakpoint of functional programming off the top of your head besides the ever popular, ever erroneous complaint about "performance" by people who think functional programming is immutability, purity and function pointers. If all you care about is the social baggage with a working discipline and its tools, how can you possibly have anything but the most trivial, surface-level and, to put it bluntly, ignorant view of things? There is no substance to that nonsense, don't kid yourself. Until you change that you will never receive any signal, just noise. The heterogeneity of programming as a discipline will continue to frustrate you to no end. "All over again" Lisp is a tool explicitly designed for functional programming ;-)