Early Reflections on Pseudocode

I mentioned back on January 1 that I’m using the Pseudocode Programming Process for Greetings, Survivors, my current learning project. I’m about two weeks into this project now, which seems like a good time to do some assessment.

So, how’s it going?

It feels weird.

I began this project about two weeks ago, but I haven’t written any permanent code. Instead, I have 29 pseudocode files in various states of completion, each representing a future C# file.

Some of them are really detailed – lists of variables, methods, explanations of how the methods work, on and on. Others are just summaries waiting to be filled out.

All this time, and I’ve created nothing that can run. This isn’t how my projects usually look after two weeks. It’s disconcerting.

I feel ineffective…

…which is not surprising. When I’m writing in Inform 7, my progress tends to be something like 10k – 20k words per week. (Unlike most languages, I7 gives you progress in words instead of lines.)

Here, I’ve written a grand total of zero words on the project. Some part of my brain thinks this means I haven’t even started my project. It wants to know when I’m going to stop messing around, and actually do some work. (It is not a very nice part of my brain.)

…but I think I’m actually being more effective.

I wanted to learn more about software architecture for large-size products. I’m doing that. There have been multiple times when I’ve realized oh, no, wait, that doesn’t work. Under the pseudocode process, those alterations have only scrapped half an hour or so of pseudocode instead of a full day or more of actual code. There’s a lot to be said for that.

When I’m working in actual code, it’s easy to get lost in the details – how should something be formatted? where should it appear on the page? what should the exact language of a given message be? But this high-level approach doesn’t allow me to access the details yet.

Additionally, outlining the entire project from the beginning has forced me to look at what I really do understand and really don’t understand. I can’t outline a system in pseudocode if I don’t have some concept of how the underlying principles will work.

I’m not producing permanent project code, but I’m learning C#.

A lot of my time has been spent building tiny research programs.

For example, one of the first things I didn’t understand was how to set up a TCP server. I’d never done any coding with networking before, so I had no idea how to explain it in pseudocode.

Some googling brought me to the TcpListener class, which contains a source code example for a very basic server. I typed the source code into my files verbatim (shades of the Hard Way approach to learning) and then chased down links for all the applicable keywords until I was confident I understood how the server was working.

After that, I studied threading, and then I modified the Microsoft code to accept multiple connections on separate threads. After that, I studied asynchronous programming, and modified my threaded code to accept multiple connections on a single thread.

Other stuff from the recent tiny-program queue: saving objects into files with serialization (so that the game world can be saved and loaded), learning how to use a hash algorithm to safely authenticate passwords (so that users can log in safely), and learning how to get Lua and C# talking (so that EVERYTHING.)

Two console windows showing the serialization of cereals.

Sorry. My sense of humor does this sometimes.

I may have zero words of permanent project code, but my goal is to learn. I am learning.

I don’t think I’m going to bring this approach to my Inform 7 code.

You can do a lot with Inform 7 – it’s a very powerful tool. But it’s a very powerful tool designed for the specific purpose of making parser games, and it looks like English already. (When I was at Harmonix, I showed the I7 source for One Eye Open to one of my coworkers. He reasonably assumed it was my outline rather than my actual code, and asked if he could see the actual code.)

I’m good at I7 architecture. In I7, I think in terms of rooms and puzzle hierarchies and conversational structures, and I don’t get lost in my line-by-line code. I’m better off writing straight into I7, and improving my commenting habits.

But so far, it seems like a good idea for C#.

If I want to build a room in I7, there’s one practical, correct way to do it. I7 is prepared with all the necessary built-in structures to make my life easy.

But C# is a programming language, not a scripting language. If I want a concept of room in C#, then I need to decide how rooms work from scratch. What fields do rooms have? How does a room get created by the program? How does the system present a room to a player?

And now that I’m looking at C# alone (rather than C# with Unity), I’m really coming to terms with the sheer power involved. I can set up programs that will delete files, launch external programs, open ports on my computer, overtask my processors, and do pretty much… well… anything. Having a detailed outline from the beginning seems like a very good idea.

Admittedly, this was true of C as well. But somehow I’m far more aware of it this time around. Maybe I’ve levelled up?

Lua interpreter working

(Ding!)

Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *