[Chicago-talk] Good Post on PerlMonks

Steven Lembark lembark at wrkhors.com
Fri Apr 9 11:10:31 CDT 2004


> Yeah, well, it's a marketing issue. It doesn't matter
> that perl is compiled to bytecode before execution,
> because it's always compiled to bytecode before
> execution.

So is C.

If people as me this I reply by asking what the
output of a C compiler, say gcc, is. This usually
gets me "object code".

bzzzzzzzzzt...

care to try again?

C compilers output assembly language either for the
local CPU (native) or another (cross compiler). The
assembler produces relocatable object; the linker
produces an executable.

Point is that perl[45] and gcc work in the same way:
they both compile and then call the assembler as a
convienence to the user. The difference between them
is that C stores the assembler's output perl runs it
immediately and discards it after use. Given the speed
of today's processors there is little or no real
differeence between these approaches in most realistic
situations. For the few times it really matters you
can easily push portions of your code into C and use
them via something like inline.

Perl6 changes that becuase Parrot is language-agnostic
and has its own assembly language. At that point perl6's
output is parrot assembly that gets assembled to parrot
object and stored. Call it "bytecode" or "machine language",
they are the same thing: output that directly drives the
hardware at the register level.


> perlcc doesn't count.

Fine, because it has nothing to do with anything.

> All the rest of the world's gonna see is that
> 1) you have perl source and then
> 2) you run that source.
>
> Just screams of being an interpreted language.

Then part of our task is to educate people on the
difference between interpreted languages (re-read
the for loop 1000 times) and compiled lines like
C and Perl (compile the loop once execute it 1000
times).

> But I've said for years that Java is basically just
> perl with better marketing.

Actually, it isn't. The main difference between
them is that Perl is a high-level language, Java
isn't.

Quick: what size integer is necessary to store the
offsets for DNA bases in M.musculous hemogloben?

Dunno?

Second question: why should you have to care in order
to utilize the information? What if elephant hemogloben
is the next thing you study and it's longer?

The normal approach to this in Java is to use
container classes. Most of these are based on
hashes and end up putting sync points into the
code because java hashes have semaphores in them
(last time I looked at it at least).

Great. So insted of using native types you end
up with an extra layer of computation just to
avoid stepping on yourself.

Try this instead: Perl stores its data in a strongly
typed, encapsulated object. The base data type is a
highly-optimized, internally supported container.
So, instead of worrying how Java container classes
integrate with other layers of your code, in Perl
you just program with native objects and be done
with it.

Can't see the downside of better encapsulation, native
object support, and -- oh yes -- it's quite fast and
more portable.

The OO model in Perl is also clener than Java's
since it doesn't break the "classes define behavior"
rule. In C++ and its derived languages (e.g., Java,
Python) classes define data. This is where diamond
and single inheritence, interface classes, and the
inability to easily copy objects all come from.

Because the other languages define data along with
behavior, you cannot "rebless" an object. This gets
into lots of copy and re-initialize issues if you
need to modify behavior on the fly (which is hugely
useful in realistic parsing situations).

> No one ever listens, though.

Keep buying them beer until they do.

--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 888 359 3508



More information about the Chicago-talk mailing list