Intro to Sixy Perl

Introduction to Sixy Perl

Sixy (6'y) Perl promotes a broad world view about language, software and development. Newcomers to the Sixy community often assume Perl6 is an ordinary IT product - an upgrade of Perl (it is, and it isn't) or a new product added to computer science's menagerie of exotic entities (it is, and it isn't). So we get repeated questions that are based on assumptions that Sixy Perl is like something else. The answers to these questions are also often "it is and it isn't", which is confusing as hell, and can irritate some delicate psyches to the point of heated huffiness.

This is a short introduction to the Sixiest computer language in the world, and why things are the way they are.

The Ideal and the Real.

Previous incarnations of Perl (1-5) were defined by the software (compiler / interpreter) that took a script as input and did things. When at one point in time it seemed the software might fork (for Windows and Unix), Larry Wall (Perl's inventor/guru/prophet/king) insisted on a single implementation. The language was defined by the implementation.

This was good because any Perl script / program would run identically on any OS, if the OS was good enough. Learn Perl in Linux, and use it in Windows, or Apple OS. (Multi-platform systems are now ubiquitous, but Perl was the first to show the way.)

Because the implementation defined the language, what worked is what the language should do. So if a programmer thought something should happen after reading the documentation, and it didn't happen that way, then the result was a feature, not a bug, of the interpreter and the documentation was ambiguous.

In this sense, the ideal Perl (what we think should happen after reading the documentation) and the real Perl (what the interpreter does) were/are the same.

But identifying the definition of the language with its implementation was not good because there was no way to test other ways of achieving the same goals in the interpreter as it was difficult to define what 'the same' meant. In addition, smart things at one point in the evolution of the language turned into hacks, and then into kludges. And the kludges began to slow down growth.

Deciding whether a language is an abstract thing or its instantisation is a dilemma computer scientists have faced from the appearance of the first high-level languages. A natural answer is to separate the ideal from the real: a definition of the language (written in some formal, legalistic way) and an implementation (eg., a compiler). If the compiler does not do what the language designer said it should do, then the compiler is wrong.

Except ...
Not everything that a designer thinks of can be done (eg., too slow, too much memory, unsupported by current hardware);
Not everything that a designer thinks of should be done (eg., subtle conflicts with other parts of the language, implicitly assumes a halting problem solution);
Not everything that an implementation does was defined by the designer;
Not everything that is possible was thought of by the designer;
Not everything that can be designed can easily be expressed in words.

Experience in software development has shown that there has to be a process of iteration between design and implimentation. And pragmatically, mallable design wins out in speed an popularity over elegant design.

Plain words can explain most things, but not everything. It is possible to show something happens without being able to describe it unambiguously (try describing a sine wave in words as opposed to a graph). A code example and the expected result is better than a legalistic, or even a mathematical, description.

Suppose too that the documentation is ambiguous at some point, and two implementations do subtly different things, each of which is consistent with the documentation. Which is correct? Or are both correct? Something else, some benchmark, is needed to break the deadlock.

Sixy Perl deals with all of these issues by having an ideal, a real, and a benchmark.

The "ideal" is a definition of the language, which is called "Perl6". Since evolution is inevitable, there will be re-births of Perl6, which will be labelled using letters. In fact Perl6 has gone through several iterations of design change and implementation before a version was considered stable enough to let loose upon the world. And because for YEARS everybody wanted (pleaded/implored/demanded) to know when Perl6 would be released, the designers said 'Before Christmas'. So the first release is called Perl6.c and was released around Christmas 2015.

The "real" is the implementation. The first fully working implementation is Rakudo. There were previous implementations, a notable early one being PUGS. There are other implementations. The implementers of Rakudo are not finished working on the software. It needs to be faster, smaller, more complete, etc etc. Implementers can use a numbering system consistent with their idiosyncracies (PUGS updates were labelled with an increasingly precise pi).

The "benchmark" is the test suite or roast. If an implementation can process all of the pieces of code in the test suite and produce the results defined in the test suite, then it has been roasted. And a roasted implementation is a true implementation of Perl6.

Suppose two true (roasted) implementations of Perl6.c (for example) process some arcane code but produce different results? In the Sixy world, both can claim to be true implementations. That is, unless or until the Perl6 designers decide on the results that code *should* produce and include a snippet into the test suite. The suite is updated (not necessarily the language definition), and all implementations have then to conform.

And that is why in the Sixy world, we have Perl6.x, Rakudo.yyyy.mm, and a Roast suite.

In terms of speed of evolution, time will tell, but it might be expected that changes will be:
- slow for Perl6
- moderate to fast for Roast (initially, slowing quickly)
- rapid for Rakudo.

The implications of changes in Rakudo for software that sticks to code tested in Roast will be zero in terms of results, but should be positive in terms of speed (faster) and footprint (smaller).

Welcome to the Sixy World of Perl.