Sundry Thoughts

Git is the best version control system ever.
College is one of those things I have to do instead of programming, which is what I really want to do but can't cause I need a degree or else people won't pay me. It sucks especially cause I'm almost through the crappy general-ed part where I have to take writing classes and discussion classes, and almost onto the kick-ass degree only part; where I'll be programming like a madman. I'm not even sure anymore if I care about getting A's. I just want to pass the classes and get on with the good-stuff. My enthusiasm for school has been worse, but it's getting down to the ground right now. I was briefly interested in the new college experience; real college is a lot different than junior college, culture-wise; and that was interesting for awhile, but now I'm starting to feel closed in by homework and tests. It's not that the curriculum is so hard, as it is that I just can't keep myself together enough to push through things that aren't immediately gratifying. That's one of my bigger problems.
Other people get narcolepsy or epilepsy, I get avoid-olepsy. I avoid things I don't want to do, instead of doing them. It's not the most beneficial strategy I know, but it's obviously hardwired into my brain because I can't seem to stop! I need a self help book...
However, today was a good day by emotional standards. Woke up, felt good--didn't have a headache, unlike the past couple days. Now if only the neighborhood would regain power so that I might take my nightly walks without bumbling in the dark, everything would be great.

The problem with college teachers is that they repeatedly, and obviously erroneously, refer to their knowledge of the real world, and assert that in the real world, the stuff that they teach in the academic world actually matters. When of course, we all know that is not the case. What's astonishing (or perhaps only natural) is that teachers, who by vocation rarely step out into the "real world", unceasingly make reference to it. This may be an example of the Dunning-Kruger effect; so divorced from realness are they, that they paradoxically (and mistakenly) assume they know everything about it. But perhaps I give them too little credit. Certainly some of them occasionally breach the ivory tower--but I doubt it is as many as claim to.

A Question of Ajax

So I've reached the point in Mipper, my Mips interpreter, that I'm constructing the website; indeed, I've reached the point in constructing the website where I have to decide just how to connect the server-side Mips interpreter, to my client-side UI. The obvious choice is Ajax... but just how much Ajax is the right amout of Ajax.
What I need to do is allow the Mips proggies to execute on the server side, where my pythonic interpreter lives (I'm unwilling to port it to javascript to run on the browser: I like it fine where it is), while somehow getting the output and register and memory changes updated to the browser. This task would be simple enough (just send the data over) if I had infinite bandwidth and a fiber optic cable, but I don't. I can only update the client side gui infrequently unless I want to overload my connection: imagine me sending data for every iteration of a tight loop. Not gonna happen!
What I decided I need to do, is exactly what debuggers like eclipse do: offer two modes, step and break. In break mode, the ui only stops and updates when you reach a breakpoint in the code. Step mode would be the interpreter executing one instruction at a time, per user request. Both these solutions would be relatively light on the bandwidth while at the same time giving the user the information that they need. And indeed, I think I'm going to implement these two options and have that be the way of it. I might in the future consider porting my pythonic interpreter to javascript, but for now it's just redundant time wasting. I have to get this project finished or else I'm never going to be able to concentrate on my school work.
Which brings me to my final point: I'm neglecting my school work for programming. Like an irresponsible pair of lovers, skipping class to make out in the dark, me and my project are neglecting our friends and our obligations. But once I've finished with it, oh what accomplishment! The website already looks great; I got a template off www.owsd.com called missunderstood that looks great.
Django has been a pleasure to work with. It has less magic than rails, but I think that is a good thing. Rails is often too behind-the-scenes; sometimes I want to be able to see what is going on. It gets to the point with rails, for me, that I don't even feel in control of the app anymore. But I really shouldn't say that now; I was less experienced when last I used it for anything. When next I come back to it, then I'll pass my final judgement.
For the client side behavior, I'm using a combination of JQuery (for DOM manipulation) and Ext for sexy user interface. Only the actual Run-the-Code part of the app relies on Ext. The rest is standard xhtml and css. Truly I don't like the ultra-scripty websites that're wannabe desktop apps; so called thick-rich-webapps. Discretion please. The web is supposed to look like the web.

Python Goodness

It's possible that I like python more than ruby. Python seems to emphasize higher order functions more than ruby does; I mean, it's possible to do functional-ish programming in ruby, but not idiomatic. In python it might just be idiomatic. At least I have found it more natural to do functional-type-things in python than I did in ruby; and maybe that's just because I was using ruby 6 months ago, before I had touched Haskell or Clojure, and therefore didn't have a mind for composing functions, and making functions that return other functions, etc. I'll have to go back to ruby after this, and see if my new understandings make any difference.
Project Update: my MIPs interpreter, written in python, is working. It supports all the standard op codes (that I am aware of) along with the typical pseudo-instructions. The remaining issues with it are overflows and byte vs. word memory. Right now I'm just treating everything as words, no individual bytes, which is incorrect. And I'm not dealing with overflows correctly. In signed operations, I detect overflows and throw an exception, but in unsigned operations I don't do anything, just keep adding. That's a problem because, according to the bits, when I overflow an add I should go negative, but because python can handle arbitrary precision numbers, I have to build in that un-functionality myself. And it's a bummer man!
Instead of engineering my interpreter to maximum compliance, I'm starting the web portion of the project; wherein I create a web-gui in Django for the interpreter so I can put it up on Google App Engine, and show it off to everybody. Now, I don't know anything about Django; just that it's in Python and it is of the Rails Generation of web frameworks. Hopefully that means I'll be able to pick it up by analogy, but maybe not. I think I might do a significant portion of the UI in Javascript, and just serve up the interpretation functionality from the server-side. I've been wanting to give the EXT framework a serious go-round for awhile now, and this just might be my opportunity to do that. Though I do caution myself against trying to make a desktop app on the internet: I hear that is bad form, cause the web is supposed to look like the web not the desktop. If that is the case, then EXT is a bad influence: it's whole purpose seems to be bringing desktopishness to websites. Is it evil?
In any case, I'll just have to see what works. But you mark my words, I'm incorporating javascript somewhere into my application. Aside from the UI, the other big opportunity looks to be Ajax. Obviously the server-side interpreter code is going to have to communicate with the client somewhere, and why not in real-time, with no pesky click-refresh cycle to ruin the flow?
Anyway, hurricane Ike interrupted my school, so I have more to time waste on coding, hurray!

Mipper

Since I'm a crazy person, and this semester I'm doing a computer architecture class, I've decided to write a MIPS emulator. Originally I was just going to do it in Java using ANTLR, and indeed that's what I spent Saturday on, but then I figured how cool would it be if I could throw the emulator up on Google App Engine once I was done. But App Engine only supports Python, so now I have to rewrite it in Python, which is what I spent Sunday on.
ANTLR has a python output target, but it's not fully supported and I'm afraid of it, so I decided to just roll the parser/lexer myself; normally I would say "Don't Do That!" but MIPS (or any asm) is pretty simple--that is, doesn't require complex parsing algorithms, so it can reasonably be done by hand without much of a fuss.
So now the lexer and parser are done, and I can merrily digest MIPS assembly code; what remains is to specify the behavior. I can do some of that now... but I still have some things to learn about MIPS behavior before I can complete my emulator. I don't think the emulator itself is so hard as figuring out how to shoe-horn it into app engine when I'm done, particularly since I have zero prior experience with Python or Django.
Some comments on Python: When I think Python, I think Haskell-Ruby. The indentation-matters approach is totally Haskell, and so are the tuples and list comprehensions, while the dynamic typing and scriptyness is Ruby. Lambdas are Haskell-Ruby, and the tuple-unwrapping is kindof like Haskell's pattern matching (though of a lesser magnitude).

Actors

The Scala Actors library is gods gift to the JVM. In the absence of the mysterious and not yet fully realized STM, concurrency problems need Actors. Why do they need Actors? Because if they don't have Actors, then they have locks, and if they have locks, then they have deadlocks and unlocks and inconsistent shared global state spahgetti disasters. Actors solve this problem by keeping state local to the actors, and only allowing communication via message passing.
Loosely, each Actor belongs to its own thread of a execution; notice, you can pool them for efficiency. And each Actor communicates with other Actors via message passing: an asynchronous communication between the seperate objects not liable to be responded to, necessarily. As a consequence of the model, Actors tend to form loosely coupled asynchronous event-driven systems (without, necessarily, all the trappings of a traditional event-driven system).
Why do I care about Actors? Well I can't tell you. It might infringe on my old company's IP, and I wouldn't want to get sued now would I? However, let us say that I have experience with non actor based systems, and I have experience with my own personal actor based systems, and the latter is infinitely superior to the former.
Back in the day when I didn't know anything about anything, I tried to multithread a program by multithreading a program; which to me meant threading absolutely everything, and synchronizing absolutely everything. Of course, this was absolutely a disaster, and I will never do it again. If ever I am forced to uses locks again, it will be under protest, and I will cry myself to sleep; also I will emphasize, as everyone should, atomicity and resource pooling--for safety purposes in an inherently dangerous situation. It is unfortunate that I didn't discover the mysterious and wonderful language of Scala, and it's glorious Actor library sooner, cause it would have solved a lot of my problems.
As you may or may not know, Scala Actors are based on Erlang Actors, which in turn represent Erlang's answer to the concurrency question. As mentioned before, they operate by keeping state actor-local, and using asynchronous message passing for communication. What this produces is a loosely coupled asynchronous event-driven-esque system, which can be made extremely (emphasis extremely) fault tolerant through the use of a Supervisor-Worker pattern.
The Supervisor-Worker pattern (and I don't know if that's really the name, but in the name we have the two most important elements), is a relationship, like you might expect, between Actors designated as Supervisors which watch Actors designated as Workers, looking for signs of failure. If a worker fails, the Supervisor executes appropraite behavior to bring the worker back online, or else in some way handle the fault and keep the system from going down. This methodology is practiced and proven: evidence being the extraordinary uptime of some Erlang systems, nine nines or whatever.
What makes all this relevent to me is that if you ever were, hypothetically, to design a polling system for the collection and collation of sensor data, you might want to look at the Actor based approached, certainly in Scala and possibly in Erlang -- if you can stomach getting away from the Java platform. The reason being, as stated, you can produce very fault tolerant systems. And indeed, the systems just look nice anyway. An Actor is an easy abstraction to understand; the only drawback is that generally (unless you're willing to specify timeouts or risk deadlocks) the whole thing is asynchronous, so you have to adapt yourself to the asynchronous lifestyle as it were. I don't find this is too difficult for the work that I've done, but in more complicated software that has order-dependent logic in it (as in, things must be sequenced) you might have a greater issue with asynchronicity. However, I think this might be solvable using Monads, and I've implemented something like that; where you bind monadic Request objects together such that as one request is fulfilled, another is sent off, all in order. But I haven't used that in a large system so I can't tell you if it really works, especially if you are using a language that doesn't really support monadic types.
Actors rule!
Beware Locks!
What made me really think about Actors, besides actually using them, was taking the bus. I thought to myself, taking the bus is like a huge concurrency problem. You've got all these seperate threads (buses and people), that are supposed to meet at specified times (joins or walls or whatever). The problems arise when a bus runs late, and then you miss your transfer to the next bus, and all of a sudden your standing idle on the corner while you wait for the next. That's so much like a concurrency problem. Unfortunately, I think that the actor version of taking the bus is actually having your own car. And I'm way too green for that.

Started School

I've started my first semester at U of H. It is nice being at an actual university for once. They have a very nice library with a substantial collection of CompSci material, which I am quite enjoying. I've picked up this book on "First Order Logic and Automated Theorem Proving", which is right up my alley. And you know, I've found that as I've gotten older and become more experienced with math, it's all totally understandable. Maybe it was experimenting with functional languages, especially Haskell which is very math-esque, but my ability to understand mathematical statements (algorithms and proofs in particular) has expanded noticably. Part of this is simply development. Up to a point (say your mid thirties) you do get more mentally competent. That's not to say I'm going to make very many personal breakthroughs in the upcoming 15 years, but I can at least count on getting better at things I practice at. After 35, of course, it's all downhill, so I'd better be good enough to go into something soft like management, else face the addlement of age in a technically demanding profession; which I can tell you is not ideal, having observed many over-ripe male college professors who are no longer capable of professing their profession!
Which brings me to a critique of my current classes. I'm only taking one course in CompSci, and that is Computer Architecture; and unfortunately it is yet another class taught by an old man whose many years of long life and toil have leeched away all enthusiasm from his head. His brain-cells cry out for sleep, and I would indulge them.
Thank goodness I don't require teachers to learn, because otherwise I'd be screwed at the prestigious University of Houston. I can tell why so many CompSci graduates have no idea about anything when they get out of school. If you don't have the ability and motivation to educate yourself, you're at the mercy of whatever institution you're at; and in my case, that would mean a mediocre education at best.
I watched a documentary recently about the declining standards of American colleges, i.e. grade inflation and drunken fratboys scating through their degrees. I don't know if it's really all that bad; but I can assert that any highschool teacher who uses the excuse when professing to her students "Learn this cause you'll need it in college" -- she is likely mistaken.
My calculus and PoliSci classes are really big, but they're both taught by experienced and competent teachers, so it's ok. My writing class is taught by a psychotic woman (who is fun, but crazy). My discussion class is taught by a middle-aged football player who has a sarcastic wit and no seriousness. What other class am I taking.... I can't remember. Anyway, I get to spend lots of time reading cool books in the library. I wish HCC had had a better compsci collection. It's a real constrast from U of H, and I bet someplace like Rice or another top university would have an even more impressive (and enviable) collection.