Yes, a good programmer (and one working on low level) will need memory management, but nearly all modern languages (perl, all other "scripting" languages, java and all function programming languages) hide memory management from the programmer. With good reason, IMHO.

I think the more relevant question is if the programmer should first learn how to deal with static typing (like in Eiffel, Java or Haskell, or less rigorous in C/C++), or with dynamic typing.

I started with basic (which has no user defined types at all, iirc), and then learned C and Eiffel. With Eiffel I learned about the benefits and harm of static typing. I had no problem learning other statically typed languages (like java) and dyamically typed languages (mostly perl, but also scheme and a few others).

Since I can't repeat the experiment the other way round, I have to ask: Who has learned a dynamically typed language first? How hard was it for you to learn statically typed languages?

I think you should learn both, but which one first?

(As a side note I could imagine that learning perl first "spoils" you as a programmer, i.e. you never want to miss it's dwim'miness.)

(As a side note I could imagine that learning perl first "spoils" you as a programmer, i.e. you never want to miss it's dwim'miness.)

It's funny, many people in the threads linked above said that back then, too. Reminds me of the great, recent I think Perl ruined me as a programmer.

In 2002, I thought it silly. Perl is too good of a tool for the job, so start with something worse? What nonsense.

Now, though, I'm not so sure. When I learned photography, I learned with an ancient 35mm Pentax, developing my own film and printing my own prints. It was a gigantic pain! My workflow was hours longer than it is today with digital. Sometimes I'd spend a day on some rolls of film and get nothing out of it.

But, comparing myself with other amateurs who have been digital exclusive, I think I picked up many virtues. I no longer have to buy film, but I'm still careful about the composition of every single shot. I grew up without Photoshop, so I don't take shots I intend to fix later, I take the right shot now. Etc. etc.

My comparison, did my own programming become more robust because I started out with a "pain in the rear" language? Today, I think so. The real question is whether or not it was worth the aggravation, though, and I don't have an answer for that. I'm better today for my experience, but what if it turned me off of programming entirely?

---

On the subject of types, I do not recall which Perl-related slideshow I was watching, but one of the slides said something like:

I want static typing!
No, you don't. Remember the hell that was atoi()?

I'm sort of undecided on the issue at the moment, but the annoyance that slide made me remember tips the scale in the direction of dynamically typed languages.

I'm reminded of those who said that photography itself would destroy or devalue painting, or of those who said that the phonograph would destroy live music.

There is only so much you can do with a digital camera, just as there's only so much you can do with a 35mm SLR vs. a treated copper plate in a 200mm box camera.

There is also only so much one can wring out of Lisp, Perl, Ruby, Python, Smalltalk, ML or the other languages people say have spoiled them. Yet these tools are very useful for those looking to work quickly inside those limitations. Those who know assembly for an architecture (or who can customize the microcode for it) will always have certain advantages bought by taking on certain disadvantages.

I'm not sure which slideshow the above was in, but MJD has an excelent slideshow on type systems. He argues that the problem isn't really type systems in general, but the fact that C has perpetuated a broken type system, and that languages exist that do it much, much better.

---

"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'm not sure whether static vs. dynamic makes as much difference as with and without side effects.

There are many dynamically typed languages out there, and lots of projects are actually implemented in them.

When I query my memory for side effect free languages only Haskell comes up. I'm not too deep in the function programming community, so there could be a lot more, actually. But nevertheless I think that the existing code base and current usage is heavily dominated by languages that allow side effects.

So the question with or without side effects is currently more an academic one. It might be the next big question tomorrow, but IMHO it's not yet today.

public static void main doesn't mean anything to a beginner. It is a mysterious black box that makes people feel...

intimidated?

I think this, and your identification of Perl as a language in which a beginner may face somewhat less intimidating introductory challenges is an excellent argument for "Perl first."

OTOH, the challenges of memory management -- while valid and important for the CS student; future system architect; and such-like -- are NOT, IMO, fundamental to the objectives for which some (or many?) seek to become programmers.

While that distinction may seem inappropriate to the CS-minded academic (or may be reason to consider restructuring curricula to separate the 'wanna-be 'mere programmer' from the CS-complete "computer scientist"), it might mean that, for example, the candidate for an advanced degree in Library Science or physics or whatever, would find "learning to program" a challenge within reach.

I actually think it's very useful to think in different levels of abstraction for different problems. I also think it's good to abstract the code in a way that helps the problem domain at hand.

When doing list processing or handling code as data, Lisp offers both a good level and a good model of abstraction. When handling storing and retrieving large datasets according to basic rules, SQL is a good interface to an RDBMS. Representing the nesting and the relations of data between one part of a collection of data and another, XML, Lisp, Perl's data structures, and JSON are all pretty good.

When the problem domain is interfacing to the hardware more compactly or more specifically to a particular machine's strengths, then that's where assembly languages (and such) shine. It's rare, though, that assembly models the problem of the overall application very well.

That's why there's always the advice thrown about to write in a higher-level language that lets you rewrite portions in a lower-level language later. A person who knows Lisp, Perl, C, C++, Forth, or any number of other higher-level languages and who can handle the overall problem can code a working solution. Then, a person who knows C, Forth, or assembly can tune the critical sections. This can be one person at different times, or it can be two people.

It probably shouldn't be one person trying to solve both problems at once. That messes up both levels of abstraction. The assembly programmer's probably going to pay attention to microoptimizations and miss the algorithmic win. The higher-level programmer's probably not going to care until tests pass how fast that inner loop is.

The wisdom is often, I think attributable to Kernighan and Pike, worded similarly to: Make it work. Make it right. Make it fast.

There's simply no reason to think of a huge system in tiny little pieces. People have enough trouble picking the right class or subroutine lines to draw, let alone trying to get a 300kloc C++ project written an op at a time. If we can break things down on multiple levels and stop breaking down the parts that are sufficiently decomposed, then we can worry about performance on an easily isolated portion of a project. That helps not just the ratio of runtime improvement to time spent programming it, but also the encapsulation of the problem's parts along the lines set by the higher-level language of your choice.

Agree with everything you've added, mr mischief. In fact, the ability to move from one level of abstraction to another is sorely lacking in today's world. Schools do not teach kids to think of associations and context, and so they're crippled when it comes to analyzing a situation or problem.

There are some efforts to teach kids about patterns and sets, but they're so limited. The vast majority of 'education' is rote skill practice and regurgitation, and that's leaving our kids stuck in the muck.

Don Wilde
"There's more than one level to any answer."

I don't think I'd recommend Perl as a first language to anyone.

I'm almost convinced by the "say 'Hello world!'" argument, but I think that Perl has too many weird pitfalls for beginners. It makes Lisp and Scheme a lot more appealing, because the beginner learns a simple syntax in a short time, and that's all there is.

Perl as a first language might be best for someone who just wants to get a job done and has no aspirations to be a professional programmer. Such a user might be better off learning only Perl than learning something easier (and less powerful) before moving on to Perl. That is, it's hard to justify wasting time on HappyFunLanguage when you're going to need to learn something like Perl later anyway.

Someone on the path of a professional programmer should learn other languages first in order to learn the various paradigms that Perl supports without mandating (object orientation, functional programming, etc.). This way they can get used to staying inside certain boundaries even when they no longer have them. For example, I think it's good to learn to live with strong encapsulation before one comes to Perl and finds object systems that mostly don't enforce it.

(!= (s(i(m)(p))(l(e)))((e(a s)y)))

Programs are complex beasts no matter what you use to express them so the simpler do you make one thing, the more complex ends up some other. In this particular case you end up with Lots of Irritating Silly Parenthesis. And searching for that one misplaced character out of thousands exactly the same characters can be very frustrating.

Jenda


Support Denmark! Defend the free world!

Programs are complex beasts no matter what you use to express them so the simpler do you make one thing, the more complex ends up some other.

I don't buy that. I think that Perl makes a lot of things much simpler than they would be in, let's say, C. Memory management, for example. There isn't a complexity debt to be paid. It's not zero sum.

What I meant by "Perl has too many weird pitfalls for beginners" is not obfuscation but rather things that look good to a beginner but aren't. Examples:

$x = ~ /regex/;
%hash = map { "\L$_", 1 } @array;
[download]

If the poor beginner hasn't learned to Use strict and warnings,

$hash1 = { a => 1 };
$hash1{b} = 2;
# $hash1{a} == 1, right?  No?
[download]

I don't think the degree to which a language can be obfuscated should be a concern for beginners. A beginner reads code only from a text book that doesn't obfuscate or from their own programs which they also haven't obfuscated. The problem with Perl for a beginner is that it's possible to write code that looks as if it should work but doesn't because of some obscure historical reason or very common misunderstanding.

I saw something like this not too long ago:

foreach (@foo_list) {
    my $x = "blah $_ blah";
    my $foo = $_;
    while ( something() ) {
        # more stuff
        foreach (@bar_list) {
            other( $_ );
        }
    }
    more_with( $foo );
}
[download]

I wonder how long the programmer had to debug to figure out that $_ at the end of the loop had changed, and it ought to be saved in $foo. To you and me, "foreach my $foo (@foo_list)" is obvious, but we learned the lessons of $_ a long time ago.

See also perltrap. (We have a whole section of the documentation for "traps for the unwary"!)

It makes Lisp and Scheme a lot more appealing, because the beginner learns a simple syntax in a short time, and that's all there is.

In my experience, people who think Lisp syntax is "simple" are either wizened gurus so lambda-hardened that they even speak in prefix notation, or have never actually tried to use Lisp.

Contrary to popular myth, Lisp has quite a lot of syntax. It just all looks the same. Sorry, but I don't know how anyone can think that

(defun foo (x y z) (bar (+ x y z)))

is easier for a beginner than e.g.

int foo(int x, int y, int z) {
    return bar(x + y + z);
}
[download]

just because it uses exclusively parentheses and spaces, instead of distinguishing between different concepts by using different characters. You still have to remember where you're supposed to put the parentheses, and because it all looks the same, it's less obvious when you get it wrong. (Remember that we're talking about beginners here.)

And that's without getting into the bits of Lisp syntax that don't use exclusively parentheses and spaces. Quick, should it be (list 'foo 'bar) or '(list 'foo 'bar), or maybe even `(*list* 'foo 'bar)? Hmm, maybe it should have been ,@(list `foo `bar), or do I mean #A(:list #'foo #'bar)...? Sure, it's obvious to anyone who knows Lisp that most of those examples are nonsensical, but to a beginner it's, well, a bunch of confusing syntax. You know... that thing that Lisp allegedly doesn't have.

Most of the replies so far seem to be focusing on end point application of the learning process mediated by one of: static/dynamic typing, abstraction level or mathematical purity of the language's syntax. To a large degree none of these are important. Consider what needs to be taught to get someone started in programming:

• mechanics of getting a program written and running
• simple output
• debugging
• program flow
• program flow control
• storing and manipulating data
• simple input

Before the student can do anything else she has to be able to enter a program (I'm not talking about one liners or evaluating expressions here btw) and have it do something that he can see. That involves writing some "code" and "running" it. Very often it also involves figuring out why it didn't do what was expected - "debugging". So far all that has been described is what is required for a "Hello world" program, and very important it is too!

Once the student gets anything at all running the teaching/learning process tends to head off in myriad directions. But the fundamental skills learned in the next stage involve understanding and managing program flow along with some understanding of storing and manipulating data. One can go a long way in acquiring those skills before one needs to know anything about getting data into the program!

So what's important for teaching programming? Well, to a degree it's the tools you use. Running from a command line and switching between that and an editor gets in the way of teaching rather. Using an editor with a "command" window or an IDE that can run the code you are looking at helps. Being able to step through the code a line at a time and inspect the contents of variables easily helps a lot. Actually teaching programming is more about teaching debugging than writing code in the initial phases!

Minimizing the amount of extraneous cruft is important too. Less cruft means tighter focus and a less steep learning curve. It doesn't matter how rich a language is here - just how much required cruft there is (Perl has almost no required cruft). Cruft can take many forms - syntactic cruft is obvious, less obvious are paradigms that don't map on to the student's current experience - Forth with it's stack and dictionary paradigms is not a good teaching language, Lisp with it's list paradigm ain't so good either.

A good teaching language for programming is one that provides program flow control in ways that can easily be mapped to student's current knowledge and has suitable tools available for program generation, execution and debugging. It also provides basic I/O in a simple fashion and doesn't need extra cruft in the form of required syntactic sugar or an interesting programing paradigm to get basic stuff done. Perl seems to fill the bill pretty well.

There are some really great replies here...in fact, IMHO they are all great and very thought-provoking.

They all made me harken back to my first programming experience...during the summer of my junior year in High School learning to program in Fortran on a batch system where we had to learn to use a punch-card machine and had to wait 3 days for our submitted jobs to get turned back to us.

I graduated to Basic when I went to Dartmouth for undergraduate study and was taught by John Kemeny who had just become dean of the college but still taught introduction to programming. It really is what turned me towards programming...not because it was a great language, but because it was easy to learn and...more importantly...I could run it on a time-shared system from a teletypewriter terminal instead of on punched cards and get almost instant feedback on typographical errors, structural errors in the logic, and the actual results of the program's excution.

But looking back on the experience, I realized that the single most important thing about learning to program was learning how to think about problems...about how to decompose the problem, how to see the flow of the solution and how to translate that into very precise actions. The computer alwasy did exactly what I told it...when something didn't turn out right, it was because I didn't correctly tell the computer how to accomplish the task.

Irrespective of whether Basic was a good or useful language...it was simple enough that I could focus on the problem rather than get all hung up on complicated or confusing syntax, or on the frustrating construction of things like FORMAT statements in Fortran. I could focus on the critical thinking, on structuring the problem, on learning to program.

Looking back on my first programming language...Fortran...I realize that it, too, started to get me there...but it took too much effort to get through the technicalities of 'format' statements, of making sure that everything started in column 7...except certain directives and, of course, the ever popular format numbering and continuation lines...that I lost the "forest for the trees". The syntax and language demands were too distracting (especially when we were also learning how to use the punch-card machine and waiting 3 days to get our job back only to find out that I'd hit the f-key rather than the d-key in a do-loop so that my fo-loop didn't compile...argh!).

As a first language, I think I would tend to steer away from Perl...well, at least away from "full Perl" (see next paragraph)...not because it is too difficult or not because the padawans wouldn't be well served by it...but because it SO flexible that grappling with it distracts too much from what, IMHO is the nexus of that initial experience in programming...learning to formulate your problems in ways that can be solved (or helped) by programming a computer.

I recently read the book Minimal Perl and found it to be really attractive as a candidate 'first language'...it hides so much of the depth and complexity yet still provides an excellent foundation for moving into that complexity if it is needed. It reminded me of what I liked about Basic...simple to learn, easy to experiment with, and it provides all the functionality that any beginning programmer needs...yet could allow the padawan to focus on learning to Think like a programmer rather than on any more complexity than is absolutely essential to allow that learning. I don't necessarily think Perl is unique in this regard; but my experience with C, C++, Java, Lisp, COBOL, Ada, and others is that they, much like Fortran was for me, have too much syntactic and structural baggage that detracts from what, to me, is that important "first step" in programming.

Of course, with all the power and strength of OO-programming (a concept that I am still trying mightly to "get my arms around"...having grown up with and immersed in the procedural programming paradigm)...is an important consideration and is a way of thinking and structuring problems. I think that deserves consideration for a "first contact" with programming, too. And the great thing about Perl is that, with a different "minimal Perl", that paradigm could also be easily developed and learned by beginners. In fact, that's exactly how I'm teaching myself the basics of OO-programming...for me Perl is a much easier learning-ground than Java (which is what I first tried to use to learn about OO-programing).

So I guess I've talked myself into believing that Perl (at least with some variation on "minimal Perl") is and ideal first 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.

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.

You're displaying what many people call the "Lisp Programmer's Disease" (where) recursion is better than iteration

I had a C.S. professor who wanted the class to implement a Lisp interpreter as an exercise; I assume he hoped most people lwould implement Lisp in Lisp. I did it in Fortran.

His head almost exploded when I told him what I had done... 8-)

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.

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.


TGI says moo

I think that the most important attribute of someones first programming language is that it sparks their interest and holds it--not bore them to death with CS theory nor machine level arcania.

For me, BASIC(+) was my starting place, and despite all the critisism that can be levelled against it, it was simple to learn, productive to use, and easily to learn the basics(sic) of.

Once someone has gained an interest, has had their spark ignite so to speak, there is plenty of time for them to be damped down with CS formality. But unless that spark is lit, there's nothing to dampen.

I think Perl has what it takes to ignite the spark.

I wish my second langauge had been Q though, and I think it would be interesting to see the programmer that would result from someone starting with that.

Perl features that make Perl a good first language:

• marking of variables with symbols (% @ $)
• automatic garbage collection
• simple set of types -- only array, hash, and scalar
• expressive syntax (well, generally)
• availability of modules via CPAN

Perl features that make Perl a poor first language:

• strict and warnings are off by default
• "tacked on" object support
• confusing "config" variable names (e.g. $/)

Of course, good instruction can take care of all the negatives.

Personally, as much as its blasphemy here, I think Python is one of the best languages for learning about programming -- that's a good bit of what it was designed for, after all. That said, though, one could certainly do much worse than Perl.

And don't get me started on introducing programming by using Java -- I think that idea is perpetuated by instructors that want to keep people out of the field.

My CS101, looking over the packed room on the first day, told us all sorts of things about CS. That most would end up dropping out, that many people in the room would be happier in another major, very hard work, the major doesn't even have room for an incoming class this size, etc. etc.

One man left.

After two weeks of trying to absorb the fundamentals of programming via Java, though, we lost 15-20 people. I'm thinking he could have skipped the speech and gone right to the Java, more bang for his buck! :)

Seriously, though, I'm sure there were several amongst those who left who would have done fine and been happy, but were intimidated by Java. It has few virtues as a learning language.

Well I actually wasn't able to really grasp object orientation until I tried the very basic, "guts out" OO Perl. I didn't get it with Java, C++ or TurboPascal, but Perl shows you the inner machinery and that seems a pretty good thing for a teaching tool.

By that I mean, different people need to learn different skill sets. I'd point a statistician towards SPSS. A Civil Engineer might be better served by Fortran with a good math library. A compiler-writer might prefer C with a YACC library.

In 1973, everyone at my college (Chemists, Physicists, mathematicians, and engineers of all stripes) learned Fortran-4 as a freshman. I don't know if I'd recommend a 'one language fits all' mindset today.

Back in 1973, if you needed complex numbers and didn't want to implement them yourself, Fortran was pretty much the only game in town. These days any language with a decent Object system has a Complex Number implementation.




On another subject, given all the great Statistical tools/languages out there, why SPSS? Most recent version changes have broken working code in a dramatic and undocumented ways for no known benefit. Licensing has always been a nightmare and has gotten worse over the last 3 years. It's as bad as most business software was in the mid 80s.

Unfortunately, most of the SPSS users I've met are unwilling to learn another tool.

If you have someone who is not yet hooked on SPSS, don't do them the disservice of pointing them that way.

Your points are well made. I cited the examples I did because
• I'm a dinosaur, and mentioned territory from my past (I partially paid for Sophmore year by writing and consulting SPSS)
• there was a point (when memory and disk were expensive) that Fortran-77 had an incredibly optomized floating-point library. I realize hadware limitations are seldom a primary concern these days.
In the real world, I would never suggest a first language for someone to learn. When my son was in high school (10 years ago) classes in C++ were offered; the high school my wife teaches in offers classes in Java. Anyone interested in learning a language has more opporunities available to them than talking to me. 8-)

Having said that, I still don't know if there's a "one size fits all" first language, short of Logo in grade school.

How about you? What are your experiences? What would you recommend?

Starting on Scheme makes a lot of sense to me - I wish that's how I'd started, really. The interactive prompt is a great fit for learning along with a book and there's some great beginner materials out there for Scheme. The one downside is that for most working programmers Scheme is going to be essentially useless.

Starting with C, which is what I did, also has some strong points. Like Scheme it's a little langauge - K&R covers everything you need to know in around 200 pages. Better yet there's just so much C code around to learn from - pretty much everything that a computer can do has been programmed in C. And it's really useful in that we all work on C-based systems (like Perl and Linux, say) every day. Knowing how to read and patch them is a great tool, even if your every-day work happens at a higher level.

-sam

The size of the language is not relevant to the novice (or initiate). What matters is how much you need to know to start producing a functioning program, and how easy it is to incrementally learn more features. Perl is perfect on that count. PL/I and C++, on the other hand, are famous for producing astonishing diagnostics.

Having a minimum amount of red-tape to get a "Hello World" program running is probably the most important thing for a fist language—especially to self-taught programmers. Perl is as good as it gets on that point.

I don't think Perl should be the only language known or used by a professional programmer, but it's the best choice for non-programmers, because you can know as little or do as much as you could possibly want.

For training a professional programmer, it's still the best choice. It allows you to start working on programming, rather than housekeeping, red tape, and such. That can be taught later, with C, and assembly. OO programming should come later. And I still believe in C++, but maybe Java will do. Maybe Perl 6 will do.

sas

I think you're overestimating how hard it is to write "hello world" in C. If I had my K&R around I'd quote a page number by which a student would be ready, I bet it's pretty low.

And for Scheme, well, you just don't have a case. It can't possibly be easier to write a "hello world" than in scheme! You just fire up your interpreter and:

   guile> "Hello world."
   "Hello world."
[download]

Scheme is not only a bazillion times smaller than Perl, it's also faster to get started in, with less syntax and house-keeping to learn.

Ok, you've convinced me, Scheme is the perfect first language. Now if only I could go back in time and get started right...

-sam

I rather think that “you gotta start somewhere, so pick one.” You need to get three or four languages under your belt as quickly as possible so that you begin to have a solid basis of comparison between them.

It is reasonable to choose a “kind and gentle” language ... one that takes care of its own garbage collection and reference-handling, so that you're not whamming your head against hard-to-debug mechanical issues at a point when you're still trying to wrap your mental machinery around algorithm-design.