In this respect rating the "expressive power of C versus LISP" depends
very much on the problem domain under discussion.
Of course. I pointed out in my first post on the thread that "[...] for a
person of my (low) caliber, LISP is neither suited to the family of
problems I encounter nor suited to the machines I solve them on." I cannot
exclude other machines and other problems but can talk from what little I
have personally experienced.
I would like to see Haskell fill C's niche [...]
Is it as readily comprehensible to newcomers as C? Are there texts out
there that can welcome a real beginner in programming and help him become
productive, on a personal level at least, as rapidly as good C
textbooks--you know the classic example--do? Is there a coherent mental
model of small computers--not necessarily what you or I deem to be a small
computer--that Haskell fits well and can be taught to learners? I imagine
those will be indispensable for any language to replace existing languages,
much more so in case of C.
--On Saturday, September 05, 2009 20:58 -0500 Jason Catena
<jason.cat...@gmail.com> wrote:
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
