Comment by hardwaresofton | Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

If you like this, you're probably also going to like Haskell/OCaml/Ada/F#/Coq (ML family of languages?):

I'll leave links for Haskell since the only one of those I've tried and liked personally:

https://www.haskell.org/

http://learnyouahaskell.com/

IMO Haskell is the type system you wanted Java to have, with even more strictness. While it's possible to write unsafe haskell, just about everything you will read, and the language itself encourages you to push as many worries as you can to be solved by the type system.

If that doesn't get you excited, there's actually a saying that is mostly true in my experience writing Haskell -- "If it compiles, it works"(tm).

Also Haskell on the JVM if you want to dip your toes in:

- https://eta-lang.org/

- https://github.com/Frege/frege

[EDIT] - If you try to learn haskell you'll inevitably run into the M word which rhymes with Gonad. The best guide I've ever read is @ http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

BTW, be ye warned: when you start understanding/getting cozy with the concepts introduced by Haskell you'll wish they were everywhere, and they're not. Languages without proper union types will look dumb to you, easy function composition/points free style will be a daily desire, and monadic composition of a bunch of functions will be frustratingly absent/ugly in other languages, not doing errors-as-values will look ironically error-prone.

[EDIT 2] - More relevant to the actual post, how you would do this in Haskell is using the `type` keyword (type aliasing, e.g. `type Email = String`) or the `newtype` keyword, which creates a new type that is basically identical (what the article talks about). Here's some discussion on newtype:

- http://degoes.net/articles/newtypes-suck (this article is good, it describes the premise, promise, shortcomings, and workarounds, forgive the clickbaity title)

- https://www.reddit.com/r/haskell/comments/4jnwjg/why_use_new...

Although Haskell has a relatively powerful and useful type system, you are perhaps being a little kind to it here. Haskell also has partial functions, including quite a few dangerous examples in the standard library, various mechanisms to escape the type system entirely, and 27 different ways to handle errors, 28 of which look a bit like exceptions but need handling in 29 different ways. And it still can't handle basic record types very elegantly, nor dependent types such as fixed-size arrays/matrices. Haskell's type system does have a lot going for it and it also makes a useful laboratory for experiments with type-based techniques, but as far as safety goes it has never really lived up to the hype, and for all its advanced magic, it is surprisingly lacking in support for some basic features that are widely available in other languages.

You are absolutely right -- there are other ML-family languages that do a better job at avoiding some of the pitfalls (but surely with other tradeoffs). Most of the stuff you've mentioned is actively recognized by the Haskell community and has been somewhat improved:

> Haskell also has partial functions, including quite a few dangerous examples in the standard library,

Partial functions -> https://wiki.haskell.org/Avoiding_partial_functions (introduces the safe library @ https://hackage.haskell.org/package/safe)

> various mechanisms to escape the type system entirely

Type systems are leaky abstractions. While that's just a random assertion with no fact to back it up, I think it is a good idea design wise to account for that possibility, and give people the ability to completely bin the type system when they need to. Most of that stuff is marked with some wording that strongly suggests against use, but does not prohibit (e.g. unsafePerformIO)

> 27 different ways to handle errors

Could you elaborate? I understand this is hyperbole, but I feel like the number in actuality is <= 3... which might make your statement ~90% hyperbole, which is a bit much.

> still can't handle basic record types very elegantly

Compared to which language? Records in Haskell are indeed a PITA to get values out of when they're deeply nested, and you have to destructure or string to gether the accessor functions or something, but I still like it more than other languages which take a looser approach, often leading to runtime errors. If I do a obj.something.somethingElse, that line might blow up at runtime, but in Haskell I have some guarantees/checking that it won't. C#'s `?.` operator is pretty good for accessors when dealing with nullable values as well.

The lens library helps with that, but though it's simple in function, the mathematics around it that are often introduced at the same time complicate things.

> nor dependent types

https://www.reddit.com/r/haskell/comments/8cp2zg/whats_the_s...

> laboratory for experiments with type-based techniques

Haskell is less of a laboratory these days, people are actually using it for production stuff now, and they can't change core pieces of the languages so quickly -- I'm sure people would love to go back and eliminate partial functions from the standard library where reasonable.

Languages like Ada might be better for experimental type stuff?

> never really lived up to the hype

Compared to what? Would you consider Haskell better for type safety than say Java/C#? Because I certainly do (I'd love to be proven wrong as well).

I assume you meant the features you noted above as missing (easy record types, coherent error handling, lack of partial functions) in Haskell but widely available in other languages -- could you note which ones you had in mind? Java is what I've seen used most in enterprise and every function is basically a huge walking partial function -- Haskell's type system (at the very least) seems like a huge step up there. Things got better with 1.8 and the introduction of Optional (and are probably even better these days) but back when I wrote a lot of Java, it didn't seem right to 'poison' all the code with Optional<>s everywhere... Now I know better, I wasn't poisioning the code, I was writing better code but couldn't recognize it at the time.

Contrast this with Java that waited until 1.8 for functions as a first class object.

>> 27 different ways to handle errors

> Could you elaborate? I understand this is hyperbole, but I feel like the number in actuality is <= 3

Not quite 27, but exceptions in Haskell are quite messy. You have:

1) Exceptions. Which can be thrown from pure code, but only caught in IO. And which get thrown when evaluated, which causes a mess with Haskell's lazy evaluation. So the following code is not safe:

    val <- catch (willThrowError) handler
    print val

Because willThrowError may return a thunk that will not throw an error until you attempt to resolve it to a value. This means that it will not actually throw an error until `print val`, at which point it is outside of the catch, so your entire function will error, and your handler will not be called. To be safe, you want to do something like:

    val <- catch (evaluate . force <$> willThrowError) handler
    print val

Which requires the return value of willThrowError to be a support type. With the proper language extensions, it is not difficult to autogenerate the instance needed for a type to work with force, so long as you control the type definition and all the types it relies on supports it. I avoid actual Exceptions like the plauge, so I might be off on some details here.

2) Maybe/MaybeT/Either/EitherT

Arguably 4 methods, but I will concede that they are the same-ish.

3) ExceptT.

Maybe belongs in catagory 2?

4) MonadError

5) MonadFail

I might be missing somne.

Hey thanks for clarifying -- Maybe I've just been a victim too long, but those actually don't seem like distinct ways. As far as why you can throw an exception in pure code but only catch it in monad, much ink has been spilled[0]. I won't claim to completely understand the reasoning in that SO post and the linked paper[1], but the reasons for this dichotomy seem to be clear.

2) -> 5) are not ways of handling errors though, they're ways of characterizing/combining monadic computations that CAN error, IMO. In the end, it's still the errors-as-values (`Either SomeException value`) concept, but in combined with the fact that your computation is in a monadic context. Also, maybe I've just been brainwashed by myself to think that way after doing Haskell for this short amount of time.

In practice, how I throw an error from a monadic computation (I generally have never done it from pure code) has been pretty well-defined, I haven't had to go down this particular rabit hole much at all -- ExceptT is what I've used the most (I've done most of my work with Servant[2]). Honestly what I've had problems the most with from my haskell code was dealing with the database or mail servers and tcp sockets and stuff -- stuff that failed at runtime because I put in some bad code Haskell couldn't check before runtime.

That said, monads & monad transformers are indeed a complex concept, and are very confusing to beginners (I'm still not 100% confident in my knowledge of them), so this is definitely a point against Haskell.

And of course your earlier point about unsafe functions in the std lib is as valid as ever.

[0]: https://stackoverflow.com/questions/12335245/why-is-catching...

[1]: https://www.microsoft.com/en-us/research/publication/tacklin...

[2]: https://haskell-servant.readthedocs.io/

My only real complaint about exception handling in Haskell is the interaction with laziness. 90% of my problems would go away if they just made the default catch functions include `evaluate . force` and save the lazy behavior for special "I know what I'm doing" functions. Without that, exceptions are just a loaded gun. Even with making exceptions "safe", I still much prefer the error-as-values approach. Otherwise, every pure function is really some type of ExceptT IO monad. I'm sure this escape hatch is useful to someone, but actually using it is a pretty big code smell.

Yeah this is actually an oft-repeated problem. I haven't really run into problems with enforcing strictness but that just means I haven't written/profiled enough Haskell yet, probably.

Note though that there is the new Strict pragma:

https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

Also, this isn't really a solution to the problem (at best I'm just being an apologist), but you could write rules with hlint or any other code-smell-checking-tool to make sure no one every tries to use the escape hatch(es) you don't like.

We basically ban throwing exceptions in pure code at my shop; usually we use ExceptT or throwIO or something.

I used to think the multiplicity of error handling constructs in Haskell was confused and bad, but they all have their uses. The key insight is that your error handling should conform to the local structure of your code, not the other way around.

Propagating errors across multiple component boundaries or multiple layers can be cumbersome but I think that reveals fundamental architectural weaknesses in the program itself.

Thanks, that covers much of what I had in mind before.

Error handling in Haskell seems to suffer from two fundamental problems.

One is that there is a clash between non-strict evaluation and exceptions, as your first example illustrates. I understand the arguments about why throwing can be done in pure code but catching needs to be in IO in Haskell, but those reasons are consequence of other design decisions in Haskell. The asymmetry is awkward, and it feels like you can never quite trust pure functions to do what you expect. It's a little like the long-standing criticisms of exceptions in C++, except that at least in C++ idioms have evolved to compensate, whereas shoving everything behind one or another of the `catch` variants in Haskell feels very unidiomatic to me.

The other fundamental problem is that the different techniques for representing potential failure don't compose very elegantly. Given that flexible composition is arguably the biggest selling point of being lazy in the first place, that is unfortunate. The elegance gained from a language like Haskell in expressing tidy, pure code loses its shine a little if you then have to wrap a lot of real world code that calls out to other libraries to do things inside 17 levels of monad transformers, forced evaluations and catches.

Of course I'm not suggesting that these are new or insurmountable problems or that no-one can write reasonably safe code in Haskell or anything silly like that. But I do think some advocacy, as if the type system is borderline magical, can be rather idealistic, and sometimes overlooks the warts that also arise as a direct result of the decisions that made the language safer and more elegant in other respects.

A nitpick. At top level:

> Haskell/OCaml/Ada/F#/Coq (ML family of languages?)

Then:

> Languages like Ada might be better for experimental type stuff?

It seems to me there's a confusion between Ada [1] and Agda [2], where Agda is what you meant. Ada is also interesting, but in the Pascal/Modula family and although strictly typed the type system is nowhere near as sophisticated as the ML family languages (and here too a big difference between real ML and dependently typed languages like Coq/Galina and Agda).

Among the things I liked in Ada:

- generic packages, a more disciplined way to have static genericity than C++ templates. One can declaratively constrain the input types to a generic package, with clean error codes. C++ concepts will close the gap and maybe be even more powerful, but Ada had this from day 1;

- protected types for mutual access. A higher level mutual exclusion scheme than mutex. Add in Ada 95 IIRC;

- integer subtypes, with ranges and automatic checks.

Still I believe the train has passed, and nowadays rust (with some strong inspiration from the ML family) has more of a chance to make it as the next gen system programming language, although it'll take time.

[1] http://www.adaic.org/ [2] http://wiki.portal.chalmers.se/agda/pmwiki.php

Ahhhh thanks I knew I was mixing them up somewhere -- I think they'd morphed into the same thing in my head.

Type systems are leaky abstractions. [...] I think it is a good idea design wise to account for that possibility, and give people the ability to completely bin the type system when they need to.

Agreed on both counts, if we're talking about having escape hatches like `unsafePerformIO`. Maybe even `undefined`.

But I grimace a little whenever I see someone criticising the prevalence of runtime problems like, say, null pointer exceptions in Java, and then in practically their next breath advocating a functional programming language with a better type system like Haskell... and giving a neat example that will quite happily compile and then crash at runtime when given an empty list as input because it used a partial function like `head` without checking. This sort of gaping hole in the protection of the type system is less welcome.

Could you elaborate [on 27 different ways to handle errors]?

I think gizmo686 did a nice job of covering this in another reply to your comment, and I added some further thoughts of my own in a reply there.

In our current context, I note in passing that the issue of throwing from pure code when catching needs IO is another somewhat counter-intuitive result that we might instinctively expect the type system to protect against.

Compared to which language [can Haskell not handle basic record types very elegantly]?

Perhaps C, C++, C#, Java, and friends as a starting point? At least the names of members of structs/classes there are used in context and don't clash with the same name used in a different context.

Haskell also has the same challenge as any functional language when it comes to constructing new values from existing ones where there is deep nesting. As you say, lenses can help there, but bring some additional complexity of their own.

Compared to what? Would you consider Haskell better for type safety than say Java/C#?

Yes, certainly. I'd much rather write software that involves complicated logic and needs high reliability or longevity in a language like Haskell than a language like Java, other things being equal.

I'm just wary of putting Haskell up on too high a pedestal, partly to avoid setting expectations too high for those not familiar with it yet, and partly because I think a lot of mainstream languages could benefit from relatively simple improvements in their type systems without necessarily encouraging the "using types for non-trivial things requires five PhDs" stereotype.

I assume you meant the features you noted above as missing (easy record types, coherent error handling, lack of partial functions) in Haskell but widely available in other languages -- could you note which ones you had in mind?

Yes, for example the struct/class member naming mentioned above. Almost every statically typed language I have ever used does records better than Haskell, because Haskell doesn't really support record types at all, it just has a bit of syntactic sugar that creates the illusion of that support if you don't look too closely. (This assumes the basic language without the various relatively recent GHC extensions/proposals, of course.)

> points free style will be a daily desire

Not...really.

That is why they call it pointless style sometimes.

Point free is good for short functions, like 1-3 compositions is fine (maybe little more), but if you overuse it, it's actually much less flexible and you have to rewrite more code if you want to change something.

"Point-free style can (clearly) lead to Obfuscation when used unwisely. As higher-order functions are chained together, it can become harder to mentally infer the types of expressions. The mental cues to an expression's type (explicit function arguments, and the number of arguments) go missing.

Point-free style often times leads to code which is difficult to modify. A function written in a pointfree style may have to be radically changed to make minor changes in functionality. This is because the function becomes more complicated than a composition of lambdas and other functions, and compositions must be changed to application for a pointful function.

Perhaps these are why pointfree style is sometimes (often?) referred to as pointless style. " https://wiki.haskell.org/Pointfree

Reply on news.ycombinator.com