Why Cawen ? Why using it ?
“My biggest contribution to the software world is that I never invented yet another programming language.” Jerry Weinberg, septembre 2010
The process that led to the creation of the language has been both naive and pragmatic.
A few years ago, we realized that 80 % of the software developments in which we had been involved were dedicated to simple data handling : acquisition, validation, recording, transformation, etc…This would not be problematic if we had not experienced that this kind of development was often time consuming, almost never reused, redundant, particulary error-prone and expensive to maintain, and, from the coder point of vue, terribly tedious…
To help improve the production of such applications, we decided to design a language specialized in basic data management : some kind of swiss army knife, an all purpose encoder/decoder. The pseudo code had to be expressive enough to represent all types of format and translation as a very concise xml tree. Given that it was expected to process huge amounts of data, it had to be particulary efficient.
As we added more and more features and targets to the initial project, we understood that we where designing an all-purposes language…Yet another ?
Why adding an extra floor to the Babel tower ?
All-purposes languages are numerous and their users are usually very satisfied with the one they master best. Then why bother to propose a new language ? To further illustrate our approach, let’s describe our personnal vision of the current state of the art :
- There is an enourmous expressivity gap between interpreted and compiled languages.
- There is an enourmous efficiency gap (execution times and memory consumption) between interpreted languages (Java included) and compiled languages.
- For a long time, there has been a clear trend towards the speeding up of developpement to the detriment of the efficacity and/or the quality of the deliverables.
Software industry may be the only human activity in which, to get the same service, the induced resource consumption keeps growing : Could one imagine that an aircraft manufacturer would launch on the market a plane with an extremely automated and simplified flightdeck but that would use 3,4 or 200 times more fuel and would fly 10 times slower that the models of the previous generation ?
This sacrifice of service efficiency for usage simplification is a lasting trend in the supply of new programming languages.
If this choice can be justified for some technical or functionnal niches, it most often leads to developper’s infantilization, service degradation and additionnal costs : a wrong initial choice results in server upgrading or replacing and even to the rewriting – in whole or in part – of the application in C/C++.
Furthermore, performance and energetic consumption are highly correlated. More than about the ecological footprint of IT business as a whole – even if it would be wise to care about – the IT actors get more and more concerned about their electricity bill.
A this stage of the project, it seemed clear to us that the creation of another all-purposes programming language could only be justified if it would represent a substantial progress in these two directions : power of expression and performance.
What about C++ ?
Compiling functionnal languages still being unjustly unknow, this is C++ that naturally comes to mind when one speaks about both expressivity and performance.
We implemented the first version of our universal coder/encoder in this language that had faithfully served us all through our developer’s careers…But we soon realized that its templating system, which we had to use intensively, was definitively too rigid for what we had in mind. This rigidity leads to redundancy and one of our top goals was to eliminate redundancy.
Developers have to solve dozens of algoritmic and functional issues daily. Quite often when they use C++ and when they have to leave the beaten track they must cope with an aditional problem : explaining their needs in a complex and deliberately closed syntax. And this issue is here to stay for C++ promoters, version after version, choose to respond to every new functionnal need by a grammatical extension.
- Cawen had to go further than C++ in brevity, clarity and creative freedom.
Moreover, C++ does a lot of things by default (constructions, destructions, exceptions,…) that should be left to the developer. All these “behind the scenes” choices and processings reduce the potential of optimization of a C++ application. Average C++ performance stay well below C.
- Cawen had to go further in terms of runtime effectiveness.
Return to the sources
To meet this ambitious set of specifications we started thinking about generating code in a pre-existing language : what dynamic could we unleash by associating one of the more efficient but less expressive all-purposes languages, C, with the best macro processor language, M4 ? Rather than proposing a new language, why not proposing three languages in one package : C, M4 and Cawen ?
Why using Cawen
A macro processor much more powerfull than the C preprocessor
One purpose of our work was that coding Cawen that writes Cawen code becomes as easy as writing Cawen code itself… If C++ can be schematically described as the meeting of C and object-oriented programming, Cawen can be defined as the association of gnu M4 and C…Or as a tool to easily write clear and efficient C code. It may be noted that to give an easier access to M4 power, we added a few dozens builtin functions and communicated their code to gnu M4 maintainers.
No added runtime processings
With Cawen, everything happens before C compilation. Only those treatments that have been explicited by the developer are executed. C performance is thus preserved.
No “turn-key” services but a lot of basic tools in a building kit
By default, Cawen does not provide any of these complex services that developers got used to, as programming languages evolved. Instead, it offers Cawen coders enough basic functionalities so they can create their own version of these services that are no longer intrinsic characteristics of the language but user developments like any others.
For example, Cawen :
- Does not call a destructor when the scope of a variable ends, but you can write your own automatic cleaning policy (in govel, the first container library of the language, this policy is coded in a few hundred Cawen lines).
- does not offer exception handling, but you will be able to build your own mechanism without too much effort.
- does not have a proper syntax for operators overloading but you can implement your own version of this functionality.
- knows nothing about objects, inheritance, function overloading, but…
An as-light-as-possible and homogeneous syntax to be assimilated easily and quickly
Cawen includes C99 and add 37 keywords and 6 operators. Thay might sound a lot but
- each one of these symbols stands for a simple functionality
- it reflects one design choice : it is better to offer a lot of basic tools than a handfull of complex concepts and services.
A limited technological risk
Every project manager who chooses to use an emerging technology takes some risks that cannot be neglected. Amongst others, the risk that this technology does not stand the test of time and that its promoters stop supporting it or the risk of becoming hostage to the skills and availability of a few specialists.
The very nature of developing with Cawen reduces significantly such risk-taking : the Cawen preprocessor produces clear (and soon automatically commented) C code. That is to say source files that are maintenable in themselves.
When you choose Cawen, you can decide that you are only interested in getting the generated C. It is a way to escape from the inherent constraints of a new technology (training, development environments setup,… ) and access as well to a more efficient application delivered more quickly.