As it usually happens, UPL project is already taking much more time than I thought :) I already have written several drafts, containing basic syntax information and have some final ideas about how programming would look like using UPL.
First of all, my initial idea was to create two versions of UPL: one for stand alone programming and another - for programming inside my own OS. At this point I am not so sure that it was such a good idea. Without first testing an implemented language it would be a crazy thing to start implementing a stand alone version at once. Instead, I decided to create a program that would translate UPL code to PHP and use it for web development.
Why PHP, you might ask. Well, first of all, it is a language that I know rather well :) UPL is expected to be rather dynamic, so PHP becomes handy here as it is interpreted. Quite a lot of ideas of PHP will remain in UPL, so conversion (translation) is expected not to be very difficult. All in all, this is one of the easiest ways to test a new language.
Now, let me talk a little about the UPL way of programming. First of all, this will not be another OOP language, though it will have objects. Instead, it will inherit some features from PBP and procedural programming with modules. I decided to call this type of programming - Utility Based Programming.
Main three terms in UPL are: utility, object and interface.
- Interface is understood nearly the same way it is understood in OOP languages. The only difference is that interfaces are applied to objects instead of classes that do not exist in UPL.
- Objects are created from scratch, by being generated inside utilities or by copying another object. This idea of creating objects without classes came from PBP languages.
- Utilities are collections of procedures (called methods) that are just like static methods in OOP languages. Utilities may also have static properties. Main difference between utilities and classes is that objects may not be created from them.
*** A little bit of OOP criticism
First of all, consider that you are using some framework that provides XString objects in OOP. Framework is not a magical thing and its creators were not able to predict all the situations XString could be used for, so you might have to extend its functionality. At this point, OOP provides inheritance mechanism that should solve this problem, but what if XString changes in later framework versions? You would have to rewrite the whole inheritance tree and don't say that XString wouldn't change... Meet the reality :) Everything changes and this is a weak point of OOP as OOP developers are expected to write a perfect code which is impossible. And that is not the only problem of inheritance... It encourages polymorphism, complex code behavior and makes code hardly readable for new developer assigned to some OOP project.
Another situation with same XString... What if there is a method somewhere that requires String (without X) as argument? It is probably created by another manufacturer who didn't know anything about XString. XString and String classes are not related by a mechanism of inheritance and implement the same thing in different ways, so you would have to write some wrapper to solve this problem. If XString hasn't been written wisely, it might become a huge problem because of encapsulation (note that encapsulation is encouraged in OOP)...
***
Now, lets go back to UPL. First of all, there is no inheritance, because there are no classes. Dedication is a much better solution than inheritance, because only user (in case of inheritance it would be called a child) would depend on its supplier (parent), but user's interface itself could remain the same for its own users. Also, by using dedication, you will always see, what is done in some particular utility - there are no derived methods or properties.
When talking about objects, you can always change their behavior by adding new methods and replacing the old ones. You may be sure that objects will do what they are expected to do by using interfaces.
What about the XString vs String situation? In UPL object should be used to define complex type instances only. Those can be structures of existent simple types, database connections, network connections, I/O types and so on... Connection details and similar things should be encapsulated but object itself should return and ask for as simple data as it is possible: strings, integers, arrays, booleans... Objects should not be supplied to other objects. All control sort of work should be done using utilities. In this way even if there were two different String objects, it would be very easy to convert to one from another. More than that, using such simple objects would encourage different programmers to use same interfaces causing much less problems...
Note that in OOP there is usually a problem with class constructors, because they are not able to return a value in case of failure. In UPL there is no such problem because objects may be returned by utility methods. If something fails, simply return false instead of an object or throw an exception.
UPL is better than OOP in a lot more different ways and I will not try to cover them in this article. Instead, I will talk about this later in UPL manual.
Several more important things to know about UPL:
- Dynamic typing - there are no static types, type conversions are not necessary;
- Dynamic code - code may be stored in variables and manipulated as if it was data;
- Strict coding standard - programmer must write code in a strict way in order to be able to compile;
- Minimalistic syntax - there are as little syntax rules as possible, easy to learn.
