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

81–90 of 297 posts

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

#81

Post by cies »

unicornmama wrote: post #3

Good luck scaling this to organization of 100+ engineers. You will soon learn the tradeoff between writing and reading code. And the stark realities of the dev hiring markets and the thing called a learning curve.

Not sure, but how big are the pools of Haskell-devs over at Galois, FPComplete, HKIO, Facebook, Tsuru Capital, Type Safe, ...?

Probably under 100, but not sure though.

I dont think this learning curve/hiring thing makes sense. Haskell can help attract smart dev, it makes refactoring so easy increased learning curve is off set.

I'd say it's harder to outsource, and there may not be as many libraries. Compare to Ruby/Rails for web, or Python for ML, and you have to write more by yourself in Haskell.

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

#82

Post by uryga »

magicalhippo wrote: post #52
betareduce wrote: post #43

Earlier quoted context omitted.

I guess you haven’t spend too much time with Haskell. Haskell types especially generic ones are way more expressive and limit your search quite a bit. The function Int -> Int -> Bool can not reach for a database or anything other than the two Ints it is given.

Why couldn't it be a function that queries a database, like answering "on invoice x, does line y exist"? Genuinely curious, not that familiar with Haskell, just thought you could use something like parameter binding or similar to construct functions like that.

if it has side-effects, it has to be something like

  Int -> Int -> IO Bool
otherwise the type checker won't let you perform any side-effecting operations

(btw Haskell's `IO Bool` would be spelled `IO` in C++/Java syntax)

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

#83

Post by unnouinceput »

Quote: "GHC, the most commonly used Haskell compiler, produces extremely fast executables, especially when compared against other languages commonly used for application development, such as PHP or Python"

Really? You comparing apples with oranges? Why not, if you're at the step of comparing compiled versus interpreted languages, compare it with Java too?

Now, do the same comparison versus C++, let's see who wins when talking about speed.

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

#84

Post by MaxBarraclough »

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…

I don't agree here. As someone who's only ever dabbled with Haskell, I found its error-messages pretty cryptic, no better than C++. Perhaps they make more sense to someone with significant Haskell experience.

For what it's worth, I believe modern C++ compilers give much better error messages than older ones.

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

#85

Post by johndoe42377 »

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, but brain-dead straightforward verbose crap.

To use Haskell correctly, like the classic xmonad and similar projects, requires discipline, knowledge and good taste for just right abstractions, like Go stdlib or Scala3 standard library.

Yes, it doubles development time, which must be spent on understanding anyway, but fast food fp code, full of redundant abstractions, is a worst nightmare to maintain.

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

#87

Post by rednum »

egwor wrote: post #50
erik_seaberg wrote: post #34

Earlier quoted context omitted.

Is is actually hard to hire for Haskell? You can’t just tell some random to learn it (because his head will explode), but my impression is that you’ll have candidates coming out of the woodwork who could never get away with using it before but always wanted to .

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.

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

#88

Post by wombat23 »

What I'd like to understand: When/why does one choose Haskell over other functional languages e.g. F# or OCaml?

It looks to me like they would satisfy the same points that the article makes.

Edit: just did a quick comparison of the last 2 SO developer surveys, and it looks like Haskell "replaced" F# in their popularity ranking last year.

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

#89

Post by nicoburns »

mehrdadn wrote: post #78
js8 wrote: post #14

Earlier quoted context omitted.

Actually, the reason why I found static typing annoying in the past (and why I felt more productive in Python) were the types are really low level (missing basic things like tuples) and lack of type inference. You have to repeat the type information, a lot. And also you have to declare lot of intermediate data structures. In Python, this became easier and one could focus on the data transformations, thinking about th…

> 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.

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

#90

Post by hardwaresofton »

kreetx wrote: post #44
fegu wrote: post #32

If you want to get a feel of the productivity using Haskell in production start with a simple CRUD app and use IHP ( https://ihp.digitallyinduced.com/ ) to build it. You will have something usable within a day - GUI and all. Then move further down the rabbit hole from there.

How about servant, and some popular js framework on top of that? IHP might be putting a lot of effort into the project, but the code generation part... I (personally) don't like that at all. And it's not common practice in haskell.

Second this -- Servant is one of the best examples of server-side haskell there is, and from what I understand IHP is relatively new in comparison (correct me if I'm wrong).

Servant is one of the best if not the best example of how haskell's higher level abstractions can benefit practical bread and butter programming (which making APIs is these days) tasks, and where type safety is a huge benefit.

Writing servant handlers can also feel mostly imperative depending on how much you use `do`.

Post reply on HN