Java:

Java is the most used language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling Java to accommodate more programming styles (e.g. functional programming via closures). Others believe that being lightweight is a virtue.

JavaScript:

JavaScript is the most deployed language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling JavaScript to accommodate more programming styles (e.g. by adding classical inheritance not just prototypal inheritance, and an optional type system). Others believe that being lightweight is a virtue.

Features:

It's interesting that the current simple version of JavaScript already has the features (i.e. closures) that people want to keep out of Java otherwise it will become too complex, and that Java already has some of the features (i.e. classical inheritance) that people want to keep out of JavaScript, otherwise it will become to complex.

Crossroads:

The Java language is challenged by languages such as Ruby, Groovy and even Scala, all of which support closures. The majority of people that have spent serious time with these languages prefer them over Java for at least some set of problems.

The JavaScript language is challenged by Silverlight. Microsoft try to avoid saying things like "death to Ajax", but secretly (or not so secretly depending on who you talk to) they would love to control the platform once more, and Silverlight is the latest attempt at regaining control.

Features vs. Complexity:

Joel noticed that there is a big difference between good developers and bad developers. Google noticed it with it's picky hiring process. On many projects there are a few developers that do all the real work, while others just slow things down.

But much of the "keep complexity out of the language" debate is aimed at helping the people that write less code anyway.

Nail-guns and angle grinders are dangerous tools, but the building trade accepts the danger in the name of greater productivity. In software development where the difference between good and bad developers is that much greater, and where developers don't actually get physically maimed, the argument for power over simplicity is that much stronger.

In summary, extra power helps smarter developers work more quickly, but makes life harder for less smart developers. Since a small number of smarter developers generally do better work than a large number of no so smart developers, we should tend slightly toward giving developers more powerful tools.

Java:

In Java, BGGA closures enable higher-order programming. It's hard to say that the addition of closures in and of itself would cause a complexity implosion, after all, Java is virtually the only modern day programming language without them. It could be argued that the Java language can't be evolved to accommodate them, but I'm leaning towards there being a net gain by including them.

Interestingly, Google Android contains a clean room re-implementation of Java. If Sun (or the JCP) accepts closures, and if (as seems likely) Google votes against them, what will happen to Android? Will it follow how Google votes, or how Java evolves?

JavaScript:

With JavaScript, people see a neat, compact language and fear it turning into Java. The good news is that it won't fully turn into Java because JavaScript already has closures and no one thinks they should be taken out ;-) The danger of the "features over complexity" argument, is that it can be applied indiscriminately, creating a monster, and the fear is that JavaScript will become a monster.

I'm gradually coming round to the opinion that many of the changes proposed to JavaScript actually reduce complexity. There are nearly as many frameworks that add classical inheritance to JavaScript as there are Ajax frameworks. Having one solution that we can all agree on can't be a bad thing even if you prefer prototypal inheritance.

*: For some value of simple. The exact definitions of simple used in these 2 paragraphs are not necessarily the same.

Responses[7]

Posted by Joe Walker on 17 December 2007 13:19:28 GMT #

This is very good news for DWR and for Ajax on Java.

The short version is that DWR is now part of the Dojo Foundation and that I now work for SitePen. This means that I'll be working nearly full-time on DWR rather than spending part of my time stuck in a big enterprise with Word as my IDE churning out technical architecture documents.

There are a whole bunch of questions that I just know I'm going to get asked:

Does this mean that DWR is going to become part of Dojo?

No. DWR will remain totally independent. There are some bits that I'd quite like to steal (JS compression for example) but you won't need to use Dojo if you want to use DWR or the other way around.

What's going to happen to Getahead and the DWR website?

For some time you've been able to visit www.directwebremoting.org and get redirected to the DWR website. We'll be moving the DWR website over to Dojo Foundation infrastructure and making use of the new domain at the same time. I'll be keeping my blog at Getahead for now at least. Consulting deals that Getahead would have done in the past will now be done by SitePen.

Who are SitePen?

SitePen employ a bunch of cool hackers: Alex Russell and Dylan Schiemann and many other Dojo people, Kevin Dangoor (Turbo Gears), and many more. They offer support packages for Dojo and now DWR, but also develop complete solutions.

What's happened to the TIBCO deal?

It's not gone away. I'll still be working to enhance DWR's Reverse Ajax proxy APIs, which from the next version of DWR particularly should aid DWR/GI integration.

Kevin Hakman from TIBCO is quoted on the official press release:

"Development teams, both small and large, have quickly discovered the benefits of using DWR in conjunction with leading Ajax libraries like Dojo, TIBCO General Interface, Scriptaculous, and others. DWR joining the Dojo Foundation is a great win for the DWR community," said Kevin Hakman, director, TIBCO Software, Inc. who has been a corporate sponsor of DWR's development for more than a year. "The close alignment of these projects, and the anticipated integration points between them, will serve to further simplify creating Ajax applications for Java developers."

Responses[7]

Posted by Joe Walker on 11 December 2007 16:45:21 GMT #

Dear Sun,

You recently asked for my feedback as a previous attendee of JavaOne. I'd like to add the following to my comments about how to improve things:

Please, please, don't force the trademark lawyers to change my presentation.

Each year the lawyers get to hack about with my presentation. Last year I had a slide that said DWR could:

"Use Java EE role based security to declare roles that can access methods"

However, this got changed to:

"Use Java™ Platform, Enterprise Edition (Java EE platform) defined role based security to declare roles that can access methods"

And when I claimed that DWR could marshal:

"JavaBeans and Objects"

This was changed to"

"JavaBeans™ architecture and Objects"

This is now technically incorrect - DWR can't marshal the entire JavaBeans Architecture - it might be cool if it could, but it can't.

The logic behind the trademark changes are that Sun are seen as the publisher of the presentations, so for them to publish the talks without proper trademark usage could lead to a case that Sun have lost their trademarks.

However, in reality, Sun have published in literally thousands of places on the web without the correct trademark phrasing. The (TM) symbol is missing from virtually every use of the word 'Java' on Sun's website, so why confuse presentations by insisting on strange phrasing there. Why not worry about java.net, where I can freely alter text without worrying trademark lawyers?

Please, please, make the presentation template ultra-minimalist.

How many of the presentations on SlideShare would be improved by the use of a standard template? Talking of which, this presentation is one of the most popular presentations ever on SlideShare ever. It would be destroyed by a template.

The presentation from Asa Raskin's brilliant talk "Don’t make me click" from the Ajax Experience was just a series of icons, where the point was made through the icons. Again, a presentation template would have destroyed the talk. The same goes for Dick Hardt's seminal "Identity 2.0" talk from OSCon 2005.

Many postings on Presentation Zen are about the problems of bullet points, but the presentation templates encourage people to use bullet points and to get sucked into the trap of reading from the slides.

I totally understand the need for some branding, but it doesn't need to be on every slide, and it shouldn't discourage people from being creative in how they present.

I like creating a good presentation, but whenever it comes to creating a presentation with a mandated template, I feel that some of the opportunity for creativity has been taken away, and the presentation suffers as a result.

Thanks for listening,

Joe.

What do you think? Is a conference helped by having a common theme across all presentations?

Update: Hani makes the good point in the comments that there is time in the 'Speaker Ready Room' to fix the problem. This is true, and I've spent several hours doing just that. However, if Sun just dropped the whole lawyer review thing, they could push back the deadline for slides, which might mean that talks were not 6 months out of date by the time they were presented.

Responses[2]

Posted by Joe Walker on 29 November 2007 13:03:33 GMT #

Cringely may know enough about social security fraud that the DHS want his advice, but I'm not sure he's got good advice about password security.

He starts well:

Identity thieves... can start a sweepstakes website that requires only free registration to win that cruise of a lifetime to Bora Bora. And in doing so the thieves can know that a majority of registrants will use a username and password combination that they also use at a lot of other sites, like bank and brokerage accounts. Not only don't they need to actually award the cruise, they don't even have to break into your bank account in order to benefit from the username/password combo. They just sell that information to another crook.

But the conclusion:

So CHANGE YOUR DAMNED PASSWORDS and put an end to this kind of scam. Perhaps remembering new character strings will help to stave off Alzheimer's.

This has to be terrible advice:

If the crook can get to your bank, and work out that you've used the same password details (he doesn't say how the crook is going to get your bank account number) then one thing is certain - the crook can get there faster than you want to change your passwords. Suppose the crook is going to sell the personal info that night in the pub to a mate whose going to plug the data into his account cracker later on that week. That means you should be changing all your passwords at least once per week. And that's only going to stop the slow crooks.

Things that help password security:

• Complex strings that are not guessable.
• Passwords that differ from site to site

I'm yet to see any situation where changing your passwords helps. If the bad guy once knows your password and can impersonate you, the chances are that he's changed your password and locked you out, or installed a backdoor so changing your password doesn't keep him out anyway.

So how do you use a different complex passwords on each site and still remember them all?

This is a good trick. It uses 3 components:

• Pick a random string of 4 characters containing upper/lower case letters and numbers. e.g. tS8j
• Decide on a way to mangle the domain name of the website to get 3 letters that are not obviously related to the domain. Suppose you want 3 letters from google.com. You could pick the 3 from the end in reverse order: elg, you could type the first three letters one key up on your keyboard: t99, you could Caesar shift: hpp, pick the middle 3: oog, etc, etc.
• A single digit/letter that you can increment (or decrement) when someone insists that you change your password.

Then put those characters together in some order, so you might end up with tS8jelg0 or oogAtS8j. Then use the same system, with the same set of 4 random characters, just changing the 3 characters per domain and the one character whenever someone forces you to change.

This may sound overly complex and paranoid, but it is lots easier than changing your passwords on a regular basis, and far more secure.

Using regularly changing passwords just forces you to use simpler passwords to avoid forgetting, and simpler passwords are far more of a risk than re-using passwords, or using guessable ones.

Responses[5]

Posted by Joe Walker on 20 November 2007 10:32:45 GMT #

Comet Daily is new - dedicated to all things Comet. The idea, if we can get enough content, is to have regular - even daily, postings on the growth of Comet.

There are a whole bunch of people writing, and claiming that they are going to be writing.

It's easy to disparage Comet as just Push, and to remember PointCast. But 1995 was the wrong side of the Ajax boom and the wrong side of the whole social explosion. The tipping point is where those 2 trends crossover - which is the point of my first article:

Add a comment

Posted by Joe Walker on 07 November 2007 10:38:47 GMT #