Pourquoi un nouveau langage ?

Pourquoi Cawen ? Pourquoi l’utiliser ?

“My biggest contribution to the software world is that I never invented yet another programming language.” Jerry Weinberg, septembre 2010

Pourquoi Cawen

La démarche qui a abouti à la création du langage a été à la fois naïve et pragmatique.

Il y a quelques années, nous avons pris conscience que 80% des développements informatiques auxquels nous avions participé étaient consacrés à des traitements simples de manipulation de données : acquisition, validation, consignation, transformation, etc… et qu’ils étaient bien souvent chronophages, intégralement jetables, redondants, particulièrement coûteux en maintenance et, du point de vue du développeur, terriblement fastidieux…

Pour contribuer à améliorer l’implémentation de telles fonctionnalités, nous avons décidé de concevoir et développer un langage spécialisé dans le traitement basique des données : une sorte de couteau suisse, un décodeur/encodeur universel dans lesquels tous les formats de données et toutes les transformations imaginables pouvaient être exprimés sous forme d’une arborescence xml extrêmement concise. Étant appelé à exploiter et produire d’énormes masses de données, il devait être sobre en mémoire comme en cpu.

Au fur et à mesure que le cahier des charges s’enrichissait, le projet initial s’est transformé en création d’un langage généraliste à part entière.

Pourquoi donc ajouter un étage à la tour de Babel ?

Les langages généralistes sont légion et leurs utilisateurs sont généralement très satisfaits de ceux qu’ils maîtrisent le plus. Pourquoi donc proposer un nouveau langage ? Pour éclairer notre démarche, voici, en quelques mots, notre vision de l’état de l’art :

  • Il existe un écart énorme d’expressivité entre langage interprétés et langages compilés.
  • Il existe un écart énorme de performance (temps d’exécution et consommation mémoire) entre les langages interprétés (Java inclus) et les langages compilés.
  • La tendance dans l’offre de langage de programmation a longtemps été d’accélérer les développements au détriment de l’efficacité des applications produites.

L’industrie du logiciel est probablement la seule activité humaine où, à service constant, la consommation de ressources induites ne cesse d’augmenter : Peut-on imaginer qu’un constructeur aéronautique mette sur le marché un avion au poste de pilotage extrêmement simplifié et automatisé, mais consommant 3,4…200 fois plus de carburant et volant 10 fois moins vite que les modèles de la génération précédente ? Ce sacrifice de l’efficacité du service au profit de la simplification de l’utilisation est la tendance de fond de l’offre en langages de programmation.

Si ce choix peut parfois se justifier, dans le cadre de certaines niches techniques ou fonctionnelles, il conduit le plus souvent à l’infantilisation du programmeur et à la dégradation du service. Et quotidiennement, provoque des surcoûts de production et de maintenance : un mauvais choix initial aboutit au remplacement, à la mise à niveau des machines ou à l’agrandissement du parc voire à la réécriture de tout ou partie des applications en C ou C++.

Par ailleurs, performances et consommation énergétiques sont fortement corrélées. Plus encore que de l’impact écologique de l’industrie informatique, dont il serait pourtant sage de se préoccuper, les décideurs du secteur se montrent de plus en plus soucieux de la consommation électrique qu’elle engendre.

Le positionnement de Cawen

A cette étape de notre projet, il nous a semblé que la création d’un nouveau langage généraliste ne se justifierait que s’il représentait un progrès tangible dans ces deux directions : puissance d’expression et performance.

Et le C++ ?

Les langages fonctionnels compilés restant dans l’ensemble injustement méconnus, c’est le C++ qui est le plus naturellement cité quand on parle de combiner à la fois expressivité et performance.

C’est d’ailleurs dans ce langage, qui nous avait fidèlement servi tout au long de nos carrières de développeurs, que nous avons choisi de rédiger la première version de notre encodeur universel… Pour constater assez rapidement que le système de template, le sous-ensemble syntaxique que nous étions appelés à utiliser le plus, se montrait beaucoup trop rigide pour ce que nous avions à l’esprit. Cette rigidité entraînait une redondance que nous avions dès le départ décidé de réduire au maximum.

Le travail du développeur consiste à traiter des problèmes d’ordre algorithmique et fonctionnel. Bien souvent, avec le C++, dont la syntaxe est complexe et volontairement fermée, le développeur, dès qu’il doit sortir des sentiers battus, fait face à un problème supplémentaire : expliquer à C++ quel est son besoin. Et ces difficultés vont croisssant, car les promoteurs du langage choisissent de répondre à chaque nouvelle demande fonctionnelle par une extension grammaticale.

  • Cawen devait aller plus loin que C++ dans la concision, la clarté et la liberté de création.

Par ailleurs, C++ procède par défaut à enormément de traitements (construction, désallocations, exceptions) qui devraient être du ressort du développeur ce qui réduit d’autant la marge d’optimisation. Si bien que, quoiqu’on puisse lire sur la toile, les performances du C++ restent significativement en deçà de celles du C.

  • Cawen devait aller plus loin en terme d’efficacité à l’exécution.
Retour aux sources

Les exigences de cet ambitieux cahier des charges nous ont orientés vers la génération de code dans un langage préexistant : Quelle dynamique pourrait-on enclencher en associant le plus efficace – mais le moins expressif – des langages généralistes, le C, au meilleur des langages de macro, le m4 ? Plutôt qu’un langage pourquoi ne pas en proposer trois : le C, le m4 et Cawen ?

Pourquoi utiliser Cawen

Les avantages concurrentiels
un mécanismes de précompilation plus puissant que le préprocesseur C.

Le but étant qu’il soit aussi facile d’écrire du Cawen qui écrit du Cawen que d’écrire du Cawen proprement dit… De même que l’on peut définir schématiquement le C++ comme le fruit du C et du concept objet, Cawen peut être décrit rapidement comme l’association des langages GNU m4 et C… Ou bien encore comme un outil permettant d’écrire facilement du C lisible et efficace. Il est à noter que pour faciliter l’accès à la puissance de m4, nous l’avons enrichi de plusieurs dizaines de fonctions builtins dont nous avons ouvert le code.

Aucun ajout de traitement à l’exécution

Avec Cawen, tout se passe à la précompilation, seuls les traitements explicités par le développeur sont exécutés. Les performances du C sont ainsi conservées.

Pas un langage clef en main mais un kit de construction

Cawen n’offre par défaut aucun des services complexes auxquels se sont habitués les développeurs au fil de l’évolution des langages de programmation, mais il met à leur disposition suffisamment de fonctionnalités de base pour qu’ils puissent les recréer à leur guise. Ces services changent de statut : ils passent de caractéristiques intrinsèques du langage à celui de développements utilisateur à part entière.

Par exemple, Cawen :

  • ne procède à aucune libération automatique de variables en sortie de portée, mais il permet d’écrire très facilement sa propre politique de libération automatique (par exemple, dans govel, la première librairie de containers du langage, cette politique est codée en quelques centaines de lignes de Cawen).
  • n’offre pas de mécanisme de gestion d’exceptions mais vous pourrez sans trop de peine en coder un.
  • n’a pas de syntaxe propre à la surcharge d’opérateurs mais vous pourrez implémenter votre propre version de cette fonctionnalité.
  • Il ne possède pas de notion d’objet, ni de dérivation, de surcharge de fonctions mais ….
Une syntaxe la plus homogène et la plus légère possible pour être assimilée facilement

Cawen inclut le C99 et y ajoute 37 mots clefs et 6 opérateurs. Ce nombre peut paraître élevé mais

  • chacun de ces symboles recouvre une fonctionnalité simple
  • il reflète un choix de conception du langage : plutôt que d’offrir une poignée de services et de concepts complexes, Cawen propose de nombreux outils élémentaires.
Un risque technologique limité

Tout responsable de projet qui choisit d’ adopter une technologie naissante prend des risques non négligeables, entre autres, le risque que cette technologie fasse long feu et que ses fournisseurs cessent de la maintenir ou encore celui de devoir confier le suivi technique du projet à une poignée de spécialistes.

La nature même du processus de développement en Cawen est à même de réduire significativement cette prise de risque : Son précompilateur produit du C clair, lisible et commenté. C’est à dire maintenable en l’état.

Un client qui choisit Cawen échappe aux contraintes inhérentes à toute nouvelle technologie (formation, mise en place environnement de développement, asservissement technique, … ), tout en bénéficiant de ces avantages : un développement plus rapide et donc à moindre coût d’une application plus efficace.