Motivation for Carrot in Perl 5

With Carrot you have $expressiveness


Motivation

It's a popular habit to sprinkle syntactic sugar on each and everything, not only in Perl. You'll notice the lack of such sugar in the following example. It looks more like healthy food and takes longer to chew: like a Carrot.

DIVERSITY {
        my $expressiveness = Carrot::diversity;
        ...
}
MODULARITY {
        my $expressiveness = Carrot::modularity;
        ...
}
my $expressiveness = Carrot::individuality;

Carrot is a good name for this project. Everybody has at least seen one and most readers will now about taste and texture. Compare with the underlying key concept 'systematic expressiveness'. With what? Marketing wins.

CARROTS, CARROTS, FOLKS BUY CARROTS, SPECIAL OFFER ONLY TODAY.

Some marketing is required, because Carrot.pm does nothing an experienced Perl 5 programmer would expect from a mainstream Perl module. Both 'no Carrot' and 'use Carrot' result in error messages, it doesn't export any symbols, it doesn't serve as a parent class, and it doesn't have a constructor. Only on the third level of the module hierarchy some actual work is done.

This description suggests that Carrot is about upper level management. Why would one want that other than for cracking a joke in the documentation? The answer is simple: even a million Perl one-liners don't make up an application. Perl 5 is focussed on one-liners and doesn't contain enough management 'overhead' for application development. Consequently the number of public Perl applications is negligible, though there are some prominent public examples and many in-house legacy applications. These vanishing exceptions only confirm the rule.

The chance for potentially larger applications comes at the price of what is sometimes called overhead. But 'overhead' is just a perspective - from a lower conceptual level. Every script is overhead, if seen from the point of Perl opcodes. Similarly the opcodes are a giant overhead if seen from the viewpoint of machine code. And lets not forget the viewpoint of unclean electrical signals, from which even machine code seems like pure luxury. It's easy to spot overhead by stepping down a conceptual level. The perspective alone is futile.

So what kind of 'overhead' is required for more applications written in Perl? Better line noise? More passion in riding dead camels? Project number 28,745 on CPAN? A smart while-loop, which terminates when bored? All ironic questions, of course. Applications simply require support for more than one line, more than one file and more than one author role. In other words, applications require more than what the Perl tradition offers. That's the challenge.

The mainstream Perl 5 style assumes a communication between the programmer and the computer. Ideally that speeds up execution of the program. Quite differently the style of Carrot assumes a communication among programmers. That allows for larger teams and speeds up development of the program, ideally.

Consequently Carrot breaks free from the traditional solitary attitude of Perl. Other than that Carrot is perlish. Perl is said to combine the best from several languages and its said to be extensible by its users. Carrot addresses both with general plugin-based principles. And as if that wasn't perlish enough, it does so in the (hopefully) most useful and least obvious way.

Language

Expressiveness in computer languages can't be about English or natural language, because these have different aims. The aim of natural language is communication and the aim of programming language is description of potentials. In short, a recipe is not the cake. Though for marketing reasons the contradiction has been promised ever since high-level computer languages were invented. Our product makes eating a cake the same as baking. You know how to eat? Then buy our product and without any mental effort become a star programmer.

The illusion of programming a computer by just talking to it is tempting. But it lacks plausibility: communication with another human isn't always effective, so why should the situation be better when communicating with a computer? The approach would make sense in a world where humans have become picturesque pets of machines. 'Look, how sweet, it's babbling to me.' It hasn't come that far, yet.

The point about the consequent use of English words in Carrot is the use of Latin script for symbol creation. The point isn't a literal translation of natural language concepts. Natural language has sentences, programming language has statements. Carrot doesn't change such fundamentals. At least not in this version.

Traditionally Perl is close to Chinese, because Perl promotes a pictorial composition of interpunctation symbols. Furthermore Perl 5 is highly context sensitive, which is also a more Chinese way of thinking. Chinese is a nice language and the script is beautiful. But it doesn't scale: for every scientific finding a new unique picture has to be created. That hinders fast development of new technology and expressiveness. The discussion of romanization addresses this problem. Carrot romanizes Perl.

Now, any scientific formula, be it in mathmatics, chemistry or biology is a pictorial symbol. The benefit of formulas is out of question. But new pictorial symbols take years to establish, while new roman words can be created in seconds. Blocks like packages or subroutines serve as organisational units for words. These avoid conflicts and speed up development. Introduce the new word 'print' in such a block and the discovery that millions of other programmers used 'print' differently won't be a problem.

The expressiveness in Carrot is not about the implementation of a fixed set of English keywords. It's about creation and attachment of meaning to words in general.

Perl

Perl acquired a bad reputation and since 15 years the author of Carrot faces the question why he continues using Perl. Before an answer is given, the deficits commonly attributed to Perl should be described more specifically. In short, Perl 4 left the impression of spaghetti code, Perl 5 crippled object orientation, and Perl 6 received prominent vaporware awards and is still vague in its destination. These might be rough generalizations, but they're fair enough for the purpose of this document. There is little point to match them with subtle or detailed counter arguments. For example, Carrot does bring an object oriented system, but this only confirms the fact that the one of Perl 5 is crippled.

The generalizations can be further generalized by taking a broader viewpoint. That view leads to the key property most competitors have and to which Carrot gives a perspective. Looking at the top of the page an obvious guess would be 'expressiveness' and the author would happily sell a few more Carrots. But the story takes a different turn than expressiveness.

User Groups

The broader viewpoint goes as follows. The Perl community organizes itself in local user groups. They're an important part of the culture and their enthusiasm enables fantastic conferences. For Germany there are two main listings: pm.org and perlmongers.de. They list different locations and different dates, sometimes even both wrong. Many groups are simply dead, though some are very lively and are strong enough to even have bi-weekly meetings. The situation with the user group listings reflects the reputation of Perl 4, 5, and 6. Chaotic like in Perl 4. Less useful than the average (represented by a Google search) as in Perl 5. And overly optimistic like in Perl 6. The situation confirms the validity of rough generalizations.

Knowing the reason for the mess could lead to an approach for improving the situation. External reasons aren't so plausible. Germans like order, they're heading for excellence in engineering, and rather keep their promises. In principle and at least to an extent that the user group listing can't be explained away as a matter of a lazy national culture. Seen from a technical point of view, Perl is strong in text processing, the information about user groups is text, and the maintainers should be fluent in Perl. No sign for a technical problem. It doesn't go with the stereotypes.

There seems to be no external reason, so an internal reason could be around the corner. One is, that adding information is so much easier than changing or removing it. What would happen if information was thrown out of the user group listing? Some groups are dead so that they couldn't give their consent, some won't admit they're dead and some might not be aware of the problem at all. What would happen? The volunteers involved in streamlining the listing would encounter a lot of conflicts. Because they're changing the rules of the game. Before the game was inventor-centric and all of a sudden it matters what the public might think and what potential new members experience. What gives the volunteers a mandate for a change?

Now the reason for the mess becomes more clear. The listing of user groups has no explicitly written vision or how you want to call its constitution. Which could state: no update or confirmation of information for 3 months triggers a stale flag, 3 months stale flag result in removal of an entry from the listing (including deletion of the data). Nobody could seriously complain of being removed, because the rules of the game had been mentioned beforehand. If only there was awareness for moderating change in the Perl community.

CPAN

Basically the same problem exists for CPAN, a central site where Perl modules are collected. Though the number of accumulated modules is impressive, it becomes scary once you realize the huge effort for evaluation. There is a lot of duplication but little guidance. The problem has been recognized and a rating system was added to CPAN. Unfortunately the number of ratings is negligible. A very simple approach to guidance was created in form of Enlighted Perl, a list of recommended modules for mainstream purposes. The information of Enlighted Perl is maintained and must be appreciated though it's not a general solution.

Same applies to the list of Perl packages shipped with Linux distributions. It's a pragmatic solution to consider what is actually in use.

Duplication is also a result of not finding existing modules. Their names might be AB, A::B, or B::C::A. Finding a module on CPAN doesn't imply anything. It might function or crash, have documentation and unit tests - or not. On top the number of modules is advertised. Sounds like 4-5-6. The repeated encounter of the rough generalizations again confirms them.

Modernity

The original idea behind Perl is rather simple: take some good ideas from other languages and keep adding to them. That there could be the need to cut, depose, throw, remove, dismiss, drop, abandon, or reduce features was only accepted around twenty years later. Not only too late, it was also marketed as compatibility for too long. As a consequence, Perl lacks a culture of introducing major incompatible changes and improvements; 'modernity' for short. It's a taboo in Perl. Modernity is still misunderstood as an ever growing pile of new features. But actually modernity is the opposite: an attitude of cutting down features in favor technological progress.

For example, nobody would consider a smartphone with a mechanical dialling wheel as modern. An incompatible change to the interface is required for something to become modern.

Modernity isn't a goal in itself. Modernity means to stop using limited resources on old lesser used features and concentrate them on new often used features. That convinces developers, because it also affects their resources. A sculpture in the middle of a wrecking yard of programming technology might fill conferences and books, but won't open doors into commercial software development projects.

Sure, features have been removed from Perl. But only at a rather slow rate. And one can't ignore that problematic ancient features like the Perl 4 format of package names are still present in Perl 5 which is an option in Perl 6. The generalization is that Perl is old-fashioned from many perspectives.

Look at competitors like Python or Ruby and you'll find that they are very modern. But it's not a matter of their features. It's interesting (but no wonder) to see how the communicative code style of Python goes with a political understanding and culture that leads to modernity.

Conclusion

Modernity in form of the two-year limitation for gratis support for Perl 5 releases was a big win. The move boosted development. Suddenly long outstanding critical bugs like the handling of $EVAL_ERROR were fixed. Before there was no proper error handling and bigger applications were out of question. That has changed. So not all hope is lost.

Carrot demonstrates tools for massive use of object orientation (OO) in Perl 5. It's not meant as a drop-in replacement or immediate solution for anything. It promotes dynamic thinking on top of the dynamic resource management of Perl 5. By introducing several indirections between package name spaces and all kinds of identifiers, less is hardcoded for eternity and more can be easily changed. It reduces the technical barriers for modernity, though a lot more would be required to make Perl modern.

Carrot doesn't imitate other languages, it provides a perspective that goes beyond. That justifies to still consider the Perl 5. However, nobody will start using Carrot because of its theoretical value. And just for the matter, nobody will stop using Carrot only because of its theoretical value. Applications have always been more decisive. For Carrot the reference application is the Mica Environment (to be published soon).