19 Aug
2001
19 Aug
'01
8:33 a.m.
It was thus said that the Great "Fred Cisin (XenoSoft)" once stated:
It depends upon the nature of the problem and the system you are running
it on. I was never a big fan of recursion, simply because I never saw a
need for it---the examples given were too trivial and wasteful of resources.
A good example for recursion is parsing expressions:
expr ::= term | term + term | term - term
term ::= factor | factor * factor | factor / factor
factor ::= NUMBER | `(' expr `)'
A factor can be a number, or an expression itself in parenthesis. Makes
it easier to parse. Another area I've used it in is traversing the
filesystem doing some processing (say, looking for files owned by a
particular user and calculating the space used (`find' and `du' don't quite
cut it for this operation):
size addfiles(directory start,user id)
{
size sum = 0
for each entry in start
do
if entry is owned by id
{
if entry is file
sum += sizeof(file)
else if entry is directory
sum += addfiles(entry,id)
}
done
return sum
}
How do you avoid stack overflows? Either make sure the worse case will
fit in the memory space allocated to the stack, or have virtual memory with
overcommit 8-P
Why are pointers intrinsically non-portable? I've written C code (with
pointers) that has compiled cleanly and worked across several different
systems (MS-DOS, OS/2, AmigaOS, Unix, Windows). It's not pointers that are
intrinsically non-portable; it's assumptions like 16 bit integers and 32 bit
longs that lead to intrinsically non-portable code (and if I see stuff like
DWORD or LPTRSZ I know it's not going to be portable).
-spc (Have compiler, will program)
> The syntax is extremely simple, I think Tony would like it. A lot of
> people superficially describe it as "a lot of parantheses", and that's
true.
> There's not a lot of semicolons, three kinds of parantheses, hashes and the
> like.
I've never been a fan of LISP because of all the parenthesis, and I've
rarely, if ever, have come across LISP code that I could follow.
Then again, it could be that I'm not overly familiar with it, or I just
have a problem following other people's code 8-)
I've been told that LISP stands for Lots of Insane
Stupid Parentheses.
But could any language have punctuation more demented than C?
Perl.
OTOH, I also
thought that it (and the teacher) encouraged some very dangerous
programming techniques, such as recursivity.
Encouraged? Some of the teachers won't let their students do a program to
count to 10 WITHOUT recursion! They can't imagine doing something like
Fibonacci sequence WITHOUT using recursion. How can you do a non-trivial
program with recursion without stack overflow? NOPE. NO preparatory course, nor stated
prerequisite!
It's worse than that. The profs doing the intro course have decided on
Scheme, but the ones teaching the next course (Data Structures and
Algorithms teach that class using C. When challenged as to the
inconsistency, their response was, "well, they should already know how to
program in C before they get here." When you have a prof who writes
"puzzle code", like Alan Holub, undergrads are expected to follow stuff
like
while(*T++=*S++);
with NO formal preparation.
Well, that *is* a C idiom and if the students are expected to know C upon
arrival, then the student should know the C idioms. But my biggest
complaint about C teachers is forcing the students to learn the C precidence
table. I've been programming in C for over ten years and *I* still don't
know it (when it doubt, parenthesize it).
Now it seems
to be all about Java, though. =/
If it were to live up to its claims of portability, if it were to survive
MICROS~1's perversions of it, and if they would give me POINTERS (OK,
intrinsically non-portable),
then it could be a reasonable approach.