John Reynolds's Blog

"Programmer to the Stars" Bruce Tate spotted at swanky North Austin establishment

"What? No Elephant on the menu!?!"

Of course I am just kidding. I asked Bruce to pose for the picture (and supplied the sun glasses)... but there has been a bit of a nasty furor over Bruce's latest book: Beyond Java, and I wanted to poke a little fun at his critics.

Kudos to Bruce for stirring the pot, for as William Hazlitt (English essayist (1778 - 1830)) noted:

"When a thing ceases to be a subject of controversy, it ceases to be a subject of interest."

In this case, the controversy is Java versus Ruby On Rails: Is Java a great tool for creating web-based CRUD applications or does Ruby leave Java in the dust?

Bruce is still pretty sold on Ruby for this problem space, and his enthusiasm is hard to resist... I feel very tempted to try ROR, but in honesty I am rooting for Rick Hightower's JSF/Rife integration efforts.

Ruby aside, I am in total agreement with Bruce that many of Java's abstractions obscure the relationship between our customers' requirements and the code that implements the functionality.

Bruce and I talked of many things over lunch, but we kept coming back to questions regarding learning how to program: My starting point is to start teaching programming concepts (programming literacy, not computer literacy) in our middle schools... Bruce's approach is to eradicate distractions through the use of Domain Specific Languages.

One "sort of quote" from Bruce stuck in my mind. Bruce never thought of himself as a high-level programmer, but he finds himself spinning out DSLs on every Ruby project he tackles. This reminds me very much of my own experiences with FORTH. The basic tenet of FORTH was the creation of a vocabulary for the job at hand, and composition of the application from that new vocabulary (Maybe I need to dig out my old copy of Leo Brodie's Thinking in FORTH to refresh my "little gray cells").

Controversies aside... I really enjoyed my lunch with Bruce, as I really enjoy interacting with other programmers through my blog. What's really great about Java is the community spirit... the ability to interact with a diverse group of talented people who are truly passionate about what they do (sometimes a bit too passionate, but that sure beats apathy).

One thing is crystal clear... If we don't continue to question and rethink our basic approaches to Programming (and how Programming is taught) we really are going to have a Software Crisis on our hands.

As for Bruce: Hopefully the Javatollahs will rescind their fatwa and he can ditch the sun glasses ;-)

Comments

• The DSL stuff *is* pretty cool, I've been trying to simulate the same stuff for business logic with enums/tiny objects-- Howard Lewis Ship wrote a blog around the use of static imports with DSLs which was pretty insightful at cleaning up the code out of the class/dot notation into simple functions

  Posted by: jhook on April 18, 2006 at 01:57 PM

• RoR reminds me of the next version of PHP. PHP was the next version of ASP. ASP was the next version of CGI / Perl. Not sure if there was anything popular pre-CGI / Perl for web applications...

  But the common thread here is that all of the forementioned languages are all quick & dirty solutions. The customer gets their web application working fast using RoR, PHP, ASP, CGI, etc.

  Unfortunately their website isn't very scalable, and the spaghetti source code becomes a nightmare in later maintainence. I'm not saying RoR is bad - I believe it simply has one market, and Java has another market.

  I really don't feel that RoR has stolen Java's lunch (yet) by any means. Heck we're still trying to get rid of Cobol & C programs 20 years later - think Java will go away anytime soon?

  Posted by: phlogistic on April 18, 2006 at 06:02 PM

• Phlogistic,Your comments reminded me of another part of my conversation with Bruce...We both feel that Java's roots are more from Systems Programming than from Applications Programming... it did come from C++ after all.
  Do you think there might be an intrinsic difference between systems programming (infrastructure) languages and application programming languages?

  Are Dynamic Languages more suitable for applications than strongly typed languages?

  Interesting to ponder...

  --JohnR

  Posted by: johnreynolds on April 18, 2006 at 07:13 PM

• John,

  "Are Dynamic Languages more suitable for applications than strongly typed languages?"

  This seems to me a bit like asking, "is oil a superior to watercolor as a medium for creating art?" A visit to any museum will demonstrate that, as phrased, this is a meaningless question. There are masterworks in both media, along with charcoal, pencil, etc.

  The best artists should be capable of producing art in any medium. As an extreme example, I have a friend who can draw a recognizable portrait on an Etch-A-Sketch. The fact that you don't see a lot of Etch-A-Sketch art outside of an elementary school does not make it an invalid medium. It just means it's not a preferred medium for grown-up, "serious" artists. Which is a shame, because they're missing out on a healthy challenge.

  By the same token, I think we programmers should be able to work idiomatically within the capabilities (which sounds more positive than "constraints") of any language. Even if it's a language we've never seen before, if there are books that explain the syntax -- or, better, working code -- we should be able to pick it up. I think we owe it to ourselves to learn as much about as many languages as we can and figure out what works best in each, and what to avoid in each.

  Dang it, this turned in to a bit of a diatribe. Maybe I should take it over to my own blog... :-)

  Posted by: davidrupp on April 19, 2006 at 08:15 AM

• John, your last comment is really food for thought... As frightening as is might be, you and Bruce could be right. As soon as a decent Ruby equivalent of SWING is released, I might very quickly say goodbye to Java -- looking back fondly, that is, but still looking back. I am not sure, if that day will arrive in the near future, but I'd be very curious to see a rich client API done with Ruby.

  Posted by: norb on April 19, 2006 at 08:19 AM

• P.S.: I forgot to point out that Ruby is a strongly-typed language. Everything is an object, and everything has a definite, fixed, type, even if it's just the proto-object Object. What makes Ruby dynamically typed is the ability to assign any object as a value to any variable at any time. There's no compiler to enforce the idea of a variable being able to take only values of a specific type (or its subtypes). It's a subtle distinction, but an important one.

  Posted by: davidrupp on April 19, 2006 at 08:20 AM

• How DSLs can ease something? Can someone explain?

  If I switch projects will I need to relearn everything in a Ruby project? DSLs smell maintenance issues. In a big enough project the complexity of such solutions would go up, programmers would be hard to replace and bugs would appear more frequently.

  DSL reminds me of Unix. Small programs for all kinds of things you can imagine, but we all know what the bad is: complexity when it comes to the "end user", inconsistency in the environment. In Ruby the "end user" is us.

  That would be fixable with someone managing the evolution of the platform, but since one of the chief complaints against Java from the Ruby zealots is the "JCP", I seriously doubt anything similar would come up. The only way for Ruby to be number one would be with a JCP-like or a Microsoft--like company backing it up.

  About the "applications programming" and "systems programming" is a bit of wishful thinking by the Ruby zealots and Java developers shouldn't agree with it so easily. As Microsoft has shown with Windows you can use your current position to attack niches where you weren't strong and slowly choke the competition, that's what Java should do. And I believe it's going to be so with the perspective of evolution I have read in websites, so "application programming" should be where Java is excellent too.

  Posted by: thiagosc on April 19, 2006 at 08:31 AM

• Clearly we'll have to issue a fatwa against John as well!

  There's nothing wrong with Rails as a mini platform. There is a lot wrong with the assertion that it will replace Java for the web. That's almost like saying Perl will replace C++ for desktop software. That's why most Java guys get up in arms, not because we feel so personally attacked, but more so because it's pretty impossible due to scope mismatch. It's marketing masquerading as technological superiority.

  Why don't the Rails guys pick on someone their own size? I'd like to hear them make the assertion that Ruby/Rails will replace Php. I wonder why we don't hear that so often?
  Hmmmmmmm? ;)

  Posted by: ilazarte on April 19, 2006 at 08:33 AM

• Annoyed responder here.
  If we don't continue to question and rethink our basic approaches to Programming (and how Programming is taught) we really are going to have a Software Crisis on our hands.

  I cannot understand this frequent chicken little concern about a "software crisis". Consider for example that there is a modest oil crisis at the moment, Oil and gas companies and their employees are doing great. Starting salaries for Geologists in the same field are way up. This so called software "crisis" is the basis for our careers and salaries...by way of the simple fact that writing software is difficult. And don't get me wrong, I'm not against advancements in efficiency and quality. I just seriously doubt the

  Exxon CEO is lamenting high demand for oil...while we programmers act like Binary Mothers of Mercy, giving everything away for free, lamenting that people have to pay a lot for our product, and then insiting that children learn about what we do for their enrichment.

  Regarding how programming is taught...it really matters not if we teach programming at all, there are plenty of other countries that teach programming, they'll fill the gap, so don't worry...there will be no crisis. If the advancements you are looking for come along, programming will be similar to using a calculator, something most competenet people can figure out on their own. If they don't and the ever looming "software crisis" strikes, well, at least the middle schoolers that you taught will be compensated well for their programming skills. (Just keep in mind that the Chinese students I taught in China will be able to program circles around your students).

  
  tcowan
  

  Posted by: tcowan on April 19, 2006 at 08:38 AM

• tcowan,
  I don't know whether it qualifies as a crisis or not, but Ihave seen the figure that 70% to 80% of IT budgets are spent on maintenance.... Certainly something to be concerned about.But then, that may have little to do with the languages that are used.

  --JohnR

  Posted by: johnreynolds on April 19, 2006 at 09:22 AM

• John,

  I have seen that figure too. (I'm surprised you didn't come back with the project failure statistics too, that's the typical line from the self flagellating software community...) If the thing being maintained is so bad, why isn't it abandoned for new development? It's like the highway system, a victim of its own success. Remember y2k? The authors of the bad software never imaging that it would still be in use 30 years later...surely somebody would have come up with something better by then they thought. But in actuality the value of what they had produced endured for years and years.

  I'm sure that if we modified how developers are compensated that 80% number would change. Developers are rewarded for on time or early completion of today's requirements.

  Posted by: tcowan on April 19, 2006 at 10:36 AM

• tcowan,
  When I was at Tandy back in the 80's, we had our own Y87... The original authors of TRS-DOS were so memory conscious that they only use 3 bits to store the year... never imagining that people would keep the machines for over 7 years ;-)

  My personal experience with "maintenance cost" in an IT group is a bit different then what you seem to be implying. In my expereince, most of the software started out working just fine, exactly as it had been designed to work.

  The high cost of maintenance is not due to fixing bugs... instead it comes into play when the business requirements change, and the software has to be modified.

  In most cases, the expense is involved in figuring out how that many-years-old piece of software works, and then how to adapt it to the new requirements. Unfortunately, many programmers make their changes without really understanding the architecture of the application... as the years progress and you get change on top of change and you end up with something very, very expensive to modify (and generally very brittle).

  Perhaps programmer compensation plays a part, but I also believe that some blame lays with the abstractions that we use... if the mapping between a requirement and the code that implements the functionality is through many layers (with all sorts of distracting boilerplate along the way), then it's easy to understand why folks patch code the way that they do.

  Could "better" languages and frameworks make a difference? I think they might... but only time will tell.

  --JohnR

  Posted by: johnreynolds on April 19, 2006 at 02:04 PM

• John,

  
  I agree with your assessment of a crisis in software due to maintenance costs. It sounds to me like the basis of the disagreement between your perspective and that of tcowan is that you are looking at it from the client's perspective and he from the programmer's.

  No, it isn' t a crisis for programmers, as we just get paid to go in and fix each other's work over and over. Yes, it is a crisis for the organisations we work for, many of whom now have twenty or thirty years of accumulated software 'solutions' to maintain with a shrinking budget.

  However, I can't see this as an issue that can be addressed at the programming language level. It is at the level of enterprise architecture, IT portfolio management and program management. The only technologies that will help here are those that address EAI concerns, such as SOA and ESBs.

  Apologies if I sound harsh, but thinking that language level advances will address real-world enterprise maintainability problem is like believing that advances is building construction will get rid of slums. The problem exists at a completely different level, and must be addressed there.

  Regards,
  Christopher

  Posted by: rodmac on April 19, 2006 at 08:18 PM

• You don't sound harsh at all Christopher,In fact, I mostly agree with you.
  My experiences as an "Enterprise Architect" for an IT group lead me to look for architectural styles and frameworks that had abstractions that more closely match the "business problem" that we were trying to address... In many cases, adopting an SOA architecture (choreographing services to form composite applications) matches the problem space very well.... If the business process itself is defined in BPEL, with process tasks performed by individual services, you have a much better chance of responding to a change in the business process requirements without producing an unmaintainable mess.

  If you've done much with BPEL, I think you will agree that it certainly could stand some "language level advance" ;-)

  This is a good discussion... I hope the new fatwah against me doesn't keep us from continuing ;-)

  ==JohnR

  Posted by: johnreynolds on April 20, 2006 at 05:59 AM

• John - agreed about the systems / infrastructure programming vs application programming.

  Java lends itself great to the back end of SOA - solid architecture, scalable, that can run on many web containers, open source or commercial, failsafe and distributed workload, that can run on any OS. If a new business unit, department, or developer wants to use your service, there's no proprietary API to learn - only a WSDL contract to read.

  Ruby, PHP, ASP, CGI - not one can hold a match to a Java SOA implementation.

  The inverse can also be said - Ruby, PHP, ASP, & CGI all take far less resources to quickly create a function UI / web appliction when compared to a J2EE / Swing / SWT solution (placing target on chest). So - yes about the application programming as well.

  Posted by: phlogistic on April 20, 2006 at 05:27 PM

This work is licensed under a Creative Commons License.