As a non-Perl user who knows Perl quite well and would be able to use it if it made sense... I can't even guess what kind of features Perl would need to be used for any given task on any given platform. These days I am using (1) UNIX/Windows+Java+Xtend+JavaScript, with Xtext to write domain-specific languages for tasks; (2) Windows+.NET+VB.NET (which has type inference!), PowerShell or F#; and (3) Browser+JavaScript. The chance I'll use Perl, Ruby, Python or PHP is roughly (and equally) 0%.
David Larochelle wrote: > I hope you guys didn't think I was trolling. I was really hoping that someone on this list could point to a problem space (e.g. bioinformatics) > or an application domain where they could make a compelling case for starting a new project in Perl. > > I would be concerned about the future of the language if no one can make this case. UNIX system administration scripting. > > On Tue, Jul 23, 2013 at 8:17 PM, David Larochelle <[email protected]>wrote: > > > >> Stevan Little's talk "Perl is not dead, it is a > >> deadend"<https://speakerdeck.com/stevan_little/perl-is-not-dead-it-is > >> -a-dead-end>and his recent follow on Perl > >> - The Detroit of Scripting > >> Languages<https://speakerdeck.com/stevan_little/perl-the-detroit-of-scriptin g-languages> are apropos. These were entertaining. Honestly, they were too entertaining and insufficiently brutal on the reasons why Perl is in the state it is. I don't think terms like "dead" or "dying" make much sense -- the comparison to COBOL is more valid, though one wonders how many people are aware of the state COBOL is in these days, and thus what such a comparison means. For the sake of clarity I would suggest that Perl is closer to approaching the fate of awk, sed, grep, find, sort and other UNIX utilities that reflect the fundamental origin of Perl itself. The future of Perl is more likely to be one of changeless stagnation, near-universal existence, popular usage for infrastructure, and limited or no use for general purpose programming. And I am not sure why Perl users would be upset by that -- I don't see anyone upset that bash or grep aren't being used more widely and replacing languages/tools that aren't all that much like them anyway. One might be content to see Perl do best that which it does best, and not worry about the things it does not do. > On Wed, Jul 24, 2013 at 7:59 PM, David Larochelle <[email protected]>wrote: > > > Thinking about this more, I realize that marketing Perl to new > > developers will require there to be clear cases in which we can argue > > that Perl is the obvious choice. Usually, these type of arguments rely > > as much on community, libraries, and tools as core language. The Little presentations are spot-on when they describe Perl as being "glue" -- that was its origin and that is what it was one best at. Now it's not. And it won't be again. Perl's popular origin was based on its operation as a tool that glued together the functionality (not the code) of existing tools like sed, grep, find, sort, sh, and so forth. Perl4 made it possible to write scripts that would be able to manipulate data in ways that were familiar to shell-script writers, without the inefficiency of the shell, where data must be written & read on pipes between separate processes and holding complex data was quite difficult. Perl4 had a serious problem in its lack of references, and when Python came along, despite many quirks, that was its "killer feature", drawing away many Perl users and facilitating a degree of "real programming" work. Perl5 responded by adding references, and thus Perl moved into a space where writing "real programs" (define that as you like) also became possible. All of this was happening at a time where "real programming" -- in that general UNIX environment -- meant C or C++, and Perl's XS mechanism, in general, made it very easy to glue a wide variety of C/C++ libraries into Perl, thus providing all the "power" of those libraries, with the convenience of a fundamentally simplistic programming language. That time is long, long past. > > Is there a domain in which we could make a similar argument for Perl? > > Currently, it seems that the reason people code in Perl is because > > they know Perl or because they have an existing Perl code base. Can > > anyone come up with a use case in which we could make a compelling > > argument for building a new system in Perl as opposed Python or Ruby? > > What if other languages such as C++, Java, or Scala are available? Yes. People now use Perl because they already use Perl A key fundamental flaw of Perl, as I have mentioned before, is in the scalar/array/hash data types Perl offers. It's not so much that they are "inefficient" as that they are efficiently implemented for being what they are, but "what they are" is fundamentally inefficient for some tasks. Scalars are far less efficient than real numeric types, in the same way that Java's Number classes (Integer, Float, Double, Short, etc.) are less efficient than its primitive numeric types (byte, short, long, float, etc.). Arrays are "fine" at being what they are, but the user is not able to choose between array-backed storage, linked-list-backed storage, doubly-linked-list-backed storage, etc. Hashes are similarly "fine", but other languages provide sets, efficient sorted iteration, efficient insertion options, etc. When it comes to this kind of thing, the Perl response has traditionally been "You can write that stuff in C." And you can. But that just highlights that Perl has long been, effectively, a C-library scripting language, not a first-order programming language. Besides, Perl isn't the glue it used to be. These days one can call into C libraries quite easily from Java or .NET or pretty much any language. And all the Java and .NET languages can efficiently call into their respective diverse language pools. People still write C libraries, but often as not libraries exist only in Java or .NET code without a C implementation. So, Perl has had two great "features" in its history which have driven popularity. One is being a better shell-scripting tool than shell scripts. The other is happening to be First Or Second To Market with a wrapper around some C library for X11 graphics, XML processing or the like. Over time, being first or second isn't going to compete with "better supported" or "more efficient" alternatives that come along later. > > Any thoughts? CPAN -- while there is a lot there, the only people who know which modules are "the good ones" are the people who are already using them. Perl maintainers have known for roughly "forever" that Perl's exception handling is unusable. But rather than simply provide what many other languages provide, the answer has remained "more than one way to do it"... despite that being the very statement of the problem itself. What new users do you expect to be drawn to a language that has been unable to solve a problem that no other language has ever even had, and which it could solve simply by developers admitting that they were wrong and implementing the same solution that every other language has provided. Also, any time I hear Perl advocates talking about how dynamic typing is better than static typing, it just reminds me that Perl doesn't have type inference. Of course, the substantial problems of Perl are intractable. One cannot fix them without changing Perl into a completely different language -- even if one maintained backwards compatibility, there would be a serious question of why one would bother to do so. No, I wouldn't change anything about Perl at this point. I don't think there is much you can add to the language to make it better, and there is not much you can take away from the language and still call it Perl. I suspect that the best thing you can do is be happy with it as it is, much like I am happy with sed as it is. _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
