Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Good language to teach beginners?

By chipuni in Technology
Thu Sep 06, 2001 at 04:15:37 AM EST
Tags: Help! (Ask Kuro5hin) (all tags)
Help! (Ask Kuro5hin)

In a chat-zone that I'm part of, the following classic question came up:

[unixgeeks] Sabachka says, "Hey all ... what is a good language to teach someone to allow them to learn a language and what a programming language is about and how it works?"


The question is serious, and it needs to be revisited every so often. Although Pascal was designed as a teaching language, it was invented in the early 1970s, and programming has shifted greatly since.

In my opinion, the languages that programmers use daily make for poor first languages. The features that give power also create confusion. On the other hand, a language with too few features might not teach enough about programming.

What language do you recommend that lets people with no background quickly get going, learn more when they want more, and allow them to shift over to a real language when they're ready for it?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
What language do you recommend?
o Visual Basic 7%
o Python 29%
o Java 12%
o C or C++ 13%
o Scheme, Lisp, or ML 11%
o Pascal / Delphi 13%
o Perl 8%
o The Shakespeare Programming Language 3%

Votes: 147
Results | Other Polls

Related Links
o Also by chipuni


Display: Sort:
Good language to teach beginners? | 125 comments (124 topical, 1 editorial, 0 hidden)
Scheme, Lisp or Java. (4.08 / 12) (#1)
by la princesa on Wed Sep 05, 2001 at 08:31:31 PM EST

Hell, even Smalltalk would be a pretty decent one as an intro. Alternatively, some form of assembler. Either give a kid something pretty low level or give them something pretty abstracted out to work with as a first language. Although some might disagree with me on this, I would also recommend the alternate approach of teaching introductory formal logic (the kind with the funky symbols philosophers use.) To me, ideally programming should begin in a perspective that embraces general principles of logic and applies them practically to the problems one is given in work or school or for fun. And there are several ways to get across that applied logic ideal, some of which don't even require one to start out learning a programming language at all.

Pascal (4.00 / 5) (#2)
by BigZaphod on Wed Sep 05, 2001 at 08:31:50 PM EST

I still think Pascal is one of the better starting languages. It has most of the features of the popular languages (such as C) but it isn't quite as different as Python/Perl.

IMHO, Perl would be an especially bad starting language because it teaches nothing about how the computer itself works inside and wouldn't really get a beginner ready for something like C++. Of course this is a rather interesting debate in my mind because I happen to think it is time we break some of the bonds of the currently popular languages and try something new. Sigh. Catch-22, really.

"We're all patients, there are no doctors, our meds ran out a long time ago and nobody loves us." - skyknight
Pascal scared me off coding for years. (3.25 / 4) (#4)
by la princesa on Wed Sep 05, 2001 at 08:36:11 PM EST

The whole idea of programming in general didn't even make any sense to me until I discovered Scheme and Lisp and Java. I agree with you that Perl is useless as a first language. It's too pasted together and just teaches bad habits to beginners. But it is tolerable as a secondary language.

[ Parent ]
In what way? (3.50 / 2) (#5)
by BigZaphod on Wed Sep 05, 2001 at 08:41:40 PM EST

What scared you off with Pascal? I'm just curious because I really caught the programming bug when I finally got to know Pascal (I had started with BASIC on Apple IIs and Commodores).

I'm interested in this because I've been playing with some new programming concepts and I'm trying to find out everything I can about how people perceive programming.

"We're all patients, there are no doctors, our meds ran out a long time ago and nobody loves us." - skyknight
[ Parent ]
It never worked. (3.00 / 1) (#9)
by la princesa on Wed Sep 05, 2001 at 09:07:04 PM EST

Nothing I wrote ever ran. I even copied code from other students exactly and it ran for them, but never for me. None of it made any sense, which made the not-running part even more depressing. Oddly, once I got a look at some other languages (x86 assembler, scheme, lisp, java), I was able to get a better feel for what they were doing to run a given program. At this point I just have a mental block against pascal and will likely never go near it again. I just think personality-wise I would have been better off with an intro language that was more abstract. Without an idea of the underlying logic, I just get kind of lost. I have to see it at the AND/OR level almost or at the abstract, englished-up logic level to understand a language presently. But I am also still new to programming, so maybe in a few more months I'll be comfortable with languages like C and non-OO perl.

[ Parent ]
If you can't get this to work... (5.00 / 2) (#20)
by sopwath on Wed Sep 05, 2001 at 10:22:29 PM EST

You should check out something called Karel the robot. Yeah it sounds lame, but it's based on pascal and teaches good program design as opposed to specifics of a certain language.

There are only 5 instructions and 4 primitives so there's nothing useful you can do, but it's good for learning proper structure and it helped me figure out loops finally. For what ever reason, I had a hard time with them in QBasic, but I got it with Karel. I'm getting into C again, I took some classes in high school, so I think that something simple might be what you need. It's so easy that you literally have to be retarded to not get it. You can learn the basics in a couple hours (or 1 if you read fast) but some puzzels in a book called "Karel the robot: A gentle introduction to the art of programming" by Richard E. Pattis really make you think when you need to make certain looping structures.

You just tell Karel (the robot) where and how to move around his little world, (there's more, but that's the gist of it) it's fun but not frustrating.



good luck,
sopwath
Graduation, Sleep, Life: Pick Two
[ Parent ]
better late than never, but... (1.00 / 1) (#116)
by Justinfinity on Mon Sep 10, 2001 at 10:51:51 PM EST

a language CAN NOT teach bad habits. Perl has the shortcuts available to make programming easier. if your teacher teachs you the shortcuts _before_ you know what they do, that's his fault, not Perl's.

do() unless $i_am_true;


if (i_am_true != true) {
do();
}

a bit less typing. multiply that times 10000 lines and you've just saved 50000 characters or so worth of typing.

[ Parent ]
doesn't teach you anything? (2.50 / 4) (#24)
by Justinfinity on Wed Sep 05, 2001 at 10:44:03 PM EST

#!/usr/bin/perl -w

# allocate some space in memory and put the given data into it
my $string = "hello kitty!";
# get the address of said memory location and store it elsewhere
my $reference = \$string;

# dereference (look at the data pointed to, not the pointer itself) and print it
print "$$reference\n";
# print the reference without dereferencing it, see the memory location
print "$reference\n";

-Justin
Why don't you listen to me? If you listen, you get some of that clean, refreshing, new world Parent ]

What about Ada? (4.00 / 1) (#32)
by fernand0 on Thu Sep 06, 2001 at 02:55:19 AM EST

Well, in fact, an adequate subset of Ada. It is very similar to Pascal but (imho) more regular (remember all the problems teaching students when to/not to put begin end, ;, etc ...). Moreover, it is a very complete language: you can add more features if the students get interested without need to switch to another language (the standard of Pascal is very limited). It has a good free compiler (gnat) with support for a great variety of platforms, and it is really portable.

[ Parent ]
very complete (4.00 / 1) (#51)
by wiredog on Thu Sep 06, 2001 at 08:27:07 AM EST

That's its problem. It's very complete. Ada was designed by a government committee that put everything in there. At one time Ada was mandated for all DoD programming. DoD discovered that they couldn't mandate that because, given the choice between a guaranteed income on government contracts using Ada and taking their chances in the Real World with C, many contractors chose the Real World.

As you said, an "adequate subset" might be good for teaching, but the same applies to C++. I use C++ every day, but have been learning Python and am looking at Java. C++ is great for systems programming, and anyplace where sheer raw performance is a must. This makes it difficult to use. Java suffers from the same "too many damn libraries to learn" problem as C++.

The idea of a global village is wrong, it's more like a gazillion pub bars.
Phage
[ Parent ]

you don't have to use it all... (none / 0) (#69)
by Just Me on Thu Sep 06, 2001 at 04:53:35 PM EST

... but it's there if you need it.

Ada is complete, and contains more than C++, but that doesn't mean you have to use every single construct it provides in your program. For example, you don't have to know/teach about tasking, if you never use it. Same for other features. You can program in Ada about as easily, as in Pascal, but if you later want any advanced features, you don't have to learn a new language.

Ada is also better than a subset of C++, since it is more readable, compilers catch more errors, there are run-time checks for errors the compiler can't detect at compile-time. Ada is also more portable than C++. All this can be beneficial to newbies.

(Disclaimer: I have never taught any programming to anybody).



[ Parent ]
The exception handling (none / 0) (#74)
by wiredog on Thu Sep 06, 2001 at 06:39:42 PM EST

in Ada is highly regarded, I think it was stolen and, after the serial numbers were filed off, stuck in C++.

The idea of a global village is wrong, it's more like a gazillion pub bars.
Phage
[ Parent ]

Prolog ... (3.71 / 7) (#3)
by iwnbap on Wed Sep 05, 2001 at 08:32:22 PM EST

... and no I'm not trolling. The reason beng that it's a good language for teaching low level design skills - it's one of the few languages where you cannot just write large gobs of code and pray that it does something.

The other benefit it that it has a somewhat non-prcdural flavor to it, and helps inculcate the idea that we're specifying what the machine should achive, rather than what it should do.

The other advantage is that you can do almost anything with a very small number of primitives. There aren't 10 different looping constructs to teach, there's simply standard rules, "is" and "cut" (the last you can get away with leaving for a little while); it's how you put it together which makes it powerful.

Unfortunately it don't do so well for the last criterion: and allow them to shift over to a real language when they're ready for it for which something like Python might be a better choice.

On Prolog and large gobs (4.50 / 2) (#17)
by Pac on Wed Sep 05, 2001 at 10:08:08 PM EST

Yes, but then again you can mostly write large gobs of rules and pray it deduce something...

I like Prolog, but I would really be amazed if it could be used as an introductory language. Too many wierd concepts, too many advanced techniques. And when I first learned it, the available systems could not even deal with graphics (not true after Turbo Pascal, and I hope not true nowadays).

I think it is important for a learner to have some sort of feedback all the time. That is part of the philosophy behind the 60's invented Logo language, a pretty advanced language for its time. Prolog, on the other hand, will have you making a trip to Logic and Deductive Systems way before someone can make it write "Hello, World!" to stdout.


Evolution doesn't take prisoners


[ Parent ]
ColoBot (3.66 / 3) (#6)
by Smiling Dragon on Wed Sep 05, 2001 at 08:55:45 PM EST

ColoBot is a game made by an outfit called EPSITEC (It's a new one on me) where the player controls a little guy exploring alien planets.

The neat bit is the way you control your robots, you either control them directly one by one or write programs to drive them.

The programming language it uses is pretty c-like (aren't they all these days?) and suprisingly powerful for an in-game language. If you want a good way to teach coding while keeping it interesting to the ones that can't see the beauty in a cunning hack of perl (<grin>) then this would be a good start. The other plus is that it wouldn't be too hard to change to other procedural OO language from it.



-- Sometimes understanding is the booby prize - Neal Stephenson
Aren't they, indeed (3.14 / 7) (#12)
by localroger on Wed Sep 05, 2001 at 09:33:06 PM EST

The programming language it uses is pretty c-like (aren't they all these days?)

Yes, and the very thought of a C-like language (including C) drives me bugfuck because it is such a fscking kludge and has corrupted the whole direction of programming language development in the last 15 years or so.

C sucks. C++ sucks double turds. C was designed to be a massively efficient, bare-bones, incredibly fast language suitable for writing operating systems -- "portable assembly language." Which, of course, it fails at, since even a moronic human can write better .asm than a computer (latest generation of processors possibly providing the first ever exception, though I have my doubts).

C++ was an even bigger kludge on top of this kludge, to add a layer of "object orientation" with all kinds of restrictions on the new data structures it introduced (except that all of them can be bypassed, and have to be occasionally if you want to write real code).

C is unreadable. C bears no relationship to the interior hardware. Whoever first had the bonehead idea of making the program a "stream of characters" rather than a list of commands should, if there is any justice in the world, be tied to an anthill right now. This idiotic idea has now infected the whole arena of language development.

For reference, friends & neighbors, the computer does not process CHARACTERS. It processes INSTRUCTIONS. The most natural way to relate what is going on inside to what you want to do is to build BIGGER INSTRUCTIONS. Which, if you have any sense of order, you will put on SEPARATE LINES.

Which, of course, any good C programmer does, since he wants his stream of gibberish to be readable 6 months later. But he doesn't have to. Why is this? Because some TOTAL IDIOT had a COMPLETELY FLAMING INSANE idea back around 1975, and it's totally taken over the world now.

I'm tired of people who learned to program in C and Perl and Python and Java and (god help us) Flash. I tell them "the double precision library doesn't do rounding" and they look at me doe-eyed and say "32 digits should be enough for anybody," without understanding a word I've said. Learn a language that requires you to know a little math and logic before you can even write "Hello, World." Then get into stuff that's "real."


P.S. Visual Basic is the worst of all possible worlds, and newbie programmers shouldn't even be allowed near it until they've passed a test indicating they can spit out the ASCII set to the hardware in .ASM first.

I can haz blog!
[ Parent ]

Nice rant! (3.85 / 7) (#19)
by sigwinch on Wed Sep 05, 2001 at 10:21:59 PM EST

C was designed to be a massively efficient, bare-bones, incredibly fast language suitable for writing operating systems -- "portable assembly language." Which, of course, it fails at, since even a moronic human can write better .asm than a computer...
A human might be able to write a few kilobytes of assembler better than a compiler, but not the tens of millions of lines a modern PC runs. Moreover, even if a human could write assembler 1000 times better than a C compiler, the C compiler would still be a huge win for nearly everything: assembler is forever locked to a single architecture; the same C code will happily run on anything from an 8051 microcontroller to an Athlon.
C++ was an even bigger kludge on top of this kludge, to add a layer of "object orientation" with all kinds of restrictions on the new data structures it introduced (except that all of them can be bypassed, and have to be occasionally if you want to write real code).
Oh yeah. Two words: template metaprogramming. <shudder> On the other hand, if you ignore the tasteless features and stick to single inheritance and polymorphism, C++ is nicer than C.
C bears no relationship to the interior hardware.
And thank Cthulhu it doesn't! It runs happily on Harvard or von Neumann architectures. Stack or stackless. Segmented, paged, or flat. VM or no VM. 8, 16, 32, or 64 bits. RISC, CISC, or VLIW. Signed magnitude or two's complement. Single register set, sliding register window, multiple register set, whatever.
For reference, friends & neighbors, the computer does not process CHARACTERS. It processes INSTRUCTIONS.
But the software processes symbols, which is the sole purpose for the computer. Assembler may have its place, but it is about the poorest tool for symbol processing that exists.
I'm tired of people who learned to program in C and Perl and Python and Java and (god help us) Flash.
Not everyone needs to be able to do every conceivable task. Very few people need to be able to work at all levels of abstraction, from quantum mechanics to ERP package. They just need to know enough to get their jobs done. If a medical researcher wants to analyze the results of a drug study, SAS is entirely appropriate. Assembler, front panel switches, or a soldering iron would be ludicrously inappropriate. Hell, I once designed a simple CPU, but when I need to process some text files I whip out the Python interpreter and don't worry the slightest about how it works.
P.S. Visual Basic is the worst of all possible worlds, and newbie programmers shouldn't even be allowed near it until they've passed a test indicating they can spit out the ASCII set to the hardware in .ASM first.
This is absurd. It's like requiring someone to learn how to anneal and temper steel before they're allowed to profane the sacred drill press.

--
I don't want the world, I just want your half.
[ Parent ]

what tasteless features ? (3.00 / 2) (#44)
by tomte on Thu Sep 06, 2001 at 06:59:48 AM EST

Oh yeah. Two words: template metaprogramming. <shudder> On the other hand, if you ignore the tasteless features and stick to single inheritance and polymorphism, C++ is nicer than C.

Template programming is able to spare you a lot of time otherwise spend typing mindless code (like in highly interfaced java-systems:-);
Read this and learn whats possible.

I'm not advocating for c++ as a beginners language, that would be python anyway.


--
Funny. There's a brightness dial on the monitor, but the users don't get any smarter.
[ Parent ]
[OT] Templates considered as tasteless (none / 0) (#71)
by sigwinch on Thu Sep 06, 2001 at 05:06:54 PM EST

IMHO, compile-time type binding is a misfeature, and templates are a workaround. Templates are basically macros with type-aware conditional compilation. Fully dynamic run-time typing is nearly as fast and small when a few types are being used, and vastly faster and smaller when many types are being used. (Indiscriminate use of templates can easily create enormous amounts of machine code -- most of which is trivial variations on a theme -- which *murders* the i-cache and TLBs.) Plus it lets you put objects of disparate types in the same container with no muss or fuss.

Templates also needlessly complicate the design of debuggers: the same untyped source code serves multiple static types, which means the debugger has to infer variable type from the context in which the templatized function was called.

I'm not arguing that templates cannot be used to useful effect: they can. I'm arguing that they're tastless and baroque from a systems engineering point of view.

--
I don't want the world, I just want your half.
[ Parent ]

I don't understand (none / 0) (#75)
by jacob on Thu Sep 06, 2001 at 07:00:27 PM EST

I'm not sure what you mean by this. Do you mean you think type-checking (the static process at compile time of proving that only certain subsets of values, such as the int's or instances of MyClass, flow into particular variables) is a bad idea, and that instead your ideal language only checks while the program is running whether a value is being used as though it were a member of a subset it isn't? I'm not trying to be sarcastic, I just don't understand what you're saying. In fact, one of my favorite programming languages, Scheme, does it that way, but such languages are generally called untyped rather than typed at run-time.

I agree with you wholeheartedly that C++'s templates are bad -- am I right in assuming that the whole "make a new copy of the code for every new type" business is somehow mandated or encouraged by the language specification? All kinds of problems. However, the idea they're going for, type-polymorphism, can be done much more cleanly, as, e.g., ML proves, as does Sun's new version of Java, which sports a much cleaner implementation of similar syntax as templates.



--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Static vs. dynamic typing (none / 0) (#80)
by sigwinch on Fri Sep 07, 2001 at 01:33:28 AM EST

Do you mean you think type-checking (the static process at compile time of proving that only certain subsets of values, such as the int's or instances of MyClass, flow into particular variables) is a bad idea,...
Yes, that's what I don't like. Specifically, the encoding of deep assumptions about an object's type into the machine code. (I'm not entirely against it. It's useful for operating systems and high-performance code. It's just that programmer time is usually more expensive than machine time.)
In fact, one of my favorite programming languages, Scheme, does it that way, but such languages are generally called untyped rather than typed at run-time.
Untyped is probably more meaningful. (If I had time, I'd insert a rant about Scheme's parentheses here. Fortunately for you I have work to do. ;-)
I agree with you wholeheartedly that C++'s templates are bad -- am I right in assuming that the whole "make a new copy of the code for every new type" business is somehow mandated or encouraged by the language specification?
I'm not a language lawyer, but I don't think it is actually required by the standard. It is probably legal for the compiler to use a single chunk of machine code that does dynamic typing behind the scenes. At least that seems like it ought to work for simple templates. I think nobody does it because it would take a lot of complexity in the compiler and linker, and would be incompatible with existing C++ machine code calling conventions.

--
I don't want the world, I just want your half.
[ Parent ]

oh (none / 0) (#84)
by jacob on Fri Sep 07, 2001 at 11:13:22 AM EST

Yes, that's what I don't like. Specifically, the encoding of deep assumptions about an object's type into the machine code. (I'm not entirely against it. It's useful for operating systems and high-performance code. It's just that programmer time is usually more expensive than machine time.)

Well, deep assumptions, yes, that's bad. I know I've had many evil nefarious bugs in C and C++ that stemmed from me using a value as though it were a Blah* when it was really a Blah2*. But keep in mind that while in C and C++ a variable's type declaration is just an assumption, in ML (and other languages) it's actually proven mathematically -- there's a kind of theorem called a type soundness theorem that you can prove for some languages that guarantees that any program the type checker signs off on will never misapply types. Versions of that theorem are explicitly false in C and C++, believed to be true in Java (but unproven except for smaller "toy" versions), and proven for Standard ML, among others. In those languages, a compiled program makes no assumptions about the type of a variable, it actually has a real honest-to-goodness proof, so the problems that crop up in C and C++ can't ever happen.

If a type soundness theorem can be proven for a language, I think strong typing can sometimes really cut down programmer time. Even in an untyped language, the programmer needs to know what types of values are flowing into each function/method/procedure/block of code, and the programmer making a mistake there causes bugs that can be insidious -- consider the following program in an untyped mutant version of Java I just made up:

myMethod(anObject) {
  if (anObject instanceof ClassA) {
    anObject.classBMethod();
  }
}

The bug in that code would be spotted right away by Java's type-checker, but in the untyped version no error gets raised until myMethod actually gets sent an object that is an instance of ClassA. And what if that happens only in some obscure error case that the programmer doesn't check? He'll never know there's a bug.

Anyway, if you're interested, there's a lot more to type systems than you'd think by looking at the popular typed languages. You might want to check out this introduction to type systems.



--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Colobot is worth a look at neverless (none / 0) (#59)
by beleriand on Thu Sep 06, 2001 at 12:59:02 PM EST

Yes, and the very thought of a C-like language (including C) drives me...

Ok, you don't like C, but you'r missing the point here with this comment. The cool thing with colobot is you click on one of the robots in the game and a programming window pops open. You enter a few line of code, click execute, and off goes the robot... And you can watch what it does in 3D. I't kind of like a quake C for dummies.

I guess they could have picked another language. But than, C++ is most popular so they went with that.

For reference, friends & neighbors, the computer does not process CHARACTERS. It processes INSTRUCTIONS. The most natural way to relate what is going on inside to what you want to do is to build BIGGER INSTRUCTIONS. Which, if you have any sense of order, you will put on SEPARATE LINES.

Which, of course, any good C programmer does, since he wants his stream of gibberish to be readable 6 months later. But he doesn't have to. Why is this? Because some TOTAL IDIOT had a COMPLETELY FLAMING INSANE idea back around 1975, and it's totally taken over the world now.

Yeah, i have sometimes forgotten the ; in C. But really, it's not that big of an issue, most other languages have their little quirks too. You can use an Editor that automatically checks for that stuff, so whats the big deal? Next thing you'll say anyone should use eg. 4 lines indent or is a TOTAL IDIOT?



[ Parent ]
My vote is for Pascal (3.16 / 6) (#7)
by Tatarigami on Wed Sep 05, 2001 at 08:57:56 PM EST

I thought about javascript or some other such deliberately-limited scripting language, but dismissed them because I don't think they encourage good technique.

I learned to enjoy coding through Pascal, which was simple enough and forgiving enough for a newbie to pick up before moving onto more object-oriented languages.

I say I learned to enjoy Pascal, because I took a programming class at highschool in which the teacher made a half-hearted attempt to teach us top-down design and coding in a macro language that came bundled in a word processing package the school paid way too much for. About the most complicated thing we were able to pick up was changing the background colour of the menus we created... it was at that point I decided that I'd rather eat my own foot than code for a living, but Polytech and a Turbo Pascal paper the following year made me think it wouldn't be so bad.

Python, of course (3.50 / 14) (#8)
by MK77 on Wed Sep 05, 2001 at 09:02:38 PM EST

It's simple, elegant, teachs OO principles and its ideal is CP4E: computer programmer for everyone. I can't think of a better language for beginners, and it's also useful for experienced programmers. How can you beat that?


--
Mmm... rageahol
Definitely (2.83 / 6) (#14)
by mbrubeck on Wed Sep 05, 2001 at 09:41:32 PM EST

In my experience this is completely true. Recently some math majors at my school who had never programmed before chose Python for some numerical analysis they had to do. After just a couple hours of tutorial they were already getting real work done. They even produced readable, well-structured code (students I've graded who start out in C/C++ or Java generally produce very kludgey code until they are more experienced).

[ Parent ]
I second Python (3.80 / 5) (#25)
by sigwinch on Wed Sep 05, 2001 at 10:49:21 PM EST

You're right about the syntax being simple and elegant, but I would add that it is easily readable. (Other languages, like Lisp/Scheme are elegant but difficult to read.) The syntax also strongly resembles mathematical notation: Python lists, tuples, operators, and loops will be familar to anyone who has studied much math. Object-orientation is nice, but I don't think it matters for a novice student.

It also has a nifty command line interpreter. Want to know what a statement does? Type it in and press enter. Its exceptions are also nice, telling you what blew up and how the program got to that point. (Unlike a C program, which will just say 'segmentation fault' and die.)

Python is also a useful language. Not only is it easy to learn, it is expressive enough that an experienced programmer can create complex, powerful programs. Even better, it is mostly OS-agnostic: your programs will run on Windows, Unix, or a Java machine without major changes.

Python.org has a good collection of material on Python in education. The LiveWires Python Course is aimed towards 12-15 year olds (although it would be useful to a novice of any age) and has worksheets and other materials available for download.

--
I don't want the world, I just want your half.
[ Parent ]

Do they really want to learn? (4.09 / 11) (#10)
by pdw on Wed Sep 05, 2001 at 09:07:37 PM EST

Most people that ask me about a good first language, really want one of these two things:

  1. They want to write a virus, or a Quake III clone, and expect me to point them to a tutorial that explains how to just do that.
  2. They really want just to quickly write a Windows program. I tell them to get Delphi, but they'll buy VB because it's from Microsoft. Usually one or two crappy shareware programs follow, and then their programming carrier is over.

Other people don't ask about it, they go out and do it. They notice that a lot of the scripts on their Linux system are written in Perl, and they hear it is a pretty easy language to do something in. So they search from documentation on the net, or get a book from the library, or whatever, they read at the code of the scripts, and then they try to write some scripts of their own.

When they have some experience with Perl, they notice some people don't like Perl and use Python, or Ruby, or Scheme instead. They get some documentation on it, and try a couple of those languages. They may like them and switch, or not, but that's not important. While playing with them, they learned a few more ways of doing things.

or (3.00 / 1) (#28)
by spacejack on Wed Sep 05, 2001 at 11:13:25 PM EST

They want to make 'X' and find out such-and-such language is the best solution.

[ Parent ]
It wasn't like that for me.. (none / 0) (#65)
by Rainy on Thu Sep 06, 2001 at 03:32:08 PM EST

I started with C++ because I that's what most programs were done in. I didn't get very far. Then I learned a bit of java and it felt wrong to me, so I again didn't get very far. Maybe it was the book I was learning by. Then I tried python and it took me a long while to get somewhere with it, but I never got sick of it. I kept coming back. I think if someone recommended me python back when I was opening my first C++ book, I'd save a lot of time and I'd be a much better programmer now. YMMV, of course.
--
Rainy "Collect all zero" Day
[ Parent ]
7 posts, and nobody has mentioned BASIC? (4.00 / 11) (#11)
by localroger on Wed Sep 05, 2001 at 09:10:23 PM EST

Stop laughing. I'm not talking about VB. I'm not even talking about QuickBasic, or even GW-BASIC. I'm talking about BASIC, which has exactly 7 keywords and one variable type.

This is how I learned, on a HP2100A minicomputer with 32Kbyte (16Kx16bit) RAM, on a model 22 Teletype machine which spit my chars out at the then-amazing rate of 110 baud (all electromechanically) on very wide toilet paper.

You learn one very important lesson from an environment like this: THE COMPUTER IS LIMITED. It is failure to respect those limits (even though they recede regularly) that causes much of the grief we experience when using modern software.

Of course, an alternative might be assembly language on an 8-bit processor (my next step after BASIC), or FORTH. What you do NOT want is an environment that does everything for you and greases the path to success. You do not learn when everything is done for you. You learn when privation forces you to learn the mechanisms because the alternative is failure.

Yes, you can spend 60 seconds writing one line in PERL to do the same thing that takes a couple of hours of tinkering in a primitive language, but you don't learn anything in the higher-level language. You get used to the convenience, then take it for granted, so you never know what is really possible when you're asked to do something important and critical like write an operating system.

Oh, wait a minute, that's how modern operating systems came about. Never mind. Just start with an easy language, since nobody cares how inefficient things are any more. I suggest BASIC.

I can haz blog!

RPDUB (3.75 / 4) (#18)
by Pac on Wed Sep 05, 2001 at 10:20:28 PM EST

As in "Real Programmers Don't Use Basic"...

But seriously, you must be joking. The second language I learned was AppleSoft Basic (after Pascal). The third was 6502 Assembler, just to get away from that mess.

Standard Basic is one of the worst first languages one can choose, partly because it is too easy to learn but mainly because it has too little modern programming language theory build in. And you do not need take "modern" as in 2001, you can take it as in 1970.

C, Pascal, SmallTalk and a great number of other languages will keep a student from learning bad habits and help the student to learn good habits by simply enforcing a number of syntatical rules. Basic will let the student do almost anything, at the cost of making the switch to a real language harder.


Evolution doesn't take prisoners


[ Parent ]
Old Farts... (3.00 / 1) (#49)
by wiredog on Thu Sep 06, 2001 at 08:19:42 AM EST

That's the type of system I did my first programming on back at Langley High School. We also had two glass ttys in the "computer room", which was a retired broom closet. At one time I knew all the escape codes to get cool text effects (like blinking white on black) on the terminals. The system also provided fortran and, I think, lisp.

They were still teaching the use of slide rules back then.

The idea of a global village is wrong, it's more like a gazillion pub bars.
Phage
[ Parent ]

Fortran 77 (4.00 / 3) (#50)
by shrub34 on Thu Sep 06, 2001 at 08:25:45 AM EST

I learned Fortran 77 as my first language. Yes you don't have pointers and yes you use the infamous GOTO but you learn something. You learn that the computer is limited, you learn to make variables as readable as possible so you can follow your own code. You also discover that tab and space are 2 different characters. You also learn that computer expect special formats to get your program to compile (your line best start in column 7 or it will fail). Once I learned Fortran, I discovered that any language is easy with the right refrences.

=====
It's good to see the BSD community forking and execing so many child processes.

  • Comment about editor of Daemon News not attending BSDco
    [ Parent ]
  • 42 (3.60 / 5) (#13)
    by slaytanic killer on Wed Sep 05, 2001 at 09:33:06 PM EST

    Teach 'em the language which allows them to create the stuff they want to build. I'd never use the same style of teaching on two different people; you want to work with the clay you get. As their interests change, tell them about other languages. The important thing is not teaching them in serial, but building up a net of knowledge which makes later concepts jell faster and make more sense.

    There is a reason for great similarities between languages. They're mainly just optimized for scale, and backwards compatibility.

    Look at all the languages everyone is advocating. Then this point becomes clear. And yes, I have responses to any disagreements people will have, if anyone cares to rebut, so feel free to blast away.

    Related question (3.20 / 5) (#15)
    by scriptkiddie on Wed Sep 05, 2001 at 09:56:40 PM EST

    Would teaching people to program using a MOO be worthwhile? The advantage is that they can create soft models of hard objects - I can make a desk, a chair, or a window by programming in a MOO. This is an amazingly concrete way to teach object-orientation. Also, many MOOs have thousands of people online who can be asked about technical and conceptual issues. The disadvantage is that the MOO programming language is fairly obtuse.

    Any suggestions?

    LPC is a nice language (4.00 / 2) (#31)
    by dasunt on Thu Sep 06, 2001 at 01:15:11 AM EST

    LPC is a nice simple language with OO and a feeling simular to C. Its used for LP Muds, and is an interpretted language.

    The nice thing about mud coding is that it teaches efficiency (or that it should). For example, I was talking with another coder just last night about a stat rearrange system for a mud. A player can rearrange stats only once. So, it makes little sense to add that code to the player object, since its added baggage that will lead to more memory consumption with no benefit. The stat system also had an order to rearrange stats in, which had to be fixed, since different players would choose different orders, and fsck up the other player's order. Now the order could be set by a player property (a variable saved to the player), but again, this is inefficient since the order to rearrange stats is only used once. Instead, the code needs to be arranged so it can be invoked once per player, and either reused, or preferrably (in a small mud with few players, and thus even fewer requests for rearranges) unloaded from memory when its not being used.

    There is also the issue of properly commenting code so that other coders can understand your work. Its a group project, which reflects the coding environment for a lot of projects.

    Plus LPC has the ability to shadow functions, which is good, because every beginner's language should have at least one problem. ;) What's better then totally messing with proper flow control?

    Oops, I'm ranting. :) But you get the idea. I like the fact that in a MUD or MOO, memory management is important. Poor code will create problems, good code won't.



    [ Parent ]

    Pascal is very fine (3.66 / 6) (#16)
    by Betcour on Wed Sep 05, 2001 at 09:56:56 PM EST

    What's the problem with Pascal ? It is not out of date. As for as I know loops, variables, constants, types, branching, arrays etc... are all still up to date. If you want to teach object oriented programming, you can use the Borland version (Turbo Pascal or better, the latest Delphi which supports exceptions, trendy object features etc...).

    Pascal is good because it teach clean and orthodox programming (it won't let you use an int as a pointer by default), yet is a "regular language". It is easier to go from Pascal to C, PHP, Java or whatever than the other way around (just as it is easier to go from strong typing to loose typing than the other way around). Best of all, with Delphi and Kylix it can be put to real use pretty quickly.

    I'd avoid languages like LISP, Prolog or SmallTalk. While they are fine and interesting in themselves, they are very different from "regular" programming languages (C/C++, Pascal, Java etc...) and use radical concept. Going from LISP to C might be a difficult trip !

    Lisp and Scheme have C translators, actually. (2.00 / 1) (#23)
    by la princesa on Wed Sep 05, 2001 at 10:43:24 PM EST

    I cannot recall the specifics and am presently disinclined to look them up tho. Although I imagine a google for 'Scheme and C' or 'Lisp and C' will turn up some stuff.

    [ Parent ]
    Perl (2.47 / 17) (#21)
    by Justinfinity on Wed Sep 05, 2001 at 10:32:58 PM EST

    Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl, Perl!

    and don't forget Perl!

    -Justin
    Why don't you listen to me? If you listen, you get some of that clean, refreshing, new world

    Perl? There's More Than One Way To Screw It Up (4.09 / 11) (#22)
    by Valdrax on Wed Sep 05, 2001 at 10:40:11 PM EST

    Are you kidding? Perl teaches you every bad habit of C, AWK, and shell scripting all in one TMTOWTDI mess. Perl is a terrible teaching language!

    You need something with more structure and discipline to wean newcomers on before taking away the training wheels. Otherwise, you can get people stuck in some really bad coding habits, like using single-letter variable names, compounding statements into one hard-to-read line, and making heavy use of short-circuit evaulation as flow-control.

    I'd recommend Java, ML, or Python.

    Really, do you want to start people on a language for which the suggestion of an International Obfuscated Code contest brought responses of, "Why bother? Isn't it already obfuscated."

    [ Parent ]
    it really comes down to style. (4.00 / 5) (#27)
    by Defect on Wed Sep 05, 2001 at 11:07:58 PM EST

    When it's all about programming, think back to high school, and to which teachers you learned better from.

    Did you learn more from the teachers that prevented you from thinking outside the box, and forced boring after boring assignment down your throat? Or did you learn more from the teachers that were cool, made learning fun, and allowed you to learn what you wanted to learn?

    Perl's an extraordinary language to learn because it forces you to think creatively, rather than extensively. I'm not saying stricter languages suck, but the problems that arise from them leave you thinking "fuck, what do i do now" rather than "hmmm, how can i do this?" And that's really because perl allows you to do nearly anything with fairly basic knowledge, once you get the basics down you can put what you've learned to work and get some pretty cool results in no time at all.

    Having a million and one ways to execute one simple algorithm is not a bad thing.
    defect - jso - joseth || a link
    [ Parent ]
    It's not that good to reinvent the wheel 1000x. (4.00 / 2) (#33)
    by la princesa on Thu Sep 06, 2001 at 03:06:00 AM EST

    "Having a million and one ways to execute one simple algorithm is not a bad thing."

    In that case, one might as well just go with C or the assortment of shells that perl erupted from. It's almost unfair to subject a newbie to multiple options for a single process when they could learn the basic form of the process and worry about the myriad alternate ways to perform it later.



    [ Parent ]
    a good teacher.... (none / 0) (#95)
    by Justinfinity on Fri Sep 07, 2001 at 10:01:33 PM EST

    won't let the student use the shortcuts until they are ready too. a good teacher will teach the correct methods. any language can be coded bad.

    -Justin
    Why don't you listen to me? If you listen, you get some of that clean, refreshing, new world Parent ]

    boxes (4.00 / 3) (#76)
    by kubalaa on Thu Sep 06, 2001 at 07:28:53 PM EST

    The challenge of programming isn't thinking outside the box, it's thinking INSIDE. Yes, I'm serious! There are an infinite number of text strings that you can type into the computer, but there are only a few that will get it to do what you want, and even fewer that are efficient, easy to read, easy to understand, and easy to extend. Maybe only one.

    The "box", then is the rules which govern and limit the program. Syntax is one such rule languages impose; others impose more conceptual boxes with idioms like objects. A programmer's job is to find the box in which that one perfect program is contained, and then they will have written it. The job of a good language is to restrict the area of search so the box is easier to find. That's why some languages are better for some tasks than others, because their box is closer to that of the task.

    Perl's philosophy is to combine the domains of many languages to make more things easy; it lets you draw your own boxes with some freedom. BUT this is NOT helpful to a beginner; a beginner needs to learn some good boxes before you send them off to make their own, and even experts have trouble finding the willpower to impose necessary structure and consistency on perl programs.

    [ Parent ]

    again, it's about the teacher (none / 0) (#97)
    by Justinfinity on Fri Sep 07, 2001 at 10:12:34 PM EST

    as i said in my other comments. it's up to the teacher to keep the students in the box in the beginning. Perl also lets the teacher gradually expand the box, at the pace of the students. to learn many other languages you have to be force-fed huge chunks in order to make little pieces make sense.

    -Justin
    Why don't you listen to me? If you listen, you get some of that clean, refreshing, new world Parent ]

    ARRGH! (none / 0) (#96)
    by Justinfinity on Fri Sep 07, 2001 at 10:09:51 PM EST

    do you code Perl? I'm so fucking sick of people saying Perl is messy or overly complex. i taught myself using the Llama book in about 3 days. My perl, while not overly complex yet, is always very well commented and very clean syntactically.

    one-line short-circuit evaluation is bad? it reads like english and performs like a 5 line if-then-else branch in C that reads like swahili to most people. do_this() or do_that(); do_this() if $that = true; if that's complex, i'm fucked up in the head then.

    any language can be coded bad, it's up to the teacher to teach good coding habits. the good thing about Perl is that once the basics are learned, and they can be easily learned piece by piece and learned quickly, the student then can expand along their own path.

    Perl is freedom in programming.

    -Justin
    Why don't you listen to me? If you listen, you get some of that clean, refreshing, new world Parent ]

    Learning to program is different than... (4.00 / 1) (#105)
    by darthaggie on Sat Sep 08, 2001 at 01:14:23 PM EST

    ...learning a language. If you can program, you can program in any langauge that is documented.

    My perl, while not overly complex yet, is always very well commented and very clean syntactically.

    And for every good, clean, easy to read perl program you write (I do the same acutally, as its more conducive to my mental health), I can yank a fetid, steaming pile of crap out of "Matt's script archive". Good perl is a matter of discipline and experience.

    Perl is really about programming freedom, which is a Good Thing. But it will also cheerfully hand a newbie all the rope she/he needs to hang themselves, too. And that's not necessarily a Good Thing.

    I am BOFH. Resistance is futile. Your network will be assimilated.
    [ Parent ]

    good [pick a lang] code is a matter of discipline (1.50 / 2) (#107)
    by Justinfinity on Sat Sep 08, 2001 at 02:34:44 PM EST

    what came first, obfuscated C contests or obfuscated Perl contests? C, of course.

    the reason you can find a lot of seemingly messy Perl scripts is:
    a) Perl is damn popular. a lot of web programmers know Perl.
    b) Perl adapts to your programming style. as you learn more of the language, you can take more and more shortcuts and get more useful code written in a given time. you learn C and you're locked in stone.
    c) advanced Perl is so very powerful. compare to sufficienctly powerful and complex apps in other languages? how many brand new C++ programmers can look at a class hierarchy with polymorphism and multiple inheritance and have a clue what is going on? not many.

    People who don't know Perl at all see complex scripts (or scripts done simply for fun, for contests and such) it and bitch about it being too confusing. send a beginning C coder to look at the code from an OCC and see what he says about coding in C.

    not to mention that Perl is constantly evolving. while maintaining backwards compatibility (use Perl <version>;)

    BTW (to everyone) i learned (taught myself) BASIC, then Pascal followed by C/C++ melded together, then Perl. i wish i had learned Perl first.

    -Justin
    Knock knock Neo.
    Want some new world water?
    Perl is freedom in programmin
    [ Parent ]

    #!/usr/bin/perl (2.20 / 5) (#26)
    by Defect on Wed Sep 05, 2001 at 10:53:23 PM EST

    $,=a;$/='$,';$c='print';$.=" ";@_=qw(15 4 17 11 $. 8 18 $. 15 14 18 18 8 1 11
    24 $. 19 7 4 $. 1 4 18 19 $. 11 0 13 6 20 0 6 4 $. 24 14 20 $. 2 0 13 $. 11 4
    0 17 13 $. 22 7 4 13 $. 9 20 18 19 $. 1 4 6 8 13 13 8 13 6 '.' $. 13 14 19 $.
    14 13 11 24 $. 8 18 $. 8 19 $. 4 23 19 17 0 14 17 3 8 13 0 17 8 11 24 $. 4 0
    18 24 $. 19 14 $. 6 4 19 $. 19 7 4 $. 1 0 18 8 2 18 $. 3 14 22 13 ',' $. 1 20
    19 $. 19 7 4 17 4 $. 8 18 $. 18 20 2 7 $. 0 13 $. 8 13 5 8 13 8 19 4 11 24 $.
    11 0 17 6 4 $. 0 12 14 20 13 19 $. 14 5 $. 17 14 14 12 $. 19 14 $. 6 17 14 22
    $. 19 7 0 19 $. 24 14 20 $. 2 0 13 $. 11 4 0 17 13 $. 8 19 $. 0 13 3 $. 13 14
    19 $. 6 4 19 $. 1 14 17 4 3 $. 5 14 17 $. 24 4 0 17 18 '.' $. 0 13 3 $. 7 4 24
    ',' $. 8 19 "'" 18 $. 0 11 18 14 $. 0 2 19 20 0 11 11 24 $. 20 18 4 5 20 11 $.
    8 13 $. 19 7 8 18 $. 3 0 24 $. 0 13 3 $. 0 6 4 ',' $. 18 14 $. 22 7 8 11 4 $.
    15 4 14 15 11 4 $. 0 17 4 $. 11 4 0 17 13 8 13 6 $. 15 0 18 2 0 11 ',' $. 1 0
    18 8 2 ',' $. 0 13 3 $. 22 7 0 19 4 21 4 17 ',' $. 24 14 20 $. 2 0 13 $. 1 4
    $. 11 4 0 17 13 8 13 6 $. 18 14 12 4 19 7 8 13 6 $. 19 7 0 19 $. 2 0 13 $. 4
    21 4 13 19 20 0 11 11 24 $. 12 0 10 4 $. 24 14 20 $. 0 $. 1 8 19 $. 14 5 $.
    12 14 13 4 24 '.');for(@_){if(!/\d/){$d.="$c $_;"}else{for(1..$_){$d.="$/++;"}
    $d.="$c \$,;$/='a';"};}eval$d

    defect - jso - joseth || a link
    [ Parent ]
    for those of you without perl installed... (1.00 / 1) (#117)
    by Justinfinity on Mon Sep 10, 2001 at 11:01:36 PM EST

    and those who can't read FUN perl (most people)

    "perl is possibly the best language you can learn when just beginning. not only is it extraordinarily easy to get the basics down, but there is such an infinitely large amount of room to grow that you can learn it and not get bored for years. and hey, it's also actually useful in this day and age, so while people are learning pascal, basic, and whatever, you can be learning something that can eventually make you a bit of money."

    -Justin
    Knock knock Neo.
    Want some new world water?
    Perl is freedom in programmin
    [ Parent ]

    eh? (none / 0) (#119)
    by Defect on Thu Sep 13, 2001 at 09:11:34 PM EST

    There are people that don't have perl? Wtf kind of world do we live in?
    defect - jso - joseth || a link
    [ Parent ]
    a world where people listen to propaganda... (1.00 / 1) (#120)
    by Justinfinity on Thu Sep 13, 2001 at 11:18:16 PM EST

    from MS. 'cause you know, MS provides everything you will ever need to use a computer, ever. including incentive to pay them more money after you have to buy a new machine because their latest stuff won't run on your old one, but then you need to buy their next latest stuff to take advantage of your new system.

    oh yeah, did you hear: you need a pentium 4 and windows xp to burn a CD. really! i saw it in some ads in a magazine with "internet" in it's title. must be true.

    /me falls over

    haha

    -Justin
    Knock knock Neo.
    Want some new world water?
    Perl is freedom in programmin
    [ Parent ]

    Lay off the crack pipe (3.25 / 4) (#36)
    by spiralx on Thu Sep 06, 2001 at 03:38:33 AM EST

    Come on, Perl is an awful language to learn. The high initial learning curve means that anyone wanting to do anything in Perl is going to be put off before they get there, and the fact that so much of the language relies on default behaviours is not conducive to moving to other languages. I've learnt a dozen or so languages over the years, and Perl is the only one that just put me off bothering with it.

    Nope, I'd go with other posters suggesting Pascal or Python. Both were designed to be easily taught, and they're both a lot more readable than Perl ever will be.

    You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
    [ Parent ]

    i really don't understand... (none / 0) (#99)
    by Justinfinity on Fri Sep 07, 2001 at 10:28:43 PM EST

    ...exactly what you're saying.

    perl's learning curve is tiny since you can pick up little pieces at a time.

    -Justin
    If you just listen, you get 8 liters of clean, refreshing, new world water[ Parent ]

    But... (4.00 / 1) (#104)
    by spiralx on Sat Sep 08, 2001 at 12:52:34 PM EST

    You personally may be being taught in a good way, explicitly putting in all of the shortcuts and hidden variables Perl uses (well as much as you can), but the syntax is not immediately obvious in a lot of cases because of this stuff. For a beginner it will mean constant referrals to man pages or what ever, which interferes with learning how to program.

    For a beginner explicit is always better than implicit, as you pretty much said yourself in another comment. Perl is a very explicit language; this may be great for people who know the language really well, but it doesn't make it a doddle to pick up.

    Oh, and any language can be picked up in little pieces at a time :)

    You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
    [ Parent ]

    to clarify... (1.50 / 2) (#106)
    by Justinfinity on Sat Sep 08, 2001 at 02:20:54 PM EST

    "For a beginner explicit is always better than implicit"

    ok

    "Perl is a very explicit language;"

    ok

    so Perl is good then.

    the syntax of Perl is very obvious, since it reads so much more like English than many languages.

    not to mention (to everyone) that since Perl takes pieces from so many other languages, it's a good base to expand upon. learn perl and not only can you code on virtually any platform in existence, but you can apply what Perl taught you to a whole slew of other languages.

    -Justin
    Knock knock Neo.
    Want some new world water?
    Perl is freedom in programmin
    [ Parent ]

    Ooops (none / 0) (#110)
    by spiralx on Mon Sep 10, 2001 at 04:11:03 AM EST

    "Perl is a very explicit language;"

    My mistake; I meant implicit of course.

    the syntax of Perl is very obvious, since it reads so much more like English than many languages.

    Short of the fact that you can use if and unless after statements I've yet to see anything that would make me agree with this. In particular, the abundance of variables with obscure characters in them is hardly like English is it?

    not to mention (to everyone) that since Perl takes pieces from so many other languages, it's a good base to expand upon.

    Maybe so. Although I'd say the syntactic shortcuts you are so fond of are likely to proove a hindrance when moving to other languages which aren't so sloppy.

    You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
    [ Parent ]

    example (1.00 / 1) (#112)
    by Justinfinity on Mon Sep 10, 2001 at 01:11:18 PM EST

    Perl:

    foreach $line (@data) {
    if ($line =~ /text/) {
    print $line;
    }
    }

    English:

    for each line in the data
    if the line contains "text"
    print the line

    whoa, pretty damn similar!

    (the formatting is shitty cause of HTML collapsing whitespace}

    [ Parent ]
    Example (none / 0) (#114)
    by spiralx on Mon Sep 10, 2001 at 05:41:32 PM EST

    Python:

    for line in data:
      if line.find("foo"):
        print line

    Hmmm, pretty similar to English again!

    You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
    [ Parent ]

    i never said it wasn't (1.00 / 1) (#115)
    by Justinfinity on Mon Sep 10, 2001 at 10:45:47 PM EST

    (to everyone)

    notice how all along i've done nothing but point out the good parts of Perl.

    not once do i recall actually putting down another language (well maybe Python's formatting based syntax a little, but who wants to be forced to learn formatting AND programming at the same!?).

    this whole time everyone has just bashed perl, made blanket statement based on limited amounts of code they've seen, or perhaps not seen.

    Perl has this nasty reputation of being unreadable. i'm no where near being a perl guru, but i can take a look at most perl and get the gist of it (maybe not packed data, but you don't often see eval code intentionally pack()ed unless they are having fun with it, ie a contest).

    and i'm done with this topic for now since you all just want to criticize instead of looking at the good sides.

    -Justin
    Knock knock Neo.
    Want some new world water?
    Perl is freedom in programmin
    [ Parent ]

    Point (none / 0) (#118)
    by spiralx on Tue Sep 11, 2001 at 03:32:53 AM EST

    and i'm done with this topic for now since you all just want to criticize instead of looking at the good sides.

    Perl is a good language for a lot of things, I don't recall ever saying it wasn't. I just don't see it as being very good for a first language for someone that has no programming experiance that's all.

    You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
    [ Parent ]

    I agree because of my experience (4.00 / 3) (#72)
    by hansel on Thu Sep 06, 2001 at 05:34:00 PM EST

    I started with Perl, and Perl's loose typing and general messiness allowed me to accomplish something fairly quickly without too much code and too much strictness. In other words, I very quickly got a taste of what I could accomplish with it, and moved on to more strict languages once I understood the generalities.

    I don't think Perl has a steep learning curve; just the opposite, in fact, which is beneficial to a beginner.

    Bad coding habits aren't a product of the language; they're a fault of the programmer. I can write clear Perl and muddy Python, and the choice is up to me, not the syntax.

    [ Parent ]
    yay! a sane person! (none / 0) (#98)
    by Justinfinity on Fri Sep 07, 2001 at 10:20:44 PM EST

    indeed, perl lets you learn about programming without having to worry about the syntactic necessities that other languages force upon you.

    take python for example. not only to you have to teach the student about logic in programs, but you also have to teach them how to indent. personally, i'd rather learn the logic, and use my own brain to apply the formatting based on how MY brain interprets the logic.

    -Justin
    If you just listen, you get some of that clean, refreshing, new world [ Parent ]

    Beginners? (3.20 / 10) (#29)
    by cunt on Wed Sep 05, 2001 at 11:38:21 PM EST

    Well, it depends on how you feel about this beginner. If you have a shred of affection or pity for them, or even a modicum of human decency, tell them to stay away from computers. If not, it really makes no odds what language they start with. In tech, all roads lead to hell.

    Bitter, am I? Damn straight I am. Computers are tearing our culture apart and offering nothing back except endless frustration and a whole lot of free porn.

    Yowch! (3.50 / 2) (#42)
    by Cloaked User on Thu Sep 06, 2001 at 05:01:03 AM EST

    Someone got burnt in the dotcom crash, didn't they?


    Cheers,

    Tim
    --
    "What the fuck do you mean 'Are you inspired to come to work'? Of course I'm not 'inspired'. It's a job for God's sake! The money's enough and the work's not so crap that I leave."
    [ Parent ]
    Don't despair (none / 0) (#73)
    by mami on Thu Sep 06, 2001 at 06:14:38 PM EST

    because I speak from experience. If a beginner asks which is the best first language to learn that means he looks for an excuse not to learn any... :-)

    [ Parent ]
    -1, Information. (4.50 / 2) (#30)
    by float1111 on Thu Sep 06, 2001 at 12:35:29 AM EST

    I suggest you direct that person to http://www.azillionmonkeys.com. It has quite a bit of links to programming resources, and on site critique and examples of techniques.
    /._^./
    LISP (3.75 / 4) (#34)
    by kvan on Thu Sep 06, 2001 at 03:26:09 AM EST

    Starting people off in LISP (or possibly another functional language, in case you're more familiar with Scheme or ML or such) serves two purposes:

    • Everyone starts off at the same level, since almost nobody without prior training will have even seen a functional language before.
    • Unlike procedural programming, functional programming is usually not immediately intuitive; it takes some time before people have the "aha!"-experience. This is good because it forces them into using design methodologies and documenting their code.


    "Many people would sooner die than think; in fact, most do." - Bertrand Russell


    That's the theory, at least (3.00 / 1) (#45)
    by pdw on Thu Sep 06, 2001 at 07:03:19 AM EST

    The local university teaches its introductory programming course in Scheme. Like you, they claim that since nobody knows it, everybody starts at the same level.

    Well, that's not true. The're were clear differences between students with and students without programming experiences. I grasped it pretty quickly. My friend (whose only programming consisted of copy&paste of JavaScript) had trouble with it for most of the year.

    Unlike procedural programming, functional programming is usually not immediately intuitive. LOL. I agree with you, but do you realize most functional language advocates claim the opposite? As functional languages have no assignments, they are stateless, and people don't have to think about it.

    [ Parent ]

    I'm not sure it's programming. (4.00 / 2) (#48)
    by kvan on Thu Sep 06, 2001 at 07:59:42 AM EST

    When I started CS in Copenhagen, they started out with LISP. What I noticed was that of those of us with programming experience, it was only the ones who were also good at math who understood LISP faster than non-programmers. And some who were skilled in math understood it at least as fast as those with programming experience. The difference was particularly telling since the class attracted several second and third year Physics students, who had taken university-level calculus and algebra. They latched on to the required mindset much faster than even the most experienced freshman programmer.

    And yes, many functional language advocates are full of crap. We live in a stateful world, and people already know variables from elementary algebra. Actually, based on the time I've seen people take to grasp the concepts, I'd make the comparison that the procedural paradigm is "easy" to learn in the same way as algebra, whereas the functional one is "hard" in the same way as calculus; one requires more discrete thinking, and the other more abstract thinking. I quote "easy" and "hard" because for some people they're reversed, and for some there isn't much of a difference.


    "Many people would sooner die than think; in fact, most do." - Bertrand Russell


    [ Parent ]
    Logo! (3.66 / 3) (#35)
    by 31: on Thu Sep 06, 2001 at 03:28:45 AM EST

    It was mentioned below, and I really think it's a great idea.

    For those who haven't used it, you give it command, and a turtle follows them. It has functions, you can do recursion in it, it does all of the high level stuff.

    Now... as for learning to program it... you wanna know how I know about this language? Because it's taught to elementary school kids at a school I work part time at. Every student, by the time they leave at the end of the fifth grade, has programmed in logo.

    Depending on who you're trying to teach, you can either go for traditional computer science topics, or for a younger group it's good for teaching a combo of math and showing how a computer does nothing but follow instructions you give it.

    Here's the first link I could find for it. There's at least free programs for windows for it, and I'm sure they'll provide a better justification for it's use than I will.

    -Patrick
    LOGO (4.00 / 1) (#46)
    by 0x00 on Thu Sep 06, 2001 at 07:15:57 AM EST

    Some of my earlier programming experience came from LOGO, the progam was called logowriter which we used at school. A year or so later we upgraded to a program that used LOGO called Microworlds. IIRC, Early lego robots could be programmed using logo. Now, almost 10 years later, what goes around comes around, and i'm using LISP. heh. funny.

    I don't think it really matters what language is used to introduce programming to students. Just make sure by university strong design principles are being pounded into their head every single second.

    --

    0x00

    defun Clown

    [ Parent ]
    Teufelkunst (3.00 / 2) (#37)
    by kaatunut on Thu Sep 06, 2001 at 03:49:11 AM EST

    Malbolge

    If they survive that they'll be on their way to being a new Mel, and if they don't they've avoided the dreadful fate of a coder.

    --
    there's hole up in the sky from where the angels fall to sire children that grow up too tall, there's hole down in the ground where all the dead men go down purgatory's highways that gun their souls

    Decide what are the goals first. (4.00 / 4) (#39)
    by Sawzall on Thu Sep 06, 2001 at 04:03:43 AM EST

    Then make the decision. I do think that the goals of a project often guide us to the "correct" choice.

    What are some of them?

    1. It should not teach bad habits by its very nature. Which leads me to strong type. I know we all hate it once we learn what we are doing, but the reality is that our beginner language should not allow us to effectively reformat our drive because we are stupid.

    2. It should allow for quick results. Effective learning requires rewards, particularly when it is likely to be a challenge. 3. I really think it should be compiled. Why? So that the student learns the entire process. If you can get it to compile and run, switching to interpet is easy. So even if you think my list is nuts, fine. Come up with your own. Have other ideas for it, add on. But I really think that an objective process of determining the language is better than a "holy war".

    A structured, strongly typed language of course (4.25 / 4) (#40)
    by thunderbee on Thu Sep 06, 2001 at 04:14:50 AM EST

    I've read the most stupid things here. The ony way to teach good programming practices is by using a structured language. One without goto, one with strong variable typing, and one with minimal obfuscating capabilities.

    So this definitely rules out perl or php (even perl -w with use strict, which sadly almost nobody uses anyway).

    Pascal is the way to go because it has the 'string' variable type that C lacks. It's easier for a beginner to be able to handle string variable without having to understand pointers at the very beginning of his training.

    There certainly are other languages around that satisfy those two requirements, I don't know all of them ;-)

    "easy" languages, like perl or php (don't know python, but from it's popularity, I gather it must be loosely typed) are of course more forgiving to the beginner, but also encourage bad programming practices.

    I'm amazed at how badly 90% of GPL / open source / free software is written. I often find it easier to write a program from scratch rather than trying to improve an existing code-base. I also understand the incredible number of releases and bug-fixes for simple programs: easy programming is not good programming. It's just faster. But in the end, you'll pay tenfold for what you thought you saved.
    And, yes, I use perl, and php. But I learned to code in pascal (self-taught basic doesn't count), before moving to C, lisp, prolog, and then perl and php.

    Php and perl are nice tools, very suitable to some tasks, when you know how to use them properly! They're just not for learning.

    A dynamically-typed, elegant language of course (4.66 / 6) (#43)
    by spiv on Thu Sep 06, 2001 at 06:19:24 AM EST

    "easy" languages, like perl or php (don't know python, but from it's popularity, I gather it must be loosely typed) are of course more forgiving to the beginner, but also encourage bad programming practices.

    Here I disagree.

    You make that assertion, but don't back it up at all. Allow me to build your argument up a little for you...

    Perl and PHP encourage "messy" code. They don't lack ways to make code well-structured (I'm being vague, I know), but they somehow fail to make you want to use them. Objects are often (yes, I know, not always) a useful abstraction, and Perl has a horrid way of building them. Perl is far too liberal in what it does... imagine trying to explain how different contexts work to a person trying to learning programming. PHP has many similar flaws, and less power.

    ...but you'll notice something about this argument. I haven't mentioned Python yet.

    In Python, structure is everything. You have explicit control of the namespaces. Variables have a well-defined scope, and objects are just so and simple in Python, and are a wonderful tool for keeping the structure clean. Modules are also dead-easy. So far, not too dis-similar from Perl.

    But it is much, much cleaner. Practically everything is a first-class object. Functions are objects that can be passed around and manipulated identically to class instances. Classes can be manipulated identically to class instances. Same with modules, too. It sounds cute, but it is incredibly useful.

    There are other reasons (e.g. enforced consistent indenting... you should do it anyway, so there's no reason to not like it), but you'd do better to investigate it for yourself. You say you've never looked at it... you should. It is easy to learn. http://www.python.org.

    I think it could be a wonderful beginner's language. It has lists and dictionaries as built-in types, and an interactive prompt mode that is incredibly useful for playing with the language, and demonstrating things with.

    I agree, I'd never teach a newbie Perl or PHP. And I suspect the quality of much free software is as bad as you say, although I haven't really looked at the source of enough to know. But neither of those points is an argument against Python. Python encourages "good" programming, which is what you seem to be after... and it abstracts away alot of the mundanities of your statically typed langauges, which would just bog a newbie down (public static void main(String args[]), anyone?).

    -Spiv.



    [ Parent ]
    one thing (4.00 / 1) (#68)
    by timmyd on Thu Sep 06, 2001 at 04:37:39 PM EST

    i've talked to a few people that use python and have not experienced other languages like a lisp. in python given some situation they would write code like this:


    for item in mylist:
         read_some_info(item.age)



    instead of something that you would learn in a functional-like language:


    map(lambda item: read_some_info(item.age), mylist)


    while i think the first is much easier to read is this simple case, i think you simplify things in the long run when you think like the person who writes number two. maybe haskell and python would be an interesting combination to show someone two extremes but i don't know how much i would use haskell out of learning.

    [ Parent ]
    Another thing about your one thing (none / 0) (#79)
    by spiv on Thu Sep 06, 2001 at 11:15:58 PM EST

    A handy equivalent in Python 2.0 and later for maps such as:

    new_list = map(lambda item: read_some_info(item.age), my_list)

    is to use a list comprehension:

    new_list = [read_some_info(item.age) for item in my_list]

    Which is arguably more intuitive. I really don't know if it is, I'm too far removed from a beginner who's never seen functional programming to judge, but I suspect it is.

    -Spiv.



    [ Parent ]
    strong vs weak and dynamic vs. static typing (none / 0) (#64)
    by Rainy on Thu Sep 06, 2001 at 03:26:40 PM EST

    You should be careful not to mix these up.

    Correct me if I'm wrong, but this is how it goes:
    Weak typing: "3" + 2 gives you 5
    Strong typing: "3" + 2 gives you error

    Dynamic typing:
    a = 5; a = "my string" #legal
    Static:
    int a = 5; a = "my string" # Error! a is an int.

    Imho, typing should be strong and dynamic, like it is in Python.
    --
    Rainy "Collect all zero" Day
    [ Parent ]

    correction (none / 0) (#66)
    by timmyd on Thu Sep 06, 2001 at 04:23:43 PM EST

    Correct me if I'm wrong, but this is how it goes: Weak typing: "3" + 2 gives you 5 Strong typing: "3" + 2 gives you error

    weak typing will generally give you an error. maybe you are thinking about PHP, which will let you do some weird things like that.

    [ Parent ]
    php, perl? (none / 0) (#87)
    by Rainy on Fri Sep 07, 2001 at 03:01:14 PM EST

    Won't perl do the same, too? What exactly is weak typing, then and how is it different from strong typing?
    --
    Rainy "Collect all zero" Day
    [ Parent ]
    Strong vs. weak typing (none / 0) (#124)
    by jacob on Tue Sep 25, 2001 at 04:25:58 PM EST

    What exactly is weak typing, then and how is it different from strong typing?

    Nothing like replying two and a half weeks later ...

    Strong vs. weak typing has nothing to do with what the result of an expression like "2" + 3 will be -- that's a misconception. Strong typing refers to a language that determines the type of a variable -- that is, the set of values that flow into it -- before the program runs. By contrast, in a weakly-typed language, the language simply checks at run-time to see if a value is being used incorrectly. So a better illustration of the difference would be that in a strongly-typed language in which the semantics of + doesn't allow strings to be added to numbers, the expression "2" + 3 generates an error at compile-time (or at least before run-time: an interpreter could have a type-checking phase before interpreting a given program and just refuse to even start if the type-checker finds an error), whereas in a weakly-typed language, "2" + 3 generates an error at run-time when the program actually tries to do the addition.

    This is actually not the preferred terminology anymore: strongly-typed languages are usually called simply 'typed safe languages' and weakly-typed languages are 'untyped safe languages,' and a third category of 'untyped unsafe languages' exists where the values' types are never checked at all, even when they are used. Most assembly languages are in this category.

    Technically, there are also 'typed unsafe languages' where types are checked before run-time but checking types doesn't guarantee that you won't use a value in a way it shouldn't be used. Also technically, all typed, safe languages have a "type soundness theorem" that proves that any program that the type checker passes cannot possibly misapply a value. Haskell and ML have such a theorem proven for them. However, many languages we consider typed and safe, such as Java, actually don't have a type soundness theorem proven for them, and some typed unsafe languages, such as C and C++, actually have informal safety guarantees anyway (as long as you stay away from certain features).



    --
    "it's not rocket science" right right insofar as rocket science is boring

    --Iced_Up

    [ Parent ]
    Maybe Python (4.20 / 5) (#41)
    by neuroman on Thu Sep 06, 2001 at 04:39:11 AM EST

    Is it important what is your first language ? I found in one of Fowlers book something like a university professor saying that the students which where getting in programming with Basic, where unable (or with great difficulties) to properly understand and use OO concepts. I started with Basic and I feel I'm OK with OO.

    Howewer, if would be to teach my son programming I would start with Python! Why? First it's object oriented, it's simple, it's powerfull and then it force you to properly format your code, something wich will be handy latter for any programming language.

    I would stay away from anything functional (unless it is already passionate about one domain (like math)) and it needs some programming skills to help him in that specific area. I don't argue the power of the languages like Lisp, Prolog, SmallTalk but those languages have to many particularities, and I'm sure latter on will get the poor people some real hard time understanding other languages.

    Pascal was my second language, but let's be serious that was 15 years ago, the scene is different now, now would be maybe Oberon or Eiffel.

    Howewer learning a programming language is only 10% of the problem, learning how to think is the most difficult job, and after lot's of years of learning I fill that I'm closer but I still need a lot of effort to be there.

    Any way I wish him good look! If there wouldn't be the passion and I would have a chance to start again, I would try to be anything else than programmer :)

    /Remus
    "One must still have chaos in oneself to be able to give birth to a dancing star." [ Friedrich Nietzsche ]
    BASIC (none / 0) (#54)
    by davidduncanscott on Thu Sep 06, 2001 at 10:12:10 AM EST

    I think it was Werth who said that BASIC programmers were "brain-damaged". Of course, that was back in the days of GOSUB 120 and PEEK 32705 and stuff.

    [ Parent ]
    Resolve/XXX (4.50 / 2) (#47)
    by MicroBerto on Thu Sep 06, 2001 at 07:48:00 AM EST

    Although I wasn't a total beginner when coming to college, I still have to go through the entire Software Engineering set of courses to learn to program the "right" way.

    Here at The Ohio State University, it is done using Resolve/C++, which is basically a modified form of C++ that is used to properly teach templates, instantiation, objects, and such.

    The best part, in my feeling, are the extra comments that come along with the parameters, telling client what is "preserved", "altered", created (forget the keyword on that one), and destroyed.

    After I got over the "I'm too cool for this formal comments bullshit" attitude, I ended up actually liking it a lot, because I always knew what was going on! Check it out if you're interested, our Open Source group also makes Resolve Linux distribution CDs.

    Berto
    - GAIM: MicroBerto
    Bertoline - My comic strip

    Its not the language its what you do with it... (4.71 / 7) (#52)
    by bil on Thu Sep 06, 2001 at 08:46:47 AM EST

    Personnally I lernt to program with FORTRAN77, and have since moved on to lots of other languages. FORTRAN has advantages as a first language, such as the type system and declaring variables (not necesarily obvious ideas if you've never programmed before), without some of the nastier bits of other languages (pointers for example).

    This is entirely incidental to why it was such a good first language to learn however.

    Its real strength was we had a really good project to undertake in it (a simple image processor for astronmical images, I was studying Astrophysics). This is (IMHO) the real secret of learning a language, have something solid to do with it, somthing that, when you've finished, you can look at and say "yep I can use that for my real work". This gives you a sense of having achieved somthing usefull, as well as encouraging you to keep on at it and not just get bored and walk away (somthing I've done with several languages I've tried to learn "just for fun"). After all any app you use regularly can always use just that one extra feature and if you wrote it yourself then its easy to start adding stuff (eventually you end up with bloatware but hopefully by then your good enough at the language to redesign from scratch the Right Way(tm)).

    Writing any non trivial (not the same as complicated) program in mainstream language will teach the basics of programming far better then any amount of "messing about" in the best designed teaching language.

    All that said I dont think you can understand computers without at least a passing knowledge of assembly. But then understanding how computers work isn't really important for a beginning level programmer.

    bil


    bil
    Where you stand depends on where you sit...

    I agree 100% (3.00 / 1) (#58)
    by a humble lich on Thu Sep 06, 2001 at 12:58:55 PM EST

    I had almost the same experience. I learned on f77 because I started a group and we needed to integrate PDEs. Based on my experience the most important things are to have a real problem that is interesting and needs to be solved, a knowledgeable person around to answer questions, a good book for all the other questions, and a lot of good examples.

    I'm sure that this method can lead to all kinds of bad habits if you are not careful, but I will say that whenever I've tried to learn a new language without a clear project to work on I have been unsuccessful.

    [ Parent ]

    Right on... (2.50 / 2) (#61)
    by Mad Hughagi on Thu Sep 06, 2001 at 01:36:06 PM EST

    I first started programming a little bit when I was a kid with Basic, but after that I fell out with programming for about 10 years.

    In my first co-op job I was required to write programs for satellite dynamics analysis - and FORTRAN77 was the natural choice. It was slow moving at first (I hadn't thought about programming for a long time), but since then I've done a lot of programming and I've managed to pick up a lot of other languages, so I would have to say it was a good starter. It's simple and mathematically straightforward (what more can you ask for!).

    Mind you at school now they make us take computational courses (I'm in physics). We had to use VB in the first one (yuck), but in the second one our prof let us use whatever we wanted! It was great. Programming courses without the manditory explanation of how to program are sweet like honey.

    I'll throw my 2 in on FORTRAN77 though. Too bad it's not on the poll ;)
    HUGHAGI INDUSTRIES

    We don't make the products you like, we make you like the products we make.
    [ Parent ]

    It's both (4.00 / 1) (#63)
    by Rainy on Thu Sep 06, 2001 at 03:19:13 PM EST

    There's no doubt in my mind that some languages are easier to learn that others. A cryptic language with an obscure syntax and many rules and special cases will likely scare students off. I think python, ruby or smalltalk are much better first languages than assembly, c++, COBOL or perl. I believe that getting the big picture is very important vs. getting bogged down in nitty gritty details: if you start by writing something useful to you in python, for instance, a personal address book and you may not have any idea about pointers, polymorphism, etc but you will have overcome the biggest hurdle of programming: getting something useful DONE. I think there's 2 things that a great first language should have: firstly, it should be easy to pick up and do something useful and working in it; and secondly, there should be a smooth progression from simple first program to more serious projects that may have some performance requirements, use some classes here and there, etc. While there are many languages that meet the first requirement and many others that meet the second, there are only very few that meet both equally well: again, python, ruby and smalltalk. Python is perhaps more preferable because it's more mature, there's more books and libraries, and it's more readable, but any of these would be good. A good second language would be C/C++ or Java, if only for employment opportunities. If you don't want to become a professional programmer just yet, you can stay with one of those first languages and keep writing great useful software quickly and easily.
    --
    Rainy "Collect all zero" Day
    [ Parent ]
    Project is far more important though (none / 0) (#82)
    by bil on Fri Sep 07, 2001 at 05:44:51 AM EST

    There are some languages that I would steer clear of if I was trying to teach programming to somebody (assembly, forth, intercal etc) but not so much because of problems with the language themselves (I'm a big fan of forth) but more because they are very different from mainstream languages, learning to think in forth dosn't make learning C (or fortran or smalltalk or whatever) easier. Teaching transferable skills is quite important when so many mainstream languages are so similar. But I would still say that coming up with a good project is far more important, if the pupil WANTS to learn programming she will learn far more effectivly then if she sees it as just another class to try and scrape a decent mark in, and is far more likely to take her enthusiasm further and continue studying programming once the course is over.

    Working out how to pass on this enthusiasim for programming is the hard bit, but for my money giving them a good, usefull, acheivable, clearly defined, extensable, project is the way to go. In this field things like address books, CD catalogues and most other projects you find in programming books dont cut it (if I wanted an address book I'd go to the store and buy one, cheaper and far more portable then anything on a PC). Somthing that can only be effectivly done on a computer, and cant be done better by preinstalled software is more likely to enthuse the pupil (writing a basic text editor is pretty pointless if you are using emacs or vi or whatever to do the coding, because nothing the pupil does will ever be as good, and they'll know it). Basically something the pupil is likely to use even after the class is over.

    So yes the language you teach is worthy of consideration, but really its only 10% of teaching, enthusing the pupil to the subject is the other 90%, and the easiest way to do that is with the project.

    bil


    bil
    Where you stand depends on where you sit...
    [ Parent ]

    May be, but.. (3.00 / 1) (#88)
    by Rainy on Fri Sep 07, 2001 at 03:16:50 PM EST

    As for the project - I think there should be only one simple rule here: the project should be something the students wants and needs. I personally made a time management system, a diary program, a frontend to cdrecord, and an mp3 player (in the sig). The other thing is that a student should have a reinforcing feedback - his efforts must be rewarded constantly. If you start by learning assembly or C++, the problem is that you're working on something and you don't have a feel for what the complete program will be like. In other words, you may be writing some low-level procedure that writes data to a file, but you don't have a ready program that could use that procedure, so it sort of hangs in the air. It'd be much better if a student could whip up a 20 lines program that *works*, if only in a very primitive way, so he could tweak an existing working program.

    At that point the student can open up the source file, add several lines and see program's functionality improve, which prompts him to make further improvements. Working on some small part that will later on fall into place and work wonders is too much to ask from a newbie, if you've already written something similar that you can picture how it works and write separate components with relative ease.

    I don't know what the percentage split here, 10 to 90 or 50 to 50, but I am sure that making a wrong choice here can mean the difference between the student going forward or giving up completely.

    Give them a language that's easy to pick up and scales up well, and tell them to work on something they want - and most will have fun and eventually become programmers and will be ready to take on more obscure and complex languages, in a few years.
    --
    Rainy "Collect all zero" Day
    [ Parent ]

    So, Chip... (none / 0) (#53)
    by fluffy grue on Thu Sep 06, 2001 at 10:05:13 AM EST

    I guess you guys already ruled out MUF/MPI, huh? ;)
    --
    "Is not a quine" is not a quine.
    I have a master's degree in science!

    [ Hug Your Trikuare ]

    MUF and MPI (Slightly OT) (none / 0) (#67)
    by CrayDrygu on Thu Sep 06, 2001 at 04:24:12 PM EST

    MUF and MPI are probably the worst things you could ever show a newbie programmer! =) MUF (for anyone reading who doesn't know, it's a Forth-based language) makes enough sense if you think about it long enough (or take enough mind-altering substances), but it's still bass-ackwards, and MPI is just crazy. I've managed to do some useful things in each, but I can't even understand my own code anymore...

    [ Parent ]
    I held my nose and voted for Python... (4.50 / 2) (#55)
    by avdi on Thu Sep 06, 2001 at 11:25:31 AM EST

    ...because it's the worst programming language to learn in, except for all the others.

    I taught myself programming in REXX, (because it was what was available) which I now remember almost nothing of. I moved from there to C and C++. In the end, it really doesn't matter what language you start in; if you truly want to learn, you'll learn the principles regardless. If you aren't motivated, no language will ever work. The main advantage a teaching language can have is to have as few "gotchas" as possible; the fewer headaches the student has to deal with, the less likely she'll be discouraged and give up.

    This is why I (reluctantly) pick Python; despite the glaring faults that Python has (particularly in it's half-assed OO-support), it *is* a simple language; one in which there are clear rules that you can usually count on. The main problem I have with Python as a teaching language is that it teaches student's they have to hold the compiler's hand to create an OO program; which is hardly intuitive.

    (What's he talking about, you ask? Simply the fact that, just like in Perl, you have to explicitly declare the 'self' or 'this' pointer in instance methods; and then you have to use that pointer religiously to get at the current object. This is the sort of behind-the-scenes busywork that the interpreter should take care of; and is reminescent of libraries that attempt to support OO in straight C. While it's /techinicaly/ OO, it's hardly a good beginner's introduction to OO. Languages that truly support OO, like Smalltalk, Ruby, and (to a lesser degree) Java and C++, take care of these kinds of frustrating details behind the scenes)

    I have a whole list of other gripes about Python, but none of the others are as applicable to it's use as a teaching language. Few other languages besides BASIC provide as simple and straightforward a syntax as Python. And Python would certainly teach better habits and concepts than BASIC. Even Ruby, in almost all ways Python's superior, is probably a bit too complex for the newbie. (Although my current programming student (my wife) thinks that Ruby code is more readable than both Perl AND Python). And anyway it's more mature and more widely available than Ruby. It also has an interactive shell mode, which is a wonderful aid to learning a language.

    Yup, Python's the way to go, for now.

    --
    Now leave us, and take your fish with you. - Faramir
    re: self keyword (none / 0) (#62)
    by Rainy on Thu Sep 06, 2001 at 03:07:09 PM EST

    If you assume it implicitly, then how does interpreter distinguish between instance variables and other variables you could use in the class? Last time I checked, no language could read programmer's mind. One of the principles python built on is that explicit is better than implicit: if a variable is an instance variable, it must be easy to glance on the code and say that it's an instance variable. IMHO, this is one of the things that make python great.
    --
    Rainy "Collect all zero" Day
    [ Parent ]
    I figured someone would bring that up... (none / 0) (#70)
    by avdi on Thu Sep 06, 2001 at 05:02:49 PM EST

    Different languages tackle it differently. C++ and Java simply assume that if the variable isn't localy scoped, look in the class's data members for a variable by that name. This is admittedly ambigous, and occasionally confusing to new programers.

    In Ruby, like in Python, there's no need to declare variables before their first use; so the language needs a different mechanism to distinguish instance vars from locals. Ruby distinguishes the different scopes that it searches with different prefixes; if a variable starts with a letter it's a local; if it starts with an '@' it's an instance var; if it starts with '$' it's a global, and so on. This keeps things nicely unambigous.

    That said, if distinguishing between locals and members were /really/ the reason for this design choice of Python's than I wouldn't have any problem at all with it. It fits into Python's philosophy well to make the difference as unambigous as possible; and saying "self.foo" is certainly about as unambigous as you can get. The problem is, you still have to spoon-feed the compiler by explicitly declaring the "self" argument. This, to me, is the reverese of the principle of least surprise. If I were a newbie, I would have a hard time understanding that I /had/ to declare this magical argument when defining a method, but then I must subsequently pretend that argument doesn't exist when calling my method. The "right* way to do this, IMHO, is to mimic Java/C++ and make "self" a reserved word which always points to the "self" object when used from within a method. I.E., make this legal:


    # crappy indentation is K5's fault, not mine
    def MyFunc(foo, bar)
    self.foo = foo
    self.frob(bar)
    ...


    --
    Now leave us, and take your fish with you. - Faramir
    [ Parent ]
    Possible explanation.. (none / 0) (#89)
    by Rainy on Fri Sep 07, 2001 at 03:31:55 PM EST

    First, a warning: I feel out of depth here, I don't know much about OO internals of python, I just gathered some bits from comp.lang.python and mailing lists.

    Anyway, passing self argument works very cleanly in the sense that you can pass some real instance as the first argument instead of self. Another point is that it doesn't have to be self, you can do def func(s, arg1): s.arg1 = arg1. It was perhaps a consideration that in small script people may want to use s. instead of self for brevity, while in larger programs people may prefer to use more readable and explicit "self". By the way, I think I've seen this question being asked on c.l.p. and someone gave good answers but I can't find it now on groups.google.com. If you want, you can ask this again. Okay, now I checked FAQ and method meth(self,a,b,c) can be called as x.meth(a,b,c) for some instance x of the class in which the definition occurs.

    In fact, here's the complete answer to your question in faq: Why must 'self' be declared and used explicitly in method definitions and calls? Um, okay, I looked at it and it doesn't address why self has to be in the list of arguments..

    Incidentally, I think that using $ and @ and @@ in front of variables makes programs less readable and, dare I say, perl-ugly? :P
    --
    Rainy "Collect all zero" Day
    [ Parent ]

    Thanks for the answers... (none / 0) (#92)
    by avdi on Fri Sep 07, 2001 at 05:10:31 PM EST

    ...I didn't expect someone to go to that much trouble for me! :-)

    Anyway, passing self argument works very cleanly in the sense that you can pass some real instance as the first argument instead of self
    I'm not sure what you mean by that. Do you mean as well of saying foo.bar(x) I can also say bar(foo, x)? I'm not so sure that's a good thing... there's nothing to be gained that way; it's just a way for people to cheat and write procedural code in an OO language. Why would anyone want to?
    Um, okay, I looked at it and it doesn't address why self has to be in the list of arguments..
    ...and that's precisely what I don't like. Again, I really don't mind having to explicitly reference self (or s or this or whatever). I do object to having to put it into the argument list. Come to think of it, isn't allowing users to call the 'self' pointer anything they want against Python philosophy? What if I named the 'this' variable someone_else or input or something?
    Incidentally, I think that using $ and @ and @@ in front of variables makes programs less readable and, dare I say, perl-ugly?
    Well, to each his own. To be honest, I did wince when I first saw @@var, and I still think it's ugly. On the other hand, I never really objected to that element of Perl; I find that it doesn't detract from readability as much as some of the other elements of perl. It's the lengthy dereferencing in Perl that gets to me: $$${@{$foo->{bar}}[${baz{buz}}]}. Anyway, the FAQ entry you so kindly pointed me to makes the answer quite clear:
    When classes were added to Python, this was (again) the simplest way of implementing methods without too many changes to the interpreter
    Simply, classes were (originally) an addendum to Python; not an innate feature. And this was the easiest way to code them. So the reason boils down to laziness. Not that I fault Guido for doing it the easy way; after all, I've never written a programming language myself. But it is laziness if, now that Python has matured and has a sizable community, nobody bothers to fix this misfeature in the next year or so. Fortunately, it looks like Guido is not afraid to break backward compatibility in future versions in order to do the Right Thing.

    --
    Now leave us, and take your fish with you. - Faramir
    [ Parent ]
    Re: thanks for the answers (none / 0) (#100)
    by Rainy on Sat Sep 08, 2001 at 01:09:32 AM EST

    I'm not sure what you mean by that. Do you mean as well of saying foo.bar(x) I can also say bar(foo, x)? I'm not so sure that's a good thing... there's nothing to be gained that way; it's just a way for people to cheat and write procedural code in an OO language. Why would anyone want to?

    Well, one thing that comes to mind is mapping a list of different tuples of form (foo, x) to bar. There probably are other reasons, as well.

    ...and that's precisely what I don't like. Again, I really don't mind having to explicitly reference self (or s or this or whatever). I do object to having to put it into the argument list. Come to think of it, isn't allowing users to call the 'self' pointer anything they want against Python philosophy? What if I named the 'this' variable someone_else or input or something?

    It seems too, but perhaps Guido wanted to give a bit of freedom here so that you could call it just 's' for small scripts. It's just like from module import * - it's frowned upon but it's a time saver for small scripts and such. One of the philosophy pointers of Python is practicality beats purity. Anyway, I can only guess here, if you want the real solid answer, ask on c.l.p.

    Simply, classes were (originally) an addendum to Python; not an innate feature. And this was the easiest way to code them. So the reason boils down to laziness.

    Well, that's partly true, but then again, laziness is a *good* thing, when you're being lazy about fixing some minor problem and instead focusing on far more important stuff, like polishing libraries or adding list comprehension, etc. Besides, this self keyword can be handy 'cause you immediately see this is an instance method, otherwise you may need to scroll up to see if it's inside a class or inside another function. Explicit beats implicit.
    --
    Rainy "Collect all zero" Day
    [ Parent ]

    Re: thanks for the answers (none / 0) (#111)
    by avdi on Mon Sep 10, 2001 at 11:04:38 AM EST

    Well, one thing that comes to mind is mapping a list of different tuples of form (foo, x) to bar. There probably are other reasons, as well.
    Assuming list contains our list of tuples:

    result = [foo.bar(x) for foo,x in list]

    No need for the ugly procedural form.

    One of the philosophy pointers of Python is practicality beats purity.
    No, no... that's Perl you're thinking of! ;-)
    Besides, this self keyword can be handy 'cause you immediately see this is an instance method, otherwise you may need to scroll up to see if it's inside a class or inside another function. Explicit beats implicit.
    Well, once again, I don't object to that; I think it fits Python's intent well. It's declaring it in the parameter list that bugs me. Anyway, I think the FAQ made it quite clear that the reason for having to declare it in the param list was simply because that was the easiest way to code it.

    Lemme know when this thread bores you, and I'll shut up ;-)

    --
    Now leave us, and take your fish with you. - Faramir
    [ Parent ]

    re: thanks for the answers (none / 0) (#113)
    by Rainy on Mon Sep 10, 2001 at 05:30:02 PM EST

    Assuming list contains our list of tuples: result = [foo.bar(x) for foo,x in list] No need for the ugly procedural form.

    When classes were introduced, list comprehensions weren't in yet.

    One of the philosophy pointers of Python is practicality beats purity. No, no... that's Perl you're thinking of! ;-)

    No, that's an official line from "python philosohpy page". In perl, practicality beats everything - readability, clean design - in python, it only beats purity. Besides, this self keyword can be handy 'cause you immediately see this is an instance method, otherwise you may need to scroll up to see if it's inside a class or inside another function. Explicit beats implicit. Well, once again, I don't object to that; I think it fits Python's intent well. It's declaring it in the parameter list that bugs me. Anyway, I think the FAQ made it quite clear that the reason for having to declare it in the param list was simply because that was the easiest way to code it. Lemme know when this thread bores you, and I'll shut up ;-)

    No, I'm talking about definition itself! If you see def func(self, blah) you know it's an instance method, if you see def func(blah), you know it's not, if self was assumed implicitly, you would not know which it is. You may say that this is not a big deal, and you're of course right, but adding that 'self' there in arguments is no big deal either! Besides, the FAQ lists ease of design as only one reason. And even if this admittedly small advantage wasn't considered during this decision, it would still apply :-). Not tired of the thread at all, it's quite interesting.
    --
    Rainy "Collect all zero" Day
    [ Parent ]

    I think ruby got that one right (none / 0) (#93)
    by klash on Fri Sep 07, 2001 at 06:55:39 PM EST

    Incidentally, I think that using $ and @ and @@ in front of variables makes programs less readable and, dare I say, perl-ugly?

    I completely disagree: the punctuation-determines-scope is one of the things I like best about ruby! Knowing the scope of a variable is important, and I think the random conventions people invent to encode the information into the variable name are much worse (mVar and m_var, yuck!).

    Here's a perfect example (and an extremely common one) of how punctuation makes for more readable code:
    def initialize(foo, bar, baz)
       @foo = foo
       @bar = bar
       @baz = baz
    end

    I don't think there's anythin inherently evil with variable punctuation: perl uses it sub-optimally, IMO, for 3 reasons:

    1. Every single variable has punctuation. This makes the language more prone to looking like line noise. The punctuation should convey extra information, and the most common or uninteresting case shouldn't require any.
    2. It conveys information that isn't too interesting, and is largely redundant: when are you going to use the '+' operator on arrays or push a value onto a scalar? The array vs. scalar is much easier to determine from context than the scope of the variable is.
    3. $var[0] is part of @var. what was he thinking?


    [ Parent ]
    Agree that it's cleaner than perl (none / 0) (#101)
    by Rainy on Sat Sep 08, 2001 at 01:19:08 AM EST

    But I think self.variable still looks cleaner and more readable. As per your example:
    def initialize(self, foo, bar, baz):
     self.foo = foo  self.bar = bar  self.baz = baz There are some other things that bug me about ruby. One thing is that end keyword wastes a line; @@var looks way odd and ugly, I dont' even think perl has something like that; there are some syntactic sugar-things, special cases like a = %w{ ant bee bar } vs. python's a = "ant bee bar".split(); attr reader thing: class Song\n attr_reader :name, :artist, :duration vs. Python's def __init__(self, name, artist, duration): . In other words, almost every thing that was wrong with perl and python fixed, ruby only fixed half-heartedly.
    Of course, take this with a grain of salt the size of hotel Ritz - I only read Ruby's tutorial for a few hours and haven't written anything in it. I'll probably go back to it when I feel that I learned all of python that I wanted to learn. I'm still quite a bit short of that. I just looked at smalltalk and ruby a few days ago just to have some idea about them..
    --
    Rainy "Collect all zero" Day
    [ Parent ]
    "$var[0] is part of @var. what was he thinkin (none / 0) (#102)
    by Mr.Surly on Sat Sep 08, 2001 at 01:57:13 AM EST

    $var[0] is part of @var. what was he thinking?

    Makes perfect sense to me:

    $var[0] returns a scalar. Scalars start with '$'.

    @var[0] returns a list. Lists start with '@'. Incidentally, this is a "slice", as it will return multiple values if multiple indexes are supplied.

    You can use @var[0] in lieu of $var[0], as long as you're aware it's a list (with one element) instead of a scalar, which means it may behave strangely depending on context.

    [ Parent ]
    Oh, by the way.. (none / 0) (#90)
    by Rainy on Fri Sep 07, 2001 at 03:34:29 PM EST

    It's odd that you bring up such a minor syntactic thing when there are real, ugly, confusing warts in python as well. One is that 3/2 will give you 1 (even worse considering the whole cp4e thing). There are other things but that's what I can think of right now.. Although, this is being worked on and may change in py3k.
    --
    Rainy "Collect all zero" Day
    [ Parent ]
    I forgot to mention Squeak (none / 0) (#56)
    by avdi on Thu Sep 06, 2001 at 11:54:35 AM EST

    While I still think Python's the way to go in most cases, I've recently become intrigued by the teaching possibilities of Squeak Smalltalk. Squeak is an amazingly interactive way to learn a language; You can create instances of graphical objects, and twiddle with their code and attributes in real time. Every change you make immediately takes effect. Every single element of the system makes it's own source code available to be read and modified. Every change you make is saved from session to session, automaticly. Revision control, at a per-method granularity, is innate in the system.

    The aspects that this adds to the process of learning is fascinating. Rather than going through the frustrating write, run, re-write, re-run, re-write, debug, re-run, etc... cycle, every time losing and rebuilding all state you might have set up for testing purposes, you can interactively add to, modify, and excercise your classes. Developing changes from a process of carefully setting up a lengthy, precarious list of scripted events and then letting it fly and hoping it doesn't blow up; into a process more like molding playdo: molding, prodding, testing, and re-arranging objects in real time, without ever losing your cumulative state. This method of learning might be especially good for visually-oriented thinkers.

    On the other hand, Smalltalk syntax is just plain bizarre. Oh well, you can't have everything.

    --
    Now leave us, and take your fish with you. - Faramir
    Not enough info (5.00 / 2) (#57)
    by reeses on Thu Sep 06, 2001 at 12:49:01 PM EST

    There are a lot of possible applications for a "first programming language". A simplification that will enable me to write a short comparison:
    • Introducing programming to people who would otherwise not program (kids, non-technical workers, etc.)
    • Introducing software engineering concepts
    For the first group, I would probably say,"VB". They'll get immediate feedback with their development, there are a zillion books available, and any competent programmer can pick up the basics in half an hour to act as a mentor. Most of these applications will be permutations of "Click on this button to hear a fart sound," but the point is to get people to program, not to produce applications for a broad audience. These people don't care about OO, functional programming, dynamic binding, or multiple dispatch.

    For the second group, I'd probably do what a large number of rigorous CS departments do: teach Scheme first. Give them a copy of SICP and have them go at it. On other days, I'd probably say dylan or haskell.

    Everything I needed to know I learned in Pascal (4.00 / 1) (#60)
    by kostya on Thu Sep 06, 2001 at 01:29:32 PM EST

    I'd have to vote for Pascal, even though I have an awful opinion of it now. But I'm a professional programmer now, so I'm probably miffed I didn't get an edge by learning C a while back.

    We started with BASIC on Apple IIes. That was really a hoot and very good. I did some really impressive stuff with Apple BASIC, including a graphics drawing of the SDF-1. I then made a shotgun version that shot the picture full of holes (you could even set the spread and amount of shot to use). So BASIC has plenty of room in it to do very cool and powerful things.

    That being said, BASIC also teaches you how much it sucks when a language isn't designed right. A lack of structured programming and being forced to use literal addressing (i.e. goto 75) will teach you everything you need to know about structured programming--i.e. mainly that you really need it.

    I then went on to Pascal. What a treat after BASIC. I could use lower case!! I really liked having actually functions and procedures. Pascal also was useful in exposing you to advanced concepts while shielding you from a lot of hard stuff. Pascal has pointers, and I think it is a great way to learn them (as opposed to C and C++). I took the advanced placement tests in Pascal and did very well. All of my "classical training" to date is from those high school courses.

    That being said, I wouldn't want to program in Pascal now. I like OO too much.

    I think it is actually a good idea to learn the language generations in sequence because you will run into them all out there in the "wild". So I'd recommend BASIC, then Pascal, then something else (an OO of your choice--probably Java). You need to know how to think in structured languages so when you have to write in C you aren't handicapped by constantly saying, "Oh, my gosh, there aren't any objects!" The ability to think in, and understand, each of the paradigms is vital to a successful computer science career. Learning just one is a good way to get pidgeon-holed early on.

    Learn something really simple first followed by a language that teaches pointers in a safe way. I'd stay away from any language that doesn't have a "string" data type (C and in some ways C++). Working with character arrays and pointers right from the start is very frustrating to a complete newbie (us old farts love the challenge, I suppose).



    ----
    Veritas otium parit. --Terence
    Two ideas no-one has posted yet. (none / 0) (#77)
    by static on Thu Sep 06, 2001 at 07:37:32 PM EST

    Although it's very very limited as a programming language, learning RPN at some early point is useful. This is because it teaches how stacks work and introduces a new way of thinking about arithmetic.

    I'd also like to know if there are any programmers whose first language was Icon. I know in years gone by there were people whose first language was SNOBOL, but SNOBOL is showing its age (it is almost as old as FORTRAN) and programming language technology has moved on a lot from there.

    Wade.



    Ada (none / 0) (#78)
    by sudobash on Thu Sep 06, 2001 at 10:21:32 PM EST

    Everyone talks about strong typing and yet no one mentions good 'ole Ada. Probably because nobody knows Ada, but when it comes to strong typing and a picky compiler, nothing beats Ada. Ada is provides the maximum in safety. You are forced to explicity and verbosely state everything you mean. Probably beneficial for newbies.

    My ideal learning path (4.66 / 3) (#81)
    by yigal on Fri Sep 07, 2001 at 01:41:19 AM EST

    Another interesting aspect might be the ideal learning path, instead of the ideal language. Assuming the student wants to learn how to program, instead of how to make a program (a big difference imo), there are many aspects that should be considered.

    Before I went to univ, I knew how to make a program. When I left, I knew how to program. My ideal learning path is closely modeled after how they taught me.

    First of all, let them start with 'Hello World'. Write the program in the most barebones editor (no syntax highlighting, no built in compile-options, no debugger...), compile it, run it. This teaches them several aspects of a program already, such as: the difference between source and binary, the different steps of a build process, etc.

    Then introduce the basic types. Ideally, this is done in a strongly typed language. This can teach them that for a cpu everything is just a collection of bits, which they have to interpret all by themselves. Show them how the compiler will help you interpret them correctly. Don't annoy the student with pointers yet.

    After this the basic looping structures, blocks and stuff like that, are a good candidate. Be nice, include GOTO and let the student jump into a loop ;^)

    Procedures, routines, functions (depending on your lang) are also a good candidate. Since pointers are still absent, this is a nice point to explain the pass-by-value part. (And if your lang supports it, maybe also pass-by-reference). When the routines are introduced, the student can be banged over the head with the dangers of global variables, the interesting aspects of shadowing and maybe even recursive calls.

    By now, programs are becoming more and more complex. If you're a lenient teacher, you can tell them about the better editors. Give them syntax highlightin, give them compiler shortcuts, be nice. I would not yet include debugging, since stdout is your friend for ever.

    After this, its time for structured types. Arrays, lists, sets, dictionaries, records, whatever. Data suddenly can be packed in logical units. Wow. Remember, still no pointers.

    At this point, the student will know almost all the basics of procedural programming. Let them run around for a while, whooping with joy, and then assign them a recursive datastructure. Watch them scratching their heads, banging their heads against the monitor and cursing the compiler.

    Yup, it's time for pointers.

    Personally, I hate pointers. I spit on their semantics, I cry over every notation I've found so far (char* ? &i ? yuck yuck yuck. Pascal's ^ is pointy, but using the same character for pointer declarations and dereferencing is idiotic as well), but not knowing about pointers is like not knowing the capital of Assyria. You never know when you need the knowledge.

    Show your students the cool thing about pointers. Then let them play around until they dereference unknown data, leak memory, overflow buffers, free their structures before they're finished; let them assign addresses instead of pointers to numbers, be cruel. Then, take the weeping student apart, give them a cup of really strong coffee (If they want to become programmers, they should learn to drink coffee. Unless they want to work on Qt/KDE) and tell them in a friendly, soothing voice that real, modern languages don't need pointers anymore. And that some real modern languages don't need FREEing either.

    And then tell them about OO.

    For me, it took some time before I really appreciated OO. Once you grok it, it's so natural, you can forget that for others it's like: 'duh?'. Start with 'enhanced records', and slowly introduce inheritance, polymorphism, virtual thingies etc.

    From this point, the path branches almost infinitely. As for myself, I took the opportunity to sniff at as many languages as was possible. It positively enriched my understanding of computers. But that's my problem.

    Well, that's about it. Given this path, not many options are available. C is a bad choice, since it has no OO. C++ is better, but I do not like it. Python and Java are great, but the GC and the lack of pointers are a serious shortcoming for a language to learn programming in. I'd never advise Perl to anyone, SmallTalk has the same 'shortcomings' as Python and Java (and the added shortcoming that there are no basic types).

    So personally, I'd shout Borland ObjectPascal! dcc is a cool compiler, even though Kylix is a very bad environment for beginners (again, beginners that want to learn how to program). Ada might also be nice, but I don't know if there is an Ada version that supports objects. I only used it procedurally (is that a word?).

    Languages like Lisp, Prolog and Haskell don't fit in my proposed learning path at all. Sorry.

    YDD
    .sigmentationfault

    Ideal first language? (2.66 / 3) (#83)
    by Anonymity2 on Fri Sep 07, 2001 at 06:16:05 AM EST

    English would be a good start.

    Different Types Of Language For Different Needs (5.00 / 1) (#85)
    by Wildgoose on Fri Sep 07, 2001 at 12:45:32 PM EST

    For scripting use Python to teach indentation and other good practises.

    Tcl/Tk has a syntax that can be explained and understood in its entirety in as little as 2 minutes. And a powerful, simple GUI.

    For Systems Programming use Eiffel - the most complete OO language available.

    How's about Postscript? Unlike other stack-based languages you get to see a result immediately.

    Programming using Higher Order Functions in a functional language is an important progression. Scheme is commonly used as a drop-in scripting tool thanks to "Guile", and better still is Haskell which is properly typed, and has pattern recognition, etc. Probably particularly appropriate for mathematicians as well. (And btw, "monads" can supply state).

    Which is best? It depends on what use it will be put to in future. A professional programmer should start with Eiffel, "Design by Contract" and provably correct programs. They should also learn functional programming to improve their programming further. As to the rest, what use will they put it to? That should be the best guideline.

    Awk (none / 0) (#86)
    by spring on Fri Sep 07, 2001 at 01:45:20 PM EST

    These guys use awk as their language for undergraduate AI programming, which just goes to show, I suppose.

    Perl, of course (2.00 / 1) (#91)
    by asiufy on Fri Sep 07, 2001 at 04:15:52 PM EST

    If you want this person to be more than a coding droid, teach Perl. Otherwise, go with Java.

    it really depends on what they want to do. (4.00 / 1) (#94)
    by Espresso_Boy on Fri Sep 07, 2001 at 07:14:03 PM EST

    first, start off with something easy to understand, like logo, or python. then move on to a little harder stuff, 6502 or z80 assembly or some such nonsense. if they seem to be progressing quite well, then move on to something evil like perl or intercal. if they still have the will to learn to program, then go to a normal language like c, or let them choose a langauge. it doesn't really matter. at this point they should be skilled enough that they can understand what they want to do and how to do it with whatever language they choose, and they will be able to learn on their own without much trouble. the important thing is to let them do whatever they want to do, in a way that makes sense to them. if they don't understand OOP, then don't cram it down their throat. if a concept is unclear, then move on to a more promising area. if they have the will to learn to program, then they will gain the necessary skills eventually.

    ML should be good (none / 0) (#103)
    by Xone on Sat Sep 08, 2001 at 08:29:10 AM EST

    At the Dept. of Computer Science at the University of Copenhagen they use Standard ML (Moscow ML) for their new students - I haven't used it much yet, but so far it looks simple and easy to learn.

    Re: ML should be good (none / 0) (#109)
    by crazyscot on Sun Sep 09, 2001 at 09:48:47 AM EST

    The University of Cambridge also teach ML as a "first" language. When I was there, one of the dons explained that while incoming students have a wide range of programming experience, almost none of them have done anything functional before, which levels the playing field somewhat.

    They then go on to teach Java a few months later. Personally, I think that while Java makes a decent OO teaching language, it's a bit hairy for the folks who are having their first imperative experience.

    [ Parent ]

    What i did, and regret (none / 0) (#108)
    by isobars on Sat Sep 08, 2001 at 05:32:29 PM EST

    Well ive been 'learning' to program for about 3/4 years now and reckon had i taken a better approach i would be doing some pretty neat stuff.

    Being relatively young i started copying my dad and messing about in QBasic.. had a laugh, i would recommend anyone to start programming it as its easy to get hold of and very intuitive.

    I then made the fatal mistake of chosing Visual Basic.... which was great and i still use fairly often, i enjoyed it immensley as i could very quickly write windows apps which sometimes even did what i wanted! However, it got me into bad habits. I never comment my work because its such an easy language to understand, and i didnt 'learn' it, i self-taught, which got me into awful programming habits.

    I tried learning JAVA a while ago and was way out of my depth... i just wasnt ready for the difference and it taught me that i needed a fresh start

    so once my current visual basic app is finished, im off to learn PERL because i am and its good as any. so perhaps this might be a good starting language.

    Woah though having said all this, VB is great for certain things, but i think spending too much time in it can be lethal, especially if you dont know any other languages. MY advice: go and ask someone or take the advice other people are suggesting, then go on a course to learn how to program PROPERLY.. self teaching is good but a first language should be TAUGHT.



    He who laughs last... Hasnt Seen the Cattle Prod
    Well, (none / 0) (#121)
    by stfrn on Fri Sep 14, 2001 at 07:54:05 PM EST

    i also started with basic on a 64 and move up to Qbasic. and then jumped right into java. sure, i didn't understand it all right away, but it was fairly easy to move to, and the advanced topics aren't that hard to do crudely.

    "Man, I'm going to bed. I can't even insult people properly tonight." - Imperfect
    What would you recomend to someone who doesn't like SPAM?
    [ Parent ]
    maybe java (none / 0) (#122)
    by d0g1e on Mon Sep 17, 2001 at 04:23:20 AM EST

    http://alphaworks.ibm.com/tech/robocode
    I haven't tried it myself (166mhz 16mb ram :( ) but it may seem usefull to people who want to learn Java the fun way.

    Language is unimportant... (none / 0) (#123)
    by Rizzen on Mon Sep 24, 2001 at 05:23:34 PM EST

    The important thing is the process. The problem nowadays is that no one wants to take the time to learn anything: they just want results.

    For this reason, VisualBASIC is very popular. Anyone can open the IDE, drag a few buttons around, type a few lines of gibebrish (that the IDE completes for you) and have a working program. However, they have *no* idea what they just did or why it works (and this is the way the Computer Science degree works at the local Univ).

    Personally, I'd like to see a programming class where the first month is taught using a plain-jane text editor and command-line compilers. Learn how a computer works, the logic behind programming, and how to write using the language being taught. Then, move onto the IDE where things are automated a little for you.

    The language taught isn't too important so long as it is structured, doesn't have 10000 ways to do the same thing, and has a clean syntax. It all comes down to how it is taught, and how the programmer learns.

    Me, I'd like to see a simple language like Pascal taught first (to get the basics, the structure, the thought process down). Then assembler to learn how a CPU works, why certain algorithms are better than others, and other low-level details. Then move on to the high-level languages like C++/Java/Delphi. Starting with a visual language, IMO, is completely bass-ackwards, pointless, and self-defeating (too bad the local univ doesn't feel that way).

    --
    Linux: the OS for those who hate Windows.
    FreeBSD: the OS for those who love Unix.
    -- unknown
    ----- The years of peak mental activity are undoubtedly those between the ages of 4 and 18. At age four, we know all the questions; at eighteen, we have all the answers. -- unknown
    My List (none / 0) (#125)
    by fujisan on Thu Oct 11, 2001 at 11:25:25 AM EST

    As always, there is divided opinion as to what language. But first however, since comp. science isn't a very exposed course in high school level (not in australia anyway), I think students probably need to learn what the course involves and the art of programming before anything really.

    After the theory is settled, there are 3 languages which you may consider: 1) Java 2) Visual Basic 3) C. Most Australian universities tend to choose C since they argue this is perhaos the most useful and one of the harder langauges for beginners to adapt to. The logic behind starting off with C is that if they can handle this, most other languages are easy in contrast. One lecturer used to say "C is like driving a manual car, if you can drive it, an automatic car is no challenge".

    Personally, I would leave assembly and stuff off the list since that is somewhat in my opinion more architectural stuff and that hould really be in the Engineer's dept. not software development itself.

    Anyhow, I went into a university that started off with Java (odd considering almost all the State's unis opted for C instead). Anyhow, it was argued that by the uni that OO is more useful nowadays and gets your thinking on track. On hindsight, this wasnt such a wise choice by the uni. Other unis used C as a kind of measuring stick as well, doing a kind of "weeding out" process along the way....it was a way of getting rid of the "i'm in for the money sake or i'm in coz i like computers" as opposed to geniune students who had a passion and really understood what comp. science was all about. Java also brought many bad habits into programmers and created a major migration to C problem. Many who handled java couldn't get the hand of pointers and malloc, and stuff of that sort. Java however was good in the fact that it tught the OO paradigm.

    With C, it was a great "weeding out" tool for the other univerisities and also a good language to start off with, provides more skill than java would. It gives studenst a real idea of the stuff which they would be faced with and also good depth. C++ would also be easier to adapt to later on.

    Visual basic is more or less good for a more IT approach, better for Info Sys students. It's rather like java, too "automated" like the garbage collector and pointers and stuff like that in java. The DRAG AND DROP is just stupid since students don't really know what is going on anyway. Do this as a last resort.

    It would be good if students had studied either QBASIC or perhaps even Visual basic prior to coming into the course. It gives an idea of what they can expect of CS without going into mich depth. QBASIC isn't very good really since you really can't do much with it.

    In order of preference go with: C, Java, Visual Basic...even Perl is good.

    Good language to teach beginners? | 125 comments (124 topical, 1 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!