I have to laugh at parts of the release document. For example, the claim that programming languages started simple and easy to learn, and that the high-level concepts of modern languages discourage people from learning to code. “Hello World” is a one-liner only in a high-level language; it’ll take a beginner a few days of work and tons of documentation to accomplish in assembly. I also loved the section titled “Rules for naming Variables”: “[TODO]”

In general, this looks like a rehash of QBasic, of which all the warts are still present. The language lesson introduces GOTO long before talking about subroutines. Subs (not functions) access and modify global variables, and are limited to the current file’s scope. The major differences seem to be that most of the library functions have been rewritten in an object-oriented style and additional libraries for GUI stuff and Turtle programming have been added. Even though the library uses objects, the user has no way of writing their own.

I can see some junior coder at Microsoft doing this as a project for promotion points. It very much feels like a student project. However, I can’t see any programmer using it to actually teach programming. Small Basic might be useful if your ambition is to one day work up to Visual Basic as an enterprise programming language, but people interested in learning modern programming techniques would be better advised to look elsewhere for their first language.

I may not have put enough emphasis on “more difficult to get up and running.”

So, I’ve decided to write a walkthrough for how to get a FreeBSD box going. This is almost as much to make me think through each step and ensure that I’m doing all of them, and in the right order, as a service to the public–but once it’s done, I will make it publicly available just in case someone else wants it as well. At just over 9k of text so far, I feel like I’ve made decent headway. Of course, the next step (installing the GUI) is both optionful and pitfallful enough that I’m more worried about getting it right myself than getting it into text.

With luck, the walkthrough will be up later today.

It’s just that it’s so incredibly picky.

Say that, for some reason, you want to include a GUI checkbox in a program. You can drop one in with no problems at all; it looks like a checkbox, it can be checked and unchecked, it has a string attached, all seems good. Then, say you want to find out what is the state of the checkbox. It turns out to be LITERALLY IMPOSSIBLE. You are REQUIRED to use Java’s event-driven methodology, which means more work, and more coding time. The checkbox MUST remember its own state internally; it just refuses to tell you. It’ll fire off an event, in case you’ve attached a listener, but that really seems like a whole lot of work to just retrieve a boolean value from a component.

I’m going to go to sleep, and work on this more tomorrow. I wish there was a language that combined the best features of Java and Perl. That is, I want it to be universally supported, have quick and easy GUI applications… and not enforce a specific programming style on you. Because maybe if you’re handling 40 checkboxes in a single page, an event driven model really is easier to code and reduces bugs and all that. But when you’ve got a single checkbox, in its own container class with some other things, and you just want the state so you can write the toString() for the container class… it’s just annoying.

The AI textbook was clearly written by hackers (look at the definition if you think this is a pejorative term). It’s lucid, written with a sense of humor, and has lots of examples and visual aids. Anyone used to doing the CS thing could easily take this textbook and read it straight through, or look in the index and read through a section of interest quickly and easily. More importantly, they could immediately apply what they learned. It is presented simply, directly, and engagingly.

On the other hand, the Human-Computer Interfaces textbook seems to have been written by people who, like William Gibson, have never actually used a computer but have heard of them and have clear ideas of how they should be operated. The illustrations are nearly all screen captures of programs that were dated even when the book was published, and the most interaction with the computer that the authors expect is for the designer to watch and take surveys of users interacting with the computer. You keep seeing notions about the elderly being afraid of computers, and how computer games are an interesting but trivial case. The majority of the book is concerned with text-based systems, with very few references to GUI applications and their proper design. The user is in nearly all cases supposed to interact with the program with special commands and control key sequences.

The biggest problem with the book is that it is simply dated. There have been a lot of developments in human-computer interaction since computers became graphical beasts, and the book ignores most of them. It doesn’t even mention how users in games perform complex actions within a game-world as fast if not faster than they could in reality through efficient control mechanisms. Most of all, it doesn’t feel like it was written by, or for, a programmer. It’s the type of book that a pointy-haired-boss would read to learn about the subject, not something I would reccomend for an actual programmer or interface designer.

Unfortunately, I get the feeling that this class is just going to reinforce my dislike for implementing code that actually deals directly with the user.