David Hussein Brunton
Tuesday, March 25, 2008
Perl 6 Is Not Just a Language
Perl 6 is a programming language I've discussed before.
Like anyone else who spent more than five minutes on the Perl 6 IRC channel, I got a commit bit to Pugs, but Pugs isn't really moving. Perl 6 has some traction on other fronts: Rakudo is moving along at a good clip, Parrot keeps getting cooler, and Perl 5 keeps getting more Perl 6 syntax built in. There are variants of Perl 6 syntax, too: KindaPerl, NotQuitePerl, etc.
Now, I'm not part of the Perl 6 design team, and I don't speak for anyone but myself. But Perl 6 is still a long ways off. I mean a real Perl 6 with mutable grammar and meaningful interoperability with other Perls and maybe other languages as well, along with all the pretty new syntax that could probably be "done" a lot sooner if it weren't so tied up in other aspects of the implementation.
By "a long ways off" I mean "more than five years."
I don't say this to denigrate the efforts that are bringing us pieces of Perl 6 right now. I say this in the interest of recognizing how big a change Perl 6 is likely to be. Especially if it keeps the interesting bits that Larry Wall seems pretty likely to keep. It's a whole culture. And it has to be rewritten from scratch. And we're just starting.
Perl 6 is not just a language.
It's a new programming culture that recognizes programmers for the language designers we are, and gives us the tools we need to do it well. A presumption that we will write code which looks at itself and adapts. A recognition that most the good ideas will be someone else's, and we should have easy ways to use them.
These kinds of changes won't come easy, especially since they'll break so many of our existing tools. Syntax highlighters and IDEs and testing frameworks will all need to be rethought, along with who knows what else. Best practices will need to be borrowed from communities that have dealt with some of the same problems, and new practices will need to be invented for dealing with new problems. We'll have to gradually move in that direction, discovering obstacles along the way, and hopefully not forgetting to enjoy ourselves.
Yeah, Perl 6 is still a ways off. But getting there is still fun. And once we've gotten there it will be worth it.
Since we'll be able to use Perl 6 to write Perl 7.
Like anyone else who spent more than five minutes on the Perl 6 IRC channel, I got a commit bit to Pugs, but Pugs isn't really moving. Perl 6 has some traction on other fronts: Rakudo is moving along at a good clip, Parrot keeps getting cooler, and Perl 5 keeps getting more Perl 6 syntax built in. There are variants of Perl 6 syntax, too: KindaPerl, NotQuitePerl, etc.
Now, I'm not part of the Perl 6 design team, and I don't speak for anyone but myself. But Perl 6 is still a long ways off. I mean a real Perl 6 with mutable grammar and meaningful interoperability with other Perls and maybe other languages as well, along with all the pretty new syntax that could probably be "done" a lot sooner if it weren't so tied up in other aspects of the implementation.
By "a long ways off" I mean "more than five years."
I don't say this to denigrate the efforts that are bringing us pieces of Perl 6 right now. I say this in the interest of recognizing how big a change Perl 6 is likely to be. Especially if it keeps the interesting bits that Larry Wall seems pretty likely to keep. It's a whole culture. And it has to be rewritten from scratch. And we're just starting.
Perl 6 is not just a language.
It's a new programming culture that recognizes programmers for the language designers we are, and gives us the tools we need to do it well. A presumption that we will write code which looks at itself and adapts. A recognition that most the good ideas will be someone else's, and we should have easy ways to use them.
These kinds of changes won't come easy, especially since they'll break so many of our existing tools. Syntax highlighters and IDEs and testing frameworks will all need to be rethought, along with who knows what else. Best practices will need to be borrowed from communities that have dealt with some of the same problems, and new practices will need to be invented for dealing with new problems. We'll have to gradually move in that direction, discovering obstacles along the way, and hopefully not forgetting to enjoy ourselves.
Yeah, Perl 6 is still a ways off. But getting there is still fun. And once we've gotten there it will be worth it.
Since we'll be able to use Perl 6 to write Perl 7.
Labels: culture, perl, perl6, programming
¶ 1:50 PM Links to this post
Friday, February 29, 2008
Perl 6, Compiling, and Even More Smartness of Others
In the previous post, I talked about why I like Perl:
Perl 6 is a new language, which is much like Perl in some ways. Unless there is some secret Perl Cabal working on a project they're not talking about, Perl 6 is still a ways away. But there are a number of interesting documents that describe what Perl 6 will do when it comes, which bear thinking about, particularly in the context of Perl.
Of course, there is new syntax- new nouns and verbs and even punctuation that some people will love and some people will hate but most people will just use (or not use) without thinking about it a great deal. From what I've seen of it, I like the new grammar in Perl 6, and I especially like that it is a grammar (rather than an implementation of a grammar, like Perl). But syntax aside, there are two points worth noting about Perl 6 that mirror Perl's original contributions in many ways:
On Boundaries
Perl blurred the traditional boundary between scripting and application development. Using Perl, application developers write code quickly that is platform independent and easily modified. These three variables (speed, portability, and agility) are not altogether unrelated, but that is a topic for another day. With the caveats spelled out in the previous post, Ruby and Python erase these boundaries even more completely.
Perl 6 is aiming for a different boundary. Traditionally, there is a huge gulf between a programming language and its compiler. This gulf is filled with Compiler Compilers like yacc and bison, which make grammars into parsers, which parse languages, which create an abstract syntax tree, which is ultimately compiled down to machine instructions (either virtual, or actual, physical machine instructions). It's a lot of steps.
Perl 6 is not the first language to aim for this boundary, by a long shot. But Perl 6 does take aim with style and flair. If the approach is successful, it may signal the end of learning a new syntax for writing parsers with compiler-compilers. Programmers themselves will be able to experiment with creating new programming paradigms by rewriting the rules as they go along.
Is this a good idea?
The heck if I know. I imagine it will not be used by a great horde of programmers, but then most programming language features aren't.
There are a number of other features that take aim at this boundary, but setting their phasers on stun rather than kill. The design of Perl 6 has a great deal of introspection built in- giving programmers the ability to not only inspect the contents of a container, but also to inspect the container itself, and even make changes to the container.
Once again, I don't really know if this is a good idea. Python and Ruby have already got it in the form of duckpunching or monkeypatching or whatever they're calling it these days. We're going to call it Perl 6, and rather than hating it, we're going to love it. Since, after all, there is more than one way to do it.
On Leveraging the Smartness of Others
Perl programmers believe that other Perl programmers are real smart. It's why CPAN works so well. But there are problems with this belief. Sometimes other programmers get smarter faster than I do, which means they change how their code works in a new version. CPAN made it a little hard to grab a specific instance of someone else's smartness. There might also be more than one smart person working on a particular problem, who both call their code by the same name (since they're both real smart). CPAN made it a little hard to pick one or to not care or to do whatever else I want to do in that instance.
On top of all this, there are times when I may even think someone else is smart, who isn't even a Perl (or Perl 6) programmer. I know it sounds far-fetched, but it does happen sometimes.
Once again, Perl 6 is not the first language to aim for this ability. Perl gave us interfaces to the C programming language, and others eventually, but they are real hard to use unless someone else had already done it (which is often the case). Perhaps I should say real hard to write.
Perl 6 provides enough optional type declaration that writing interfaces to other languages becomes much easier. And in the case that Perl is running on a (possibly virtual) machine that supports other languages (approximately 100% of the time in the current implementation efforts), it will (hopefully) be a no-brainer, such that using the smartness of others will be the same kind of reflex it was with Perl.
And as for CPAN- Perl 6 comes packaged with a nice abstraction layer that allows a great deal of information to be specified about a given class or grammar or package. Authors, versions, and namespaces are built in.
So, I imagine in the future world of Perl 6, I'm going to care even less about who wrote the code I'm running (especially if that person is not-me), but to be able to trust more reliably that the code won't be changing out from under me. I may even care less about what language it's written in, which brings us full-circle to the earlier point.
The code I'm running very well may look like it's written in Ruby or Python, but simply be using a grammar from one of those languages on top of Perl 6. Wouldn't that be strange? Talk about blurring boundaries.
Conclusion
It's hard to conclude anything from this exploration. But it is worth noting that after thinking about it for a while, I do think taking down the language/compiler barrier is a great long-term goal, and I do think (re-)using the smartness of other people is nice. And I admit that it's possible Perl programmers eventually lost their way on the latter some time in the past twenty years. It happens to the best of us. Twenty more years, and we'll be ready for version seven, which will, according to Larry, be the perfect language.
- Perl fudged the boundary between scripting and application development
- Perl gave smart people a way to share their smartness: CPAN
Perl 6 is a new language, which is much like Perl in some ways. Unless there is some secret Perl Cabal working on a project they're not talking about, Perl 6 is still a ways away. But there are a number of interesting documents that describe what Perl 6 will do when it comes, which bear thinking about, particularly in the context of Perl.
Of course, there is new syntax- new nouns and verbs and even punctuation that some people will love and some people will hate but most people will just use (or not use) without thinking about it a great deal. From what I've seen of it, I like the new grammar in Perl 6, and I especially like that it is a grammar (rather than an implementation of a grammar, like Perl). But syntax aside, there are two points worth noting about Perl 6 that mirror Perl's original contributions in many ways:
- Perl 6 is fudging the boundary between language and compiler
- Perl 6 is making it easier to use the smartness of other people
On Boundaries
Perl blurred the traditional boundary between scripting and application development. Using Perl, application developers write code quickly that is platform independent and easily modified. These three variables (speed, portability, and agility) are not altogether unrelated, but that is a topic for another day. With the caveats spelled out in the previous post, Ruby and Python erase these boundaries even more completely.
Perl 6 is aiming for a different boundary. Traditionally, there is a huge gulf between a programming language and its compiler. This gulf is filled with Compiler Compilers like yacc and bison, which make grammars into parsers, which parse languages, which create an abstract syntax tree, which is ultimately compiled down to machine instructions (either virtual, or actual, physical machine instructions). It's a lot of steps.
Perl 6 is not the first language to aim for this boundary, by a long shot. But Perl 6 does take aim with style and flair. If the approach is successful, it may signal the end of learning a new syntax for writing parsers with compiler-compilers. Programmers themselves will be able to experiment with creating new programming paradigms by rewriting the rules as they go along.
Is this a good idea?
The heck if I know. I imagine it will not be used by a great horde of programmers, but then most programming language features aren't.
There are a number of other features that take aim at this boundary, but setting their phasers on stun rather than kill. The design of Perl 6 has a great deal of introspection built in- giving programmers the ability to not only inspect the contents of a container, but also to inspect the container itself, and even make changes to the container.
Once again, I don't really know if this is a good idea. Python and Ruby have already got it in the form of duckpunching or monkeypatching or whatever they're calling it these days. We're going to call it Perl 6, and rather than hating it, we're going to love it. Since, after all, there is more than one way to do it.
On Leveraging the Smartness of Others
Perl programmers believe that other Perl programmers are real smart. It's why CPAN works so well. But there are problems with this belief. Sometimes other programmers get smarter faster than I do, which means they change how their code works in a new version. CPAN made it a little hard to grab a specific instance of someone else's smartness. There might also be more than one smart person working on a particular problem, who both call their code by the same name (since they're both real smart). CPAN made it a little hard to pick one or to not care or to do whatever else I want to do in that instance.
On top of all this, there are times when I may even think someone else is smart, who isn't even a Perl (or Perl 6) programmer. I know it sounds far-fetched, but it does happen sometimes.
Once again, Perl 6 is not the first language to aim for this ability. Perl gave us interfaces to the C programming language, and others eventually, but they are real hard to use unless someone else had already done it (which is often the case). Perhaps I should say real hard to write.
Perl 6 provides enough optional type declaration that writing interfaces to other languages becomes much easier. And in the case that Perl is running on a (possibly virtual) machine that supports other languages (approximately 100% of the time in the current implementation efforts), it will (hopefully) be a no-brainer, such that using the smartness of others will be the same kind of reflex it was with Perl.
And as for CPAN- Perl 6 comes packaged with a nice abstraction layer that allows a great deal of information to be specified about a given class or grammar or package. Authors, versions, and namespaces are built in.
So, I imagine in the future world of Perl 6, I'm going to care even less about who wrote the code I'm running (especially if that person is not-me), but to be able to trust more reliably that the code won't be changing out from under me. I may even care less about what language it's written in, which brings us full-circle to the earlier point.
The code I'm running very well may look like it's written in Ruby or Python, but simply be using a grammar from one of those languages on top of Perl 6. Wouldn't that be strange? Talk about blurring boundaries.
Conclusion
It's hard to conclude anything from this exploration. But it is worth noting that after thinking about it for a while, I do think taking down the language/compiler barrier is a great long-term goal, and I do think (re-)using the smartness of other people is nice. And I admit that it's possible Perl programmers eventually lost their way on the latter some time in the past twenty years. It happens to the best of us. Twenty more years, and we'll be ready for version seven, which will, according to Larry, be the perfect language.
Labels: compilers, language design, perl, perl6, programming, python, ruby
¶ 2:24 PM Links to this post
