4 ms·

Maybe another reason is: there is two kinds of software, one is programms which process input data and transform them to output data. And then there is software

Maybe another reason is: there is two kinds of software, one is programms which process input data and transform them to output data. And then there is software which operates hardware, like steering of the stepper motors of a robot, or the firmware of a washing machine. Functional languages are (rightfully) immediately dismissed for these kinds of problems. Then there is a grey zone: GUI programming, this is almost hardware progamming and FP have been trying but not doing well in this domain (might be wrong though). Hardware programming doesnt come up often IT departments, so maybe this is a blind spot, but basically you are loosing a big share of the market. Ps: something special might be with the erlang telco system, but i have no idea about it

skohan 6y ago
One could argue that all software is operating hardware. In many cases the hardware you're operating is a CPU, GPU, memory and storage. Most of the time it doesn't feel like that if you're doing something like web programming. But for something like computer graphics, where you're thinking carefully about how to lay out memory so that a multi-core CPU can traverse it in the most efficient way, functional programming feels similarly lacking as you're describing in the robotics case. In my experience after "looking behind the curtain" for this kind of task where performance and low-level control is absolutely necessary, it's difficult to ignore all the inefficiencies which must exist in a more abstract system. But I'm not sure that's entirely justified.
didibus 6y ago
This is true, but it depends which language we're talking about. There are two definitions to FP. The stricter one is about having immutable data and pure functions. In that one, it's fundamentally only a computing language, not a programming language, in that by definition it cannot tell the computer to perform any action, as purity implies no side effects. That means you always need an additional layer which then drives the side effect. For a lot of programs, that adds some complexity to the program. The programmer has to model their side effects with this layer in mind. The layer means the programmer loses control over the fine grained details of the side effect as well, which might hurt performance, or make certain things more difficult. That said, there are impure FP languages. Where you can program the machine to do whatever you want, and also make computation functionally with immutable data and pure functions. Clojure is such a language. I'm very biased towards it FYI, as it's the language I enjoy most as of now. But I think it's important to bring it up. Defaulting to immutable and pure computations, but letting you perform all kinds of controlled mutation and side effect really seems like a good future to me. Rust in a sense is pretty similar. While it doesn't use a strict functional sense of immutability and purity of data and functions. The borrow checker tracks all changes to data and assigns ownership of access, which is kind of similar to immutability and purity. Yet it lets you do unsafe things when required, often for interopping with peripherals and the machine itself. Erlang like you mentioned is another example of this. I think those languages might have a better future, and are slowly starting to pick up on popularity. Even in JS for example, lots of people are adopting this style. So if not a programming language, at least the paradigm seems to become more and more popular. As an aside, for example, there is a Clojure dialect called ferret https://ferret-lang.org/ https://ferret-lang.org/ which is designed for use on microcontrollers. It has immutable data structures and support all the functional aspects of Clojure, yet targets real time control applications.
- eru 6y ago
  Immutable data and pure functions aren't as big as an obstacle as you might think. Uniqueness types allow you to use immutable variables and still directly model side effects and state changes. Arguably better than mutable variables do so. (Haskell is not a good language for that kind of control. Though you could make a language that looks quite a lot like Haskell that fits. And people have done so.)
  - didibus 6y ago
    Isn't uniqueness typing just a more restrictive form to Rust's linear types? And since Rust itself is often forced to rely on unsafe blocks for programming tasks (as opposed to computing tasks), then wouldn't that be true of a language with uniqueness types as well? Also, I'm guessing you mean Clean or Miranda? Any idea why they aren't more popular than Haskell? Or why Haskell doesn't adopt uniqueness typing?
    - eru 6y ago
      Linear types and uniqueness typing are so close together that people often mix them up. Yes, that's basically what I am talking about. For general usage monads are much easier to deal with than Clean's "pass around the world" system. (I only used Clean for a bit, but haven't used Miranda, yet.) However, linear types for Haskell have been in the works for some time. See eg https://www.reddit.com/r/haskell/comments/dpr276/what_is_the_status_of_ghc_linear_types/ https://www.reddit.com/r/haskell/comments/dpr276/what_is_the... (Similarly, GHC now support strict Haskell, too, on a per module basis.) Uniqueness typing shines when you want to split up your 'real-world' object, so you can eg manipulate individual memory cells or ports etc independently. Rust goes into unsafe mode for multiple reasons. You could eliminate most of those, if you were willing to take the complexity of dependent types. Ie more or less that means the programmer taking on a greater burden of proving code to be safe to the compiler; instead of relying on Rust's more automatic but conservative system.
eru 6y ago
I've done GUI programming in a Haskell dialect. It was rather pleasant, thanks to a nice library by Neil Mitchell that took ideas from functional reactive programming and lenses. You can get arbitrarily close to the hardware with functional languages. It's just that the flagship functional language that everybody knows and loves, Haskell, is not the one for the task. You want a language with linear variables / uniqueness types for that.
- andi999 6y ago
  Could you name the dialect and the name of the GUI lib? While Neil Mitchell mentioned he worked on GUI on his blog, I somehow couldnt identify it.
  - eru 6y ago
    The dialect is Mu, Standard Charter's internal Haskell clone. I don't remember the name of the library, but it was also internal. I've used JavaScript's React last year, and it feels somewhat similar in some respects; though a bit more messy and cumbersome.
Oreb 6y ago
I have to disagree with you on the GUI side. The most pleasant GUI programming I have done has been with ClojureScript/re-frame and with Elm, despite all the horrors of the web platform.
- andi999 6y ago
  Good to know that things start to move. I was looking a while back at Lisp and Haskell for GUI programming, and it at most looked a bit half-baked. To me then it was obvious why ppl would implement their GUI in VB or win32 C-API.
tome 6y ago
> is software which operates hardware, like steering of the stepper motors of a robot, or the firmware of a washing machine. Functional languages are (rightfully) immediately dismissed for these kinds of problems Given that there is literally a version of Haskell (https://clash-lang.org/ https://clash-lang.org/) designed for programming FPGAs and ASICs I don't thin the dismissal is rightful. I've used Clash to program FPGAs with computer vision algorithms.

skohan 6y ago

One could argue that all software is operating hardware. In many cases the hardware you're operating is a CPU, GPU, memory and storage. Most of the time it doesn't feel like that if you're doing something like web programming. But for something like computer graphics, where you're thinking carefully about how to lay out memory so that a multi-core CPU can traverse it in the most efficient way, functional programming feels similarly lacking as you're describing in the robotics case. In my experience after "looking behind the curtain" for this kind of task where performance and low-level control is absolutely necessary, it's difficult to ignore all the inefficiencies which must exist in a more abstract system. But I'm not sure that's entirely justified.

didibus 6y ago

This is true, but it depends which language we're talking about. There are two definitions to FP. The stricter one is about having immutable data and pure functions. In that one, it's fundamentally only a computing language, not a programming language, in that by definition it cannot tell the computer to perform any action, as purity implies no side effects. That means you always need an additional layer which then drives the side effect. For a lot of programs, that adds some complexity to the program. The programmer has to model their side effects with this layer in mind. The layer means the programmer loses control over the fine grained details of the side effect as well, which might hurt performance, or make certain things more difficult. That said, there are impure FP languages. Where you can program the machine to do whatever you want, and also make computation functionally with immutable data and pure functions. Clojure is such a language. I'm very biased towards it FYI, as it's the language I enjoy most as of now. But I think it's important to bring it up. Defaulting to immutable and pure computations, but letting you perform all kinds of controlled mutation and side effect really seems like a good future to me. Rust in a sense is pretty similar. While it doesn't use a strict functional sense of immutability and purity of data and functions. The borrow checker tracks all changes to data and assigns ownership of access, which is kind of similar to immutability and purity. Yet it lets you do unsafe things when required, often for interopping with peripherals and the machine itself. Erlang like you mentioned is another example of this. I think those languages might have a better future, and are slowly starting to pick up on popularity. Even in JS for example, lots of people are adopting this style. So if not a programming language, at least the paradigm seems to become more and more popular. As an aside, for example, there is a Clojure dialect called ferret https://ferret-lang.org/ https://ferret-lang.org/ which is designed for use on microcontrollers. It has immutable data structures and support all the functional aspects of Clojure, yet targets real time control applications.

eru 6y ago
Immutable data and pure functions aren't as big as an obstacle as you might think. Uniqueness types allow you to use immutable variables and still directly model side effects and state changes. Arguably better than mutable variables do so. (Haskell is not a good language for that kind of control. Though you could make a language that looks quite a lot like Haskell that fits. And people have done so.)
- didibus 6y ago
  Isn't uniqueness typing just a more restrictive form to Rust's linear types? And since Rust itself is often forced to rely on unsafe blocks for programming tasks (as opposed to computing tasks), then wouldn't that be true of a language with uniqueness types as well? Also, I'm guessing you mean Clean or Miranda? Any idea why they aren't more popular than Haskell? Or why Haskell doesn't adopt uniqueness typing?
  - eru 6y ago
    Linear types and uniqueness typing are so close together that people often mix them up. Yes, that's basically what I am talking about. For general usage monads are much easier to deal with than Clean's "pass around the world" system. (I only used Clean for a bit, but haven't used Miranda, yet.) However, linear types for Haskell have been in the works for some time. See eg https://www.reddit.com/r/haskell/comments/dpr276/what_is_the_status_of_ghc_linear_types/ https://www.reddit.com/r/haskell/comments/dpr276/what_is_the... (Similarly, GHC now support strict Haskell, too, on a per module basis.) Uniqueness typing shines when you want to split up your 'real-world' object, so you can eg manipulate individual memory cells or ports etc independently. Rust goes into unsafe mode for multiple reasons. You could eliminate most of those, if you were willing to take the complexity of dependent types. Ie more or less that means the programmer taking on a greater burden of proving code to be safe to the compiler; instead of relying on Rust's more automatic but conservative system.

eru 6y ago

I've done GUI programming in a Haskell dialect. It was rather pleasant, thanks to a nice library by Neil Mitchell that took ideas from functional reactive programming and lenses. You can get arbitrarily close to the hardware with functional languages. It's just that the flagship functional language that everybody knows and loves, Haskell, is not the one for the task. You want a language with linear variables / uniqueness types for that.

andi999 6y ago
Could you name the dialect and the name of the GUI lib? While Neil Mitchell mentioned he worked on GUI on his blog, I somehow couldnt identify it.
- eru 6y ago
  The dialect is Mu, Standard Charter's internal Haskell clone. I don't remember the name of the library, but it was also internal. I've used JavaScript's React last year, and it feels somewhat similar in some respects; though a bit more messy and cumbersome.

Oreb 6y ago

I have to disagree with you on the GUI side. The most pleasant GUI programming I have done has been with ClojureScript/re-frame and with Elm, despite all the horrors of the web platform.

andi999 6y ago
Good to know that things start to move. I was looking a while back at Lisp and Haskell for GUI programming, and it at most looked a bit half-baked. To me then it was obvious why ppl would implement their GUI in VB or win32 C-API.

tome 6y ago

> is software which operates hardware, like steering of the stepper motors of a robot, or the firmware of a washing machine. Functional languages are (rightfully) immediately dismissed for these kinds of problems Given that there is literally a version of Haskell (https://clash-lang.org/ https://clash-lang.org/) designed for programming FPGAs and ASICs I don't thin the dismissal is rightful. I've used Clash to program FPGAs with computer vision algorithms.