An interview with Larry Wall (LinuxVoice)

All languages tend to WORN. You might be able to discern basic Java syntax, but can you determine all of the APIs and interfaces buried underneath? You might be able to tell me the type of a Haskell function, but can you tell me about the implications for lazy evaluation? Are you sure you have all cases of C undefined behavior memorized?

Parsing syntax is like 1% of the problem of dealing with most codebases.

I know I'm part of that niche. I have perl code from 10 years ago that I go back and still understand. Of course, my code uses a small subset of perl, thus it stays rather readable (I had a python coder once tell me that my perl code was the first perl program that he could understand).

I'm a big fan of C, and I try to program perl like C code, which is probably why I never could get use to python. I developed in python for 6 months and it never caught on to me. In fact, I have a much better time understanding my perl code than I do my python code ;-)

I maintain a few perl files in the Linux kernel, and I've refused to take patches that make them more "perl like". I try to keep them as C like as possible, as that keeps them readable. You can have a look and give your own opinion:

scripts/recordmcount.pl
scripts/kconfig/streamline_config.pl
tools/testing/ktest/ktest.pl

 while (<>) {
    print;
 }

 for l in sys.sdtin.read():
     sys.stdout.write(l)

  foreach $x (@array)

  open(IN, "file") or die "could not open file";

for line in sys.stdin:
    print(line)

for l in sys.sdtin.read():
     sys.stdout.write(l)

/*************** Micro getopt() *********************************************/
#define	OPTION(c,v)	(_O&2&&**v?*(*v)++:!c||_O&4?0:(!(_O&1)&& \
				(--c,++v),_O=4,c&&**v=='-'&&v[0][1]?*++*v=='-'\
				&&!v[0][1]?(--c,++v,0):(_O=2,*(*v)++):0))
#define	OPTARG(c,v)	(_O&2?**v||(++v,--c)?(_O=1,--c,*v++): \
				(_O=4,(char*)0):(char*)0)
#define	ARG(c,v)	(c?(--c,*v++):(char*)0)

 cat script.pl
 $a=<STDIN>;
 $b=<STDIN>;
 print $a+$b;

 echo -e "1\n2" | perl script.pl
 3
 echo -e "1.1\n2" | perl script.pl
 3.1
 echo -e "aa\n2" | perl script.pl
 2

$ cat script.py
 import sys
 a = sys.stdin.readline().strip()
 b = sys.stdin.readline().strip()
 print a+b

$ echo -e "1\n2" | python script.py
 12
$ echo -e "1.1\n2" | python script.py
 1.12
$ echo -e "aa\n2" | python script.py
 aa2

$ cat script.py
 import sys
 a = float(sys.stdin.readline().strip())
 b = float(sys.stdin.readline().strip())
 print a+b

$ echo -e "1\n2" | python script.py
 3.0
$ echo -e "1.1\n2" | python script.py
 3.1
$ echo -e "aa\n2" | python script.py
 Traceback (most recent call last):
   File "script.py", line 2, in <module>
     a = float(sys.stdin.readline().strip())
   ValueError: could not convert string to float: aa

my $matrix = [
    [0, 1, 2,],
    [3, 4, 5,],
    [6, 7, 8,],
];
foreach my $row ( @{$matrix} ){
    foreach my $col (@{$row} ){
       print $col;
    }
    print "\n";
}

What "there is more than one way to do it" (TIMTOWTDI), and CPAN, helps with is whipituptude - you can write script to do your thing quickly. Compare Java, where mere Hello World is multi-page monstrosity.

The number of different ways to do something provided by a language also depends on what is included in 'the language'. The C language itself does not provide data structures such as linked lists or hash tables, or any input/output primitives. Once you add the standard C library you get the question of whether to use puts() or printf() - or sprintf() followed by puts(), and so on. Add a library for data structures and you then can choose whether to use a vector, a linked list, a tree... These combinations multiply together pretty fast to give easily 'dozens' of ways to achieve a fairly simple operation such as picking the top three integers from a sequence. With a higher-level language, more data structures and manipulation operations are part of the core language and the syntax tends to be more compact, so it is not a surprise to see many different ways to express even a single line of code.

Take Python as an example, often held up as a contrast to Perl. "There should be one obvious way to do it" is certainly a fine principle and one that Perl could sometimes take note of. But in Python too you can choose between lambdas, list comprehensions, explicit loops (of several types, with some interesting ways to break out of the loop); lists, dictionaries or perhaps tuples; and of course different ways to structure object-oriented code. Again there are easily dozens of ways to achieve a relatively simple operation. And this is a good thing.

I don't have experience with Perl 6 so I can't comment on details, but I will say that if the language includes more powerful tools like grammars, these obviously provide new ways to tackle a problem, and so several more "ways to do it".

BTW, it's also very nice to read in English with words.

Mutating syntax is a triviality for any dynamic language. You can write Perl in latin if you want.

You've misunderstood Perl 6 "private/public" semantics. I'll try to clear that up as I respond to your suggestions about syntax.

Private
=======

Almost all the Perl 6 code I've seen uses the `!` symbol for private attribute declarations. I've read many Perl 6 coders say they prefer to use it.

But the `!` is optional. One can write as you suggest for the private attribute except missing out the word `private`:

class Foo { has Task @dependencies; # declare a private attribute that's an array of Tasks }

Public
======

A public accessor is a method, not an attribute.

A method is called using `.` syntax. Thus, assuming a public accessor method called `done` has been written for a class `Foo`, one might write code such as `say Foo.new.done` and it'll work.

The typical way to get a public accessor method written is to ask Perl 6 to automatically generate it for you:

class Foo { has Bool $.done; # declare attribute, generate public accessor }

The `.` is there in the declaration to remind one of a method call.

All methods called with `.` are public method calls so I'm not seeing the benefit of using the word 'public'. And dropping the `.` would be a big backward step imo.

So...
=====

Use `.` for declaring both a private attribute and public accessor method.

Then use the same `.` for calling the method -- with associated semantics/performance (run-time method resolution that only the JIT can optimize).

Use `!` (or simply omit the `.`) for declaring a private attribute.

Then use the same `!` (or not) for reading/writing the private attribute -- with associated semantics/performance (compile-time direct attribute access that's inlinable by an AOT optimizer).

---------------------------------------------

> Using ~ for string concatenation ... is weird.

I still recall the first time Larry explained his choice. It looks like a piece of string. If this mnemonic doesn't instantly make you go "ahhh", well, you're weird. :P

---------------------------------------------

> A good language design should take best practices, and not re-invent the wheel everywhere.

Sure. It sounds like we just disagree on what best practices to focus on and when innovation is a good thing.

If that were the case then obfuscated, minified, or shrouded source code would be just as easy to work with as the original. After all if all you need to convey to a human reader is exactly what you need to make the machine do, then variable names a01, a02, and a03 are just as good as lower_bound, upper_bound, and middle. The semantics of what the code does are exactly the same either way. And you could replace all loops with if-goto, again still specifying to the tiniest detail what the machine must do.

But although the a01 code expresses exactly *what* you are getting the machine to do, it says nothing to a human reader about *why*. You could, I suppose, write code in this style and rely on comments to explain the intent, but normally it is better to use both ways of communicating, so that both the program code (through meaningful variable names, routine names, code structure and ordering) and the comments give a human reader some idea of what you were thinking and what all this highly specified, minutely detailed code is intended to be *for*.

> As Joel Spolsky said: "All non-trivial abstractions, to some degree, are leaky." Is that not the origin of the phrase "leaky abstraction"?

Ugh. Thank you for calling me out about this and doing it gently.

Prudence suggests I stop right here. But I was trying to convey something useful when I wrote the nonsense "non-leaky abstraction" and I want to have another go.

----

In 1992, Kiczales proposed a principled, general solution to the problem later popularized by Spolsky. My TL;DR version would be "build atop [something like] the CLOS mop".

http://www2.parc.com/csl/groups/sda/publications/papers/K...

----

Perl 6 adopts Kiczales' solution wholesale. CLOSish mop mechanisms drive everything from the high level down to as close to the metal as the underlying systems allow.

In particular, the NQP layer implements its abstractions of run-time VM features, and object and function interfaces with other languages, using NQP meta objects.

http://edumentab.github.io/rakudo-and-nqp-internals-cours...

----

When I used the ill begotten phrasing "non-leaky abstractions" I meant "abstractions that can, in principle, be relatively easily tweaked by users so they give correct and performant results -- ie don't leak -- for a given use-case".

> string-using code over a VM that uses NFG and a VM that uses UTF-16 is going to be able to tell the difference; either Perl6 code that expects NFG will be incredibly slow on the JVM, or calling other JVM languages is going to involve a conversion of every string.

First, let me note that I personally don't expect to see Perl 6 *officially* supporting running on the JVM for at least another year.

I think you chose well to pick the NFG abstraction as being especially prone to leakage in the sense of serious performance ramifications when Perl 6 is running on the JVM and especially when one is passing strings back and forth between Perl 6 and another JVM language.

One mitigation is that code that doesn't use character level operations, eg just copies whole strings, compares whole strings, passes strings back and forth between Perl 6 and some other JVM language, etc., could just use some type that `does Unicodey` with an appropriate encoding, eg UTF-16, rather than using Strs (NFG strings).

But yes, it's going to be interesting to see how NFG on JVM pans out. :)