The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Android, evolvability & comcast

One of my best friends in college decided to get all his calories from chocolate-chip-cookie-peanut-butter sandwiches for a whole quarter. In case youre imagining bread in there, no: its just peanut butter between two cookies. As an experiment, he also went all quarter never, or seldom, washing his hands. We lived in the same dorm and you could tell where hed been by an oily glitter on banisters and doorknobs.

The visceral reaction youre having to that image? Thats how I feel every time I interact with the java ecosystem, and android has been even worse.

(Scroll down to Constructive criticism at the end to skip the argument and go straight to the punchline, which is that we need single-file builds in android).

This doesnt feel like programming

Earlier this year a project needed an android app and because it didnt have to look good or work well I elected myself to build it. It was traumatic so I took copious notes, summarized here:


Around the end of this experiment I read an article about life, physics and the concept of evolvability. Evolvability, as I understand it, means that a single token (or single base-pair) change in a set of instructions can produce:

The third option is the most evolvable.

A web-oriented example: changing one byte of a PNG will change a color, create visual artifacts, or create an unprocessable file. Changing one byte of an SVG file could change the radius of a circle.

If youre new to this concept read this 2013 paper on producing modular gene networks in simulated environments.

One liners matter

Java is pretty bad at producing portable one-liners. In my opinion thats because of the public/private feature (completely unnecessary), a fixation on classes being somehow related to files on the filesystem (who cares what file somethings in), and a cultural preference for hard-to-use, one-off constructors.

Android, which is the combination of java, gradle, android studio, the android libraries, and the layout system, is even worse. Tying everything to contexts / fragments / activities makes android constructors even less reusable than POJO. Harnessing the XML layout system to code is also way too hard creating a custom widget, for example, requires several files.

This is half technology and half culture. For some reason when I write a line like WhateverClass wc = new WhateverClass(); android studio wants me to split it onto 2 lines. wtf.

Switching back to evolvability needing to paste in several lines of junk to use a feature in a new context has two bad side effects:

  1. Cost to change: the reason java has relatively good refactoring tools is because better languages can do the same job with find-and-replace or indirection
  2. Compatibility / reusability: highly-customized, expensive-to-instantiate (in terms of lines of code) classes are more likely, in my opinion, to rely on some special member or local and be unusable in other contexts. Leading to over-specialization.

I dont think one-liners is a realistic short term goal for android theres too much kruft in the standard library. What is a realistic goal? Keep reading.

Constructive criticism

When I get the call from Gs android team to build a better buildsystem, what will I do in month 1?

We need to be able to build apps from a single file. Thats the low-hanging fruit for android improvement. Bonus points if a small app (< 500 lines) can build in under a second.

Why is this important?

Continue reading on