in reply to Beginning Programming with Perl

Short version: Perl is too helpful to make a good intro language for career programmers. (Then again, so is pretty much any other language, from Java to Lisp.) Start with a sane assembly language, move to C, go from there.

Longer version: Re: Learning Perl as a First (programming) language

(Lest you think I'm some sort of Real Programmer type, or even a C evangelist, I try to avoid C for most purposes, and I think you should, too. Perl is usually good enough, and if it isn't, Lisp is usually better. I've applied too many patches and read too many BUGTRAQ advisories to advocate C for general systems programming. That said, sometimes you need low level system access, blazing speed, or both, and sometimes the only language bindings you have are to C... and if you haven't learned from the start to check buffer lengths and malloc's return values, well, I'll probably be reading about your software on BUGTRAQ.)

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

Replies are listed 'Best First'.
Re: Re: Beginning Programming with Perl
by Adam Kensai (Sexton) on Aug 20, 2002 at 16:42 UTC
    Not to go too far aside but in the Physics ciriculum we teach the new students things that are utterly false, and we do so for a reason. We start with Newtonian physics, we tell them all sorts of things, we even give them a formula for the work done by kinetic friction that is so wrong as to be silly, but why? Because we take whats correct and simplify it so that the student can see the forest through the trees. If a new student was mired adding things like relativistic effects to their problems they would entirely miss the point of starting out in the program, not learning physics but learning how to do physics.

    I think that C and Java give you enough rope to hang yourself with in this department. There is enough that has to be thought about and enough that has to be done a certain way that (in my experience) students don't spend enough time learning how to program well. It's my opinion that the above that you noted can be learned after the basics with no ill consequences. With a proper helping hand in learning the basics, nothing will have to be unlearned from developing bad habits either.

    I feel a need, with plaintext being so poor at expressing the emotions of the writer compared to conversation, to explicitly note that there is no malice in the above and I am very thankful for your opinions. ~Adam
        There is enough that has to be thought about and enough that has to be done a certain way that (in my experience) students don't spend enough time learning how to program well.

      Actually, this is one reason why I suggest starting with a sane assembly language, probably in a simulated environment. (My university's using spim for this purpose, although the intro assembly course is well into the comp.sci. curriculum.) The scope of the programs, especially the first programs, are so limited that the students don't have the opportunity to get overwhelmed with detail, so they're free to concentrate on the basics of what they're doing.

      Further, programming in assembly gets out of hand so quickly (if you let it) that some good programming practices, like descriptive names (for labels and such), subroutines, even stuff like unit tests are actually emphasized, rather than ignored. I've never seen an introductory programming course taught in assembly, but I imagine it could be very successful at teaching basic programming practices.

        It's my opinion that the above that you noted can be learned after the basics with no ill consequences. With a proper helping hand in learning the basics, nothing will have to be unlearned from developing bad habits either.

      In my experience, students who have learned to program in "helpful" languages have a difficult time taking over the chores of memory management, bounds checking, and so on when they switch to a lower-level language like C or assembly, because the languages (and, usually, the instruction) hide the workings of the computer to the degree that students aren't prepared (or inclined) to think of memory as a finite resource that must be explicitly allocated and freed, or pointers as things that can point to unexpected places, or strings as having finite length, etc. Sure, this sort of careful programming (really, the issue at hand is resource management) can be learned after the basics, but it often isn't. There is a lot of ground to cover in a standard comp.sci. curriculum beyond the basics without including extra material on basic software engineering.

        I feel a need, with plaintext being so poor at expressing the emotions of the writer compared to conversation, to explicitly note that there is no malice in the above and I am very thankful for your opinions.

      No worries. :-)

      --
      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      The hell with paco, vote for Erudil!