Cloud and Devops: eliminating an entire layer of assholes

I've been in quite a few gigantic enterprises. Medical, Insurance, Retail, Government, you name it.

Without exception, in every one of these organizations the infrastructure teams function as blights upon innovation and adaptability, and impose unreasonable costs and delays. Infrastructure is not simple, I will grant... and this is not revelatory news to anyone in the industry.

It used to be, oh, say, a decade ago that we heard only rumors of Google, Facebook, Amazon, and other firms with dynamic, adaptive, cost-effective, anticipatory, and plentiful infrastructure for testing, prototyping, and production. No nightmares of 8 extra GB of RAM costing $1,000, or a simple PC server carrying $10,000 / year in upkeep chargebacks.

Once rumors, AWS / Rackspace / Google Compute and a host of other cloud providers have made that a much more stark contrast to anyone mired in internal infrastructure. Once things like Chef and other automated provisioning come into play, the contrast becomes even more pronounced.

Again, none of this is revelatory. Clouds are better cost, more adaptive, efficient, allow you to discover new technologies and make those practical to your job, group, and enterprise. Anyone who has done a cloud-enabled project has experienced the nirvana... But only now when we are being cast back into the rats nest of mandated internal infrastructure use do I recall all those meetings and emails and total clusterfucks:

• your RAM is too big, we can't support more than 8GB. Oh, you want 4GB? That will be $1000/year extra
• oh, you need another 100 MB of disk space, that will be $1000/year. No we won't provision you extra space, you have to crash in production and then raise a ticket to get us to do anything.
• Let's schedule 10 meetings to discuss minor hardware spec increases that should be 1/100 of the labor waste of the meetings
• Hardware guys bloviate about what your application's hardware spec requirements are, even though they have NO IDEA about what it does or its user base
• CPU? You like 386s right? 
• Oh, your VM is colocated with other extremely high use VMs? Too bad, so sad.
• SSD? What is that?
• Cloud? We have an internal cloud. No we don't have elastic storage or API provisioning. We can get your new VM up in 5 months rather than 1 year!
• Accounting... ah, the accounting. "It's free... if you can get it". "It has no upkeep cost, but it costs a ton to setup". "Will the cost drop over time as Moore's Law marches on? NO". 

I am so fucking sick of it. Thus I DECLARE:

The #1 Feature of Clouds is the Elimination of an Entire Layer of Assholes From Your Life

That's right. #1 feature by far. No one from our cloud provider has ever sent us threatening emails yanking our RAM size, or down-specced our machines without consultation, or dragged their feet to provide new machines, disk space, CPU, whatever. Or spent weeks ignoring tickets behind ticket walls. No one scheduling bloviating meetings and handing down arbitrary new policies from above. No meddling in your application architecture. No complaints to the CEO if you decide to use someone else's infrastructure. None of it.

Not just any arbitrary layer of assholes. Infrastructure lends itself to controlling and sociopathic shitheads. They get to ooh and aah over high-spec machines, they get large lump-sum budget line items, and, best of all, they get to lord over the distribution of those resources to the people that need them, and demand asskissing and tribute. This is a particularly obnoxious layer of entitled, intractable, petulant assholes you are extricating from your life.

What is the #1 downside of our collective profession? Stress. Stress that causes measurable, documented deleterious health effects. If you can identify something that significantly reduces that stress, and I argue clouds can do that, then it should be a priority: personally, professionally, and industry-wide.

Language Evolution Battle Royale.

So I read a lot of programming blogs and the inevitable debate about languages. Rust, Go, Java, Groovy, Ruby, Python, Javascript, C, C++, CSharp, etc.

What would be really fun is a long, thoughtful, crowdsourced, dynamic converging evolutionary practical language bracket shootout.

You start with a March Madness style of bracket. Not random, but the MAJOR languages seeded by their popularity.

Lesser seeds go to languages of note, usually in-use languages of lesser popularity with nonetheless some valid use case, but also emergent languages (Go, Rust), and some important historical ones not yet reproduced (Ada, APL, Smalltalk, ?Delphi?).

Lisp doesn't get in. If you've ever dealt with a lisper (how would you know... DON'T WORRY THEY'LL TELL YOU) you know they just aren't constructive members of any practical language discussion. Haskell is probably also not in for basically the same reasons.

For each language in an individual match, the features, standard library, runtimes, and debated. The outcome of each match is an evolved merged language... one that takes an effective compromise of the two languages, making sure to keep in mind the seeding of the sourced languages: if one language is bigger seeded, the reasons for its popularity/dominance can't be dramatically undermined in the evolutionary product.

Each evolutionary advancement in the bracket should note what was left out.

I (at the bottom of the blog, assuming bracket ninja stays around longer than next Tuesday) basically structured 16 languages. I only seeded the top four: Java and C++ are number one seeds, Javascript and Python are the #2 seeds.

From there, I didn't go by the usual ranking. Instead, the "competitors" for the immediate opponent and hopefully the second-round opponent deal with the primary domains of the language.

So C++ is obviously from the C family of languages and exists primarily as a systems language and, due to popularity and historical gravitas, is in many other domains. While Objective C isn't really a systems language, it is targetting devices with some aspects of performance and embedded problems. It also is a direct descendent of C as well. Objective C has strong recent popularity in TIOBE, but this is mostly due to the authoritarian dictates of Apple rather than a matter of public choice. Anyway, since these are both close in lineage and similarity, lets have them blast it out in the first round to produce a reasonable direct-from-C immediate evolutionary step

Similarly, Java is paired with CSharp. Both are essentially enterprise programming platforms, and quite similar in approach. So let's have them battle it out and produce the evolutionary result of managed portable C-esque languages with great standard runtimes and deep software ecosystems.

Python and Ruby are paired in the second-seed battle. Both are high-productivity scripting languages intended for both small and medium scale software packages, and dabble with aspirations of large-scale code. Both have their primary mission for fast-start web applications and the leading scripting languages. Both have worked hard to leave their scripting limitations behind with LLVM runtimes for performance and modern multithreading abilities.

The last seeded battle is Javascript and Dart. Javascript is seeing massive adoption rates due to the web (duh) and has made notable forays into other areas (Node.js, etc). Dart is the most obscure language on here with the least adoption, but is the most preeminent challenger to address JS's massive shortcomings as a fundamental language. Here also will likely be the battle to determine the fate of prototyping as a viable OOP feature moving forward.

It should be noted that most of the four top seed battles are really to address the glaring issues in the main four platforms.

The other four faceoffs all relate to the set-of-four subbracket they belong to.

 So Go and Rust are addressed at systems programming like C++, but much more exotic. The second round mashup between Objective++ and GRusto should produce a systems language par excellence.

Scala and Ada are two enterprise-focused languages (Ada has strong historical strength, once the #3 language in TIOBE). The eventual hybrid of Java# and Scalada should produce a featureful yet very performant and productive enterprise programming platform with strong typing and scalability.

Visual Basic and Smalltalk are two high-productivity languages with strong IDE designer components and RAD aspects, aligning with Python and Ruby high-productivity loose-typing applications. Smalltalk's legendary status as the ultimate IDE-supported OOP language needs to be represented. Visual Basic, despite the guffaws, has produced more applications in its programming for the masses than most non-top-seeded languages. The outcome of BasicTalk and Rubython should produce an amazing high-productivity scripting application building capability with phenomenal database integration and UI construction from desktop to web.

Finally, there is Perl and PHP. PHP is too popular to not include. Perl is too popular to not include. Both are viewed as intermediate steps in the evolution of their domains, and remain very heavily used. PHPerl should cull whatever is good about these platforms not that was missed by their successors, be it simplicity, frameworks, syntactic sugar. Combined with JavaDart in the second round will produce a useful, flexible language with unique programming constructs and a powerful standard library with nods to other domains such that it can expand into other places. This overall bracket represents the "ugly but effective" group of languages and platforms that produces an enormous, undeniably proportion of modern software and can't be ignored.

From those four domains, combined evolutions may be harder.

What is left out? Well, the free bracket only allowed me 16. I think that Ruby/Perl should be subjected to a play-in game before facing Python, or strangely Python/Perl face off. Ada should probably be subjected to a play-in bracket of many other languages in general systems use from the ages.

The lack of R/APL/Fortran and other heavyweight array/matrix/stats/math processing should probably be inserted into the systems sub-bracket. Go and Rust can battle it out in a play-in prelim, and then incorporated with the powers of the raw computing languages.

Scala should be representative of a grand JVM language battle between groovy, scala, and all the others.

In the end, we see if some comprehensive language can be ideated that isn't the tragedy of the commons.