That awful typeface is such a blight. I don't know why people persist using it. Still, you are right, reading it is time well spent.

[...] Early Lisps let you get your hands on everything. A good deal of that spirit is, fortunately, preserved in macros. What a wonderful thing, to be able to make arbitrary transformations on the source code.

I would love to be able to rewrite the op-code tree in a Perl program. I know it is possible, that there are modules that let you get your hands on that sort of stuff, but it's not something I've spent any time researching.

For instance, a reccurring code pattern I encounter is iterating through a list, and processing each element, but also having an if condition in that loop that can only be true once. It would be nice that once that path was taken and acted upon, to rewrite the op-tree so that the if condition just disappears and the loop tightens up and runs faster (i.e. by having more code fitting in the CPU cache). This happens to me all the time.

I do have significant reserves, however, as to what that could do to the comprehensibility of the program, both in terms of reading the code and following execution in, say, a debugger. But if it were "done right", I would use it. There are other ways to achieve this explicitly, such as falling out of the loop with the if, into a loop without the if, but then this leads to having the same code in different locations on the code. (And if you're in a tight loop, you probably don't want the cost of calling a subroutine that factors the code anyway)...

We can get rid of (or make optional) a lot of parentheses by making indentation significant. That's how programmers read code anyway: when indentation says one thing and delimiters say another, we go by the indentation. Treating indentation as significant would eliminate this common source of bugs as well as making programs shorter.

I beg to differ. I agree that we go by indentation, but everybody has their own style of indentation. The canonical way to understand code written in a style other than your own is to run it through a pretty printer, be it B::Deparse, PerlTidy or something else. Assigning semantic information to indentation is, IMHO, wrong.

For instance, the other day, I was writing some CGI.pm code to generate some tables. CGI offers some useful short-cuts for generating code, such as passing references to lists, in order to generate multiple HTML elements of the same kind, e.g.:

This will print out your INC array in a bulletted list. And you can't get much more compact than that. There are times, however, when it's just too much effort to try and pull that off, especially when dealing with nested tables, because then you have to juggle tables, TRs and tds. CGI lets you import special names, such as:

... that will define the methods start_table(), end_table(), start_TR and so forth. So I wound up using indentation to help me keep track of what was happening. The code looked something like this:

print
    $q->start_table( {-bgcolor=>'#000000', -align=>'center'} ),
        $q->start_TR( {-valign='bottom'} ),
            $q->start_td( {-bgcolor=>'#ffe0a0'} );

                foreach( @list ) {
                    # do lots of wierd stuff and emit nested tables
                }
print
            $q->end_td,
        $q->end_TR,
    $q->end_table;
[download]

Now I have no idea what Python would make of that, but I suspect it would have a fit. Creative use of whitespace goes a long way, in terms of letting you line things up correctly, to make sure that everythings comes out balanced. What is opened, is closed, what is pushed, is popped, and so on. This should not be under-estimated.

So, in practice, the way to get fast code is to have a very good profiler, rather than by, say, making the language strongly typed. [...] you need to be able to find out where the bottlenecks are.

[...]Language designers like to write fast compilers. That's how they measure their skill. They think of the profiler as an add-on, at best. But in practice a good profiler maydo more to improve the speed of actual programs written in the language than a compiler that generates fast code.

Yes! I was pleasantly surprised the first time I used Devel::DProf to find out just how infinitesimal the slowdown was when just counting subroutines. (I've never had to resort to counting lines, so I don't know if that's painful or not). I have memories of C programs taking really huge speed hits when profiled.

I have long wished for a development environment that would take the profiled output of run n-1 and use that to make informed guesses as to how the code should be generated in version n. It could rearrange the way code blocks are ordered in the output bytesteam to ensure that the code branches as little as possible, or that frequent references to different code (e.g. subroutines) are coalesced into arenas that fit on a page. There are a number of optimisations a compiler could perform if it had access to the way the code was likely to behave.

g r i n d e r