The article really hits its stride in the section “Creeping bureacracy”. If you’re short on time, jump down to that header. I found myself laughing and nodding at these pearls of wisdom:

I think that by far the biggest reason that C++ and Java are the predominant industry languages today, as opposed to dynamic languages like Perl/Python/Ruby or academic languages like Modula-3/SML/Haskell, is that C++ and Java cater to both secure and insecure programmers.

and

Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done. It’s not very easy to drag your heels and dicker with class modeling in dynamic languages, although I suppose some people still manage. By and large these languages (like C) force you to face the computation head-on. That makes them really unpopular with metadata-addicted n00bs.

While the whole article sent my neurons firing off in dozens of different directions worthy of blog entries, I’m going to concentrate on this bit:

Java has been overrun by metadata-addicted n00bs. You can’t go to a bookstore or visit a forum or (at some companies) even go to the bathroom without hearing from them. You can’t actually model everything; it’s formally impossible and pragmatically a dead-end. But they try. And they tell their peers (just like our metadata-addicted logical data modelers) that you have to model everything or you’re a Bad Citizen.

Hello, my name is David and used to be a metadata-addicted n00b. Joking aside, Steve is absolutely right.

I think Java became the garden of frameworks due to its early positioning as an enterprise software platform. Enterprises are strange beasts. Internally developed enterprise software has a tendency to live a long, long time. A decade, often more. Take a moment and pause to think about what you were doing 10 years ago today, and then think about how much technology has changed in that time, too.

One of the problems faced by enterprise software that isn’t typically encountered outside of enterprises is that the systems, protocols, and interfaces that an application was originally written to run on or collaborate with will have been replaced. Vendors are replaced, authorization systems change (database to directory to single sign-on), databases are upgraded, CORBA loses favor to EJB and then to SOAP, and so on. Consequently, the fathers of Java emphasized abstraction—don’t get too close to your touch points, because they may be changed tomorrow. Let’s call this “abstraction at the edge”.

I think that a lot of Java developers—myself included—took abstraction too far. Instead of abstracting at the edge, we started abstracting everything. Rather than creating opinionated software, the Java development community promoted and embraced frameworks that competed to be the most general and all-encompassing. Rather than solving problems, the Java community invested its energy in building problem-solving engines.

This is important because as Java developers have started jumping into new communities—I’m thinking of .NET, Flex, and Ruby on Rails—they have brought their framework addictions with them. NHibernate and Spring.NET are gaining momentum within .NET communities and you can’t look sideways at Flex without tripping over a new Flex MVC framework¹. The Rails community has been very successful at resisting the inventions of “metadata addicted n00bs” because the big names in the community have taken a strong positions against abstraction.

I might be growing up faster than Steve’s timetable for growth, but I’m tired of frameworks that try to do everything. I just want to get things done.

¹ Here’s nine for you: Cairngorm, PureMVC, ARP, MVCS, Flest, Model-Glue: Flex, ServerBox Foundry, Guasax, and Slide. List compiled from here and here.

Don’t get me wrong; I think the switch to Java was a leap forward for the industry; I just wish people would have jumped to a better language.

Who cares about programming languages? Languages are a tiny part of the overall development stack. The PERL language is showing its age, but CPAN continues to make PERL a great choice for many UNIX applications. Ruby is interesting, but it’s Rails that attracted the industry’s attention. Objective-C would be nothing without Apple’s fine compliment of frameworks. Microsoft recognized the value of stacks over languages when it designed .NET’s CLR to support many languages. And finally, Java’s decade-long success as a server-side development platform wasn’t due to any stand-out features of the Java language — or even Sun’s marketing¹. Its success was due to being a compelling development solution for server applications:

• Develop on your favorite system (Windows, Solaris, or Linux)
• Deploy on your business’ favorite system (Windows, Solaris, or Linux)
• Roll-out with confidence due to standardized server deployment artifacts and environments (JavaEE)
• Enjoy the easy stuff being easy with built-in support for internationalization, threading, and asynchronous processing

Development stacks don’t “win” based on their language — they win based on the ecosystem of developers, frameworks, and libraries that surround the language.

¹ I find the idea that Sun’s marketing significantly impacted Java’s adoption to be laughable. During those early years, while Sun was the tech media’s darling child, Sun was also actively antagonizing its developer community, whose members were building open source alternatives to the expensive enterprise solutions being pushed by Sun and its industry partners.

You suck. I switched from you to TMobile six years ago because you didn’t provide reception in my condo. I was happy with TMobile. They had exceptional coverage in my condo—and everywhere else I went, too¹! They had good prices and excellent customer service every time I called them. (Their in-store service left something to be desired, but sadly that’s parity for the industry.)

I had to switch back to you, AT&T, because you are the exclusive carrier of the iPhone. I had hoped that your network coverage would have improved in the last six years, but as soon as I powered on my iPhone in my condo I saw that it hadn’t changed at all. I love my iPhone, but your disgraceful coverage limits it’s utility and hampers my ability to recommend it to non-enthusiasts.

I was reminded of this again on Sunday while attending a pre-event for Adobe MAX in the McCormick Center west building. As soon as I stepped inside, I was down to one bar, and a half dozen paces further I had no service at all. I saw other iPhone users struggling with the same problem. People with other carriers, however, had no problems at all.

So, I simply have this to tell you: I completely empathize with those who are unlocking their iPhones to use them on other networks. The moment I’m out from under my contract with you, I’m unlocking my phone and returning to TMobile.

Good luck,
David

¹ TMobile’s data services in Chicago are pathetic, but I use Sprint for mobile broadband and couldn’t be happier with their coverage and speed.

The first items aren’t that interesting. A 360|Flex folder and an Effective UI graph pad I picked up off a table while at that conference (thanks, guys!). I plan to use the graph pad to layout some screens for an upcoming project at work and want to keep it handy in case inspiration strikes. I’m still waiting for that inspiration.

Then I pulled out a two inch thick collection of papers I’d printed (duplex, to conserve paper). On top of the stack is D-Click’s Adobe Flex Coding Guidelines. I really don’t like placing opening braces on their own line. Drives me nuts. (For my money, the Sun Java Coding Conventions can’t be beat.) But, when in Rome, do as the Romans do. I recognize that being consistent (especially across developers on the same team) is more important than the merits of any single convention, so I’m trying to learn new habits.

Next up are printouts of six chapters from Adobe’s Building and Deploying Flex Applications (PDF here). I have only built Flex apps inside of Flex Builder, so I still need to learn the command line tools. My company is big on “repeatable builds”—meaning that any interally-developed production applications should be easy to regenerate from source without developer involvement. In practice, this means that the application must be built with a command line build script (Make, Ant, etc.). Besides, I get nervous when I’m overly dependent on an IDE. I like code completion, syntax highlighting, and refactoring, but I really like to know that I can do it all from vi or Notepad and the raw Flex SDK if desired or needed. Hence my interest in the Building and Deploying Flex Applications book. And I mean book! A full printout would weigh in at 400+ pages! So I picked the most important parts to me and just printed those.

The first chapter is Chapter 3 (Flex Application Structure). I just finished reading this chapter last night. Not a lot to say here. It’s good to have the layout with which I was familiar due to Flex Builder reinforced in print. Next up are Chapter 4 (Applying Flex Security), Chapter 7 (Building Overview), Chapter 9 (Using the Flex Compilers), Chapter 13 (Using ASDoc), and Chapter 14 (Creating Applications for Testing).

Then I come to printouts of various O’Reilly articles about Ruby on Rails that I intend to read Any Day Now™. Rolling with Ruby on Rails Revisited, Cookin’ with Ruby on Rails: May, Cookin’ with Ruby on Rails: Designing for Testability, Cookin’ with Ruby on Rails: More Designing for Testability.

And finally, I have Greg Hamer’s presentation slides for introducing Cairngorm at 360|Flex. I suppose I can take this out of my bag. I have the general idea of how Cairngorm works. I’m still waiting to write an app large enough to make playing with Cairngorm worthwhile. Okay, that’s not quite right. I’m still working on my first Flex app ever. I’m plugging into the 37signals Backpack API. When I’m done with that, I might look at refactoring it for Cairngorm just to get that experience under my belt.

And that’s wy my computer bag weighs a ton. What’s in your computer bag?