>>Managers want to move away from Perl.
>>I want to move closer to Perl.
I remember as a young programmer, our client once asked us to produce tool to migrate an entire legacy version control system with something like 20 years of history to a different version control system. It first went to up to some UML drawing Java architect, he came up with a estimate to have it done in 3 months with a team of 2-3 people working full time. The client was like "Never mind, forget about it". A few weeks passed by and client had dropped their mind to migrate the history and opted to just have the latest files checked in. In a random discussion with my manager it got a mention. My manager asked to check if I can do it quickly. I remember I wrote a script over the weekend and had every thing done. It was in Perl.
The script then got passed around and lot of people migrated their repos.
Finally it reached the Java architect. He had a hard time believing something like a few thousand lines of functioning feature rich code could even be written over the weekend. We had a good talk about it.
Perl belongs to a very different culture of programming/programmers who care only about solving problems and getting things done. Its not exactly a language that blends well with corporate political goals.
The sad thing is about 90% of normal back-end computing at enterprises is take data source A,B,C,etc and generate data file Z. Cobol lives because it could do that well. Perl did that amazingly well[1]. Its really trivial to write easy to maintain code that does that in a very standard (across programs) way.
1) Data Munging with Perl was a pretty good book for it
Oh yeah, the details are the problem. Worse, its a technical problem and a people issue for some kinds of output. Report Writing has all of the problems of graphic design and date munging with none of the rewards. Lord help you if the friggin DBA & Application Developers built the database or other data sources for transactional processing and didn't provide any help (e.g. summary tables, other data source) for batch (set) processing.
I now follow a simple law when setting up a data source: If I need attribute X from an item then I better have a way to find all items with attribute X in a hurry.
Yep. It is often much easier (see UNIX pipes) to break a problem down into steps that can be paused / restarted, not to mention just making the logic of each piece much simpler. I've seen where one class of data (e.g. transactions on contracts) are broken down into subclasses (e.g. commercial, individual) then processed by a different perl program to be recombined into one set that is finished by another perl script.
Its amazing how 5 very simple programs is easier to maintain code-wise and operations-wise than 1 big program sometimes.
Amazingly enough, not really. Quite a few don't do it at all without some really good library support. Its not really that "sexy" of a problem and often ignored by people developing languages for interactive situations.
On top of that, I know actual companies that specialize in doing this for bigger companies. The companies want to move something from form, database, file, or whatever to another. Or merge several with some analysis into a new one. You'd think this would be automated or a simple job for one, on-site programmer.
Instead, these firms get paid big money to do that on a regular basis for the same companies. Mind-blowing.
You would think, but it does take some upfront thinking about how to get data cleanly out of one system and into another. Most developers don't really care about that part so you pay big bucks later. If your report writers are struggling getting collection-style reports (e.g. "give me all open contracts"), expect to pay through the nose.
I can write Perl. Okay-ish. But I can almost never read Perl. I mean, I can read my Perl, 75% of the time, but other people's Perl? Very difficult.
Managers (wisely) know that a large important project isn't (shouldn't be) built by one super-star programmer who then decides to leave for greener pastures, but that it's read, often times more than its written, by a team of people. Readability > Writability.
And so Perl was destined to "fail" in the corporate world, at the expense of more boring languages like Java/C#.
Of course there's exceptions and I'm sure there's 2-3 companies still out there that run Perl exclusively, but ultimately, it's a "bearded-loner-sitting-in-the-corner" language.
Without saying what your level of expertise is, and showing a sample of your Perl, drawing any conclusions from your statements is like reading tea leaves.
Readability, of ANY code, is more often than not determined by how good the author is at naming things and avoiding senseless repetition (which are both skill honed with experience), and much less by any given feature of the language itself.
It is hard not to like him. But as a recovering linguist (not the programming kind), I find him strangely approachable.
I wish I had his code and programming abilities. He seems like such an interesting guy. Every once in a while Perl6 comes up. I read about it, and like Perl 5 but more so (at least Perl 5 I have used from time to time), but it seems like such an impressively rigorous build-up of work by hardcore veterans. Most of his jokes come off as sarcastically arrogant, and I enjoy how he pokes fun at his work and himself. I only kind of worry about the Perl Jam security talks his "doctor it hurts when I laugh" retort, because malicious doctors force you to laugh all damn day and steal PII and run up your bills online with malicious transactions. I do not want to dismiss TIMTOWTDI, but if you have a limited set of bad ways to do it, you cannot expect people to ignore it. This shows a weird kind of idealism to me in the one area we know idealists do not lurk.
Jokes aside, I will always see him in a special light. If only I could honor him better by churning out some Perl!
"Perl has always considered itself primarily a programmer-centric language, while Python has always considered itself to be more institution-centric. So in a sense it's a bit dumbed down, much like Java. You'll note both of those languages make their greatest appeal to managers. :-) "
Huh? I was using Python when Perl was more popular, and this seems completely fabricated. He's trying to lump Python in with Java, which is bizarre because those 2 camps have pretty big philosophical differences.
I think that the main reason that Python became more popular because it has both clearer syntax and clearer semantics than Perl. It is compact AND readable -- not just compact. The data structures in Python also behave more like those you would see in a CS textbook.
I'm working on my own language, and I just read over the Camel Book ("Learning Perl"). Honestly I don't see much in there that I want to borrow, except maybe for ~= automatically introducing variables. What else is good about Perl, which is
1) not in Python/Ruby/JavaScript (like hash tables)
2) overly terse/clever?
(Honest question)
Perl's regex syntax seems to be it's biggest influence and legacy, with Python/Ruby/Java/PCRE all adopting its syntax.
And -e in Perl is also useful -- Python/Ruby/etc. aren't really good for one liners like Perl. This provides a nice gateway into the language.
But a lot of other features were rightly ignored by other languages IMO.
Also, with regard to the previous sentence, I actually consider Python OO kind of weak, but it's definitely better than Perl's AFAICT.
> What else is good about Perl, which is 1) not in Python/Ruby/JavaScript or 2) overly terse/clever? (Honest question)
Scalar/list/hash context. It makes zero sense and the syntax seems to change randomly… until you understand it. Then contexts make a great deal of sense.
Also, having dealt with a good deal of Python, I'm inclined to lump it in with Java too—less verbose and dynamically typed, but still focused on code that's superficially easy to read or understand. There's a big difference between being able to read a function or class definition (whatever the hell it means to ‘read’ code; I don't even know anymore) and understand where that falls in the big scheme of things. Python and Java read from the bottom-up; individual methods make sense but then you have to piece everything together. Perl, APL, and Lisp-family read from the top-down. You start with some abstractions and idioms and work your way down to individual functions, which may be hard to grok but what matters is what they do, not how. Perl makes writing those really, really fast, and allows building abstractions easily.
OK thanks for the answer. I agree that this context sensitivity is probably the most Perl-ish part of Perl. I just read over the Camel book section on this, and it says:
"This is the most important section in this chapter. In fact it's the most important section in the entire book."
"Not only that, but you can't make any general rules to apply what you know about some expressions to others. Each expression can make up its own rules. ... Perl is very much a language that tries to do the most common, mostly right thing for you."
"In fact, a big part of learning Perl is actually learning how Larry thinks. Therefore, once you can think like Larry does, you know what Perl should do".
Those quotes don't inspire confidence in me -- it sounds like a battalion of mostly correct special cases... mostly correct meaning "sometimes wrong". However, I do appreciate that the linguistic part of your brain is very large and powerful, and once you internalize all these rules they can lead to a beautiful expressivity. Larry is making use of a different part of your brain than other languages do.
But I have to work with 5 languages regularly, and I see this polyglot trend only increasing in the future. So I appreciate when languages are a little more predictable, and a few months away from them won't diminish my fluency.
"Not only that, but you can't make any general rules to apply what you know about some expressions to others."
has been greatly improved in Perl 6 over Perl 5. That is, the very rules of the parser feel more concrete and the degree of composability between interlocking syntactical constructs has far fewer rough edges. The explanations for the edge cases, when you do come across them, tend to feel more "justifiable" to me as well, in the sense that Perl 5 justifications can and will often be implementation oriented where Perl 6 justifications will tend to come from the language design itself. (Where implementation demands in excuse in Perl 6, it tends to be of the NYI variety).
So the fear of 'mostly correct' is not an issue in Perl 6, in my experience. FWIW, I've also written a lot of Perl 5 code at this point and I've found 'mostly correct' to be absolutely fine in practice, if a bit of a WTF in a few cases going on (edit: going in).
"Each expression can make up its own rules."
While at the same time as becoming more predictable in the manner I describe above, Perl 6 also pushes this to the absolute limit by making it LITERALLY true. For Perl 5, this sentence is pretty true in spirit, if a little bit of a fib practically. The language just didn't have the design that would allow it to, say, produce a real AST. Things like source filters were attempted early on in the language cycle and were already considered harmful by the time I started Perl in 1998.
In Perl 6, every expression can easily make up its own rules, but you don't do it in some oddball one-liner. Instead you have an operator (that is, "a subroutine with a funny name") defined somewhere in scope using the same definition mechanism as every native operator in the language. You get absolute guarantees for behavior on your own operators -- anything core can do, you can do. And it's (edit: core is) always there as a reference to guide you while writing your own operators.
But then again, maybe you actually just don't define that many custom operators. The syntax is terse and expressive enough that I don't find myself doing it very often.
I think in the long run, Perl 6 has everything you need -- and if you don't like the way it looks, it has everything you need to change that, too. And your code wouldn't be transpiled as we do in JavaScript today. It would instead be parsed by the same grammar engine that parses Perl 6 itself.
> In fact, a big part of learning Perl is actually learning how Larry thinks. Therefore, once you can think like Larry does, you know what Perl should do.
Haha, this reminds me of Ruby's Matz:
> The principle of least surprise means principle of least my surprise.
The key insight here is that without unusual levels of care, the principle of least surprise always is about what would surprise the author least, and this can be subjective.
I find hard to think of a single positive thing of contexts in Perl. For me, this is one of the worst aspects of the language (along with references) because is really confusing and it doesn't provide any benefit at all, i.e. there is nothing that you can do with contexts that you can't do in a better way without them.
Although I don't think of Python and Java as that similar, I do see what Larry is getting at. Python encourages "There should be one-- and preferably only one --obvious way to do it", which is very nice for institutions where multiple programmers have to work with the same code.
The power that comes from "more than one way to do it" in Perl is great for an individual programmer that wants to create his own custom tool box, but it can cause difficulties in an organization with people at different skill levels all working on the same code base.
By the way, you see similar issues with Common Lisp. It is great for individual power programmers, but it seldom catches on for something that has to scale way beyond one programmer. As a contrast, look at Go, which was, as Larry Wall would say, "dumbed down" to meet the institutional needs of Google.
I know a lot of Hacker News types would rather think of themselves as power programmers rather than institutional types, but we shouldn't overly disparage the power of institutions to scale way beyond what a single individual can do, even though there can eventually be problems with bloat and mediocrity.
All this is to say that there is need and room in the world for programmer-centric and institution-centric tools. Larry has been helpful to point out the difference, and so people should think about these things when choosing between Python and Perl, for example. I work at a small school, and although I am a one-man programming shop, I do everything in Python in the hopes that if something happens to me, my successor will have an easier time understanding my code. I had done some work in Racket, Clojure, and Haskell, but then I thought about the future and converted everything to Python.
Yeah I see what he's getting at in the sense that Python is more regular and compositional, while Perl is more personal and "poetic" (if I'm to be charitable, I don't really like that quality in my code).
But "Python has always considered itself institution-centric" is patently FALSE... as I said, if you were using Python 10+ years ago, when Perl was more popular, you would find that statement very surprising.
>if you were using Python 10+ years ago, when Perl was more >popular, you would find that statement very surprising
I am not sure why do you correlate popularity with being 'institution-centric'. The thing is that the philosophy behind Python is very institution friendly (where institution can be academic or enterprise) and Perl's philosophy appeals to a very specific hackers subculture, but none of that has anything to do with popularity.
Perl was popular because it sucked less than the alternatives for CGI 20 years ago. Python benefits from its vast set of libraries to the point that sometimes feels more like a Lego language rather than that a general purpose programming language. Again, I don't see the correlation of that with the fact that might be coder or institution centric.
I will agree with you that Python didn't consciously consider itself institution-centric, but it has valued institution-friendly goals such as readability and maintainability.
My problem is that I don't consider those institution-centric goals... I consider them to be essentials for developing good software quickly.
I've written many open source Python projects in the thousands of lines, and one of them was 30K lines. Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution. I don't see how you could NOT value readability and maintainability in this context.
But yes, I get what he's saying. He's just saying it in a wrong-headed way. As if writing readable code is actually a burden or a cost. It's not if you value your own time properly.
> Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution
I think by "institution", he mostly meant "group of people" as compared to a solo programmer.
Personally, I tend to prefer "institutional"-style languages because I have a pretty bad memory. Basically even my solo code is still the work of a group of people—me and all my past selves.
I think there are "solo programmers", but they either:
1. Tend to have a pretty good memory for their own code so they are comfortable living in their own idiosyncratic world.
2. Don't maintain solo programs for a long time.
Even for group code, I think there is still room for languages that are more focused on "build your own mini-language, then write your program in it" as opposed to "there's one prescribed way to do it".
I think a lot of it comes down to ramp up time. When a new developer (or your future forgetful self) starts hacking on your program, how much time do you want them to spend before they are useful?
Languages like Python, Ruby, and Java try to minimize that by making all code in those languages roughly similar so it's easy to hop from one codebase to another.
Languages like CL and Perl place less of a premium on that. In return, the idea is that once you have ramped up, your overall velocity is higher. You basically have to learn a new language—the "language" that the program itself is written in—but once you have you now can express concepts in that program's domain more succinctly.
I don't think there's a right or wrong here, just different trade-offs to be made.
You are equating readability and maintain-ability with quick ramp up time. That is a very institution centric way of looking at software development.
As a great counter example look at Haskell. The ramp up time for a typical Haskell program is fairly high but once you invest the upfront cost and understand the programs major abstractions you can make changes quickly and in a much less error prone fashion.
>My problem is that I don't consider those institution-centric goals... I consider them to be essentials for developing good software quickly.
I would say it depends. Readability and maintainability are very nice virtues, but if you are a driver or graphics developer and it cost you the performance then it stops to be desirable.
>As if writing readable code is actually a burden or a cost
It does have a cost, most of the time in the performance form and some other times in creativity form.
> I actually consider Python OO kind of weak, but it's definitely better than Perl's AFAICT.
Another comment on this was downvoted, because it was unkind, but the point it made is correct:
That statement of yours there is entirely wrong. Python's OO is what it is and it's largely static. Perl's OO however consists, at the language level, of building blocks that are very low level. That does not mean Perl's OO is bad however, since in the year 2016, you rarely operate at that level. Instead you use Moo or Moose, which take these building blocks and provide an OO API that is better than most competitors' OO APIs.
I have been using Perl for the last 3.5 years (for work). Before that I used Python for 8 years. For the vast majority of things Python is better. Perl programmers tend to say that the language is more powerful and allow for shorter programs, but in my experience, when writing the same program in Perl and Python, the later is more concise. There are some Perl features that save you keystrokes, for example, autovivification, but in the long run those are a lot of trouble. Also, it's really hard to learn to use Perl properly, it's full of inconsistencies and antipatterns, it's so easy to write bad code with it. Python is much simpler, consistent and with less corner cases. Python features (e.g. iteration protocol) seem more elegant to me. Perl features feel really hacky, they work, but they're rarely orthogonal and usually have surprising side effects.
One aspect where Perl still kickass is for writing shell scripts. Running commands, interacting with the filesystem and other tools is so easy. Once you know Perl, you rarely use bash, sed, grep or awk.
Python being intuition-centric is true in the sense that there are a limited number of orthodox, pythonic ways of accomplishing something, so if you're invested in the Python philosophy, those solutions will come to you. The comparison to Java, albeit a bit surprising, comes from the notion that both of them ship with intentionally simple building blocks, which you can chain together in a limited, constrained set of ways.
This kind of programming leads to Java's verbosity, where to read a file, you have to obtain an InputStream, so you use a FileReader, but you probably want to wrap in inside of a BufferedInputStream to get buffering, which you probably want to surround in a try-catch-finally to clean up exceptional states, which you're going to want to call readLines on until you run out of lines, which you want to put into a data structure that implements the interface List<>. None of these building-blocks are complex on their own. Furthermore, Java is about enforcing language restrictions from the programmer -- you must deal with checked exceptions before you can proceed, you must not clash types, you must provide an implementation of this abstract method, you must not access this private variable.
Meanwhile Python encourages 'pythonic' constructs, which are idiomatic ways of accomplishing a certain task; these are not unlike what Java programmers would call 'design patterns'. But Python is more lax than Java, and has a notion of 'we're all adults here' [1] towards OO.
Perl takes 'we're all adults' to a new level, providing a LOT of specialized syntax and sophisticated heuristics to squeeze more expressive power from expressions.
He answers that question in the interview, 'What do you think about Python'.
Short summary: closures (no, python lambdas are not the same), the kind of FP that having real closures allows, a real meta-object model, concurrency without a GIL
That whole section talking about Python seems like sour grapes, or making up excuses why Perl gave up so much mindshare to everything else.
Python and Ruby beat out Perl because they released new versions and responded to and kept up with changes in the software industry, while Perl stagnated for 15 years, making incremental point releases to Perl 5 while struggling with the boondoggle that is Perl 6.
> It turns out if you accept the 90% of each paradigm that is practical, and reject the 10% that puritanically rejects other paradigms, you can get a pretty decent general-purpose language out of it
> But there's a long history of people confusing "general-purpose" with "Turing-complete".
Yeah. Things that are formally equivalent are not (usually) equally easy.
That's basically everyone's sentiment in the Perl community right now. Perl6 is a nice language (I mean, I'm not a huge fan, but it's not bad either) but it's a language that has some Perl influences but is definitely not Perl. It's like if Ruby was called Smalltalk 2.
It is not just a sentiment, but a fact that Perl 6 being called Perl 6 has hurt Perl 5. The only reason you don't have a lot of people telling Larry to stop being stubborn about this issue is that the milk is already spilled.
The data is obvious online, in that many many people have to be explained that they're different languages, with a good part of those also stating that they gave up on Perl 5 since "Perl 6 is coming"; as well as in direct talks with companies as early as 5+ years ago already when many german companies told me they're delaying further investments in Perl 5, since "Perl 6 is coming".
Thank you. I don't doubt that Perl6 has had some negative impact on Perl5.
However, I and many others believe that Perl6's positive influences on the Perl5 community far outweigh the downsides. For starters, the whole Moose:: ecosystem (https://metacpan.org/pod/distribution/Moose/lib/Moose/Manual...) would arguably not have existed were it not for Perl6. And there are quite a few other examples.
I think the parent's point was just about the name of the language. If it were called something like "P6" instead, it would have helped avoid some confusion - especially among those who are only peripherally involved with Perl.
FWIW, I use and love Perl5, and completely agree with your assessment.
It's a historic feeling, that is no longer accurate, at all.
I just bought a new computer, and until a new flash drive arrives, I'm stuck running Windows. I installed Strawberry Perl, and my Mojolicious projects and some other stuff Just Works, like immediately, with no fucking around at all required. It is, admittedly not a huge project with a huge variety of dependencies, but it does have some XS modules among other things, and they all were functional without trouble.
My most recent Ruby project still won't run from the source tree using bundler (though it runs fine if i install the gem for the app). So, in my experience, Perl is currently doing better than Ruby on Windows. Or, at least it is a reasonable comparison. I just saw there's a new version of berrybrew, as well, so you can do perlbrew things on Windows. I'm not sure if plenv works on Windows (but rbenv seems broken, too), as I haven't tried it yet, and I have been using perlbrew on Linux, anyway.
In short: The world has shifted quite a bit when it comes to developing with Perl 5 on Windows. It's actually pretty fine these days. As I understand it, Perl 6 is also fine on Windows.
Same; I've always had more problems with Python on Windows, rather than Perl.
With Perl 5, both ActiveState's and Strawberry Perl just worked, whereas Python can't even print to the console [1] without workarounds or an extra library that's not installed by default.
"Which large companies are still using Perl in production? I can name Booking.com, but do you know any others?" - it's worth mentioning DuckDuckGo of course, which is quite young and chosen Perl as a way to go.
Yahoo's infrastructure - Packaging, deployment, configuration management, monitoring etc. - was all Perl about a year ago when I was there, and most likely still is. The recommended tech stack was: Java for large applications, Perl for smaller ones, and any kind of scripting. In other words, any library that accesses infrastructure would be available as a Perl Module. To me, it was interesting to see the same developers diligent about unit tests etc. when dealing with Java code don't exercise the same level of discipline when it comes to Perl.
Slightly off topic, but I've been thrust into working with some perl code and am looking for a good learning option. I like Code Academy's interface and there are also a few good Markdown tutorials out there[1][2].
Does anyone know of a similar experience for Perl?
The best learning option is to head to http://perl-tutorial.org and check out what the most recent things are. Reason for that is that due to Perl's sheer age and rate of evolution, many of the older learning resources are outright damaging to newbies.
> LW: PHP is both the motivational poster child for worse-is-better, as well as the demotivational poster child for worse-is-worse. Somehow PHP has managed to convince a horde of programmers that if their programs are flakey or hard to maintain, it must somehow be the programmer's fault. It couldn't possibly be because they've been frog-boiled.
I've never heard the term 'frog-boiled' before, but it's the most succinct description of PHP I've ever heard.
At my current job we've started using Node.js for a lot of windows based migration jobs and shell scripts, historically where we would have used Perl. We're mostly C#, but data munging and migration is just a lot easier and faster in Node.js or Perl.
I'm curious on what we're missing out on by using node instead of perl?
Node is getting pretty good. I'm a Perl developer of many, many years, and it is still my go to for command line scripts (and also web, but only because I really like Mojolicious and it happens to fit into existing systems). But, building command line tools in Node is no longer a crazy idea. It's still gonna be more verbose, by a lot, than Perl, for many classes of problem (data munging, file operations, almost anything that needs to interact with the OS), but the language has gotten nice with ES6. The libraries are pretty good.
It's really hard to beat the built-in "while <>" semantics of Perl for writing concise, clear, programs that take something in from a file or STDIN and spit it back out. Perl is effectively a DSL for writing command line scripts that live in a UNIX environment (they work OK on Windows these days, too, now that Windows has a reasonable shell with reasonable semantics for scripts like that).
If you want to write many small commands that are composable, Perl is a perfect fit. If you want to write one big application that does a bunch of things, the benefits of Perl look smaller and may even be outweighed by the bigger ecosystem of JavaScript/Node/npm; you can amortize out stuff like options handling and file/stdin handling across all of the functionality and it won't look like such a big part of your program anymore, compared to Perl (which gives you most of those things practically for free with one or two lines of code).
(Of course it's the odd numbers, not the even numbers, but it just happens that the odd-valued entries are in the even-indexed positions in this list.)
JS as target will always be slower and bigger(as payload) than WASM as target so my point is that JS as compilation target is no longer relevant once WASM is supported(i.e. most likely by the end of the year). It makes little sense to start a javascript backend now unless you are looking for very short term benefits.
It's JavaScript that's a much smaller and faster payload if you need garbage collection. There's talk of putting a generic garbage collector into WASM but that's still well into the future. WASM also doesn't have direct access to the DOM - right now it's more like Flash or Java applets than it is JavaScript.
Edit: It's on the roadmap just after MVP so I wouldn't say it's that far. Also based on the latest talks from Luke at City Hall(I can't find the link) the access to DOM could arrive even sooner than the GC. My point is that wasm is worth investing it because it's the future. Once language X compiles to wasm and perl compiles to JS you can see a double digits performance difference. I don't need to tell you which language looks more appealing. WASM has nothing to do with applets/flash etc. It was already clarified in various posts.
The github repo for rakudo-js dates to September 2012. You're correct, but it looks like this effort has been in development for longer than WASM has been around.
We (a corporate shop) have a lot 'legacy' scripts in Perl.
I am assigned to maintain such scripts as no one else wants that role.
I discover, Perl is powerful.
Every 'legacy' script I find can be trivially regression tested (These scripts always have the same pattern, take some input, produce some output).
Managers want to move away from Perl.
I want to move closer to Perl.