5 ms·

I think in the end step by step functional programming will be widely adopted. Concepts that have a strong theory behind them tend to last longer. Similar to ho

I think in the end step by step functional programming will be widely adopted. Concepts that have a strong theory behind them tend to last longer. Similar to how relational databases and SQL are still the gold standard today.

deleted 1y ago
[deleted]
cubefox 1y ago
That seems improbable. Pure functional languages are very unpopular according to TIOBE. In particular, interest in Haskell seems to be in decline. Functional features are mostly just an add-on to programming languages with mutable state. By far the most popular language, Python, doesn't even have static typing.
- bheadmaster 1y ago
  > By far the most popular language, Python, doesn't even have static typing. Arguably, Python is statically typed - it's just that it only has one type: object.
  - wk_end 1y ago
    I know Robert Harper has advanced that argument, but I think it's only really interesting for striking a single rhetorical blow: that, uh, actually statically typed languages are trivially more expressive than Python, since Python has one static type and they have as many as you want. But I think as an actual ontology, as an actual way of understanding and structuring the world, it's obviously quite silly. There's no compile-time (static) type checking phase in Python, because it'd be trivial and therefore a waste of time. Without static type checking, what does it mean to say it's "statically" typed? Moreover, the language has an entirely different, extraordinarily related concept of type which is checked dynamically. Yes, you can say that "Python is a statically typed language with only a single meaningless static type and but also dynamically checked dynamic types", but frankly that's not telling you anything that calling it a dynamically typed language isn't. From a different angle, you can't program SML or something "monotypically" - just restricting yourself to one type - without effectively building an interpreter for an entirely separate, dynamic language inside of it (you can of course build a statically typed language inside of Python, so if you think that counts you're just stripping the meaning from comparing languages). In that sense, Python's just plain doing something fundamentally different from what "a static language with one type" is.
    - zozbot234 1y ago
      These so-called dynamic types are merely the equivalent of tags in a discriminated union/variant type. Statically-typed languages can easily do the same thing: the argument that this amounts to "building an interpreter" applies to any language implementation.
      - remexre 1y ago
        > These so-called dynamic types are merely the equivalent of tags in a discriminated union/variant type. That's far more true in a language like JavaScript or Scheme than in an "everything is an object" language like Python; the only reason why you would need a variant type for PyObject is to avoid the circular data structures the actual implementation uses. If you allow the circular data structures, your dynamic types instead are "merely" a relatively complicated codata type, but it's far less obvious that this is actually what anyone considers to be "merely."
- ahf8Aithaex7Nai 1y ago
  That's already been happening for quite some time. Mainstream programming has done little else in recent years than converge toward functional programming. Also, they wrote "functional," not "purely functional." By the way, from a formal perspective, imperative programming is an extension of purely functional programming.
  - rauljara 1y ago
    This is true, in that most of the scholarship builds up its proofs starting with the lambda calculus. But there are so many paradigms (Turing machines, SKI combinators, excel spreadsheets) that are equivalent that I’m not at all convinced they had to start with lambda calculus. They just happened to. Out in the real world, the thing that all programming languages are actually built on top of looks much more like a Turing machine than a collection of composed anonymous functions. But of course if you want to make your programs go really fast, you can’t treat them like Turing machines either. You need to acknowledge that all of this theory goes out the window in the face of how important optimizing around memory access is. Which isn’t to say one perspective is right and one is wrong. These perspective all exist and have spread because they can all be useful. But acting like one of them is “reality” isn’t all that helpful. Ps. Not that the parent actually said the formal perspective was reality. I just wanted to articulate this thought I had bouncing around in my head for a while.
    - zozbot234 1y ago
      > Out in the real world, the thing that all programming languages are actually built on top of looks much more like a Turing machine than a collection of composed anonymous functions. Hardware logic as described in a HDL language is precisely a collection of "composed anonymous functions", including higher-order functions which are encoded as "instructions" or "control signals". We even build stateful logic from the ground up by tying these functions together in a "knot", with the statefulness being the outcome of feedback.
      - jove_ 1y ago
        But it's hard to argue the machine at the end is stateless. We can endlessly do this. You can construct lambda calculus with Turing machines and Turing machines in lambda calculus. There seems to be this weird idea in the functional community that the existence of some construction of one thing in another shows that one of those things is "more fundamental" than the other, when in reality this is often a circular exercise. e.g. Functions can be formalized as sets and sets can be formalized as functions. Even worse in this specific case, the Church-Turing thesis tells us that they're equivalent, which is the only sensible answer to the question of which is more fundamental. There's an oft quoted phrase of "deep and abiding equivalencies" and it bears pointing out how deep and abiding these equivalencies are. From a formal perspective they are the same. Yes, there's arguments could be made that typed lambda calculus and its relation to logic are important, and that's true but it's not a formal argument at all and I think it's best to be clear on that.
- Fraterkes 1y ago
  I know powerful typing features are very important for Haskell in particular, but is static typing considered a functional feature more broadly? Most lisps don't have static typing as far as I know. Clojure was one of the main functional languages that actually saw industry use for a while, and it is dynamically typed.
  - JacobGoodson 1y ago
    "but is static typing considered a functional feature more broadly" It might be, but it is not an essential feature. Functional programming is the practice of using pure functions as the primary form of computation and composition. Whether one adds types to this is as relevant as adding types to any other paradigm (imperative, oop, logical, functional, etc)
    - Fraterkes 1y ago
      Right, that was my assumption. I asked because the person I replied to mentioned the popularity of dynamic languages as a data-point for the decline in popularity of functional programming.
      - JacobGoodson 1y ago
        To drive the point a little further, all of those paradigms encompass both statically typed languages and dynamically typed ones.
  - marcosdumay 1y ago
    It seems to me that algebraic nominal types are getting strongly attached to functional programming right now. Even on multi-paradigm languages, both idioms tend to come together. It's not a necessary relation, those things are pretty much independent. Except in that pattern matching and function composition complement each other very well.
- HelloNurse 1y ago
  Haskell is suitable for, and designed for, bleeding edge experiments, not for practical usage. Its low popularity says very little about the "market penetration" of better engineered functional languages.
  - cubefox 1y ago
    There is no other popular functional language either. Except if you count imperative languages which let you, optionally, write functional code, except that in practice most code is imperative.
  - instig007 1y ago
    > Haskell is suitable for, and designed for, bleeding edge experiments, not for practical usage The notion of practicality depends on what one wishes to practice. You, for instance, are practicing FUD spreading, it's practical for you to say these things without actually doing work with the tools provided.
    - HelloNurse 1y ago
      I tried to learn Haskell, and while the language has merits every library I attempted to use was a problem: at best not documented enough, but more often a half-baked proof of concept.
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.
implicit 1y ago
I agree. It's happening. Lambdas are now a requirement for any modern programming language. Monadic promises are how asynchronous programming is done. Rust is basically OCaml except with typeclasses and without a GC. Inch by inch, ideas from FP bubble up into mainstream programming. I predict that algebraic effects (a la Koka) are next, but it'll be a while before the industry is ready for it.
- layer8 1y ago
  To play the devil's advocate: From an OOP perspective, lambdas are just syntactic sugar for a special form of objects. Regarding monads, we had smart pointers and the like in C++ already in the 1990s. Both concepts are orthogonal to mutability. I'm convinced that imperative programming will endure alongside functional code, because being stateful is how the real world works, and most programs have to repeatedly interact with the real world over the course of their execution.
  - implicit 1y ago
    Sure. I don't mean to say that imperative programming is going anywhere. If you're looking for programming languages with no support for imperative programming, Excel is pretty much it. Even Haskell has robust support for sequencing actions. If it didn't, I don't think we'd be talking about it at all. What I predict is that ideas from FP will continue to bubble up into the mainstream. Like prior inventions, they won't be presented as a thing that asks you to rework all of your algorithmic code. They will instead be polished and presented in a way that makes them work more as extensions to what you can already do. If you squint a little bit, Haskell's do-notation is already available in mainstream languages in the form of async/await syntax. async/await is not quite as general as the original Haskell solution, but it also doesn't ask you to completely rethink the way you design algorithms.
    - layer8 1y ago
      Well, once it quacks like an imperative duck, what’s really the difference?
motorest 1y ago
> Similar to how relational databases and SQL are still the gold standard today. ...except they aren't. The world is gradually slipping towards nosql databases and stepping away from normalized data stores, to the point where tried and true RDBMS are shoehorning support for storing and querying JSON documents. All flagship database services from major cloud providers are nosql databases. Perhaps you're confusing pervasiveness with representing gold standard. Yes, RDBMS are pervasive, but so are non-compliance with the standard and vendor-specific constructs. The biggest factor was not what was the theoretical background behind each implementation but ease of use and ease of adoption. SQLite is an outstanding database not because of its compliance with SQL standards and adherence to theoretical purity, but because it's FLOSS and trivial to setup and use. I expect the same factors to be relevant in adoption of functional programming. This stuff exists for decades on end but mass adoption was between negligible to irrelevant. What started to drive adoption was the inception of modules and components that solved real-world problems and helped developers do what they wanted to do with less effort. In JavaScript the use of map, filter and reduce is not driven by any new-founded passion for function programming but because it's right there and it's concise and simple and readable and capable. In C#, linq is gaining traction for the same reasons but is largely kept back by performance issues. The key aspect is pragmatism, and theoretical elegance is by far a mere nice-to-have.
- jghn 1y ago
  > The world is gradually slipping towards nosql databases My observation has been that this pendulum is swinging back the other direction. You're correct that some NoSQL-isms found their way into RDBMS, but at least in the circles in which I travel, people are by and large heading back to RDBMS stores.
- efitz 1y ago
  > ..except they aren't. The world is gradually slipping towards nosql databases and stepping away from normalized data stores The 2010s called and want their database paradigm back. NoSQL is definitely not the zeitgeist today. Graph DBs, KV stores, document DBs, and OLTP DBs are what is popular today- I would say that the two shifts I see in the 2020s is the rise of cache-as-database (eg redis) and an “all of the above” mentality rather than one-size-fits-all.

deleted 1y ago

[deleted]

cubefox 1y ago

That seems improbable. Pure functional languages are very unpopular according to TIOBE. In particular, interest in Haskell seems to be in decline. Functional features are mostly just an add-on to programming languages with mutable state. By far the most popular language, Python, doesn't even have static typing.

bheadmaster 1y ago
> By far the most popular language, Python, doesn't even have static typing. Arguably, Python is statically typed - it's just that it only has one type: object.
- wk_end 1y ago
  I know Robert Harper has advanced that argument, but I think it's only really interesting for striking a single rhetorical blow: that, uh, actually statically typed languages are trivially more expressive than Python, since Python has one static type and they have as many as you want. But I think as an actual ontology, as an actual way of understanding and structuring the world, it's obviously quite silly. There's no compile-time (static) type checking phase in Python, because it'd be trivial and therefore a waste of time. Without static type checking, what does it mean to say it's "statically" typed? Moreover, the language has an entirely different, extraordinarily related concept of type which is checked dynamically. Yes, you can say that "Python is a statically typed language with only a single meaningless static type and but also dynamically checked dynamic types", but frankly that's not telling you anything that calling it a dynamically typed language isn't. From a different angle, you can't program SML or something "monotypically" - just restricting yourself to one type - without effectively building an interpreter for an entirely separate, dynamic language inside of it (you can of course build a statically typed language inside of Python, so if you think that counts you're just stripping the meaning from comparing languages). In that sense, Python's just plain doing something fundamentally different from what "a static language with one type" is.
  - zozbot234 1y ago
    These so-called dynamic types are merely the equivalent of tags in a discriminated union/variant type. Statically-typed languages can easily do the same thing: the argument that this amounts to "building an interpreter" applies to any language implementation.
    - remexre 1y ago
      > These so-called dynamic types are merely the equivalent of tags in a discriminated union/variant type. That's far more true in a language like JavaScript or Scheme than in an "everything is an object" language like Python; the only reason why you would need a variant type for PyObject is to avoid the circular data structures the actual implementation uses. If you allow the circular data structures, your dynamic types instead are "merely" a relatively complicated codata type, but it's far less obvious that this is actually what anyone considers to be "merely."
ahf8Aithaex7Nai 1y ago
That's already been happening for quite some time. Mainstream programming has done little else in recent years than converge toward functional programming. Also, they wrote "functional," not "purely functional." By the way, from a formal perspective, imperative programming is an extension of purely functional programming.
- rauljara 1y ago
  This is true, in that most of the scholarship builds up its proofs starting with the lambda calculus. But there are so many paradigms (Turing machines, SKI combinators, excel spreadsheets) that are equivalent that I’m not at all convinced they had to start with lambda calculus. They just happened to. Out in the real world, the thing that all programming languages are actually built on top of looks much more like a Turing machine than a collection of composed anonymous functions. But of course if you want to make your programs go really fast, you can’t treat them like Turing machines either. You need to acknowledge that all of this theory goes out the window in the face of how important optimizing around memory access is. Which isn’t to say one perspective is right and one is wrong. These perspective all exist and have spread because they can all be useful. But acting like one of them is “reality” isn’t all that helpful. Ps. Not that the parent actually said the formal perspective was reality. I just wanted to articulate this thought I had bouncing around in my head for a while.
  - zozbot234 1y ago
    > Out in the real world, the thing that all programming languages are actually built on top of looks much more like a Turing machine than a collection of composed anonymous functions. Hardware logic as described in a HDL language is precisely a collection of "composed anonymous functions", including higher-order functions which are encoded as "instructions" or "control signals". We even build stateful logic from the ground up by tying these functions together in a "knot", with the statefulness being the outcome of feedback.
    - jove_ 1y ago
      But it's hard to argue the machine at the end is stateless. We can endlessly do this. You can construct lambda calculus with Turing machines and Turing machines in lambda calculus. There seems to be this weird idea in the functional community that the existence of some construction of one thing in another shows that one of those things is "more fundamental" than the other, when in reality this is often a circular exercise. e.g. Functions can be formalized as sets and sets can be formalized as functions. Even worse in this specific case, the Church-Turing thesis tells us that they're equivalent, which is the only sensible answer to the question of which is more fundamental. There's an oft quoted phrase of "deep and abiding equivalencies" and it bears pointing out how deep and abiding these equivalencies are. From a formal perspective they are the same. Yes, there's arguments could be made that typed lambda calculus and its relation to logic are important, and that's true but it's not a formal argument at all and I think it's best to be clear on that.
Fraterkes 1y ago
I know powerful typing features are very important for Haskell in particular, but is static typing considered a functional feature more broadly? Most lisps don't have static typing as far as I know. Clojure was one of the main functional languages that actually saw industry use for a while, and it is dynamically typed.
- JacobGoodson 1y ago
  "but is static typing considered a functional feature more broadly" It might be, but it is not an essential feature. Functional programming is the practice of using pure functions as the primary form of computation and composition. Whether one adds types to this is as relevant as adding types to any other paradigm (imperative, oop, logical, functional, etc)
  - Fraterkes 1y ago
    Right, that was my assumption. I asked because the person I replied to mentioned the popularity of dynamic languages as a data-point for the decline in popularity of functional programming.
    - JacobGoodson 1y ago
      To drive the point a little further, all of those paradigms encompass both statically typed languages and dynamically typed ones.
- marcosdumay 1y ago
  It seems to me that algebraic nominal types are getting strongly attached to functional programming right now. Even on multi-paradigm languages, both idioms tend to come together. It's not a necessary relation, those things are pretty much independent. Except in that pattern matching and function composition complement each other very well.
HelloNurse 1y ago
Haskell is suitable for, and designed for, bleeding edge experiments, not for practical usage. Its low popularity says very little about the "market penetration" of better engineered functional languages.
- cubefox 1y ago
  There is no other popular functional language either. Except if you count imperative languages which let you, optionally, write functional code, except that in practice most code is imperative.
- instig007 1y ago
  > Haskell is suitable for, and designed for, bleeding edge experiments, not for practical usage The notion of practicality depends on what one wishes to practice. You, for instance, are practicing FUD spreading, it's practical for you to say these things without actually doing work with the tools provided.
  - HelloNurse 1y ago
    I tried to learn Haskell, and while the language has merits every library I attempted to use was a problem: at best not documented enough, but more often a half-baked proof of concept.

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.

implicit 1y ago

I agree. It's happening. Lambdas are now a requirement for any modern programming language. Monadic promises are how asynchronous programming is done. Rust is basically OCaml except with typeclasses and without a GC. Inch by inch, ideas from FP bubble up into mainstream programming. I predict that algebraic effects (a la Koka) are next, but it'll be a while before the industry is ready for it.

layer8 1y ago
To play the devil's advocate: From an OOP perspective, lambdas are just syntactic sugar for a special form of objects. Regarding monads, we had smart pointers and the like in C++ already in the 1990s. Both concepts are orthogonal to mutability. I'm convinced that imperative programming will endure alongside functional code, because being stateful is how the real world works, and most programs have to repeatedly interact with the real world over the course of their execution.
- implicit 1y ago
  Sure. I don't mean to say that imperative programming is going anywhere. If you're looking for programming languages with no support for imperative programming, Excel is pretty much it. Even Haskell has robust support for sequencing actions. If it didn't, I don't think we'd be talking about it at all. What I predict is that ideas from FP will continue to bubble up into the mainstream. Like prior inventions, they won't be presented as a thing that asks you to rework all of your algorithmic code. They will instead be polished and presented in a way that makes them work more as extensions to what you can already do. If you squint a little bit, Haskell's do-notation is already available in mainstream languages in the form of async/await syntax. async/await is not quite as general as the original Haskell solution, but it also doesn't ask you to completely rethink the way you design algorithms.
  - layer8 1y ago
    Well, once it quacks like an imperative duck, what’s really the difference?

motorest 1y ago

> Similar to how relational databases and SQL are still the gold standard today. ...except they aren't. The world is gradually slipping towards nosql databases and stepping away from normalized data stores, to the point where tried and true RDBMS are shoehorning support for storing and querying JSON documents. All flagship database services from major cloud providers are nosql databases. Perhaps you're confusing pervasiveness with representing gold standard. Yes, RDBMS are pervasive, but so are non-compliance with the standard and vendor-specific constructs. The biggest factor was not what was the theoretical background behind each implementation but ease of use and ease of adoption. SQLite is an outstanding database not because of its compliance with SQL standards and adherence to theoretical purity, but because it's FLOSS and trivial to setup and use. I expect the same factors to be relevant in adoption of functional programming. This stuff exists for decades on end but mass adoption was between negligible to irrelevant. What started to drive adoption was the inception of modules and components that solved real-world problems and helped developers do what they wanted to do with less effort. In JavaScript the use of map, filter and reduce is not driven by any new-founded passion for function programming but because it's right there and it's concise and simple and readable and capable. In C#, linq is gaining traction for the same reasons but is largely kept back by performance issues. The key aspect is pragmatism, and theoretical elegance is by far a mere nice-to-have.

jghn 1y ago
> The world is gradually slipping towards nosql databases My observation has been that this pendulum is swinging back the other direction. You're correct that some NoSQL-isms found their way into RDBMS, but at least in the circles in which I travel, people are by and large heading back to RDBMS stores.
efitz 1y ago
> ..except they aren't. The world is gradually slipping towards nosql databases and stepping away from normalized data stores The 2010s called and want their database paradigm back. NoSQL is definitely not the zeitgeist today. Graph DBs, KV stores, document DBs, and OLTP DBs are what is popular today- I would say that the two shifts I see in the 2020s is the rise of cache-as-database (eg redis) and an “all of the above” mentality rather than one-size-fits-all.