Efficient Software (by alaric)
Getting a factor-of-20 speedup by writing it in C rather than some highly dynamic language suddenly seems rather unimpressive. Especially if the highly dynamic language is living up to the promise of reducing development time by a large factor. If the app takes a quarter of the time to reach feature-completeness, you can afford to spend more programmer time on good algorithms, then spend the rest of the programmer hiring costs saved on having twice as many servers, increasing your capacity and increasing redundancy (thus decreasing the impact of a server dying).
So I think the focus of "platform developers" (people who design programming languages, programming frameworks, database servers, operating systems, and the like) aiming for efficiency should be on commpactness, followed by the order-of-magnitude speed improvements provided by good algorithm choice (which IMHO mainly means ditching SQL for something that's easier to optimise without needing intimate knowledge of the innards the query planner, and with more flexible locking; then at the programming language level, offering decent standard implementations of data structures). But, also, that efficiency shouldn't be a very high priority. As long as it's easy for programmers using your platform to ensure they are using the correct algorithms, getting a factor of 20 improvement in the speed of executing that algorithm is wasted if the system spends most of its time idle, waiting for the disk or network.
In this day and age, the pressures upon a software development team are more rapidity of development, flexibility, and reliability of the application. They need to get the application out of the door before the competition does, and with less bugs (and less time spent testing) than the competition, and then be able to quickly adapt it to produce the next version. It's inefficient to throw away the software and write the next version from scratch because some core assumption has changed.
Languages with metaprogramming facilities, modularity, object orientation (or some variation on that theme) and loose type systems are a help here.
Modular applications are easier to test since parts of the application can be tested in isolation and faults traced quickly. They can be modified more easily, since the well-defined interfaces between modules make it easier to see which parts of the system are affected by a change, and often reduces the amount of changing required.
At the simpler end, metaprogramming means less boring template code. Common patterns can be abstracted into a useful macro. You can create tools to help you program, at a much higher level of abstraction that just writing reusable functions. At the higher end, metaprogramming lets you seamlessly integrate snippets of alternative programming paradigms into your code (the standard textbook examples are nondeterministic or logical programming) - particularly when you're using a programming language that supports native continuations.
Loose type systems are an aid to metaprogramming, and in normal code mean less writing of wrappers and casts and adapters. Most of what's painful in Java is due to overly strict typing.
It's a testament to this that languages like Python and Ruby are becoming popular for modern application development. They make it easier to produce code, so the programmer can get to market quicker, or spend more time on developing new features. But metaprogramming support is still primitive in those languages. Lisp derivatives still hold the edge there, and are fast catching up in the areas they've fallen behind in (namely, portability and useful standard libraries).
For example, Chicken Scheme implements the Scheme dialect of Lisp, satisfyingly efficiently, while providing libraries for object orientation, multithreading, sockets, database access, unit testing, and so on.
There's simultaneously a shortage and surfeit of Web frameworks in the spirit of Ruby on Rails for Lisps. The thing is, with decent metaprogramming, it's so easy to roll your own (you want to dynamically generate classes that wrap SQL tables? Sure, no problem!) that lots of people have made their own frameworks and published them as open source - yet not many others use them, because they roll their own. Time shall tell if any one of them accretes enough useful features to start becoming easier to learn than to re-implement.
These features make a program shorter while still providing the desired functionality. Shorter programs are quicker to write, harbour less bugs, and are easier to change in future. And they can often actually be faster to run; easier programming makes it less painful to use more complicated algorithms, and allows more time for optimisation such as more clever caching to avoid disk and network I/O, more efficient use of memory so more can be cached, more compact data formats so there are shorter waits for I/O, and so on.
However, when it comes to bulk arithmetic jobs like graphics, audio/video processing, and scientific computation, you do need access to a low-level language that lets you more directly manipulate the resources of the CPU to use them to best advantage. But these are usually relatively small parts of the actual application; a particular inner loop. Therefore, there should be easy and efficient bindings from one's high level metaprogramming language into something low-level. Ideally, the two languages should share as much "mental model" as is practical, to keep the interaction seamless. This is something I'm still exploring.
It's still early days, as lots of people still feel that programming in C is the logical way to more efficient programming, but I think the software industry is slowly starting to learn this.
Fri 20th Apr 2007 10:24 pm 
Subscribe
By woolstar, Thu 26th Apr 2007 @ 6:38 am
What I love is that shell sort beats quicksort every time, and its easy, and nobody can tell you precisely how it works. It just does. It doesn't always beat quicksort, but its consistent. Lovely thing.
Btw, the people who care about performance, now live in the land of the mobile phone. Year 2007: cpu 100mgz, memory 8mbs. Wow, seems like I was here before.