3 ms·

Sadly I don't think so, just because it looks "too functional". If comments on the web are anything to go by, being familiar to C and JS programmers is one of

by dvdkon 1y ago

Sadly I don't think so, just because it looks "too functional". If comments on the web are anything to go by, being familiar to C and JS programmers is one of the main reasons for Go's success. I think it has plenty of its own specifics, it's not like e.g. C# which really did start as a straightforward Java clone, but OCaml has even more differences.

jchw 1y ago
I think it's worth considering the possibility that imperative style is just more approachable than functional style. On one hand, some tasks that are basically trivial few-line solutions in a good functional programming language balloon to hundreds of lines of arguably more error prone code in especially dumb imperative languages like Go. On the other hand, it's really really easy to understand what the vast majority of Go code is doing by just reading it line-by-line. Don't get me wrong: it's easy to write broken and unreadable code in pretty much any programming language (I can write bad code in imperative or functional style, I'm a multi-paradigm bad programmer) but at the very least for most imperative code you can really just follow everything line-by-line. It's harder to pull apart complex compositions of map/reduce/filter/fold/etc. (especially if you involve other complex topics like async.) This does seem to be quite a conundrum. I don't think there's any argument regarding the merits of functional programming as a paradigm, but imperative just seems easier to wrap one's head around, and frankly most code is really boring and doesn't need to be able to do the super powerful things that functional programming can do with relative ease. I feel like I'm playing with fire by saying this here, but I think it's true.
- andrewflnr 1y ago
  That's the thing about OCaml, though, it's relatively friendly with imperative programming too. At least, it's not picky about side effects the way Haskell is. It might still be a pain with loops, though. It's been a while since I used it.
- suprtx 1y ago
  I think you are correct, perhaps even being too careful in your claims. I think functional and imperative programming, in practice, tend to have different types of constraints, and there are different things that are easy to reason about in them, and encourage different reasoning methods and approaches, and ways of proving properties about them. I think that for learning functional programming, being all-in on purely functional programming and never having side-effects or mutation, can be useful. But for practical programming, functional programming is not in itself a virtue just by itself. One should always consider the trade-offs of the specific case one is facing if one is not learning, as such. If a project has decided on a trade-off where purely functional programming is chosen, then maybe continuing with pure FP is fine; but even in such a case, a function that from outside is purely functional, but uses imperative programming internally, for instance for the sake of optimization, can make sense. There are different advantages and disadvantages to having: pure FP; imperative programming; or different kinds of mixes of FP and imperative programming. Overall, my approximate opinion is that it does not make sense to be dogmatic about functional programming, except when learning FP. https://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort https://stackoverflow.com/questions/7717691/why-is-the-minim... is arguably a relevant example, though a proper in-place implementation in Haskell might be more fair for comparison. Though I am not certain whether Haskell's lazy evaluation would help or hinder analysis, Ocaml or SML might be better languages for implementing and analysing an in-place implementation variant. Also, Hacker News is a censorship hole.
- suprtx 1y ago
  Sorry, apparently there was a "true" implementation in Haskell in one of the answers, though I am not sure how the lazy evaluation of Haskell is handled. https://stackoverflow.com/a/7719971 https://stackoverflow.com/a/7719971 You can see that the Haskell code is more verbose than the C code.
- suprtx 1y ago
  Prolog, not being based on imperative programming or FP, but being based on logic programming, is another example in regards to this topic. Prolog can be very concise and clear for a specific set of problems, but reasoning about the time complexity of an algorithm implemented in it can often be difficult at best.

by dvdkon 1y ago

jchw 1y ago

I think it's worth considering the possibility that imperative style is just more approachable than functional style. On one hand, some tasks that are basically trivial few-line solutions in a good functional programming language balloon to hundreds of lines of arguably more error prone code in especially dumb imperative languages like Go. On the other hand, it's really really easy to understand what the vast majority of Go code is doing by just reading it line-by-line. Don't get me wrong: it's easy to write broken and unreadable code in pretty much any programming language (I can write bad code in imperative or functional style, I'm a multi-paradigm bad programmer) but at the very least for most imperative code you can really just follow everything line-by-line. It's harder to pull apart complex compositions of map/reduce/filter/fold/etc. (especially if you involve other complex topics like async.) This does seem to be quite a conundrum. I don't think there's any argument regarding the merits of functional programming as a paradigm, but imperative just seems easier to wrap one's head around, and frankly most code is really boring and doesn't need to be able to do the super powerful things that functional programming can do with relative ease. I feel like I'm playing with fire by saying this here, but I think it's true.

andrewflnr 1y ago
That's the thing about OCaml, though, it's relatively friendly with imperative programming too. At least, it's not picky about side effects the way Haskell is. It might still be a pain with loops, though. It's been a while since I used it.
suprtx 1y ago
I think you are correct, perhaps even being too careful in your claims. I think functional and imperative programming, in practice, tend to have different types of constraints, and there are different things that are easy to reason about in them, and encourage different reasoning methods and approaches, and ways of proving properties about them. I think that for learning functional programming, being all-in on purely functional programming and never having side-effects or mutation, can be useful. But for practical programming, functional programming is not in itself a virtue just by itself. One should always consider the trade-offs of the specific case one is facing if one is not learning, as such. If a project has decided on a trade-off where purely functional programming is chosen, then maybe continuing with pure FP is fine; but even in such a case, a function that from outside is purely functional, but uses imperative programming internally, for instance for the sake of optimization, can make sense. There are different advantages and disadvantages to having: pure FP; imperative programming; or different kinds of mixes of FP and imperative programming. Overall, my approximate opinion is that it does not make sense to be dogmatic about functional programming, except when learning FP. https://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort https://stackoverflow.com/questions/7717691/why-is-the-minim... is arguably a relevant example, though a proper in-place implementation in Haskell might be more fair for comparison. Though I am not certain whether Haskell's lazy evaluation would help or hinder analysis, Ocaml or SML might be better languages for implementing and analysing an in-place implementation variant. Also, Hacker News is a censorship hole.
suprtx 1y ago
Sorry, apparently there was a "true" implementation in Haskell in one of the answers, though I am not sure how the lazy evaluation of Haskell is handled. https://stackoverflow.com/a/7719971 https://stackoverflow.com/a/7719971 You can see that the Haskell code is more verbose than the C code.
suprtx 1y ago
Prolog, not being based on imperative programming or FP, but being based on logic programming, is another example in regards to this topic. Prolog can be very concise and clear for a specific set of problems, but reasoning about the time complexity of an algorithm implemented in it can often be difficult at best.