Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Javva The Hutt April 28th, 2003

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:



JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 029 contents | All Javva's articles

The future of programming languages

Paul Graham's talk on the evolution of computer languages is the kind of article that I call an "idea generator". The article itself would be pretty mediocre if you took out the basic idea: that of trying to predict the future of languages. But that's being mean, it's like saying that a sandwich is pretty bland if you take out the filling. Instead, I guess I should say that this is a great article because it really gets you thinking about the future of computer languages.

Is Java a dead-end like he thinks? I think that Java, as an offspring of Smalltalk, took one major feature which will be seen in languages of the future, the virtual machine. In that sense, I think you'll see Java as a core predecessor to any future language. Another major feature is HotSpot technology. Running an automated profiler on the code while it is running, automatically determining the bottlenecks, and optimizing them, all automatically. Of course you might say that this is not part of the language, but I think it is.

I don't think Strings being a separate data structure from lists is a case of premature optimization. Strings are fundamental to people because we do so much talking, writing, etc. In fact, one of the really great things about Perl is way that you could treat numbers as strings and strings as numbers a great deal according to the context. Strings are fundamental to people, I don't see any successful future language treating Strings as just another list. It is likely to stay a special type. It is extremely convenient to have it a special type. A vast number of programs out there are essentially string manipulation programs, simply because so much useful data is managed as Strings

Actually, I disagree with almost all of his specific predictions. For example, parallelism. Years and years ago I worked on a research project that looked at automatically parallelizing programs. We found that it was feasible for a large class of very complex cases. And it will only be the really long-running programs that need it in 100 years time. I expect it would be a parallel version of HotSpot technology. After a few seconds the VM identifies that the program needs to be parallelised, so it runs a parallel task of parallelising the running program. Just like HotSpot, it would probably spawn off parallel tasks bit by bit, as it recognized them.

What's funny is that he says

our ideas about what's possible tend to be so limited by whatever language we think in that easier formulations of programs seem very surprising

then goes on to use the idea of how we currently write a program as an example of how programs may be written. I think that programs in a hundred years will be written the way we handle instructions to other people. Simply put, when you want someone else to do something, you have two routes: you explain what you want done, or you give an example of how to do something and tell them to do the same but more or slightly different. You often do both of these. I think that typically you'll run through an example of what you want, then leave the computer to get on with it. Like recordable macros we have now. One of the great things the turned me on to emacs was the ability to record a sequence of edits, then just tell the thing to get on and do it to all to the rest of the doc. Couple that with a complete record of all the changes made, together with the ability to back out of any single change, and something that understands what the expected result should be like so that anomalies can be detected, and we would be where I expect programming to get to.

So, my prediction is clearly that the primary programming language in 100 years will be an intelligent macro recorder, runnning on a VM with a built-in optimizing parallelizing profiler, with every operation executing as an atomic transaction. And there will be only three data types: Strings, Numbers, and Composites.

All in all, a really great article for its main idea. It got me thinking, and just because I disagreed with a lot of what he said shouldn't change the benefits I gained from it.

Diary of a Hutt

March 5. Project Xenon. Who thinks up these stupid names, I ask you? In this case, it was probably Frezian. In what way this project resembles a noble gas, I have no idea. Perhaps Frezian liked the idea of having a "noble" project. Perhaps someone else thought he was full of gas. In any case, why didn't they start with Helium or at least Neon. That way they could have worked their way up to Xenon across project versions or new projects. Sort of like those stupid nineties project names from Microsoft which were cities on the way to Mecca. Boy, that was sure calculated to give offence at some point. Did you know that it's a secret project? Gotta give credit where credit is due, Frezian really knows how to get internal publicity. I would guess that he sent the photocopied memo to half a dozen people, carefully leaving one or two extra photocopies "accidentally" by the departmental photocopier. Every conversation that I heard that day seemed to start with "Hey, have you heard of the hotshot new hush-hush project in I.T.? I hear its called Project Xenon ..."

March 12. Naturally, I'm involved. It's a Java project, and I'll be handling the performance specifications. That little tick Weevil is doing the QA program. We've already had our first run in, about testing resources. He suckered both Frezian and HasntGotAClue into believing him. "As we can have only one dedicated test environment, of course we'll have to share this between the QA testers and the performance testers". Fair enough, I agreed, but then came the sucker punch: "Of course the QA testing needs manual oversight because of the frequent errors that break the tests, whereas performance tests can easily be run unattended overnight and analyzed the next day". I couldn't try to deny we could run automated tests, after all, that's one of the productivity benefits of my management that I've pushed often enough. So there I was, committed to years of night time access to the test environment. I could see Weevil was savouring that. The word "Slimeball" popped into my mind. Well, I'll have to come up with some strategy for future projects to avoid this, but for the moment I guess I'm up the proverbial creek without a paddle.

March 19. I've been working with HR to see if we can offer Boris and Brainshrii the option of flexi-time. Being a progressive kind of person, I feel that certainly I trust these excellent employees to adjust their working patterns to their natural bio-rhythms. In fact, I feel sure that their productivity will rise as a result of moving to more flexible working practices. Brainshrii hasn't started yet, but he seemed quite positive towards the idea when I spoke to him. He's even less intelligible on the phone than in person, but he's clear as crystal in an email. Boris seemed quite positive towards the proposed change in employee terms and conditions.

March 26. Of course, its not yet a done deal. Apparently, these things need to go through legal checks, and the employee needs to be made fully aware of how any changes in contract may affect him. But it looks like I'll be able to sleep comfortably at night knowing that my efficient lieutenants will be ensuring that any performance testing is going according to plan. Unfortunately, I probably won't be able to be present as my non-flexi-time contract would place any night-time activity into my over-time bracket. And that would be an unnacceptable expense for HasntGotAClue.

BCNU

Javva The Hutt.


Back to newsletter 029 contents


Last Updated: 2017-11-28
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/javvathehutt029.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us