Forum comments in chronological order

Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.

May 2013

Interesting essay with some valid points, but the context lacks depth: it is one thing to do this because it is a hobby, quite another if one must walk the very delicate line of writing code easy to debug in consideration of others, because one is an entrepreneur, racing against the clock. "When are we going to ship?"

You are probably privy to the Zen of "software is done when it is done!", which means that writing quality code must necessarily avoid cleverness in favor of maintainability: if one is an entrepreneur, one must eventually ship, or the startup will bust.

Rule of clarity: clarity is better than cleverness

"Because maintenance is so important and so expensive, write programs as if the most important communication they do is not to the computer that executes them but to the human beings who will read and maintain the source code in the future (including yourself)."

http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877610

Rule of representation: fold knowledge into data, so program logic can be stupid and robust

"Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. To see this, compare the expressiveness and explanatory power of a diagram of (say) a fifty-node pointer tree with a flowchart of a fifty-line program. Or, compare an array initializer expressing a conversion table with an equivalent switch statement. The difference in transparency and clarity is dramatic."

...but if you are really, really smart, make a complex thing simple! Can you go the other way, can you effectively simplify complex things? That is true smarts, because it is incredibly hard to do, and requires one to be extremely smart, knowledgeable, and experienced. Not very many people can do it, even among the smart.

Rather than parsing the replay routine and doing all this analysis, would it not have been cheaper to just extract the data, and write one's own replay routine?

I mean, most of the $1000-$1003 tunes were made in a limited set of music programs, were they not? And $1800 tunes, there is only one culprit, Future Composer, whose format should be well understood, well enough to construct one's own relocatable replay routine (if using Future Composer's own relocation capabilities is not desired). That should cover 90% of tunes out there, should it not?

AnonymousWed 8-May-2013 20:44

What C=64 code really needs is support for executable and linking format ("ELF"). Writing ELF headers from Turbo Assembler is no problem, but something should be able to read and parse the global offset table ("GOT"), which is exactly what is needed here for all these SID tunes (not the data itself, of course, but for a truly relocatable replay routine).

So maybe a little "shim" routine which would act as the runtime linker for dynamic objects, ld.so.1?

Hmmm, that might be a cool next project for me to implement, hmmmmm...

I love your work and your website; I do hope you make other tunes with a similar orchestration in terms of the waveforms used. I hope to build something like this myself when I get the time. You're an inspiration!

In addition to the points mentioned above, I'd like to point out that some skimming is *good*.

For example, say a string literal is being passed in a function call. In essence, there are two bits of information for a programmer to be aware of:

1. A string literal is being passed2. The contents of the string

Now, it is *right* that those things can be considered separately. It's right that I can saccade past the contents of the string if right now I'm not interested in that argument, and need to examine another argument to the function more closely.

It is wrong to be forced every time to track my eyes across carefully, and find the closing quote, before I can look at the next argument to the function. These little inefficiencies add up.

The analogy with a novel is false. A novel must be read in a linear fashion. For most modern code paradigms it's not even clear what linear would mean (a source file, a stack trace, an inheritance hierarchy?). Furthermore the English language does not have the same kind of formal syntactic structures as code: function calls, literals, operators, macros etc are not merely different kinds of words.

Well, it is the age of information. Noone said it was the age of wisdom.

AnonymousSat 18-May-2013 14:08

"yes" program , produced in 2009 !

Thank you David McKenzie for your contribution to open source community !

I am just wondering what in your background that enabled the FSF to accept such worthless contribution ?

Member of what masonic lodge or what church or son of a war hero or billonarties you have to be so they accept that piece of crap ?

For reference:

yes command - otputs a line on tty until killed !

coded and added to Linux in 2009.

Actually, "yes", which is part of GNU coreutils, has been around since, like forever, being an implementation of the same-named Unix command.

David MacKenzie is the author of many of coreutils' commands, including chgrp, chmod, chown, date, dirname, expand, fold, ginstall, groups, head, mkdir, mkfifo, mknod, nice, printenv, printf, rmdir, stty, su, tty, uname, unexpand, and obviously yes; and is co-author of many others. But he is probably best known for autotools, which is one of the most central pieces of free software, as any distribution maintainer could tell you.

It also occurs to me that you've had a bit of a free pass with the "seeing the woods for the trees" comment. It's the kind of statement that seems intuitively right, and most programmers at first glance would consider it to be important. But on reflection, I don't believe it is important, or even correct.

For any sufficiently complex program, abstraction is incredibly important.

When I'm writing a class I should be concerned with just what that particular class does. And in terms of calling other classes, it should be safe to forget how they internally work. If I can't do this then this implies poor design and a creaky system. And needless to say, there should not be global variables, or shared states. I should be able to focus on a single method at a time because everything is so neatly encapsulated.So being able to work at the "trees" level is actually an ideal.

Now I'm sure you'll say that what you mean is the big picture: an awareness of what the whole shebang is doing, and is for. But again, for sufficiently complex programs that level is far above the level of actually looking at source code. Understanding the big picture, and your preferences for displaying code, are very far removed.