Hmmmm, now this may be of zero interest to the OP, but I the appearance of yet another programming pedagogy thread has caused me to spawn a crazy idea.

Disclaimer:  This is probably a bad idea.

So what if one of the ways to institutionally teach beginning programming was to just institutionalize the way I learned how to program?  You set up an Ultima Online server.  Customize it to cater to macroing/botting.  So it's kind of like robocode, but more RPGish and with some obligatory grindy numerical crap that has to be done before you are actually good at the game.

First of all, make sure the students coming in actually want to play games, namely an RPG style game, and if they don't send them to the bland boring typical programming classes.

The first few days of class are spent familiarizing the students with the game.  At this stage the instructor is mostly an admin as well as a player that helps other players out.  The students/players are allowed to play the game with relatively weak characters that should nonetheless be able to handle some fun canned activities.  They should also have some harrowing encounters.  You know; teach them their limits.  During this time the students will ideally gain some kind of personal attachment to their avatars and become assimilated into whatever kind of token economy might be deemed appropriate.

I suppose I should mention that you can safely assume that the students haven't played this particular incarnation of the game and that you can safely used canned quests and such.  It will all be novel to them.

After the first few days of the students being the squishy mortals they are, show them the power of programming.  Have them use a simple easyuo script like this overnight:

top:
; Hide every 10 seconds.
event macro 13 21
wait 10s
goto top

By repeatedly hiding every 10 seconds the player's character will develop hiding skill.  Run this overnight and you will likely have 100.0 (maxed) hiding skill.  Now, hiding isn't an uber powerful skill that allows them to kill everything with the flick of a wrist, but it is useful.  This is good: you don't want to give everything away all at once.  Teach the students how to, in a pinch, run and hide, thus granting them invisibility to the AI mobs.  Given a low latency connection (school network?) and maxed hiding skill, they will be extremely hard for the AI to kill.  Now they are untouchable, but still poor at killing or very much else in the game.  That's good, they still have a reason to improve their programming skills.

Also, for reference, the less useful "hello world" script:

msg Hello world!$

Which makes the player's character say "Hello world!"
Yep. One liner.  The $ tells the computer to hit the enter key.

You're probably also glaring at that goto.  Heresy, isn't it.  But hey, goto is much easier to understand than functions.  It fits nicely with the idea of execution flow.  You can say that goto is horrible programming practice and hard to debug, and you'll be right, but the alternative is harder to teach at first.

At this point hopefully they've been using bandages to heal.  Hopefully they are also frustrated.  They have to move their mouse into their backpack, double click the bandages, then double click their character/healthbar every time they want to recover some precious hp. This just won't do.  So you have them write a macro to, on the press of a key, automatically find bandages in the backpack, use them, and begin applying them to self.  The solution looks somewhat like this:

hotkeyloop:
; poll for the key press.  It need not be only ctrl-shift-e.
onhotkey e ctrl shift
    goto heal
goto hotkeyloop

heal:
; Find a bandage.
finditem ZLF

; Use it.
set #lobjectid #findid
event macro 17

; Wait for targetting cursor to appear.
; If it takes longer than 2 seconds, give up.
target 2s

; Target self.
event macro 23

; done.
goto hotkeyloop

Hey, we have some branching and now the notion of variables.  The variables are #lobjectid and #findid.  They are builtins, and "set" is the assignment operator.  Teach it.
More gotos.  Deal with it.  It will get uglier in a bit, and that will probably be a good thing, ironically enough.

(Note: Last time I tried, onhotkey doesn't work with UO under Wine on Linux.)

Now for some magery.  They'll go from killing lowly rats and orcs to slaying dragons with this one.

top:
if #MANA = #INT
    goto cast
if #MANA < #INT
    goto med

med:
event macro 13 46
wait 4s
if #MANA < #INT
    goto med
if #HITS < #STR
    goto heal
if #MANA = #INT
    goto cast

cast:
event macro 15 41
target 4
event macro 23
wait 1s
if #MANA = #INT
    goto cast
goto heal

heal:
wait 1s
Finditem WKORQQD
set #LOBJECTID #FindID
event macro 17
target 2s
event macro 23
wait 1s
goto top

We start to see some if statements here, comparison operations, and a slightly more complicated program.
To be honest, I just grabbed this one from my old dusty collection of macros I've used at some point.  I have forgotten what WKORQQD is. event macro 15 41 casts energy bolt.  Other spells may be needed to level if the shard is set up differently.  Setting it up to keep it this simple is probably a good idea.  event macro 13 46 does meditation. This will train the auxiliary skills for magery too.
Maybe give them a skeleton program of this and possibly some bugs too. Fun with goto debugging.

For those that care, I haven't mentioned melee skills.  Those are harder to macro.  Just do magery.

You're still reading this?  Are you mad?

At about this point it's time to introduce EasyUO's subroutine feature, which is pretty much just functions.  Now they can ditch gotos.  Perhaps  switch goto loops out for while loops as the way to do a main loop. EUO seems to have most of the good structured programming constructs.
Before jumping directly into functions, it may be possible to goad the students into writing functions using goto primitives and thus teach low-level concepts like a call stack and a return address.  I'm not sure how much of a good idea this is.  I know I was writing functions this way before I know what functions were.  Then I learned, and sploited.

At this point they have some ?optional? assignments:
- There are nice builtin variables for things like #HEALTH.  EasyUO can also read messages displayed on the player's screen.  With these two things in hand, and a solid grasp of conditionals, control flow, variables, etc, it is possible to write a macro that does healing automatically.  No need to press a button.  It just continuously strives to keep the player at full health.
- Make another character.  A "mule" character.  Now make a macro to max out alchemy skill, so that the player can make potions.
- Make a macro that automatically chugs cure potions when the character is afflicted with the poison status.
- Make a macro that can max out tailoring/blacksmithy/carpentry/tinkering/mining on the mule character.
- Encourage classmates to share.
Welcome to teamwork.  Perhaps mandate that the students do all of these collectively as a class.  They will get first hand experience with the multiplicity of human programmers and how awesome it is.  Oh hey Linux Kernel, the might of mankind's giant programmer swarm is pretty cool huh?

Now perhaps we can get tricky.  Melee skills were ignored.  Perhaps this can be rectified.  Even though everyone is a mage just having maxed wrestling skill will be a valuable asset defensively.  Currently when a monster attacks them they get hit %100 of the time.  Maxed wrestling skill drops that to %50.  Alternatively, the student may opt to build a melee character (they should probably keep their mage, it's useful).
So how to max melee skills?
The macro-able way requires two characters to spar with each other until both are maxed out.  This is nontrivial.  The combatants will have to disengage when their partner is too low on health, or they will kill the partner and it's game over.  This may require the characters to move away from each other, and as such the macro must be vaguely aware of position.  Weapons degrade over time, so the macro will have to periodically equip a new weapon as old ones break.  The characters can heal themselves using the self-heal, but healing each other is considerably faster.  Heal self takes 10 seconds.  Heal other takes 4. Just how bad this is can be tweaked on server side (e.g. don't make weapons degrade over time).
At this point we can introduce the concept of finite state machines.  At some level most of these macros were just FSMs to begin with, but this is probably a good time to formalize the idea and begin exploiting it in earnest.  Writing this sparring macro as an FSM is probably a good idea.
This may also involve arrays.
It might also be good to mention the applicability of FSMs outside of this, such as in regular expressions.

Now if we really want to cement these concepts, we can have the students attempt to write AIs for their characters.  They'd probably be Player vs Player (PvP) or Player vs Mobile/Monster (PvM) AIs.  And by that I mean combat AIs.  The really nice thing about this is that the students will be able to replace a lot of their tasks in the game as a human being with things that their program can do.  They may even be able to run multiple AIs at once, thus multiplying their capabilities.  This realization and ability is quite an awesome experience.  It's probably doable in this setup too.  Of course, they'll probably need some guidance, and if fully autonomous AIs are too tough then there's plenty of room to expand on automatic healing/curing and construct a more robust part-man-part-machine kind of combat system.  Either way this is just damned cool.

That's about as far ahead as I've thought on this.

At one point my nephew wanted to learn how to do some EasyUO macroing to help him play UO.  My time was short, so in about 3 hours I taught him about 2-4 weeks of introductory computer science material.  He quickly realized this was more work than he thought it would be, and he seemed pretty wide-eyed by the end of the experience, but he did seem to learn and in a remarkably short period of time become something of a programmer.  So maybe there is something to this.

Notably, the topics covered by this will probably be different from a normal introductory course.  Finite state machines are covered, while user-defined types are not.  OOP is not covered here.

Pros:
- Fun factor.  The students are more likely to have unnaturally high levels of motivation during this course.
- Shock value.  It only takes a few lines of code at a time for the student to profit something fierce.

Cons:
- EasyUO is not a useful language outside of playing UO.
- Time spent on non-programming things.  Also, addiction.
- Differences with usual curriculum.  Non transferability of course credits.
- EA Games' rights to artwork in the UO Client.
- Has anyone even done this kind of thing before?

A couple of the problems can be solved with investment in a new UO client and macro language.  Of course, using existing RunUO server technology for the game server is probably a good idea.

Links:
High quality, free/open source UO server: http://www.runuo.com/products.php#1
The EasyUO main site: http://www.easyuo.com/
EasyUO documentation: http://wiki.easyuo.com/index.php/Documentation
Ultima Online site: http://www.uoherald.com/news/

OK, I've had my fun for the night.  Later.
- Chad

Nick Sabalausky wrote:
> "dsimcha" <dsimcha@yahoo.com> wrote in message news:gbrvb5$cdt$1@digitalmars.com...
>> == Quote from Christopher Wright (dhasenan@gmail.com)'s article
>>> Sean Kelly wrote:
>>>> The typical approach to this tends to be "just put this stuff in the
>>>> file and ignore it--I'll explain it later.  I never understood why this
>>>> is considered a good teaching method :-)
>>> Because it lets you create toys without understanding, and thus gets you
>>> interested without you expending significant effort.
>> Agreed, though I wouldn't necessarily phrase it in a way that smacks of
>> intellectual laziness.  Personally, I've always felt that I learn much more
>> quickly and much more thoroughly when I get to try to do something (preferably
>> useful) with my new knowledge as I'm learning, even if my understanding is fairly
>> shaky, rather than being forced to learn all the minutiae/background/theory before
>> trying to use any of what I've learned.  For example, I would *never* read a book
>> about a new programming language cover to cover before trying to write something
>> in it.  I would probably skim the first chapter or two, try to do a project in it,
>> use the book as a reference, and then read the book cover to cover later to learn
>> some better ways of doing things after I'd gotten my hands dirty a little.
>>
>> I feel that once I've actually tried to use a new piece of knowledge, I have a
>> *much* better idea of what, specifically, I still don't get, and can ask much more
>> intelligent questions than if I'm forced to learn large amounts of stuff passively
>> from lectures/books before getting my hands dirty with any of it. Furthermore,
>> learning this way also makes it much easier for me to see how things fit into the
>> bigger picture.  Not sure if this is universal, or just a personal preference.
> 
> I'm not sure if that's universal either, but I suspect that it is (excapt maybe for some rare fringe cases). At the very least, I can say that my mind works that way too. 
> 
> 

Same.
I don't even use books very much, if at all.
Examples + reference material + experience.  It seems to be my killer strategy.

"Chad J" <gamerchad@__spam.is.bad__gmail.com> wrote in message news:gbs393$j44$1@digitalmars.com...
> Hmmmm, now this may be of zero interest to the OP, but I the appearance of yet another programming pedagogy thread has caused me to spawn a crazy idea.
>
> Disclaimer:  This is probably a bad idea.
>
> So what if one of the ways to institutionally teach beginning programming was to just institutionalize the way I learned how to program?  You set up an Ultima Online server.  Customize it to cater to macroing/botting.  So it's kind of like robocode, but more RPGish and with some obligatory grindy numerical crap that has to be done before you are actually good at the game.
>
> First of all, make sure the students coming in actually want to play games, namely an RPG style game, and if they don't send them to the bland boring typical programming classes.
>
> The first few days of class are spent familiarizing the students with the game.  At this stage the instructor is mostly an admin as well as a player that helps other players out.  The students/players are allowed to play the game with relatively weak characters that should nonetheless be able to handle some fun canned activities.  They should also have some harrowing encounters.  You know; teach them their limits.  During this time the students will ideally gain some kind of personal attachment to their avatars and become assimilated into whatever kind of token economy might be deemed appropriate.
>
> I suppose I should mention that you can safely assume that the students haven't played this particular incarnation of the game and that you can safely used canned quests and such.  It will all be novel to them.
>
> After the first few days of the students being the squishy mortals they are, show them the power of programming.  Have them use a simple easyuo script like this overnight:
>
> top:
> ; Hide every 10 seconds.
> event macro 13 21
> wait 10s
> goto top
>
...trimmed...
>
> OK, I've had my fun for the night.  Later.
> - Chad

 [*Skims over most and nods head*] I think looking at how good programmers
learned is a great way to find perspective on how to teach programming.

And yes, a great thing to do is to show them right away how code can be useful and/or fun. Otherwise most of them will gloss over they way they usually do when introduced to something like algebra. Your idea would probably be great for people that are into hardcore RPGs (table-top or electronic). It shows them right from the start that programming is all about automating repetitive, but useful, tasks. And right away it gives them that feeling of power.

In a similar, but somewhat more general sense, I've always thought game development with a game-oriented tool like BlitzBasic or Torque2D is a great way to get people started in programming without immediately loosing their interest. Similarly, I've always felt that "High/Low number guessing game" should be every bit as quintessential as "Hello World" for people learning on something that leans heavily text-based (or, heck, even for the game-oriented systems like the ones I mentioned above).

Also, I learned a lot by typing in BASIC programs (many of them were games) from old library books, debugging the inevitable typos, and then customizing it by making changes and seeing how those changes affect the overall program. I think simulating that environment could be of great benefit to beginners, particularly the "making your on changes to a simple existing program." Among other benefits, this gives them positive early exposure to samples of "how code should look", and the skill of reading other people's code.

Another thing from my own programming past that I think is really good is the interactive tutorial. My very, very first coding experiences (and computer experiences in general) were from the AppleSoft BASIC, LOGO, and "Getting started" tutorial discs that came with the Apple IIc. I'm very surprised that twenty years later we still see very little of that sort of thing (Books and group lectures are very 1800's by comparison).

Chad J wrote:
> Hmmmm, now this may be of zero interest to the OP, but I the appearance of yet another programming pedagogy thread has caused me to spawn a crazy idea.
> 
> Disclaimer:  This is probably a bad idea.
> 
> So what if one of the ways to institutionally teach beginning programming was to just institutionalize the way I learned how to program?  You set up an Ultima Online server.  Customize it to cater to macroing/botting.  So it's kind of like robocode, but more RPGish and with some obligatory grindy numerical crap that has to be done before you are actually good at the game.
> 

I learned to program playing a warbots game on a Mac Classic.  I started by making my own robot icons and moved up to customizing and then programming my own bots in a calculator/assembly-like language.  My brother is learning to program by creating Flash movies and having a desire to add interactivity.  The difficulty would be formalizing this method of learning; it works great at your own pace but imposing a pace might defeat the method.

And yup, I read your whole post ;)

-Dave

Chad J wrote:
> Hmmmm, now this may be of zero interest to the OP, but I the appearance of yet another programming pedagogy thread has caused me to spawn a crazy idea.
> 
> Disclaimer:  This is probably a bad idea.
> 
> So what if one of the ways to institutionally teach beginning programming was to just institutionalize the way I learned how to program?  You set up an Ultima Online server.  Customize it to cater to macroing/botting.  So it's kind of like robocode, but more RPGish and with some obligatory grindy numerical crap that has to be done before you are actually good at the game.
> 
> First of all, make sure the students coming in actually want to play games, namely an RPG style game, and if they don't send them to the bland boring typical programming classes.
> 
> The first few days of class are spent familiarizing the students with the game.  At this stage the instructor is mostly an admin as well as a player that helps other players out.  The students/players are allowed to play the game with relatively weak characters that should nonetheless be able to handle some fun canned activities.  They should also have some harrowing encounters.  You know; teach them their limits.  During this time the students will ideally gain some kind of personal attachment to their avatars and become assimilated into whatever kind of token economy might be deemed appropriate.
> 
> I suppose I should mention that you can safely assume that the students haven't played this particular incarnation of the game and that you can safely used canned quests and such.  It will all be novel to them.
> 
> After the first few days of the students being the squishy mortals they are, show them the power of programming.  Have them use a simple easyuo script like this overnight:
> 
> top:
> ; Hide every 10 seconds.
> event macro 13 21
> wait 10s
> goto top
> 
> By repeatedly hiding every 10 seconds the player's character will develop hiding skill.  Run this overnight and you will likely have 100.0 (maxed) hiding skill.  Now, hiding isn't an uber powerful skill that allows them to kill everything with the flick of a wrist, but it is useful.  This is good: you don't want to give everything away all at once.  Teach the students how to, in a pinch, run and hide, thus granting them invisibility to the AI mobs.  Given a low latency connection (school network?) and maxed hiding skill, they will be extremely hard for the AI to kill.  Now they are untouchable, but still poor at killing or very much else in the game.  That's good, they still have a reason to improve their programming skills.
> 
> Also, for reference, the less useful "hello world" script:
> 
> msg Hello world!$
> 
> Which makes the player's character say "Hello world!"
> Yep. One liner.  The $ tells the computer to hit the enter key.
> 
> You're probably also glaring at that goto.  Heresy, isn't it.  But hey, goto is much easier to understand than functions.  It fits nicely with the idea of execution flow.  You can say that goto is horrible programming practice and hard to debug, and you'll be right, but the alternative is harder to teach at first.
> 
> At this point hopefully they've been using bandages to heal.  Hopefully they are also frustrated.  They have to move their mouse into their backpack, double click the bandages, then double click their character/healthbar every time they want to recover some precious hp. This just won't do.  So you have them write a macro to, on the press of a key, automatically find bandages in the backpack, use them, and begin applying them to self.  The solution looks somewhat like this:
> 
> hotkeyloop:
> ; poll for the key press.  It need not be only ctrl-shift-e.
> onhotkey e ctrl shift
>     goto heal
> goto hotkeyloop
> 
> heal:
> ; Find a bandage.
> finditem ZLF
> 
> ; Use it.
> set #lobjectid #findid
> event macro 17
> 
> ; Wait for targetting cursor to appear.
> ; If it takes longer than 2 seconds, give up.
> target 2s
> 
> ; Target self.
> event macro 23
> 
> ; done.
> goto hotkeyloop
> 
> Hey, we have some branching and now the notion of variables.  The variables are #lobjectid and #findid.  They are builtins, and "set" is the assignment operator.  Teach it.
> More gotos.  Deal with it.  It will get uglier in a bit, and that will probably be a good thing, ironically enough.
> 
> (Note: Last time I tried, onhotkey doesn't work with UO under Wine on Linux.)
> 
> Now for some magery.  They'll go from killing lowly rats and orcs to slaying dragons with this one.
> 
> top:
> if #MANA = #INT
>     goto cast
> if #MANA < #INT
>     goto med
> 
> med:
> event macro 13 46
> wait 4s
> if #MANA < #INT
>     goto med
> if #HITS < #STR
>     goto heal
> if #MANA = #INT
>     goto cast
> 
> cast:
> event macro 15 41
> target 4
> event macro 23
> wait 1s
> if #MANA = #INT
>     goto cast
> goto heal
> 
> heal:
> wait 1s
> Finditem WKORQQD
> set #LOBJECTID #FindID
> event macro 17
> target 2s
> event macro 23
> wait 1s
> goto top
> 
> We start to see some if statements here, comparison operations, and a slightly more complicated program.
> To be honest, I just grabbed this one from my old dusty collection of macros I've used at some point.  I have forgotten what WKORQQD is. event macro 15 41 casts energy bolt.  Other spells may be needed to level if the shard is set up differently.  Setting it up to keep it this simple is probably a good idea.  event macro 13 46 does meditation. This will train the auxiliary skills for magery too.
> Maybe give them a skeleton program of this and possibly some bugs too. Fun with goto debugging.
> 
> For those that care, I haven't mentioned melee skills.  Those are harder to macro.  Just do magery.
> 
> You're still reading this?  Are you mad?
> 
> At about this point it's time to introduce EasyUO's subroutine feature, which is pretty much just functions.  Now they can ditch gotos.  Perhaps  switch goto loops out for while loops as the way to do a main loop. EUO seems to have most of the good structured programming constructs.
> Before jumping directly into functions, it may be possible to goad the students into writing functions using goto primitives and thus teach low-level concepts like a call stack and a return address.  I'm not sure how much of a good idea this is.  I know I was writing functions this way before I know what functions were.  Then I learned, and sploited.
> 
> At this point they have some ?optional? assignments:
> - There are nice builtin variables for things like #HEALTH.  EasyUO can also read messages displayed on the player's screen.  With these two things in hand, and a solid grasp of conditionals, control flow, variables, etc, it is possible to write a macro that does healing automatically.  No need to press a button.  It just continuously strives to keep the player at full health.
> - Make another character.  A "mule" character.  Now make a macro to max out alchemy skill, so that the player can make potions.
> - Make a macro that automatically chugs cure potions when the character is afflicted with the poison status.
> - Make a macro that can max out tailoring/blacksmithy/carpentry/tinkering/mining on the mule character.
> - Encourage classmates to share.
> Welcome to teamwork.  Perhaps mandate that the students do all of these collectively as a class.  They will get first hand experience with the multiplicity of human programmers and how awesome it is.  Oh hey Linux Kernel, the might of mankind's giant programmer swarm is pretty cool huh?
> 
> Now perhaps we can get tricky.  Melee skills were ignored.  Perhaps this can be rectified.  Even though everyone is a mage just having maxed wrestling skill will be a valuable asset defensively.  Currently when a monster attacks them they get hit %100 of the time.  Maxed wrestling skill drops that to %50.  Alternatively, the student may opt to build a melee character (they should probably keep their mage, it's useful).
> So how to max melee skills?
> The macro-able way requires two characters to spar with each other until both are maxed out.  This is nontrivial.  The combatants will have to disengage when their partner is too low on health, or they will kill the partner and it's game over.  This may require the characters to move away from each other, and as such the macro must be vaguely aware of position.  Weapons degrade over time, so the macro will have to periodically equip a new weapon as old ones break.  The characters can heal themselves using the self-heal, but healing each other is considerably faster.  Heal self takes 10 seconds.  Heal other takes 4. Just how bad this is can be tweaked on server side (e.g. don't make weapons degrade over time).
> At this point we can introduce the concept of finite state machines.  At some level most of these macros were just FSMs to begin with, but this is probably a good time to formalize the idea and begin exploiting it in earnest.  Writing this sparring macro as an FSM is probably a good idea.
> This may also involve arrays.
> It might also be good to mention the applicability of FSMs outside of this, such as in regular expressions.
> 
> Now if we really want to cement these concepts, we can have the students attempt to write AIs for their characters.  They'd probably be Player vs Player (PvP) or Player vs Mobile/Monster (PvM) AIs.  And by that I mean combat AIs.  The really nice thing about this is that the students will be able to replace a lot of their tasks in the game as a human being with things that their program can do.  They may even be able to run multiple AIs at once, thus multiplying their capabilities.  This realization and ability is quite an awesome experience.  It's probably doable in this setup too.  Of course, they'll probably need some guidance, and if fully autonomous AIs are too tough then there's plenty of room to expand on automatic healing/curing and construct a more robust part-man-part-machine kind of combat system.  Either way this is just damned cool.
> 
> That's about as far ahead as I've thought on this.
> 
> At one point my nephew wanted to learn how to do some EasyUO macroing to help him play UO.  My time was short, so in about 3 hours I taught him about 2-4 weeks of introductory computer science material.  He quickly realized this was more work than he thought it would be, and he seemed pretty wide-eyed by the end of the experience, but he did seem to learn and in a remarkably short period of time become something of a programmer.  So maybe there is something to this.
> 
> Notably, the topics covered by this will probably be different from a normal introductory course.  Finite state machines are covered, while user-defined types are not.  OOP is not covered here.
> 
> Pros:
> - Fun factor.  The students are more likely to have unnaturally high levels of motivation during this course.
> - Shock value.  It only takes a few lines of code at a time for the student to profit something fierce.
> 
> Cons:
> - EasyUO is not a useful language outside of playing UO.
> - Time spent on non-programming things.  Also, addiction.
> - Differences with usual curriculum.  Non transferability of course credits.
> - EA Games' rights to artwork in the UO Client.
> - Has anyone even done this kind of thing before?
> 
> A couple of the problems can be solved with investment in a new UO client and macro language.  Of course, using existing RunUO server technology for the game server is probably a good idea.
> 
> Links:
> High quality, free/open source UO server: http://www.runuo.com/products.php#1
> The EasyUO main site: http://www.easyuo.com/
> EasyUO documentation: http://wiki.easyuo.com/index.php/Documentation
> Ultima Online site: http://www.uoherald.com/news/
> 
> OK, I've had my fun for the night.  Later.
> - Chad

I have a book written by one of the programmers in UO.  I was half-tempted to check out UO, but never had the time or money.  I'll definitely check out what looks to be an interesting potential pedagogical application.

Also, have you ever heard of Core War?

http://en.wikipedia.org/wiki/Core_War

A lot lower level, but I hear it's still crazy fun.

And no, I didn't really read your whole message, just sorta skimmed it.

The way I learned programming wasn’t quite perfect. We started with C++, writing C-like programs and went on to C# to write user interfaces by clicking around in Visual Studio. I’m just glad I found D pretty early, because it actually taught me programming.. or rather, I taught myself programming by exploring D. The D community and its open, positive attitude also had quite a big influence on me.

Thus, I think D would be a very good first language. Given that it sports a C-like syntax and includes so many paradigms, there’s lots of stuff to explore. Also, a “hello world” program is pretty easy to explain, as it only contains a very small set of constructs.

import tango.io.Stdout;

void main() {
	Stdout("Hello world!");
}

- import statement
- function declarations (main is a function after all)
- function calls
- string literals
- compilation :) (I’d just use rebuild to keep it easy for beginners)

Further, I would gradually add more things to this program, starting with function parameters!

import tango.io.Stdout;

void main(char[][] args) {
	Stdout.formatln("Hello, {}", args[1]);
}

- passing parameters to the program
- function parameters
- arrays
- passing parameters to functions

Next step would be to check args in some ways and explain flow controls that way, and so on.

You could well extend that to any paradigm you can find in D, given that you don’t skip anything that a paradigm builds on.

Best regards,
Alex

Chris R. Miller wrote:
> Sean Kelly wrote:
>> == Quote from Chris R. Miller (lordsauronthegreat@gmail.com)'s article
> 
>>> At a certain point you have to pedagogically ask the student to take
>>> certain things on faith until you can better explain it all.
>>
>> Fair enough.  But the amount each student is willing to take on faith varies.
> 
> It doesn't matter what they're willing to take.  You are the instructor.    In due time you will make all things known.  For now they need to just shut up and do what they're told.

And some will become frustrated and change majors, fail out, etc.

> Yes, standardized education for nice little standardized children!

If children were all the same then this wouldn't be a problem, as you're clearly aware :-)

>> Some will accept pretty much anything as magic, while others want to know
>> how a function call works mechanically (or in some cases conceptually, if
>> they're math geeks) before they feel comfortable actually calling functions.
> 
> I have seen many different kids from all three ends of this triangular spectrum do just fine with Java.  I got curious and started experimenting with it, trying to make my own classes at month 4. Eventually I figured out how they worked syntactically so I could use multiple classes in my programs (the files were getting too big for my tastes, I just wanted to split stuff up).  Later on the explanation of why and how they worked came and I had this great big "ah hah!" moment and I was ruined as  a Java pro ever since.  It's been four long years of deprogramming myself to get off of Java, so I'm doing well.  ;-)

In my experience, students with a math background often tend to do better with functional languages, since the way they work is a bit closer to the mathematic definition--immutable variables, no global state, pure functions, etc.  My wife is one such person, and between that and her need to know the details behind how things worked before she could apply the concepts she was pretty much the antithesis of the standard approach to teaching CS.  Once she got to the more theoretical or low-level classes like computer architecture, algorithm analysis, compiler design, AI, etc, she had no problem at all.  But those first few programming courses were incredibly frustrating for her.


Sean

Sean Kelly wrote:
> Chris R. Miller wrote:
>> Sean Kelly wrote:
>>> == Quote from Chris R. Miller (lordsauronthegreat@gmail.com)'s article
>>
>>>> At a certain point you have to pedagogically ask the student to take
>>>> certain things on faith until you can better explain it all.
>>>
>>> Fair enough.  But the amount each student is willing to take on faith varies.
>>
>> It doesn't matter what they're willing to take.  You are the instructor.    In due time you will make all things known.  For now they need to just shut up and do what they're told.
> 
> And some will become frustrated and change majors, fail out, etc.

Probably a better thing for them.  If they can't deal with approaching a new and foreign concept by gently probing into it, they probably won't fare well in the rest of Computer Science as well.

>> Yes, standardized education for nice little standardized children!
> 
> If children were all the same then this wouldn't be a problem, as you're clearly aware :-)

I have several classic quotes (of my own invention!) related to that topic, perhaps my favorite of which:

School is like a trash compactor: we stick our kids in and expect to have nice little rubbish cubes come out that stack nicely with the rest of the stinking trash heap we like to call "modern society."

>>> Some will accept pretty much anything as magic, while others want to know
>>> how a function call works mechanically (or in some cases conceptually, if
>>> they're math geeks) before they feel comfortable actually calling functions.
>>
>> I have seen many different kids from all three ends of this triangular spectrum do just fine with Java.  I got curious and started experimenting with it, trying to make my own classes at month 4. Eventually I figured out how they worked syntactically so I could use multiple classes in my programs (the files were getting too big for my tastes, I just wanted to split stuff up).  Later on the explanation of why and how they worked came and I had this great big "ah hah!" moment and I was ruined as  a Java pro ever since.  It's been four long years of deprogramming myself to get off of Java, so I'm doing well.  ;-)
> 
> In my experience, students with a math background often tend to do better with functional languages, since the way they work is a bit closer to the mathematic definition--immutable variables, no global state, pure functions, etc.  My wife is one such person, and between that and her need to know the details behind how things worked before she could apply the concepts she was pretty much the antithesis of the standard approach to teaching CS.  Once she got to the more theoretical or low-level classes like computer architecture, algorithm analysis, compiler design, AI, etc, she had no problem at all.  But those first few programming courses were incredibly frustrating for her.

I think that part of computer science is appreciating the proverbial "black-box" of architecture and learning how to use an abstracted system that you don't know how the whole thing works.  To a degree you need to train yourself to ignore the dead zones in your understanding and to do the best with what you have.

She must be really fond of closed-source proprietary APIs that hide everything about their implementation, eh?  ;-)

Chad J wrote:
> Hmmmm, now this may be of zero interest to the OP, but I the appearance of yet another programming pedagogy thread has caused me to spawn a crazy idea.
> 
> Disclaimer:  This is probably a bad idea.
> 
> So what if one of the ways to institutionally teach beginning programming was to just institutionalize the way I learned how to program?  You set up an Ultima Online server.  Customize it to cater to macroing/botting.  So it's kind of like robocode, but more RPGish and with some obligatory grindy numerical crap that has to be done before you are actually good at the game.

In my wife's AI course the students built simulated robots which competed in various contests (navigate the maze fastest, etc).  I think it was a fun way to get students interested in the material and think about how to apply it in a practical manner.  This is my succinct way of agreeing with your idea of making courses fun for the students :-)


Sean

Chris R. Miller:
> Probably a better thing for them.  If they can't deal with approaching a new and foreign concept by gently probing into it, they probably won't fare well in the rest of Computer Science as well.

From what you say you are an awful teacher :-]
I'm glad to have had teaches way better than you.

Bye,
bearophile