Curricula (was: Assembly vs. Everything Else

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Sun Aug 19 15:33:13 2001

It was thus said that the Great "Fred Cisin (XenoSoft)" once stated:
>
> > 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?

  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

> 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.

  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)
Received on Sun Aug 19 2001 - 15:33:13 BST