Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell is our first choice for building production software systems

foxhound.systems

Post reply on HN
Print view View original

101–110 of 297 posts

Re: Haskell is our first choice for building production software systems

#101

Post by hardwaresofton »

johndoe42377 wrote: post #85

Unfortunately, the Haskell ecosystem has been ruined (well, almost) by unnecessary, redundant abstractions and narcissistic idiots who pushes them. I recently tried to compile haskell-language-server and stack from sources. 157 and 168 (or something) dependencies, full of redundant esoteric bullshit, compat packages, lifted crap, etc. It is even worse than J2EE where it was the same redundant wrapping and indirection…

This article might be a bit overeager and overzealous, but how you use haskell is up to you -- don't use those underlying packages that disgust you if you don't like them. Haskell offers benefit at every level of abstraction. There are many ways to write Haskell and you do not need a bunch of the higher level stuff. 99% of the time you are just fine with the data modeling (simple Algebraic Data Types) and type classes, along with a cursory understanding of monads via "do" notation.

This comment reads like someone seeing the worst of J2EE, and going back to C++. I'd characterize haskell as having the type system that Java wishes it did.

Why are you trying to judge how haskell should be written for your use case by looking at haskell-language-server, stack, and xmonad? Those are the domains of haskell experts -- one is a language server, the other is one of the pre-eminent build tools, and the other is tiling manager.... Are any of those your use-case?

There are real problems with haskell, and forcing you into complexity is not one of them -- a steep learning curve (for certain concepts), hard to debug space leaks, and a relatively small ecosystem are the biggest issues.

Re: Haskell is our first choice for building production software systems

#102

Post by mehrdadn »

nicoburns wrote: post #89
mehrdadn wrote: post #78

Earlier quoted context omitted.

> You have to repeat the type information, a lot. Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

I thought the complaint was about the logic duplication, not the extra keystrokes. If you want type inference you already have auto. If you want to minimize your keystrokes, you're using the wrong language to begin with, whether there's type inference or not. C++ is designed for writing software robustly, not quickly. (<-- This is not a trivial or obvious statement btw. It took me several years to grasp this. And I viewed C++ from an entirely different perspective when it finally sunk in for me that I would appreciate C++ much more if I decided to make minimizing keystrokes a non-goal.)

Re: Haskell is our first choice for building production software systems

#103

Post by kreetx »

dmitriid wrote: post #76
kreetx wrote: post #48

Earlier quoted context omitted.

To clarify the sibling, a signature of `Int -> Int -> Bool` can't do any IO (so no connecting to databases, reading/writing files, network requests), so it does tell you a lot about a function. It can manipulate strings, decode JSON, but both of these are either (immutable) values from enclosing scope, or created within the function. But since they can't be output anywhere (because no IO) then they don't matter. EDIT…

> To clarify the sibling, a signature of `Int -> Int -> Bool` can't do any IO (so no connecting to databases, reading/writing files, network requests), so it does tell you a lot about a function. It doesn't help if it's `Int -> Int -> IO Bool`, for example. Well, it does do IO, but other than that, who knows. Perhaps it reformats the disc while CPU is idle :) My main point though is that the article does a very poor…

It's the fact that it is `Int -> Int -> Bool` that ensures you that the function doesn't do any random thing (like doing something on the database). Combining non-IO capable functions is quite helpful in reasoning about programs. I.e if the function has `IO` in the result type then exactly - "who knows". But with the fact that it doesn't, you do know that it doesn't do anything other than return the bool.

Re: Haskell is our first choice for building production software systems

#104

Post by pjmlp »

corty wrote: post #26
jcelerier wrote: post #2

> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java…

Annoyance about C++ errors isn't only about the error occuring. With me, it is predominantly about the utter unusability of the error messages. C++ has postprocessors you can use to get your 20 page STL errors down to a few lines just by reversing the expansion the compiler did to show you mere mortal something that you might recognize as your code instead of template-cthulhu. Haskell has such situations as well, but…

Not only do modern compilers give better error messages (with room for improvement still), it is possible to make use of enable_if and if constexpr/static_assert to give proper error messages for templates, and when C++20 gets widespread enough, concepts.

Re: Haskell is our first choice for building production software systems

#105

Post by dagw »

rednum wrote: post #87
egwor wrote: post #50

Earlier quoted context omitted.

Quite a few universities in the UK teach haskell as a way to start everyone on a level playing field and to introduce various concepts.

Similar situation in Poland. Also my anecdotal experience is that Haskell classes are not considered to be the most difficult, rather they are somewhere in the middle.

The University I went to in Sweden used Haskell for its intro classes. Intermediate classes where taught in Java.

Re: Haskell is our first choice for building production software systems

#106

Post by oblio »

FlyingSnake wrote: post #70
IfOnlyYouKnew wrote: post #23

No, sorry, it has very little to do with technology. There's at least a dozen languages you could have chosen, and that others have chosen for any given use case. within some bounds, it makes very little difference.[0] The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that f…

> The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits. I think you're projecting too much on them. They found Haskell performant and are promoting it, I don't see any problem with it. How is any different from all the Rust evangelism HN sees all the time?

I think his point is that there are N languages that are performant and they could have probably chosen any of them to achieve their goal, so the choice is primarily aesthetic.

Re: Haskell is our first choice for building production software systems

#107

Post by hardwaresofton »

Haskell is an excellent language, and you are free to choose not to drown yourself in the most complex uses of it.

Haskell has the type system Java wishes it did, and half of the reason languages like Rust are interesting is because they've learned from Haskell (which is the point of Haskell, a research langage, though it happens to also be a pretty darn good language for building practical things). Simple basic data types like `Maybe t` and `Either l r` are such a revelation that you wonder how you lived without them.

I've shared this anecdote before, but Option in Java is an example of the blub paradox[0], and discovering Haskell and finding out about Algebraic Data Types (ADTs) and the Maybe type cured my blub. The crux was this: Options seems to "infect" any codebase you use it on, because you realize that anything can fail and be null -- living in java land made it seem like it was out of place it's actually Option that is right -- if you allow nullable types in your code base, or you do operations that can fail, properly representing that failure is the right decision.

Without over stating some of the best features of Haskell are:

- Compile time type checking (this cannot be understated) and non-nullable types

- Expressive and simple data type creation via `data`, `type`

- An excellent system for attaching functionality and composing functionality to data types via `typeclass`es and `Constraint`s.

- An emphasis on errors as values (unfortunately exceptions are in the language too, but you can't really stop them from existing)

- Forced delineation between code with side-effects and code without (this results in some complexity if you come from a world with side-effects everywhere and no control)

- Fantastic runtime system with good support for concurrency, parallelism and shared memory management.

- Very easy refactoring (if you're not adding any complexity/abstraction) because you can just change what you want and let the compiler guide you the rest of the way.

Haskell has it's warts (hard to debug space leaks, relatively small ecosystem, the ability to drown yourself and your team in abstraction), but it's just about the most production-ready research language I've seen.

Whether or not you like it, the likelihood it's already improved your life in whatever language you're using is very high.

Re: Haskell is our first choice for building production software systems

#108

Post by oblio »

mjburgess wrote: post #31
st1x7 wrote: post #11

Earlier quoted context omitted.

I don't think that it's wise to sabotage your own future and productivity as a company just so you can pave the way for some language to become more popular.

It isn't, of course. But the crowd of other people want you to do that. It's the role of applause (and in your case, downvotes). The crowd throws cheap adulation at individuals who act against their own interests.

The peanut gallery :-))

Re: Haskell is our first choice for building production software systems

#109

Post by UweSchmidt »

nicoburns wrote: post #89
mehrdadn wrote: post #78

Earlier quoted context omitted.

> You have to repeat the type information, a lot. Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up?

I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.

Re: Haskell is our first choice for building production software systems

#110

Post by Kototama »

Biggest problem I had with Haskell was once you know the language you also need to learn a pile of extensions that any serious project is using. Also there is a tendency in the community to always look for the "best" (abstract) solution. It makes the whole ecosystem fast changing.

I would prefer a more stable platform designed for engineers , something like Clojure but with types. Ocaml has a small community and Scala brings unnecessary complexity with its support for OOP.

Post reply on HN