On Tue, 2005-02-22 at 17:38, Ranga Nathan wrote:
> Here is an email I received internally regarding the shortlist of
> languages for future software development. I must add that this is a
> corporate environment. I responded saying that Perl has one of the richest
> data structures that I know of. Strong typing is actually a bad thing as
> far as I am concerned. How can I rebut this arguement in a better way?
> Actually, there is a hidden agenda to standardize on C# here!
On Type Safety and Perl
First, let's start with a definition. This one comes from answers.com:
http://www.answers.com/type-safety&r=67
In computer science, a programming language is type safe when
the language does not permit the programmer to treat a value as
a type to which it does not belong.
In Perl, there is one data type and two containers. The data type is
called "scalar". In so far as the definition goes, Perl is a type safe
language, since you can never treat a scalar as a "not scalar" in Perl.
Of course, what type safety is SUPPOSED to mean is that you have a
semantic hierarchy of types, and each one has some particular definition
which prevents abuse of that type. In Perl, we fundamentally deny
"abuse" of data. There is no such concept. If you wish to add the number
10 to the string "five", then you may do so because Perl brings to the
table a set of tools that allow the free conversion of string and
numeric data.
The type safe programming languages instead force you to pre-declare
that a variable is a "string" or "integer", and then to invoke a
function or method which explicitly converts one to the other, and thus
adding "five" to 10 would result in a compile-time error in most cases.
While Perl 6 will add features that allow for such type-safety,
ultimately Perl will always provide this facility. Why? Ease of use, and
rapid development. It is possible, for example, to read the raw text of
an HTTP response like so:
$response = http_request($details);
($proto,$status,$text) = split(/\s+/, $response, 3);
if ($status >= 200 && $status < 300) {
print "Success: $status $text\n";
} else {
print "Failure: $status $text\n";
}
Notice that $status moves from string to number and back to string
without any explicit conversion being required. The savvy programmer
would point out that we run the risk of $response containing some
strange error message from the server. What would happen, for example,
if $status contained the word "violation"? Let's find out by running
this code:
$status = "violation";
if ($status > 200) {
print "that's strange\n";
} else {
print "Good news, violation isn't > 200\n";
}
I run this by placing the text in a file, and typing "perl -w filename".
I then get:
Argument "violation" isn't numeric in numeric gt (>) at - line
3.
Good news, violation isn't > 200
As you can see, Perl knows that I'm doing something that doesn't match
its understanding of valid string-to-numeric conversions, but it
proceeds anyway, after producing a warning message. This warning is
enabled by the "-w" flag, which is a critical flag to know about,
regardless of your preference for typing.
So, what else does dynamic typing give us? One useful feature is
free-form data structures. For example, take:
@employees = (
{
name => 'Bob',
id => 1,
title => 'Muckety Muck',
subordinates => [ 2, 3 ],
}, {
name => 'Alice',
id => 2,
title => 'Coffee Drinker',
subordinates => undef
}, {
name => 'Charlie',
id => 3,
title => 'Trouble Maker',
subordinates => undef
}
);
this is a complex data structure which contains 3 records for employees
of a company. There need be no forward declaration of how this data
structure behaves, however, since it is just a collection of arrays and
hashes of scalar values. Notice that "subordinates" is an anonymous
array of ids in the first case, but in the other two cases, it is the
special value "undef". This is possible because references to arrays and
the undef value are both scalars, and hash values and array elements are
always scalar values.
This free-form data management is tremendously powerful, and while it
sacrifices the assurances of strongly typed languages, it is far easier
for modules and extensions to provide such safety where needed than it
is for a strictly typed language to provide dynamic typing.
Conclusions
Type safety is a powerful tool, but to confirm that high quality code
can be written and maintained without type safety, one need only look at
the CPAN repository where Perl modules and add-ons are stored. In this
repository everything from genetic modeling software to Web server
management tools to protocol implementations to graphics toolkits is
managed by contributors and authors.
--
â 781-324-3772
â [EMAIL PROTECTED]
â http://www.ajs.com/~ajs
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
