My Workspace

I was asked by someone about my workspace. This is kind of an opinion piece. My way is certainly not the One True Way to set up a coding environment, and shouldn't be taken as such. Hell, even for -me- it's not a One True Way. It's possibly not even a -Better- way. It's just a way that lets me get things done without wanting to punch the machine.

So, first, platform. If I'm on a Linux box, my work gets done at the command line, all the time every time. I still prefer to have a GUI with a desktop and graphical applications so I can Google for something real fast or distract myself for a few hours with that neat marble game, but actual coding work will be done at the terminal. I'm fond of Ubuntu's tabbed-capable terminal. I'll almost always make that sucker super big, make a tab, get one tab to where I want to be in the file system and the other one will be used to run my current editor of choice. For most languages, I'll use vim. If I'm coding in Common Lisp, I'll use emacs, simply because the emacs/SLIME combination is, for my purposes, extremely hard to beat.

On Mac, I use a hybrid approach. I'll have the terminal open to where I suspect I'm going to be doing a lot of compiling and running of code. For actual editing, well, this really depends on my mood. If I just need to make a small, fast edit, I'll use vim from the command line. If I'm working with Common Lisp at all, again, emacs is the tool of choice. If I'm doing major work, Sublime Text 2 has been amazing. I don't even fully utilize all of the stuff it can do. I just really like its slick appearance and some of its capabilities, like highlighting a whole bunch of the same keyword all at once and then changing them all at once, and regexp search, and a few other things it does well.

On Windows, well, I don't typically code on Windows. When I do, I usually struggle along with Visual Studio. I am not saying anything bad about Visual Studio, in fact, it seems to be a really slick tool that would work fantastically if I'd just sit down and take the time to get really familiar with it. I don't, so I find it slightly annoying to work with.

You may have noticed that unless I'm on Windows, I'm not using a dedicated IDE. Yes, I know vim can be made to be very much its own IDE, but I haven't done that yet, so it doesn't count. It's not from a lack of trying. I certainly find myself in Visual Studio often enough, and I tried Eclipse for a few months, as well as XCode. The problem with all these tools is that I don't really want to learn a new tool. I get frustrated by starting a new project in an IDE. Also, Eclipse was really, really slow on my Mac for reasons I didn't investigate.

Also, part of me absolutely loves only relying on tools which are almost universally accessible. Sit me down in front of any given Mac or Linux box, and I can code, without feeling frustrated about my favorite tool not being available. That's -neat-.

It's worth noting that almost all of my work to date involves either command-line apps, or a handful of OpenGL programs using SDL. If I was to do more work which required frameworks, or which had to talk to a specific platform's GUI API, I would probably pretty quickly adapt to using an IDE. In particular, I've played with QT Creator in the past, and I really liked that.

What are the benefits to my workflow, if any? Well, it works for me, and I can work pretty fast this way. Which should really be the goal of any work environment. If it lets you do the work you need to do, it's a good work environment.

Dates on a computer

Dates are one of those things in Computer Science that keep finding new and more entertaining ways to behave really badly. So here. Read this XKCD comic, and then everyone, please just follow the ISO standard. Hell, if everyone follows the ISO standard, everyone can keep doing that annoying thing where they store a date in an integer. That'll work okay until well after my lifetime is over. Note that other habits for storing time as a single integer don't sort as well ( the ISO standard, take out the dashes, sorts perfectly fine using the standard integer comparators ), or they have edge cases that'll behave oddly.

For example, if you stored dates as month-day-year, and you need to store January first, 2001, let's first convert that to its numerical equivalent in month-day-year: 01-01-2001. To get your integer, remove the dashes.

That leading zero gets lost. If you're using -three- ints to store the date ( a distressingly common thing I see ), -two- leading zeroes get lost in conversion to a single integer, and we wind up with 112001. Which I don't know what that is when your custom date format object gets passed to my code.

What I'm asking for, is if you're going to be sloppy about your date formats, store them in a single int, in the ISO format.

Though what I -really- want is for your date formats to actually be a robust first-class object in your system, but I understand that's a pain to code for.

If you decided to store dates as the number of seconds on your system, well, okay, that's fine, I can work with that. Please don't ignore things like the 2038 problem. ( Hint: If you're going to count seconds, use a bigger integer )

Wait, what's the 2038 problem?

Okay. Well, assuming a single 32 bit block of data is storing time information, and assuming you're working on an architecture that assumes the beginning of time is 1970-01-01 at 00:00:00 UTC, ( so, pretty much all Unix-based systems ), AND you're storing time as the number of seconds since this beginning of time, the last date that can be recorded correctly is 2038-01-19, at 03:14:07 UTC. At that point, the integer will overflow, and it'll be 1970 again for everyone.


Note to actual professionals reading this blog: I'm still a college student. These are problems I deal with. Somebody tell me better in the comments.

Trivia point: if we're counting the number of years since 'the beginning of time', last year was year 42. I hope everyone remembered their towels.

Late

Update will be late. I'll post something about my workflow later this week. Also, an announcement that's only exciting to me, but is really exciting for all that.

Technical Debt

This post is not about money.

Any serious programmer who has been programming for any reasonable period of time, whether as a hobbyist amateur or making big money at the big company, will eventually have to make this decision:

Accomplish your task doing something dirty -now- and fix it later, or do it the correct way ( whatever your idea of the correct way may be ), taking longer, possibly even taking up time that is unavailable. And in almost every situation, the temptation to do it dirty and do it now is overwhelming.

Doing it dirty and doing it now has the advantage of instant gratification. You can see the results of your work sooner, get immediate benefits, and spend time on something more interesting or less vexing. Of course, you’ll fix it proper later. Maybe during a maintenance cycle or during code review or in the next patch or when you revisit this program. Whenever it is, it is usually in the indeterminate and unplanned future but we as programmers are -certain- we’ll fix it.

Of course, we never fix it. We’ll forget how we programmed our quick and dirty fix in a week, forget the problem domain in a month, and just plain forget the whole program in a year. Either we will move on to another project, or the demands of this project will always stay high enough that we are never able to quite get back to fixing our quick and dirty code.

And in a high entropy environment, one quick and dirty fix becomes two becomes many. And we never get back to create those proper solutions we’ve always dreamed of. This is the technical debt. Taking out a loan in time now, and then never paying it back. The debt is incurred typically in code understanding or maintenance, and the quick and dirty fix can wind up costing us far more time than creating the proper solution in the first place.

It’s important to try to remember this. The technical debt for most projects will be incurred, sooner or later. It’s hard to keep in mind during crunch time or during finals or when you -just want to draw a box on the screen, dammit-, but that technical debt will tend to come back. Pay it now, and pay it forward. Don’t fall into the trap.

As a final note, though, moderation must be exercised here. While a quick and dirty fix now is almost never worth the end cost, a good solution now is often better than a perfect diamond solution, depending on what you are working on. Good judgement that comes with experience will help a lot here, but given the choice, I would recommend most programmers try for perfection rather than settle for quick and dirty.

Programming Paradigms

This is a placeholder for some terminology.

There are some ‘big’ programming paradigms that I’m familiar with. Procedural, functional, and object oriented are ones I have hands-on experience with. There’s also imperative versus declarative, and the idea of reflection, and macros, and... well. Programming languages tend to support one or more of these paradigms, and that, in turn, will affect the way in which a coder will code. Since production languages tend to be Turing complete, you can technically force any language into any paradigm. Having said that, programming languages are tools, and just like real tools, while you can force them into tasks they weren’t designed for, it’s probably better to just change tools.

Real fast, for those who aren’t programmers, Turing completeness describes a machine that can perform any calculation. You can imagine a machine that can read symbols that are printed on an infinite ribbon, and can interpret those symbols to carry out an arbitrary number of instructions, as well as modify those symbols. For practical purposes, if a programming language has an IF construct, and can read from, write to, and modify memory, it’s Turing complete.

IMPERATIVE programs are programs that can be described as a series of orders. Imperatives, if you will. PRINT a number, GOTO a line number, do this, do that. You can think of it as marching orders for the machine. Procedural and object oriented programming tends to fall in this category.

DECLARATIVE programs just describe what the program should do, but not a thing about how it should go about doing it. Functional and logical programming languages tend to enter this paradigm, as well as database languages such as SQL.

PROCEDURAL programs are the ones I am most familiar with. They have a list of commands to be followed, and procedures which can be called. C and BASIC are procedural programs, with the procedures that can be called being known as ‘functions’ in C, and ‘subroutines’ in BASIC. I think BASIC also has functions, but it’s been so long since I used it, I don’t really recall.

FUNCTIONAL programs are called that because they can be thought of as running a series of mathematically provable functions as programs. Haskell is an example here. They are noted for their lack of side effects, which is a way of saying that they don’t modify states like procedural/imperative languages do.

OBJECT ORIENTED programs have, well, objects. These objects tend to have a number of characteristics, such as encapsulation, and message passing. An object will tend to have a public interface, which is a way of passing commands to the object. This object will then have an implementation, which code outside the object doesn’t need to concern itself with. Objects often can also pass messages to each other, and act on these messages. C++ and Java are object oriented languages.

Hopefully this is clearer than the relevant Wiki pages.

Time Is Not Free

This is a lesson I learned from EVE. There is also a relevant XKCD here. (http://xkcd.com/951/)  Basically, the idea is that my time - and your time! - should not be considered free. And as a result, anything you do with your time has some nominal cost associated with it, even if you’re not paying out cash during that time period.

The lesson in EVE comes from pretty much the most boring occupation in the game, mining. A fair number of players in EVE spend a significant amount of time mining. It’s boring, but that’s fine. Once you’ve mined your minerals, you can turn around and sell them on the market. This activity, of course, presents no problems. You’ve spent your time hoovering up space rocks, and now that time is being converted into the in-game currency of ISK. Great.

The problem occurs when a player begins manufacturing. They go out and mine their own minerals to build in-game equipment, such as modules and ships. Now we’ve got the potential for an economic problem and a logic failure. The less savvy player who does this may decide that it’s cheaper to build things this way, because after all, they got the minerals for free. They didn’t have to buy them off the market! They converted their own work into minerals, and now they’re free to build stuff for cheap!

Except it’s not for cheap. It’s at the cost of time. There is an easy fallacy to fall into. After all, how you spend your time in game is your business. And in this process I’ve outlined, no ISK is generated, since the player skipped the market step. They mine the minerals, they process the minerals, they use them to build the module. Where’s the problem?

The problem is that the cost is in time, and it has an ISK number associated with it. Other, savvy players of course realise this, and generally, they’re the ones setting market prices. So even if you think your module or whatever was built for ‘free’, what’s happening is you’re simply eating a sort of opportunity cost.

What is opportunity cost? Well, in this case, it’s the expense of mining versus the cost of just buying the module. I’m going to make up some numbers here to help illustrate the point. Let’s say it takes you an hour to hoover up 100 units of space rock. And let’s say space rock is going for 1 ISK per unit. So, at the end of an hour of mining, you’ve essentially got 100 ISK in your cargo hold. But you don’t want to sell it, because you need to build your module, which just so happens to take 100 units of space rock.

Here’s the tricky part. Let’s say this module is available for sale on the market, and it’s going for only 90 ISK.

So which is better; to buy the module on the market for 90 ISK, or make it ‘for free’? Well, if you sell your 100 units of space rock, you get 100 ISK. Then spend 90 ISK on your module, and ta-da, you’ve managed to make 10 ISK.

Your time was not free, and the module you were going to build was not going to be free. Thanks to market fluctuations and manufacturing times and many, many market factors, it’s important to stop and think about the real actual costs of the activities you undertake. ISK makes a useful middle step in EVE, even if you’re not earning it or spending it directly. How much ISK per hour could this activity net me? How much would I make or lose doing something else? This can get as complicated as you like, because EVE is a complicated game, but I hope my simple illustration will suffice.

This applies to the real world as well. My time, and your time, it’s not free. Right now, I’m eating an opportunity cost. I could easily be making somewhere upwards of 60,000 a year doing industrial work. Instead, I’m choosing to go to college, and filling out the broke college student stereotype quite well. The opportunity cost for me is about two years’ worth of industrial level salary. In exchange, I’m getting an education. Hopefully when I’m done, I’ll be able to get a higher paying job, but honestly, that’s not the point. I’ll certainly get a job I’ll find more interesting. But I -am- paying attention to the costs of my decision, both eyes open, and fully informed.

You can take all of this however you wish. For me, this doesn’t mean I spend every waking moment of my life trying to wrench the maximum value out of it. How droll would that be! I would become an exhausted, wretched man. But it is worth paying attention to how I am spending my time. So that way, as the XKCD comic points out, I’m not working for drastically less than minimum wage in search of better gas prices.

Mental State Saving

I was thinking about why I could go back and easily get back into a saved Bejeweled game, but not other, more complicated games, such as Arkham City or Deus Ex. It’s certainly not a question of favoritism. If you asked me which game I liked more, the answer will be Deus Ex, by a considerable margin. But what is it, then? I find it more difficult to load up a save of Deus Ex than it is to pick up my phone and fire up Bejeweled. There are many possible answers, but I think one of the more interesting ones to explore is hedged in complexity and mental state.

If we were to ask which game is more complicated, certainly, games like Deus Ex win by a landslide. They have conversation arcs, location maps, branching decision trees and story paths, inventory systems, and so on. Even a very simple single player FPS such as Serious Sam will have things such as which weapons you have, which map you’re on, and what stuff you have/have not picked up and secrets you have/have not found yet. Bejeweled, on the other hand, has very few simple rules, and while they may change from game type to game type, overall the playing field is very homogenous.

Similarly, the rules are different. For Bejeweled, the entire ruleset can be and in fact must be kept in the player’s head if they are to be successful. There are only a few ways to move gems on the field, and only a few ways to make successful combinations. Contrast this with a FPS where the minimum information you need is where you’re at, where the enemy is at, what weapons you have, and how much ammo.

I think the difference in picking up the game again, particularly long after the last time I’ve played it, comes down to the idea of mental state. Can the player hold the entire state of the game in their head, and do they need to? For simpler games, the answer is really no. I can pick up my saved Bejeweled game at any point and immediately get into it. The state is revealed in full, immediately, when I load the playing field, and the rules are simple enough that even if I’ve temporarily forgotten them some experimentation will quickly reveal them to me again. Contrast this with many other game types, where even the loading screen tips and reminders may not be enough. What objectives have I accomplished? Which side objectives do I need to pick up or already have? What’s in my inventory? Who did I talk to last, what’s my character’s relationship state?

Steps can be taken to mitigate the problem of restoring the player’s mental state, like the aforementioned loading tips and reminders, and of course many games implement something like a log book to help you keep track of what you’ve done in this save file. However, they tend to be necessarily incomplete; they do not contain all of the details, and they certainly cannot be expected to keep track of certain personal goals a player may have set for themselves ( like try to get a certain weapon early because you knew where it might be stored ).

However, in the end, the simply PopCap style games can be said to be devoid of player state. The player needs to bring nothing to the game besides a desire to play, and no matter where they were last or what they were doing, they can quickly and easily get back into gameplay. For me, this low barrier makes them often more strangely more alluring than trying to run Arkham City again and try to remember everything I feel I need to know as well as what button throws the freeze grenade if I even have it. Of course, I still like the big deeper games better. The depth is welcome, the storylines intriguing, and a good game can get me to explore myself a bit.

But it’s still interesting to think about, both as a player ( why do I have more hours logged in on my iPad than my PS3? ) and as a budding game designer. I’ll need to keep these things in mind as I make large and complicated games. Saving and loading the state of the game, that’s easy; getting a player back into a game after months of them not touching it and trying to restore their mental state sufficiently to a point that they’re not repeating tasks or getting frustrated, that’s hard. Difficult, but definitely worthwhile to try and overcome.