The key here is the application you're writing - The vast majority of enterprise apps do more or less the same thing -
1) They put a form onto the screen
2) They wait for some user input
3) They perform a database search on the basis of that input
4) They perform some basic math (multiplying the unit price by 1.05 to add sales tax for example)
5) They put some data back into the database.
When you look at the app's behaviour, it's actually waiting for something most of the time - Waiting for the user to press a key, or for the database to return some result.
It doesn't matter how fast your code is - All apps "wait" at the same speed.
The scenario I've shown above may be generic - but it's what the majority of enterprise applications do. In this scenario it's very hard to justify writing the app in a 3GL or Assembler.
There are plenty of other scenarios, though, where no matter how fast processors are, or how cheap memory is, there is going to be an advantage in writing native code. Any very complex math, massively parallel task management, device drivers etc will, in general, be more suited to a lower level language. But even here, I think that exceptions can and will emerge - Domain specific higher-level languages will increasingly do a "better job" of creating fast code than we can.
In practice higher-level languages, scripting languages, 3gls and Assembler have co-existed for decades and will continue to do so. Better approaches to interfacing and re-use should actually make this even easier to do - So we'll use higher level tools and scripts to tie things together, paint UI's and do lots of groovy IO and presentation layer stuff, while invoking services that have been implemented using all sorts of lower-level techniques.
There's a cultural factor too... I've seen evidence of "language machismo" in my time... developers insisting that their hand crafted code will "always be better than that nasty generated stuff" - In my experience, while this is sometimes true, it isn't always the case. So perhaps we need to exercise a little more circumspection when we sit down to make our choices?
Slashdot Mirror
The key here is the application you're writing - The vast majority of enterprise apps do more or less the same thing -
1) They put a form onto the screen
2) They wait for some user input
3) They perform a database search on the basis of that input
4) They perform some basic math (multiplying the unit price by 1.05 to add sales tax for example)
5) They put some data back into the database.
When you look at the app's behaviour, it's actually waiting for something most of the time - Waiting for the user to press a key, or for the database to return some result.
It doesn't matter how fast your code is - All apps "wait" at the same speed.
The scenario I've shown above may be generic - but it's what the majority of enterprise applications do. In this scenario it's very hard to justify writing the app in a 3GL or Assembler.
There are plenty of other scenarios, though, where no matter how fast processors are, or how cheap memory is, there is going to be an advantage in writing native code. Any very complex math, massively parallel task management, device drivers etc will, in general, be more suited to a lower level language. But even here, I think that exceptions can and will emerge - Domain specific higher-level languages will increasingly do a "better job" of creating fast code than we can.
In practice higher-level languages, scripting languages, 3gls and Assembler have co-existed for decades and will continue to do so. Better approaches to interfacing and re-use should actually make this even easier to do - So we'll use higher level tools and scripts to tie things together, paint UI's and do lots of groovy IO and presentation layer stuff, while invoking services that have been implemented using all sorts of lower-level techniques.
There's a cultural factor too... I've seen evidence of "language machismo" in my time... developers insisting that their hand crafted code will "always be better than that nasty generated stuff" - In my experience, while this is sometimes true, it isn't always the case. So perhaps we need to exercise a little more circumspection when we sit down to make our choices?