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.:
print $q->ul( $q->li( [@INC] ));
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:
use CGI qw/*table *TR *td/;
... 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;
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
| [reply]
[d/l]
[select] |
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.
I clearly second this. Fortran made use of indentation as
syntactic/semantic information representation. I have been
told it is a mess.
As for the essay itself: Itīs a nice subsumption of some
views on the reasons for a language becoming popular. It is
worth a read even for those that evidently donīt like Lisp
(like me). Iīm really into programming since 1987. Have
done so before, but rational programing for 14 years now.
Why did perl become my popular language?
The answer is simple: 95% because its features match my
needs best, and 5% because I saw cool people practicing
perl. It was really a shock 1995, when I (used to some
"my lang is better than your lang"), after converting from
C to C++ (feeling itīs mightier but not the right thing)
saw how perl-hackers looked at all this "which lang is the
best" with a ENORMOUS amount of peace and humor which only
could mean that they had found something.
Then I was told to do a project I wanted to do in C in perl...
I didnīt like this command but obeyed. About one week later
I was happy like a kid in a toy shop for having the possibility
to work with such a great lang.
If only there was a good Prolog<->Perl interface. (hint hint) :-)
Ciao
| [reply] |
I'm having difficulty finding a windows program for reading postscript files. Can anyone offer a suggestion for those of us who don't have our own *nix box? | [reply] |
| [reply] |
If you cannot print out the PS file directly to a
Postscript printer Ghostscript will do the job. Ghostscript is
available for Unix, Windows,Macs, and maybe some other
plattforms. E.g. Ghostscript will allow you with the "ps2pdf"
command to translate PS-Files to PDFs.
Hanamaki
| [reply] |