Friday, August 25, 2017

The Pain of Not Knowing

We’ve been rewriting a site with React, which I never actually looked very deeply into.  I heard it was a “framework” and expected it to be, more or less, Client Side Rails.  So I assigned it, things happened, and many surprises were had.

One of them was that, in thinking about React as a framework, I missed the need to specify that it should act like it belongs on the Web, with linkable pages, and stuff.  We got to the end of the road and the developer was surprised that completely lacking deep links wasn’t what I had wanted or expected.

This confused me, because we have another site that we’ve been wanting to rewrite for a while.  There’s a decent list of complaints about it, and I thought he understood them, especially that it’s a single-page app written in one huge mass, that never updates the URL bar.  There aren’t any seams to pull it apart and replace things gradually.

I guess not, because he wrote this auxiliary system as a single-page app in one huge mass, that never updates the URL bar.  It took us nine months or so to get this result, and something so fundamental as request routing would basically require a rewrite.  Which I don’t think we have time for, and besides, the developer is burning out on frontend work as it is.

tl;dr: you can’t actually manage what you don’t understand.  Or you can try, but it’s going to be incredibly inefficient.

Sunday, August 20, 2017

Types as Communication

In my last post about static typing, I missed something.

My current employer is larger than any previous employer I’ve worked with, at least on the tech team side, and I’m getting a lot more interaction with other programmers.

Mostly, they’re a pain… because I have a tendency to nano-optimize for fast. Following the ground rules, my PHP code is fairly likely to cheerfully Do The Wrong Thing™ if it’s passed some incorrect type. It might leave Important Data blank, or outright crash.  My general attitude was, “Don’t do that, then!”

But I can also see that it’s a drag on other people.  They write code, it looks reasonable, maybe it even runs, but it quietly gives an unexpected result.  I wrote some code that took an int to pack into something. When it received a string, it would silently pack 0 instead.  Fortunately, the developer realized they were making an assumption, and checked it before that bug made it toward testing or production.  A different developer may have rushed on ahead and released it.

This leads to an intriguing property of static typing: the types become an additional point of documentation between programmers.  And unlike doc comments, they never go out of date if the compiler insists on their correctness.

The stronger the type system, the richer that communication is.

Which means that the most interesting comparison is not along the lines of Python vs. Java, but Python vs Haskell.  How easy is it for a team to work on a Python codebase, compared to Haskell?  How easy is it when the code is 2, 5, or 10 years old?

Saturday, July 8, 2017

Trying F# for static types and functional programming

Between all the ado about monads and rereading a literature review of static vs. dynamic typing on Dan Luu’s blog, I decided to take another swing at both static typing and functional programming in one go. I built a thing with F# because, well, I’m not really sure.  It sounded cool, and F# for fun and profit had a lot of pragmatic articles about it.

Sunday, May 14, 2017

Reflections on Work (as our codebase turns 10)

I’ve been at my current employer for over seven years.  We’ve been building and maintaining all the code around the business this whole time, and I’d like to think I learned something worth sharing…