The Holy Grail of Programming

I don't usually post these days, since I'm way too busy to do so. But I have recently started thinking again about how to structure the ideal programming language, and perhaps implement it. Certainly, it's no easy task. So at the moment, there are basically two different directions popular languages are going: the ones that offer you more control (such that you can shoot yourself in the foot), and those that favor obscurity and portability at the loss of control. Certainly, I think the two figureheads for these languages have to be C and Java. C, because the concept of object-oriented programming is not present, yet allows control beyond the operating system layer (Not counting C++, of course, but implementing something as drastic as OOP as a second thought always leads to a confusing implementation, ala PHP). Also, let's not even mention how many times people have voiced their complaints against pointers in C (although it makes plenty of sense, espescially if you program assembly). Java, because the object-oriented model is certainly running strong, but lacks some conventions (important conventions such as unsigned integral types) that satisfy the needs of the bit-basher. So the question at hand is whether or not it is possible to mate these two, perhaps for a breif second, and create the bastard child known as the ultimate programming language.

So, of course the nerd inside of me wants to persue this. But those persuant of the Holy Grail instantly come to a startling revelation: there is a fine line between portability and control. Remeber, that as programmers, our goal is an end to our means that is as efficient as possible. In a nutshell: time is money, and for this reason, semantics is important. The semantic value of the class, for instance, can't be denied because it is a coherent aggregation of data that specifies one concept. Yet, in reality, the object is difficult to implement, and important tradeoffs have to be made. If we do, in fact, attempt to implement this functionality, the implementation may easily change semantics. For instance, if I say that a child object may have two parents, then I no longer have a list of classes where the inheiritence model is cut out and dry, and I must decide what happens when two methods conflict. Yet, is it really an issue if the parents don't conflict at all? And if they do, then the program can still theoretically have both methods, espescially if the methods are private and have no chance of being overriden anyway. Then, perhaps a dominaint method can be explicitly defined. So,let's say A and B get freaky and produce a child class, C. We could refer to C.A.doStuff(), C.B.doStuff(), or, if we for instance explicitly defined A's method to be dominaint, then C.doStuff() -> C.A.doStuff(); Is this proper? Not entirely, because now, the meaning of doStuff() is ambiguous to one of its parent classes. If C is assigned to a variable of type B, then provisions must exist that allow B to imply that (B) C.doStuff() -> C.B.doStuff(), so extra checks as far as type goes are a concern. This says nothing of method overriding, which in either case, might result in an entirely new doStuff() method being created as a result of not being specific. So naturally, this is not an optimal situation.

Yet, the idea of multiple inheritence beyond the simple interface is somewhat desirable if you want one common peice of code against fundamentally different objects, and you don't want a static class. Why not just put it into an abstract class way at the bottom of the tree heirarchy? Because in some cases, you need to take two fundamentally different segments of code and merge them. The single inheiritance model, at the same time, has direct benefits of its own. Because only one parent class exists, we know for sure that if A is the parent and B is the child, that (A) B.doStuff() -> A.B.doStuff(), and it makes overriding these methods much easier. So the debate rages on.

Now, another debate which comes to mind is whether or not interpreted or compiled code is better. Of course, the idea of merging the two into a hybrid is nothing new (see .Net, even if it is too proprietary to work on more than one platform). In my opinion, this is the best way to go. You've got to ask yourself, if you can interpret the code into a native instruction set anyway, why can't you do this at compile time? This would make the distribution of programs alot better and has significant advantages over running it in a VM.

Anyway, more to come, I feel like I'm beginning to ramble.