The essence of JIT is that it defers a substantial portion of compile-time to run-time. In a JIT scenario, we generate machine code just-in-time to execute it.
Now consider “scripting” languages like Perl, Python, Ruby, etc. These guys don’t even bother parsing ahead of time. My 2+ GHz processor hardly breaks a sweat.
OK lets review:
- Programming is hard
- Good design is difficult
- Optimization sucks
- Processor cycles are free
Clearly, if I can spend processor cycles to make programming easier, it’s worth it.
So why am I blathering on about this? Well, I thought there was nothing left for us to usefully push into run-time. I was wrong: we can still combine edit-time and run-time. Check out the Subtext programming language and this cool demo.
I’d like to be the first to say “blah blah…Smalltalk…blah blah….Lisp…blah blah”
Thank you.
:)
Smalltalk did its duty: it forced the community to embrace MVC.
J2EE falls short in Rapid Application Dev but GoF design patterns are key.
But… anything in excess, and now we have a behomoth of abstract classes and loosely coupled interfaces in this pourage of plugable modules.
Sure you can plug a toaster into your midi keyboard, but common.
And XML? Yikes. http://www.livejournal.com/users/hyperfl0w/18673.html
Subtext, while obviously premature, does its part:
Identify the problems we face today.
* We absolutely want to start with someone’s example and build on it
* Copy,Paste,Code
* Toolkits!
* etc (too tired to remember others)