Simple Is Not Small

MIT/Stanford:

> Simplicity -- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

New Jersey:

> Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

TFA maps "simplicity" to "MIT/Stanford simplicity" (simplicity for the user) and "smallness" to "New Jersey simplicity" (simplicity for the developer).

I wonder if the root of the tension between the two schools comes down to the ambiguity of the user/developer distinction. Developers are also users. Simplicity of implementation is helpful to developers when they are working directly on implementation, while simplicity of interface is helpful to developers when they are using other developers' work.

[1] https://dreamsongs.com/RiseOfWorseIsBetter.html

One of the core features of the Unix command-line is that it is user-extensible. If there's no "native" command equivalent to frequencies, you can write your own, and it will be given the same first-class treatment as any other binary in your PATH. This is entirely in keeping with the Unix philosophy of simple implementations.

I am currently building a piece of very modular software and it has been the hardest-to-design project of my entire career. I would never be allotted this amount of time-effort at any job I have held to make something this robust and clearly defined. Many aspects of this project have taken 3-5 rounds trying-and-trashing to get an abstraction that is uncomplicated.

This is precisely why vibe coding is so successful for building tiny isolated scripts, and so disastrous for anything else. It's just really dang hard to build something large and simple.

> Clojure decouples data representations from type checking.

This is funny to me because seen from the other side, (this) Clojure couples runtime type information to data structures: you're no longer allowed to define a data structure that doesn't have some runtime type information attached. A fixed static structure is just the consequence of not adding dynamic type information.

Meanwhile in Rust you can get type-checking ‘without’ a fixed structure by using trait objects.

Expectedly, Rich Hickey explains it best, watch the "Simple Made Easy" talk if you haven't before, one of the few talks I probably watch bi-yearly: https://www.youtube.com/watch?v=SxdOUGdseq4

Few things, concepts and ideas have changed as much of my programming mind as Hickey's talk and ultimately Clojure have done over the years.

Wish we had new amazing Hickey talks to link to, maybe it seems he's about the hang up the hammock perhaps?

Copy pasted functions with subtle changes mean you cannot reuse the proof (DRY). Giant functions with lots of if/else statements however might cause a branch explosion in the proof. The right abstraction removes lots of assumptions that a proof could depend on, limiting the search space and often forcing elegance (this also applies to math, eg. when reasoning with abstract groups instead of integers). The wrong abstraction might force case distinctions on consumers of the abstraction.

This specific usage appears to come from this linked talk, Simple Made Easy:

https://www.youtube.com/watch?v=SxdOUGdseq4

My reaction to the Unix pipeline was that, the reason it exploded in complexity is because the pieces were too simple. They were insufficiently expressive.

But the word is used in a different way here, and I'll have to watch the talk to understand what exactly is meant. (Something like orthogonality?)

It is especially dangerous when something is "good" and people try to appropriate the term to appropriate the goodness of the term, as if goodness flows from a term to the thing it is attached to rather than the other way around. "Simple" is good so my good thing must be "simple" to be "good". But it doesn't. Simple can even be bad, in the wrong place or in the wrong sort of "simple" for a given job.

These concepts simplify for the user these questions: “I know what I want - how do I make the program do it?” (Execution) and “The program did something — what state is it actually in?” (Evaluation)

I believe the author was getting at these concepts, especially in their Google Drive example - how the large program has a “small” UX. Understanding the domain model provides a much stronger basis for designing user interfaces, and understanding the Gulf of Evaluation/Execution allows you to build incredibly complex-looking, large UX’s without confusing or overwhelming the user.

A single regex line could be far more complex than a 100-line java program.

  grep -Eo '[A-Za-z]+' README.md \
      | tr A-Z a-z \
      | {
      distinct=()
      declare -A freqs
      while read word; do
          [[ -v freqs["$word"] ]] || distinct+=("$word")
          ((freqs["$word"]++))
      done 
      for word in "${distinct[@]}"; do
          echo "${freqs["$word"]}" "$word"
      done
  }

The clojure expression reads the entire file into memory first, and then operates on that memory representation.

The pipeline processes the input in chunks. The two `sort`s might read the entire contents into memory, but an implementation like GNU sort will instead, for large inputs, create temporary files for sections of the input and then merge sort them to the output.

You could make clojure do the same thing, but it might not be as "simple" as the pipeline.

    tr < README.md --complement --squeeze-repeats '[:alpha:]' '\n' \
    | tr A-Z a-z \
    | nl \
    | sort --key=2,2 --key=1,1n \
    | uniq --skip-fields=1 --count \
    | sort --key=2,2n \
    | awk '{ print $3, $1 }'

(I originally posted the above as a comment on lobste.rs, on this same article.)

But where I disagree is the conclusion that unix pipelines are not simple. IMHO unix pipelines as a platform are incredibly simple and powerful, allowing for solving a massive range of small problems much more elegantly than any general purpose programming language. Obviously the constraints that enable this simplicity at the low-end, are real tradeoffs that prevent simplicity at the high-end. But one of the core principles of effective engineering is do the minimum to solve the problem at hand, no more, no less.

Logic that the blog presents is sound; but sometimes small works as a good-enough proxy to get to the simplicity that we find elegant.

I like this question. Some projects will sacrifice usefulness in the name of simplicity.

I don't see how the example would benefit at all from having that information at run-time when it exists at compile-time. The problem with Rust specifically I think is that it's a relative PITA to get to the information that exists at compile-time in this case. In Zig, you'd just iterate over the fields using the same language you use for run-time code.

    const fields = std.meta.fields(@TypeOf(instance));
    inline for (fields) |field| {
        const name = field.name;
        const value = @field(instance, name);
        std.debug.print("{s}: {any}", .{name, value};
    }

    < README.md \
      tr -c '[:alpha:]' '\n' \
    | tr '[:upper:]' '[:lower:]' \
    | awk '
        NF {
          if (!($0 in count)) order[++n] = $0
          count[$0]++
        }
        END {
          for (i = 1; i <= n; i++) {
            print count[order[i]], order[i]
          }
        }
    '

The Unix pipeline and the similar-looking Clojure expression are entirely different in how they do what they do. Pipes are process abstractions. The (perniciously improperly understood) "pipeline" macro is not pipelining anything in any way (not CPU nor process nor memory). It is merely syntax sugar to write a deeply nested call chain as a "flat" list of operations.

And it goes on to compare "ugly" code, again making the category error that "more" code is "worse". Because, one is swapping / splicing entire programs within a pipeline. Also, there are plenty of ways to slice that mango; you don't need temp files.

That said, having intermediate files in one's pipeline is a big help because one can use those to make pipelines idempotent. Plus, one doesn't need flat files, one could swap in a SQLite cache too, at will, without modifying anything else in the pipeline. This kind of design change is not possible with the equivalent Clojure function call chain, as-is. In fact, having such a requirement (one always finds need to restart processes after crashes, and have them pick up from where they died) causes us to write some custom (and therefore design-wise brittle) conditional restart loop on top of the computation to manage its failures inside the running program. An idempotent Unix pipeline simply needs to be... restarted from outside the process.

In this particular case, a valid complexity complaint would be about the lacunae of the Bash / shell programming language (and interpreter model) versus the Clojure language.

Also, again from a program design point of view, I feel there's a bit of "holding it wrong" going on there... Bash / Shell-fu, yes, but not enough to be dangerous (for example, sort | uniq | sort is a standard idiom of pipeline programming). Which claim is personal, and so I'm open to being corrected at the same level. Sources: my code and writing:

https://www.evalapply.org/tags/bash/

https://www.evalapply.org/tags/clojure/

https://github.com/adityaathalye (the pinned repos are Bash and Clojure)

And specifically, this log processing code, for a more apples-to-apples comparison with OP's post.

https://github.com/adityaathalye/bash-toolkit/blob/master/lo...

  deduplicate() {}

  frequencies() {}

  drop_first_n() {}

  drop_last_n() {}

  drop_header_footer() {
     drop_first_n "${1}" |
         drop_last_n "${2}"
  }

  window_from_to_lines() {}

But they are.

UNIX Pipes do not mandate having to use tons of different programs with stupid commandline options. I simulate them in ruby itself; method chaining works in a very similar way, but I built a pseudo pipe around it. The idea was more to have an object oriented shell, e. g. combine good ideas from UNIX pipes and the MS powershell.

They are simple if you design them well and have them be flexible too. The reason UNIX pipes were awkward is because they delegated onto many different programs such as awk or sed with their own strange rules. Nowhere does it say you HAVE to use such awkward tools. Use better tools and the idea of piping becomes simple, similar to (a more flexible variant of) method chaining. Just without being tied down to a specific object per se (I do use the pipe-handler master object to handle the pipe instructions; each pipe instruct I call cmdlet, e. g. shorter for commandlet, as this is how I like to think about this in terms. This also combines e. g. virtualdub + avisynth ideas. I loved them when I used windows. The idea behind avisynth is great - not necessarily all of the syntax, but the idea that all multimedia audio can be operated on at all times in flexible ways.)

Somehow when things get complex, I could never find fully functional style to be more understandable than imperative

1. "You need to have taste (so: experience) to do DRY right". Same chunk of code more than once, so natural/expected behavior is to export to a helper... Aaaand the now introduced coupling is (too) often ignored, as in "no thought given whatsoever".

2. "Sometimes it's better to just leave it as is". 95% to 98% of "same chunk of code" in a number of places. The temptation to DRY is strong, yet the "numerically mere 2 to 5 pp" make the extracted helper an exercise in all manners of gymnastics. The only correct answer is: do not start.

(Own experience; your mileage may vary - if it does, feel free to comment back!)

> That's because our original program was small but not simple.

I would say no - because it was inflexible.

This is why I think the formalists studying complexity back in the 50s had the right approach. You can only give "simple" precise meaning within some kind of formal system with a shared set of initial axioms or assumptions. From that point you can define it quantitatively over some set of objects (relations, programs).

Funnily enough, this approach also touches on Hickey's etymological derivation. The root words also fundamentally have to do with the quantity of relationships.

Taking 9 months to fix a bug sounds alarming to me.