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

191–200 of 297 posts

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

#191

Post by neutronicus »

KingOfCoders wrote: post #21
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…

I've joined several companies, and getting into a Python code base was the most difficult one, because of the lack of typed method parameters. It was easier with Java and better still with Scala - same for Typescript vs. Javascript. I would be interested, is your Python experience green field or joining a large project? (just wanting to know, not implying anything on your part).

I worked on a large-ish C++/Python codebase and touching the Python parts was always extremely frustrating for me.

The lack of .h files alone is a huge grievance for me - I had to scroll past definitions even to know names and arities of class methods, read constructors to know what's in class members.

SciPy was nice enough for turning data into a picture, though.

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

#192

Post by dkersten »

msla wrote: post #179
mehrdadn wrote: post #128

Earlier quoted context omitted.

You're asking for the impossible. What you want is precisely what templates are, but you also want them to not be "templates" for... some bizarre reason. > I can have an array of T, but I can't specify that T is Numeric? Sure you can. If you have C++20 concepts: template concept Numeric = std::integral || std::floating_point ; template T twice(T x) { return x + x; } Or if you're on a C++11 compiler: template typename…

Bah. Leave it to the latest versions of C++ to show me up.

That's the point though, isn't it? To improve on areas that were lacking in older versions. It can be hard to keep up, though!

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

#193

Post by Areading314 »

It is absolute nonsense to say that using Haskell will improve productivity or maintainability. There are problems like bad libraries, complicated performance profiles, virtually no developer adoption, limited ghc build targets, package management, lack of tooling, slow compile times. Choosing Haskell is likely a terrible choice despite the type system, which seems to be its only advantage.

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

#194

Post by st1x7 »

vp8989 wrote: post #168
st1x7 wrote: post #9

Earlier quoted context omitted.

I feel like this isn't discussed enough. I can't comment on the technical merits of Haskell but growing an organization and replacing engineers is so much more difficult when you're using tools that aren't mainstream.

Optimizing for worker fungibility, in a vacuum, seems like a -EV "playing not to lose" strategy. It's understandable that this line of thinking is common though. I also believe that to be the case as an employee. Ie, being a generalist is probably -EV for your career but it feels safer so it's kind of a contrarian position to say "be a specialist".

> Optimizing for worker fungibility, in a vacuum, seems like a -EV "playing not to lose" strategy.

That's why you don't optimise for it in a vacuum. You weigh the potential benefits of switching to Haskell versus the additional cost of maintaining/growing a Haskell team.

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

#195

Post by dkersten »

pansa2 wrote: post #56
cjfd wrote: post #38

Earlier quoted context omitted.

The thing is, though, that you mostly only get errors for code that is actually executed. So, your program is only fully type checked when all code paths are executed. In the case of python one can ameliorate this situation a bit by using mypy. At my job I see very often code being broken because, e.g., the signature of a function was changed but not in all places and so on. Now somebody will say that the IDE can sol…

> your program is only fully type checked when all code paths are executed. The solution to this is to make sure that, during testing, all code paths are executed. And that’s something you should be doing anyway, to find bugs that aren’t type errors.

I've worked with Python codebases that had very extensive test suites and I've still encountered many cases of bugs slipping through that a static type check would have caught. Its really hard to make sure tests are fully comprehensive. About the best you could do is generative property-based tests, but then the feedback loop is not great as it may take minutes, hours, days or weeks for a particular problem case to be generated, while the static check would have caught it at compile time or even interactively in your IDE.

I don't hate dynamic languages, but this is a pretty major weak spot for them, in my personal opinion, and one that's bitten me a number of times.

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

#196

Post by pjmlp »

dkersten wrote: post #190
pjmlp wrote: post #104

Earlier quoted context omitted.

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.

Modern clang (usually, there are edge cases) gives pretty good error messages over all. And like you point out, if you use constexpr you get even better messages. Hell, I watched some cppcon videos over the weekend and learned that clang can even detect out of scope access of temporaries when in a constexpr (but not otherwise sadly), and also that in many cases, a lot more of a program can probably be constexpr than…

Jason Turner has very cool talks, check the C64 one if you still haven't watched it.

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

#197

Post by bryal »

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…

> narcissistic idiots

Right back at ya

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

#198

Post by ashtonkem »

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…

Haskell error messages are far less verbose, but I find them hard to read. What makes it worse is that often the error message involves a lot of deeply nested types that were hidden from me before by library writers using an alias. So I’ve had a lot of “where did that come from?” moments.

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

#199

Post by dbattaglia »

gregorygoc wrote: post #49

I think most programmers nowadays face no interesting problems to solve. They crave for a mental challenge, but instead of looking for a job that requires solving hard engineering problems, they believe they can satisfy their mental needs with coding in “somewhat” hard language.

I think you make a valid point in general about coding professionally at most jobs, and I know I've fallen into this desire myself while working on endless CRUD apps over the years. That said, I do think the article brings up some good points about domain modeling. After becoming somewhat proficient in Scala I've found these same features (ADTs) mentioned in the article helpful for the important part of these boring CRUD apps: modeling data at the various application boundaries (API, domain layer, database layer, etc). I now find using weaker type systems and/or imperative code to be either more error prone or more verbose (due to validation + extra tests).

Of course there are other parts of Scala, Haskell and similar that require more mental gymnastics than I'd like, such as composing asynchronous operations; flatMap and monad transformers may be "elegant" once you really understand them but damn is async/await easier to just write and move on with your life.

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

#200

Post by PietPtr »

414owen wrote: post #29
infinityplus1 wrote: post #8

Earlier quoted context omitted.

Someone has to take the first step to solve the chicken and egg problem. If there are jobs requiring Haskell, it might get more users.

I write Haskell professionally, and I can confidently say that there are plenty of jobs. Some large tech companies (eg. Facebook, GitHub, Twitter), quite a few banks, a lot of consultancy companies, and plenty of random companies I'd never heard of. It is quite difficult to get a first Haskell job though, because they mostly require production Haskell experience, so there's your chicken and egg problem.

Working with Haskell professionally sounds like a very interesting career path. Could you point to some resources to get better at the production Haskell skills that these companies are looking for? Perhaps gaining experience with projects which use Haskell in a similar way to the companies you mention could help with finding that first Haskell job.
Post reply on HN