James Gosling on Closures or: How I Learned to Stop Worrying and Love the Bomb
James Gosling: on the Java Road
“Lisp is a Black Hole: if you try to design something that’s not Lisp, but like Lisp, you’ll find that the gravitational forces on the design will suck it into the Black Hole, and it will become Lisp”
This is a great quote by Guy Steele that James has recreated. The context is around closures and java language enhancements. I think it is relevant to enterprise architecture because it highlights a force that is orthogonal to enterprise architecture.
In my view, enterprise architects must focus on the business and its needs. If a feature or functionality does impact the bottom line, than it is a non-starter. Does JPMC, Wells Fargo, Shell, BP, Verizon or any other major corporation need to be concerned about this? No, they don’t; so an Enterprise Architect does not need to bring this up in their discussion. However, it will make itself known for one reason. Most enterprise architects deal directly with system architects or engineers, where this is important for them because it is important for the community. However, Guy’s quote about Lisp is important. While most system architects remember Lisp in college, I don’t think a good deal have taken the time to understand what Lisp means to their development projects.
My own journey through this exercise left me realizing that Lisp and Scheme are essentially languages left to academia, two environments exists today that provide a source of bleeding edge applications and a source of headache when it comes to maintainability. Those two applications are JavaScript and Excel.
That is right, JavaScript and Excel are functional languages that are just as powerful as Lisp. With JavaScript, the latest Web 2.0 spurt would not have been realized. Excel is hands-down the number one application for prototyping business applications in the workforce. Most of wall street runs on Excel. Millions of dollars have led to taking Excel and placing it on the server side to varying degrees of failure. Nonetheless, these platforms provide plenty of opportunity to achieve what Lisp set out to achieve so long ago.
Getting back to enterprise architecture, it is important to recognize that a system architect or engineer that clamors on about closures really needs to realign themselves to the today’s modern functional platforms, JavaScript and Excel. The enterprise architect should also realize that closures in Java will lead to one thing, higher maintainability cost and this is something the business understands.
February 10th, 2007 at 1:52 am
I couldn’t agree with you more. Javascript is a weird miracle that just happened out of nowhere (with closures and all). And Excel, well excel is ugly like coal, but hey, it powers plants.
But I hope you realize your blog is going to be set ablaze pretty soon with comments about how this or that you are.
February 10th, 2007 at 10:00 am
Umm…I think you’re lacking some important detail in places. For example, ‘Excel’ isn’t a programming language at all — there are built-in functions that have specific uses, and you can either build in new functions with VBA or by writing add-ins. And I can’t think of how you might do lambda calculus with Excel…
February 10th, 2007 at 11:10 am
I don’t recall how I made the link between excel and functional languages. I was investigating Scheme as a platform for rapid development having been inspired by these stories. Basically, I came across a discussion like this and I made the link.
@Uzair I can’t defend Excel as a functional language, but the ability to have cells represent functions is pretty powerful, perhaps the reason why it’s so popular. There is a lot of procedural code bolted on around the engine, but that’s so procedural developers can hook into it.
I don’t oppose using functional languages to solve real world problems. I realize that many business critical system use them. However, for mainstream applications, Java and .Net are the predominant tools in the field. I believe that language complexity leads to a higher cost of maintainability all things being equal.
Functional languages, at their core, are extremely powerful because of their simplicity; however, finding talent that can wield the tool en masse is very difficult, hence the higher cost of maintenance.
[the flames rise a little higher]
February 10th, 2007 at 12:01 pm
“That is right, JavaScript and Excel are functional languages that are just as powerful as Lisp.” Wow, you really don’t have any clue what you are talking about, do you?
Yes, JavaScript is in some theoretical sense as powerful as Lisp. But Excel isn’t as powerful, neither theoretically nor practically. (I’m not counting addin functions, because they are not part of Excel.) I’m not a Lisp guy, but this is just to much.
February 10th, 2007 at 1:23 pm
“But Excel isn’t as powerful, neither theoretically nor practically. ”
Define power.
“I’m not counting addin functions, because they are not part of Excel.”
Isn’t that a bit arbatrary? Discounting part of a the platform, especially one that is essentially unseperatebly, sounds like dodgy reasoning to me.
February 10th, 2007 at 6:54 pm
Actually, I was excluding both VBA and addins.
Excluding VBA is arbitrary, because it really is part of Excel. Excluding addins is not arbitrary, because you are then calling something in another language. Of course you’d have the power of this other language then. Excluding VBA was a bit rash. But if you do, Excel is not Turing complete.
As far as power goes, it’s a very difficult thing to define. But just because Wall Street runs on Excel doesn’t mean it’s the most powerful or effective thing to do. Parts of Wall Street even realize this and are looking for other means.
February 10th, 2007 at 10:24 pm
All of Teenwag runs of functional Javascript with very little server side components much like Skype…
Teenwag
Hottest social network for teens
February 11th, 2007 at 2:37 am
Excel does not have closures. Javascript has closures, but you stopped talking about Javascript when it was time to talk about server-side results. There are some pretty good links at http://en.wikipedia.org/wiki/Server-side_JavaScript
I think you’d be a better architect if you knew more about the underlying technologies. Nothing you wrote indicated to me that you know what a closure is or have ever used Javascript or Excel (or, for that matter, Java).