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

181–190 of 297 posts

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

#181

Post by sesuximo »

aardvark1 wrote: post #155

This company looks to be a team of three (probably very smart) engineers who build cool custom software for likely relatively small clients. The software is likely only supported and modified by them. In that scenario something like Haskell makes sense - however once you need to scale your engineering footprint beyond 5-10 people it becomes virtually impossible to rationalize using a niche language like Haskell.

Also unclear how long they’ve been doing this... I’m unable to find any info about provide projects other than very high level blog style stuff

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

#182

Post by srean »

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.

You can think of the compiler for a statically typed language doing exactly that at runtime for a subset of potential errors -- the type errors. Some people claim that they never make them and they may well be correct. I do commit such errors so compiler is a friend, but a pedantic friend.

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

#183

Post by wassenaar10 »

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

> getting into a Python code base was the most difficult one, because of the lack of typed method parameters

Yup, this is probably my main issue with Python. I love writing it when I'm working on personal projects, having to read massive Python code bases at work feels unnecessarily tedious due to how much work you have to do sometimes just to find out the type of something.

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

#184

Post by magicalhippo »

uryga wrote: post #174
magicalhippo wrote: post #145

Earlier quoted context omitted.

Ok, so you make pure functions and turn them dirty, so to speak. Makes sense. In our case, almost all core code depends on various parameters, which come from the database. For example, GB recently left the EU so everything involving GB is now processed under different rules, except old stuff which has to be processed under the old rules. Thus being part of EU or not is a date-dependent database query (it already was…

> In the case above, I'd pass a function which maps a (pure) date and string into a (pure) bool, to test for EU membership. i doubt you could make (or really, even want to make) `checkEUMembership` pure, I'm guessing it'd involve a DB lookup of some kind. in general, you can't always "pull out all the IO" into an only-pure-logic "core"; like if you want to look up one thing and then look up another thing based on the…

> i doubt you could make (or really, even want to make) `checkEUMembership` pure, I'm guessing it'd involve a DB lookup of some kind

Well that was kinda the root of my question. The core logic doesn't really care as such, as long as it could determine EU membership somehow, but actual code would have to use a DB lookup[1].

That of course spirals back to what would that really buy you. You'd write code pretending it's pure while it really isn't. I can see part of the appeal, but I can do that in my current language.

Of course I don't get an error if I do something silly in the middle of some otherwise "pure" module, so there's that.

Anyway, illuminating. I enjoy thinking about these things and challenging my self-taught ways. Thank you all for your contributions, much appreciated!

[1]: An aside but, due to an error on the government side, GB is part of EU today as far as one of their validation checks is concerned. So today only we have to pretend along, for just that one field. This stuff is fun!

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

#185

Post by jjice »

Haskell seems extremely neat, and I do like the ML family for compiler development, but Haskell just seems like such a steep learning curve. The amount of operators I've seen boggles my mind, are they user defined? Is there a good way to learn Haskell that preferably skips over some common functional concepts?

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

#186

Post by ivanbakel »

aardvark1 wrote: post #155

This company looks to be a team of three (probably very smart) engineers who build cool custom software for likely relatively small clients. The software is likely only supported and modified by them. In that scenario something like Haskell makes sense - however once you need to scale your engineering footprint beyond 5-10 people it becomes virtually impossible to rationalize using a niche language like Haskell.

What is that claim based on? Plenty of companies use Haskell to great success scaling to well beyond 10 people. It may be a niche language, but in a remote-working world, and with a truly massive number of developers in the workforce, there still end up being a sizeable number of professional Haskell developers available to most companies.

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

#188

Post by lallysingh »

jjice wrote: post #185

Haskell seems extremely neat, and I do like the ML family for compiler development, but Haskell just seems like such a steep learning curve. The amount of operators I've seen boggles my mind, are they user defined? Is there a good way to learn Haskell that preferably skips over some common functional concepts?

I'll put the learning curve around the same level as C++, with the qualifier that most of what you learn aren't parts of the language, but patterns and formalisms you can use in any language.

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

#189

Post by lostcolony »

jhayward wrote: post #158
Rompect wrote: post #69

Earlier quoted context omitted.

In contrast, Rust's compiler sometimes gives suggestions for changes which can often just be copied.

I'm always puzzled by people who see this as somehow a good thing. If the Rust compiler can figure out what the type should be, why doesn't it just do the cross-function inference, and leave the complicated nested implications which only obscure the intent and effect out of it? If having the programmer specify types is an important check on the correctness of the code that is written, how is blindly copying, without…

Because the computer being right 90% of the time when something is ambiguous doesn't preclude the programmer from understanding it (while still providing them a best guess at their intent for those times they don't), but DOES mean that the program doesn't assume the wrong thing that remaining 10%.

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

#190

Post by dkersten »

pjmlp wrote: post #104
corty wrote: post #26

Earlier quoted context omitted.

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.

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 we might think.

The talks were by Jason Turner, who has an ARM emulator implemented entirely as constexprs and a test suite that runs at compile time (so if it compiled, the tests passed). Obviously for actually interacting with it, its not running at compile time, but the logic has the ability to run at compile time, which is pretty cool.

Post reply on HN