Introduction to Programming

Taking an introductory programming course this semester has been an interesting experience. Since I grasp the course material well, I’ve spent some time helping others with their work. As anyone who has taught math can attest, teaching even basic concepts requires you to understand the material far better than the student must. When it comes to programming, helping people is even more difficult because you can’t just tell them how to do it. You need to let them to figure it out on their own, otherwise they won’t have learned anything.

But leading someone along without explicitly telling them anything is really, REALLY difficult. Our professor is a master at this, and I respect him deeply because of it. A student will ask a question, and the professor will reply with an oblique statement that doesn’t seem to address the student’s question at all. Yet soon enough the student says “Oh! I get it!” and goes on their merry way. I try as hard as possible to emulate this method when I help those who are struggling, but it is nigh impossible to strike the correct balance. Help them too much, and they don’t learn. Help them too little, and they despair or begin to resent programming. And as much as I don’t like seeing it happen, many of the people in the class have come to resent programming.

This is as sad as a student resenting literature because of a bad English class experience, or resenting math because of a bad math teacher. Yet I don’t fully understand how to prevent it. If there was a good, standardized methodology for teaching difficult concepts without causing students to resent the field, I feel a lot of the problems in society today could be solved. Maybe that is just wishful thinking, though.

The second interesting observation from taking this class has come from observing a peer. The first language she learned was Python, and learning C++ this semester has caused some distress. There were many lamentations along the lines of “why is the computer so dumb?!” Of course, I found this hilarious because it mirrors a situation in the novel A Fire Upon the Deep. As the protagonists head towards the bottom of the Beyond, much of their advanced computer technology stops working, and they are forced to adopt more primitive methods. Needless to say, the characters who grew up with the advanced technology are indignant that they are forced to use such primitive technologies as a keyboard. Meanwhile, the character who grew up using primitive technology merely smiles.

In my mind, this helps clear up the argument of whether new students to the art of programming should be started on a high-level language, or a low-level language. Until such time as low-level programming is never needed except in rare circumstances, students should be started at a medium-to-low level. For example, it is easier to step up to Python from Java than it is to step down. I was originally of the mind that new students should start at a high-level as to learn common computing concepts without getting bogged down in obtuse technicalities and syntax, but getting a first-hand view of the results of such an approach has changed my mind.

The Simulation Problem

(No, not this)

I’ve been struggling with this problem for a while now every time I sit down to start playing KSP. As you may know, I am a huge space enthusiast, and a stickler for realism when it comes to portraying space and science topics. Then, of course, I also like playing fun video games. So I’m fundamentally at war with myself when I ask myself: how much realism is enough?

The key here is not striving for realism, but making it feel realistic. This means simulating what I know, and glossing over that which I know nothing about. Yes, this is lame. Additionally, there are some things that take far too much effort to simulate realistically — engine physics, weather patterns, n-body gravitation, physiology.

This problem has been eating away at me enough that I haven’t actually been able to play KSP. I tried a variety of different play styles, but ultimately I got stuck on one problem: I wanted my rockets to be as small as possible, and to take the optimal ascent route.

As I began researching this problem, I realized it was not trivial. In fact, planning an ascent path is quite complex, and the equations have a large number of parameters. Another compounding factor was that there is really no good documentation on the internet about ascent patterns. I’m not sure if this is because that information falls under some sort of ITAR restriction, or just because nobody is interested in it. I wasn’t even sure how to start thinking about it. I knew there was something called a “pitch-over maneuver”, but how does it work? Do they pitch over at a constant rate starting at some altitude, or is a more complex function? Are there multiple pitch-over functions? I could find nothing that answered this.

The second problem was that it is not easy to simulate rocket ascents. You have to account for the curvature of the Earth, so it is not a ballistics problem but a set of differential equations in a polar coordinate system. I tried some basic solution in both Scilab (a free version of Matlab) and in Python, but in both cases the complexity of the problem became so great that I threw up my hands before reaching a satisfactory solution. I mean, it’s hard enough if you consider one stage, but once you consider that a rocket can have any number of stages, the design space spirals out of control.

The design feedback loop

This problem would not stop bothering me. Every time I sat down to play KSP, I realized I was sitting down into a self-imposed math nightmare. Then after that nightmare was solved, I would still be stuck with a inability to truly simulate all the aspects of spaceflight I wanted to simulate, at least not without a lot of work making my own mods.

The moral of the story is: don’t mix realism/math and videogames.

(There is another corollary problem, which is that Reality Is Unrealistic. We have these notions of how phenomenon look drilled into our heads by TV and movies, but the truth is often different and less COOL. Unfortunate that we have been trained to have that heuristic for coolness. TV Tropes says it best. An interesting example is Star Citizen, which shows the ship engines as firing all the time — even when they are off in the physical simulation — because it “looks cool”. Sigh.)

Obsessive Rationalization of Unrealistic Genres

I am constantly amazed and disappointed by people’s perpetual insistence on willful ignorance and disregard of logic. It is common to tout that people are able to “distinguish reality from fiction”, but I am finding that hard to believe. This ailment is especially prevalent in fans or supporters of a particular lore; enjoyment of a genre appears to be a debilitating disease that leaves its victims completely incapable of making concessions to critics.

Let’s examine two examples. First, zombie lore. The genre is wide and diverse, but is generally accepted to be a gross fabrication and completely improbable, right? Nope. There is a fixation on coming up with more and more “realistic” explanations of how a zombie apocalypse could “actually” come to be. This is true both in media — we see the introduction of terms like “infected” to make the scenarios seem more authentic — and in the fan culture surrounding it. Look at any article on the Internet pointing out the most obvious reasons that a zombie apocalypse would never arise, and you will see a flood of comments defending the feasibility of such a scenario. Do they think that pointing out the unrealism of the genre is somehow offensive? That explicitly distinguishing reality from fiction (in a genre that is constantly trying to move the latter towards the former) somehow invalidates the fiction? It boggles my mind that people feel the need to defend the feasibility of a clearly fictional and improbable scenario.

But this feeling of wonder is only compounded whenever I accidentally wander near Star Wars or Star Trek fans. Both these franchises are clearly future fantasy (where technology serves only to further the plot, as opposed to hard science fiction, where there is a clear bi-directional interplay between the two). Yet many fan sites are created to help flush out the technological lore and attempt to apply rational, scientific explanations to the events in the media that are clearly only in service to the plot. If you point this out to a fan, they will become indignant and start explaining their way around any obstacle you toss at them. Never mind that the whole thing is fictional and doesn’t actually need to be scientifically accurate in order to be entertaining (and in fact was never intended to be scientifically accurate). This madness continues to the degree that later productions in the franchise may even try to explain some of the happening with science, but 9 times out a 10 this only bungles things up further.

Anyways, I wish die-hard fans would accept that they are fans of a fictional entertainment franchise that not only isn’t realistic or feasible, but in fact doesn’t need to be in order to be entertaining. Being unrealistic does not invalidate zombies or Star Trek or Star Wars in any way. So get over the fact that none of those franchises make any damn sense.

A Solution for Difficulty Curves and Power Creep

Most games portray you as a hero of some sort. A common trope is for the hero to be either inexperienced at the beginning of the game, or lack his equipment. This gives a reason for why the hero does not just plow right up to the main baddie and kill him at the beginning. In any case, a lot of games suffer from a strangely shaped difficulty curve. The game starts out fairly easy as the player learns the ropes, then the enemies get harder. Finally, you max out your stats and the game begins to get easier again.

Granted, the best games suffer from this less, but a lot of games have trouble with this type of power creep. Spore is a prime example of a ridiculously easy endgame (the space stage was essentially a sandbox). Some developers solve this by making enemies more powerful as the player progresses. This can work in games where, for instance, the enemy starts to realize just how much of a threat you are. In open-world games like Skyrim, though, this makes little sense.

Yahtzee, of Zero Punctuation, mentioned in one of his Extra Punctuation an inkling of an idea for a game that is designed with this problem in mind. I have taken the liberty of gripping the nebulous concept by the horns and fleshing it out.

The game is based around the power suit you wear. It is a magnificent piece of High Technology. Unfortunately, this means that nobody is quite sure how it works. The machining of the piece is much too fine to replicate, in any case, which means any replacement parts have to come from other pieces of High Technology, which are few and far between.

At the start of the game you escape from the main fortress of the Bad Guys with some sort of Valuable Item (perhaps information). You raid the armory and steal the suit before plunging yourself deep into the wilderness around the citadel. You spend the game running from a cadre of pursuers, trying to make your way to the border. At every encounter with an enemy, it is up to you to protect your suit as much. Each blow is physically simulated and, depending on where you place armor, where the hit was, how hard it was, etc. a component on your suit has the potential of breaking. Parts also wear down over time.

The most critical part of the game is deciding how to keep your suit in working order. Some systems are critical, like the pneumatics that let you move (damage to arm parts may impair aiming speed, damage to legs may reduce speed or jump height, etc), and some are dispensable, like weapons. If a critical system receives a hit and becomes in critical danger of breaking down, you have to stop and either fix it with any spare parts you find, or scrap a non-critical system on your suit to get the essential parts.

This meta-game with the suit solves the problem of power creep. You are at maximum power at the beginning, but enemies are also at the greatest density. Slogging through the wilderness and fighting enemies wears your suit down, so by the end you are barely limping along. As time goes on, you have to choose which weapon or system to scrap for parts. This means that you get a sample of all abilities at the beginning, and can keep the ones that best suit your play style. One of Bioshock’s biggest problems was that there was no incentive to try new plasmids. I’m sure the majority of players just improved the starting set, because buying new powers was too much of a liability.

I like the idea of having the game being mostly free-world. You can choose the best path through the different types of terrain to avoid encounters. Cold environments, wet environments, and sandy environments all have different types of wear and tear on the suit. Roads are easy to traverse (meaning less food consumption and lower likelihood of suit failure) but are more likely to find troops on them. Towns and other population centers are more likely to hold supplies (food and maintenance items are critical for survival) and spare parts, but the citizens will raise the alarm if they see you, and there are likely to be troops in towns.

The catch is that any alarms you raise will alert the search parties to your general presence and means a higher chance of encountering troops. Same goes for any military engagements in which an enemy scout or survivor escapes. The game is part stealth (avoiding conflict), part tactics(managing the suit, choosing your world route), part combat (winning conflicts you get into). At the end, instead of a boss fight, you have a final battle at the border of the kingdom as the search parties converge on your position and a friendly militia comes down from the other side of the border to help you across.

Why Richard Stallman is Wrong

I listened to an interview with Richard Stallman, and I truly believe he is wrong regarding the ethics of proprietary software and especially the fundamental beliefs behind computer and Internet usage.

Fundamentally, he assumes incorrect things. He says that people should be able to use computers for free. That doesn’t mean that having people pay to improve the experience is evil. I can decide to gnaw through a tree on my property for free, but I can obviously pay to have it cut down. Similarly, a user should be able to do anything they want for free, but should also be able to pay to either improve the experience, do it faster, or change the feel. The point at which you start getting involved with morality is when the development of proprietary software begins to interfere with the development of open-source software. However, I think that if proprietary software was somehow banned, the rate of development of open-source software would not increase by very much.

Stallman is fine with software developed for a single client, where the developer is paid for the development of free software, rather than the software itself. However, that is fundamentally the same as distributing proprietary software. The cost of the proprietary software represents the effort that went into making it, as well as upkeep for the company including other worker salaries and continued research and development. I do agree that such costs can get out of hand and that a ridiculous amount of money can end up going to those higher up on the corporate ladder. However, that is a necessary evil to keep high quality proprietary software pumping out at a rate faster that free software can be developed.

Although he demands that the functionality of ebooks mirror that of books, he doesn’t seem to make the same connection regarding proprietary software and its real world parallel: non-free services. Although you should be able to live in a house and use public transportation for minimal costs, you almost always buy furniture and hire services to make your life more comfortable. Similarly, proprietary software allows users to improve the aspects of their experience that they want to.

As I said before, Stallman discusses ebooks, and how you should be able to do the same with an ebook as you can with a regular book. However, as a completely different medium, you can’t just demand something like that. Suppose I demand that JPEGs be viewable in the same resolution as the paintings at a museum, for free. That doesn’t even make sense. Being a completely different medium, we need to approach ebooks in a completely different fashion. It would be nice to be able to easily share ebooks or sell them used. However, for an ebook to exist in an economic and material singularity similar to that of a paper book, proprietary software is absolutely necessary. Using Stallman’s logic, I can say that if you want a book to be freely available, write it yourself!

In some ways, open source philosophy (or at least Stallman’s) is like Communism. Everybody pools their resources and in return everybody gets the same, free software. However, as we see with many actual implementations of Communism, somebody who contributes resources may not need all the products. If I spend time coding, I want a video editor, not a database manipulator. The obvious solution is to have both developed and then have those who want the video editor to give their share of resources to that developer, and those who wanted the database software to the other.

Interstellar Travel

The most important part of writing science fiction is laying down a set of rules which stays constant throughout the book. In A Fire Upon the Deep (aFUtD), there was hyperwave, anti-gravity, hyperspace, and the Zones. In The Mote in God’s Eye (tMiGE), there were only two pieces of technology which violated physics: the Alderson Drive and Langston Field. Each was defined very clearly. Nothing is more infuriating than when an author saves the day with a previously undisplayed loophole.

Cover of A Fire Upon the Deep

The interesting thing about tMiGE is the interstellar travel. Scifi authors usually couple FTL travel with FTL communications; in tMiGE, the only way to send a message to another star system in a timely manner is to send a messenger ship. In addition, jumps between systems can only be made from specific points within each system, determined by the mass of the star and the arrangement of surrounding systems. aFUtD uses a similarly interesting, but completely different, device. Starships in the Beyond make micro-jumps, instantaneously jumping between two points in space and then calculating the next jump. This means that to go faster you just need more computing power. Systems built for different regions of the Beyond work differently; a bottom-lugger isn’t as fast as a state-of-the-art battleship except close to the Slow Zone.

In the fictional world I’ve been developing through a short story, interstellar travel is also interesting. Like tMiGE, the only way to go faster than light is with a spaceship. In my universe, ships have a minimum size requirement; messenger probes are out of the question. An interstellar drive has two parts: the ring, and the spikes. The ring manipulates space, flattening the local regions of the universe around the ship. While in theory a ring could be any size (bigger rings make bigger fields in a not quite linear fashion), it would lack control and have a tendency to fall into gravity fields. That’s why a ship needs spikes. Spikes are long, thin sensors that monitor the properties of the universe in small regions of space. They help the ring avoid massive bodies, correct for small spatial inconsistencies, and deactivate in the correct place. The more spikes a ship has, the safer and more precise it is. The higher quality a ring a ship has, the faster it can go. A ship that was too small wouldn’t be able to avoid planetary bodies or have a large enough detection field to navigate in flattened space. Ok, so maybe there is a little bit of Handwavium. But not THAT much.

You may be wondering: if the spikes hold sensors, why not just make a bigger spacecraft and imbed the sensors within the hull? Good question, reader. The answer is: you could. That is, if you are filthy rich. Rich people sometimes drive crazy cars and build crazy buildings, so certainly some people would make stylish spacecraft. At the end of the day, though, your spaceship is still occupying the same volume of space. It uses more sensors (unless you want minute pockets within your spaceship to expand and explode), and it only gives so much more interior space. It masses more, which means more energy or fuel to boost it through regular space. Spaceships aren’t like cars, either. Stylish lines are going to count for very little; even space stations don’t have windows, and nobody uses video to navigate. The result is that most spaceships are spheres inside a forest of spikes. Not very romantic, is it?

Mass is going to be the limiting factor on spaceship size. Unless you have very expensive spikes, you are still going to redimensionalize hundreds of thousands of miles from your target. You need some sort of in-system propulsion system. Since it is impractical to put a high-powered propulsion system aboard an already too-small ship, most spaceships would use local services: tugboats. Even obscure areas could afford one or two spacecraft with excellent traditional drives that can ferry interstellar craft around in cubic space. This also solves the problem of giving interstellar craft big dangerous drives that create exhaust. Except for military ships, redimensionalizing craft wouldn’t run the risk of toasting someone behind them. Military ships would be the exception; your enemies aren’t going to help you invade their system, so you need your own engines. On the other hand, military ships would be significantly different already. Most attack ships would be gigantic; they need to carry ship-board weapons, planetary craft, and a propulsion system. Military ships also carry prized interstellar equipment; governments are going to outfit their fleet with the finest rings and spikes.