[Israel.pm] Language evolution
dov at freescale.com
Wed Jan 9 03:14:32 PST 2008
Personally, I have 10...no...11...make that 12 fingers. Just to be sure, I'll ask my wife - she keeps track of these things
SmartDSP OS Development Leader,
DevTech, Technology and System Organization
Freescale Semiconductor Israel
The information contained in this email is classified as:
[ ] Freescale General Business Information
[ ] Freescale Internal Use Only
[ ] Freescale Confidential Proprietary
[x] Personal Memorandum
ü SAVE PAPER - THINK BEFORE YOU PRINT
From: perl-bounces at perl.org.il [mailto:perl-bounces at perl.org.il] On Behalf Of Jason Elbaum
Sent: Wednesday, January 09, 2008 12:22
To: Perl in Israel
Subject: Re: [Israel.pm] Language evolution
As programmers, we love to complain about how complex our development
environments have become - languages, OS APIs, core libraries, etc. It
was all much simpler 30 years ago.
And indeed it was. But that's because computers were solving much
simpler problems then. They weren't doing networking, or windowing, or
threading, or internationalization, etc. Or if they were, they were
doing them using specialized environments and customized languages,
not generic user-oriented systems.
You can't eliminate complexity from complex problems. You can only
rearrange or restructure it. Where C++ or Java or Perl (etc.) doesn't
support a particular form of complexity, the client code must do it
instead. And it must be reimplemented by each system, often in
incompatible ways. Complexity omitted from the language ends up in the
The optimal boundary between the language and the code (or libraries)
is debatable. And the impact on complexity of user code can be
ambiguous. Operator overloading, for example, lets you write your own
number classes and use them like built-ins, including generic
programming with them. But it also means that you can't look at "a+b"
and know what it's doing unambiguously. There's a case to be made on
Perl 5 is missing a built-in simple syntax for object oriented
programming, and all the cruft and crud of using OO in Perl is shoved
into the client code - or CPAN modules, which are nonstandard and not
always supported. That's a weakness of Perl, and it's good that Perl6
will be fixing it.
Personally, one of the things I love about Perl is what I call
"fingertips" - having everything at your fingertips. You don't say,
"use regexps. r = new Regexp("a*...")". You just use your regexp:
/a*.../. The same goes for OS calls and math functions and hashes and
all kinds of other useful everyday functionality. They're just there,
at your fingertips. Unlike in C++, or Java, or (to a lesser extent)
But there can come a point where you forget how many fingers you have,
or what they're called, or how they work. Or where the number of ways
to quote a regular expression confuses your syntax-highlighting
editor, or your colleagues. It's about balance.
I do wonder if Perl 6 has gone too far down the route of featuritis.
Time will tell.
Perl mailing list
Perl at perl.org.il
More information about the Perl