Skip to content

Latest commit

 

History

History
124 lines (95 loc) · 5.04 KB

2024-03-14-what-if.md

File metadata and controls

124 lines (95 loc) · 5.04 KB
Raw
title categories
What if...?
programming

From time to time I like to revisit best practices and look for counterexamples, or success stories of projets that did exactly the contrary.

Sometimes, just rewriting the opposite, and see how it develops.

I feel it gives ways to discovering non-euclidean programming rules, and it's pretty fun anyway.

Programming at max revs

What if programming at the max capacity of your level was ok: https://www.linusakesson.net/programming/kernighans-lever/index.php

Write dumb code

Write dumb code: https://news.ycombinator.com/item?id=39503777 , there are some comments like https://news.ycombinator.com/item?id=39507108 where kazinator makes the point that some problems are hard, and by making the code "simple" on the surface, it's not possible depending on the domain.

There are a few things I see here:

  • The waterbed theory on one side, where a problem has inherent complexity, and at some point, if you push complexity down in one place, it will appear in another, so thinking in local optimas is not a good thing.
  • Sometimes it's clear, that something is overly "complex", and the code could be simpler while doing the same. That is also a very personal take on design. Some people don't care about nesting ifs and think that they give clear mindmaps, and some other people will frown upon them, saying it just clobbers the "meaning" of the code. Same with naming vs nesting temporary variables.
  • Dumb code (code that any junior can understand) has a trap inside. Using less powerful primitives makes repeating oneself a part of the deal. Brainfuck is the simplest language I know (it's like a turing machine). And even reading bf could be considered "easy", in practice, it's not. Higher level constructs help us convey meaning in ways that simple code can't.

So "Write Dumb Code", yes, but that sentence is just pushing words around, not solving the issue.

Code is not read more times than written

I'm still shocked by this comment in HN by gitonthescene:

"In my professional experience most code never gets read by anyone other than
the original author and when it is read it's often reluctantly. If you
have any links to studies which show that code is read more often than
it is written, I'd be interested to read them."

It's something I never thought it could be true, but I respect that user (he's on the k scene, and definitely has coded a lot), so I'm trying to see how the world looks if this is true.

Do one thing and do it well

Do one thing and do it well. This is the motto of unix, and a basic tenet of programming (broader than just in CleanCode).

I've blogged about it before (in my old blog), but Emacs or Perl don't obvey that, and they do it in a very conscious way. I read the foreword to Learning Perl by Larry Wall, and it explains in such an artistic way why orthogonality is not always the optimal way to get things done.

Regular expressions should be used only for very simple matchings

Becuase the complex ones are bug prone

If you have a bash script longer than X lines, rewrite it in Python

I say it's obviously been proven that's not the case. Same as with sql and pandas. Sometimes ppl state that for anything more complex than X, sql is not enough. And while it might be true, depending on how dextrous you are with the tool at hand, you can stretch that tool's sane usage by a lot.

Sometimes it's by recurring to ugly wizard non-documented hacks, but most of the times the tool was able to do that thing from the get go. You just didn't know. (trivial example is usless use of cat)

What if programming wouldn't be like LEGOs, but play-doh?

There are a bunch of blogposts around this, and none that comes to mind now, but in the latest arraycast, there's some discussion about it on the second half of the episode.

The right tool for the job (kinda repeated)

Python is the second best langauge for everything, boring technology, use postgres for everything...

Or, using superspecialized tools, one thing at a time.

Going up through the ladder of abstraction vs keeping down on the ladder

Sometimes, generalizing by keeping down is more powerful, while going up is most of the times constraining.

In array programming languages, keeping abstractions low ensures that you don't create incompatible things, and let suggestivity flow freely.

Going up through abstraction makes the system more robust vs less

You can't build on shaky abstractions to make more robust abstractions. That's an "additive" view of things. Like,

  • working with total functions is ok, but once you taint it with some discontinuity (throw exception?), then you can't rely on that property anymore.
  • colored functions ....

But, there are cases where you can go up through the ladder of abstraction and get more robust stuff. Like,

  • erlang
  • retries
  • tcp/ip (see joe spolski's leaky abstraction article)