6 ms·

My problem with Haskell is that it is not pragmatic and the reason I stopped using it. The philosophy of separating pure and impure code – and to enforce it – d

My problem with Haskell is that it is not pragmatic and the reason I stopped using it. The philosophy of separating pure and impure code – and to enforce it – does more harm than good. Often its difficult to understand what your "forth level of abstraction code" above the usual abstraction levels really does. Haskell is fun to learn. Haskell has a lot of interesting concepts to explore and it will make you a better programmer. Haskell code can be really dense. And Haskell code can be totally unreadable, using concepts which take weeks to learn – which is... not so great. Lisp (Common Lisp) is what you get when you reduce the rules and syntax to a minimum and try at the same time to be a maximal flexible programming language. This simplicity and applied pragmatism is what makes it so great. Like the authors in the Lisp books warned, after learning Lisp, coding won't be the same. Now I see everywhere code that could easily be written in Lisp, but is not so great in language XYZ. All those SDL's and stringified API's and code-generators they need to do real things and data formats like JSON... all obsolete, if they would have chosen Lisp (or a language with brackets and Lisp like evaluation rules). The other thing that is often overlooked regarding Lisp is, that in a Lisp like language there is no need to wait for a new version of the programming language to be released to get new syntax – you can simply add it yourself (or have a library doing it for you). E.g. a lot of the JavaScript mess could be fixed by code transformation, if they would have chosen a Lisp like syntax in the first place. I don't see Haskell as uber language. If I want super correct code, speed and I'm okay with using a more complex language, then there is Rust – which is probably more correct than Haskell and faster, too. Haskell, Lisp and C++ would really benefit form a std library 2.0 and a default package manager... one can dream.

bad_user 8y ago
The ability to come up with new syntax in LISP is in my opinion vastly overrated. Yes, LISP code can be easily parsed for as long as you stick to lists. However the ability to do anything complicated with LISP code is simply not there because LISP code loses type info, which is extremely important for anything you’d want to do with code, like all kinds of non-superficial transformations and refactorings. So here are some facts given as examples: (1) LISP code does not make the job of IDE authors easier; just ask the authors themselves (2) in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach; for example .NET’s LINQ cannot be expressed in LISP, not unless you add a static type system, but at that point you’re no longer talking about LISP ;-) In my opinion LISP has been vastly romanticized, yet it doesn’t live up to expectations. It falls short in every department, from functional programming, to available tooling, to the great enlightenment people are supposed to experience once they learn it. Whereas Haskell really does live up to expectations, being one of those very few ecosystems that does make developers better, at this point being the lingua franca of FP.
- ced 8y ago
  You make an interesting point about types, but > (2) in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach I've seen and built tons of exotic stuff with macros. On Lisp builds a Prolog compiler if you want a specific example. Your point about types makes me curious about LINQ. Brings to mind Julia's generated functions.
- billsix 8y ago
  > in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach; I wrote a compile-time test framework in 7 lines of Gambit Scheme code https://github.com/billsix/bug/blob/master/README.md https://github.com/billsix/bug/blob/master/README.md
- na85 8y ago
  >for example .NET’s LINQ cannot be expressed in LISP, not unless you add a static type system Doesn't that imply that Lisp, sans-static typing, is not Turing-Complete? Surely that is not the case.
  - nine_k 8y ago
    A Turing machine is Turing-complete. Good luck expressing LINQ syntax, or Lisp syntax, or even Basic-80 syntax on it. Syntax is important, it's a tool of thought.
    - na85 8y ago
      I understood the post to which I replied to be arguing that LINQ could not be expressed in Lisp, not that Lisp doesn't have the correct syntax. Surely you can write LINQ in any Turing-complete language.
      - crabmusket 8y ago
        I guess the question you are begging is: how far can Lisp-LINQ go from the syntax, semantics, and ergonomics of C#'s LINQ before you stop calling it LINQ? Turing completeness doesn't describe expressivity of source code, as far as I understand it - it describes the ability to produce a desired outcome. So yes, you can perform the same operations LINQ allows, in Lisp or any other Turing-complete language. But can you do it while giving the programmer the same (or a similar enough) experience? From the .NET docs: > Language-integrated query allows query expressions to benefit from the rich metadata, compile-time syntax checking, static typing and IntelliSense that was previously available only to imperative code. Language-integrated query also allows a single general purpose declarative query facility to be applied to all in-memory information, not just information from external sources. Now, to be fair, I'm not sure you can express all that in Haskell either. And it could be reasonable to argue that a few of those benefits (e.g. intellisense) just _haven't_ been done for Lisp, not necessarily that they _can't_ be done.
ainar-g 8y ago
>I don't see Haskell as uber language. If I want super correct code, speed and I'm okay with using a more complex language, then there is Rust – which is probably more correct than Haskell and faster, too. But it doesn't even have Higher Kinded Types! What a disgrace. /s I do wonder, what would OP, or any seasoned Haskell programmer, think about Rust. Would they consider it strange? Primitive? Too mainstream?
- deleted 8y ago
  [deleted]
- cloudhead 8y ago
  Rust doesn't really have a way to control for effects in functions. The type of the function doesn't define what the function can do. This I think is the biggest problem coming from haskell.
  - MrBuddyCasino 8y ago
    How does that work in Haskell, is it the pure/impure dichotomy regarding I/O that is encoded in the type signature? Because one could argue that Rusts ownership is a primitive version of that, but yielding most of the gains ("if it compiles, it works").
    - lomnakkus 8y ago
      Kind of, but not really. The combination of type classes (traits in Rust) and HKTs in Haskell mean that you can quite easily restrict a function to only be able to do a subset of what's possible in "the world". A trivial example would be foo :: Logger m => Int -> m () where Logger is a type class (trait in Rust-speak) which implements the Monad type class (thus allowing 'imperative'-style programming), but also has a "log" method which allows the program to emit a string to the log. The thing is that given the restrictions of parametric polymorphism that function 'foo' has to work for any Logger instance we give it, so it absolutely cannot do anything other than pure computation or invoking the "log" method. It cannot do any other side effects at all. So, it's not "pure", but it's also much more restricted than "impure". That's a very powerful tool for modeling highly effectful systems.
paidleaf 8y ago
I find that haskell is great to learn about functional programming and programming ideas, but to get things done, I stick to imperative or OO languages. Could be that I learned CS with C/C++/Java and work with C#/C++. So I just stick to what I'm familiar with.
donut2d 8y ago
I learned Haskell and then moved to OCaml and found it to be a much more practical language. Haven’t tried Lisp yet, but it’s quickly moving to the top of my list.
- lomnakkus 8y ago
  Oddly enough it was the opposite for me. I think I might have given up on Haskell if I hadn't learned O'Caml first. It's been 15 or so years, so I'm sort of guessing at this point, but I think the combined cognitive effort of going from typical imperative languages to Haskell and the whole algebraic data types+pattern matching thing might have broken me. I found Haskell much more practical because it makes refactoring truly easy, but I'm very "programmer-centric". I mean 'refactoring' in the strict sense of preserving absolutely all the existing behavior, including side effects. That is extremely difficult if you can have side effects all over the place. (Strictness obviously helps a lot, but it also has downsides.) Btw, given your experience and if you want to try Lisp seriously I'd probably recommend Racket, Typed Racket and their Turnstile experiment(?).
  - fiddlerwoaroof 8y ago
    Or, you could go with Hackett, which is a Haskell-like language implemented in Racket: https://github.com/lexi-lambda/hackett https://github.com/lexi-lambda/hackett
  - donut2d 8y ago
    You’re right about the advantages of Haskell regarding side-effect strictness and refactoring. That’s a huge win. I think now that I have significant experience with OCaml it’d make going back to Haskell easier for me. That’s probably something I’ll do. But right now I’m finding OCaml has been great for me. I’ll look into Racket and friends. Thanks
- rainygold 8y ago
  How do you find OCaml to be a more practical language? Interested in trying it out.
lomnakkus 8y ago
> My problem with Haskell is that it is not pragmatic and the reason I stopped using it. I find it extremely pragmatic, but perhaps not in the way most people use the word. It's pragmatic about the abilities of programmers to get every single detail right all of the time, i.e. it discards that notion entirely. We will not get things right enough of the time and so the language must support and help you. This goes all the way from simple static typing to enforcing Purity of Essence, I mean, Functions. If you don't care about managing side effects you can always just write everything in IO and slap a "pure" here or there. Haskell's actually also a pretty good imperative programming language, IME.
Buttons840 8y ago
> Haskell code can be totally unreadable, using concepts which take weeks to learn – which is... not so great. I don't think it's fair to say something is "not so great" because it takes more than a few weeks to learn. That logic leads to a sad place. You suggest using Lisp and maybe Rust, but both of those languages would probably take more than a few weeks to learn. Also, you could just use the IO type on every function in Haskell, and thus eliminate the separation between pure and impure code. You'd only have to a type a few extra characters here and there, which isn't ideal, but is acceptable while being pragmatic. Haskell has had a default package manager, called "cabal", for many (15+ ?) years.
rs86 8y ago
Agree that haskell sometimes is not that practical but it does make you a better programmer.

bad_user 8y ago

The ability to come up with new syntax in LISP is in my opinion vastly overrated. Yes, LISP code can be easily parsed for as long as you stick to lists. However the ability to do anything complicated with LISP code is simply not there because LISP code loses type info, which is extremely important for anything you’d want to do with code, like all kinds of non-superficial transformations and refactorings. So here are some facts given as examples: (1) LISP code does not make the job of IDE authors easier; just ask the authors themselves (2) in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach; for example .NET’s LINQ cannot be expressed in LISP, not unless you add a static type system, but at that point you’re no longer talking about LISP ;-) In my opinion LISP has been vastly romanticized, yet it doesn’t live up to expectations. It falls short in every department, from functional programming, to available tooling, to the great enlightenment people are supposed to experience once they learn it. Whereas Haskell really does live up to expectations, being one of those very few ecosystems that does make developers better, at this point being the lingua franca of FP.

ced 8y ago
You make an interesting point about types, but > (2) in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach I've seen and built tons of exotic stuff with macros. On Lisp builds a Prolog compiler if you want a specific example. Your point about types makes me curious about LINQ. Brings to mind Julia's generated functions.
billsix 8y ago
> in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach; I wrote a compile-time test framework in 7 lines of Gambit Scheme code https://github.com/billsix/bug/blob/master/README.md https://github.com/billsix/bug/blob/master/README.md
na85 8y ago
>for example .NET’s LINQ cannot be expressed in LISP, not unless you add a static type system Doesn't that imply that Lisp, sans-static typing, is not Turing-Complete? Surely that is not the case.
- nine_k 8y ago
  A Turing machine is Turing-complete. Good luck expressing LINQ syntax, or Lisp syntax, or even Basic-80 syntax on it. Syntax is important, it's a tool of thought.
  - na85 8y ago
    I understood the post to which I replied to be arguing that LINQ could not be expressed in Lisp, not that Lisp doesn't have the correct syntax. Surely you can write LINQ in any Turing-complete language.
    - crabmusket 8y ago
      I guess the question you are begging is: how far can Lisp-LINQ go from the syntax, semantics, and ergonomics of C#'s LINQ before you stop calling it LINQ? Turing completeness doesn't describe expressivity of source code, as far as I understand it - it describes the ability to produce a desired outcome. So yes, you can perform the same operations LINQ allows, in Lisp or any other Turing-complete language. But can you do it while giving the programmer the same (or a similar enough) experience? From the .NET docs: > Language-integrated query allows query expressions to benefit from the rich metadata, compile-time syntax checking, static typing and IntelliSense that was previously available only to imperative code. Language-integrated query also allows a single general purpose declarative query facility to be applied to all in-memory information, not just information from external sources. Now, to be fair, I'm not sure you can express all that in Haskell either. And it could be reasonable to argue that a few of those benefits (e.g. intellisense) just _haven't_ been done for Lisp, not necessarily that they _can't_ be done.

ainar-g 8y ago

>I don't see Haskell as uber language. If I want super correct code, speed and I'm okay with using a more complex language, then there is Rust – which is probably more correct than Haskell and faster, too. But it doesn't even have Higher Kinded Types! What a disgrace. /s I do wonder, what would OP, or any seasoned Haskell programmer, think about Rust. Would they consider it strange? Primitive? Too mainstream?

deleted 8y ago
[deleted]
cloudhead 8y ago
Rust doesn't really have a way to control for effects in functions. The type of the function doesn't define what the function can do. This I think is the biggest problem coming from haskell.
- MrBuddyCasino 8y ago
  How does that work in Haskell, is it the pure/impure dichotomy regarding I/O that is encoded in the type signature? Because one could argue that Rusts ownership is a primitive version of that, but yielding most of the gains ("if it compiles, it works").
  - lomnakkus 8y ago
    Kind of, but not really. The combination of type classes (traits in Rust) and HKTs in Haskell mean that you can quite easily restrict a function to only be able to do a subset of what's possible in "the world". A trivial example would be foo :: Logger m => Int -> m () where Logger is a type class (trait in Rust-speak) which implements the Monad type class (thus allowing 'imperative'-style programming), but also has a "log" method which allows the program to emit a string to the log. The thing is that given the restrictions of parametric polymorphism that function 'foo' has to work for any Logger instance we give it, so it absolutely cannot do anything other than pure computation or invoking the "log" method. It cannot do any other side effects at all. So, it's not "pure", but it's also much more restricted than "impure". That's a very powerful tool for modeling highly effectful systems.

paidleaf 8y ago

I find that haskell is great to learn about functional programming and programming ideas, but to get things done, I stick to imperative or OO languages. Could be that I learned CS with C/C++/Java and work with C#/C++. So I just stick to what I'm familiar with.

donut2d 8y ago

I learned Haskell and then moved to OCaml and found it to be a much more practical language. Haven’t tried Lisp yet, but it’s quickly moving to the top of my list.

lomnakkus 8y ago
Oddly enough it was the opposite for me. I think I might have given up on Haskell if I hadn't learned O'Caml first. It's been 15 or so years, so I'm sort of guessing at this point, but I think the combined cognitive effort of going from typical imperative languages to Haskell and the whole algebraic data types+pattern matching thing might have broken me. I found Haskell much more practical because it makes refactoring truly easy, but I'm very "programmer-centric". I mean 'refactoring' in the strict sense of preserving absolutely all the existing behavior, including side effects. That is extremely difficult if you can have side effects all over the place. (Strictness obviously helps a lot, but it also has downsides.) Btw, given your experience and if you want to try Lisp seriously I'd probably recommend Racket, Typed Racket and their Turnstile experiment(?).
- fiddlerwoaroof 8y ago
  Or, you could go with Hackett, which is a Haskell-like language implemented in Racket: https://github.com/lexi-lambda/hackett https://github.com/lexi-lambda/hackett
- donut2d 8y ago
  You’re right about the advantages of Haskell regarding side-effect strictness and refactoring. That’s a huge win. I think now that I have significant experience with OCaml it’d make going back to Haskell easier for me. That’s probably something I’ll do. But right now I’m finding OCaml has been great for me. I’ll look into Racket and friends. Thanks
rainygold 8y ago
How do you find OCaml to be a more practical language? Interested in trying it out.

lomnakkus 8y ago

> My problem with Haskell is that it is not pragmatic and the reason I stopped using it. I find it extremely pragmatic, but perhaps not in the way most people use the word. It's pragmatic about the abilities of programmers to get every single detail right all of the time, i.e. it discards that notion entirely. We will not get things right enough of the time and so the language must support and help you. This goes all the way from simple static typing to enforcing Purity of Essence, I mean, Functions. If you don't care about managing side effects you can always just write everything in IO and slap a "pure" here or there. Haskell's actually also a pretty good imperative programming language, IME.

Buttons840 8y ago

> Haskell code can be totally unreadable, using concepts which take weeks to learn – which is... not so great. I don't think it's fair to say something is "not so great" because it takes more than a few weeks to learn. That logic leads to a sad place. You suggest using Lisp and maybe Rust, but both of those languages would probably take more than a few weeks to learn. Also, you could just use the IO type on every function in Haskell, and thus eliminate the separation between pure and impure code. You'd only have to a type a few extra characters here and there, which isn't ideal, but is acceptable while being pragmatic. Haskell has had a default package manager, called "cabal", for many (15+ ?) years.

rs86 8y ago

Agree that haskell sometimes is not that practical but it does make you a better programmer.