Derek Dongray (12/15/2008)
This sounded like FUD so I thought I'd try it out. C# console app, 5k executable. And with code that's orders of magnitude easier to maintain. There's nothing even remotely simpler or faster about what you wrote. I built the example in under a minute and had output of a real world, distributable application. All you have is DOS script. What's the point you're trying to make here? 27 bytes of source that's good for nothing?
Most people posting here sound completely detatched from reality and are completely ignoring the benefits modern tools give the developer. ASP.Net let's you build a scalable, thread-safe web app in a day. You can go back to C and write procedurally, or to C++ and have to manually manage memory again, but there's a reason people don't and why you'll never get a business case off the ground to do so. Hey, chuck out web services and go back to writing proprietary APIs coded directly to the TCP/IP stack while you're at it. That'll make your app faster to write and resuable for partners, I'm sure.
The reason apps take longer to write nowadays is they're bigger, talk to more systems, manage more data, and have more bureaucracy as a result. Crappier tools won't change any of that. If you don't want to design an enterprise data model to aggregate your systems you don't have to. If you don't want to go to the effort of building using SOA principles you can still do one off "enhancements" on two systems to move data with flat files. But you get what you pay for and there's a reason these are considered bad practices in the real world.
OK. I been developing software for about 30 years, so have this vague idea that I understand it. The list of languages I've worked with include assembly code for many platforms (IBM 360, DEC PDP-7, -8, -10, -11 & -15, Intel x86 series...)as well as assorted high-level compiled and scripted languages such as PL/1, Fortran, Basic (many flavours), Pascal, C, C++, VB, Perl, PHP, SQL, etc. Applications I've worked on range from simple single-use apps to large applications used by thousands of users. I also worked on compilers, which is why I am certain that applications have got slower.
My example was written using the DOS debug command because I no longer have an assempler installed. The point was to show that current compilers are terribly inefficient and that the user interface actually prevents the developer from writing efficient code. I would say it's impossible to tell whether a 27byte program is faster than a 5k one because the execution time of either would be milliseconds and most of this would be in overhead external to the actual code.
I agree that writing a "Hello, World!" program (or any program) in assembler these days is probably overkill (as well as the fact that the program is pointless). But my point is that the tools do not give enough control to reach the optimal solution. I know that to do the job I want done (output "Hello, World!") the minimum needed is 27 bytes, but, as you pointed out yourself, there's no way to get close because the tools insist on including checks which may or may not be needed. "Hello, World!" only uses constants, so there is no need for memory management, but you can bet that all the check routines for stack overflow and so forth are getting dragged in even if there is no chance of them being triggered.
I also agree that, for maintainability and speed of development, it's much better to work in as abstract a language as possible and let the tools take care of the details. But the problem is that the overheads resulting from this abstraction invariably results in slower code and, very often, you can't provide the necessary hints to reduce the overhead or, if you can, people don't bother.
In SQL terms, this means that although SQL is supposed to be declarative (tell the server what you need not how to get it), since the tool (in this this case the optimiser) is just another application with limitations, the developer very often ought to be guiding it how to get the best result.
But the trouble is that a lot of modern developers tend not to do this (they just argue that you need a faster server) so applications run slower than they need to.
Apologies for the length of this, but it is something I feel strongly about. I beleive developers should not just write code that works and let the tool optimise it, but should think about all the steps (even in SQL) and see if they can improve on the speed of the result. As I mentioned above, far too many people stop at "it works".