D vs Java as a first programming language

[Chris R. Miller]

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.