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

211–220 of 297 posts

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

#211

Post by Geminidog »

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…

Intuitively you can derive that this is true informally past just an overall feeling.

It’s simple really. Functional programming is just imperative programming without one feature: mutability. Thus if functional programming is just regular programming with a reduced feature set it means it has the same error surface area as regular programming minus the surface area of errors caused by mutability. Hence by proof the error surface area is smaller.

Now think of of all the errors caused by initializing a variable as null and changing it later rather then immediately initializing an immutable variable with the correct value and you can intuit just how big the error surface area actually is.

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

#212

Post by mumblemumble »

supergarfield wrote: post #201
neutronicus wrote: post #191

Earlier quoted context omitted.

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…

They don't, but, at least in object-oriented languages, much of overall experience is easy enough to replicate with formal interfaces and coding standards.

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

#213

Post by Geminidog »

Haskell does not actually get rid of side effects in practice. I find that tons of Haskell code involves do notation which is basically code that embraces monadic side effects which sort of defeats the purpose that this article says of pushing side effects to the edge.

Really in order to “push side effect to the edge” people need to avoid using monadic composition as much as possible which I see Haskell programmers rarely doing in practice.

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

#214

Post by silluk »

UweSchmidt wrote: post #109
nicoburns wrote: post #89

Earlier quoted context omitted.

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up? I remember my first attempts at programming and being annoyed tha…

To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.

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

#215

Post by revskill »

I spent 1 year to focus on learning Haskell. It's a brain-hacking language, too hard to master. But in the end, i've got some nice basics on doing functional programming the right way. Immutability, composable abstraction lies in the heart of a maintainable software i'll produce.

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

#216

Post by wtetzner »

UweSchmidt wrote: post #109
nicoburns wrote: post #89

Earlier quoted context omitted.

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up? I remember my first attempts at programming and being annoyed tha…

> Is it really that painful to write "String" each time?

I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it.

But languages that have type inference but allow type annotations at least allow you to try to hit that balance.

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

#217

Post by KingOfCoders »

mumblemumble wrote: post #212
supergarfield wrote: post #201

Earlier quoted context omitted.

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

They don't, but, at least in object-oriented languages, much of overall experience is easy enough to replicate with formal interfaces and coding standards.

I thought the nice thing about Modula-2 was that you could browse through interface files to understand some code and then go into implementations.

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

#218

Post by steveklabnik »

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…

> why doesn't it just do the cross-function inference

It could! This is an explicit design choice. There are a few different reasons. They're all sort of connected...

In general, Rust takes the position that the type signature is the contract. If you inferred the types on function signatures, changing the body of your function could change the signature, which means that breaking changes are harder to detect. It also leads to "spooky action at a distance" errors; I could change a line of code in function A, but then the compiler complains about the body of some unrelated code in a totally different part of the codebase, because that changed the signature of function A, which changed the signature of function B, which is called in function C. My error shows C is wrong, but I made a mistake in the body of A. That's confusing. Much nicer to say "Hey you said the signature of A is X but the body is Y, something is wrong here."

I am gonna handwave this one slightly because I don't fully remember all of the details, but full program inference and subtyping is undecidable. Rust doesn't have subtyping in general for this and other reasons, but lifetimes do have subtyping. I am sure this would get ugly.

Speaking of getting ugly, Rust is already criticized often for compile times. Full program inference would make this much, much worse. Again with that changing signatures issue, cascading signature change would cause even more of your program to need to be recompiled, which means that bad error message is gonna take even longer to appear in the first place.

I think there might be more but those are the biggest ones off the top of my head.

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

#220

Post by nicoburns »

secondcoming wrote: post #111
nicoburns wrote: post #89

Earlier quoted context omitted.

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

And it's my experience that that is only a benefit to the person who wrote the code, and only for a short time. Generally, I prefer being able to read a line of code and understanding exactly what it does. If I need an IDE and have to repeatedly try to find the definition of something then, in my opinion, that's wasting my time. C++'s 'auto' is really useful but it's over-used IMO. I think that there's a belief that…

I find that types can reduce readability as well as enhance it. They add noise and make it harder to concentrate on the variable names which are often much more important than the types which are often (but certainly not always) obvious from context.
Post reply on HN