In all seriousness, I'd still recommend Smalltalk as a first language, if you can find a good set of tutorials that match the implementation you've downloaded (or bought). Smalltalk's advantage is that the syntax fits on the back of a business card (literally!), permits object-oriented programming for everything (in fact, forces it!), provides incredible introspection, and gives very easy access to graphical widgets in the first few hours.

For implementations, I'd start with Squeak, which has the advantage of being open source and being maintained by the people that originally came up with Smalltalk some 30 years ago. VisualWorks also has a non-commercial personal-use version that seems decent and cross-platform.

-- Randal L. Schwartz, Perl hacker

Make them pay their dues first: teach them C++.

That's child abuse.

Cheers,
KM

That's child abuse.

Ahh, but I think it falls under that oh-so-trendy category of "tough love". {grin}

-- Randal L. Schwartz, Perl hacker

• It grew out of a need to parse text -- it's built closer to the way people speak than the way machines process information.
• It's forgiving, quick to develop, and the write-compile-debug cycle is short, thanks to the interpreter/compiler.
• It's expressive and powerful, but useful even with a small subset of commands.
• It encourages good programming practices -- if you want it to.
• There's more than one way to do it.

• It's tied to Unix by some syntax and other design decisions. That's a plus, in my opinion, but unless you've learned or are learning Unix as well, some of the higher-powered features of Perl will be harder to understand.
• It's not a purely functional or object oriented language (thank goodness). That kind of flexibility might make it difficult for someone to learn a new language.
• There are few enforced disciplines. If you start strictly (pun intended), you'll probably do okay, but if you cultivate lazy habits, you'll have to unlearn them later. More bondage-oriented languages (er... the ones with strong typing and forced indentation rules :) have some initial pain in this area, but rapidly bludgeon you into submission.

Once they actually wrote a cheezy 'Hello world' and started to learn how to 'program', they dove right into it. No matter what language we use, there are still rules. If we don't follow these rules, our programs will not do what we expect them to. This has to be enforced when teaching someone how to program.

I learned 'C' as my first programming language. Yes, it made me really appreciate Perl for it's ease. One bonus for someone learning Perl first could be that C's syntax is close enough that the learning curve for C later will be pretty well cut off at the knees.

The language shouldn't matter, it's how you present the problems at hand. Of course, at some point, any serious programmer will have to learn assembly of some flavor. . .

Jeff

When I was first learning basic on an apple II (Ctrl-b got you into basic, from assembler or some other equally useless language), I had a math teacher who told me, "Pursue algebra and it will make you a better programmer, pursue programming and it will make you a better mathematician." It's true enough... How many times do you perform a simple assignment or a join/grep/split that you couldn't have done without algebra?

When you are first starting out, it's critical that you predeclare your variables and comment your work. If you don't, you don't think about what you are doing long enough to remember it. Putting into plain English what you are doing makes it clear to yourself what you have to do with a given sub or function. It's particularly useful when you start to do OO stuff where you've got to be really careful about what each class and object does.

The other idea is the thought processes. I have noticed that some people just do not understand that a computer only does what you tell it to do. How often have you heard the complaint, "My computer is possessed!" ... (ehem... except when it really was, by BO...) The point is that all the frustration with "teaching" a computer to do what you want it to do, can be avoided if you sit down and think through each step calmly realizing that each statement is telling the machine to do something in a particular way to a particular thing.

In my opinion, these are all things that can be taught before a child starts to program. If your children are old enough to begin using numbers, spend time with them drawing clock faces with one hand, ask them to count at all times, do their math homework with them, stretch them beyond what their school is willing to teach, play them in games of chess when they get old enough, make an effort to spend time with them doing intellectual work. It is an effort that you will be rewarded from as their concentration grows. First of all, it will teach concentration and attention to detail, second of all, they will remember the time that you spend with them... and it will be a positive reinforcement kind of thing. Mostly, if you show that it matters to you, they will likely make it matter to them.

"Pursue algebra and it will make you a better programmer, pursue programming and it will make you a better mathematician."

Such an awesome insight. I remember when I first started programming on a TI-994a back in 1981 . . . I didn't really understand how strongly math tied into programming.

On the flip side, I remember having a difficult time finding a pratical use for algebra and trig, my teachers just said "Learn it! You'll need it!" but never said WHY.

All I needed was someone to say - "hey kid, learn this stuff and you can make video games one day!"

All well's that end well, though, if I was good at math, I probably never would have pursued music . . .

Jeff

Well, my first language had been Commodore Basic V3.5, then I even had to downgrade to Basic V2 (CBM 64). I got me a book on assembler, too, but never really learned it. On a PC, I went on with GWBasic. This is all still in my head, and perl offered so many new horizons. A limited language tends to limit your thoughts, at least in my case. My colleage has never done any 'real programming', he is now working with Macromedia's ActionScript and had a glimpse on my perl scripts and he even understood *a little*. I guess, Perl as a first language might be a good idea. Give the people some good examples that are well documented and then let's see ...

My main winge with Perl has been the lack of GUI/graphics capability. Yes I know you can use GD and Tk and all that good stuff, it's just a rather steep learning curve for a newbie by him/herself. Tk involved learning yet another language to use it. GD was sparcely docuemnted and took me a while to pick up too. In many ways Java was a cinch for GUI programming. If you have a teacher, this may help.

So if you're using pretty pictures as a means of teaching programming skills, and kids love pretty pictures, Perl may not be your first language of choice, IMHO.

MadraghRua
yet another biologist hacking perl....

Though Perl is a wonderful and fun language, the best language to start with is assembler. No language gives you so much insight in the inner workings of a computer. Once you learn assembler the working and especially restrictions, innerworking, and limitations of other higher level languages are much easier to understand (for instance things as passing arguments by register or by stack, stack overflows, size limitions of numbers, hexadecimal number, optimizations etc). Once that is learned Perl makes an excelent 2nd language....

Have Fun, Frans.

GalaxyNG

This can be difficult to do when designing an entry-level programming class for a group of students with different backgrounds and goals, but it is not always impossible (for example, an entry level CS class is likely to use a different first programming language than a web development programming class). And, it's very important to take these things into consideration if you're trying to go it alone and teach yourself how to program- one of the most common reasons I see this fail is attrition due to lack of interest.

Different people come to programming from different backgrounds. Leveraging someone's previous experience can make it easier for them to learn how to program by either building on knowledge they already have, or by improving their attention span by keeping the experience interesting. For some people, working with a graphical system can keep things interesting. For others, working with something that "looks almost just like a unix shell" is better. And those coming from an html web-development environment would be most comfortable working with something that looks "almost just like HTML."

At the same time, what the person intends to do with their programming skills is also important. If you're teaching future Computer Scientists, it's probably more useful and important to start with formal (but less frequently used in Real Life) languages with stricter syntax, such as Lisp and Pascal. If you're teaching a system administrator how to make their life easier, through automation of common tasks, but they never really intend to move on to large-scale development projects, then you'll never get anything accomplished with LISP (okay, except maybe in Emacs). Likewise, a web developer- if all they really want to do is spice up some otherwise boring web pages, knowing that you always have to predeclare variables and functions in Pascal isn't really going to help much.

It's probably heresy in CS circles to suggest that It's Okay to leave gaps in peoples' programming knowledge, that It's Okay to cut corners in order to facilitate Getting The Job Done. Teaching a web designer PHP as their first programming language will probably leave many lessons which would later need to be unlearned if the person eventually decided to go into Computer Science. But not everyone wants or needs to be a computer scientist just to write useful programs (or, to write programs Well, within a certain domain).

With all of that in mind... "Is Perl a good first programming language?" I'd say Yes, sometimes, for some people.

One poster commented that it's too easy to shoot your foot off in Perl if you're unexperienced. I claim, it's easy to shoot your foot off in Almost All languages. Perl has the benefit that it's less likely to crash your machine and require a hard reboot to recover, when you do shoot your foot off. And because there's no explicit compilation stage, it takes less time to sew your foot back on and try again.

Alan

Personally, I don't really think that Perl is a great language to teach and learn as the first language. I've been brought up with (Turbo) Pascal, and I think that first learning strict stuff (like, predeclaring your variables, predeclaring functions, strict count of parameters, strict typing) is very important. After you've learned that stuff, you can move over to the greener pastures of dynamic type conversion etc..

"Over" in the CS departement, they are nowadays teaching (eeeek) Python, and I think that Python is maybe a good start, since it's very strict in its requirements, and available for a lot of platforms. Note that I haven't written a single line of Python yet :)

There are other "toy" languages designed specific for learning programming, something in the style of Logo, maybe with another metaphor than the turtle :).

Cheers,
KM

Perl is as good a place to start as any. If you look around, you will notice that there were two languages that were invented strictly for teaching (BASIC and Pascal) and both have had remarkable runs as real working languages over the years. Even now you see the newest BASIC (VB 6) up against the newest Pascal (Delphi 5).

The grim fact is that your first language seriously colors your later choices and mental parsing. So much so that many people are still more comfortable in a majorly bastardized version of their first language than one designed to address the needs of the task they are assigned.

If you know what type of task you will be performing I recommend you pick as a first language the one you will do most of your work in. If it has been years since you programmed, I tell people that Perl is to Basic what Java is to Pascal. Nothing LIKE it yet strangely familiar.

As to the original post's question, teach them more than one language at once. I recommend a language like Perl or old BASIC with inflected verbs and nouns (&subs vs sub() and $var vs @var vs $var3); a stricter language like Java or Python with a plainer grammar; and a radical grammar language like Scheme or Forth that makes you look at the logic of the program from a whole different angle.

There are a lot of good languages out there, make sure you give them a taste of more than one and let them find the once that fits them like an old shoe. Personally I wouldn't be half the Perl programmer I am without Lisp, x86 ASM, Forth, Basic, Pascal, C and more all floating around in there. (Lisp really helped with Perl, one week after first playing with hash arrays I yelled out, "Oh! Dot lists!" =)

--
$you = new YOU;
honk() if $you->love(perl)

Teaching Perl to First-Time Programmers

It depends entirely what you intend to do with your life. As I've said before, you can't write operating system code in Perl (barring the silly, impractical scenarios that have been previously discussed). If you want to write Windows applications, Perl is not a good language. Not so much as a language in itself, but the lack of easy interface to the underlying windows functions.

You *could* write a complete windows app using Win32::API, perhaps, but why? In addition, Windows makes use of many callback functions, and I don't know how well these really port to Perl. Implementing an event driven system in Perl would seem to be a lot more difficult, considering the operating system has certain expectations. And last time I checked (and this may have changed), you couldn't call straight back into a Perl subroutine. At least, not without writing some XS code to manage it all. Which starts to get away from the point of writing in Perl.

Perl also lacks an effective method for distributing and installing Perl as part of an application. If someone has Perl (and assuming you don't have version dependencies), you'd be OK. But since it's not something that's installed as part of the O/S, and the fact that it's nowhere as easy to install as copying a DLL file out, it makes for a painful application installation.

Also, IMHO, Tk isn't there yet. And for most Windows users, it doesn't look enough like Windows to make them happy. In fact, one of the points of Windows (and MacOS on a MacIntosh) is to give users a common user interface for applications. Now I'll be the first to admit that some people can't begin to grasp this, and certain basic functions like copying a marked text block aren't control-C in applications. But, the window frame work is basically the same, and generally speaking, the underlying user interface is pretty consistent. With Tk apps, I haven't found this to be so.

Now, if you're going to spend your life not writing OS code for Linux, and not writing Windows apps, then yes, you may never choose to learn C++. Of course, the more languages you learn, the better a programmer you become. C++ teaches methodologies that are supported but not enforced by Perl. Perl has some powerful OO capabilities, but I believe that using C++ gives you better insight into them.

Perl is an excellent langauge for many tasks. It is not the solution to every problem out there (How many AI modules do you see for Perl? 1: AI::NeuralNet::BackProp). A good programmer recognizes when to use a given language for a given solution. Not beating every problem into submission would a tool that's not appropriate to the task.

--Chris

e-mail jcwren

-It is not the solution to every problem out there (How many AI modules do 
-you see for Perl? 1: AI::NeuralNet::BackProp). A good 
-programmer recognizes when to use a given language for 
-a given solution. Not beating every problem into submission
-would a tool that's not appropriate to the task. 

The people that I learn programming stuff from replaced
LISP and Prolog with Perl.  They find it easier to use
and just "way bitchin' cool."  Inference engines work
just fine in Perl.  

--moo