I didn't get around to the Pascal part of the Class. The entire class was pretty pointless though. They didnt get to C till the third year? wtf?

Just to clarify; I'm looking at this from a business stand point: I have a language already (NASIC: adding {..} syntax would be trivial) and using something like Qt to create a flow chart generating IDE based on QtScintilla is (seems to be) very doable.

So I'm basically doing a feasibility study

Keep the comments coming, cookies still up for grabs!

Edit: and the age range I'm looking at is early high school, middle school.

Edit2: and integrating with a 3d engine is doable too: Irrlicht for example. Lots of details to work out there of course (api to expose and what not).

I'm not sure if theres any room for something like this. Maybe if its "that much" better than what else is out there. Also, if you haven't beaten RealBasic on its language features, you need to go a little further

I have a "Basic" language brewing in my head (or did, I havent worked on it in ages), based on a mix of RealBasic and some perl idioms (no perl syntax though ).

If you think back to the past, things like LOGO were very popular, where you "programmed" a "robot" (what was it called, a turtle?) around the display.

As for flow charts, skip them. I don't think many/any kids will even grok them, unless you can simplify everything down into cartoonish levels of simplification.

edit: If I was to try something "educational" it would probably be a drag & drop oriented event based wysiwyg type program. With the ability to customize events if you happen to want to get into the code at all.

A general comment. The discussion in this thread will probably be moot, since in the end you have to do studies with kids themselves. Armchair arguing or planning will definitely not translate well to the real world. So, don't ask us. Ask the kids.

Also, people consistently underestimate the intelligence of children, and instead feed them drivel that the adults think is 'basic' enough for them to understand, while they are actually capable of doing so much more.

In my opinion, give them C or C++ with allegro and STL and be done with it. In the end, it's not the language itself but the way it is taught that what will matter the most. And in that case, why start with something obsolete like BASIC, when you can just start with the end goal. I guess you could start with C# instead, to keep things modern, although doing manual memory management should be done at least once in one's life.

My main point is that there are many general purpose scripting languages that can easily be paired with a gaming library/engine to create a "beginner's programming environment." If that's basically all you are going to offer, then you might as well stick with main stream stuff (e.g., Lua) and focus on selling a concept as opposed to your own labor.

[Edit: Basically what SiegeLord was saying.]

That said, to continue with my previous statements, I would think that the engine would have things like "entities" already built-in. One usage example:

You add a character to the level and in his properties you say he is neutral (enemy: false). Then you add a built-in event called onHit() and add a snippet of code like:

IF $attacker = $me THEN
  $char.enemy = TRUE
END IF

Of course most things would have natural defaults. So if you were creating a 2D platformer (assuming the engine supported that), you could just add baddies to the level and say this is a "flying baddie" and default movement would already be set. But by double clicking on an event, you could modify the flight code, etc.

The above example is not well thought out, so don't bother discussing the details of it. But that's the general idea of what I'm talking about:

Something that's basically visual, but with snippets of code that can be changed. That way the kid can quickly put stuff together in "level editor" mode but then do something crazy by experimenting with the code behind it.

And obviously if the idea is education (as opposed to production value), then you can limit yourself to some relatively small niche.

I think we had documentation. What I think I lacked was something simpler to start with, that I could see "work" as soon as possible. I got frustrated rather quickly from not seeing any real progress. Mind you I was mistaken for having ADD as a kid, which had much to do with my frustration, I had no patience or attention span.

Theres always an opportunity in something, its just a matter of the difficulty level in pulling it off.

edit: In my opinion, you need to provide something the kids can keep interested in. Allowing each kid to procede at their own pace.

My first real programming experience was in grade 10 with Turing and then in grade 11 with plain C (all taught at school). By the time my younger brother got to high school the school had started introducing kids to programming using Delphi. I remember he was so frustrated by all the 'magic' involved in his programs. The teacher was showing them stuff like adding a button and hooking up handlers, etc, but they never explained how any of it worked.

I still think that one of the most important things to keep kids interested is to let them have a feeling that they're creating something from scratch. Give them a 'main' function and say that it's the program entry-point. Let them see that if they put a print statement in main it will do something and then the program will quit. Let them see that they can put a loop in main to make the program keep doing something until a condition is met. Then tell them that that is how all computer programs work.

One of the biggest sources of encouragement is showing them how nothing the computer does is magic and that it's just varying levels of complexity built up using some very simple building-blocks.

Good point, I guess I should say all my points apply only to me any my brother (and people like me). Because people learn in different ways it's going to be hard (impossible?) to make a learning language that suits everyone. Like Matthew said above

Which type of person are you targeting?

I started out with GW-Basic maybe around 12 years old or so , the fact that I could draw on the screen was one of the coolest parts. I didn't stick with it too long and until I bought a book on C++ and found Allegro , a year or two ago I couldn't even imagine how to write graphics programs. Just prior to taking up C++ I was working on learning some Windows Script so I could re-parse some log files into a useful form and that got me hooked again. I plan to stick with it now and I spend most of my free time programming and studying math and programming. So don't think that a simple introduction to programming won't encourage anyone to take it up in the future. Of course I did the work of learning the GW-Basic myself but if I hadn't had the manual for GW-Basic that shipped with the computer I would never have known that I even found programming interesting not to mention enjoyable.

Which language should kids learn first? Well , it should be any language where they can learn only a few functions and a few syntax rules and immediately put something together with it to get a feeling of accomplishment and intrigue going. I would go with C/C++ (because you only have to learn a few things to get started using it , although this probably applies to a lot of languages) , maybe BASIC but I don't know what it's like these days , and a nice graphics library like Allegro to give some visual feedback to what's going on inside the program.

Like those ancient Borland C++ "programming environment"s we were instructed to download for free, and used in class and at home.

Though to be fair, when we switched to VB.NET (:() we used Visual Studio 2003, until they decided to switch to 2005 (a horrible decision, since their computers couldn't handle it).
We were of course advised to pirate it if we wanted to work at home

IMO, the first language should be C and/or C++. Partially because that's what I first learned and I loved it. They also offer a lower-level understanding of the program and offer more control, which for a beginner is useful in learning (you could even throw some assembly in there). C# would be my second choice because it's a very nice language to learn. D is a another nice language.

In grade 12 I took a grade 11 level computer science course. In grade 11 I didn't even know such a thing existed. I don't even remember exactly how it happened, but it probably paved my way to a career. The actual course used C/C++, with an emphasis on C++, and we used Visual Studio 6 (it would have been nice to use MinGW or GNU tools so that I wasn't reliant on Visual Studio for so long, but now that there's a freely available express edition it's not such a big deal).

In my high school computer science class the teacher did nothing more than assign chapters to read and examples to do. That's all he had to do. If somebody had a problem with something he would explain it, but mostly we did it ourselves. We're talking about HelloWorld and GuessTheNumber programs! If by grade 11 you can't follow simple instructions in a textbook without the teacher holding your hand then you're in the wrong class (and a lot were, but most still managed to get the credit). A lot of people complained because the teacher didn't do anything most of the time, but I preferred it. He stayed out of the way and let me learn on my own. It was great preparation for college.

While it might be possible to market, I wouldn't personally encourage it. If it's going to take a lot of work it might not be worth the time. A better approach, IMO, would be to write a textbook that was basically a tutorial for simple game design with something like C++/Allegro that provided the art and sound and walked them through putting it together to make simple games. However, I think jumping straight to game making would be extreme and it's more beneficial to learn about programming instead. I don't personally see high schools offering a game making course because learning to program would be a prerequisite and there is only so much time in high school. A WYSIWYG system doesn't really prepare students for the game industry (since things don't work that way IRL) so it would only be useful for fun (elementary school, perhaps?). Something event driven that's WYSIWYG sounds basically like Flash, which high schools already offer, so I don't really see this QBASIC venture as being successful.

QFT.

I think that a potential problem here is that you're asking a bunch of programmers what value they see in kids learning programming. I think it's pretty obvious that none of us are going to say "there's no value, forget about it" and, inevitably, most of us are going to find a reason to justify whatever route we took. Because objectivity is hard — really, really hard.

My personal experience is similar to Matthew's. I started at age 8 on an 8bit computer. When you switched it on, you'd instantly get a menu with four options. One was a calculator with variables and stuff that was essentially a stripped down version of the BASIC, another two went into BASIC in different configurations, and the fourth loaded other software from tape. So it wasn't really like an OS that shipped with a BASIC, it was a BASIC that shipped with the bonus feature of being able to load non-BASIC software. The manual that came with the machine had a full documentation of the BASIC language, and we had a pile of magazines with type-ins. I learnt from those. Everything subsequent to that is not really relevant to the question you're asking — i.e. what sort of thing we think should be first presented to spark an interest.

Maybe as a result of starting off in an incredibly simple environment on an incredibly simple computer, my interest in programming has always been trying to understand a system from top to bottom. The fact that the system I first tried to understand was an entire computer is neither here nor there. I think that whatever you present to the kids should have enough background functionality to allow them to express creativity relatively quickly (which, in my case, was provided by the line/circle drawing commands, text output stuff and keyboard input stuff) but not have so much hardcoded that the child cannot reach a point where nothing that is happening is 'magic'.

That all said, if you're really just trying to spark an interest then your system need not be an end in itself. If you implement some sort of simple game engine (and, please, don't do a side-scrolling tilemap game — they're about as relevant to today's children as introducing them to television production by making them record a three-set drama live to 425-line black and white tape) to start them with scripting, then make sure they can elevate as far as seeing your code for that engine and compiling it in whatever you used.