Software Development

When I saw this article titled Old School Programming, I just had to add my own story to this. Other than a sense of nostalgia, there is a real advantage to old school programming. The path you take makes all the difference in what kind of programmer and what kind of skills you will acquire. It will also determine WHERE you will look to find more information.

When I was in grade 9, I had a Commodore 64. This was near the end of the height of popularity for this machine. I had read the manual that came with it over and over. I did not have a disk drive at the time because it cost twice as much as the computer itself. So I learned BASIC inside out and also got familiar with a few addresses that did different things. Right there, I learned something valuable. I knew that memory could be used for different things. There was plain RAM where you stored software and data. Then there was ROM. You had to know about this because BASIC was in ROM and you could switch it out if you didn't need BASIC. In its place, you got more RAM. The same principle applied to the kernel ROM. Then there was another kind of memory. This is what made everything work. This was I/O. You could change a byte in memory and a character would pop up on your screen. Another location changed its color. Yet another changed the background color of each character, of the entire screen and even the border. As you learned about all the different kind of I/O, things got really interesting.

Read more...

In traditional programming, there always comes a time when you need to add a significant amount of functionality that wasn't there before. Maybe it's because the focus has shifted. Maybe it's the clients. Maybe it's budget. Who knows. One thing is for sure though. You have a really nice and tightly coded application that will be decimated. Adding this new functionality can be done in one of two ways. The first way is to modify the existing code and redirect some of the functionality to the new code and vice versa. The second way is to add the new functionality via existing extensibility frameworks. Most applications aren't created with extensible frameworks unless the need arises. And that need is now.

So option #2 is simply NEVER available unless it's the second or third time you're adding similar kind of functionality. The first time around, you have no choice. You have to modify the code you have. Even then, you won't add in custom frameworks. You'll just insert the new functionality. The next time, you may think about adding extensions facilities. No matter what you do, your original code WILL be messed up. At least temporarily.

Read more...

I've been asked to write something about what Project V is so that anyone can have a good idea of exactly what this is all about. I've been trying for a long time without much success, but that doesn't mean I have to give up. This time, I'm going to create some graphics. Project V is visual, so I may as well show how the basics of this work in a visual manner.

We need a test application. This is probably the best way to start. Let's do something extremely simple. We'll create a network that computes the midpoint of two end points. (x1,y1)-(x2,y2). We know that the midpoint is calculated with ((x1+x2)/2,(y1+y2)/2). Here's conventional code.

struct Point
{
  float x,y;
};

Point midpoint(Point A, Point B)
{
  Point C;
  C.x = (A.x + B.x)/2.0;
  C.y = (A.y + B.y)/2.0;
  return C;
}

That's C++ (maybe even C).

This has 2 additions, 2 divisions, 2 assignments and a return instruction for seven operations.

In Project V, we deal with components instead of functions. It's like a conveyor belt. Each station has its job. Once a station is done working on an item (or multiple items), it passes the results to the next stations (components).

Read more...

OO has got to be the greatest chameleon ever in the realm of programming techniques. I thought functional was bad, but I was incredulous to what I was reading in this article about OO.

On page 1, we get this classic quote:

First of all, think of an object-oriented system as a bunch of intelligent animals (the objects) inside your machine talking to each other by sending messages back and forth.

Uh... NO!

If you send messages back and forth, you end up with a stack overflow. That's the main problem with OO that I'm struggling with now which I have overcome. You need to often send messages and let the other animal process it later or otherwise the new animal can send something to another animal that may send it back to you and then there's no way out. Happens all the time. As I've said many times, if it was just about sending messages around, I'd be all for it. But there's execution in there too. No one talks about this beast and the problems it causes for some strange reason.

Read more...

While developing my type system, I discovered something that was there all along, but isn't really discussed much. I'm talking about implicit types. Or rather if there is such as thing as a non-type. In my type system, everything is a type. This leads to the obvious confusion about how to differentiate between a value and what we commonly describe as a type.

I wanted a consistent type system, so I decided to have values as subtypes to their common types. So 4 is a subtype of Integer. But that's not the whole story. This description is wholly inadequate for our purposes. Four isn't exactly an Integer. The Integer type is the set of all numbers (without fractions). Four is only one of these values. So that's the main difference between a value and a type. A type is the enumeration of all possible values. This is commonly known as a set. A value is ONE value from this set. So when we declare an instance, it's assumed that we are declaring memory for this ONE value. The value only exists at runtime.

But in my system, everything is a type. So I needed a way to define values at design time. The IDE and compiler will use these values (because these values are in turn needed to define type properties). I simply decided that if a type has the Enum type as a base type, then you've declared a value. The primary base type defines the set from which the instance may take its value from.

Simple enough I think. What I really like is the unintended consequences of this decision. Say you define a class as you would normally do where you list a number of instances including instances of other compound types. Here's an example in pseudocode (the initializers are default values).

class Complex
{
  double r(0.0);
  double i(0.0);
};

class Test : public Enum
{
public:
  int a(2);
  int b(4);
  Complex c(r=1.0,i=0.0);
};

Test value(b);  // Can only contain ONE item from the Test class (a,b or c).

You can use this definition of Test as a set. Because that's what it is. It contains a list of items. What you can now do is subtype it along with the Enum base type and you can define your very own value that can be chosen from one of the items in your class. Each item would also have its own type. As such, you have a way to inspect the internals of any class directly from within the type system without any special functionality like reflection. It's a basic feature.

A difference is that there is no such thing as instancing anymore. Everything that is defined exists. At compile time, the compiler strips out any and all unnecessary information. There's more to this, but that's for another day.

As far as the GUI is concerned, I'm done the core functionality of it and it works great with Direct3D. There is one function I don't like that I had to include. You cannot nest render target operations, so I have to do two tree traversals instead of just one when drawing on screen. One for any component that caches its graphics and then another one for drawing on screen. It seems to work much better than I thought, so I'm happy with it. I'll be creating some more graphical components and then I should finally have something to show. I want to stress that I'm only working toward being able to connect components together and getting something running on a single core. Once that's done, I'll start adding stuff in that people want so that developers can produce their own stuff for Project V.