|
I the early Nineties, I had a good idea of what an ideal programming language would be. Then I encountered Perl, which was diametrically opposite to everything I thought I wanted. Perl enabled me to do in a morning what would have taken a week in C. I was blown away. I was converted. I became a Perl evangelist. I used Perl everywhere I could. 20-odd years later, writing Perl for fun and C++ for money, I had a Perl program which, over ten years, had gradually grown to about 5,000 lines and 25 classes. It needed more testing than anything else I maintained. I missed the help I would have got from a C++ compiler -- what some Perl people disparagingly call BDSM. In C++, if I need to add a Widget argument to a leaf method, the compiler will find all the call sites that need updating. If they in turn need updating to accept a Widget, the compiler will find their call sites, and so on. By the time the program compiles again, it's much of the way towards working. But Perl doesn't do that for me. I can't even specify the number of arguments a method should take, let alone their types. I eventually rewrote the whole thing in D. It came out at almost exactly the same length, which was a surprise, but I got native speed, much-reduced memory consumption, and proper type-safety. My hunch is that a translation to modern C++ would have been longer and taken more work than doing it in D, but not that much more, and the performance would have been better still. This is not so much a story about Perl, C, C++ and D as about weakly- and strongly-typed languages. (Perl 6, in particular, remedies some of the deficiencies in Perl 5's type system, and some of the bolt-on object systems for Perl 5 take steps in that direction as well. These are heroic and ingenious efforts to give users the best of all possible worlds, to the extent that that's possible, and I wish them well.) Languages that are too weakly typed, too dynamic, too flexible, are fine for short programs that are maintained over a short period of time, but they just don't scale -- maintenance becomes too difficult, too time-consuming and too error-prone. At some point, it's best to rewrite in a well-chosen language that imposes more structure and provides more type-safety, and work with that structure (not against it) to make your program rigid enough to stand up under its own weight. As a result of that experience, I no longer use Perl, or any other very dynamic language, for anything but the smallest throwaway programs. For everything else, I anticipate the need to grow by using C++ or D, and the next language I learn is more likely to be Rust than, say, Python. A more general point: if you only know one composer, one band or one style of music and you think the rest aren't worth knowing, you don't know music. Even though I don't use dynamic languages much nowadays, I'm a stronger engineer for having done so. Do take the time to learn several different languages that differ widely from each other and from what you already know -- preferably including some assembler -- and don't assume that the language of the month is best suited to your unique temperament or to the job in front of you. Having an abundance of tools and choosing between them wisely is better than having one and using it for everything. It doesn't matter how dexterously you can use a soldering iron when what you need is a chainsaw. |