thedataangel

`Void` is not equivalent to the unit type. Haskell _has_ a unit type, called `()`. A return value of `Void` represents a function which is unimplementable, or which never terminates. It can also represent an unreachable possibility, e.g. in the type `Either Void a`.

In "serious" Haskell code, almost all top-level definitions (i.e. functions) are given types - for exactly the reason you specify.

The second. Because everything in Haskell is immutable, it can take a _lot_ of liberties in terms of letting structures share parts of one another, in the case where one version is derived from the other.

Conversely, in the case where something like a list is modified in entirety (e.g. with a `map` function), if the compiler can determine that the original is no longer needed, it can run the map operation in place - much like you might do on an array in C - avoiding the need for a second copy of the structure in-memory.

Quite a few of Rust's features were borrowed from or inspired by ones in Haskell - albeit often modified to be more suitable for systems programming (and systems programmers!).

Most Haskellers I know are quite fond of Rust :)

Having used Haskell in industry, I can say it's actually _surprisingly_ good at boring run-of-the-mill software. The strong focus on correctness and the ecosystem-wide consistency of it's core design patterns means you spend a lot less time debugging things, and a lot more time writing the thing you actually want to write.

That said, the type system _does_ stand in the way of learning it - though it's very powerful once you get your head around it - and lazy evaluation means you do spend more time than you'd generally like hunting down space leaks if you're writing the sort of code that's capable of getting space leaks.

That's the stupidest password I've ever heard in my life! That's the kind of thing an idiot would have on his luggage!

No filters you say? That sounds terrible. Could you provide a link so that I can definitely avoid it.

The one you linked is close to how you'd write this in idiomatic Haskell. The paper is describing a particular technique, and using FizzBuzz as an example problem, not suggesting that the technique is a good way to solve FizzBuzz.

I don't _think_ Accenture were the original or primary contractor. I'm Australian and interviewed with Digital Asset for that project - as far as I'm aware, DA were the main company responsible, although from what I've heard from people working on it, a lot of the failure stems from mismanagement on the ASX side.

Haskell's syntax without Haskell's type system sounds like a nightmare. The type system is what makes me at least vaguely confident that the incomprehensible string of symbols that make up a good chunk of Haskell expressions are at least close to being correct.

(And to be clear: I use Haskell professionally and love it - but the syntax is _not_ why most people use Haskell).

In general you can't mutate records. Nothing prevents you from making a new one that's slightly different though. It just won't change the already existing one.

In practice this is not actually a problem. It just takes a little getting used to to get yourself out of the 'memory-address as identity' mindset that procedural languages have.

I write Haskell commercially, and none of the problems you list are problems my team actually has in reality.

It was Conal Elliott's stuff, though it was a more recent paper - Compiling to Categories, if memory serves me.

My understanding of automatic differentiation (AD) is that it's only really possible at the compiler level, since you need the ability to interpret and manipulate function definitions themselves. Certainly, no library would be able to offer the same level of guarantees telling you if you've done it wrong, nor the same opportunities for optimisation.

This is actually huge. I saw a proof of concept of something like this in Haskell a few years back, but it's amazing it see it (probably) making it into the core of a mainstream language.

This may let them capture a large chunk of the ML market from Python - and hopefully greatly improve ML apis while they're at it.

The key is that there is a distinction between "not statistically significant" and "statistically insignificant".

Not an issue in practice. Most students choose degrees that have real world demand.

Starbucks is next to non-existent in Australia. Partly it's because there were already established local chains when they tried to move into the market, but mostly because you can walk into almost any cafe in the country and get a much better cup of coffee at a comparable price.

I personally use VSCode with the Haskell IDE Engine as a backend.

It's definitely not as nice as something like Visual Studio or IntelliJ, but it's not too bad.

> The same goes for mutability, it is there and you should certainly use it when it makes sense but it is not the default.

This is also true for Haskell. It's not especially hard to get and use mutable variables, they're just not something that most tutorials cover.

Java's types become incomprehensible once you start trying to do anything complex with generics.

Haskell _allows_ you to write some true type monstrosities (cf. Lens), but almost all the useful instances of that are wrapped in libraries. Types in app code are typically very readable and expressive.

My main complaint with Haskell's type system vs Java's is actually that Haskell has too few type annotations. The inference is good enough that you usually don't need anything besides the function header, which can make it harder to read code without an IDE if you don't know what types certain functions have.

I'd probably rephrase "not" to "less". Haskell is sufficiently unlike other languages that a lot of knowledge/skills that are usually transferable between languages don't apply to it. That means you need to (re-)learn how to solve those problems in Haskell if you want to use it.

The end result is _usually_ better (e.g. Lenses are in almost all cases an improvement over getters and setters; Functors, Monads and Traversable are an improvement over imperative control flow), but damn it it doesn't take a while to get your head around those concepts.

> You'll have to be more specific here - polymophism in the return type is clearly trivial w/o specific constraints, e.g. <T> T identity(T x) { return x; }

Consider a function "decode :: Read a => String -> a". What this returns (and what it does) is dependent on the type that the caller expects.

> <T extends Comparable<T>> T f(T a1, T a2)

Java may have improved this somewhat since I last used it, but the general complaint from Haskellers on this is how difficult it is to say that types must be equal. Consider the fact that java `.equals` is implemented in terms of `Object`, so there's no requirement that the argument be of the same type (or even of a comparable type) to the originating object. Contrast to Haskell's `==`, which can only be called with the same type on both sides. (There is no concept of referential equality in Haskell, so no equivalent to Java's `==`).

Also, I think you'd struggle with that extends trick once you started getting more complicated constraints. e.g, try something like: "T is traversable, A is orderable and serializable to JSON, and T<A> is a monoid".

> Higher kinded types

This probably gives a better explanation than I can be bothered writing: https://stackoverflow.com/questions/35951818/why-can-the-mon...

The TLDR is that there are some concepts involving higher-kinded types (such as Monads) which are simply inexpressible in Java's type system.

Practically speaking, Haskell's type system gives you a lot of code for free.

Stuff like "toString", "equals" and inequalities that you'd usually implement manually in something like Java are done for you automatically by the compiler, with a one-line directive.

That system is extensible as well, so for example you can automatically get Serde code for stuff like JSON, Avro, Protobuf etc with a one-liner.

On a more abstract level, there's a lot of stuff you can express in Haskell that's difficult or impossible on a technical level in Java. For example:

- Functions which are polymorphic in their return type, so that what they do is determined by what type the caller wants them to return.

- Function constraints - for example try to express "A function which takes two polymorphic arguments, which must both be of the same type, and which must be orderable (i.e have <, ==, >, etc defined for them), and returns the same type" in Java. In Haskell, that's just "f :: Ord a => a -> a -> a".

- Higher kinded types. These let you have (loosely speaking) polymorphic containers. For example, instead of List<A> and Set<A>, in Haskell you'd have something like Traversable t => t a, where Traversable is a particular interface you want your "container" to implement.

Your second and third points are just wrong.

The community is one of the more helpful and responsive ones I've come across. You can generally jump on IRC and find either the people who wrote the stuff that's tripping you up (e.g. Ed Kmett for Lens and MTL), or people who know that stuff backwards and are quite happy to help (e.g. Tony Morris).

There are high quality libraries for _most_ common problems. A lot of them are vast improvements over what you'll find in other languages (e.g. Aeson for JSON serde & manipulation). Stuff like Amazonka often runs ahead of Amazon's official libraries, because it compiles directly from their API spec.

Are you going to run across holes? Sure. My team maintains a bunch of open-source libs for where we've found them. If you just want to do connect-A-to-B programming, Haskell is not for you - occasionally you're going to have to go and implement something yourself.

Haskell's type system is _worlds_ better than Java's, and it's absolutely essential to the maintenance benefits that Haskell gives you over other languages.

In my experience, languages that try to bridge OO and functional ecosystems (F#, Scala, etc) tend to suffer from a lot of split-brain / "worst of both worlds" syndrome. You miss a lot of the advantages of FP unless you go all-in on it like Haskell does.

I've done something very similar, albeit with a more bottom-up approach. Pretty much everything he's suggesting is good advice.

In Australia (where I'm from) companies are legally obliged to keep enough cash on hand to cover employee entitlements, which at minimum is pay for the notice period + accrued leave + superannuation (may be more depending on your contract and time served with the company).

Above that, employee entitlements get paid out first in the event of bankruptcy/wind-up (i.e. before any investors or creditors see a cent).

Also, any director of a company that doesn't comply (i.e. keep enough cash on hand) is likely to 1) get banned from being a director of a company, 2) prosecuted, and worst of all 3) get reamed by the tax-office for the amount owing.

Healthcare is almost entirely public here. Employer-provided private health insurance is rare.

This sort of thing makes me very glad I live in a country with legally guaranteed employee entitlements and public healthcare.