← Интервью /

Interview with Stevan Little (September 2013)

When did you start programming?

I first started programming in BASIC around 1984 when my family bought an Apple ][e. I mostly programmed simple graphics and made failed attempts at adventure games, I lost interest in about a year. I did not pick up programming again until late 1997 when I discovered HTML and Javascript and got a job working on the early web. Initially I just copied and hacked up simple Javascript widgets, but eventually I bought the big O'Reilly Javascript book and taught myself how to actually program. After that I spent the next several years reading computer science textbooks and learning other programming languages, including stuff like Ada 95, Erlang, LISP, Standard ML, Java and Python. It was not until 2002 — when I got hired at my current job at Infinity Interactive — that I learned Perl.

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?

As I said, I learned Perl when I got hired in 2002 at my current job. At the time I was still doing mostly HTML/CSS and Javascript for work and playing around a lot with Python in my spare time. At first, I was not very happy about having to learn Perl, until I found a copy of Damian Conway's Object Oriented Perl book and saw really what Perl could do. Having studied and learned a number of programming languages it was fairly easy for me to learn Perl initially, but it took several years before I really understood what it meant to write truly "Perlish" code.

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.

I also recently played around with TypeScript, which is Microsoft's attempt at making Javascript into a language more suitable for large scale programming. I found it quite nice to work with and I look forward to the 1.0 version.

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.

Flexible and robust type inference I believe is going to be a key feature as well. In the past type inference has been found mostly in functional programming languages like Standard ML, OCaml and Haskell that have rigorous type systems, but recently people have been trying to apply it to more dynamic languages. A good example of this is the TypeScript compiler, given any ordinary Javascript (because TypeScript is a superset of Javascript) it will actually check all type usage even though no types are specified. While this does force the programmer to be more strict about their variable usage, meaning once you store an Integer you cannot later store a String, TypeScript also provides an "escape hatch" with an "Any" type, which allows the programmer to violate this at will. This kind of combination of flexibility and rigidity I think will be key for any future language.

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?

I wrote 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.

I think 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 years. 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" implementations of Moose?

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" to Moose if you need too.

What are p5-mop and p5-mop-redux projects?

The p5-mop project was my first attempt at building an object system, similar to 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 p5-mop-redux project 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?

I work for a small consultancy called Infinity Interactive, we have 24 full time employees and a handful of regular freelancers. We offer a full range of services such as; Perl programming, high end HTML/CSS development, sophisticated Javascript driven UIs, .NET and Java programming, system administration consulting and services and more. These days I tend to do more project management and architectural design then I do programming for clients, however this is not all bad because it means I have more time to work on Open Source projects like p5-mop.

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)