prefer duplication over the wrong abstraction

From: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction

1. Programmer A sees duplication.
   
2. Programmer A extracts duplication and gives it a name.
   
   This creates a new abstraction. It could be a new method, or perhaps even a new class.
3. Programmer A replaces the duplication with the new abstraction.
   Ah, the code is perfect. Programmer A trots happily away.
   
4. Time passes.
   
5. A new requirement appears for which the current abstraction is almost perfect.
6. Programmer B gets tasked to implement this requirement.
   
   Programmer B feels honor-bound to retain the existing abstraction, but since isn't exactly the same for every case, they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of that parameter.
   What was once a universal abstraction now behaves differently for different cases.
7. Another new requirement arrives.
   Programmer X.
   Another additional parameter.
   Another new conditional.
   Loop until code becomes incomprehensible.
8. You appear in the story about here, and your life takes a dramatic turn for the worse

Book: Amusing Ourselves to Death

You've read 1984, you've read "A Brave New World", you've read "The Information" (you should), you've read McLuhan, and you want more connections between those, Amusing Ourselves to Death. It's like a missing (darker) chapter from "The Information", or an update to "A Brave New World".

Filled with data, and very up to date (being written in 1986).  I'd love to see an extension to it talking about the nonsense of information flood and "And now ... this" we're in now.  Neil Postman hints at gamification without naming it and speaks with great clarity about the continuous amusement we're in nowadays. Slot machines aren't mentioned in the book, but the fact that now we know many successful platforms/services/soma base engagement on the same algorithms than slot machines makes the book scary when looking at both directions from when it was written. Both as constataion of facts and premonitory.

Here's a very nice review about it, (funnily enough with nice pictures to help the reader)

A Philosophy of Software Design

I finished "A Philosophy of Software Design" by John Ousterhout (creator of tcl): https://www.goodreads.com/book/show/39996759-a-philosophy-of-software-design.



The book contains some tips and tricks to keep complexity low, and some concerns against some mainstream trends (agile, short methods, etc..). 

I was expecting a bit more, given that the trigger for me was this review [https://lethain.com//notes-philosophy-software-design/]  that already covered 90% of the value of the book.  

The author did a talk (https://www.youtube.com/watch?v=bmSAYlu0NcY) which covers also many of the good points.

Overall the book is a nice conversation starter. It's packed with good advices but it feels a bit short and sometimes simplistic. Maybe it's removing complexity even in the tips, so keeping it "obvious" is part of the magic. 

I'm still deciding if it's meta-genius.

overlapping screens

I recently bought a screen, and funnily enough, this shiny new thing is not sufficiently tall to be placed just behind my laptop screen without overlapping.

The bottom centimeter of the screen is behind the laptop screen.

And this is a huge problem because emacs' minibuffer is what is hidden.

But luckily, ratpoison has this option called "padding".

set padding 0 0 0 50

Maybe it's clearer with a picture.

So this is my stupid trick of the day.

Yes, books would work too.

Regex madness

I'm a big fan of regexes, the problems they solve, and the problems they create. It reminds me of Perl :p

Lately I've encountered a couple of very twisted uses of them worth a post.

First of all is a very nasty way of using the regex engine as a sintactic transformer that ends up validating arithmetic operations. Totally nuts.

• http://www.drregex.com/2018/09/a-regex-i-submitted-to-reddit-climbed.html 

Second one is a kind of "sed for power users". It's about internals of sed at a user level (as strange as it seems).

• http://tech.bluesmoon.info/2008/09/programming-patterns-in-sed.html 

After reading drregex post I started hunting for that Abigail's slides on how to solve sudoku using regexes.

• http://perl.abigail.be/Talks/Sudoku/HTML/index.html 

And here is Brian d Foy explaining how to parse json with a single regex.

• https://www.youtube.com/watch?v=-O-Uajd2WzU 

Last one is my metaII bootstrapping parser. A single regex to bootstrap the metacompiler. I guess it also counts as crazyish.

• https://github.com/kidd/meta-II/blob/master/metaII.pl

e{vil,macs} macros

Macros are a powerful tool. I personally prefer vim-style macros although they're less powerful than emacs'(as I don't usually need anything on the surplus of emacs' macros features, I'm good with that).

Here's something I noticed today when using evil macros.

In vim, when you record a macro, you do it specifying a register where you want it to be stored. And registers are used for both copying/pasting text and storing macros (it stores the keypresses, so it's all text!).

On the other hand, a nice thing about emacs macros is that you can fine tune a macro in a very user-friendly way with kmacro-edit-macro.
Evil macros are a kind of hybrid between the two, and stored in an evil register and also as an emacs macro, so kmacro-edit-macro will give you the last macro you created, even if you created it with evil. The "problem" is that it doesn't update the evil register, so once the macro is defined for the first time, both macros (emacs kmacro and the evil register) are completely detached, and modifying one, does not modify the other.

I guess this is the right thing to do, because entangling one with the other could have many unexpected effects.

Along this experimentation, It's worth noting that editing the macro "the vim way" works great. kudos to evil devs again.

 So given we have stored the evil macro in register 'q':

1. "qp to paste the register q. 
2. edit the line - select the characters of the macro. 
3. "qy 
4. @q