5 ms·

Did you even read the article? His point was that introducing some functional features to imperative languages do not confer them the safety benefits found in t

Did you even read the article? His point was that introducing some functional features to imperative languages do not confer them the safety benefits found in type systems such as Haskell's. It has absolutely nothing to do with pragmatism or any such thing.

coldtea 11y ago
>Did you even read the article? I did, did you? >His point was that introducing some functional features to imperative languages do not confer them the safety benefits found in type systems such as Haskell's. And my point was that I don't want ALL the safety benefits found in type systems such as Haskells. If I would, I would be using Haskell. Or rather, while I might want it, I also want other things more, so I wouldn't sacrifice all of them to get it. His point was that mostly functional "does not work" which is a BS thing to say, because it's an absolute statement. And his whole article revolves around that absolute, e.g.: >The idea of "mostly functional programming" is unfeasible. It is impossible to make imperative programming languages safer by only partially removing implicit side effects. Nope, you can very much make them safer. It might not make them the "safest" it can be, but it can totally make them safer. Even merely substituting for loops with map and fold will eliminate lots of potential bugs. Heck, you can even make C much safer by just removing pointer arithmetic or just adding a built-in string type. Either of those two things alone would eliminate tons of bugs while the language would remain the imperative thing that it is.
- kstenerud 11y ago
  Exactly right. While some purists will bemoan imperfection and invent all sorts of "horror stories" from their ivory tower, engineers who actually get things done are quite satisfied with "good enough." Functional purism after awhile starts to smack of the bad old days of waterfall development, where each step in the series requires perfection lest the remaining steps collapse (if everyone would just follow this perfect system, we'd all have rainbows and unicorns). You can have perfect safety, or you can have a workable system delivered in a timely manner.
  - sacado2 11y ago
    Well, sometimes perfect safety is the only option. Would you fly on a plane that is piloted by a workable system delivered in a timely manner ?
    - deleted 11y ago
      [deleted]
    - bunderbunder 11y ago
      Considering the languages that are normally used to write aircraft control software, this is perhaps a questionable choice of example. And there are probably very good reasons why a language like Haskell is not likely to be chosen for this kind of application. Consider predictability: Haskell may make it easy to prove algorithmic correctness, but its laziness makes runtime characteristics more difficult to reason about because they're hidden behind so much abstraction. This could make it very difficult to deal with stuff like subtle bugs related to timing issues that might crop up in an electromechanical system.
      - sacado2 11y ago
        Yes, I totally agree, I was just questioning the above assertion : "perfect safety is only good for ivory tower guys".
    - coldtea 11y ago
      Perfectly safe systems like planes, missiles, space missions etc. are 99% done in imperative languages such as C and Ada. Not Haskell and not even Lisp. The last thing you want from a perfectly safe system is some lazyness smartness in the compiler hitting at the wrong time and affecting execution time, memory use etc, or things like GC pauses.
      - sacado2 11y ago
        Yes. My comment was not clear, I don't associate "perfect safety" with functional purity. Quite the opposite actually, for the reasons you gave.
- bunderbunder 11y ago
  > Nope, you can very much make them safer. It might not make them the "safest" it can be, but it can totally make them safer. This one might come down to conflicting definitions of "safe". The author seems to define safety purely in relation to the number of language features with which you can contrive to shoot yourself in the foot. You seem to also take into account the number of language features you can use to make it harder to shoot yourself in the foot. I think there's some value in both definitions. The author's perspective captures a lot of what worries me about languages like C++. But it also fails to give C++ any credit for all the language improvements that have materially improved the overall quality of most C++ code over the past couple decades.
AnimalMuppet 11y ago
> It has absolutely nothing to do with pragmatism or any such thing. Yeah, well, for those of us who actually write programs, pragmatism matters a lot. If you're going to tell us how we should do it, but without anything like pragmatism, you're not going to get much of a hearing from the people you think you're trying to talk to.
- tome 11y ago
  I'm not why tincholio expressed it like that. It's exactly to do with pragmatism. Mixing effects and laziness is not pragmatic exactly because it leads to very confusing orders of effect execution.
  - coldtea 11y ago
    Functional is not about lazyness. So you don't have to mix effects with laziness, you can mix effects and other functional constructs (pure functions, immutable values, closures, map, fold, homoiconicity and macros, etc) and you still get a huge benefit. So the theme of the article "mostly functional can't work" is wrong.
    - AnimalMuppet 11y ago
      But (if I understood correctly), the article was about lazy functional, even if that was not stated in the title. Whether or not I read the article correctly, tome's comment was brilliant. It very succinctly exposed the pragmatic issue at stake.
    - tome 11y ago
      > So the theme of the article "mostly functional can't work" is wrong. You're right. It's not really an issue of "functional" at all. It's worth noting that the author is an incorrigible (yet gentle) troll who likes to poke fun at Haskell and non-Haskell languages alike.

coldtea 11y ago

>Did you even read the article? I did, did you? >His point was that introducing some functional features to imperative languages do not confer them the safety benefits found in type systems such as Haskell's. And my point was that I don't want ALL the safety benefits found in type systems such as Haskells. If I would, I would be using Haskell. Or rather, while I might want it, I also want other things more, so I wouldn't sacrifice all of them to get it. His point was that mostly functional "does not work" which is a BS thing to say, because it's an absolute statement. And his whole article revolves around that absolute, e.g.: >The idea of "mostly functional programming" is unfeasible. It is impossible to make imperative programming languages safer by only partially removing implicit side effects. Nope, you can very much make them safer. It might not make them the "safest" it can be, but it can totally make them safer. Even merely substituting for loops with map and fold will eliminate lots of potential bugs. Heck, you can even make C much safer by just removing pointer arithmetic or just adding a built-in string type. Either of those two things alone would eliminate tons of bugs while the language would remain the imperative thing that it is.

kstenerud 11y ago
Exactly right. While some purists will bemoan imperfection and invent all sorts of "horror stories" from their ivory tower, engineers who actually get things done are quite satisfied with "good enough." Functional purism after awhile starts to smack of the bad old days of waterfall development, where each step in the series requires perfection lest the remaining steps collapse (if everyone would just follow this perfect system, we'd all have rainbows and unicorns). You can have perfect safety, or you can have a workable system delivered in a timely manner.
- sacado2 11y ago
  Well, sometimes perfect safety is the only option. Would you fly on a plane that is piloted by a workable system delivered in a timely manner ?
  - deleted 11y ago
    [deleted]
  - bunderbunder 11y ago
    Considering the languages that are normally used to write aircraft control software, this is perhaps a questionable choice of example. And there are probably very good reasons why a language like Haskell is not likely to be chosen for this kind of application. Consider predictability: Haskell may make it easy to prove algorithmic correctness, but its laziness makes runtime characteristics more difficult to reason about because they're hidden behind so much abstraction. This could make it very difficult to deal with stuff like subtle bugs related to timing issues that might crop up in an electromechanical system.
    - sacado2 11y ago
      Yes, I totally agree, I was just questioning the above assertion : "perfect safety is only good for ivory tower guys".
  - coldtea 11y ago
    Perfectly safe systems like planes, missiles, space missions etc. are 99% done in imperative languages such as C and Ada. Not Haskell and not even Lisp. The last thing you want from a perfectly safe system is some lazyness smartness in the compiler hitting at the wrong time and affecting execution time, memory use etc, or things like GC pauses.
    - sacado2 11y ago
      Yes. My comment was not clear, I don't associate "perfect safety" with functional purity. Quite the opposite actually, for the reasons you gave.
bunderbunder 11y ago
> Nope, you can very much make them safer. It might not make them the "safest" it can be, but it can totally make them safer. This one might come down to conflicting definitions of "safe". The author seems to define safety purely in relation to the number of language features with which you can contrive to shoot yourself in the foot. You seem to also take into account the number of language features you can use to make it harder to shoot yourself in the foot. I think there's some value in both definitions. The author's perspective captures a lot of what worries me about languages like C++. But it also fails to give C++ any credit for all the language improvements that have materially improved the overall quality of most C++ code over the past couple decades.

AnimalMuppet 11y ago

> It has absolutely nothing to do with pragmatism or any such thing. Yeah, well, for those of us who actually write programs, pragmatism matters a lot. If you're going to tell us how we should do it, but without anything like pragmatism, you're not going to get much of a hearing from the people you think you're trying to talk to.

tome 11y ago
I'm not why tincholio expressed it like that. It's exactly to do with pragmatism. Mixing effects and laziness is not pragmatic exactly because it leads to very confusing orders of effect execution.
- coldtea 11y ago
  Functional is not about lazyness. So you don't have to mix effects with laziness, you can mix effects and other functional constructs (pure functions, immutable values, closures, map, fold, homoiconicity and macros, etc) and you still get a huge benefit. So the theme of the article "mostly functional can't work" is wrong.
  - AnimalMuppet 11y ago
    But (if I understood correctly), the article was about lazy functional, even if that was not stated in the title. Whether or not I read the article correctly, tome's comment was brilliant. It very succinctly exposed the pragmatic issue at stake.
  - tome 11y ago
    > So the theme of the article "mostly functional can't work" is wrong. You're right. It's not really an issue of "functional" at all. It's worth noting that the author is an incorrigible (yet gentle) troll who likes to poke fun at Haskell and non-Haskell languages alike.