|
in reply to The future of Perl?
I think one of the big problems in Perl's future is one of the same ones people have been battling for years. Perl is meant to make the easy things easy and the hard things possible. However, one of the hard things about Perl that could be easier is grasping the language and documentation.
I refer you to syntax of Data::Dump and the associated thread as an example. In particular the words "The reason I remain confused is perlop" in Re^2: syntax of Data::Dump and "Sometimes the perl interpreter is too clever for me." in Re^4: syntax of Data::Dump are particularly telling. What is the cost of outputting data formatted as the language documentation asks for it to be input? What's the cost of accepting the input in a consistent fashion? Why is it normal to cite paragraph two (out of three) of footnote seven (out of eight, most of them multiple paragraphs long)?
A sharp blade cuts best, and Perl as the Swiss army chainsaw has a lot of sharp blades. However, a tool as old as Perl should be worn smooth about the handle which holds those blades together. The saying about a craftsman not blaming his tools assumes that a craftsman can choose and improve those implements. Lots of things about Perl have been improved over time, but there are still these odd gotchas people find surprising. A powerful tool can always be dangerous, but one should be able to be wary of the cutting edge and count on the handle.
The rule of least astonishment (principle of least surprise) usually makes allowances for audience type. Perl has a different core design than lots of languages, and it's okay to surprise a bit with context and such. However, when programmers are surprised by things on a pretty regular basis by little bits of things not part of the language design like the above example, that's bad.
Python is ugly (my opinion), Ruby is slow, and Java is wordy. Perl's weakness is that it's sometimes hard to predict without specific experience around that part of the language. We have a great community that provides support, which is a good thing because apparently we really need it. We need it to impart those nuggets of knowledge to the long-term apprentices who have chosen to follow the not so smooth path to Perl mastery.
Perl's future I think is less fraught with competition from Ruby and Python than people assume. I see competition from Go, D, Rust, and Lua from below now that systems and embedded languages are getting friendlier. I see Scala, Clojure, and Java coming in from the side. PHP and Hack will continue to follow behind, picking off the stragglers. Julia and R may grab a bit, too. The most interesting of these to watch I find to be Go, Rust, and D. Their goals seem to be very much aligned with the goals of Perl6, but they are delivering production tools.
|
Re^2: The future of Perl?
by BrowserUk (Patriarch) on Nov 06, 2014 at 20:40 UTC
|
Your post seems to imply that the problem is the language itself. I don't see it that way; and a recent study, probably the most comprehensive of its type ever, seems to support that.
People and companies don't pick (or not pick) programming languages based upon syntax or features. They are picked on the basis of perceptions; and perceptions are influenced by a huge variety of factors; of which syntax is well down the order.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
I don't discount at all that perception is the main problem. I think Perl is a wonderful language overall myself. The perceptions of it being complex, deep, broad, and somewhat arcane start somewhere, though. They are also reinforced when people come to the language and have such issues as did WoodyWeaver.
Should the rough spots be enough to keep people away from Perl? No, I don't think so. However, the rough spots do little to discourage the negative perceptions of incantations via line noise. Smaller, more regular, and more orthogonal languages are less susceptible to these perceptions and to some extent to these realities. One of the ways for Perl to really answer critics is to overcome the perceptions, not allow things that reinforce them when someone ventures past the anti-Perl hype.
| [reply] |
Re^2: The future of Perl?
by Arunbear (Prior) on Nov 13, 2014 at 11:09 UTC
|
Go, Rust, and D are all low(ish) level languages designed to be used in situations where C/C++ would normally be used. In what way are their goals aligned with the goals of Perl6 (a very high level language) ?
| [reply] |
|
|
Perl6 like Perl5 is a high-level language that is able to reach down to low-level things like bit strings and fine-grained control over system calls. With XS and the the FFI C is part of the Perl5 language. Perl6 has a much improved FFI. One of the goals of Perl6 is to have compilation and as far as I remember that includes JIT, precompilation, partial precompilation, separate compilation, and optimizations. Perl6 supports optional static typing for faster and safer programs.
Go, Rust, and D on the other hand are systems languages but are not so low-level as C. They are all growing toward higher-level concepts but retaining as much compilation speed and runtime speed as they can.
Go for example has goroutines, maps, slices, a continue for loops, support for imaginary and complex numbers, labelled goto, methods, a return of possibly multiple values, panics, channels, and more. It compiles quickly for fast development iterations. It has regular expressions in its standard library (although they aren't as integrated into the language as in Perl). Strings, although immutable, are a separate type from characters and aren't just bare character arrays.
Rust has vectors that support push and pop. It has variable interpolation. It has traits and dynamic dispatch. You can pass closures. Its match is closer to Perl's smartmatch than to a C switch. The 'if' block is an expression rather than a statement, so it can return a value to a 'let'. This is a great generalization of something like the ternary operator or Puppet's setcode() or Puppet's case statement. It supports channels for communication. There are both references and pointers. Rust's regex library supports iterating over capture groups, supports named and numbered captures, supports character classes, and more.
D's regex library is part of the standard library. It supports matches, splits, replaces, etc. D has associative arrays built into the language. It has mixins, operator overloading, contracts, attributes, traits, exceptions, and try/catch/finally/throw.
Go and D are garbage collected. What I've mentioned just scratches the surface. That I've mentioned a feature for one of the three doesn't mean it doesn't exist in the other two. Some of the features in these languages actually borrow from Perl, Python, and Ruby in syntax or inspiration.
There's a lot of growing downward from higher-level languages these days. Perl has always been at the forefront of allowing one to reach down into the system a bit. There's a lot of growing upward from some of these newer low-level languages, too. As people look at object-oriented, perhaps compiled or JIT compiled, modular languages with strong standard libraries and the ability to prototype and iterate quickly I see Rust, D, and Go as a niche just adjacent to Perl6, Clojure, and perhaps Lua.
| [reply] |
|
|
