3 ms·

Are you suggesting functional programming is somehow so resource intensive that it is impractical to use? Or that functional programming makes effectful work im

Are you suggesting functional programming is somehow so resource intensive that it is impractical to use? Or that functional programming makes effectful work impractical? Because neither of those are true. You’ve conceded that SQL queries are one case where a functional approach is more ergonomic (after first asserting that the world is not functional, whatever that means). Why aren’t there other cases? Are you sure there aren’t other cases? One could argue that a functional approach maps more practically and ergonomically for the majority of general programming work than other mainstream approach.

raverbashing 7y ago
> Are you suggesting functional programming is somehow so resource intensive that it is impractical to use? Or that functional programming makes effectful work impractical? Because neither of those are true. No, I'm saying the functional abstraction doesn't work or is clunky in a lot of cases and that Haskell's approach of making it the core of the language is misguided (Lisp is less opinionated than Haskell for one). > One could argue that a functional approach maps more practically and ergonomically for the majority of general programming work than other mainstream approach. They could argue, but they would be wrong. SQL works because it's a strict abstraction on a very defined problem. Functional is great when all you're thinking about is numbers or data structures. But throw in some form of IO or even random numbers and you have to leave the magical functional world. And you know why SQL works so fine? Because there are a lot of people working hard in C/C++ doing kernel and low-level work so that the "magic" is not lost on the higher level abstractions. And can you work without a GC?
- yakshaving_jgt 7y ago
  > I'm saying the functional abstraction doesn't work or is clunky in a lot of cases and that Haskell's approach of making it the core of the language is misguided Functional programming certainly doesn't work literally everywhere, but to say Haskell's design is "misguided" is your opinion, and it's one that some of the biggest names in the industry reject. How much experience do you have designing programming languages? Or even just building non-trivial systems in Haskell? Judging by the evident ignorance masked with strong opinions I'd say around about the square root of diddly-nothing. > But throw in some form of IO or even random numbers and you have to leave the magical functional world. Wrong. Functional programming handles IO and randomness just fine. > And you know why SQL works so fine? Because there are a lot of people working hard in C/C++ doing kernel and low-level work so that the "magic" is not lost on the higher level abstractions Are you suggesting there aren't a lot of people working hard on GHC? Because if you are — and you seem to be — then again you would be wrong.
  - deleted 7y ago
    [deleted]

raverbashing 7y ago

> Are you suggesting functional programming is somehow so resource intensive that it is impractical to use? Or that functional programming makes effectful work impractical? Because neither of those are true. No, I'm saying the functional abstraction doesn't work or is clunky in a lot of cases and that Haskell's approach of making it the core of the language is misguided (Lisp is less opinionated than Haskell for one). > One could argue that a functional approach maps more practically and ergonomically for the majority of general programming work than other mainstream approach. They could argue, but they would be wrong. SQL works because it's a strict abstraction on a very defined problem. Functional is great when all you're thinking about is numbers or data structures. But throw in some form of IO or even random numbers and you have to leave the magical functional world. And you know why SQL works so fine? Because there are a lot of people working hard in C/C++ doing kernel and low-level work so that the "magic" is not lost on the higher level abstractions. And can you work without a GC?

yakshaving_jgt 7y ago
> I'm saying the functional abstraction doesn't work or is clunky in a lot of cases and that Haskell's approach of making it the core of the language is misguided Functional programming certainly doesn't work literally everywhere, but to say Haskell's design is "misguided" is your opinion, and it's one that some of the biggest names in the industry reject. How much experience do you have designing programming languages? Or even just building non-trivial systems in Haskell? Judging by the evident ignorance masked with strong opinions I'd say around about the square root of diddly-nothing. > But throw in some form of IO or even random numbers and you have to leave the magical functional world. Wrong. Functional programming handles IO and randomness just fine. > And you know why SQL works so fine? Because there are a lot of people working hard in C/C++ doing kernel and low-level work so that the "magic" is not lost on the higher level abstractions Are you suggesting there aren't a lot of people working hard on GHC? Because if you are — and you seem to be — then again you would be wrong.
- deleted 7y ago
  [deleted]