Discipline Doesn’t Scale

Discipline Doesn’t Scale
sicpers.info

What grieves me is lack of inquisitive ness and communitcation. If we're not deepening our understanding of how things work, and working together, then things get wobbly.

True story: delimited text data ingest file. Guy wrote a C language file to hack the upper byte off the characters, and then write them back to disk. At a glance we think "C! This was a performance thing." Except laboriously writing each character after hacking it in twain and discarding the upper byte isn't a performance hack. It's a "didn't RTFM on the python open() command and try the encoding argument, so we did a C hack" move. Encoding="utf-16" worked great.

I'd take a victory lap, except for every time I'm clever, there are two where I look an ass.

Discipline may not scale, but teamwork and inquisitiveness paper over a multitude of shortcomings.

I think that the article misses two points. In one side the more accessible writing code is, the better. To reduce the amount of knowledge and discipline that you need to code is good.

On the other side, discipline is still needed to design APIs, or just to maintain consistency between calculations and data as it moves thru your system, or keep technical debt in check.

> does that mean our tools should not let us write code for which there’s no test?

That depends on how your team/company wants to work. If you are doing Test Driven Development, it seems good that the tool forces you to do the test first. But, TDD is not the only or best way of developing software, so generic tools needs to support different paradigms.

I love code formarters for all this reasons. They relieve developers of the need to follow some basic code style guidelines, you use less self-discipline on writing good style and more on writing good APIs. But, to have a code formatter you need an agreed standard.

I try to make to write code easier for myself and other people, because implementing business requirements is already hard by itself. The more time you have to spend "coding" and the more you can spend thinking, the better.

The encouraging thing today is that we're kind of converging on good practices in language design.

- You really want to declare types for function parameters. The compiler needs that information for checking, and the programmer, and the maintenance programmers who follow behind, need that information so they know how to call the thing. On the other hand, you can usually infer the result types of expressions by a simple forward process. So C++ gained "auto", Rust and Go started off with that arrangement, Javascript got TypeScript, and Python is getting there via a side trip through unchecked type declarations.

- The three big questions in C: "How big is it?", "Who can delete it?", and "What locks it?" C gives no help with any of those. C++ now tries to address the first two. All the garbage-collected languages address the first two. Rust addresses all three.

- The idea that locks should be connected by syntax with the data they are locking took far too long to become accepted. Partly because the Ada rendezvous and the Java synchronized object didn't work well. Even Go doesn't do that very well. But language design seems to be coming around. When and if thread-type concurrency comes to Javascript, the webcrap crowd will create race conditions everywhere without automation in locking.