← Интервью /
Interview with Stevan Little
When did you start programming?
What text editor do you use?
I have always preferred GUI editors, up until recently I was a TextMate user, but about 6 months ago I switched to SublimeText 2. I really like it because it has some of the nice time-saving features you might find in a big IDE, but it doesn't force you into a particular workflow or anything like that.
When and how did you learn Perl?
What are other languages you like working with?
I am a big fan of programming languages in general, so I am always reading and learning about languages, both new and old. While I can read many different programming languages, I have only written substantial programs in about 7 or 8 or them.
Most recently I have been enjoying Scala, which I have been using for a couple experimental projects. I find it, on some level, to be philosophically a very similar language to Perl in that it seems to embrace the concept of TIMTOWTDI. However has very deep roots in academia and functional programming, which tends to eschew the more practical and "just get it done" philosophy of Perl. But it is still a very young language and it will be interesting to see the direction the community will ultimately take it.
At work we do a fair number of C# projects and I have always really liked working with that language. On some level it feels like "Java Done Right" in that the designers of the language clearly learned a lot from Java and where it got things wrong. I also have to say that the emphasis on tooling support in the core of languages like C# is really nice, this is something that many of the open source languages tend to not think about, which makes it very hard to add it in later.
In your opinion, what is the biggest advantage of Perl?
I think that Perl's biggest strength is also it's biggest weakness, and that is the philisophy of TIMTOWTDI.
Of all the languages I have learned and worked with, none of them comes anywhere near the level of flexibility of Perl. One good example is the new keyword API which literally lets you interrupt the parser in mid-stream and change the syntax of the language, I know of no comparable feature in any other language. And this is not just a new thing in Perl, we have long had access to the compiled op-tree via the B module, with which many evil things can be done. This level of access to the language runtime allows for so many interesting and useful things to be done with Perl. Along with this flexibility, Perl also has a robustness to match it, which allows for these features to be used safely, even in production systems.
But this same flexibility and robustness is also a problem for Perl.
Perl, because of TIMTOWTDI, is a language with many dialects; some good, some bad and some complete horrors to behold. I believe that this is truly where Perl gets it's reputation as unmaintainable. Any sufficiently large codebase, in any language, will contain its own internal dialect created over time by the author(s) of the code, and if you are lucky, this will help a new programmer in reading and understanding the codebase (once they learn the dialect of course). For more restrictive languages like Python or Java, the variance in dialect capable of coexisting in a single codebase is fairly small. But for a flexible language like Perl, with it's extremely robust parser, is capable of supporting a very wide and varied assortment of dialects at the same time. This makes it much harder to a new programmer to learn, maintain and safely extend the codebase.
In your opinion, what features should the languages of the future have?
A good concurrency model I think it going to be the most important thing for any language of the future. Personally I really like the share-nothing Actor model because I find it to be predictable and much easier to reason about. It has been battle tested via the Erlang language for almost 20 years and is recently in the past couple of years been embraced by Java and Scala communities with great success. I am not saying that Actors are the best concurrency model, but they are certainly the most interesting right now.
And of course I think that any language of the future should have a robust object system with strong meta-programming capabilities.
Why did you write
Moose? Why do you think it became so popular?
Moose after I had spent time working with the Perl 6 object system
during my time working on the Pugs project. After spending a lot of time with
the nice Perl 6 object system, coming back to plain old Perl 5 OO really
highlighted how tedious and repetitive it can be. I had already prototyped the
Perl 6 object system about 4 or 5 times for Pugs and I simply redirected those
efforts to making something in that would work in Perl 5. I had about two or
three failed attempts before I finally created Class::MOP and then I built
Moose on top of that.
Moose became popular for the simple reason that people really wanted
a nice Perl 6 style object system and had been waiting anxiously for it for
Moose managed to fill that need for those people, and after that it
just kind of went viral as those people introduced it to others.
What do you think about alternative implementations and so called "light"
I have no problem with them, I think they fill a need that
Moose can never
fill. Over the years there have been a lot of them, some good, some bad, right
now I think Moo is the best one because it allows you to seamlessly "upgrade"
Moose if you need too.
p5-mop project was my first attempt at building an object system, similar
Moose, that could fit into the core of Perl itself. Ultimately the project
got crushed under the weight of its own complexity and some really tricky
show-stopper bugs. I have to admit, I was quite disheartened by this and got
very negative about the Perl core for a while. This actually lead me to start
the Moe project, which was an attempt at writing a Perl 5 like language using
Scala. Moe ultimately turned into a place for me to experiment with language
concepts that I would like to see in Perl 5 but which were really hard to
prototype in Perl 5 itself.
Then on the plane ride home from YAPC::NA this year I decided to give the
p5-mop work a second chance, this time using a new approach based on things I
had learned while writing Moe. This eventually became the
that I am currently working on. I have high hopes for this project and will be
working over the next few months to try and get it into the core of Perl.
Can usage of OOP framework without understanding lead to even worse programming practices? Is it possible to write clean code without an OOP framework in Perl?
I think that not having a good understanding of your tools will often lead to bad usage of those tools, I don't think OOP frameworks are special in this sense. It is very possible to write clean code without an OOP framework, the Plack codebase is a perfect example of this.
Do you think that CPAN is now divided into two tribes:
Mo* users and others?
No, I think the division is more along the lines of "Dependencies are a good
thing" and "Dependencies are evil".
Mo* users tend to be in the "dependencies
are a good thing" camp, and non-
Mo* users often tend to be in the "Dependencies
are evil" camp, but I don't think
Mo* is the dividing line here. It is my hope
that Moo, having very few dependencies, will help to bridge the gap between
these two camps.
This too is what I hope to fix with the
p5-mop-redux projects, if we have an
extensible object system in the core then people won't have to worry about the
burden of dependencies just to have a nice object system.
Where do you work right now? How much time you spend programming?
Should we advice young programmers to learn Perl?
Yes, eventually. I say this because I do not think Perl is a good language with which to teach programming, I think either Java or Python are better for that. However, I believe that at some point in their careers they should try and really learn Perl because I think it can be a real eye opening experience for the programmer willing to dive deep enough into it. There really is no other language I have encountered quite like Perl and I think really learning it and understanding it can make you a better programmer in the end.
Interviewed by Viacheslav Tykhanovskyi (vti)