Slashdot Mirror
Exegesis 6 (Perl 6 Subroutines) Released
chromatic writes "Perl.com has just published Damian Conway's Exegesis 6 which gives practical examples demonstrating how to use the new subroutine and method semantics in Perl 6. This is the companion to Larry Wall's Apocalypse 6 which discussed the changes planned for subroutines in Perl 6."
sub Fahrenheit_to_Kelvin (Num $temp is rw) {
... ; :-)
Verbosity in coding, yeah that will go over well with people who are used to
int lbn, rax,
Don't get me wrong I'm a big fan of Perl, but not for its completeness as a language but for the ability to quickly write small utils to parse text.
But I suppose whatever floats peoples boats.
Tom
Someday, I'll have a real sig.
BTW, a nondeterministic finite automaton is much less flexible than ordinary code; there are many things (checking for palindromes being the classic example) which code in a programming language can do but an NFA (and hence a regular expression) cannot. What you mean is that regexps provide a more concise syntax, and perhaps a more efficient implementation (since the regexp engine is in C).
Perl's so-called regular expressions are not true NFAs however, because they have wacky things like backreferences. In fact they are NP-complete.
-- Ed Avis ed@membled.com
Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.
See the Inline modules on the CPAN.
See Perl Design Paterns, an article on Perl.com.
See the CPAN.
I've read the Perl parser. You're right about this one.
how to invest, a novice's guide
Having a weakly typed language is not an advantage
.NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing. Can you see the advantage here?
.Net isn't actually a language, but a Microsoft product that encompasses the .Net runtime, which in turn encompases C#... kind of like calling Java JSP).
You're confusing variable glyphs with typing. While variable glyphs in Perl do indicate something about the typing, they are not type identifiers.
I was pointing out the advantages of glyphs, not types.
Apparently, script programmers cant deal with specifying that something is an 'int' or 'float' or whatever
Script is a misused word here, since the term litterally means a collection of commands as a user would have typed them, and while you can write Perl code that looks kind of like that, it's certainly not the way Perl is used). Shell programs aren't even always scripts (just look at your average configure program). Don't contribute to watering down the word, especially if you're just doing so to make the "what makes us real programmers special" weak assertion.
Ok, that said, Perl does offer typing, but only when you really need it. Since strong typing isn't needed in perl by default (Perl 5 and under have no real compilation mechanism, so the performance gains would be minimal), all you really need is to type *data* not *variables*.
You can type data using any number of tools in Perl including pack, unpack, sprintf and vec.
In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler. This introduces the need to access system types in a more rigorous way, and Perl 6 has typing features such as you would find in any other language. Of course, $x = $y will still work regardless of types (though it could cause a compile or run-time error if they are excplicitly incompatible, but that's not going to happen unless you really mean for it to).
That's the approach of about 5-10 DOZEN languages (literally) over the last 10-20 years. Let's not credit C# with the "innovation" of objects as the only first-class data types (I assume you mean C#, since
Perl 6 is going down the same route as did Python (long before C#).
Perl 5 has fairly primative roots, and given those roots its typing system made sense at the time. Perl 5 does also have a universal base-class for all objects, but not all types are objects in Perl 5. They will be in Perl 6.
if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!
Ok, first off... Perl 6 will use Unicode by default, of course, and yes there is some talk of using things like the dot-product symbol to mean roughly what you would expect it to mean. However, that is limited by the practicality of entering and viewing Unicode characters with modern equipment. Perhaps in another 10 years....
Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).
You already had the $,@,%,& to prefix variables with.
But in Perl 6, they are rationalized a great deal, and made simpler to use (e.g. Perl used to use the glyph to indicate the type of operation being performed on a variable, no the type of the variable. In Perl 6, that has been changed to reflect what most programmers expect, so @foo[0] is the correct notation for accessing the zeroth element of an array, not Perl 5's $foo[0]).
Perl 6 is going ot be hard for outsiders to jump into at this stage because it doesn't exist yet. If you're not steeped in the culture of Perl 6's design, you won't be able to see where it's going, so everything looks kind of scary.
However, in about 10 years, I expect Perl 6 to be seen as the starting point of a new kind of programming and a level of symbolic abstraction that allows us to start looking at code in a much more constructive way.
I see Perl 6 as kind of a pantheon of programming gurus, and you can subscribe to whichever you like (or tell them all to screw off). The most important thing about Perl 6 is you can use whatever programming style suits you best. In a corporate environment, that style can even be dictated down by the powers that be, too. If you're one of those people that thinks that Lisp (et all) is (or is not) understandable, or thinks Java is a brain-dead C++, or that C++ is error prone Java, then Perl 6 may not be for you. You let (percieved) flaws obscure the important benefits, and as a result you miss out. Objectively, you would be examining the trade off between learning curve and increased efficiency over the time period of the project. In many cases, it is in fact better to stick with the tool you know, even if a different tool would be twice as effecient. Since it's just not possible to learn every single tool available, as professionals, we have to pick the most effective set of tools that we care to know given our interests and other expertise. This brings us around to the great thing about Perl 6: in one cohesive, sensible framework, it gives you really broad coverage. You don't have to learn it all at once--you start out using Perl 6 like Perl 5; then when you decide you want to do some lispy type things, you don't have to learn Lisp and a whole new toolchain, you can learn to do lispy types things in Perl. If you want to do things that would be well suited for C++ templates, you can learn the Perl 6 mechanisms for it instead of undertaking C++. And what is really, amazingly cool is that Perl 6 is shaping up to be a cohesive, well considered framework; it's not a jumble of competing ideas that don't play nicely with each other.
If you've worked with C++ templates and metaprogramming, then you certainly understand the benefits being offered by a lot of the Perl 6 constructs. But the Perl 6 way is much more comprehensive, direct, clear, and intentional. Everything with blocks, anonymous subs, closures, multi methods, named parameters, operator overloading, and macors offers unbelievable oportunities for meta-programming. Once Perl 6 gets rolling and starts developing its own equivalent of Boost, then programming will never be the same. Boost changed everything already, but you've probably never heard of it; but Perl 6 will have mainstream appeal, acceptance, and use that Boost will never have.