I have a friend who is a games artist, and he has started using the Virtools interface. It allows you to program with click & drag logic boxes & the like, as well as coding specific functions at a C/Java type level if you need to. He has knocked up some interesting little games (see them on www.playgen.com) and he has almost no prior programming experience.
Could be worth a look 
[quote]I always thought that Logo was just the best way to learn programming. Or at least, turtle graphics - the Logo language was a bit odd.
[/quote]
I took a class on Logo when I was in second grade. Truth be told, I didn’t consider it programming. The way I saw it was, you told the turtle what to do and it did it. i.e. More of a command prompt than true programming. When I started with programming BASIC (maybe about a year later), my Logo experience didn’t in any way help out. As far as I was concerned, I was starting fresh.
It wasn’t until much, much later (probably when I was 18+) that I heard other people describing Logo as a beginners programming language.
Logo is a fully featured imperative programming language with an immediate visual effect on its environment. You don’t necessarily need to control a turtle with a pen. Tanks with guns for example - I wrote a game that involved robots blowing each other up using a BASIC dialect on the ST once. Nothing graphical though.
But the immediate mode activity of turtle graphics helps people immediately understand what they’ve done. And if you reverse the control - allow the user to control the turtle directly and have it write out the instructions - you begin to see how to achieve what you want to do.
Adding things like a radar and goals would make it great fun.
But I really don’t think there’s a great deal of worth in a purely graphical programming environment. It won’t teach anyone programming at all.
Cas
Visual X3D ? An app showing a window where kids can drag and put black boxes and tie them together with lines (routed links) to send messages between each black box (object).
They could still create or extend their own black-boxes with a simple prog language Basic like.
[quote]Logo is a fully featured imperative programming language with an immediate visual effect on its environment. You don’t necessarily need to control a turtle with a pen.
[/quote]
I know that now. But as kid, it just didn’t sink in. BASIC felt a lot more like a “real” language that focused on “real” computer programming. e.g. First print “Hello World”, then write a calculator, then build a game of BlackJack. As opposed to Logo where you feel like all the work has been done for you.
[quote]Tanks with guns for example - I wrote a game that involved robots blowing each other up using a ASIC dialect on the ST once. Nothing graphical though.
[/quote]
That game is still around, believe it or not. As I mentioned earlier, IBM has updated it for Java. I think games like that can make someone want to learn programming, but I quickly came to the conclusion that it didn’t prove much about the actual capability of the programmer.
Zingbat, that’s something along the lines of how BlueJ works. Unfortunately, I have never actually seen a successful development environment that represents objects (and their connections) graphically. There’s simply not enough data to produce a good graphical representation, and even if there was, it would be difficult for the programmer to mentally connect the UI and the underlying object.
Property boxes work much better, as they are are merely a method for presenting the underlying data encapsulation. In addition, they don’t really attempt to deal with the hierarchical nature of code. Instead, they present each object as-is, and allow the user to navigate as he chooses.
I’m not sure why there’s an emphasis on programming with drag and drop anyway. Mostly it’s because the language is scary enough to look at (Java is one hell of an ugly looking language compared to nice simple BASIC code). Then OOP is scary because access modifiers really don’t serve to actually help anyone. And then there’s the fact that capital letters are mysteriously treated differently to lowercase ones. There are all sorts of things that have crept into Java to deliberately make it far harder than it needed to be. Just printing a line requires System.out.println(“Hello”); instead of print “Hello!” which is crazy.
Fix these things and you end up with something that works. Tie them in with some graphical objects which you can manipulate and you’ve got an environment which will allow people who want to learn to program to learn in safety and have fun, eg. 7yr olds.
Cas
Cas, it’s so much worse than that. Look at what you said:
[quote] Just printing a line requires System.out.println(“Hello”); instead of print “Hello!” which is crazy.
[/quote]
“Print? I don’t want to print - no! stop! I don’t have any paper in the printer!”
What you really meant was:
say Hello!
(MUDs, chat clients, and MS windows can handle you type a comand, then a space, then the arg, then hit enter. Why should anyone expect a language to require more? When they get to the point of wanting multiline output, they’ll do what we used to when I was ickle, and we were naive:
say Welcome,
say This is a program where you
say have to manually indent all
say your output
say
say …enjoy!
(actually, it was a side effect of basic that each line had to contain a complete command)
[quote]I’m not sure why there’s an emphasis on programming with drag and drop anyway. Mostly it’s because the language is scary enough to look at (Java is one hell of an ugly looking language compared to nice simple BASIC code). Then OOP is scary because access modifiers really don’t serve to actually help anyone. And then there’s the fact that capital letters are mysteriously treated differently to lowercase ones.
[/quote]
For formal teaching, I agree with you completely. As far as I’m concerned, the best path is to teach a traditional dialect of procedural BASIC (none of this QBasic or VBasic crud), then teach simple functional programing in C (which also can cover hardware control and the like), then teach Object Oriented development in Java. Each step in the ladder provides the perfect level of interaction for the student. i.e.:
Now if you just want them to be mathematicians, the path is much easier:
(Yes, I intentionally left out “???” and “Profit!”, so please keep those comments to yourselves. :-))
[quote]There are all sorts of things that have crept into Java to deliberately make it far harder than it needed to be. Just printing a line requires System.out.println(“Hello”); instead of print “Hello!” which is crazy.
[/quote]
FWIW, those things have not “crept” into the Java language. They were intentionally added to solve problems that are far beyond the capacity of a new student to understand.
[quote]Fix these things and you end up with something that works. Tie them in with some graphical objects which you can manipulate and you’ve got an environment which will allow people who want to learn to program to learn in safety and have fun, eg. 7yr olds.
[/quote]
I don’t think the point is to directly teach programming, but rather to get them interested. Klik 'n Play solutions can make a new programmer feel empowered, because they can produce impressive results in very little time. Contrast this to a complete programming language that takes time to understand the syntax and APIs available. The user will eventually have to do that anyway, but at least he’d feel like it’s something he wants to do and can do.
FWIW, specialized languages can also hurt new programmers. The problem is that they will feel that they have invested a great deal of time in learning a syntax and API structure, just to find out that those skills are useless for anything other than the intended task. This can actually cause new developers to stop programming, because they feel that they would need to start over if they wanted to learn another language. (Not to mention how intimidating most tool-chains are.)
That’s why it’s got to be limited in scope to achieving one thing only, and designed around that task. So a language that involves programming robots to blow each other up is a) fun b) teaching you how imperative programming works and c) can be completely forgotten about when you move on to a real language.
It’s got to be a toy to work!
When I was a kid I had this crazy battle tank toy that you could program with a keypad on its back. You programmed in angles to turn and distances to move, and you could get it to shoot its lazer and tip up an apple in front of grandpa. It was brilliant fun programming it to escape the kitchen, enter the living room, shoot grandpa and then scurry off.
That’s the sort of thing we need.
Cas
[quote]Cas, it’s so much worse than that. Look at what you said:
“Print? I don’t want to print - no! stop! I don’t have any paper in the printer!”
What you really meant was:
say Hello!
[/quote]
Heh. Another vestige command left over from the early days of programming. Keep in mind that when Kurtz and Kemeny developed BASIC, PRINT really did mean “Print to the printer”. Graphical TTYs were something that only the super-rich companies could afford. Not to mention that graphical TTYs were really just a way of killing fewer trees. They actually had fewer features than paper, since you couldn’t scroll back or use lines wider than 80 characters.
The use of a printer was why Dartmouth’s “Super Star Trek” game scrolled after every command instead of clearing the screen. This practice remained common in BASIC right through the 1980s, and finally died when graphical user interfaces began introducing users to the idea of scroll buffers. Sadly, that was right around the time when BASIC itself died. 
[quote]]
It’s got to be a toy to work!
When I was a kid I had this crazy battle tank toy that you could program with a keypad on its back. You programmed in angles to turn and distances to move, and you could get it to shoot its lazer and tip up an apple in front of grandpa. It was brilliant fun programming it to escape the kitchen, enter the living room, shoot grandpa and then scurry off.
That’s the sort of thing we need.
[/quote]
Again, that sort of toy won’t necessary make a connection in a child’s head. Instead of thinking “I’m programming a computer”, they’re thinking “I’m giving commands to my robot.” While the two are more or less the same, it does take some understanding of how computers work to realize that. OTOH, if you tempt them with the real thing (even if they cut and paste someone else’s code), then they will feel empowered enough to take programming much further.
IMHO you’ll have much much more success teaching:
Why?
Beanshell lets you start programming and doing nothing but writin imperative code.
Encouarge them to write longer and longer programs, then a project - THEN be nasty and get them to add features to each others projects. See them weep.
NOW you are at the perfect time to spring OOP on them, and suddenly…it all makes sense.
The great sin of OOP teaching IMHO is that so very many people merely teach the processes and ignore the reasons it was invented. I’ve had to re-teach people OOP plenty of times, and in each case as soon as I showed them the list of “things that go wrong” and “which bit of OOP was invented to prevent that” they find it easy.
Beanshell is conveniently both:
Cas…the name of that toy…was…
Big Traxx!
I used to LOVE that friggin thing! I spent SOOOO much time on that toy just trying to get the movements down “just so”. That and the Domino Rally construction set…
Me thinks it’s time for another discussion topic!
-ChrisM
blah^3*h (yes I do notice there’s an extra h at the end of your name :)), I very much agree. I know where I go to school right now, while C++ and Java are taught and a little bit of rambling about OOP goes on, they don’t actually teach good OOP programming. I don’t believe many people come out with their Major in CS having any decent experience with a real project that NEEDS it. The projects are always too small for anyone to care about what the fastest or most organized way to do things are. I think it should be more emphasized. I think I’ll have a talk with my professors about that…
Malohkan its a quite unsolvable problem. Most courses last a semester. Thats 6 months of say 2-6 hours of teaching each week. Here the student typically have to learn the basics of the language. To realy show the benefits of OO, several larhe projects are required, where the student are forced to reuse his previous implementations. There simply isnt enough time todo that in 6 months.
I first understood OO when I had an advanced OO course. The teacher was terrible at teaching, but he knew how to program. The first article he showed us what one named “Why extends is evil”, http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?post=825&lastpage=1#talkback
Before that course, OO had been the usual abstract animal enherits down to dog and cat. Nothing about composition and patterns. I think that student should patterns cause they give some good solutions to various problems and a good understanding of what OO realy is. Patterns can be used in any programming language and is therefore ideal for CS courses.
One professor at my uni taught multiple inheritance with the example of a lawyer. You see, laywers are humans, but they’re also rats…
I think you can do a good OOP course. It requires a bit of preparation on the part of the lecturer, but if you gave students two initial (reasonably complicated) codebases - one fully OO, one totally inlined and un-abstracted - and asked them to make various modifications to it, I think they’d pretty soon appreciate at least some of the benefits of OOP.
Just like SQL, I only figured out OOP after years and years on the job. Quite recently in fact - during Flux development.
Cas
yepp they are getting very popular and the biz model is sustainable in my view. happy gaming