Game-based learning is an interesting subject to me, so I thought I'd link this list of resources, originally tweeted by my pal Esther.
Of course, all games teach, but mostly they teach how to play the game. The trick is to have them teach something else, which is possible but often tricky. Situations where it's successful include things like typing tutors, and some other simple games.
Given the research suggesting certain subtle connections, it may be that Nintendo is really on to something with the Wii, the Wii Motion Plus and the Wii Fit.
Thursday, July 30, 2009
Tuesday, June 23, 2009
What Programmers Should Learn
I didn't study programming in college. I had been coding for five years by that point and, rather arrogantly, didn't think there was much they could teach me. Plus, I never expected my college education to be applicable to my future career, whatever it was.
I had some validation of that when listening to those who were in the upper classes complaining they had to write 50 lines of code for a final, when I wrote that much before lunch more or less every day--for fun.
However, I think this guy has done a very good job here laying out an impressive plan. It's interesting to note that a lot of these topics didn't even exist a few years ago.
I'm not 100% sold on the order of the items, but I like the emphasis on design. Programming is actually a very basic, very simple skill: it's not the language or the ability to code. I can switch between any number of languages easily. A new API or library or framework is a toy to me.
What kills me is the admin: Setting up the environment, managing code, deployment, security, and so on. These skills are also very general purpose, in my experience. There are the occasional big leaps--and I'm talking tech "occasional", so they're way more frequent than other fields, but a good grounding is almost always going to serve you well, even when the tech changes. Every now and again, you'll end up having to completely change the way you think, though. If you don't like that, you probably shouldn't be in tech.
If it is, keep in mind you don't need to enter a degree program to learn any of it.
I had some validation of that when listening to those who were in the upper classes complaining they had to write 50 lines of code for a final, when I wrote that much before lunch more or less every day--for fun.
However, I think this guy has done a very good job here laying out an impressive plan. It's interesting to note that a lot of these topics didn't even exist a few years ago.
I'm not 100% sold on the order of the items, but I like the emphasis on design. Programming is actually a very basic, very simple skill: it's not the language or the ability to code. I can switch between any number of languages easily. A new API or library or framework is a toy to me.
What kills me is the admin: Setting up the environment, managing code, deployment, security, and so on. These skills are also very general purpose, in my experience. There are the occasional big leaps--and I'm talking tech "occasional", so they're way more frequent than other fields, but a good grounding is almost always going to serve you well, even when the tech changes. Every now and again, you'll end up having to completely change the way you think, though. If you don't like that, you probably shouldn't be in tech.
If it is, keep in mind you don't need to enter a degree program to learn any of it.
Friday, May 1, 2009
Code Curmudgeons
My old pal Esther has a piece up that's been Slashdotted about coding practices nobody misses.
I do miss some of these, though. I miss the sorting and fiddly bits. Not all the time. But, like optimization and memory management, mentioned later on in the list, sometimes that was the difference between having a usable product or not. It was a very intellectual exercise with very practical outcomes--not a common thing these days.
Building your own GUI was fun, too. Some people still do it, of course. Squeak Smalltalk has about 40 different (mostly incomplete) GUI systems. I suspect a lot of people miss building those.
Spaghetti code I don't miss, but I'm not sure that object drill-down is much better--nor the mega-objects people use to make their class hierarchies broad instead of deep.
As for manual multi-tasking, Flash isn't multi-threaded. So, yeah, some of us still have to do that.
Finally, being patient? I find that I'm still waiting on computers after all these years. Yeah, slow compilation -- well, look, I went from BASIC to the mainframe. The mainframe compiled before you could take your finger off the enter key after submitting. When it was running, anyway. Downtime was longer.
But now? I have to wait seconds or minutes to for my computer to boot up, or transfer data, or do whatever it's doing--probably because somebody didn't feel it was necessary to do all the optimization and fiddling we don't have to do any more.
I do miss some of these, though. I miss the sorting and fiddly bits. Not all the time. But, like optimization and memory management, mentioned later on in the list, sometimes that was the difference between having a usable product or not. It was a very intellectual exercise with very practical outcomes--not a common thing these days.
Building your own GUI was fun, too. Some people still do it, of course. Squeak Smalltalk has about 40 different (mostly incomplete) GUI systems. I suspect a lot of people miss building those.
Spaghetti code I don't miss, but I'm not sure that object drill-down is much better--nor the mega-objects people use to make their class hierarchies broad instead of deep.
As for manual multi-tasking, Flash isn't multi-threaded. So, yeah, some of us still have to do that.
Finally, being patient? I find that I'm still waiting on computers after all these years. Yeah, slow compilation -- well, look, I went from BASIC to the mainframe. The mainframe compiled before you could take your finger off the enter key after submitting. When it was running, anyway. Downtime was longer.
But now? I have to wait seconds or minutes to for my computer to boot up, or transfer data, or do whatever it's doing--probably because somebody didn't feel it was necessary to do all the optimization and fiddling we don't have to do any more.
Monday, March 2, 2009
Code Is Like Waffles: You Should Throw The First Batch Away
My old pal Esther wrote an essay for JavaWorld about throwing away code. She makes the reasonable point that it takes a couple of tries to get code right. And if you take away an irreducible truth, it should be that if you are a great programmer, throwing away code is trivial.
You can learn that from any trade or art, by the way: To a great painter, it's nothing to dash off a masterpiece and use it to pay the rent; my mom crafts the most gorgeous quilts and hands them away almost immediately; for the guy who made my treadmill desk, to do so was a trifle. And I do this with code. In my last really big project, I used to write 1,000 lines of code in a (six-hour) day, unless I was throwing away hundreds of lines. (I had two metrics: How much code I could write, and how much I could throw away without losing functionality.)
If you can do something expertly--in order to be able to do it expertly, you must be able to do it easily. This isn't to say there aren't challenges for experts. But once you understand how things are done, you know how to approach and solve problems in your domain.
But note, that also contradicts the "three tries" notion at some level, or rather the conclusion that Esther draws from it, which is that programs peak at the third version.
First: Sometimes you do grasp a problem right off the bat and hit it out of the park. Subsequent versions are refinements without any real dramatic redesign.
Second: Any program of any complexity--note that Esther uses Windows as an example--is composed of various parts, and as a programmer, you have different levels of comfort with each part, most likely. Windows 3.0, for example, featured memory management code that--well, what attempt was that? And however many tries had been made, was it really the same number as had been done for device drivers? Threading? Microsoft didn't get threading right in Windows 3.x, in the early versions of OS/2, or in Windows 9x. It wasn't until N/T--built by a different crew--that MS managed threading that was less than embarrassing.
Now consider gaming: id made Commander Keen, Castle Wolfenstein and Doom. Was Doom the version 3? Keen was a side-scroller, and all three games were hits, and were fun. The programmers had been working on games previously, too, and Keen was the big breakthrough. Three tries? Note also that the id guys start over every time! They're constantly exploring the boundaries on the domain they're working in, and yet--from a standpoint of technical achievement--they're always successful.
Even if you're not pushing the envelope like those guys, the odds are your problem domain won't break down neatly in ways that allow you to say, "This is the true version three."
Third: Esther talks about fixing code versus replacing it. It's all very well to replace code, but doing so is often a crutch for coders who don't want to do the hard, unglamorous work of maintaining existing code. It's by far easier--and way more fun--to say, "Well, this is a pile of crap, we need to start over from scratch." Being able to read someone else's code, get into their head, and maintain it well is a rare skill--but it's a worthwhile skill, because without it, you can't tell the difference between code that's bad or wrong and code that you simply don't fully understand the impact of.
Joel Spolsky hits on some of the same points here.
You can learn that from any trade or art, by the way: To a great painter, it's nothing to dash off a masterpiece and use it to pay the rent; my mom crafts the most gorgeous quilts and hands them away almost immediately; for the guy who made my treadmill desk, to do so was a trifle. And I do this with code. In my last really big project, I used to write 1,000 lines of code in a (six-hour) day, unless I was throwing away hundreds of lines. (I had two metrics: How much code I could write, and how much I could throw away without losing functionality.)
If you can do something expertly--in order to be able to do it expertly, you must be able to do it easily. This isn't to say there aren't challenges for experts. But once you understand how things are done, you know how to approach and solve problems in your domain.
But note, that also contradicts the "three tries" notion at some level, or rather the conclusion that Esther draws from it, which is that programs peak at the third version.
First: Sometimes you do grasp a problem right off the bat and hit it out of the park. Subsequent versions are refinements without any real dramatic redesign.
Second: Any program of any complexity--note that Esther uses Windows as an example--is composed of various parts, and as a programmer, you have different levels of comfort with each part, most likely. Windows 3.0, for example, featured memory management code that--well, what attempt was that? And however many tries had been made, was it really the same number as had been done for device drivers? Threading? Microsoft didn't get threading right in Windows 3.x, in the early versions of OS/2, or in Windows 9x. It wasn't until N/T--built by a different crew--that MS managed threading that was less than embarrassing.
Now consider gaming: id made Commander Keen, Castle Wolfenstein and Doom. Was Doom the version 3? Keen was a side-scroller, and all three games were hits, and were fun. The programmers had been working on games previously, too, and Keen was the big breakthrough. Three tries? Note also that the id guys start over every time! They're constantly exploring the boundaries on the domain they're working in, and yet--from a standpoint of technical achievement--they're always successful.
Even if you're not pushing the envelope like those guys, the odds are your problem domain won't break down neatly in ways that allow you to say, "This is the true version three."
Third: Esther talks about fixing code versus replacing it. It's all very well to replace code, but doing so is often a crutch for coders who don't want to do the hard, unglamorous work of maintaining existing code. It's by far easier--and way more fun--to say, "Well, this is a pile of crap, we need to start over from scratch." Being able to read someone else's code, get into their head, and maintain it well is a rare skill--but it's a worthwhile skill, because without it, you can't tell the difference between code that's bad or wrong and code that you simply don't fully understand the impact of.
Joel Spolsky hits on some of the same points here.
Friday, January 9, 2009
Teaching Kids Programming (and other things, using programming as a vehicle).
Freeman Hunt asked about introducing a kid to programming.
I always wanted to do my own programming language and educational setup. Ironically, children tend to interfere with the whole "free time" thing so, it'll have to wait for grandchildren I suppose. This blog, I hope, will help others the way Ahl helped me.
In any event, it's hard to beat Smalltalk as a layered system.
First of all, there is Squeak's E-Toys. This can be found on the XO laptop--the $100-ish device they send to poor kids. That project is a realization of Smalltalk creator Alan Kay's dynabook. If you don't know about Alan Kay and the Xerox PARC crowd, well, you don't know about the history of computers. They're the guys Jobs ripped off for his Mac. Kay coined the term "object-oriented programming". I could spend some time on the rest of the crew (Dan Ingalls, Adele Goldberg, etc.) too, but we'll stay focused.
E-Toys isn't really about teaching how to program. It's meant to make the exploration of ideas simpler. Like, after teaching about gravitational acceleration, you could have the kid model its effect on various items. They'll learn about basic programming concepts along the way, but Kay's vision is broader than teaching how to program. (In fact, listening to him, one senses the dissatisfaction Kay has with software development and wonders if he doesn't worry that some new, better paradigm for development might be crushed in some young mind by current ideas.)
In the "not quite programming" category, there's also Sophie, which is a multimedia authoring tool written in Squeak. (Though apprently be rewritten in Java for some reason.) Scratch is also written in Squeak.
For The Boy, I found that he wasn't well suited to E-Toys visual approach. And he was frustrated by E-toys' limitations. In other words, he was focused on programming as an end. So, when he was able to read well enough, we used the book Squeak: Learn Programming With Robots. (I'm pretty sure Stephane has open-sourced and freebie-ized the book recently, but I like having the hard-copy anyway.)
He jumped quickly from there into straight Smalltalk (Squeak) and has been living there until now. He wants to make games, though, which you can do in Squeak, but in modern times makes more sense to do in Flash, so he'll be moving into that area this year.
I knew this time would come, but I think teaching Smalltalk first was the best approach.
Freeman asks: What hardware, software, operating system, books, etc.?
Well, hardware-wise: None. 30 years ago, the guys at UCSD figured out that if you wrote to virtual hardware, you could save a lot of trouble. This didn't work out then, because writing to a virtual machine results in slower code, and there just weren't the cycles to spare. That's increasingly less true, to the point where even code written for cell phones is virtual.
So, forget about the hardware. As Instapundit pointed out the other day, the "netbook" thing is likely to break the Intel stranglehold on the "desktop" computer.
Forget about the OS, too. The netbook will kill that, too. Microsoft has finally realized that the next platform is the virtual one, which is why they're busting their hump to get Silverlight into a usable state. Silverlight is, in essence, Flash.
Does that mean a kid looking to be savvy ten years from now needs to learn Silverlight and Flash? No, not really. What it seems to foretell is that the future platform is the browser. Microsoft lost the browser wars to Firefox--not to say that people don't use IE, but enough people use Firefox that MS can't force it's "standards" on the world. So the next battle is for the virtual machine.
And it's not just between Silverlight and Flash. Every browser has a built-in Javascript machine that has been advanced aggressively by companies like Google. However, since MS must implement that machine in IE, it's in their interest to screw it up, especially now that they have Silverlight.
And the thing is, whatever is going on now is very likely to be irrelevant ten years from now. So what anyone needs to learn is the basics: the core mechanics haven't changed since my dad's day and most modern in-use languages are object-oriented, so that leaves you with needing a platform in which you can learn about design issues like refactoring, patterns, testing and so on.
Squeak happens to do all those things very well, and because it's both a development platform and an experimental one, it tends to do whatever new thing comes down the pike before anything else.
Squeak is free and runs on nearly everything. The Boy has been using it on a ten year old machine that has Ubuntu on it. A machine of that caliber will run $5-$10, if you can find one.
The only downsides are that Smalltalk is the deep end of the pool and Squeak is ridiculously dynamic. There's always stuff going on, and that can make learning about it difficult. It's completely open by nature (Smalltalk was designed that way), but it can be like staring into the impenetrable void.
So, you very much want to get as much as you can out of E-Toys and Robots and all the others before diving into the Smalltalk proper. And when you do get in that deep, you want to get on the Squeak beginners list.
The Boy started out needing a lot of help and gradually got to the point where he could work most things out by himself, within a year or so.
And that is, essentially, what you're going for.
I always wanted to do my own programming language and educational setup. Ironically, children tend to interfere with the whole "free time" thing so, it'll have to wait for grandchildren I suppose. This blog, I hope, will help others the way Ahl helped me.
In any event, it's hard to beat Smalltalk as a layered system.
First of all, there is Squeak's E-Toys. This can be found on the XO laptop--the $100-ish device they send to poor kids. That project is a realization of Smalltalk creator Alan Kay's dynabook. If you don't know about Alan Kay and the Xerox PARC crowd, well, you don't know about the history of computers. They're the guys Jobs ripped off for his Mac. Kay coined the term "object-oriented programming". I could spend some time on the rest of the crew (Dan Ingalls, Adele Goldberg, etc.) too, but we'll stay focused.
E-Toys isn't really about teaching how to program. It's meant to make the exploration of ideas simpler. Like, after teaching about gravitational acceleration, you could have the kid model its effect on various items. They'll learn about basic programming concepts along the way, but Kay's vision is broader than teaching how to program. (In fact, listening to him, one senses the dissatisfaction Kay has with software development and wonders if he doesn't worry that some new, better paradigm for development might be crushed in some young mind by current ideas.)
In the "not quite programming" category, there's also Sophie, which is a multimedia authoring tool written in Squeak. (Though apprently be rewritten in Java for some reason.) Scratch is also written in Squeak.
For The Boy, I found that he wasn't well suited to E-Toys visual approach. And he was frustrated by E-toys' limitations. In other words, he was focused on programming as an end. So, when he was able to read well enough, we used the book Squeak: Learn Programming With Robots. (I'm pretty sure Stephane has open-sourced and freebie-ized the book recently, but I like having the hard-copy anyway.)
He jumped quickly from there into straight Smalltalk (Squeak) and has been living there until now. He wants to make games, though, which you can do in Squeak, but in modern times makes more sense to do in Flash, so he'll be moving into that area this year.
I knew this time would come, but I think teaching Smalltalk first was the best approach.
Freeman asks: What hardware, software, operating system, books, etc.?
Well, hardware-wise: None. 30 years ago, the guys at UCSD figured out that if you wrote to virtual hardware, you could save a lot of trouble. This didn't work out then, because writing to a virtual machine results in slower code, and there just weren't the cycles to spare. That's increasingly less true, to the point where even code written for cell phones is virtual.
So, forget about the hardware. As Instapundit pointed out the other day, the "netbook" thing is likely to break the Intel stranglehold on the "desktop" computer.
Forget about the OS, too. The netbook will kill that, too. Microsoft has finally realized that the next platform is the virtual one, which is why they're busting their hump to get Silverlight into a usable state. Silverlight is, in essence, Flash.
Does that mean a kid looking to be savvy ten years from now needs to learn Silverlight and Flash? No, not really. What it seems to foretell is that the future platform is the browser. Microsoft lost the browser wars to Firefox--not to say that people don't use IE, but enough people use Firefox that MS can't force it's "standards" on the world. So the next battle is for the virtual machine.
And it's not just between Silverlight and Flash. Every browser has a built-in Javascript machine that has been advanced aggressively by companies like Google. However, since MS must implement that machine in IE, it's in their interest to screw it up, especially now that they have Silverlight.
And the thing is, whatever is going on now is very likely to be irrelevant ten years from now. So what anyone needs to learn is the basics: the core mechanics haven't changed since my dad's day and most modern in-use languages are object-oriented, so that leaves you with needing a platform in which you can learn about design issues like refactoring, patterns, testing and so on.
Squeak happens to do all those things very well, and because it's both a development platform and an experimental one, it tends to do whatever new thing comes down the pike before anything else.
Squeak is free and runs on nearly everything. The Boy has been using it on a ten year old machine that has Ubuntu on it. A machine of that caliber will run $5-$10, if you can find one.
The only downsides are that Smalltalk is the deep end of the pool and Squeak is ridiculously dynamic. There's always stuff going on, and that can make learning about it difficult. It's completely open by nature (Smalltalk was designed that way), but it can be like staring into the impenetrable void.
So, you very much want to get as much as you can out of E-Toys and Robots and all the others before diving into the Smalltalk proper. And when you do get in that deep, you want to get on the Squeak beginners list.
The Boy started out needing a lot of help and gradually got to the point where he could work most things out by himself, within a year or so.
And that is, essentially, what you're going for.
Thursday, January 1, 2009
Smalltalk vs. ActionScript
ActionScript:
for each(var anObject: AClass in aCollection)
{
anObject.DoSomething
}
Smalltalk:
aCollection do [:anObject | anObject doSomething].
While not severely different, Smalltalk has the purity of the entire statement being composed of objects and messages. The dynamic typing eliminates the need for the AClass reference, which has ramifications that are too complex to cover right now. Though I think the ":anObject" is a syntactical construct, not an actual message to the block--it sure looks like it though, doesn't it?
for each(var anObject: AClass in aCollection)
{
anObject.DoSomething
}
Smalltalk:
aCollection do [:anObject | anObject doSomething].
While not severely different, Smalltalk has the purity of the entire statement being composed of objects and messages. The dynamic typing eliminates the need for the AClass reference, which has ramifications that are too complex to cover right now. Though I think the ":anObject" is a syntactical construct, not an actual message to the block--it sure looks like it though, doesn't it?
Sunday, November 23, 2008
Acey-Ducy: New Basic
As if often the case, code using modern styles is more efficient, but one often ends up writing more of it anyway to either improve the user experience or to create code that's more maintainable, reusable or robust.
Modern good practices, for example, require variable declaration. So that's extra code that needs to be written. But when I redid Acey-Ducey in the New, it found an error that had come over from the old. That is, I had mispelled a variable. In old basics, the environment was no help finding misspellings, since if you meant "M" but entered "N", it would just assume N was a new variable.
But look at this main loop:
Line numbers are terrible; initially I replaced them with labels so that "GOTO 260" was "GOTO DRAW2CARDS". That's somewhat better, but of course, on of the principles of top-down structured programming is to have one entry point and one exit point.
Doing this did remind me why I don't program in Basic much if I can help it. FreeBasic doesn't exactly match Microsoft Visual Basic and, of course, VB.NET is an entirely different beast. But all Basics have this combination of "Do whatever you want. We know what's best" that makes them irritating. (Pascal, by comparison, insists you follow a consistent pattern, no matter how stupid.)
Here's the full code. Note that I started out with an enumerated type for the game states which, I think, benefits readability. A lot of Basics don't have enums.
I went through a phase of being allergic to GOTO as all reformed spaghetti programmers must, but ultimately I think clarity rules above all. If getting rid of the GOTO would make code harder to read, then leave it in. For the past 20 years, though, it hasn't been a case of removing GOTOs but putting them in.
So, I've had only two cases where I've added GOTOs because they improved the clarity the code, and both of those were before exceptions had made it into the language I was using.
So, here? Nah, it's not necessary, but it's not "harmful" here, and we don't need to spend more time on it. This does point out the difference between modifying existing code versus designing anew.
I think it's also why programmers usually prefer to start over rather than try to make old code work. This little 100 line program has a few confusing parts in it. When you get into 10,000 lines or more, it can be hard work.
Modern good practices, for example, require variable declaration. So that's extra code that needs to be written. But when I redid Acey-Ducey in the New, it found an error that had come over from the old. That is, I had mispelled a variable. In old basics, the environment was no help finding misspellings, since if you meant "M" but entered "N", it would just assume N was a new variable.
But look at this main loop:
WHILE (GameOver=0)Ah. Much better. You can see exactly how things go.
?"You now have ";Bank;" dollars"
?"Here are your next two cards "
A=DrawCard
B=DrawCard
If A>=B then Swap A, B
? "First card ===> "+CardText(A)
? "Second card ==> "+CardText(B)
?:?
SELECT CASE GetBet(Bet, Bank)
CASE PlayerBet
C = DrawCard
? "Third Card is "+CardText(C)
if ((C>=A) AND (C<B) AND (Bet>0)) or (Bet<0) then ?"You win!!!" else ?"Sorry, you lose."
if (C>=A) AND (C<B) then Bank += Bet else Bank -= Bet
GameOver = (Bank <= 0)
CASE PlayerPass
REM Do Nothing
CASE PlayerQuit
GameOver = 1
END SELECT
WEND
Line numbers are terrible; initially I replaced them with labels so that "GOTO 260" was "GOTO DRAW2CARDS". That's somewhat better, but of course, on of the principles of top-down structured programming is to have one entry point and one exit point.
Doing this did remind me why I don't program in Basic much if I can help it. FreeBasic doesn't exactly match Microsoft Visual Basic and, of course, VB.NET is an entirely different beast. But all Basics have this combination of "Do whatever you want. We know what's best" that makes them irritating. (Pascal, by comparison, insists you follow a consistent pattern, no matter how stupid.)
Here's the full code. Note that I started out with an enumerated type for the game states which, I think, benefits readability. A lot of Basics don't have enums.
I see now that I left a GOTO in at the end with GOTO INIT.
ENUM GameStates
PlayerBet
PlayerPass
PlayerQuit
Unknown
END ENUM
REM ***SUBROUTINES USED IN PROGRAM ***
Function DrawCard as Integer
Return Int(rnd(1)*13)+2
END FUNCTION
Function CardText(Card as Integer) as String
SELECT CASE CARD
CASE IS < 11: Return Str(Card)
CASE 11 : Return "Jack"
CASE 12 : Return "Queen"
CASE 13 : Return "King"
CASE 14 : Return "Ace"
CASE ELSE : Return "Error!"
END SELECT
End Function
Function GetBet(ByRef Bet as Integer, Bank as Integer) as GameStates
DIM S as String
DIM GS as GameStates = UNKNOWN
While (GS = Unknown)
Input"What is your bet? (0 to Pass, Q to Quit)";S
Bet = Val(S)
IF LEFT(UCASE(S),1) = "Q" THEN
GS = PlayerQuit
ELSEIF Bet = 0 THEN
?"Chicken!!"
GS = PlayerPass
ELSEIF Bet > Bank THEN
?"Sorry, my friend, but you bet too much."
ELSEIF Bet <>0 THEN
GS = PlayerBet
END IF
WEND
RETURN GS
End Function
REM ***END SUBROUTINE SECTION ***
PRINT Tab(26);"Acey Ducey Card Game"
PRINT TAB(29);"New Basic Redux"
?:?:?
?"Acey-Ducey is played in the following manner "
?"The Dealer (Computer) deals two cards face up"
?"You have an option to bet or not bet depending"
?"on whether or not you feel the card will have"
?"a value between the first two."
?"If you do not want to bet, input a 0"
INIT:
DIM Bet AS INTEGER = 100
DIM Bank AS INTEGER = 100
DIM AS INTEGER A, B, C
DIM Response AS STRING
DIM GameOver as Integer = 0
WHILE (GameOver=0)
?"You now have ";Bank;" dollars"
?"Here are your next two cards "
A=DrawCard
B=DrawCard
If A>=B then Swap A, B
? "First card ===> "+CardText(A)
? "Second card ==> "+CardText(B)
?:?
SELECT CASE GetBet(Bet, Bank)
CASE PlayerBet
C = DrawCard
? "Third Card is "+CardText(C)
if ((C>=A) AND (C<B) AND (Bet>0)) or (Bet<0) then ?"You win!!!" else ?"Sorry, you lose."
if (C>=A) AND (C<B) then Bank += Bet else Bank -= Bet
GameOver = (Bank <= 0)
CASE PlayerPass
REM Do Nothing
CASE PlayerQuit
GameOver = 1
END SELECT
WEND
if Bank <= 0 then ?"Sorry, friend, but you blew your wad." else ?"Yay! You still have money left!"
Input "Try again (YES or NO)";Response
if Response="YES" then GOTO INIT
?"OK, hope you had fun!"
END
I went through a phase of being allergic to GOTO as all reformed spaghetti programmers must, but ultimately I think clarity rules above all. If getting rid of the GOTO would make code harder to read, then leave it in. For the past 20 years, though, it hasn't been a case of removing GOTOs but putting them in.
So, I've had only two cases where I've added GOTOs because they improved the clarity the code, and both of those were before exceptions had made it into the language I was using.
So, here? Nah, it's not necessary, but it's not "harmful" here, and we don't need to spend more time on it. This does point out the difference between modifying existing code versus designing anew.
I think it's also why programmers usually prefer to start over rather than try to make old code work. This little 100 line program has a few confusing parts in it. When you get into 10,000 lines or more, it can be hard work.
Subscribe to:
Posts (Atom)
