Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple Is Not Small

jyn.dev

Post reply on HN
Print view View original

31–40 of 95 posts

Re: Simple Is Not Small

#31

Post by simongray »

embedding-shape wrote: post #5

Important to note as well, is that "simple" isn't "lesser" or "dumber", it can be "more" and "wider", yet still "simpler". 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 ultimatel…

He's speaking at the coming Clojure Conj, so there will be a new talk soon.

Re: Simple Is Not Small

#32

Post by Anoian »

I mean I am not part of the same company, so I am just talking out of my butt, but I cannot imagine a dev worth their money taking more than two weeks, to fix a bug, especially today with AI assistance, most bugs are found the same day, the gnarly ones maybe take two days and in my lifetime as an engineer (10 years), I have not yet seen a bug that took me more than a week.

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

Re: Simple Is Not Small

#33

Post by sodapopcan »

aghuang wrote: post #21

Simple never means it is easy and it is always the biggest misconception in software.

That is an understatement! And not only that, "simple" is relative. The common saying that gets push back is "Do the simplest thing possible." People always seem to ignore the "possible" part of that phrase. Forgive me for being a little cute here, but a complex solution is simpler than a really complex solution.

Re: Simple Is Not Small

#35

Post by pianopatrick »

I've been thinking about a new AI based dimension to this. If your program is split into smaller decoupled "modules" then all the code for each "module" can fit into an AI context window. In this way the AI can have all the context to edit a "module" by just loading all the code for that "module". You would not need things like vector search as much. If we assume 20 tokens per line of code and the AI context window is 100k to 1M tokens, then that would argue for having "modules" between 5,000 and 50,000 loc, depending on which AI model you are using.

Re: Simple Is Not Small

#36

Post by zkmon »

Complexity (the opposite of simplicity) has nothing to do with the size of a program, but usually there is a high chance that a large program is more complex than smaller one, purely because the complexity multiplies, not just adds up.

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

Re: Simple Is Not Small

#37

Post by Twey »

> The reason for this is that in Rust, a struct couples type-checking to a fixed data representation. You can't get one without the other.

> 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.

Re: Simple Is Not Small

#38

Post by lilli_put »

I think that you can elegantly implement the second problem in bash:

  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
  }
Used grep here because the original pipeline erroneously introduces an empty line when the file starts with a character that doesn't match '[:alpha:]'.

Re: Simple Is Not Small

#39

Post by aozgaa »

FattiMei wrote: post #30
JoachimSchipper wrote: post #19

The general point is true, but the shell pipeline gets a lot more elegant if you use the sort-and-accumulate paradigm that the classic shell utilities were written for (which uses O(1) memory, by sorting on disk). Using mostly the author's own code, and adding --count to uniq: tr (Where the final awk papers over the fact that we're mixing tabs and spaces here; obviously, awk is also good at doing the accumulation ste…

Very interesting solution, and in the spirit of the original article. If I understood the snippet right, you are sorting the input sequence on the first column (the words) and then on the second one (the frequencies) It is nevertheless "complecting": the uniq assumes the data is sorted and the columns of your data structure move together. Maybe this algorithm is already complex regardless of the implementation. btw,…

the point is to do a stable sort on (word, line number) lexicographically, then when we do "uniq" we can take the first line number.

In contrast to the "we need a frequency table" idea in the article, this solution trades off memory by transferring all the line numbers in the stream. This is very much in the spirit of the infamous McIlroy/Knuth "bakeoff"[1] -- tradeoff some efficiency (via extra book-keeping or sorts) in return for composability.

Agreed, very neat.

[1] https://homepages.cwi.nl/~storm/teaching/reader/BentleyEtAl8...

Re: Simple Is Not Small

#40

Post by aozgaa »

Another solution to the pipeline example, this time making use of a subprogram for the frequency/accumulation:
If you don't allow `awk` in your "pure bash" then ofc this is not satisfactory. But it has the upside that the associative arrays are pretty explicit data structures (for the ordering and counts, respectively).
Post reply on HN