A couple of years ago I read a book – “Javascript: The Good Parts” – which changed my mind about a language that I’d struggled with back in the nineties. I realise now that much of my struggle then was with the DOM and horrible browser incompatibility. Nevertheless the scarring was bad enough to keep me on the server side for the next decade.
I recently found a series of videos featuring Doug Crockford expounding on Javascript and its place in history. This series provides an interesting and entertaining perspective on computers and languages beyond just what runs in the browser.
The whole lot is a bit of a marathon but you can sample some of the main themes in a couple of episodes. I especially recommend episodes 1 and 4. Episode 6 stands well on its own as a compressed version of the whole series. Episodes 2 and 3 are very specific to Javascript the language if that’s what you’re after.
I like episode 1 because it has nothing whatsoever to do with Javascript but is an interesting tour through the history of computing, describing how we got to the languages and architectures that we work with today. This is essential context for any working programmers today. If you view only one episode, I recommend this one. The historical perspective is reduxed in Episode IV where Ajax is discussed in the context of HTML and its origins.
The important take away from these two talks is how the history of computing is anything but linear and deterministic. We got to the place we are via a series of steps, mis-steps, loops, accidents and fashions. And the random-walk continues. Crockford says:
“…important new innovations are received with contempt & horror and are accepted very slowly – if ever.
Often it is necessary for the previous generation of technologists to “die off” before major progress is made – especially in programming languages.
A key problem is that it usually requires many years of hindsight to determine which innovations really are useful and innovative.
I had the pleasure of attending two conferences in recent weeks – the Australian Architecture Forum in Melbourne, and JAOO in Sydney. Both conferences held some surprises and in particular I was struck by the very different attitudes toward SOA.
The Architecture Forum was of course aimed at IT Architects and as a result it was about SOA, SOA and SOA…with a bit of SOA as well. Even when you tried to not talk about SOA (as one bold presenter attempted)…the conversation still swung around to SOA. By contrast, at JAOO, there was nary a mention of SOA. You don’t have to look far to understand why…JAOO’s by-line is “by Developers for Developers”…so the target audience and attendees were – Developers. Hence much of the content was around languages, platforms and agile methodologies.
What I enjoyed most about JAOO was the chance to meet and talk with the great lineup of speakers. Kudos to Dave Thomas for wrangling these people to this unfashionable side of the planet. Among the highlights were: Gregor Hohpe talking about the challenges of distributed systems, Martin Fowler expounding on the virtues of simplicity in design, Jim Webber trying to reconcile his two loves in life and Steve Vinoski on how a portfolio of languages helps us develop better solutions. All of this gave me the opportunity to consider the perspectives of architects versus developers. Gregor Hohpe captured the tone with his statement that an “architects dream is often a developers nightmare”.
An Enterprise Architect is generally focussed on the larger components in the IT infrastructure – how they are owned, sourced, maintained, combined and deprecated. And an architect considers not only machines and software but also data, processes and organizational structure. A key consideration for architects is how these things work together and therefore standards are important.
Developers care about delivering solutions for a particular business requirement. They care about the languages and platforms and methodologies that support their needs for correctioness, quality and maintainability. Developers have evolved techniques to deliver these qualities which are sometimes at odds with the needs of Architects and associated standards. From a developers perspective, many of the web-services standards conflict with their best practices. For example, XML is not really a language and cannot be completely treated like a language. Source-code management systems often have difficulty with XML. XML-based “languages” such as WSDL and BPEL are so complex that they require visual interfaces and complex IDEs that are at a higher abstraction than the XML “code”. The ability of these visual interfaces to “diff”, “merge” and debug are often pretty poor. Recently there has been a welcome move away from the masses of XML configuration files in J2EE in favour of java annotations. And perhaps there is further value in domain specific languages like Integration Flow Language in project Fuji.
Architects and Developers are in a symbiotic relationship which is definitely not frictionless. A good understanding on both sides of the needs and drivers of the other party will help to get everyone working in the same direction. Each should know the languages, techniques and platforms used by the other and a common understanding will lead to better ways of achieving what is ultimately a common goal.
