CNET is reporting that Sun Microsystems plans to simplify Java software development by combining portal and integration software in addition to releasing Sun ONE Studio. According to the article, Sun executives said the new tool will be targeted at developers that have a Visual Basic skill level. Microsoft's Visual Basic is easier to work with than most other programming languages.
Making development easier is certainly the right idea, but attempting this with the Java programming language seems to be an oxymoron. Being that I'm a recovering Visual Basic guru and having some knowledge of Java, I know.
I think a complimentary scripting mechanism for working with Java beans and services would be more effective and appropriate to making the Java family more accessible and more useful. Support of ECMA/JavaScript would be ideal because its fairly simple to learn, reflect's Java OO nature and has its own extensive developers community. Its also platform-agnostic and its not Microsoft's. ;)
It probably wouldn't take much to develop. In many ways, though not all, this would be along the lines of IBM's Bean Scripting Framework (BSF). There is also the Rhino project which has ported the Mozilla scripting engine into a Java form.
This approach would be a more effective way because skilled Java programmers can focus on complex and intricate tasks and let less skills staff (perhaps even tech saavy business users) rapidly glue that functionality together. Don't forget these skilled programmers sometimes need to get apps done quickly – like a prototype. Sometimes they have to ship that prototype.
Back in February Jon Udell wrote about refactoring the enterprise where he quotes Ward Cunningham extensively. Ward explains it best when he says:
There is a huge opportunity lurking up ahead. The enterprise guys don't know it because they think scripting is for sissies. The scripting guys don't know it because they think business problems are already simple and don't have to be made that way.
Jon continues.
Modern scripting languages have two important properties that qualify them for [scripting the enterprise in business terms as well as in IT terms]. First they use fewer tokens (words) to express concepts.
When you look at a program and try to reason about it,says Ward,the fewer the tokens, the faster you can reason about them – that's important.Second, their powerful and fluid object models support continuous refactoring. Ward says it plainly:You get to make the words say what they are.
What they are, increasingly, is business processes. And here we run into a major disconnect. To the enterprise, scripted solutions look like one-offs, not strategic systems designed to high standards of quality and able to evolve along with the business. What the enterprise folks don't get is that scripted systems can be engineered to meet these requirements. So they lean toward C++ and Java, and then rely on powerful integrated development environments, like Eclipse and IntelliJ IDEA, to make fluid refactoring possible. These tools can work very well.
They're complicated,observes Ward,and you have to learn how to work them – but boy, when you do, they make those languages start to feel like scripting languages.On the other hand, he asks,Why should we need heroics in the IDE to correct for misguidedness in the language design?It's a question of suitability for purpose.If the purpose is to continuously evolve programs for business, then what's suitable is to have clean object models that are easy to read.
Java cannot be all things to all people. (Is it really appropriate to make user learn Java for writing macros to automate their business documents as porposed in StarOffice? No, its not.) Java does alot of things well, but with great power comes great headaches. Creating more sophisticated and fat tools to abstract programming language complexity does not really solve the problem, but defers it – perhaps even make it worse. Besides abstractions always leak.
It will be interesting to see what they eventually come up with though I do miss the days when Sun would create innovative and original technology and not try to copy someone else. (They do the former better.)
<p><a href="http://news.com.com/2100-1007-993248.html">CNET is reporting</a> that Sun Microsystems plans to simplify Java software development by combining portal and integration software in addition to releasing Sun ONE Studio. According to the article, <q>Sun executives said the new tool will be targeted at developers that have a Visual Basic skill level. Microsoft's Visual Basic is easier to work with than most other programming languages.</q></p>
<p>Making development easier is certainly the right idea, but attempting this with the Java programming language seems to be an oxymoron. Being that I'm a recovering Visual Basic guru and having some knowledge of Java, I know.</p>
<p>I think a complimentary scripting mechanism for working with Java beans and services would be more effective and appropriate to making the Java family more accessible and more useful. Support of ECMA/JavaScript would be ideal because its fairly simple to learn, reflect's Java OO nature and has its own extensive developers community. Its also platform-agnostic and its not Microsoft's. ;)</p>
<p>It probably wouldn't take much to develop. In many ways, though not all, this would be along the lines of <a href="http://www-124.ibm.com/developerworks/projects/bsf">IBM's Bean Scripting Framework (BSF)</a>. There is also <a href="http://www.mozilla.org/rhino/">the Rhino project</a> which has ported the Mozilla scripting engine into a Java form.</p>
<p>This approach would be a more effective way because skilled Java programmers can focus on complex and intricate tasks and let less skills staff (perhaps even tech saavy business users) rapidly glue that functionality together. Don't forget these skilled programmers sometimes need to get apps done quickly – like a prototype. Sometimes they have to <a href="http://www.infoworld.com/article/03/02/06/06stratdev_1.html">ship that prototype</a>.</p>
<p>Back in February Jon Udell wrote about <a href="http://www.infoworld.com/article/03/02/13/07stratdev_1.html">refactoring the enterprise</a> where he quotes Ward Cunningham extensively. Ward explains it best when he says: </p>
<blockquote>
<p>There is a huge opportunity lurking up ahead. The enterprise guys don't know it because they think scripting is for sissies. The scripting guys don't know it because they think business problems are already simple and don't have to be made that way.</p>
</blockquote>
<p>Jon continues.</p>
<blockquote>
<p>Modern scripting languages have two important properties that qualify them for [scripting the enterprise in business terms as well as in IT terms]. First they use fewer tokens (words) to express concepts. <q>When you look at a program and try to reason about it,</q> says Ward, <q>the fewer the tokens, the faster you can reason about them – that's important.</q> Second, their powerful and fluid object models support continuous refactoring. Ward says it plainly: <q>You get to make the words say what they are.</q> </p>
</blockquote>
<blockquote>
<p>What they are, increasingly, is business processes. And here we run into a major disconnect. To the enterprise, scripted solutions look like one-offs, not strategic systems designed to high standards of quality and able to evolve along with the business. What the enterprise folks don't get is that scripted systems can be engineered to meet these requirements. So they lean toward C++ and Java, and then rely on powerful integrated development environments, like Eclipse and IntelliJ IDEA, to make fluid refactoring possible. These tools can work very well. <q>They're complicated,</q> observes Ward, <q>and you have to learn how to work them – but boy, when you do, they make those languages start to feel like scripting languages.</q> On the other hand, he asks, <q>Why should we need heroics in the IDE to correct for misguidedness in the language design?</q> It's a question of suitability for purpose. <q>If the purpose is to continuously evolve programs for business, then what's suitable is to have clean object models that are easy to read.</q> </p>
</blockquote>
<p>Java cannot be all things to all people. (Is it really appropriate to make user learn <a href="http://news.com.com/2100-1001-975529.html">Java for writing macros to automate their business documents</a> as porposed in StarOffice? No, its not.) Java does alot of things well, but with great power comes great headaches. Creating more sophisticated and fat tools to abstract programming language complexity does not really solve the problem, but defers it – perhaps even make it worse. Besides <a href="http://www.joelonsoftware.com/articles/LeakyAbstractions.html">abstractions always leak</a>. </p>
<p>It will be interesting to see what they eventually come up with though I do miss the days when Sun would create innovative and original technology and not try to copy someone else. (They do the former better.)</p>
Leave a comment