On Thu, Aug 10, 2006 at 11:26:01PM +0900, Francis Cianfrocca wrote:
> 
> To take a step back from CS, here's the high-level thing that really
> troubles me: why is there such an impedance mismatch between the
> things we need to achieve in software and the available tools? Why do
> I always feel like it takes mountains of "code" to do things that can
> be described without too much difficulty? I'm not saying that
> genuinely complex problems should be reducible beyond what makes
> sense. I'm also not underrating the difficulty of good software design
> or the difficulty of communicating well with the clients. But I'd
> rather that *most* of the effort go into those areas. As things stand,
> I have to solve a lot of computer-language-generated problems that do
> not contribute value to the solution. It's like our machines have too
> much friction.
> 
> 
> I would *gladly* give up Turing-completeness in order to get a
> (domain-specific) language that was more expressive (less
> "frictional") in terms of the problems I need to solve.

For that, you pretty much have to choose the language that is least
"frictional" for the specific task you've undertaken.  For certain web
development tasks, nothing beats PHP -- PHP programming mostly consists
of looking up already extant core language functions and gluing them
together with some control structures.  For something that doesn't
neatly, and roughly exactly, fit the mold of any of PHP's core
functions, you tend to find yourself battling the language quite a lot,
fighting with its half-baked semantic structure and trying to squeeze
blood from its very anemic syntax.  Perl provides a (slightly less, but
still) very accessible analog to the PHP core function bucket in the
form of CPAN, but you have to choose our modules wisely -- meanwhile,
Perl's semantic structure is better designed and more enabling, while
its syntax is far, far richer, but you have to be careful about how you
write programs so that you don't do something you won't understand later
(like, tomorrow) and be unable to maintain.  It's easy to write
maintainable Perl, contrary to the common "wisdom", but it takes
attention to detail to do so.

Lisp is about the best language you'll ever find for metaprogramming.
If you're going to be working on a large project with many people,
you're better off using a language that handles OOP better than Perl's
tacked-on object model.  Ruby manages this excellently, as does
Smalltalk.  There are other reasons to use each as well, but I'm getting
tired of describing languages, so I'll keep this short.

The point is that you're probably best served for any nontrivial
programming task by choosing the right language for the job from among
Turing-equivalent/Turing-complete languages that already exist.  Each
has its own benefits in terms of enabling easier solutions for the
problems at hand, and to get some of that enabling you have to trade off
with other enabling (at least, you do if you want your language
interpreter to finish parsing code this century).

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall