Hacker News Reader

Comment by coldtea | Hacker News Reader

Condidering that

1) mostly imperative programming has worked wonders for ages with a huge body of work to show for (almost every basic infrastrcuture, all major OSes, almost all popular programs etc are writen in one of C/C++/Pascal/Obj-C/Fortran/Ada/Java). Might have its security and stability warts, but it has shown pragmatic results.

2) "fully functional" might have its security and stability assurances, but it has little of importance historically to show for all its boasting (the AI winter is not something to be really proud of).

I'd call BS, and say that "mostly functional" works fine, thank you very much, in that it takes (1) that already works (with some issues) and makes it even better with a touch of (2).

View on HN

I think the author means to say that it's kind of an all or nothing thing. You either go purely functional and get all the benefits, or you don't and barely get any benefits at all.

You could say that "almost functional" does not really exist, just like "almost secure" does not exist.

And yes, you can still program with a non-functional language just fine he does not refute that.

>I think the author means to say that it's kind of an all or nothing thing. You either go purely functional and get all the benefits, or you don't and barely get any benefits at all.

Yes. And what I say is that "I get enough benefits from going halfway functional, thank you very much".

>You could say that "almost functional" does not really exist, just like "almost secure" does not exist.

You could say that but you would be wrong. Most Lisp coders for example have also used imperative code where they need it, with side effects and all. Nobody cared much about such total "functionalness" and purity as you get today from Haskell programmers (most of them non professional of course since there are far more Haskell programmers than Haskell jobs) and the like...

ahem pure lazy functional. One could read the article and walk away believing that laziness is the problem.

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.

>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.

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.

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 ?

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.

Yes, I totally agree, I was just questioning the above assertion : "perfect safety is only good for ivory tower guys".

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.

Yes. My comment was not clear, I don't associate "perfect safety" with functional purity. Quite the opposite actually, for the reasons you gave.

Would you fly on a plane that is piloted by a workable system delivered in a timely manner ?

I do every time I get in a plane.

> 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.

> 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.

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.

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.

> 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.

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.

Reply on news.ycombinator.com