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

171–180 of 297 posts

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

#171

Post by dmitriid »

Twisol wrote: post #125
dmitriid wrote: post #115

Earlier quoted context omitted.

I mean. Really. That's what people hang up on? The point for that particular gripe was this: "this allows a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does." Yes, IO tells that ... the function does some side effects. And that's it . If your type signature is `Int -> Int -> IO Bool`, it's just as useless as `Int -> Int -> Bool`, and requires yo…

You don't get any information from `IO _` functions, but that's the case with every mainstream language, where you have an implicit `IO` on every single function. The benefit is not in `IO` -- its that its absence on a function tells you that it is heavily restricted in what it can do. If you want to go the other way, you can concretely model the kinds of effects you need parts of your programs to do, and use that mo…

> You don't get any information from `IO _` functions, but that's the case with every mainstream language, where you have an implicit `IO` on every single function.

Indeed. And that's why I picked up on that particular point in the article that I'm criticising. The article chose to use those examples and those words and they don't show anything beyond what other mainstream languages have.

> If you want to go the other way, you can concretely model the kinds of effects you need parts of your programs to do, and use that model instead

Yes, you can. No, the article doesn't show that in any way. Just to remind you how I started my comment:

--- start quote ---

But this article goes out of its way to make the worst possible case for Haskell imaginable.

--- end quote ---

Does the article show "other models"? No. Does it even try and show how to reason about a function by looking at its type signature alone? Also, no. Would this article be laughed into oblivion had it been about any other language but Haskell? Yes, most likely.

> Effect modeling is a real shift in perspective.

Ah yes. Does the article talk about this? Does it show a single example of this? No.

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

#172

Post by dmitriid »

kreetx wrote: post #130
dmitriid wrote: post #115

Earlier quoted context omitted.

I mean. Really. That's what people hang up on? The point for that particular gripe was this: "this allows a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does." Yes, IO tells that ... the function does some side effects. And that's it . If your type signature is `Int -> Int -> IO Bool`, it's just as useless as `Int -> Int -> Bool`, and requires yo…

Having a distinction of if something does IO or not is quite important, and the fact that haskell has the ability to encode it in types is what other languages don't have. Secondly, IO is just one monad. You can build a more granular one where you can separate filesystem, network etc, and encode this into types (so you know at a glance). You can't do this in most other languages. What are the types of things that are…

Answered in a sibling comment: https://news.ycombinator.com/item?id=25729423

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

#173

Post by WraithM »

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.

I find it extremely frustrating that I have to use Nix to use this framework. We don't use Nix at my company, and we likely never will. I can easily incorporate packages from hackage into our codebase. I really don't want to have to vendor this project myself. Why make a great web framework and then create such a large constraint on who can use it reasonably?

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

#174

Post by uryga »

magicalhippo wrote: post #145
Twisol wrote: post #131

Earlier quoted context omitted.

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…

> 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 result of the first lookup. and that's okay!

i'm not going to write a whole monad tutorial, but using an `IO Foo` is kind of like using a `Promise`¹; you do stuff like this (in JS syntax):

  getX(...).then((x) =>
    getYForX(x).then((y) =>
      foo(x, y)
      // note - nested lambdas/closures, `x` is closed-over
    )
  )
"do-notation" lets you avoid callback hell, similarly to async/await.

---

¹ Unfortunately, JS's Promise#then mixes two things:

• "dirtying" a pure function:

  getNumberFromDB().then((x) => x*2)
which in Haskell would use

  fmap :: (a -> b) -> IO a -> IO
• piping the result into another side-effecting function:

  getNumberFromDB().then((x) => 
    getNameForNumberFromDB(x)
  )
which in Haskell would use the "bind" operator:

  (>>=) :: IO a -> (a -> IO b) -> IO b

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

#175

Post by arcturus17 »

dgb23 wrote: post #94
jrh206 wrote: post #10

Haskell is nice and all, but I'm not a huge fan of this take. I can't help but think that many of the arguments boil down to something like 'you can write types so that the compiler checks things for you' (not a quote), whilst the author disregarded the Java/C++ compiler as "an annoyance" (a quote). The rest of the article is mostly a comparison between Haskell and PHP/Python/JavaScript, and most laid out benefits bo…

The claims in the article sound weak, because they communicate in an informal and natural way. "Haskell's type system is more expressive than X and Y" is a strong claim and can be proven by showing that X and Y need to compose run-time workarounds for a given property that can be checked statically in Haskell. "Functional Programming reduces the surface area for Bugs" is a strong claim and can be proven by showing th…

> "Functional Programming reduces the surface area for Bugs" is a strong claim and can be proven

Is there really a formal proof or Software Engineering paper that proves this?

I was told this in my FP class in university, but it pretty much sold to me as gospel.

In practice I agree with the statement - I certainly feel there's an inherent "cleanliness" to FP.

But I also feel that the argument is not only about program correctness; many people ultimately conflate it with developer productivity. And here's where I feel that things fall apart a bit: I feel as if sometimes it's much quicker to do things with state, so maybe the time you save debugging is time you add elsewhere?

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

#176

Post by Vosporos »

dsign wrote: post #132
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…

Amen to that. I love dearly both C++ and Haskell, but I remember those times when I wanted to cry because the C++ error message broke the OS clipboard when I was trying to copy it to a text editor so that I could write a program to analyze it and find which "const" didn't match in the jungle of type names. I have never had that situation with Haskell.

Oh dear :o

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

#177

Post by mumblemumble »

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 bounced off of Python a few times before finally taking to it (at a time when I had no choice). I honestly believe that this situation has improved since Python 3.5 or so, purely on the basis of improved standards of documentation, including many more libraries adding type hints to their public interfaces.

I've recently been back to Clojure, and it's the same old aggravation again. It seems that, oftentimes, the only way to know what arguments a function is prepared to accept is to already know what arguments a function is prepared to accept.

I don't want to come across as being too down on dynamic typing - I'm currently in the process of trying to get my company over to Python by any means necessary. What I really want to challenge is the idea, popular in many dynamic typing circles, that static types just get in the way. They can also serve to communicate essential information. If you aren't communicating that information through type annotations, then it's absolutely essential that you do it by some other means.

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

#178

Post by srean »

3836293648 wrote: post #140
emteycz wrote: post #99

Earlier quoted context omitted.

That's not entirely true. It gives suggestions in the cases where the C++ compiler does too. There are more than a few very cryptic errors you can encounter with Rust. I like it though, just needs more work.

Depends on the compiler. In my very limited experience I've found that Clang is far superior to GCC in this matter (but rustc is better still, apart from iterator errors)

I am curious about which GCC, G++ version you have in mind. Clang definitely took the lead, but by GCC caught up and I prefer GCC's do Clang. But even I am behind the bleeding edge quite a bit so not sure how things stand now.

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

#179

Post by msla »

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…

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

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

#180

Post by mightybyte »

st1x7 wrote: post #11
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 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.

I don't think that it's wise to try to optimize for some kind of speculative long-term success at the expense of higher early-stage costs that reduce your odds of getting there. This is similar to companies that choose their initial technology with scalability in mind before they're even remotely close to needing to scale. I've actually done this only to discover that scalability has a very definite cost and when you're small it has an outsized impact on your burn rate. If you have success, you're going to figure out a way to make the changes you need. Case in point: Facebook. They successfully grew a PHP codebase into one of the most popular apps in the world. It definitely cost a lot more money for them to make PHP work, but when they got to that point they were a lot less cost-sensitive.

Planning for that far down the road is the least of your worries. And any plans you make along those lines are not likely to be very accurate anyway. You're much better off optimizing for the near to mid term. Based on the hosting costs described by the OP they are already reaping a tangible value here.

Post reply on HN