N programming, efficiency always entails a cost. Contrariwise, simplified and inefficient code is often easier to understand. Where can balance be found? Can it ever be found? Efficiency is often preferred by so-called ‘power users’, whereas others opt for simplicity. Consequently, when negotiating projects, either at code-level or when deciding on UI design, flame wars may arise among developers or avid users.
Let us consider code optimisation. If the programmer wants to go all the way, (s)he could optimise by shortening variables, removing excessive spaces, and stripping out newlines. In such circumstances, interpreted code will be quicker, albeit less meaningful when an error arises and goes verbose. This is nothing like bytecodes and JIT, but similar rules should apply.
Good code should be well-structured, easily-readable, elegant, and well-documented. If the code is compiled, all comments should definitely stay in tact rather than ever be stripped. Automatic documentation can fit nicely in the source rather than be generated and made peripherally available, e.g. via Web pages. The only exception is debugging ‘bits’, which could definitely slow down program execution. As long as the developer keeps the original and saturated version of the code public, however, nobody need get entangled in closed-source traps.
On to an exciting prediction, with lowered file sizes and optimised code, programs could scale better on Wi-Fi-driven Web servers which run on a PDA in one’s pocket. Such server must be properly taken good care of, as well as the Internet connection, which is as vital as that of a synapse. With the growth of smaller devices, the need for efficiency is better realised.