http://www.perlmonks.org?node_id=678796


in reply to Re^2: Perl as one's first programming language
in thread Perl as one's first programming language

You're displaying what many people call the "Lisp Programmer's Disease". The symptoms are noting that good mathematical representations (like prefix) are extremely important (they aren't always), that recursion is better than iteration (it isn't objectively better), and that purity of syntax is a goal instead of a tool.

I don't suggest a person stop with Lambda Calculus/Lisp, though. Just that it's such an important base for everything else that it's almost reckless for people not to start there. A generation of programmers have grown up starting with languages like BASIC, C, and Java, which have little surface similarity with Lambda notation. Certainly, these languages expand on the underlieing principles in useful and interesting ways, but it's important to know where it all starts.

I myself started with BASIC, and had no idea about any of this Lambda Calculus stuff before I was well into a career with Perl. I think that's a real shame, and I know I'm not alone in learning that way.


"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

  • Comment on Re^3: Perl as one's first programming language

Replies are listed 'Best First'.
Re^4: Perl as one's first programming language
by mr_mischief (Monsignor) on Apr 07, 2008 at 18:28 UTC
    I could make just as strong arguments that Forth (using little more than postfix notation, stacks, and a library of symbols) is the only way to start, because it balances mathematical elegance with performance and the theories that are actually behind modern mainstream hardware implementations.

    What's so great about Forth? It abstracts just what needs to be abstracted and keeps its implementation and language very close to what the hardware offers, resulting in a higher-level language with very good speed of execution and lightweight memory requirements. It is easy to move both down to assembly or up to more abstract languages. It encourages code reuse at every level, and many implementations have certain library routines that directly wrap the OS's libraries. It doesn't require explicit heap management (although it is all about the stack). It runs in very tight environments, like embedded hardware.

    At the same time, Forth ties one to a model of programming pretty tightly (although writing an interpreter or translator in Forth isn't that complicated). Lisp has that drawback, too, though. Perl does not.

      At the same time, Forth ties one to a model of programming pretty tightly (although writing an interpreter or translator in Forth isn't that complicated). Lisp has that drawback, too, though. Perl does not.

      I don't necessarily consider that a benefit for what's intended as a first language, though. On the contrary, it tends to cause a lot of confusion.

      However, I'm not convinced that binding so tightly to a single model is a benefit, either. Which is why I'd tend to suggest Ruby rather than Lisp.


      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        I think in a classroom setting or a mentoring setting the fact that a tool's more flexible than you are originally taught has little bearing on what one will learn. Learning a subset of a huge language like Ada or Java doesn't seem to be a particular drawback of those programs that use them (although I'd argue that both of those languages as a first have other drawbacks). Learning a very flexible language like Scheme or Common Lisp doesn't seem to be an issue, either.

        When one learns programming on one's own, it's much harder to say what would be a good thing. Perl (Ada, PL/I, PL/M) very well may be overwhelming due to language size. Perl, Python, and Ruby might be daunting due to the available programming models. Lisp, Rexx, Perl, and JavaScript might be intimidating because they all allow evaluation of arbitrarily complex programs from within a program. A good tutorial for new programmers would hopefully be as gentle an introduction to the syntax of the language as to the concepts involved.

        The biggest drawback one can have in an initial language, I think, is unusual verbosity. There are strictly typed languages with inference. There are languages which have a very declarative style of complex data structures without requiring the same for simple scalars. Languages exist in which input and output data must be pre-structured, and byte-oriented files are a pain with which to work. Since the first applications most people learn to use are not payroll systems and league sport box scores, forcing verbose data and variable declarations for the sake of performance and ease of language implementation are counterproductive, IMO, in a beginning language.