Software Development

You can indeed use a different return value that would take this into account. Or use a callback or closure and let it make the determination. Whatever option you choose, it adds complexity. And although code duplication isn't that bad as far as the code is concerned, it does mean that I have to maintain two versions of the same thing. That's usually a maintenance nightmare.

One of the things I hope to be able to make possible (and is in the plans) is the ability to change the internals of a component to suit specific needs. I can provide intermediate data as an output. Or I can simply change this one specific version while keeping the original intact. When programming, we can override functions, but not code. With my system, you can override everything, especially the internals of other components (because they're represented internally as data just like everything else). So I could use the same component for value comparison, but change one little part of it for how I want to use it. That way, the originals stay intact and you only need to maintain the changes and not two whole versions of the internals of a component.

Better than that, I can supply outputs for intermediate results. How often does it happen that you do some computations and provide a result, but in a certain special case, you need to make ONE extra check that could change that result? And how many times do you no longer have the intermediate computations? So you need to recompute them. This is happening right now with the value comparison code. I will find a way to fix it. But if I were using components, I could just provide outputs for XType (the collapsed version of my types). I could then do some extra checks on those data structures if I need to. If I use this same component elsewhere and I don't use the XType outputs, then those XType's will simply disappear and that part of the internal network won't be created at runtime. This is possible because at compile time, unconnected terminals (outputs) delete everything behind them until it reaches a connected component. Anything sent to the unconnected data path is simply deallocated and its memory reused for other components.

Another way to look at it is this. Say you have a function with two arguments. One is the input and the other is a reference to memory where the function can store the intermediate result. If the caller doesn't need the intermediate result (supplies a NULL or undefined reference), then the code that supplies the intermediate result won't be compiled. The code need not check for NULL's either. The compiler will deal with it by providing two different versions of the code. With current languages, this isn't possible because you supply arguments with variables and it's impossible to tell if it won't be used afterwards (though you could check specifically for NULL constants though that doesn't resolve the case where variables contain NULL). With networks, you have a clear and visible connection, or you don't. If you don't, then you know with 100% certainty that it won't be used. Also, the second argument should instead be a return value. Without being able to return multiple values, and being able to tell when and where return values are used, this is even more unlikely in current languages.

Another example of where I'd need intermediate results is when connecting components. If the types of the input and output are the same, then no problem. If they're different, then I need to check if the input is an enumeration. If it is, then I need to check if any member of that enumeration is of the same type as the output. So what's the intermediate data that I need? I need the XType of the output so that I don't need to recompute it every time I check each entry of the enumeration. But I only need it if the initial type comparison failed and it ends up being an enumeration. I'm caught between computing the XType at the beginning when I may not need to, or recomputing the XType when doing the extra checks. In both cases, I'm doing certain computations for nothing.

There are ways to get around this of course. But it's not simple no matter what. I'm guessing many language implementers must have gone through this. They see advantages in their new language that they cannot use during the initial implementation stage. I still can't wait to put all this together. Working on enumerations right now (needed for booleans). After that, it's testing different component network configurations.

Comedy or Unfunny?

This following part should be another blog entry, but I'll just tack it on here. I've noticed recently that it's impossible to tell if something is written as a joke or not for anything relating to computing. Take a look at this. Is that real or a comedy? I can't tell. How is one supposed to tell if something is absurd? Outside of computing, there are certain things that are taken for granted. Anything that goes against conventional wisdom by great amounts is probably a sign of sarcasm or of a comedy routine. In computing, that just doesn't happen. I think this is because there are no accepted norms in computing. Or rather that we see MANY ideas that are outside of what we take for granted. We don't need to believe them or anything like that. Just the presence of a multitude of different ideas means that we can't tell if the person is serious or not.

This isn't about me. My material is real (Project V and the concepts behind them). But there are quite a few posts where I make some remarks where you need specific background to "get it". In fact, most of my posts have these kinds of remarks. But it mostly falls flat (or come out dark) because even if you have that background, there's no history of computing being funny. There's no framework that would tell someone that a joke is being set up.

Am I the only one who sees this? I don't know. Just thought it was a strange situation.