|
in reply to Perl as one's first programming language
I wouldn't suggest Perl as a first programming language then or now. These days, I'd suggest Ruby, though I'd also like to see Logo used in schools starting at a young age (1st or 2nd grade).
Thinking of memory management as a necessary part of learning programming is looking at the problem the wrong way. I'd call this "C Programmer's Disease", but this is apparently already taken by another evil. It's not really that abstraction, in the OO sense, is the first thing a budding programmer should learn, but that even memory management isn't low level enough. All useful languages and computing machines are themselves concrete examples of Lambda Calculus, which has nothing to say on the issue of memory management.
I'm tempted to say, therefore, that Lisp should be your first language, since the language can be easily simplified to a from that's barely more than an easily-parsable Lambda notation. However, I think you can learn a lot of the same things using Ruby, and you'll run into Ruby a lot more often in practice (no, I don't want a reply listing all the useful programs that have been written in Lisp). After balancing this factor, I give support for Ruby, though I wouldn't blame anyone for choosing 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.
|
Re^2: Perl as one's first programming language
by mr_mischief (Monsignor) on Apr 07, 2008 at 17:07 UTC
|
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.
The Lambda Calculus is very elegant and very mathematically pure. Most computers, fundamentally, are von Neumann machines. The programs they run are not always so tidy as the Lambda Calculus, and the Lambda Calculus is often quite an inefficient way to represent a solution to a problem for those machines.
Many languages map better to a DFA or an NFA than to the Lambda Calculus. Some map better to propositional calculus. Some are written for data-flow machines or to emulate data-flow machines. While it's possible to have a Turing-complete language based on any of these models which can approximate one another, it's difficult to say that one is the true model of programming.
In the future, when concurrency is even more important than it is now, languages which do not impose artificial ordering upon the operations involved will be more important. Lisp, Haskell, and similar languages will certainly be handy for that. So will Prolog, any data-flow language, and well-written distributed object systems.
All that said, most people don't want to think about parentheses and order of operations when they first start programming. They want to see how to handle simple cases of input and output. That's something Perl excels at, and Lisp (at least Common Lisp and Scheme) make kind of clunky. | [reply] |
|
|
| [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
|
|
Re^2: Perl as one's first programming language
by TGI (Parson) on Apr 07, 2008 at 17:07 UTC
|
Logo is super cool, and I cut my teeth on it. There are a number of free versions available today. NetLogo is a neat version with parrallel programming tools built in.
But Scratch is what got my daughter excited.
Logo is a bit boring in comparison to Scratch. She has programs like TuxPaint to draw pictures with ("pictures" was the killer app when I was a kid, and logo was so much better at it than BASIC). Scratch provides a media rich programming experience.
| [reply] |
|
|
