New Coding Paradigms

So I’ve recently been thinking that the whole idea of editing text files filled with code is outmoded. When I’m thinking about code, I certainly don’t think of it as a set of classes and functions laid out in a particular order. I think of it as a cloud of entities with properties and interactions flowing between them. Shouldn’t our experience of writing code reflect this?

We need to start rethinking our code-editing tools. A lot. Here is a simple example:
XML heatmaps

What else could we do? How about the ability to arbitrarily break off chunks of code and view them in parallel, even nesting this behavior to break long blocks of code into a string of chunks:
Nesting chunks

What if we let the flow of the documentation decide how a reader is introduced to the code base, instead of letting the flow of compiler-friendly source files decide it? Chunks of code are embedded within wiki-style documentation, and while you can follow the code back to its source, reading the documentation will eventually introduce you to the whole codebase in a human-friendly fashion.

The same code could even appear in multiple places (obviously updated when the source changes), and you could see all the places in the documentation where a particular chunk of code appears. This could bridge the gap between documentation and code; documentation will never grow stale, as updating code necessitates interaction with it. Similarly, updating documentation is the same process as writing code. When a standard changes or an SLA (service level agreement) is modified, the code changes too.

But why restrict ourselves to semi-linear, text-based documentation a la wikis? We tend to find UML diagrams extremely helpful for visualizing complex systems in code. What if we could build powerful, adaptable tools to translate between raw code, text-based documentation, and visual diagrams? Strictly binding them together might restrict you in the lowest levels of coding (much like, for example, using a high-level language restricts your ability to control memory allocation), but it opens up the new ability to make changes to a diagram and have most of the code rearrange and resolve itself before you. Then you step in to give a guiding hand, and adjust the text documentation, and voila! Best of all, this is more than a diagram-to-code tool; the diagram is a living thing. In fact, the diagrams, the documentation, and the codebase are synonymous. A change in one is a change in the others.

We’re getting to the point where it is much more useful to be able to dance across a codebase quickly than to be able to tweak and tune the minutiae of your code. Some allowances must be made for processing-intensive applications. Perhaps this system wouldn’t even be useful in those cases. But when you find yourself favoring adaptability and iteration speed over efficiency during development, and when you find yourself being hampered by the need to go between files, scroll through large swathes of code, or referring back and forth between code and documentation, maybe it’s time to rethink your coding paradigms.

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.


A couple of months ago I discovered Pyglet, which is basically an OpenGL interface for Python. I experimented with it, figuring out different features. I had never really worked with OpenGL before, and the little bit of experience I had was limited to translating GLUT spheres (for an N-body simulation for my Parallel Computing class).

Screenshot of my program (image link broken)

My exploration into Pyglet was a two-pronged attack. On the one hand, I had to learn how to use OpenGL, and on the other I had to learn Pyglet’s idiosyncratic diversions from standard C OpenGL. Fortunately, there is a wealth of tutorials and explanations on the Internet regarding OpenGL, and Pyglet is fairly well documented.

However, there is a caveat to exploring a new tool: debugging becomes much harder. When your code stops doing what it is supposed to, you have no idea whether the bug stems from a mistake in your code, or a fundamental error in your method. Moreover, your method may work in theory, but you are using the new API incorrectly. Since there is no way to test all three of these possibilities at once, you have to assume two of them are correct and look for an error in the third. If you pick wrong, you can spend days looking for a bug in the wrong place.

For instance, I was writing code to find the ray originating from the camera and passing through a point on the screen where the user had clicked. The issue here is that although you know the location of the click with relation to the window, you don’t know where it is in world space. Well, I went through 3 or 4 methods for finding the vectors in world space that corresponded to the vertical and horizontal directions on the screen. After that the problem becomes trivial.

A graphic description of my problem

In desperation I started printing out random things in the body of my code. I realized that two variables which should have been the same were very different. It turned out that when I found the location of user click in world space (which was stored as a vector), I was accidentally normalizing it.

I had assumed my code had no careless errors, and had instead blamed the bug on my method. In reality, I doubt there was ever a problem with my method. Instead, the problem had always lain in the three lines of code that I considered the “trivial” part of the problem. While it was quite trivial, that triviality also protected it from proofreading. After wasting a good 4 or 5 days on the problem, I have learned my lesson: there was absolutely nothing I could have done about it.

Programming Paradigms

Computer science is a relatively young field, and it has rapidly evolved ever since its inception. This becomes increasingly evident when you look at computer science being taught versus computer science being used. This is extremely apparent in the misnomer: computer science. CS is more technical art than science.

For a long time, computers had finite computational resources and memory. Today, our average consumer-grade computer is comparable to a super computer from 1985. Thusly, the twenty first century requires programming paradigms far different from those taught in the twentieth century. It no longer pays off to optimize the number of calculations or amount of memory your program uses, unless you are specifically performing mathematically intensive operations. This blog voices that sentiment much better than I can.

So programming now is about implementing an idea. Its easy to rise above the technical nitty gritty details and focus on the concept at hand. Then programming becomes a form of poetry, in which you express your ideas in a structured and rhythmic way. Programming, at a consumer level, is no longer about getting a machine to do what you want; its about empowering people.

Just like a poet spends many hours revising their verses and getting the words to say exactly what is meant, a programmer spends hours rearranging and improving code to fulfill their idea effectively. And like poetry, there are many genres and styles of programming. Unfortunately, programming is also like poetry in the way that many students get turned off to it by the experiences they have with it in school.

Programming should be taught with the main objective in mind: we are here to accomplish a mission. Writing mechanics are practiced and improved, but without an idea behind a poem or story, it is pointless. Algorithms are important, and so is project design and planning. But these are merely implements with which to express the programmer’s idea.

This is why the most successful software is easy to use, is powerful, or grants people an ability they didn’t have before. When you use a program, it doesn’t matter whether all the variables are global, whether the project was built top-down or bottom-up. The functional differences of some of the most disputed methods are miniscule. Optimization is a trivial concern when compared with the user interface. Is the parse speed of one file format more important than the support of a larger number of formats?

Kids want to be programmers because of coding heroes like Notch, the creator of Minecraft. But Minecraft isn’t well-designed. In fact, the program is a piece of crap that can barely run on a laptop from 5 years ago despite its simplicity. But the idea is gold, and that is what people notice. This is why Minecraft and Bioshock, and not COD, inspire people to be game developers.

However, functional programming is the CS taught in schools. Schools need to teach the art of computer science, not only the science. Imagine if writing was only taught, even up through college, in the scope of writing paragraphs. Essays and papers would just be a string of non sequiturs (kind of like this blog). Fiction would have no comprehensible story, only a series of finely crafted paragraphs. Only those who figured out the basic structures of plot, perhaps by reading books by others who had done the same, would learn to write meaningful stories.

In the future, everyone will be a programmer to some degree. At some point data will become so complex that to even manipulate information people will need to be able to interface with data processors through some sort of technical language in order to describe what they want. To survive in a digital world you either need software to help you interface with it, or learn the language of the realm.

Yet children are being driven off in droves because computers are being approached in education from completely the wrong angle. Computers are tool we use to accomplish tasks; the use of computers should not be taught just because “people need to be able to use computers in order to survive in the modern world”, but because children will be able to implement their ideas and carry out tasks much easier if they do have an expanded skillset on the computer. Computer skills should be taught in the form of “how would you go about doing X? Ok, what if I told you there was a much easier way?”

Starting a Game Studio

How do game studios get started? We always hear about game studios releasing a hit game and being boosted to fame. But whence do they come? I suppose most large companies and studios start as some guys in a garage or in a basement. Nowadays many companies are funded by the groups of venture capitalists, waiting to hit the next media goldmine. But in terms of game studios, are there still grass roots talent being formed and emerging? Or has the market environment become too hostile, and now new talent is forced to hop into the large studios as an insignificant piece of a game producing machine?

With most mainsteam games coming from the huge studios that have been bought up by corporate syndicates, there has been an increase in indie games recently. With the increased popularity of Valve’s digital distribution platform, Steam, fledgling studios don’t have to sign onto a corporate distributor to get their game noticed. Tiny, 5 dollar stocking stuffer games are now feasible to distribute, since releasing on Steam costs virtually nothing. Gone are the costs of creating discs and advertizing.

Studios still have to come from somewhere, though. I guess college is a great time to form a game studio. People are already there and live relatively close together, they don’t have a job, they have been studying their trade and want to apply it, and they have the time and motivation to accomplish something. I would go about creating a core team of one writer, and two coders, one or two artists. I would be a coder, but also keep the group coherent. Although 5 people may seem a little big to get off the ground, there would only be 3 people actively involved at one time on average. We would also need a couple voice actors, but that is outside talent and can be dealt with on a one to one basis.

After assembling, we would create our first game. No doubt it would take a couple iterations to get something desirable, but as long as something gets made, we’re fine. The game would probably be built on a pre-existing framework to speed up the development process. Once we have our first game out, we can bring one or two more people on board, and improve our infrastructure with the money from sales. After a second, larger game, we could probably get some investments and move into a building once graduated from college. As a standalone studio, it would probably be tough to make ends meet, but as a lead producer, I think I could keep projects on task and on time, yet still deliver an exceptional product. Perhaps we would eventually be bought up, but we could certainly argue a large amount of freedom in our contract if our games did exceptionally well.

Being the head producer of a studio would be great. It is your job to make sure good games are made, which means checking out and guiding every part of the process, from writing to coding to art design. It is your job to make sure people are working together, working quickly, and doing quality work. Such a job would suit me, as I have an interest in all aspects of game creation, an ability to hold a grand vision, the ability to help people communicate and work together, and the ability to split up an idea into steps and develop a timeline.

Another side of being the lead producer at a game studio would be dealing with management. If you belonged to a larger company, you would have people above you that don’t really understand or care what makes a specific game good; all they are dealing with is sales and other numbers. It might come down the chain of command that I should implement a certain system in my game, because it increased sales for these other games. Of course, my game is completely different and incompatible with that system. So it is up to me to please the management but still make a good, undiluted game. That sort of challenge is what makes producer an especially appealing job to me.

Strategic Idea Reserves

I’ve noticed recently that my behavior has become a bit blander. I am more content to just sit and think rather than share my ideas with others. I doodle less, and when I do it is only about a few select things. This stems, I believe, from this blog. As I write down the ideas stirring around in my brain, I share them definitively. Rather than telling snippets of an idea (or at least its current iteration) to whoever happens to be around me, I can tell the whole idea to the Internet. Thus, there is no reason to discuss it or think about it anymore.

By posting almost everyday this month, I’ve burned through my idea reserves quickly. It’s as if I went straight for the gold nuggets at first and now I’m left to sifting for flakes. Ideas don’t form as rapidly as I’m posting them (although maybe that’s because before now I’ve had enough ideas as it were), and pretty soon I’ll burn through even my strategic idea reserves. Sure, I have interesting little tidbits, but nothing to make a substantial post. Maybe I’ll make an anthology post someday.

My interests balance between three points it seems. The main two are Writing and Coding (which includes the technical side of level design). The third, Drawing (also the creative part of level design), is less influential than it used to be, but I still have an interest in it and upkeep my residual skill often enough through doodling. Right now it seems to be heading from Coding to Drawing and a little bit of Writing. We’ll see where this blog will go as my interests change.

What I wanted to talk about today was circuits and mechanisms in Minecraft, but that can wait. What’s been on my mind this weekend has been a Crysis map I’ve been working on. That’s why I haven’t posted in the past two days; I’ve been up late working on the map. Of course, there’s not much to talk about on that thread. The best way to share it would be a video of the gameplay once the map is finished.

Today is going to have to be a work day. I need to catch up on schoolwork, etc. Tomorrow I will post a legitimate idea. Today I am left thinking about doing a series of tutorials or the Source SDK and finishing the Crysis map (which makes me keep thinking about the game itself, which gets more and more epic every time I think about it). Maybe I should read more and start posting book reviews.

%d bloggers like this: