Re: [tlug] "Go Considered Harmful"

["Curt J. Sampson" <cjs@example.com>]

On 2020-09-02 09:13 +0200 (Wed), Josh Glover wrote:

> I'm really not convinced by this argument. Strong type systems look great
> on paper, but I personally haven't seen that they make my code better or
> safer.

I have personally seen this, though; a good type system makes code not only
better and safer but easier to write and shorter.

Being able to clearly express even not-so-complex data structures and being
told, when you describe invalid data, that it's invalid and how, has saved
me countless hours of wondering what the heck in my code went and broke the
invariants I was trying to maintain. And, of course, it means you need a
lot less in the way of tests.

The difference is kind of similar to using a class with accessors for its
properties instead of just a dictionary of names and values (which in turn
are sometimes more dictionaries). Sure, you can always substitute the
latter for the former, but most people seem to prefer the former for any
data structures that are not completely trivial.

(Where it's not similar is in the amount of work it takes to build a class;
`data Tree a = Leaf a | Node (Tree a) (Tree a)` in Haskell is giving you
whole bunch of constructors and deconstructors that you'd have to build "by
hand" in Python or Java, the deconstructors often repeatedly throughout
your code using that data structure.)

Often extenisve compile-time type checking doesn't _feel_ like it's making
coding easier, though, even to me. For whatever reason, an hour of running
a set of tests every minute or two, most of which are passing, feels much
more like you're making forward progress than an hour of tweaking things
here and there until they compile, even though in both cases you were
broken for an hour before you were working.

> I really think it boils down to preference; some people's minds seem
> to gravitate towards strong typing, and others enjoy being able to shape
> the Matrix as they see fit. ;)

Except they're not able to "shape the Matrix as they see fit." In _certain_
ways they can do whatever they want, but there are other things that they
can't do, such as easily say "Ensure that my tree's interior nodes can
never reference anything but a (sub-) tree of the same type."

> ...she said that she prefers...Clojure when she's doing either
> exploratory programming or trying to solve a problem that she doesn't
> know the solution too yet.

Well, this is not something I would criticise without actually working with
someone to see how they do exploratory programming. But there's a very
common trap that people fall into where they tend to mentally consider just
the code that runs at runtime to be "the code" that they're writing, and
type definitions to be a sort of side thing that's not the actual
programming. And that's probably often true in languages with relatively
low-powered type systems because you can't express a lot in those type
systems. But in Haskell I found that at least a significant minority, and
sometimes the majority, of my "programming" work on a particular thing was
in writing the type definitions, and the rest of the code was almost
trivial or an afterthought in comparision. There were certainly cases
where, when getting to the runtime-level stuff, I was tired and basically
typed without much thought whatever seemed like it might be kinda the right
thing and repeated until the compiler stopped spitting out errors. That
often doesn't cause problems because all the real programming work had been
done when I was writing the type definitions.

> She said that she appreciates the type system eliminating certain kinds
> of errors she would otherwise make, but that matters a lot more in the
> case that she's implementing a known solution.

> The rule of thumb in Clojure is data structures over functions, and
> functions over macros.

Well, that sounds to me like the rule of any decent Lisp programmer, or any
functional language programmer for that matter. ISTR Paul Graham saying
something along the lines that he rarely had more than a handful of macros
even in a large program.

> Maybe Steve has lost his edge... ;-P

Well, he is an old economist now....

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch