Tom Metro wrote:
> John Redford wrote:
> > Perl's popular origin was based on its operation as a tool that glued
> > together the functionality (not the code) of existing tools like sed,
> > grep, find, sort, sh, and so forth.
>
> This is all true, and yet utterly irrelevant. If you look into the
historical origin of many languages you will find an initial purpose that
its
> current use has greatly diverged from.
It's not "utterly irrelevant". The point is, Perl still does well the thing
it was mainly intended to do. Perl could do much worse than being an
intrinsic part of UNIX.
> > Also, any time I hear Perl advocates talking about how dynamic typing
> > is better than static typing, it just reminds me that Perl doesn't
> > have type inference.
> What do you see as the advantage to type inference over dynamic typing?
> The obvious one seems to be that it lets you emulate dynamic typing in a
statically typed language by doing all the dynamic typing
> determination at compile time, and thus better efficiency.
No... cause inference doesn't do that. A lot of Perl's "dynamic typing" is
only interesting around the built-in scalar types -- i.e. strings & numbers
-- which is more related to the syntactic sugar of string concatenation in
other languages.
Perl: $x = 5; $y = "foo" . $x;
Java: x = 5; y = "foo" + x;
In both cases you get the string "foo5", because of some automatic
conversion stuff (boxing/toString) that's "nice" from the perspective of an
old-school C programmer, but basically taken-for-granted by everyone else.
Type inference comes into play with other things, like method calls:
Perl: $x = foo(); $y = $x->bar();
Xtend: x = foo(); y = x.bar();
Here Xtend can see what the type returned by foo is and determine if that
type even has a bar method to be called. There's nothing "dynamic" going on
in either language -- in theory Perl might dynamically AUTOLOAD a bar
method, but that's not going to help if you've written the wrong thing in
the first place, and it seems to be highly discouraged these days, though I
think it's a great feature of Perl which I'd want to have in some other
contexts.
The "big" advantage of this is that you never mention types other than where
they _must_ be mentioned, thus making those points in the code more visible
-- one of the many examples of how "readable code" benefits from having less
code to have to read. Changing types becomes relatively easy -- change it in
one place and it trickles to the others without a lot of typing (the
click-click kind).
> How often do you run across cases where the compiler infers incorrectly?
"Incorrectly" is basically impossible. "Too broadly" is possible, but
that's the same as it being an error to be fixed -- say you have code like
this:
def foo () {
return if ( x ) new Abc() else null
}
This infers to "Object", because that's the common super-type of Abc and
null. There are a lot of ways to fix it, like "null as Abc" to explicitly
cast the null to Abc. The point is, it would mean an error elsewhere in code
where you're writing this:
x = foo(); y = x.bar();
Because the inferred type would be "Object", and "Object" doesn't have the
method "bar", so you get a compile-time error.
> Doesn't it defeat the purpose of choosing a statically typed language?
The whole idea is just to do less physical (click-click) typing, and not
write things the compiler can figure out on its own. It just needs you to
specify types where they originate, and then make sure your usage is
appropriate based on the flow of the data.
> > Of course, the substantial problems of Perl are intractable. One
> > cannot fix them without changing Perl into a completely different
> > language -- even if one maintained backwards compatibility, there
> > would be a serious question of why one would bother to do so.
> >
> > ...there is not much you can take away from the language and still
> > call it Perl.
>
> Now if only there was a language that was shiny and new, leapfrogged the
other dynamic languages with innovative design, all while
> incorporating the spirit and flavor of Perl, so former Perl developers
would largely embrace it....
>
> Oh yeah, Perl 6.
Perl6 may or may not become popular with the Perl Community... but it would
be just as easy to rename C# to "Perl7" and tell the Perl Community "this is
the new Perl". It has more to do with who is telling them than with what is
being said.
> When Perl 6 for hit the scene, I don't think enough Perl developers were
ready to jump ship to it, even if it had been production ready.
> Now that it is finally getting close to being usable, is it still
innovative, or more on parity with the competition?
It's been a while since I've reviewed the features of Perl6, but I still
don't see anything very interesting there in terms of practical value or
even novelty -- it wasn't novel when it was new. In 1992 Annika Aasa wrote a
thesis 'User Defined Syntax' (ISBN 91-7032-738-6), which covered the subject
of a language which extends its own syntax very clearly -- around that time
I wrote a toy implementation of his approach in C. It's not exactly new...
it is somewhat "cool", but it's just not that useful in practical code.
(Reflect on how little a similar degree of expressive power did to help the
popularity of m4.)
Of more modern and practical value one finds the Eclipse Modeling Framework,
which permits one to create languages, generate code, integrate with IDEs,
connect code to proof/correctness/testing/visualization/specification
systems and generally do much more complicated, powerful and useful things
than Perl6 promises to deliver on a good day.
As I see it, Perl5 made it possible for developers (per se) to write
large/complex/real programs without (generally) any deep understanding of
what they were doing and without encouraging them to know. And Perl6
promises (or threatens) to give those same people more complicated and
powerful tools without changing their underlying philosophical approaches of
one-language-ism and don't-look-under-the-hood-ism. Like 'User Defined
Syntax' it's a fascinating -- apparently entrancing -- prospect... but
there's very little "win" in it.
In the time that Perl6 still hasn't-yet-existed, embedded XML support was
added to both VB.NET and JavaScript. Sure, it might be great for a
programmer to write their own embedded syntax... but embedded XML addresses
roughly 95% of the problem space. If I want that last 5% I can write a
little parser, target JVM/EMF or .NET, and get the benefits of the other 95%
still interoperating... Perl6 just can't offer that -- or even come close.
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
