Universal Programming
Whenever there is no specialized application available for our tasks (or too expensive), we have two options: Those who have the means can have one tailor-made to their needs. Those who do not have the means need to resort to either spreadsheets, an end-user database system or maybe an online service that fulfills an acceptable part of the requirements. There is no realistic way today an average user can “tell” a computer what she or he wants it to do the same way she or he could tell that to another human. Only specialists are able to create new functionality, average users have limited means to implement their ideas and needs.
Havel is a universal language, meaning it does not only support information expression but also the creation of new functionality, you can write processing instructions in Havel, a.k.a. programming. Havel does not use a secondary language to do that (as HTML does with JavaScript) but has processing instructions built-in.
Processing instruction organically fuse with information in Havel, there is no conceptual difference between e.g. a function and a concrete entity. The only difference is how the interpreter and the runtime environment handle information.
The declared target of Project Samarai is that every user who can use a smartphone will be able to create new functionality in Havel – at least to a certain degree. We believe that considering the nature of the language and the fact that most interactions with the language will be graphical rather than textual, it will be possible to open the programming facilities to a vastly bigger crowd of users than it would have been using a traditional programming language. The fact that users will not have to learn another tool or language will help to lower the inhibition threshold and create a much steeper learning curve. Havel’s semantic background and some of its advanced language features, i.e. universal modularity, allow for new concepts of how functionality is created.
Even if some users will not be able to create functionality themselves, it will often be much easier to extend own information models with functionality than it would be with traditional approaches. The semantic nature of Havel allows functional modules to be very flexible with the kind of data they can process. For example, a module that has been written to order items at a specific web-shop should be able to accept input from information models it has not been specifically designed for as long as they can agree on the same underlying classifications. Even if not, in many cases a user could create a translation-expression that will “explain” the foreign model to the functional module.
Functionality expressed in Havel can be loaded into connected runtime environments called “Brains”. Brains act in a similar fashion as traditional services or daemons. It is therefore relatively easy for users to create their own, customized services; be it shops, organizational centers or connected knowledge bases. Brains, together with protocol-free communication, are the technologies driving semantic social networks.
This post is part of a comprehensive introduction into SRDM, graph languages and Havel.
Continue reading: Protocol-Free Communication
Σχόλια