Re^4: Perl as one's first programming language

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.

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

Replies are listed 'Best First'.
Re^5: Perl as one's first programming language by hardburn (Abbot) on Apr 07, 2008 at 18:52 UTC
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.	[reply]
Re^6: Perl as one's first programming language by mr_mischief (Monsignor) on Apr 07, 2008 at 19:12 UTC
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.	[reply]