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.
Friday, January 9, 2009
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.
Acey-Ducy: Old Basic
Here's a good example of how the BCG books were inspiring. Acey-Ducey is not a bright game; it would never work in Vegas. Basically, two cards are dealt and you are to guess whether a third card will land between those two cards. But of course, it's easy to win by not betting much when the cards are close together--or betting negative, even, which the program lets you do--and betting a ton when you have a sure thing.
But it's a card game! In 100 lines of code! So, if you can do Acey-Ducey what else can you do? The original author was Bill Palmby of Prarie View, Illinois. Let's look:
(Note that for PRINT I use the question-mark. The interpreter changed them to "PRINT"s back in the Apple days but since I'm using a compiler, they stay "?"s here.)
It's sort of hard to read, isn't it? One thing to pick up, from line 930, is that "between" means equal or greater to the lower bound. So, you can't lose on the low side if the low card is a deuce. Also, if the cards are one apart (and they can be), you can bet negative, and only lose if you match the low card. But that's a separate issue. Let's just break down the code:
Lines 10-80: Intro/Help
Lines 100-110: Variable initialization. I think setting "M" is superfluous, since the value is never used, but since M appears in the code before the user sets it... I dunno, I didn't think any environments at the time would care.
Lines 120-130: Your status update. How much money you have left. This is, strangely, only called when you win. When you lose, you're forced to guess how much money you have left.
Lines 140-240: Sets your wins and losses. This is a very weird place for this and probably how it came to pass that the loss doesn't show your bank while the win does. This money should be added or subtracted in the 910-1050 code block.
Lines 260-650: The bulk of the program, this "draws" the cards and prints them out. Note that the two blocks of code are nearly identical. Also note that the code draws and redraws the cards until A comes out being less than B.
Lines 660-710: These take in the bet and make sure the guy doesn't bet too much, though it doesn't prevent him from betting a negative.
Lines 730-900: Just like lines 260-650, these "draw" a card and print them out. It's kind of cute, but did you notice the code checks to see if the random number it generates is between 2 and 14, and re-runs it if not? I'm pretty sure that's because the RND function was not consistent across platforms. (Basic was poorly spec'ed and liberally grown.)
Lines 910-1050: Test to see if the player wins or loses, and if the game is over because he lost all his money. Note there's no clean exit for a winner.
So, to me, the fasicnating thing is that, even at 100 lines, this program is way longer than it needs to be. Next post, I'll compact it down.
But it's a card game! In 100 lines of code! So, if you can do Acey-Ducey what else can you do? The original author was Bill Palmby of Prarie View, Illinois. Let's look:
(Note that for PRINT I use the question-mark. The interpreter changed them to "PRINT"s back in the Apple days but since I'm using a compiler, they stay "?"s here.)
10 PRINT Tab(26);"Acey Ducey Card Game"
20 PRINT TAB(15);"Creative Computing Morristown, New Jersey"
21 ?
22 ?
23 ?
30 ?"Acey-Ducey is played in the following manner "
40 ?"The Dealer (Computer) deals two cards face up"
50 ?"You have an option to bet or not bet depending"
60 ?"on whether or not you feel the card will have"
70 ?"a value between the first two."
80 ?"If you do not want to bet, input a 0"
100 M = 100
110 Q = 100
120 ?"You now have ";Q;" dollars"
130 ?
140 Goto 260
210 Q = Q + M
220 Goto 120
240 Q = Q - M
260 ?"Here are your next two cards "
270 A=Int(14*rnd(1))+2
280 If A<2 Then 270
290 If A>14 Then 270
300 B = Int(14*rnd(1))+2
310 If B<2 Then 300
320 if B>14 then 300
330 If A>=B then 270
350 if A<11 then 400
360 if A=11 Then 420
370 if A=12 then 440
380 if A=13 then 460
390 if A=14 then 480
400 ?A
410 Goto 500
420 ?"Jack"
430 Goto 500
440 ?"Queen"
450 Goto 500
460 ?"King"
470 Goto 500
480 ?"Ace"
500 if B<11 then 550
510 if B=11 then 570
520 if B=12 then 590
530 if B=13 then 610
540 if B=14 then 630
550 ?B
560 Goto 650
570 ?"Jack"
580 Goto 650
590 ?"Queen"
600 Goto 650
610 ?"King"
620 Goto 650
630 ?"Ace"
640 ?
650 ?
660 Input"What is your bet?";M
670 if M<>0 then 680
675 ?"Chicken!!"
676 ?
677 Goto 260
680 if M<=Q then 730
690 ?"Sorry, my friend, but you bet too much"
700 ?"You have only ";Q;" dollars to bet"
710 Goto 650
730 C=Int(14*RND(1))+2
740 if C<2 then 730
750 if C>14 then 730
760 if C<11 then 810
770 if C=11 then 830
780 if C=12 then 850
790 if c=13 then 870
800 if c=14 then 890
810 ?C
820 Goto 910
830 ?"Jack"
840 Goto 910
850 ?"Queen"
860 Goto 910
870 ?"King"
880 goto 910
890 ?"Ace"
900 ?
910 if C>A then 930
920 goto 970
930 if C>=B then 970
950 ?"You win!!!"
960 goto 210
970 ?"Sorry, you lose."
980 if M<Q then 240
990 ?
1000 ?
1010 ?"Sorry, friend, but you blew your wad."
1020 ?"Try again (YES or NO)";A$
1030 if A$="YES" then 110
1040 ?"OK, hope you had fun!"
1050 ENDIt's sort of hard to read, isn't it? One thing to pick up, from line 930, is that "between" means equal or greater to the lower bound. So, you can't lose on the low side if the low card is a deuce. Also, if the cards are one apart (and they can be), you can bet negative, and only lose if you match the low card. But that's a separate issue. Let's just break down the code:
Lines 10-80: Intro/Help
Lines 100-110: Variable initialization. I think setting "M" is superfluous, since the value is never used, but since M appears in the code before the user sets it... I dunno, I didn't think any environments at the time would care.
Lines 120-130: Your status update. How much money you have left. This is, strangely, only called when you win. When you lose, you're forced to guess how much money you have left.
Lines 140-240: Sets your wins and losses. This is a very weird place for this and probably how it came to pass that the loss doesn't show your bank while the win does. This money should be added or subtracted in the 910-1050 code block.
Lines 260-650: The bulk of the program, this "draws" the cards and prints them out. Note that the two blocks of code are nearly identical. Also note that the code draws and redraws the cards until A comes out being less than B.
Lines 660-710: These take in the bet and make sure the guy doesn't bet too much, though it doesn't prevent him from betting a negative.
Lines 730-900: Just like lines 260-650, these "draw" a card and print them out. It's kind of cute, but did you notice the code checks to see if the random number it generates is between 2 and 14, and re-runs it if not? I'm pretty sure that's because the RND function was not consistent across platforms. (Basic was poorly spec'ed and liberally grown.)
Lines 910-1050: Test to see if the player wins or loses, and if the game is over because he lost all his money. Note there's no clean exit for a winner.
So, to me, the fasicnating thing is that, even at 100 lines, this program is way longer than it needs to be. Next post, I'll compact it down.
FreeBasic
For Basic programs, I'll be using FreeBasic, at least until I'm motivated to do otherwise. (Say, if I discover that it sucks.) You can download it at the link, install it, and then invoke the compiler with "fbc".
If you see "Old Basic", that means we're dealing with some ancient stuff. GOTOs and line numbers, and probably ALL CAPS. (I won't type things in as all caps, though, because I find that tedious.)
To compile an "Old Basic" program, you'd enter:
fbc -lang qb progname.bas
The "-lang qb" is to imitate QBasic, which is the oldest extant dialect that I know of that will work with these dinosaurs.
Now, there's some advantage to using actual QBASIC: Old Basics were all interpreted--you had to pay big money for a compiler, which is why I learned assembler (time was cheap, money was dear). What that meant though, was that if your program crashed, you could look at it real time, fix it and go on. (This was somewhat unreliable, though, since certain actions would silently reset the variable pool.)
QB, I think, has the stop-n-go thing, but I'm not sure about that. It does interacively debug, though, and that can be a huge help in learning how the flow of a program actually works.
For now, though, I'm going to stick with FreeBasic. If I find a use for QB, I'll bring it up again.
If you see "Old Basic", that means we're dealing with some ancient stuff. GOTOs and line numbers, and probably ALL CAPS. (I won't type things in as all caps, though, because I find that tedious.)
To compile an "Old Basic" program, you'd enter:
fbc -lang qb progname.bas
The "-lang qb" is to imitate QBasic, which is the oldest extant dialect that I know of that will work with these dinosaurs.
Now, there's some advantage to using actual QBASIC: Old Basics were all interpreted--you had to pay big money for a compiler, which is why I learned assembler (time was cheap, money was dear). What that meant though, was that if your program crashed, you could look at it real time, fix it and go on. (This was somewhat unreliable, though, since certain actions would silently reset the variable pool.)
QB, I think, has the stop-n-go thing, but I'm not sure about that. It does interacively debug, though, and that can be a huge help in learning how the flow of a program actually works.
For now, though, I'm going to stick with FreeBasic. If I find a use for QB, I'll bring it up again.
Project: David H. Ahl's Basic Computer Games
When I was a kid, I begged and pleaded with my father to get me a computer, and--in a rather rare moment--he actually did. (Lesson that I realized years later: Always ask your parents for things that they want.)
I had a computer class in school, but within a week or two, I had a grasped the basics as if I had been born to them which, after a fashion, I had. Those first two days of instruction, along with a later day explaining the concept of pointers, were all I ever had.
I did have this book, though, called Basic Computer Games and its sequel More Basic Computer Games. Both were edited by Creative Computing magazine editor David H. Ahl, and many (most?) came from issues of that magazine (which I never read, heh). Roughly each pair of pages contained some explicatory text, a sample run, and the code for a game in a hard to read font. There weren't a ton of errors, though--credit where it is due to the editors and typesetters.
The coding in this book was highly constrained by the fact that it had to run in the wild west of the '70s and early '80s: It had to be Basic, and it had to be least common denominator Basic. Not everyone had a whopping 48K of RAM and a floppy disk that could store over 100 kilobytes of data like I did. Some folks were running offa 16K TSR-80s and cassette tapes.
Seriously, though, scaled for inflation, that Apple ][ cost more than anything I've ever bought or ever has been bought for me before or since, including musical instruments, my first cars, or my children's birthing expenses. The only exceptions would be my house and possibly one or two of my cars.
On the other hand, I bought most of the stuff I have using skills that began with this book. So, you know, there was a payoff.
Anyway, the code is really quite bad by any modern standards, and even by the professional standards of the time. But the programs were games, which made them interesting. I polished my skills by adding graphics, sound effects, variations on gameplay, and then by creating my own games.
And of course, managing the complexity of those games drove me to hate Basic (at least as it was) for its poor structure and the limited help it offered. Also it was slow. This drove me to learn Assembler, PL/I and Pascal. (And all this in turn led to my interest in programming languages.)
So one of my projects for this blog is to bring those games back, and revisit them in a number of ways (gameplay, design, architecture) in a variety of languages in the hopes that this will give an appreciation of history, progress in the programming world and a fun way to experiment with different languages in different environments.
I hope you enjoy them as much as I did.
I had a computer class in school, but within a week or two, I had a grasped the basics as if I had been born to them which, after a fashion, I had. Those first two days of instruction, along with a later day explaining the concept of pointers, were all I ever had.
I did have this book, though, called Basic Computer Games and its sequel More Basic Computer Games. Both were edited by Creative Computing magazine editor David H. Ahl, and many (most?) came from issues of that magazine (which I never read, heh). Roughly each pair of pages contained some explicatory text, a sample run, and the code for a game in a hard to read font. There weren't a ton of errors, though--credit where it is due to the editors and typesetters.
The coding in this book was highly constrained by the fact that it had to run in the wild west of the '70s and early '80s: It had to be Basic, and it had to be least common denominator Basic. Not everyone had a whopping 48K of RAM and a floppy disk that could store over 100 kilobytes of data like I did. Some folks were running offa 16K TSR-80s and cassette tapes.
Seriously, though, scaled for inflation, that Apple ][ cost more than anything I've ever bought or ever has been bought for me before or since, including musical instruments, my first cars, or my children's birthing expenses. The only exceptions would be my house and possibly one or two of my cars.
On the other hand, I bought most of the stuff I have using skills that began with this book. So, you know, there was a payoff.
Anyway, the code is really quite bad by any modern standards, and even by the professional standards of the time. But the programs were games, which made them interesting. I polished my skills by adding graphics, sound effects, variations on gameplay, and then by creating my own games.
And of course, managing the complexity of those games drove me to hate Basic (at least as it was) for its poor structure and the limited help it offered. Also it was slow. This drove me to learn Assembler, PL/I and Pascal. (And all this in turn led to my interest in programming languages.)
So one of my projects for this blog is to bring those games back, and revisit them in a number of ways (gameplay, design, architecture) in a variety of languages in the hopes that this will give an appreciation of history, progress in the programming world and a fun way to experiment with different languages in different environments.
I hope you enjoy them as much as I did.
Introductions
My first blog isn't really a good place for coding, so I've fired this one up.
It's sort of interesting that blogspot has so many good blog names taken up by bloggers who never made a post or who haven't made a post in years.
Anyway, I chose the name "Left Curly Brace" ironically. This style of coding, made popular by the badly designed and poorly spec'ed C language--did I mention I have strong opinions about this sort of thing?--has come to dominate the programming world. Any new language, if it's going to take off, has to look like a math teacher vomited.
{
if(!happy)
toughLuck();
}
I prefer the cleaner English of Pascal (or PL/I or BASIC):
if not happy then ToughLuck;
Smalltalk's a little stranger to read, but it makes good, logical sense:
(self happy) ifFalse: [self toughLuck].
Anyway, it's not just C's syntax that makes it awful--some day when I have time and am feeling feisty, I'll go through K&R and explain why it's so bad--and we'll be using left-curlies here because, hell, you can't hardly help these days. The curly braces won.
If you're going to be a good programming polyglot, you gotta be comfortable with the C-style.
I've got various projects I want to do, and that I want to make available to others for their use. Ultimately, I don't know how many languages I'll be using, but you can expect to see Pascal, BASIC, Smalltalk, PHP and Actionscript just for starters. Yes, even C is likely, as is C++.
I hope you'll find the entries interesting and useful.
It's sort of interesting that blogspot has so many good blog names taken up by bloggers who never made a post or who haven't made a post in years.
Anyway, I chose the name "Left Curly Brace" ironically. This style of coding, made popular by the badly designed and poorly spec'ed C language--did I mention I have strong opinions about this sort of thing?--has come to dominate the programming world. Any new language, if it's going to take off, has to look like a math teacher vomited.
{
if(!happy)
toughLuck();
}
I prefer the cleaner English of Pascal (or PL/I or BASIC):
if not happy then ToughLuck;
Smalltalk's a little stranger to read, but it makes good, logical sense:
(self happy) ifFalse: [self toughLuck].
Anyway, it's not just C's syntax that makes it awful--some day when I have time and am feeling feisty, I'll go through K&R and explain why it's so bad--and we'll be using left-curlies here because, hell, you can't hardly help these days. The curly braces won.
If you're going to be a good programming polyglot, you gotta be comfortable with the C-style.
I've got various projects I want to do, and that I want to make available to others for their use. Ultimately, I don't know how many languages I'll be using, but you can expect to see Pascal, BASIC, Smalltalk, PHP and Actionscript just for starters. Yes, even C is likely, as is C++.
I hope you'll find the entries interesting and useful.
Subscribe to:
Posts (Atom)
