Hailed Eris: > I was alluding to the expressive power of C versus LISP considered with > respect to the primitives available on one's computing platform and > primitives in which solutions to one's problems are best expressed.
I think one of the reasons there exists little languages, and cliches such as "the right tool for the job", is that the "primitives available on one's computing platform" are very often not the "primitives in which solutions to one's problems are best expressed." In this respect rating the "expressive power of C versus LISP" depends very much on the problem domain under discussion. For "systems programming", C has the advantage in both practice (use in running systems) and theory: processes which take a lot of system resources to execute also tend to take a lot of C code, whereas in most higher-order languages, things which represent high-level runtime-consuming abstractions tend look little different than simple bit-level operations. The difference is one of approach, I guess: whether you want to write optimal code yourself, and see what the machine is doing, or trust the compiler to find a good way to translate to machine language and run (in real-time) your efficient-to-code higher-order functions. The better the translation from the higher-level language, the more this difference becomes a matter of taste, programming style, availability of programmers, and the body of domain knowledge already represented in language libraries. I would like to see Haskell fill C's niche: it's close to C's execution speed now, and pure functions and a terse style gives real advantages in coding speed (higher-order functions abstract common "patterns" without tedious framework implementations), maintainability (typeclasses of parameters in utility functions means you don't write different implementations of the same function for different types, yet preserve type compatibility and checking), and reliability (pure functions don't depend on state, so have fewer moving parts to go wrong). Jason Catena
