Comment by pmjordan | Hacker News Reader

Comment by pmjordan | Hacker News Reader

Parent Full thread

But a good program is a program that works, so we need to achieve that first. :)

The thing is, static typing addresses this on the microscopic scale, where it's not difficult to make code work anyway - except maybe for novices, hence my "training wheels" analogy. I don't see any evidence that it helps correctness on a more macroscopic scale. In fact, it makes code more verbose, which makes it trickier to take in all at once.

EDIT: rather than just hating on static typing, I propose this:

How about making our languages more expressive? I don't think exceptions (try/catch/finally) are anywhere close to a global optimum for error/edge-case handling. Maybe there's no silver bullet, but I'm pretty confident we can do better than current exception handling. I hear Common Lisp 'conditions' are resumable, which sounds nice, but again only useful if you can reasonably substitute a value of some kind, a bit like the TLD example. What mechanism should we have if we really want our program to do something else in exceptional cases?

Conditions can do a lot more than substitute a value. Think of it like an exception in reverse, you can resume with different "types" that cause it to take a different path. And they might pass new data in.

Say you have a function that is basically a loop processing a list of files, it throws some kind of "file not found" error. You could sort the file out and do a resume "try again", select a different file and do resume "diff file (filename)" or do resume "skip".

Regarding "It makes code more verbose": while "new JSome<LongSuperclassName>(myValue)" is certainly more verbose than necessary, I still think that the one bit of information "this method returns Foos" vs "this method returns Foos or nothing" is worth documenting. And in a statically typed language, the type system is an obvious place for such documentation.

Sure, if you're already going to go to the trouble of having type annotations for everything, adding an extra '?' (like in C#) isn't going to break the camel's back. It's the unboxing and wrangling with the returned value that make it more verbose.

As far as I can tell the only statically typed languages that stand any chance in terms of terseness are those with sophisticated type inference. In that case, "can return null" or not makes a lot of sense for auto-generated documentation or making it an error to compare the return value to null.

There is bound to be some wrangling with the returned value if the case of "something was returned" needs different treatment from "nothing was returned" in the program's design.

However, I agree that

      match perform_foo() with
          | Some x -> do_something_with x 
          | None -> do_without

looks a lot less messy than

      JOption<Bar> baropt = performFoo();
      if(baropt.isNonempty()) {
         Bar bar = baropt.getValue();
         doSomethingWith(bar);
      }
      else {
         doWithout();
      }

There's just something deeply unsatisfying with a statically typed language that requires so much legalese and boilerplate as Java while still permitting surprising runtime errors in virtually every executable line of the program. Abandoning static types is one approach to the dilemma, trying to plug hole by hole is another.

Reply on news.ycombinator.com