Comment Re:Practical (Score 1) 617
Lisp will tend to dominate wherever the compute-to communication ratio is high, and the task is fairly complex.
What I mean by this is that if you spend, say, 10 times as much effort doing things as you do getting input or providing output, then lisp will probably be a huge win.
If you are wiring together a bunch of unix commands, bash or perl is pretty tough to beat (although scsh-scheme shell-is a decent entry here, too).
If you are writing device drivers, you will want assembler or C (or Schemeix-a kernel module that allows you to use tinyscheme to write device drivers in a garbage collected language with exception handling and continuations).
If you are going to do lots of talking to databases, then there are tons of options(like making up a mini-language in lisp/scheme to suit your needs, or skipping the db entirely).
If you have very heavy lifting to do-calculate the cheapest airfare from NYC-JFK to LAX or something similarly crazy-hard-then lisp is among the very few languages that are a legitimate option.
What I mean by this is that if you spend, say, 10 times as much effort doing things as you do getting input or providing output, then lisp will probably be a huge win.
If you are wiring together a bunch of unix commands, bash or perl is pretty tough to beat (although scsh-scheme shell-is a decent entry here, too).
If you are writing device drivers, you will want assembler or C (or Schemeix-a kernel module that allows you to use tinyscheme to write device drivers in a garbage collected language with exception handling and continuations).
If you are going to do lots of talking to databases, then there are tons of options(like making up a mini-language in lisp/scheme to suit your needs, or skipping the db entirely).
If you have very heavy lifting to do-calculate the cheapest airfare from NYC-JFK to LAX or something similarly crazy-hard-then lisp is among the very few languages that are a legitimate option.
