Twitter is on the face of it such a simple application that it can be built in 40 minutes in Grails.

For a consummate software engineer with state of the art tools, building a twitter in clone 40 minutes that can scale... might even be easy today given a proper set of cloud enabled tools. But, even if it is an exact working copy of twitter and can scale to ten times the size of the current twitter... it's NOT twitter and will never be twitter.

Twitter is a brand now. It is more than merely a functional set of software performing a simple function. It is a user experience driven not by technology but by human interaction. That experience in itself constitues a wholly separate kind of real engineering.

In fact, if Twitter were to completely rewrite their application in a whole new technology stack, the net effect (providing only nominal interruption of services) would probably be zero on their brand. That's because aside from being a brand and an application Twitter is about doing something very simple (and rather boring to systems level folks) with your computer and with existing internet technologies.

So why aren't there a bajillion Twitter-like applications? Lord knows at one point people tried. Well there are, just none of them are mentioned on CNN and the Colbert Report. There was a time when Twitter was novel and now it's not. But, that doesn't matter anymore because we all know about Twitter.

It's just like Windows. Or Google. Or Kleenex. And all the interesting socio-economic issues that go with the success of a brand like Kleenex and the problems Kleenex has keeping people off its damn lawn. See, you can't call your tissue paper Kleenex because only we can call it that even if what you make basically is in fact the same thing.

You may not care if a tissue paper is of equal quality to Kleenex. You may choose to still buy Kleenex because you remember warm and fuzzy things about that Kleenex box. You know what to expect from a Kleenex box. You like Kleenex. So you buy it.

Whenever you consume something with an intent beyond the mere act of consumption then anything that distracts you from your end goal is a waste of attention. In this day and age we can't afford to pay much attention so we had better conserve it. Your customer service representative is there to try and keep you happy and consuming.

The same is true for technologists just as it is for any other demographic. When a technologist becomes comfortable with his favorite tool X no other tool can be as good as X even if it is better. That's because technologists get brand loyalty viruses too.

So I'm going to ask you... are you sure you like to use the tools in your toolbox because they are the best for the job or are you just buying Kleenex because that's what you buy? Is it worth thinking about?

Has someone moved computing beyond the Finite State Automaton in recent years? I'm unaware of anyone providing a system of computation that is in wide spread use that is not a Finite State Automaton. If someone has please let me know. I've heard of some researchers in Tel Aviv working on a neural net.

Considering that all we have to work with, even in the clouds is FSA it seems that we will always be working with conceptual derivatives of the Turing processing tape. So as much as I would like to see something other than a suped up text editor for creating code I have to say while some feel that an IDE is not enough ... I'm afraid it will basically have to do when it comes to what we call "programming" until we escape the confines of the FSA.

Just as a FSA is the core definition of behavior for a computer, DNA is the core definition of a cell's behavior. To be sure it's not all that's going on. There's a whole mess of inputs and environmental factors too. Where do we see similarities between FSA, DNA, and epigenetics? The cloud.

When working with emergent systems, however, the external forces may produce unforeseen effects. These, however, remain in the space of discrete systems. If they did breach into the world of contiguous systems this would pose a problem on the order of the incompleteness theorems. We would have found the bridge to the mystic. Our limited discrete systems would be able to cross the cosmic gulf into to the divine space of contiguous systems.

As of yet, we can't even prove that physical reality can represent irrational numbers. We know they exist. We know they are real... we just can't represent them with atoms, particles, or waves. We slice finer and finer and we hit a generalizable uncertainty principle. So... what does that mean for my programming language?

Basically, it means that all representations of information contained within our universe (as best as we know it) is lossy and discrete. We can't ever create representations of information that is precise as a datum. Instead we can create FSA or algorithms that can compute to arbitrary precision what a particular unit of data is.

Now it is true that we have no sufficient model of computation to properly represent concurrent computing in a fully realized cloud environment. In systems programming discussions today we have to consider the effects of millions of independent FSA acting on a network. The cloud provides us an illusion of locality for things that are not actually local. The fabric of the network and the true concurrency of the cloud exacerbates issues of consistency, atomicity, and durability of systems in the cloud.

In a nutshell that's why we have big moves in NOSQL and in non-relational data stores. These solutions seek to eliminate centralized state. They compartmentalize the state issue inherent in a big ACID compliant data store.

If you don't believe me... have you ever tried to debug a neural net? How about a lisp program? How about a fully distributed system? These are non-trivial problems to debug. In this case I have to agree...  an IDE is not enough.

In all of this, I continue to wrestle with one of the original problems my first research projects touched on... the emergent system. Somehow we only have discrete matter and yet it breaches into the world of the divine. The SA breaks local minima an maxima. The EA gives rise to the mystical. And, these are accomplished by interacting FSA which are discrete systems described by strings of symbols yet not fully understood by just these.

Yet this is all we have... and all evidence we have at this is that all the universe itself has are these small planck lengths filled with properties each potentially a cosmic symbol in a universal Finite State Machine.

So I ask... has anyone found something other than this kind of a toy to do computation on? Will anyone ever find such a thing? When will we know all the digits in Pi?

Many, many, years ago I got the chance to work with a highly seasoned developer. This guy had helped write tools like make. Yes kids... he worked on an early version of make. So as he came up to speed on our new system I left him be, figuring who the heck was I to direct his work at all? I was just some schlub who started at the company earlier.

This seasoned developer got under the gun on his first project at our little company and we had a monthly UAT cycle. In the process this company used: two weeks out, you would freeze new development and then turn the whole system over to test. The new system development would start on a new branch as we practiced "clean trunk, dirty branch" style of version management. (Today I prefer dirty trunk, clean branch but I digress.)

UAT went badly and as was the policy in this company the responsible developer had to turn around and fix the bugs found by the human testers (and turn it around rapidly) so the whole human driven Testing Cycle could start all over again. Some cycles went smooth. Some cycles were hell as the release date never moved and people would have to work longer and longer hours as deadlines loomed closer and closer.

As was typical, a client might hold off on their contractual obligations to test. They might wait until the day before delivery to test. We had no automated testing at this little company. In those days things like that were not common. There was no clause that let us move the deadline. That meant if that client reported something that prevented the project from shipping we would have to work through the night to fix the bug an then sit attentively waiting for the client to test again and approve.

So when this seasoned paragon of coders came upon just such a situation what did he do? He fixed the bug in nothing flat and got everything through UAT late that night. He was a hero.

The UAT scripts were run that night were all written to test for "5" and so there was a bug in the UAT process. We did not retest *everything* after a failure. We only retested the failed things. We did not retest everything before we shipped... we only tested the failures. But, can you blame the testers? They were tired. They had been up late for days testing. They had to repeat the same boring actions over and over and over... can you blame them for beginning to short cut tests?

I looked over the changes and perhaps it was because I was a fresh pair of eyes... but I swear... I could see it right away. Somehow, the code entered a tautological loop that I don't remember exactly suffice to say... the only answer it could ever return was "5".  But, because of the process I couldn't stop the deploy and I couldn't slip-stream the changes because I had to wait for the next cycle of UAT.

We would end up in an eight month long non-stop fire-fight due to that one mistake. When the fires finally died down we would have a staff party and celebrate our victory. Yet we would do little about our mistake other than remember it and make jokes about "5" being the right answer to everything.

To this day if you ask me a question and I'm tired I may respond with a whimsical "5" ... and all my coworkers from that name-less and thank-less job (you know who you are) will chuckle along with me. We all learned a valuable lesson none of us will ever forget because it is burned into our foreheads with the brand "5" as its name.

So every time I think: "eh, I'll skip the tests." I remember what it is like to have no automated testing at all. I remember what its like to not be able to quickly tell that you've just made a mistake that means your method only returns 5. I remember 8 months forged in hell, that nearly crashed that company, and I run the tests again anyway.

I was at Clojure User's Group, NYC back in 2011...

And Stuart Halloway flashed this code on the screen:

(describe String (named "last"))

He complained that while it appears simple, it is in fact not simple and showed this code instead (which does the same job).

(->>
   (reflect java.lang.String)
   :members
   (filters
        #(.startWith (str (:name %)) "last"))
   (print-table)
)

He then claimed the new code was simpler. I had to admit I just didn't see it. How is the second listing simpler? The idea is to describe in table format some data right? "describe" seems pretty simple to me.

Over beer that night Stuart illuminated my foggy understanding. The second listing is simpler because it introduces fewer new constructs to the language. It is also simpler because the components are smaller, looser in coupling, and can be re-used later without some special facility or dependency on printable output. The key to reuse being that "print-table" now does tablular output on any incoming data as opposed to hiding that nugget of function deep inside the "describe" machinery.

We went on to discuss the issues with ORM and how mapping data adds a layer of accidental complexity. Being a good disciple of the Java/Groovy camp I believe in hiding complexity behind clever facades like Domain Specific Languages, Frameworks, and API. This is in stark contrast to a good disciple of Lisp's view of the world.

What makes Clojure interesting is the deliberate collision between these two world views. I normally would not be forced to dredge up my decade old exposure to Lisp and place it directly in front of what I've learned from Java the last decade. The Clojure folks force us to do that and you can blame this momentary encounter with Stuart for my talk on Functional Programming in Java and for the thought experiment that is lambda-cache which is an attempt to do caching (via ehCache) using a lambda construct in Plain Old Java Objects.

What is interesting is as we explore Functional Programming on the JVM and as project lambda matures we are going to finally explore how best to reconcile these differing views of simple. That is because simple is anything but simple. In it's purest form simple is really an analogy for beauty when it comes to computer science or mathematics. The value of beauty is debatable. How to achieve beauty is at least in part subjective. 

What is most surprising is that there are objective measures of beauty in many fields. For example humans find adherence to the golden ratio in proportion to be beautiful. There may in fact be a measure of beauty that can be performed mechanically. Similarly, is there a measure for beauty when it comes to computing? Ostensibly simple is the opposite of complex and computational complexity theory is still a dark murky thing. Do we need to shine some light into the corners of complexity theory before we can measure simplicity?

I was at Clojure User's Group, NYC back in 2011...

And Stuart Halloway flashed this code on the screen:

(describe String (named "last"))

He complained that while it appears simple, it is in fact not simple and showed this code instead (which does the same job).

(->>
   (reflect java.lang.String)
   :members
   (filters
        #(.startWith (str (:name %)) "last"))
   (print-table)
)

He then claimed the new code was simpler. I had to admit I just didn't see it. How is the second listing simpler? The idea is to describe in table format some data right? "describe" seems pretty simple to me.

Over beer that night Stuart illuminated my foggy understanding. The second listing is simpler because it introduces fewer new constructs to the language. It is also simpler because the components are smaller, looser in coupling, and can be re-used later without some special facility or dependency on printable output. The key to reuse being that "print-table" now does tablular output on any incoming data as opposed to hiding that nugget of function deep inside the "describe" machinery.

We went on to discuss the issues with ORM and how mapping data adds a layer of accidental complexity. Being a good disciple of the Java/Groovy camp I believe in hiding complexity behind clever facades like Domain Specific Languages, Frameworks, and API. This is in stark contrast to a good disciple of Lisp's view of the world.

What makes Clojure interesting is the deliberate collision between these two world views. I normally would not be forced to dredge up my decade old exposure to Lisp and place it directly in front of what I've learned from Java the last decade. The Clojure folks force us to do that and you can blame this momentary encounter with Stuart for my talk on Functional Programming in Java and for the thought experiment that is lambda-cache which is an attempt to do caching (via ehCache) using a lambda construct in Plain Old Java Objects.

What is interesting is as we explore Functional Programming on the JVM and as project lambda matures we are going to finally explore how best to reconcile these differing views of simple. That is because simple is anything but simple. In it's purest form simple is really an analogy for beauty when it comes to computer science or mathematics. The value of beauty is debatable. How to achieve beauty is at least in part subjective. 

What is most surprising is that there are objective measures of beauty in many fields. For example humans find adherence to the golden ratio. There may in fact be a measure of beauty that can be performed mechanically. Similarly, is there a measure for beauty when it comes to computing? Ostensibly simple is the opposite of complex and computational complexity theory is still a dark murky thing. Do we need to shine some light into the corners of complexity theory before we can measure simplicity?