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

201–210 of 297 posts

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

#201

Post by supergarfield »

neutronicus wrote: post #191
KingOfCoders wrote: post #21

Earlier quoted context omitted.

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.

> The lack of .h files alone is a huge grievance for me

That's an interesting point... Besides C and its derivatives, and OCaml, do other languages have separate definition files? It seems like newer languages, even statically typed, normally don't.

I suspect the reason is that you have to duplicate all definitions, which seems like rote work. It also feels less necessary with IDE tooling: IDEs I know have a view for all definitions in a file.

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

#202

Post by darksaints »

Okay, so this is admittedly snarky but we've seen this sort of blog post so much that it has practically become an Onion article: Why Haskell Is Our Secret Weapon, by Startup You've Never Heard Of.

And then when someone points out that nobody knows who they are or what they've built, we get commenters talking about how company X, Y, and Z are also using Haskell. And those claims also come up short...most of them can't say where or how it is being used because they don't know...just that at some point in the past, someone emails were exchanged between someone@bignamecompany.com and someone@haskell.org, and now there is a piece of copy on the Haskell website that disingenuously claims BigNameCompany is powered by Haskell!. Who cares how pervasivly it is used...if someone writes a config parser with Haskell, all of a sudden we can claim that BigNameCompany would fall over on its face if Haskell wasn't there protecting it.

Come on. Nobody cares that Haskell is your secret weapon if you've never overcome an opponent with it. Or built an entire profitable company on its back. All these types of posts do is fake an authority so you can jump straight to your fallacious argument by authority.

If you want to argue the merits of your favorite language, then do it. Don't make us sit through an argument about how your language makes you special when you aren't even noteworthy enough for a 10 sentence Wikipedia blurb. There are a lot of valid and powerful technical arguments in this article, but they're ruined by framing them all around the premise that we care about how it makes you and your startup special.

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

#203

Post by mjburgess »

tome wrote: post #160
mjburgess wrote: post #157

Earlier quoted context omitted.

Haskell is structurally typed...

Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.

Sure, my mistake. I meant something looser.

Only that the types can be analysed structurally (ie., pattern matched).

In C++, etc. there's a "radical nominalism" in which the type was very opaque, ie., encapsualated.

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

#204

Post by nix23 »

arcturus17 wrote: post #175
dgb23 wrote: post #94

Earlier quoted context omitted.

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 progra…

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

Yes (page 7):

https://arxiv.org/pdf/1901.10220.pdf

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

#205

Post by dgb23 »

arcturus17 wrote: post #175
dgb23 wrote: post #94

Earlier quoted context omitted.

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 progra…

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

I wonder if there is one such formal proof as well.

Intuitively it is trivial: functions a are a subset of all procedures, state can introduce unique bugs, these bugs are not found in functions, so you're dealing with a subset of all possible bugs.

Another intuition is this: By introducing state you increase complexity. A procedure in isolation is not necessarily referentially transparent, but a function is. You cannot reduce the procedure with it's evaluation at any given point in time, because it is 'connected' to the surrounding program via that state. Now you'd have to show that increased complexity introduces unique bugs.

I'm simply not equipped (yet) to make such claims, but I'd love to hear from experts on these matters. I know that you can formally verify stateful programs, so it is likely not an issue of what is possible. But I damn sure know it is much easier to reason informally about functions than about procedures, except if the procedure merely has local state.

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

I can only speak for myself here, but yes certain algorithms are more intuitive if implemented imperatively. But I found that the set of these algorithms shrink over time by getting used to FP. Vice versa there are also algorithms that are much more easily written with functions. Then there is core idiom of the language you're using. If it is imperative OO, then writing functional programs can sometimes feel cumbersome and less readable.

There are many factors that may or may not apply as well. For example functions are easier to compose and decompose, since they are by definition simpler. However imperative procedures are sometimes easier to read "from top to bottom", because they enable a more real-world-y mechanical/visual mental model.

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

#206

Post by Geminidog »

WraithM wrote: post #173
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?

We use nix in production at my company. It’s horrible. It’s only good for ecosystems that rely heavily on context or libraries installed by operating system package managers. Languages that have self contained package managers like JavaScript, Haskell or python don’t benefit. In fact in those cases nix actually makes things worse by making almost everything way more complex and error prone then necessary as literally nothing is designed with nix in mind.

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

#207

Post by whateveracct »

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 think at worst, Haskell is a a minor productivity cost for a company vs a mainstream language, and if it is, it's hard to pin it on the language.

So given the upside to paying people to using Haskell (they get to learn it for life, many join + grow the community, they enjoy working for your company more), I think it's worth that kind of harm to a corporation.

I'll keep trying to sap corporate resources into Haskell I take with me for life at least :)

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

#208

Post by uryga »

magicalhippo wrote: post #184
uryga wrote: post #174

Earlier quoted context omitted.

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

> You'd write code pretending it's pure while it really isn't.

in a way, it's the opposite! the point is you can't pretend, you have to make impurity painfully explicit:

  getTradeTax :: CountryId -> CountryId -> IO Float
  --                                       ^ sirens blaring, side-effect alert
  getTradeTax ca cb = do
    aInEu
there's the "IO" in the signature, and all the do-notation `>=`, piping the result into a callback. to use the Promise analogy again, `x > I can see part of the appeal, but I can do that in my current language.

true, and i've seen IO-monad-alikes for Python and JS, but most of the benefits come when every library you use has to be explicit about impurity and there's a typechecker enforcing it.

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

#209

Post by thesz »

jcelerier wrote: post #18
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…

> the types are really low level (missing basic things like tuples) and lack of type inference how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009

C++ cannot have non-local type inference due to, you know, object-oriented part of it.

This means that you cannot say something like this:

  auto sepulka;
  auto bubuka = zagizuka(sepulka);
Because if zagizuka's parameter is a structure or a class, you have a selection of parents. On a contrary, you have a selection of descendants of the result type of zagizuka() for bubuka, each having their own copy or assignment constructor.

[1] http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%...

[2] https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Mar...

[1] shows how hard it is to make right type system with inheritance. I believe these slides mention 25 years of collaborative effort. Compare that to [2] where it took 8 years to design intuitionistic type theory (1971-1979) by mostly single person.

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

#210

Post by andai »

darksaints wrote: post #202

Okay, so this is admittedly snarky but we've seen this sort of blog post so much that it has practically become an Onion article: Why Haskell Is Our Secret Weapon, by Startup You've Never Heard Of. And then when someone points out that nobody knows who they are or what they've built, we get commenters talking about how company X, Y, and Z are also using Haskell. And those claims also come up short...most of them can'…

I don't think the article warrants such a harsh reaction. Was it the word "our" in the title? They're just writing from their perspective.
Post reply on HN