Shortly after I wrote the previous blog, someone pointed out another programming blog, similar in nature to Mike Taylor’s. This is “Programming in the twenty-first century” by James Hague, a ‘recovering (games) programmer’, as he describes himself. In a similar random style, I’ll pick out a few blogposts of his, and give my thoughts. I also have some other thoughts that I forgot to mention last time, so I will mention them now.
One thing that came to mind regarding culture, is how the linux community seems focused on open source. In the demoscene, we have always been quite open about sharing information and such. Demosceners have written a lot of tutorials, explaining various tips and tricks, and demo coders are also quite willing to talk about code they’ve written, share ideas and such, when you speak to them at parties, or on IRC and such. I have written my ‘Just keeping it real’ blogs in a similar vein: I will gladly share and explain ideas, techniques and such.
But what we generally don’t do, is to share actual source code. After all, the real competition in the demoscene is to try and outdo the others by making faster and better-looking routines. So you want to write your own code, and try to make it better than what the others have written, rather than just using what someone else made.
Although I must admit, the scene has changed somewhat in that respect, in recent years. Some groups have started sharing their tools so everyone could use them to make demos. And especially in the 4k-scene, some projects are released entirely as open source. This has caused a boom in 4k-releases by new coders recently. Although sadly it also means the quality has dropped. These people only write 4k demos because they can use the code from people that have already done all the hard work for them. All they have to do is insert some shaders and some midi music into a standard framework.
Mindless re-use of code
I suppose we are all somewhat familiar with the demand for source code from certain communities. For example, they want nVidia and AMD to open up the source code of their graphics drivers, some even go as far as wanting Microsoft to release the source code of Windows. But a few years ago, I experienced first-hand just how far gone these people are.
I suppose we’re all familiar with memory clockspeeds and timing. For example, say you’ve got DDR3 memory at 1333 MHz, with 8 cycles CAS latency. Now, the issue here is that the CAS latency is expressed in cycles, rather than in absolute time. Hence, the absolute latency is a function of the clockspeed. So, if I want to run that memory at 1600 MHz instead, how many cycles of latency would it be then? Well, obviously that is very simple mathematics, barely high school level. It’s just a simple ratio: 1600/1333 * 8 = ~9.6 cycles at 1600 MHz. So you know that this memory could be used at 1600 MHz with 10 cycles CAS latency (and possibly with 9 cycles, if the margin of the original specs was large enough).
Anyway, super-simple stuff, but I decided to make a simple utility where I could select a clockspeed, then enter a few timings in cycles. Then when I selected a different clockspeed, it would adjust these timings relative to the new speed. That way you could easily find safe settings if you wanted to run memory at higher or lower clockspeeds than which they were intended for. I partly made it as an excuse to play around a bit with .NET and WinForms. But then I made the mistake of putting it online on some hardware enthusiast forum. I thought people may like to toy with such a utility when they’re tweaking their system…
But oh dear… You’d get the Windows people nagging that it was in .NET, which they would have to install (even though the .NET runtime had been on Windows Update for ages, so a normal up-to-date PC would have had it anyway). They wanted a regular Windows version. The non-Windows guys were nagging that it was Windows-only (which it probably wasn’t, it should have been simple enough to work with Mono). And then there were people who wanted a web-based version.
I said the thingie was released as-is, and I wasn’t interested in porting it to all sorts of platforms and maintaining it. So people started asking, no, demanding that I release the source code so that they can port it themselves. Really now? The program couldn’t get any more trivial than this! If you can’t even figure out how it works without looking at the source code, then I doubt you’d be very successful in porting it either.
What we have here is just a knee-jerk reaction apparently. It seems like people can no longer think for themselves. There is absolutely no reason whatsoever why any half-decent programmer should need the source code to create a program that does what my small utility does. I talked about glueing libraries together earlier, but in the linux/FOSS culture apparently it is more like glueing source code together. I suppose it ties in somewhat with another article I read on Mike Taylor’s blog: http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/
Apparently most programmers can not even work out a simple binary search algorithm. I heard a related story recently: if you ask programmers to calculate N*9 without using multiplication, division, recursion and looping, the vast majority will not be able to answer it. And I always thought that problem-solving was the REAL work in programming, rather than typing in the actual code in the editor and building it. If you can’t solve the above memory timing problem, or N*9 without multiplications, you’re an idiot, quite simply. These are problems that a 12-year old would get for homework. As Groucho Marx would say: “Quick, find me some 12-year olds, because our programming team can’t make heads or tails of these problems!”
Speaking of open source… If I understood correctly, the Pirate Party wants to make all software related to the government open source. This would include software for accounting and the software that people would use to fill out their yearly tax reports. Now, I don’t believe they have specified a license under which this software should be released, but I do hope it is not GPL. Namely, there are some problems with that. It would allow anyone to build the software themselves.
Now, perhaps you are thinking of people modifying the source code for tax fraud. But that is not even what I want to talk about here. There are tons of things that could go wrong when people can build the application from source code themselves. Even when they don’t actually change the source code. To name a few things that could happen if you compile with a different compiler, compile for a different CPU, compile with different settings, and whatnot:
- The compiler may have slightly different alignment rules, causing structures to not map 1:1 with the original formats, so exchanging data with other systems may be buggy.
- The compiler may use different sizes for certain types, causing potential overflow issues, and again problems when exchanging data with other systems.
- When using floating point, many things can go wrong. FPUs generally have higher internal precision than the input/output formats, meaning that even on the same FPU, a slightly different order of instructions may cause slightly different rounding (especially when compiler flags are specified to maximize performance), depending on when it uses registers, and when it spills intermediate results to memory. Different architectures may also have slightly different internal FPU precision, so you never get the exact same results anyway. If you’re interested, read up on Java and what Sun had to do to keep float/double performance consistent among various types of FPUs.
- Different compilers/platforms may have slightly different behaviour. Some code may not have been written entirely correctly, but it might work as intended anyway, with certain compilers/certain platforms. Take for example uninitialized data. On Windows, uninitialized memory is zeroed in the background. Therefore, when memory is allocated, the uninitialized values are generally 0 anyway. On other platforms this may not be the case. Some part of the code may accidentally rely on some uninitialized data being 0, so it works as intended, even though technically the code should have explicitly set the data to 0 on initialization.
There are probably quite a few other issues that one can think of. Bottom line is: it’s a whole lot more difficult to guarantee that code behaves as intended on every possible platform with every possible compiler than it is to just guarantee that the code behaves correctly in one compiled form. There is plenty of empirical evidence that tells us that even binary applications generally don’t quite behave as intended, so that problem is already difficult enough. But at least the government could build, test and debug some binaries for a handful of popular systems, and then have a reasonable level of certainty that the code will yield correct and compatible results on end-user’s systems.
Does this mean the source code should not be distributed? Well, no. What it does mean is that it is probably best to not allow end-users to build their own applications. So there should probably be some kind of code-signing/authentication, so that only binaries built by the government can be used to transmit tax results. This would not be compatible with the GPL licensing, so some thought would need to go into what kind of license and what kind of protection needs to be employed to ensure that tax reports will be reliable.
But I’m afraid the Pirate Party consists mostly of people such as Jed Smith, who’ve compiled a Hello World on linux once, and then Dunning-Kruger kicked in, so they think they’re God’s Gift to Programming now. But in reality they’re nowhere near experienced enough to have even thought of some of the real-world problems of open source, as I have listed above.
Another thing is… is it really necessary that we have the source code of these applications? The mathematical formulas for the tax legislation are not a secret. They are well-defined, and if you want to do it the old-fashioned way, and fill out a paper form, you can still do that. This requires you to calculate the values yourself (which again is not all that hard, should be something that anyone with a bit of high school math knowledge should easily be capable of). The software is merely a tool to automate this process. And it is relatively easy to verify the software’s correctness by simply calculating the results manually and comparing with the program’s output. So I am not all that sure what practical value the source code of such applications would have. It is purely an idealistic thing.
Speaking of Dunning-Kruger… The past few days I’ve been having a forum discussion with a guy by the nickname of Homer: http://www.asmcommunity.net/board/index.php?topic=14469.0
At first I just wanted to give a proper explanation for why books may say something other than what the Direct3D documentation says, since the answers so far more or less implied that Direct3D has the only correct answer, and therefore the books would be wrong.
Then Homer would chime in… He often does that when I post something. It seems he has this uncontrollable urge to show everyone that he knows best. Here is an earlier example of that same behaviour: http://www.asmcommunity.net/board/index.php?topic=30124.msg212527#msg212527
In both cases he seems convinced that he is an expert on the topic, and needs to ‘correct’ the others. But in both cases, he also confuses various terminology and concepts, and basically doesn’t make a lot of sense. Now, we’ve both been around on that forum for quite some years, so I know how he can be. As you can see, initially I just ignored the ego-trip factor of his posts and merely tried to correct some of his confusing information. I hate it when people open their mouths when they shouldn’t, because people who read the topic to try and learn something, will be fed with false information, and won’t get a clear understanding.
But he just became increasingly cheeky. He kept pushing for a pissing match where he could demonstrate that he is the more knowledgeable 3d programmer of the two. At some point I figured I would teach him a lesson. There is little chance of the guy knowing more than me about this subject, seeing as he’s only played around with Direct3D and OpenGL at a basic level, and even then, many of the things he posted on it showed a lack of understanding of the material. Heck, just a few months ago, the guy was completely impressed by the idea of doing 3d projection without a matrix: http://www.asmcommunity.net/board/index.php?topic=30911.0
As if that is rocket science? Matrices are just a specific notation for mathematical operations. You can write them out as formulas, and rewrite the formulas in a different form. High-school mathematics again. Note also that he had extreme problems trying to follow some very simple things I was saying about the use of matrices in shaders and how to optimize code to a minimum number of instructions. All the more funny that the guy became all arrogant and trying to imply that I wouldn’t know about various parts of the 3d pipeline, since we both know that I have implemented various renderers entirely in software. I know all the ins and outs of a 3d pipeline, including the parts that are not exposed by Direct3D or OpenGL.
So I decided to take his posts apart, and point out all the wrong information and inaccuracies, backing up my story with quotes from MSDN, Wikipedia, and actual screenshots, trying to give him a bit of a reality check about his knowledge on 3d programming. Surprisingly enough, despite the overwhelming evidence, the guy insists that he is correct, and throws in some more ego-trip stuff to boot, implying he’s so much more knowledgeable than I am (while in fact ignoring most of the arguments and evidence I produce). Cognitive dissonance at work, I suppose. I wonder how this discussion is going to end. He should have stopped posting many posts ago, because by this time, he has made himself completely ridiculous. He does not seem to understand that polygons are clipped in the pipeline, and insists that vertices are merely rejected. So I tried to explain things like I was talking to a 12-year old, showing an image of a single triangle being clipped to two sides of the screen, resulting in a polygon with 5 vertices rather than 3. I wonder what his explanation will be for these two new vertices, if all we can do is reject vertices.
But, enough about that for now…
Let the data structure the flow of the program
One thing I don’t believe I had mentioned yet, was the reviews of old and classic programming books on Mike Taylor’s blog. Take this one for example, on Elements of Programming Style, by Kernigham and Plauger. It reminded me of this blog that I have written earlier. In that blog I point out that even very old books and articles on programming still have some great wisdom in store for present-day programmers. In fact, in that blog I even say this:
What you should be doing is prototyping. ‘Grow’ the software, evolve it. Especially with less-than-trivial technologies, there often is no way to create a detailed design of the inner workings, without understanding the technology first. For example, if you need to interface with a piece of hardware… How do you communicate with the hardware? Is it event-based? Does it require polling? Do you need multiple threads to handle the input/output? Etc. Such issues can massively change how you design the software around it, so you need to know how the data is supposed to flow beforehand.
I always build a small prototype application first, which concentrates only on getting such core functionality working, and finding out what’s what. This generally takes only a few days at most… and once it works, you can actually create a design with relevant knowledge about the technical requirements (I actually got some pretty strange looks when I started on such a prototype, and someone told me “Shouldn’t you draw it out first?”, to which I simply answered: “I don’t work that way”. I don’t think he quite understood it). You will know how to fit this part of the functionality into a larger framework effectively. Without this knowledge, you would likely have painted yourself into a corner with the earlier design, and by the time you would have caught this mistake, you would probably have to redo a lot of the design and programming. Writing a prototype first will save you a lot of time.
Although the point I was trying to make was the value of experimenting with prototypes and gaining experience from that, the example I used also describes the philosophy of letting the data structure flow of the program. This is one of the most important concepts that I apply when I design software functionality. Most of what I write is very performance-critical (realtime processing of streaming video and other input, 3d rendering and that sort of thing), and a bad design can be suicide in terms of performance. If you have to copy big chunks of data around more often than absolutely necessary, or if you have to convert them from one format to another, or when you have multiple threads/cores being held up until something else completes, this could make the performance a great deal worse than a proper design.
And sure enough, Elements of Programming Style, written in 1978, proposes as one of its rules: Let the data structure the program. That is more or less what my example was saying as well. You should start by looking at what data you will be using in your program, and then structure your program around it, so that the data can be passed through the program as efficiently as possible. It seems that a lot of people think about what they want to do, when they design classes and interfaces, but they forget to think about how they are going to do that. And if you don’t know how to do it, make a prototype first and find out.
And, in another blogpost, Mike Taylor also mentions the “No silver bullet” article himself, in a similar context to the one of my blogpost: that new technologies come and go, but never really have a substantial impact on the real work in programming, namely designing algorithms.
Now that I’m on the topic of old books and articles anyway, I can also sneak in James Hague’s blog that I mentioned at the start. He seems to blog about similar things as Mike Taylor, and in fact, one of his posts also mentions the same blogpost that I landed on initially.
I’m not sure how to cover his blog… Besides, this blogpost is already getting quite long… Funny enough, one of the first things that stood out for me is that most of his blogs are quite to-the-point, and his blogposts are generally so short that they fit on my screen completely. Perhaps I should try to write more like him.
I think I’ll just wrap this up by picking out a few blogposts quickly.
Apparently he shares some pet peeves of mine, such as using terminology like ‘word’ wrongly, and he’s not too fond of the UNIX world still living like it’s 1970. Or blind adoration of technology in general for that matter. Since we know, or should know that there are upsides and downsides to most technologies.
Well, I think I should stop now. There are just a lot of interesting posts on his blog. I’ll leave you with one last one that I quite liked, not in the least because the original Need For Speed is one of my all-time favourite games.