Rhapsody in C, Sonata Basic

2011/03/02 § Leave a comment

I am perhaps bit weird in that the first programming language I learned was not the first programming language I used.

In primary school I used to borrow these “game collections” from the library. They contained a variety of program listings, always BASIC, which I then slavishly fed into BASICA (or later QBASIC). There were always a few variants because each popular computer had a slightly different language; the IBM PC must have been too prescient for these books and thus never listed specifically. Luckily, I figured out early on (probably by trial and error) that the Apple II versions always worked for some reason.

In any case, I’d write these thousand-line programs into a glorified text editor:

A BASIC LISTING

1 PRINT TAB(28);"RUSSIAN ROULETTE"
2 PRINT TAB(15);"CREATIVE COMPUTING  MORRISTOWN, NEW JERSEY"
3 PRINT:PRINT:PRINT
5 PRINT "THIS IS A GAME OF >>>>>>>>>>RUSSIAN ROULETTE."
10 PRINT:PRINT "HERE IS A REVOLVER."
20 PRINT "TYPE '1' TO SPIN CHAMBER AND PULL TRIGGER."
22 PRINT "TYPE '2' TO GIVE UP."
23 PRINT "GO";
25 N=0
30 INPUT I
31 IF I<>2 THEN 35
32 PRINT "     CHICKEN!!!!!"
33 GOTO 72
35 N=N+1
40 IF RND(1)>.833333 THEN 70
45 IF N>10 THEN 80
50 PRINT "- CLICK -"
60 PRINT: GOTO 30
70 PRINT "     BANG!!!!!     YOU'RE DEAD!"
71 "CONDOLENCES WILL BE SENT TO YOUR RELATIVES."
72 PRINT:PRINT:PRINT
75 PRINT "...NEXT VICTIM...":GOTO 20
80 PRINT "YOU WIN!!!!!"
85 PRINT "LET SOMEONE ELSE BLOW HIS BRAINS OUT."
90 GOTO 10
99 END

The above program is an example. Though this is probably not the version I originally used, I am somewhat impressed and disturbed that one of the first games I remember repeatedly enjoying was Russian Roulette. It was probably also one of the few games where I could reverse engineer what the code meant, as it didn’t involve any graphics, and thus lacked the mysterious POKE and PEEK and DIM statements that still perplex me. The keywords were reasonably verbose enough for me to understand their context. This was before the Internet, and for whatever reason my library had no basic programming language manuals, only guides on how to use various programs (and these game-books.)

I suspect many kids actually used these books to type in programs before even understanding what they were writing. Perhaps I’m not all that different.

Anyway, the first language I ever understood as a language was C. Eventually I found a book on C in my father’s secret science fiction stash. It was simply called “C”, or something like it. The author was theĀ founder of a compiler company that’s longsince been dust. I can remember the cover, a large Red C on a dark background, but not much else beyond the sparseness of its typeface.

THE C I KNEW THEN

#include <stdio.h>

first_function(f)
{
   return f + 5;
}

main(argc, argv)
int argc, char** argv;
{
    printf("Hello World!\n");
}

The book never explained the process of compilation, it assumed I’d have the smarts to know that I need to do something to the code I write in order to make it run. I may have at first tried to type the program in BASICA and quickly figured out that hitting F2 (RUN) and wondering why everything failed. Eventually I gave up and just wrote attempts on paper, placing faith in my correctness. It never occurred to me to ask my dad for a C compiler, probably because the book never talked about needing one and I couldn’t abstract my use of BASICA into a need I could demand from him. Even when I did sneak a compiler from my father’s pile of disks, enough years had passed that the syntax I had learnt had since been superseded by the ANSI standard. I learned C long before I got around to being able to use it.

THE C I KNOW NOW

<pre>#include <stdio.h>
</pre>
int first_function(int f)
{
 return f + 5;
}

int main(int argc, char** argv)
{
 printf("Hello World!\n");

 return 0;
}

Given that my programming experiences have mostly been in the context of C++ and given that I haven’t yet read the pinnacle of C reference books, I still wouldn’t consider myself remarkably fluent.

Jasmine and testing asynchronous callbacks

2011/02/28 § Leave a comment

I have been learning a variety of scripting, or dynamic, or web-development languages, simply because I am tired of being mired in C++ tar day in and day out. I am impressed — as I should be — at how much more seamless the interface is between code, editor software, and editor — but that is something I am still not completely familiar with and this shall discuss later.

My first attempt at a project is a MetaFilter reader for HP’s WebOS. The phone’s SDK has you write applications in Javascript, which on the surface is a completely whacked proposition, and I must infer that the process is incredibly mind-stretching (and even fun!.) So far, this has proven true. Javascript is a helluva drug, but there’s plenty of literature on this and anything I write I’ll get to later.

I’ve been using Jasmine to unit test my application. As a Behaviour-Driven-Development (i.e. write use cases first, but focus on human terms over code assertions) framework, it has been straightforward to adopt. However, the way one uses it for asynchronous callbacks was not entirely clear. While the user guide does go into the intended strategy at length, it took me a while to clue in that I have to structure the entire test-flow within runs, waits and waitsFor blocks.

Whereas I thought I could get away with the following:

describe('Some asynchronous code', function() {

	beforeEach(function() {
		//code to set up structures
	});

	it('should pass test 1, which doesn't actually care about the async code.') {
		//code to perform test
	});

	it('should pass test 2, which does require some asyncronous calls to be checked') {
		runs(function() {
			//Perform code that dispatches asynchronous callbacks
		});
		waits(500); //Could make this tighter with the more complicated waitsFor function.
		expect(something).toHaveHappened();
		expect(something_else).toLookLikeThis();
	}

	afterEach(function() {
		//code to clean up stuff
	});
});

I wound up having to massage it as follows:

describe('Some asynchronous code', function() {

	beforeEach(function() {
		runs(function () {
			//code to set up structures
		}
		waitsFor(...) // arguments check that the above stuff happened.
	});

	it('should pass test 1, which doesn't actually care about the async code.') {
		runs(function() {
			//code to perform test
		}
		waitsFor(...) // arguments check that the above stuff happened even though I don't really care.
	});

	it('should pass test 2, which does require some asyncronous calls to be checked') {
		runs(function() {
			//Perform code that dispatches asynchronous callbacks
		});
		waits(500); //Could make this tighter with the more complicated waitsFor function.
		runs(function() {
			expect(something).toHaveHappened();
			expect(something_else).toLookLikeThis();
		});
	}

	afterEach(function() {
		runs(function() {
			//code to clean up stuff
		});
		waitsFor(...) //arguments check whether the above thing happened.
	});
});

The reason for this is because, as mentioned in the guide, all of the functions in the runs() functions happen in linear order. As such, I had to use it (along the waits() and waitsFor() blocks) to force the entire test code to run linearly. The waitsFor() and waits() then become gates that only allow the following runs() fragments to go on when the waits() times out or the waitsFor() passes the check I put in asking if the previous code has run to completion.

Even if I don’t care about testing the results of those calls, in my test I care about having them complete so everything is ready by the time I check my expectations on the results. Thus, I have to linearize the entire test anyway. If I *don’t* place some code in a runs() block, it happens immediately with no regard for what happened previously. Even though I had that waits() function in test 2, I’m not sure whether code outside of runs() actually is forced to wait or whether it just continues on blithely.

In its defense, all the examples on the user guide are completely wrapped in runs() and waitsFor() calls. However, it was only implied that the entire process must be shepherded this way. It is entirely possible that my difficulty comes from asynchronous calls being new to me; in C++, I very rarely find myself in a world where I simply do not proceed until the function I am calling has returned a definite value … when we do allow the called function to go off and finish its work independently, I’m usually warned by tonnes of complicated thread/process code. Because the WebOS Javascript library has wrapped all of this for me so nicely, not only am I stuck in unfamiliar ground but I also don’t recognize more subtle warning signs.