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

141–150 of 297 posts

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

#141

Post by willtim »

sesm wrote: post #124
willtim wrote: post #77

Earlier quoted context omitted.

> 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. It's about quality of life and picking the right tool for the job. There are some problems I can solve in Haskell, that I simply could not solve in Java, it would be too hard and too much work. Java is a simple language and therefore it's much easier to r…

Java is much easier to reason about the performance and space usage because it's a language with strict evaluation. Most programming languages use strict evaluation, including OCaml, F# and Scala.

> because it's a language with strict evaluation

But that is not the only reason. Haskell does much more aggressive optimisations than Java (and Scala, OCaml, F#). A large part of Haskell's space-usage reasoning issues come from the combination of lazy evaluation and these aggressive optimisations. Java and Scala code can contain plenty of deferred evaluation too, for example iterators, but the compilers simply don't do (and cannot do) such aggressive optimisations. Of course, this also means that much pure functional Scala/Java code can be poorly performing.

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

#142

Post by vp8989 »

fooyc wrote: post #92

> Haskell programs have stellar performance, leading to faster applications and lower hardware costs [...] PHP $244 [...] Haskell $15 This is overlooking the cost of developers, which greatly outweights the hardware's unless you are Facebook.

No it isn't, it's a simple matter of fact statement that running code on runtime A appeared to be cheaper in terms of hardware costs than runtime B.

The "overlooking" part you filled in yourself in bad faith and bad reading comprehension, as the author actually does acknowledge that the observed hardware savings are small compared to the cost of hiring programmers.

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

#143

Post by weego »

jamil7 wrote: post #75
tome wrote: post #55

Earlier quoted context omitted.

Would you say that you've engaged in good faith with the point the author was trying to make?

Eh, I kind of agree with the parent comment. The author didn't bring up any compelling points that couldn't be found in other modern languages (granted these likely borrowed from Haskell). As an outsider to Haskell I was hoping for some more concrete use cases for picking the language.

Honestly there are no compelling arguments for picking Haskell over other languages in the same domain.

Limited open-source to leverage, incredibly limited and costly hiring opportunities, not that great tooling and integrations.

Any upside you can sell from a pure programming point of view (there are some very valid ones) pale in comparison to the negatives it brings to your overall business.

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

#144

Post by johnday »

magicalhippo wrote: post #116
ToJans wrote: post #60

Earlier quoted context omitted.

Haskell functions are pure, which means they can only access/use what is in their parameters, so unless you pass in some extra context (typically using a monad or an effect), you do not have access to the "outside world".

You can bind parameters though in Haskell, no? I'm used to Boost.Bind and similar, so was thinking a scenario where you bind the database connection parameter and pass the resulting function to something else. As the sibling pointed out though, I now get that the result would be "tainted" so to speak.

A database connection would operate either in IO (the generic "i am now talking to an unreliable outside world") monad, or some more specific monad.

In this case you can think of a monad a bit like a computational context. If one is not present, you simply cannot[^1] instruct a Haskell program to perform those operations in a type safe way even if you give it a valid database connection identifier.

[1] Well, you can, but if you do you're explicitly taking away all the safeguards that Haskell introduces, and it would never pass code review.

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

#145

Post by magicalhippo »

Twisol wrote: post #131
magicalhippo wrote: post #112

Earlier quoted context omitted.

And there's no way to get rid of the IO then, presumably (I mean otherwise I could have just used that as a wrapper). edit: So at work, just about every value depends directly or indirectly on stuff that comes from files or from the database. So would they all have to be wrapped by IO?

In Haskell, you often build pure transformations, and then lift them into an effectful context. If I have a function `String -> [String]`, say to parse a line of CSV into its elements, I can lift that to `IO String -> IO [String]` using the IO monad's `fmap`. And then I can compose it with something hypothetical like `readLine :: File -> IO String`, which actually reads the line. The core logic of a program often doe…

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, not the first time a country's EU status has changed).

So if I get your explanation correctly, I'd code the core logic as if these parameters were pure, side-effect free, which would make the core logic side-effect free. 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'd then turn that whole thing dirty via the IO thingy, passing "IO parameters" and receiving "IO results", so I can pass it my EU test function which does a database query.

edit: And I presume my "dirty" database-connecting function can also mutate things, so it can do caching. Don't want to hit that database too often.

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

#146

Post by WraithM »

js8 wrote: post #14
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…

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 appreciate that you wrote that you "feel" more productive with python. I 100% agree with this feeling at most scales of code size, and the feeling matches reality at the small scale. However, I've found that this feeling of productivity doesn't match reality in the large. I use Haskell for programming in the large despite this feeling of unproductivity, because in fact, I am way more productive.

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

#147

Post by gameswithgo »

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

there are controlled studies supporting this idea the function parameters not having types slows down productivity

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

#148

Post by jcelerier »

mehrdadn wrote: post #128
msla wrote: post #117

Earlier quoted context omitted.

Shifting topics a bit, typedefs don't allow me to write generic code. Templates do, but templates bring in their own problems, in addition to not being expressive in the right ways: I can have an array of T, but I can't specify that T is Numeric? The fact C++ doesn't have Numeric but instead has int and long and unsigned and long long and float and double all off on their own is another problem: The compiler knows en…

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…

the C++ 20 version can be simplified a bit to:

    Numeric auto twice(Numeric auto x)
    { return x + x; }

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

#149

Post by sfg »

Guthur wrote: post #45
dan-robertson wrote: post #39

Earlier quoted context omitted.

I feel like it probably isn’t worthwhile to litigate the merits of static typing every time there is a HN post that’s vaguely adjacent to the topic. For the amount people care about it, there isn’t much evidence in either direction. And most studies that do exist are limited to small programs typically written by novices. Yale’s Singapore campus are going to be running two instances of the same course in parallel soo…

It would if python actually encouraged runtime coding. In my opinion dynamic programmers need to embrace the runtime environment and use it as part of their development methodology. Unfortunately most popular dynamic languages have woeful runtime environments.

So, Common Lisp and Smalltalk?

Any others?

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

#150

Post by cjfd »

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 am all for high test coverage. One should not underestimate the effort in that, though. Some time ago I covered some two thousand lines of code completely in tests. As in, all code paths, checking all side effects. Kind of an effort in the spirit of "dealing effectivly with legacy code" by Michael Feathers. They were quite non-trivial and it took me about two months. Doing such a thing may not always be feasible. Also if code is written by others they may have covered fewer code paths in tests than one would have liked. A type checker will check all code paths but the tests that your predecessor failed to write are not checking anything.
Post reply on HN