Java is slow, piggish, and breaks otherwise-stable software with every new release. We all know that. Or at least Sun Microsystems does: Read this incredible internal Sun memo (dating to 2003, but still very much applicable).
"Within Sun, Java is not viewed as a satisfactory language for the construction of commercial applications."
"That our Java implementation is perceived as inappropriate for many uses is supported by internal documents and policies."
A great, great memo, filled with priceless insights.
One of my personal favorites:
"Our experience in filing bugs against Java has been to see them rapidly closed as 'will not fix'. 22% of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7% for C++."
A particularly noteworthy aside concerns one engineer's desperate quest to circumvent resource exhaustion on Solaris Servers by implementing a particular daemon using J2ME code (yes, that's right: J2ME).
You have to read this memo for yourself. If you're like me, you won't know whether to laugh, cry, or go to work for the circus.
Friday, March 31, 2006
Thursday, March 30, 2006
Continuations (Continued)
Several weeks ago, I was reading the doc for Rhino 1.6.2 and came across a mention of support for a new Continuation object. I didn't think much of it. After letting it drop, I returned to it later, looking for examples on the Web of real-world uses of Rhino Continuations. I quickly found a poster child in Apache Cocoon. And another one in Jetty 6.
Then I realized the Web was RIFE with examples of people trying to bring continuations support to various web frameworks. In fact, continuation servers are sprouting all over the place, with funny names like Seaside, Wee, Lakeshore, Continuity, Borges. Written in a variety of languages.
So why the fuss over continuations? The short answer is that it offers an elegant way to keep track of session state in a multi-user client-server app. You end up writing code that looks compact, linear, and obvious, rather than the typical MVC pasta-pile.
But the benefits go far beyond elegant state management. There are payoffs in scalability and efficient use of resources as well.
If you want to grok the basic paradigm shift (and you have time to read only one article), invest a few minutes reading this brilliant minitorial. You just might have a Mega-Aha Moment.
Then I realized the Web was RIFE with examples of people trying to bring continuations support to various web frameworks. In fact, continuation servers are sprouting all over the place, with funny names like Seaside, Wee, Lakeshore, Continuity, Borges. Written in a variety of languages.
| Server | Language |
| Borges | Ruby |
| Continuity | Perl |
| Lakeshore | Java |
| Seaside | smalltalk |
| Wee | Ruby |
So why the fuss over continuations? The short answer is that it offers an elegant way to keep track of session state in a multi-user client-server app. You end up writing code that looks compact, linear, and obvious, rather than the typical MVC pasta-pile.
But the benefits go far beyond elegant state management. There are payoffs in scalability and efficient use of resources as well.
If you want to grok the basic paradigm shift (and you have time to read only one article), invest a few minutes reading this brilliant minitorial. You just might have a Mega-Aha Moment.
Wednesday, March 29, 2006
goto Returns
AJAX and Ruby are driving a lot of changes in how people do web programming. Witness the resurrection of the hoary concept of continuations (otherwise known as goto in a tuxedo).
The basic notion of a continuation is that it lets you exit from a scope (using neither a return statement nor a "throw" nor a continue nor a break), go do something else, then reenter the original scope as if nothing happened. In fact, if you serialize the continuation, you can come back months later, and continue in a new thread.
It may help to think of a continuation as a snapshot of the current call stack and program counter. The main intuition is that if you can save off enough information about the current execution context, you can reenter that context at your leisure, kind of like hitting Play again after Pausing a video to go make popcorn.
The concept of continuations has been around a long time. In fact, the formalisms around continuations were invented in order to talk meaningfully about the goto statement. But the goto entered lexical leper status after Dijkstra famously savaged it. By 1980, no self-respecting programmer (outside of the Scheme community -- a leper colony in its own right) would speak the word aloud, much less use it in a program.
And yet, goto is a reserved word in Java.
The reason continuations are important to Web 2.0 is that they hold the key to making AJAX scalable. Continuations enable a threadless polling architecture that would be hard to achieve (cleanly) any other way.
I'll have more to say on continuations. In the meantime, if you want to wrap your head around it further, I strongly recommend reading about Cocoon's use of continuations.
The basic notion of a continuation is that it lets you exit from a scope (using neither a return statement nor a "throw" nor a continue nor a break), go do something else, then reenter the original scope as if nothing happened. In fact, if you serialize the continuation, you can come back months later, and continue in a new thread.
It may help to think of a continuation as a snapshot of the current call stack and program counter. The main intuition is that if you can save off enough information about the current execution context, you can reenter that context at your leisure, kind of like hitting Play again after Pausing a video to go make popcorn.
The concept of continuations has been around a long time. In fact, the formalisms around continuations were invented in order to talk meaningfully about the goto statement. But the goto entered lexical leper status after Dijkstra famously savaged it. By 1980, no self-respecting programmer (outside of the Scheme community -- a leper colony in its own right) would speak the word aloud, much less use it in a program.
And yet, goto is a reserved word in Java.
The reason continuations are important to Web 2.0 is that they hold the key to making AJAX scalable. Continuations enable a threadless polling architecture that would be hard to achieve (cleanly) any other way.
I'll have more to say on continuations. In the meantime, if you want to wrap your head around it further, I strongly recommend reading about Cocoon's use of continuations.
Tuesday, March 28, 2006
Google brings <canvas> to IE
Upon joining the Canvas Developer's Group a few minutes ago, I caught wind of the (astonishing) fact that Google has hacked a <canvas> compatibility layer for IE users, essentially finishing work that was begun a few months ago by Emil A. Eklund. The hack, ironically, relies on VML (the IE-only graphics API that went largely ignored). A similar VML-based effort to bring SVG support (sans Adobe) to IE is being pursued by Mark Finkle.
The full Google <canvas> compatibility script is at http://www.abrahamjoffe.com.au/ben/canvascape/canvas.js.
Test it out on Canvascape.
The full Google <canvas> compatibility script is at http://www.abrahamjoffe.com.au/ben/canvascape/canvas.js.
Test it out on Canvascape.
Friday, March 24, 2006
Thursday, March 23, 2006
PayPal Computing
Just as Sun Microsystems announces supercomputing on demand, available to anyone and everyone for a paltry $1 per cpu-hour (PayPal gladly accepted), Amazon comes along and offers near-free data storage via its Simple Storage Service.
I suppose it's just a matter of time before Google steps in and moots both offerings.
But let's pull back for a minute and look at this carefully. Suppose you were to substitute the name "Microsoft" for Sun/Amazon/Google. Would you trust your online computing and storage needs to Microsoft, at any price?
Then why would you put that kind of trust in Sun, Amazon, or Google?
I suppose it's just a matter of time before Google steps in and moots both offerings.
But let's pull back for a minute and look at this carefully. Suppose you were to substitute the name "Microsoft" for Sun/Amazon/Google. Would you trust your online computing and storage needs to Microsoft, at any price?
Then why would you put that kind of trust in Sun, Amazon, or Google?
Monday, March 20, 2006
WS-Meltdown
Some revealingly candid dialog has been going on over at Loud Thinking regarding the slow, relentless heat death of WS-*. (Random quote: Getting your head around all the WS-* stuff is like trying to eat an elephant.)
Someone asked David Heinemeier Hansson whether he thought SOAP had legitimate uses or was, to the contrary, simply evil. DHH tactfully replied that SOAP mostly seems unnecessary. "So SOAP feels more like the doorknob to the gates of hell," he concluded. "In itself, a doorknob is hardly evil. But once you turn..."
Someone asked David Heinemeier Hansson whether he thought SOAP had legitimate uses or was, to the contrary, simply evil. DHH tactfully replied that SOAP mostly seems unnecessary. "So SOAP feels more like the doorknob to the gates of hell," he concluded. "In itself, a doorknob is hardly evil. But once you turn..."
Write Once, Curse Everywhere
Like many of my colleagues, I have a torrid love-hate relationship with the Java language.
But let us not forget, it's more than just a language. And therein lies the hitch.
Steve Yegge (now at Google) put together a refreshingly non-religious series of posts about various programming languages that, in one incarnation or another, can run atop the JVM. As an exercise, he wrote a simple game program, then ported it to various languages, then wrote about the experience.
Steve's appraisal of Java resonates with me. "Java has lots of wonderful features," he observes, "but Java isn't one of them. Java's appeal as a platform for doing real work rests precisely on its strengths as a platform, not as a language."
Hypothesis: Sun's greatest contribution to the history of computing is the 'VM', not the 'J', in JVM. The 'J' part is, like a 10-year-old Ford Taurus, beyond economical repair. Yet the world continues to use it, due to virtual-machine lock-in. The barriers to exit are just too high.
But let us not forget, it's more than just a language. And therein lies the hitch.
Steve Yegge (now at Google) put together a refreshingly non-religious series of posts about various programming languages that, in one incarnation or another, can run atop the JVM. As an exercise, he wrote a simple game program, then ported it to various languages, then wrote about the experience.
Steve's appraisal of Java resonates with me. "Java has lots of wonderful features," he observes, "but Java isn't one of them. Java's appeal as a platform for doing real work rests precisely on its strengths as a platform, not as a language."
Hypothesis: Sun's greatest contribution to the history of computing is the 'VM', not the 'J', in JVM. The 'J' part is, like a 10-year-old Ford Taurus, beyond economical repair. Yet the world continues to use it, due to virtual-machine lock-in. The barriers to exit are just too high.
Friday, March 10, 2006
MOA (Mashup Oriented Architecture)
MOA continues to move forward rapidly.
Some important Web 2.0 architectural memes are starting to come together in the form of things like Feedflare API, Ning Atom API, and shortText.com. (If the latter would expose a REST API, it could become the Clipboard of the Web instead of merely the Notepad of the Web.) What's interesting about the Feedflare API is that it involves late evaluation of embedded XPath, giving mashers a nice combination of declarative and imperative styles to draw upon. They also silently cast your RSS to Atom at parse-time.
As more and more powerful mash APIs come on the scene, and as people normalize on Atom as a datagram format, JSON as an object-passing/serialization format, things like shortText.com for clipboard storage, etc., Web 2.0 reaches an architectural maturity level where the likelihood increases that someone will create the "killer app" that finally tips the tipping point away from IE (for good), towards Firefox, Opera, and the Web 2.0 compatibles . . . thereby locking Microsoft out of a Web 2.0 future (if it isn't locked out already). The coming "killer app" will no doubt leverage one or another IE-incompatible technology such as <canvas> and/or E4X and/or Greasemonkey and/or SVG and/or some other cutting edge technology that's fully available in Firefox/Opera but not in IE.
Mark it as a future I-told-you-so.
Some important Web 2.0 architectural memes are starting to come together in the form of things like Feedflare API, Ning Atom API, and shortText.com. (If the latter would expose a REST API, it could become the Clipboard of the Web instead of merely the Notepad of the Web.) What's interesting about the Feedflare API is that it involves late evaluation of embedded XPath, giving mashers a nice combination of declarative and imperative styles to draw upon. They also silently cast your RSS to Atom at parse-time.
As more and more powerful mash APIs come on the scene, and as people normalize on Atom as a datagram format, JSON as an object-passing/serialization format, things like shortText.com for clipboard storage, etc., Web 2.0 reaches an architectural maturity level where the likelihood increases that someone will create the "killer app" that finally tips the tipping point away from IE (for good), towards Firefox, Opera, and the Web 2.0 compatibles . . . thereby locking Microsoft out of a Web 2.0 future (if it isn't locked out already). The coming "killer app" will no doubt leverage one or another IE-incompatible technology such as <canvas> and/or E4X and/or Greasemonkey and/or SVG and/or some other cutting edge technology that's fully available in Firefox/Opera but not in IE.
Mark it as a future I-told-you-so.
Wednesday, March 08, 2006
Adobe's Linux Problem
The astonishing finding (widely reported) that Adobe Photoshop is on the list of top-ten most wanted Linux applications tells me a couple of things.
It pretty clearly says that GIMP needs to suck a lot less.
Secondly, it tells me Adobe Systems doesn't really care about the Linux market (much less the community).
Adobe's Pam Deziel admits that the shrinkwrap giant has known for some time (well before the Novell survey) about the pent-up demand for a Linux version of Photoshop, based on its own research.
So in other words, Adobe has known for some time that it could make money tomorrow by offering a commercial version of Photoshop on Linux. It chooses to leave this money on the table (shareholders be damned). Not a big enough market, says Adobe.
How, then, does Adobe explain the fact that it currently offers a Solaris version of FrameMaker 7.2? FrameMaker has nowhere near as many users as Photoshop, and Solaris is nowhere near as popular as Linux.
Adobe's story is nowhere near making sense.
It pretty clearly says that GIMP needs to suck a lot less.
Secondly, it tells me Adobe Systems doesn't really care about the Linux market (much less the community).
Adobe's Pam Deziel admits that the shrinkwrap giant has known for some time (well before the Novell survey) about the pent-up demand for a Linux version of Photoshop, based on its own research.
So in other words, Adobe has known for some time that it could make money tomorrow by offering a commercial version of Photoshop on Linux. It chooses to leave this money on the table (shareholders be damned). Not a big enough market, says Adobe.
How, then, does Adobe explain the fact that it currently offers a Solaris version of FrameMaker 7.2? FrameMaker has nowhere near as many users as Photoshop, and Solaris is nowhere near as popular as Linux.
Adobe's story is nowhere near making sense.
Subscribe to:
Posts (Atom)