On: Haskell Problems for a New Decade

[noelwelsh]

I don't think that the type systems are too complex. I think the issue is that approximately zero effort (perhaps even negative effort) has been put into the UX of the type system. We have tools for debugging run-time errors, such as debuggers and tracing. When you shift errors from run-time to compile-time, as type systems do, you need similar tools to debug and inspect type checking. Very little work has been done here.

[lonelappde → noelwelsh]

Yes, this is missing from the article. There is some recent work (inspired by Elm raising the bar) with better UX for type errors. The technology tools exists but the labor is waiting to be done for every type in every program. Like documentation in general, it's the kind of work that requires a long slog across the code base, not inventing a new abstraction, so most Haskellers and most people don't bother to do it.

[socialdemocrat → noelwelsh]

That is why dynamic languages shine. Because types are objects like any other object you can use the same tools to deal with types as other code. It is one of the reasons why meta programming tends to be much harder to achieve in statically typed languages.

[noelwelsh → socialdemocrat]

(What you call types are not what those who work in programming language theory call types. I disagree but this is an old and well worn argument and I'm not really interested in revisiting it.)

[socialdemocrat → noelwelsh]

There is your problem right there. These static type gurus live in an alternative universe in ivory towers far removed from where the rest of us simpleton programmers live.

Frankly I think it is an intellectual cargo cult. For all its sophistication these languages have not delivered that much. Look at language like Go, which these guys would laugh their butt off. Yet Go has produced usable software for a lot more people and made a lot more developers happy than Haskell ever could.

Coming years after Haskell Julia seems to be doing a lot more for science than Haskell has ever managed to achieve.

[noelwelsh → socialdemocrat]

Well allow me to climb down from my ivory tower and offer the following in way of explanation:

Here is a reasonably good overview of safety (aka dynamic typing) vs types: https://papl.cs.brown.edu/2018/safety-soundness.html

Put another way, the standard programming language theory is that types are constraints that are uncovered (via type inference) and checked at compile-time. If type information is found at run-time these are known as tags. In Haskell, for example, you can declare a type like

   newtype SecretKey = Int

This creates a new type (SecretKey) that has a run-time representation that is just an Int. I.e. it has no additional information associated with it at run-time that you could use to distinguish it from an Int. At compile-time it is distinguished, however. You cannot use a SecretKey where an Int is expected and vice-versa. This could prevent you leaking secrets to other parts of your program, for example. This is one way you can reclaim performance in a statically typed language, vs dynamic types, without degenerating to passing around uninformative primitive types like Int (which introduces the possibility for errors).

[socialdemocrat → noelwelsh]

In my opinion you are actually reading this the wrong way. When I explain concepts such as boxing to people I will refer to type tags. But in that context I use the phrase to refer to how something is implemented.

How a type system is implemented is different from how it conceptually / semantically.

For instance in Julia types are conceptually objects you can pass around. However they will not always correspond to a type tag. Conceptually all objects in Julia have a type. However at runtime they may not. The JIT compiler could have gotten entirely rid of them.

When values are placed in a Julia array, individual elements will typically not have any type tags. However conceptually they still have a type.

To me type tags are just an implementation detail which both dynamic and static languages may use. However when you speak at a conceptual level you don't use that word. You don't say, "lets put this type tag into that object," you say "lets put that type into that object, bind to that variable or whatever."

The way I like to talk about static and dynamic languages is to say: In dynamic languages values have types, but not expressions / variables. In static languages expressions have types, not values.

That is of course a simplification, but IMHO simple and sensible way of making the distinction.

[socialdemocrat → noelwelsh]

> This creates a new type (SecretKey) that has a run-time representation that is just an Int. I.e. it has no additional information associated with it at run-time that you could use to distinguish it from an Int. At compile-time it is distinguished, however.

I can do exactly the same in Julia

   struct SecretKey
      value::Int
   end

After the JIT compiler is done, there is no difference between this and an `Int`. The type associated with the value only exists conceptually at runtime. A `SecretKey` value in Julia will in most methods look no different from an `Int`

> without degenerating to passing around uninformative primitive types like Int (which introduces the possibility for errors).

That would be the same in a strongly typed dynamic language. Except the error will of course be caught at runtime. But it is not like you can use the types in an illegal way.

[magicalhippo → socialdemocrat]

Static typing makes the code self-documenting though. Just yesterday I was looking at this code I found, my very first time trying Node.js:

    stream.on('data', function(data) {
        processStreamData(data, (results) => {
            callback(results);
        });
    });

Ok, I get `data` from the stream, I guess it's some kind of array, but what can I do with it? What exactly is it's type? I need to extract Int32's from the stream and operate on those, how do I do that?

So, as you say, I was forced to trigger the code at runtime, by inserting some debugging code that logged the type to console.

So for a simpleminded guy like me, static typing helps me a lot because it makes it easier to reason about the code I'm reading.