3 ms·

I've learned haskell at the university level, and really enjoyed it(and found it very easy to pick up), but find it puzzling where I should use it. It's very e

by soperj 11y ago

I've learned haskell at the university level, and really enjoyed it(and found it very easy to pick up), but find it puzzling where I should use it. It's very easy to say this problem requires a scripting language, and this problem is better suited for an object oriented language, but I don't quite understand what problems would be easier with a functional language. At least in terms of problems that I want solved.

kqr 11y ago
> ...this problem requires a scripting language... Cool, we have that in Haskell these days![1] Except, of course, it has all the good high-level stuff of Haskell, which reduces boilerplate and increases correctness. [1]: https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle-Tutorial.html https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle...
- soperj 11y ago
  Nice to know. Maybe using it more often would lead to thinking about things functionally and finding problems that are better solved functionally.
- omaranto 11y ago
  When comparing with scripting languages, I think it's fair to talk about how Haskell increases correctness, but I don't think you'll convince people coming from those languages it reduces a lot of boilerplate. (On the other hand, you can definitely sell Haskell as a boilerplate reducer to people coming from languages like Java, say.)
bpicolo 11y ago
Traditionally speaking, one of the bigger arguments for functional languages is "embarrassingly high parallelism" because they tend to simplify many issues that writing imperative languages concurrently can bring about
implicit 11y ago
My experience is that typed functional programming is excellent for any application that can afford to run a garbage collector and needs to to be able to change continuously forever.
elihu 11y ago
Generally speaking, most programs could be written in either Haskell or an imperative language without much trouble (assuming you're comfortable with the language), though some problems are better suited to Haskell than others. The way I see it, if you want to extend your language to be able to express solutions to your problem in terms that are close to your problem domain, then Haskell is probably a good choice. If you would rather transform your problem into constructs that are easily understood in terms of the low-level operations performed by a computer, then you might be better off with a low-level imperative language. To put it another way, if your requirements include things like deterministic real-time scheduling, strict performance or memory requirements, anything involving assembly language or cachelines, then you should probably use something like C or C++ or Rust. On the other hand, if you don't care about any of that and you just want your program to compute the right answer in a reasonable amount of time and you want to have high confidence that it's right, then Haskell is a pretty good choice.

by soperj 11y ago

kqr 11y ago

> ...this problem requires a scripting language... Cool, we have that in Haskell these days![1] Except, of course, it has all the good high-level stuff of Haskell, which reduces boilerplate and increases correctness. [1]: https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle-Tutorial.html https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle...

soperj 11y ago
Nice to know. Maybe using it more often would lead to thinking about things functionally and finding problems that are better solved functionally.
omaranto 11y ago
When comparing with scripting languages, I think it's fair to talk about how Haskell increases correctness, but I don't think you'll convince people coming from those languages it reduces a lot of boilerplate. (On the other hand, you can definitely sell Haskell as a boilerplate reducer to people coming from languages like Java, say.)

bpicolo 11y ago

Traditionally speaking, one of the bigger arguments for functional languages is "embarrassingly high parallelism" because they tend to simplify many issues that writing imperative languages concurrently can bring about

implicit 11y ago

My experience is that typed functional programming is excellent for any application that can afford to run a garbage collector and needs to to be able to change continuously forever.

elihu 11y ago

Generally speaking, most programs could be written in either Haskell or an imperative language without much trouble (assuming you're comfortable with the language), though some problems are better suited to Haskell than others. The way I see it, if you want to extend your language to be able to express solutions to your problem in terms that are close to your problem domain, then Haskell is probably a good choice. If you would rather transform your problem into constructs that are easily understood in terms of the low-level operations performed by a computer, then you might be better off with a low-level imperative language. To put it another way, if your requirements include things like deterministic real-time scheduling, strict performance or memory requirements, anything involving assembly language or cachelines, then you should probably use something like C or C++ or Rust. On the other hand, if you don't care about any of that and you just want your program to compute the right answer in a reasonable amount of time and you want to have high confidence that it's right, then Haskell is a pretty good choice.