Hacker News Reader

Comment by wellpast | Hacker News Reader

> Why would you not want to know about these bugs immediately and fix them early in the development process?

That's a good question. But enforcing your codebase to be a Rubix cube you have to twist and turn until the static type checker says Yes is not trivial. Its a tax.

The real question is whether that tax is worth it when your goal is purely business delivery and not something else (eg, intellectual stimulation). Is it?

Writing unit tests and code review are other means to root out bugs. But they also come with a tax. When are they worth the tax and when are they not worth the tax?

In some cases we judge they are. In other cases not.

A statically typed language typically asks us to turn off our brain and apply type verification everywhere. In this way, statically typed languages wield type verification more like a religion than a tool.

View on HN

Honestly I've never understood this argument that choosing types is too complicated. Most often I've seen it come from people without much experience in statically typed languages and imagine that having to determine the type will be difficult.

After becoming familiar with the code base or library, particularly with modern IDE's it's rarely taken more than 10 seconds to choose a type. When reading another person's code, it does take some time to map out the relationship between the classes, but unless your code is in one giant file/function/object you're going to have to figure that out anyway.

From Rich's talk: "Now at this point I was an expert C++ user and really loved C++, for some value of love."

Rich has had many years of experience in statically typed language.

Please don't use C++ as an exemplar of static typing. There are much more powerful and congenial alternatives.

It would be just as unfair if one were to claim that dynamic typing is bad because assembly language tends to be buggy and expensive to maintain.

The type system of something like C++ and Java are so far removed from the type systems of Haskell or Idris, that it is silly to compare these two.

I've programmed professionally in statically typed languages for > 15 years. (C#, various VBs, C++, F# (which is rad), and lately TypeScript) I've also dabbled in Haskell, OCaml, Rust, and a whole lot more.

In fact, outside of Clojure, I've never liked a dynamic language (and I've used a few professionally).

So, I'm someone with plenty of static-language experience, and I am in the boat that types are more complicated, in some ways. Just today, I had to figure out how to wrangle TypeScript into a shape I needed (and wound up with a solution that I didn't like but which got me past the compiler errors and on to more important work). There is a cost. There is also a benefit. So the question is, what does the cost/benefit analysis yield?

Regardless, Clojure is worth learning. It's an amazing language.

> Just today, I had to figure out how to wrangle TypeScript into a shape I needed (and wound up with a solution that I didn't like but which got me past the compiler errors and on to more important work).

It would be really interesting, and indeed probably the most valuable contribution to this whole discussion, if you could write up what the problem was and why it wouldn't have occurred in Clojure!

You can fix your interface bugs early in the development process with the aid of a compiler, or you can fix them later manually at much greater expense. When the "tax" is so much cheaper than the consequences, not paying the tax is crazy.

But "interface bugs" are the least of our problems. As evidenced by most bug queues that I've peeked at.

No true. I have to try and reverse engineer types whenever I use JSON APIs. The documentation provides only "samples". I literally have to experiment to find out what works with no guarantee it will keep working.

I don't know about that. How about the simple interface of "shouldn't be null".

If null pointer exceptions are the most of your problems then I think you're doing pretty well.

In my experience NPEs are the easiest bugs to root out and fix.

The point is that NPEs are a solved problem, just not in Java and Clojure. I am better able to stay focused on the real problems, as I never have to root out and fix bugs like this.

Not to mention that the ease of fixing the bug has little to do with the cost of the bug showing up in production.

I can do all kinds of things to prevent bugs showing up in production. I once worked on a mission-critical piece of software in which the entire team was brought in to do a page-by-page code review for all newly written code.

Of course, the cost outweighs the benefit in this case for most industry software that can afford a few bugs at the extreme expense of (this kind of) code review.

Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time?

And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board.

> And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board.

Yes, actually, I don't find these things to be a particularly high burden, and the benefit, in my experience, easily outweighs it.

When you're writing code, you have to think about what kinds of things will be passed to a given function, whether the compiler checks it or not. So I find having the compiler check mundane things like this lowers my cognitive load, because I don't have to worry so much about what to do if I get a null (fail, handle it in some way, etc.).

I will agree, though, that the style of programming with maps so prevalent in Clojure makes a lot of sense in some programs. However, even then, there is a typing discipline that fits (row types).

Honest question: have you ever written a large computer program in a programming language descended from ML (SML, OCaml, Haskell, &c.)?

No I haven't. And, depending on how long life turns out to be, maybe I'll get to.

But.

I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupling and imprecise semantics.

These two problems are a function of the experience and training (and value system) of the programmer building them, and programming languages can do very little to save a system from these plights. (It might be that a static programming language can help here inasmuch as it slows down the programmer from producing too much code, but I realize that's arguable and also that I'm making a wicked joke.)

Still.

All computers ask is for semantic precision and you don't need a static type verification to get precision. So clearly static type verification is unnecessary for producing programs that work. And clearly statically-typed everywhere PLs are asking the programmer to do extra work. That's prima facie true. So the burden is really on the MLer/Haskeller to prove that that extra work is giving overall delivery throughput to the programming team. Maybe it is, maybe it isn't. But I'm waiting for the clearly thought out justification. Haven't heard it yet.

> And clearly statically-typed everywhere PLs are asking the programmer to do extra work.

I'm not convinced this is entirely true. The kinds of information that you encode in types is the kind of information that's useful to anyone reading the code. And if that information isn't written down somewhere, then the person reading the code (maybe you sometime later) has to reconstruct it themselves. And if it's useful to write that kind of information down, why not have the computer check that it's consistent?

> All computers ask is for semantic precision and you don't need a static type verification to get precision. So clearly static type verification is unnecessary for producing programs that work

That's a bit contrived. No matter which language you write in, at some step a type check will happen. For dynamic types its at runtime and for static types its at compile time.

> And clearly statically-typed everywhere PLs are asking the programmer to do extra work. That's prima facie true. So the burden is really on the MLer/Haskeller to prove that that extra work is giving overall delivery throughput to the programming team. Maybe it is, maybe it isn't. But I'm waiting for the clearly thought out justification. Haven't heard it yet.

Here are just a few of the real world accounts of using Haskell in production, you can check out:

- The Joy and Agony of Haskell in Production: http://www.stephendiehl.com/posts/production.html

- Haskell is Not For Production and Other Tales: https://www.youtube.com/watch?v=mlTO510zO78

- Production Haskell - Reid Draper: https://www.youtube.com/watch?v=AZQLkkDXy68

If these didn't convince you, there are tons of Haskellers that will attest that the type system in the long run has quite substantial benefits.

> I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupling and imprecise semantics.

This is a wonderfully, astonishingly, gobsmackingly interesting comment for me to read! In my experience of large systems (Haskell-style) types are exactly the thing you need to tame coupling and imprecise semantics.

To take one arbitrary but notable example, in a previous job we found several bugs in large industry XML schema^ by converting the schema to Haskell types and noticing, via type errors, that some things didn't match up.

^I forget if the bugs were in the schema itself or in the Java implementation that another team was using. I think a little bit of the former and a lot of the latter.

> I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupling and imprecise semantics.

One thing I find interesting about this is that a good type system, combined with something like OCaml's module system, is that you can force decoupling. In OCaml, you can create an abstract type, which cannot be used in any way that isn't specified through the interface. You don't have to wrap the runtime value in anything, it's purely a compile time abstraction.

> Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time?

Yes!

> And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion?

Oh god yes! Simple Hindley-Milner typing is so cheap to use it's almost free!

> Most static programming languages force you (or make it hard for you not) to do this verification across the board.

Well, not really. In Haskell, for better or for worse, you can still use `fromJust` even if it is considered rather naughty.

> A statically typed language typically asks us to turn off our brain and apply type verification everywhere

No, it doesn't.

People are not using Haskell because they want to turn off their brain.

Let me rephrase:

A statically typed language typically asks us to redirect our brains from asking the question, "Is type verification really needed in this particular instance to deliver my business value?" to instead solving the type-checker puzzle du jour.

Plenty of modern statically-typed languages have dynamic escape valves (and plenty of dynamically typed languages have opt-in static validation.)

It's true that choosing to use a static language without a dynamic escape valve for a component constitutes making the decision that, for the pieces of that component, dynamic freedom isn't an option that needs further considered.

This is effortless once you have experience[1]. Besides, understanding the type of your data is beneficial, and so is it to be able to use types as an exploratory tool in a codebase you don't know.

[1] Just like having experience in editor shortcuts bear an initial cost to make you more productive forever...

Which part is effortless? Solving the type checker puzzle, or asking whether type verification is truly needed in a particular given instance?

Thinking in types. 95% of the time, the type checker silently validates my input and the remaining 5% of the time, the trouble I get is understanding valuable information.

There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate.

> There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate.

Your analogy doesn't apply.

I can read a book in O(n) time, where n is the number of words in the book. I can read a single word in O(1) time.

When I get a type error, that is not a O(1) fix. The type error is connected to my program in the large and I have to understand/process more than just the single line where the error is called out. The worst case, obviously, is O(n).

The worst case for the number of places I have to go fix is O(n). I.e., the verification half is O(n). The solution search side ("solving the puzzle") may be worse, because I have to generate/find the code that fits the type checker.

Using a static type checker means that an error doesn't creep across all my code. The worst case you describe pretty much never happens, and the smaller instances I get are reified to a generic form I am trained to analyze and solve quickly.

> Your analogy doesn't apply.

One would think I am well placed to describe my own experience of interacting with a type system.

Lots of valid code, won't pass the type checker. That is the problem with static type checkers. You have to adapt your code to satisfy the type checker even when you know your logic is right.

Static type checking also significantly complicated meta programming, macros and code generation.

But hey I like statically typed languages too. A big fan of Swift which has borrowed many functional ideas. I just don't think static typing is the silver bullet that many of its proponents think.

It works well for some problems, but not all. E.g. I can't think of any statically typed language which can compete with Julia for numerical work and data science.

Haskell e.g. is just terrible at doing numerical work, as it poor at mutation. You can work effectively with lots of big matrices if you don't allow easy access to mutation.

> Lots of valid code, won't pass the type checker. That is the problem with static type checkers.

I fail to see this as a problem. It's pretty much a feature, just as you don't expect object oriented languages to tolerate any shit you throw at them when you use the OO model.

> I just don't think static typing is the silver bullet that many of its proponents think.

You're the one making the case here, before answering it.

> Haskell e.g. is just terrible at doing numerical work

I've had good experience with https://wiki.haskell.org/Numeric_Haskell:_A_Repa_Tutorial

> Lots of valid code, won't pass the type checker

Perhaps you could give us an example of code you want to write that doesn't pass the type checker.

We already know about the case of maps, but it's been pointed out that is solved by row types. A different example would be good.

> turn off our brain and apply type verification everywhere ... type verification more like a religion than a tool.

A statically typed language can allow us to use dynamic typing if we want. For example, using a map of variants as a query result. Programming with maps of variants is even perfectly possible and pleasant in Haskell. Dynamic typing is not unique to dynamic languages!

Reply on news.ycombinator.com