Comment by cryptica | Hacker News Reader

Comment by cryptica | Hacker News Reader

Parent Full thread

The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements.

I've seen this over and over in my career; tools can make people lazy in certain areas, it can put them on auto-pilot. Often, this can be a bad thing.

I like coding with dynamic languages because they get out of my way and shift the full responsibility for correctness on me. This creates a certain mental tension which helps me to perform. Keeps me alert and mindful.

I particularly try to avoid languages that make me wait for code to compile (which is more common with statically typed languages); this is for the same reason why don't like it when someone distracts me while I'm "in the zone" while coding.

This is the opposite of my experience. In practice, being forced to deal with edge cases makes you find implementations that eliminate them because dealing with each is painful.

This is a wrong and surface-level reading of the original post. If there are "cases" in a system, then there are going to be "edge-cases" as well. The problem is in classifying certain cases as "edge" and others as regular. We do this because the regular cases are very obvious and are either the perfect happy-path, or a failure condition that we would immediately consider.

But between these two exist a permutation of conditions that exists in the domain and often manifest in production. Either we can actively manage them thanks to types, or we can let it end up in production with hard-to-track bugs.

I've been translating a personal project (game engine) from a dynamically typed language to a statically typed one. Having to pin down what the types of function parameters are and spell out interfaces for objects has been eye opening. Using a dynamically typed language had made it way too easy to stuff things that didn't really go together down "the same pipes" of the existing object collaborations. I thought I was writing simple code, but it only appeared simple because I wasn't fully aware of the implicit (defined by behavior) types of my dynamic code. Granted the pace re-writing this with a statically typed language has been slow enough that I can't say whether it's a win overall; my point is just that it has revealed edge cases I never considered in the dynamic code. The argument you made that tools can make people lazy - doesn't that apply as well to dynamic typing?

Isn't this akin to saying I don't like wearing seatbelts because it makes me more complacent in my driving?

Someone once describing the forces acting on a race car pointed out that the horizontal forced in a curve were high enough to throw you from the car if not for the five point harness (F1 probably doesn’t have this behavior due to the cockpit design).

Sometimes safety equipment lets you go faster.

> Sometimes safety equipment lets you go faster.

Even simpler: brakes let you go faster.

When I was cycling a while ago, my brakes broke in the middle of a cross-country ride. I didn't want to push the bike back all the way, but you can bet your hat that I rode extremely slowly and cautious.

Both brakes broke, or the front brake did? You can get by with just the front brake. Question is if you had enough tools to do that surgery. Would depend on the brakes.

I don't think anybody remembers how shit bike brakes were before dual pivot came along. God bless Shimano and keep it forever. When I got my first set, I started emergency-braking with 2 fingers because I was worried I'd pole vault myself if I actually squeezed like I meant it. (I have high grip strength).

Was a 'flevo racer' recumbent bike that I was still repairing, and had only one brake (front) at the time.

I was only a few kilometres from home.

It could actually be the case that seat-belts make drivers more complacent but the key difference in the case of coding is that you won't die if you make a typo in your code. If designed correctly, your tests will catch it anyway.

Therac-25 [1] disagrees with your statement. Although to be fair, the programmer didn't die. The patients did.

[1] - https://en.wikipedia.org/wiki/Therac-25

Your tests? You should despise tests if you want to be consistent with the attitude described in your first post.

In the mean time I will just keep using my strongly typed language and, of course, also automated tests. Thank you very much.

The selling point of types (and type inference) is that they save you from having to write half your tests.

And of course, lines of code that you didn't have to write are less likely to have bugs in them.

This doesn't really make any sense. The idea that forcing you to handle all cases will encourage creating more edge cases is nonsensical.

Or perhaps it forces you to be alert and mindful of things that add no value, such as manually remembering to handle every edge case, and takes away focus from the problem in question?

Reply on news.ycombinator.com