Teaching programming h;lp

I'm going to teach programming to somebody who's going to study it more formally in a year, but wants to be learning part of it in the mean time.

What SIMPLE, CLEAN, STRUCTURED language would you recommend me to use for teaching? Please, refrain from language wars as this is not a fanboy thread but a serious question. Before yuo mention it, I'm not going to start with either Python or Ruby because they're too complex and get too much in the way, and no, I'm not stupid enough to start with Java because a radical OO language (and a crappy one at that) with a shitty enterprise API is not the best either.

I'm thinking Pascal. As much as it sucks, it has strict/anal types (it's better to start anal than to start easy-going and botch it), simple yet not messy syntax, simple stdin/stdout input and output to play with (that's all I'll need), and none of the complexity of OO. Yet it sounds so useless. But I don't know of other languages that meet these requirements.

>>1
From what you just posted, I seriously doubt you're even old enough to teach anything properly.

C

Since you're just going to do simple calculations, string manipulation, and possibly file IO, Pascal will do (although so will the other languages you mentioned). Then if the person you're teaching is moderately smart and understands all that within two weeks, you should probably introduce objects to them, and if you picked Pascal you could go with Delphi or Free Pascal. CONCLUSION: It doesn't matter which language you pick, as long as it's not ancient (>>3).

>>4
Pascal is older than C.

>>5
Yeah, but modern Pascal dialects at least have good built-in string support, which is nice if you don't want to have to mess with objects or memory management yet.

Python.

Real men use C style strings. 

>>8
C style strings are utterly braindead. They combine the inconvenience of arrays with the performance characteristics of a linked list.

>>9
You combined not having a clue what you're talking about with being a fat ugly virgin.

php

>>10
i fucking lol'd.

>>10
Not guilty on both charges, but otherwise a decent burn.

C string are retarded though. What is supposed to be so great about them?

>>14
They're simple, straightforward and transparent. Furthermore, it's trivial to teach how to write your own string handling functions. It also illustrates how there's very little in C that's "magical" and what you couldn't build for yourself. (varargs is one, primitive types is another, main() is one more, I can't think of any others.) This is very useful in a teaching context, because it lets the students think of strcmp() and the like as just something that someone has already written for them.

It's not like >>1 is going to be teaching complicated data structures beyond, say, the humble doubly-linked list or anything, right?

>>15
With C you already have a==b instead of intcmp(a,b), might as well go all the way and get a language with proper string support.

>>14
Needing only a single byte of overhead for strings of any size, I guess. Thirty years ago when you only had 5 bytes of memory this might've seemed like a good idea.

C-style (null-terminated) strings are retarded. Many operations on them are O(n), which would be O(1) with Pascal-style strings. Imagine what strcat does in the general case:

* Find length of string A (O(n))
* Find length of string B (O(m))
* Allocate lenA + lenB (depends on allocation scheme)
* Copy string A (O(2n))
* Copy string B (O(2m))

Strings that start with a size byte or int (Pascal-style) reduce the first two to O(1).

Furthermore, null-terminated can't contain anything that might contain nulls, which you'll know is a useless if you've ever operated on binary data. And for the finishing touch, it's a lot easier to overrun the lenght of a null-terminated string (forgot that null? whoops!), leading to stupid flaws and possible security vulnerabilities.

The reason we're stuck with a default string library that's gay like this? The PDP-fucking-11. Awesome 1970s Batman!

Pascal-style strings are simple to implement. All they are is:

typedef struct {
  int length;
  char *array;
} string;
Or you could use a sane system language that uses them by default, like D, or even C++'s STL.

>>17
>The reason we're stuck with a default string library that's gay like this? The PDP-fucking-11.

Yeah. Because there was no way to implement pascal style strings on that machine, amirite? You motherfucking toolbox.

>>18
Copying null-terminated strings was faster than Pascal-style on a PDP-11. And thanks to that, we're still stuck with it several decades later.

Don't believe me? Plenty out there: http://www.google.com/search?q=C+null-terminated+strings+PDP+11

Learn to google, moron.

>>19
>Copying null-terminated strings was faster than Pascal-style on a PDP-11.

OH SHIT DUDE, HOW CAN TAHT BE.

>>20
>>19

So I'm >>1. I like the discussion on C strings (BTW: C strings suck, sure they are simple, but they just can't do O(1) operations, come with an ugly standard library, and are ZERO TERMINATED, which means they are NOT BINARY SAFE), but that won't help my student.

I plan on teaching him C (or at least wait for it to get teached to him because it will), and of course he'll learn to deal with them, but right now I'm worried about teaching programming, not a particular language, so I want it simple and purist.

>>2
I'd bet I'm older than you, also working on real software and making more than you do.

>>7
Python is a great language (RUBY IS TOO, WEEABOOS, SO JUST SHUT UP), but perhaps some features of modern languages may bite to people who are learning programming and can't be bothered to deal with classes, exceptions, bound objects, iterators, range objects, etc. yet.

>>8
Real men master C strings, after which they realize how crappy they are and how a waste of time string handling in a low-level language is, so unless they need the best performance, and especially if they're getting paid, they move on to higher level languages equipped with PCRE.

>>9
Uh, no. C strings suck because they can't hold any character, have O(n) strlen and most operations, and come with a crappy standard library to handle them.

>>11
I've considered PHP. It's simple, and has a more common syntax than Pascal or Python. The problem is it's so loosely typed I think it might do bad. I want to differentiate data types before we can introduce variant types, automatic conversion, and why is "" == 0.

>>15
The same could have been done with length-based strings. Actually, I had a great idea, but never bothered to implement it: to have a struct like:

typedef struct {
int size; //Allocated size, increased or decreased logarithmically
int length; //Character size of the string; always <= (size >> 1) - 1
wchar_t chars[]; //Struct hack to hold characters
} string;

then move the pointer so that it actually points to character 0 in chars. This way you keep the array access to characters, but string functions (which should be the only ones to know about this structure) can access size and length, and deallocate/reallocate the block if necessary (base is the address of string.size). You get a O(1) macro for strlen. As an extra utility, the functions always guarantee that the string is terminated by a zero so that, when not using binary strings, read-only C string functions and functions which expect C strings will work.

>>19
Copying null-terminated strings was faster than Pascal-style on a PDP-11. And thanks to that, we're still stuck with it several decades later.
I still can't believe that. It doesn't make sense, unless perhaps if all your strings are "Hello world!" and shorter.

right now I'm worried about teaching programming, not a particular language, so I want it simple and purist.

I'm surprised no one has mentioned Scheme yet. Beautiful language, very pure, very simple, no gargantuan, poorly implemented standard lib that you have to learn before you can do anything nontrivial, and yet still very powerful and expressive.

Oh yeah and it comes with a free book designed specifically for teaching: http://mitpress.mit.edu/sicp/

>>23
>no gargantuan, poorly implemented standard lib that you have to learn before you can do anything nontrivial

Translation: you can't do anything with it

>>17 >>22
Oh I call bull on this shit. All operations on strings are O(n). There's a library called Ropes (that comes with the Böhm GC), which provides for crazy things like an O(1) strcat (since it just makes a string head structure which contains the two other strings in a left-right reference fashion), but even Pascal-style strings require a O(n) strcat. Don't believe it? Copying everything from string A and string B into string R depends on the lengths of string A and string B. Therefore, O(lA+lB), which is O(n); indeed, O(2lA+2lB) would be O(n) as well. Habeeb it.

And before the peanut gallery chimes in about "BUT BUT BUT TWICE AS SLOW!", allow me to introduce you to cache miss latency. On a minty-fresh Intel processor, one L2 cache miss is going to cost you far more (that is to say, ~200 cycles on a 2.4GHz P4 at minimum) than a few redundant strlen()s over strings of lengths typical to an average C program! Profile first, kids. Better yet, use a memory profiler like cachegrind before you scream omg slow. Bestest yet, remember that the best optimization is that which moves a program from a non-working state into a working one!

For what it's worth, no Pascal-like language implementation that I know of uses a rope-like data structure for strings. Ropes are ropes and strings are strings.

All that said, perhaps it would be a passable idea to teach programming with something simple that >>1-san can understand. Like BASIC for instance, or Python -- both of those are wonderful for simple and trivial examples that don't need to grow up into real programs.

Oh, and I forgot: O(1) strlen? Precious. How about you pass the length in an auxiliary parameter if that really matters so much? Likewise for buffers that may contain a null byte. '\0' isn't actually a character in most of the encodings in use on systems where the word size is a multiple of 8.

Requiring that a string type be "binary clean" is retarded in any case and speaks of a background where strings are commonly abused to represent arbitrary byte-oriented data, when strings are more properly a container type for _character_ data. (Hint: ASCII and Unicode 0 are the NUL codepoint, which is a control character commonly used as a terminator or invalid character.)

>>25,26
Nice job aggressively defending an utterly retarded design decision. You still haven't given any reason not to use length-prefixed strings though.

>>25
All operations on strings are O(n)
Oh I call bull on this shit. strlen is O(1). The rest are, of course, at least O(n).

About the cache, how does that affect accessing one dword that's always in the same address (at least as long as you don't resize the string), and not affect reading the whole string till the damned final zero?

Besides, C strings are not just a matter of performance, but functionality. They are not binary safe. Useless for binary data, which is something you're supposed to deal with often in a low-level language such as C. C strings, therefore, fail hard and inflict double damage.

Finally, would you care to explain why, if C strings are so great, every modern language, almost always built on C, offers Pascal-style strings? I can't think of a modern language that goes OMG is that a zero!? End of string lolol.

>>27
How about tradition. They've been in use for, oh, longer than like 98% of 4chan's user base has been alive. Also, string operations on zero-terminated strings are a couple of instructions shorter than their length-prefix equivalents (i.e. the test against zero can be folded into the load from memory), which as any embedded system developer will tell you does matter. Plus, length-prefixed strings either limit you to 256/65536 bytes, or you end up wasting one or three bytes most of the time.

>>28
Oh very well. All operations that need to touch the string data proper, or if you prefer, all operations on zero-terminated strings.

The cache bit is to remark about how optimizing for omg one loop over a string is pretty much insignificant on today's processors, where fetching extra data from non-cache storage (or even the L2 cache) can be slower in relation to the processors' core speed than memory used to be in the early nineties. Certainly, grabbing the length value from a negative offset in the string pointer is quick. But let's face it: how many strlen() operations do you actually have that aren't immediately followed by accesses to the string contents?

Binary safety I took a stab at in >>26. Nutshell version: silly pythonist, strings are for characters and buffers are for bytes.

>>29
String copy certainly is not a couple of intructions shorter than the length prefix equivalents. You need to do a compare operation on every byte as opposed to straight up copying with memcpy or similar.

Null terminated strings still exist BECAUSE IT'S FUCKING IRRELEVANT. YOU TALENT AMPUTATED NON PROGRAMMERS ARE THE ONLY ONES BITCHING ABOUT NON ISSUES LIKE THAT WHILE SMART PEOPLE CARE ABOUT THE STUFF THAT REALLY MATTERS.

IN A SITUATION WHERE THE STANDARD STRING FUNCTIONS REALLY COST SIGNIFICANT PERFORMANCE, THE PROGRAMMER WILL JUST USE SOMETHING ELSE, BECAUSE HE'S USING GOD DAMN C AND NOT SOME SHITTY SCRIPT LANGUAGE WHERE EVERYTHING HAPPENS MAGICALLY AT SOME MAGICAL HIDDEN PLACE INACCESSIBLE FROM YOUR HAPPY UNICORN AND RAINBOWS PROGRAMMING ENVIRONMENT.

NOBODY, I REPEAT NOBODY GIVES THE SLIGHTEST SHIT ABOUT HOW MANY CYCLES IT TAKES TO COPY A COMMAND SOMEBODY JUST ENTERED AT A PROMPT INTO SOME OTHER BUFFER. GET A LIFE YOU HORRIBLE ANIME FAGGOTS.

[/cruise control]

>>22

Hi, OP. Microsoft implemented the string hybrid you describe (where the pointer is to the data but the length is just before it in memory) in their "basic string" - or BSTR - in COM.

See http://blogs.msdn.com/ericlippert/archive/2003/09/12/52976.aspx

Actually there's very little difference between copying a C string and a Pascal string. Think about it - one involves copying bytes until you hit a zero, and the other involves copying a certain number of bytes. That goes for the PDP-11 as well as more modern architectures.

>>29
Plus, length-prefixed strings either limit you to 256/65536 bytes, or you end up wasting one or three bytes most of the time.
Lame... Just an int, for 4 GB strings. OMG 4 bytes. Just two characters.

fetching extra data from non-cache storage (or even the L2 cache) can be slower in relation to the processors' core speed than memory used to be in the early nineties
True, but something as hot as a string's length should be in the cache.

Binary safety I took a stab at in >>26.
Still, a good feature to have. Makes implementing stuff such as network protocols easier, interfaces cleaner.

>>31
Lol angry Internet man. BTW, nobody's defending scripting languages (bash, csh, etc.) here.

>>32
Looks good (don't know about string operations though); too bad it's not portable.

>>33 & >>29
Ever written x86 asm?

Pascal-style involves moving the number of bytes (or words if you want it to go faster) into ecx, then doing a rep movs* (the stos* family is stone-age). This is as fast as you can possibly get.

Null-terminated strings on x86 (and every other modern architecture) involves a comparison per byte (or word if you get fancy). Does this sound faster to you? Because it's a lot slower.

Binary safety I took a stab at in >>26.
Okay, as someone who mucked around often with binary data in C, allow me to say a hearty *FUCK YOU*.

Why the fuck should I have to write all this extra gay shit or drag in yet another library when C's standard library should have supported it properly in the first place? So instead of having one set of functions that operate on all data, now we need TWO sets?

You'd make a piss poor SE. Reinvent the wheel much?

Erm, here's another overwhelming reason why char* C strings are completely useless today (I don't care about thirty years ago): Unicode. People confusing a byte and a character in 2006 is an utter failure. Of course Pascal strings are just as useless in this respect.

>>1
if you're willing to give up anal types (which i'd personally recommend) TCL seems to be a good choice.  the syntax is very simple, and a handful of common commands can be learned in minutes, but the language is powerful enough to do pretty much anything he'll likely want to use it for at this point.  it can also be run interactively, allowing for instant gratification.

this lets buddy learn the basics of program flow and I/O without  having the language itself distract him.  once he's figured that out, then you can worry about the boring ugly stuff like data types and null pointers when you teach him C.

>>1
My first formal course in programming used OCaml (with no reference to the object-oriented aspect), and that's a pretty good learning language, which, unlike Scheme, has types (a nice way to understand complex data structures) and a standard library that makes it usable in real life as well.

It allows for a mixture of different programming styles that may get somewhat unsavory though, if you teach too many (the same problem Perl can suffer from in the hand of beginning students). So Clean might be a better idea, although you can't call it a popular language.

real men learn AMN based languages such as B, where strings are arituary. (or not really defined as such)

But then i'm not sure you cna call it a programming language as such? It models specifications but allows you to go all the way through towards an implementation.


Obviously, i'm not recommending this as a first language.

I begun on Visual Basic (omfg) back when i was 15. I may not be so experienced as you guys, but this language is 'decent' as a starter, provided a few things:

You guide the guy in reguards to programming style. Bad habbits are really easy to pickup early.
Teach him its not THE godly language (as i guess many people who started on xxxx language seem to appraise it?).

I'd recommend VB for the following reasons:
using m$'s IDE, the student can learn a few points about GUI design as well.
Being able to make a GUI will actually encourage a newbie programmer to think before they code. (Most students will visuallise what they want their app to look like, thus they will think of what is presents, thus what data is required, thus what operations etc.etc.  teaches refinement and synthesis.)
The language is easy, sequential and has many premade functions he can use.
   Being sequential, they'll find programming in it easier. Obviously there are many sequential type languages, indeed every language supports sequential programming. But you do not want to overwhelm the poor kid with OO and what not.
   Having premade functions will allow the kid to branch out and 'explore' what he can do. (Oh look, i've made this cool command line notepad thing... maybe if i integrate this with the inbuilt networking protocols i could build me a chat client etc etc)  Of course, once the kid gets teh basics down you can ask him to make his own versions of functions.

I guess VB can be loosely typed, but just enforce 'option explicit' and stuff.


And no, im not calling VB a godly language. I much preffer more elegant languages, but the kid has to start somewhere. And why not start off where many have? Theres many guides tutorials etc...

Plus, being able to make a GUI, the kid might take a liking to it. Also introduces him to event driven programming later on.

In first year in uni, they started us off on Haskell. They focused on teaching us the basic principles of programming, and the basics of teaching us how to solve problems programmatically.
Haskell may be obscure, but it certainly does re-enforce certain values.

C is decent for technical minded people, but for beginners? The technicallity of it all may overwhelm him.

Of course, the final decision is actually the kid's....  But remember to consider how experienced he is, how much time he wants to dedicate, and how enthusiastic he is?

An enthusiastic kid wouldnt mind diving straight into C, where as a mildly interested kid, will only be frustrated by C, calling it ancient, archaic and completely useless. (but of course they'll learn its use later on).

After starting the kid off on some language and teaching him the basics, i'd probably try to teach em Java. (*gasp*)
Despite all the haters of Java, its a decent language to teach Object Orientation in. I'd have to say its rather important to instill the concepts of OO early on. So that they have the advantage of being able to solve problems both ways and selecting the right method where appropriate.
I guess if they started on C, they could move on to C++ , but then theres the whole thing where the kid could be lazy and default back to programming in (sequential) C more than using OO principles.

If the kid likes electronics, why not introduce him to a basic FPGA? or an AVR or ARM board afterwards? Tho i doubt many will take a liking to such low level things.