Get the top HN stories in your inbox every day.
forgotmypw17
theonething
>Bless you, Larry
I see what you did there.
Edit: for those downvoting me because they don't understand my comment, it refers to the fact that bless is function of the standard library to associate an object with a class.
If you're downvoting me because you think it's a stupid and off topic comment, that is perfectly valid and acceptable to me.
forgotmypw17
Thanks for thinking me more clever than I may be.
It was a simple blessing, and perhaps a reference to this interview with Larry.
To me, the language creator's faith is one more reason to use it.
theonething
My suspicion (not in a negative way as I'm Christian as well) is that the function was named so because of Larry's faith.
singingfish
One of my criteria for good tools is that they scale well from the smallest possible use case to absolutely massive. Git meets this criterion for example.
Anyway I manage a 250kline code base written over 20 years which is in surprisingly good shape consider it's age and how many people have touched it. Last time we upgraded the perl for the first time in a decade - going through the addition of many features and major internal changes (e.g. unicode, optimisation) the total number of lines of code we needed to change was at most 50. And very little having to fiddle with underlying cpan libraries.
Back to the point. Throwaway script - perfect candidate. Code capable of running the money pump for a billion dollar company. Also just as fine as any other similarly capable environment, better than some, trickier to manage the team than others.
lupire
"Perl makes easy things easy and hard things possible."
gyulai
Getting strings to have the right encodings should be easy. On the last Perl codebase I touched it's proven impossible for all practical intents and purposes.
fijiaarone
What we need from a programming language is to make medium complexity things, at worst, medium difficulty.
I don’t care about hard problems, and easy problems.
yamtaddle
> What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO.
I don't write much Perl these days and haven't for some time, but it's still what I might reach for if I were tasked with writing something suitable for a scripting language that had to run with ~0 operational or upgrade/maintenance budget for a decade or more in environments I wouldn't necessarily be able to control or influence, or else [bad thing will happen].
latchkey
Perl needs backwards compatibility given the `write once, read never` nature of the syntax.
Imagine trying to upgrade this to some new syntax...
usefulcat
The fact that it's possible to craft deliberately obfuscated code in a language doesn't actually tell you much about the language.
gerikson
See also Acme::Bleach:
TimTheTinker
That looks more like write-only naming... but the syntax itself isn't bad at all.
Here's the main module: https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA...
yakubin
I’ve had very limited contact with Perl, but for scripting purposes it does seem like the best option, so I intend to sit down to it and learn it better. It looks like a great next step after sed and awk (perl -pe). I love the ability to write terse scripts, reasonable speed for a scripting language and, as you said, backwards-compatibility (such a stark contrast compared to Python).
HeckFeck
The Modern Perl book is great, it explains a lot of the Perl-isms to a modern audience.
http://modernperlbooks.com/ is where you can read it for free.
asicsp
I wrote ebooks on CLI one-liners featuring grep/sed/awk/perl/ruby/coreutils/etc. These are free to read online: https://github.com/learnbyexample/scripting_course#ebooks
Plenty of examples and exercises.
senorsmile
The "Learning Perl" book from O'Reilly is the best book to do this (and imho is one of the best written programming books).
jbullock35
Learning Perl is a classic of the form---the best intro programming book that I've ever seen, at least for smart readers who've done some kind of programming (any kind, with any language) in the past.
The contrast to Learning Python is noteworthy. The latter book is useful, too, but it's about ten times bigger and much less focused on introducing a language.
weare138
Learning Perl is a great book but for anyone new make sure you get a copy of the 7th addition. It originally came out in '93. The 6th edition is 12 years old now.
barrenko
Yup, I'd almost recommend it to a non-programmer.
stjohnswarts
I would argue that ruby as almost all the strengths of perl and conciseness with more coherency if you want a perl-like fluidity and terseness. I personally like python for anything that becomes more than a 100 lines of bash.
btilly
Due to poor coding practices (eg monkeypatching) and a weaker testing culture (by default Ruby does not run unit tests when installing libraries) I've found Ruby to be substantially less reliable than Perl.
However the world has moved on to Python. So I curse every time I again have to look up how subprocess works for what I'd do in Perl with backticks.
undefined
kqr
Does Ruby come pre-installed on virtually every Unix-like system out there?
ilyash
For that, there is Next Generation Shell. Also works like a charm even before 100 lines. For example when structured data is needed. Some other advantages over bash are error handling, automatic command line arguments parsing (similar to Raku, btw), standard library with functions like warn(), log(), debug(), retry(), etc that you have likely implemented hundreds of times in your bash scripts.
Disclosure: I'm the author.
arthurcolle
What is your project? Raku has some cool features and interesting syntax, I took a look at it before the rename, but find myself reaching for Python for basically everything.
klibertp
Raku is a really nice language. I especially like the features that improve safety of the code: gradual typing, subsets, PRE and POST conditions, and defined/undefined checks. Junctions and multimethods are also nice. I have an article - not finished, and probably won't ever finish it, unfortunately - showcasing these features: https://klibert.pl/statics/raku/writeup.html
I think Raku deserves way more attention. Its implementation is suboptimal in many ways and it's improving slowly due to very small core team. With more exposure, more people would come, and hopefully some of them would consider contributing, accelerating the pace of development.
forgotmypw17
Link is in my profile.
cogman10
While it's not my favorite language. I have to admit that function signatures go a long way towards making perl feel somewhat normal to work with. I have to imagine they are pretty big boons for IDEs.
cryptonector
Needs static typing.
I'll let myself out now.
MobiusHorizons
When was the last time this caused a bug for you? My experience of moving from JavaScript to typescript is that it takes significantly longer to write many generic things because the types can’t really express the intended use as well. I will certainly admit that types help a lot at the boundaries between systems , or for catching errors introduced when changing code, but it’s not always a clear win for types, given how much more verbose, and less expressive the language becomes as a result.
kqr
We actually have science on specifically plain ECMAScript versus TypeScript, where the software written in the latter has 15 % fewer bugs. https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...
But of course, the study does not account for if increased development time cancel out revenue gained from lower bug count. (And this will be a difficult problem in general, due to first-to-market effects etc.)
wruza
This is my experience as well. I have a side project in its prototyping state and tried to use typescript in it. The result was exactly what I was afraid of - the first half of a weekend spent on fine-tuning tsconfig and tsserver integration, the second half on type acrobatics and investigating wrong narrowing issues. No code was written that day. I have a decent experience with both typed and untyped languages to see pros and cons of typing and am consciously choosing untyped for the “development” phase.
toast0
It's got static types. A scalar is a scalar is a scalar and never an array. Of course, scalar is a very broad type.
undefined
forgotmypw17
I make up for this by writing short subprocedures and many sanity checks.
mbrodersen
Backwards compatibility for languages, libraries, environments, compilers etc. etc. is super super important. Without it no language/libraries/.. will be successful long term. Because people will simply switch to more modern offerings instead or not upgrade to newer versions. Making things “deprecated” is really bad. Just don’t. An API is forever. So ack accordingly.
ra88it
When I was about 20, I went to the local Barnes and Noble to find a book about programming.
Picked up the O'Reilly Javascript book from around 2000. Had no idea what javascript was, just wanted to learn how to program and trying to pick the most popular language.
$40 later, I got home and started reading! Very confusing, the first half of the book covered the language runtime (I think?) and the second half covered the browser sandbox, and it took me 200 pages to realize that I can't easily read or write to files on my machine with this language. Not what I was hoping for!
Back to Barnes and Noble, another $40 and I came home with the O'Reilly camel book, Beginning Perl I think? Cover to cover read, probably the last time I did that with a programming manual.
Decades have passed, I'm in the same camp as those that prefer Ruby now, but man what a breath of fresh air Perl was back in 2000.
cutler
That would be "Programming Perl" by Larry Wall. For me too it was the only programming book of that size I was compelled to read cover to cover. Larry is a great writer but maybe that's to be expected from a linguist. If Python is the number cruncher's favourite language Perl (and subsequently Ruby) must be the linguist's favourite. I got into programming after being intrigued by regular expressions in the advanced section of a chapter on Search And Replace in Dreamweaver 3 Bible back in 2000. At the end of the section there was a footnote to Jeffrey Friedl's "Mastering Regular Expressions" which I read cover to cover. Most of the examples were written in Perl as it was the only language with regex support so deeply baked-in so I had to then go to the source - "Programming Perl" by Larry Wall.
barrenko
Ah Ruby, the only OOP without the stink.
CraigJPerry
I don’t really miss perl. I do miss the period when perlmonks was relevant to me. I haven’t really seen a similar community since. Maybe rose tinted spectacles on my part but i learned some really enlightening algorithms on there specifically in text processing and i recall it being a really warm community.
Randall Schwarz used to run a podcast that was a total goldmine. Fond memories of listening to that on the train on the way to work.
btilly
Most of the people who were on perlmonks are still around somewhere. Often with the same or a similar handle. (I added my first initial to mine.)
wazoox
Actually some still are on perlmonks :)
collyw
I miss perlmonks as well, now that I do mostly python. It was like stack overflow, except discussions were encouraged. It gave you far more understanding than copying a SO answer usually does.
HeckFeck
It's not objective, but I find I have more fun in Perl than any other language. The initial jump was steep, but it helped that I already knew some shell. Now I think in references, I can guess what $_ is going to be, I slap in a big, my $val = s/<RE_HERE>/other_thing wherever I want, I could go on!
I think $_ belongs to a different era, before levelling everything to the lowest common denominator became seen as a good thing. I found the limitations of its rivals less than compelling, and besides JavaScript is arguably more complex than Perl these days.
wainstead
A few years ago I pulled out Higher Order Perl and started playing with some of the advanced features/techniques available in the language. And it was really fun! I think Perl was the first popular multi-paradigm language.
shp0ngle
ugh $_
I successfully hide away all my bad perl memories and now it’s coming all back
forinti
Funny thing is: $_ is a valid Java variable name.
HeckFeck
And a JavaScript library! http://underscorejs.org/
brazzy
So is ボーン苹果чай.
HankB99
I've used Perl off and on throughout my career, even working at one job that was pretty much exclusively Perl. I've also used Java and C/C++. I've done a lot of work with embedded systems where C was the order of the day.
But back to Perl. I always thought one of the best things about Perl was CPAN. I could nearly always find a module that would accomplish a specific task I needed and then I was just left to write the glue to implement that function (or functions) for my particular needs. I'm surprised CPAN is not mentioned. I wonder if it is still active. I also wonder about security of CPAN in todays environment. I find stuff like pypi and npm to be pretty scary.
I haven't started anything in Perl in quite some time. All the cool kids are using Python so I've been sharpening my skills with that. (But it's all hobby projects these days.)
guilherme-puida
> But back to Perl. I always thought one of the best things about Perl was CPAN.
I'm a younger developer, so I wasn't around when Perl was super popular. I listened to the Corecursive episode about CPAN [0] and was really impressed. It's a good listen even if you're not that interested in Perl anymore.
wainstead
CPAN was definitely the envy of other languages for many years but I feel most have caught up by now.
singingfish
Kind of caught up. I don't think there's much like cpantesters and the strong emphasis on testing elsewhere.
wainstead
Agreed, and the cpan shell too.
petre
> nearly always find a module that would accomplish a specific task I needed
Then you didn't have to write PC/SC smartcard code in Perl. Also most of the MQTT clients are crap, only Net::MQTT::Message is useful but then you have to write the network client yourself and if you also need TLS, good luck, the modules doing that have like 200+ failed tests. CPAN is great but if you need anything out of the ordinary you'll probably find modules in a state of disrepair, abandoned in 2010.
HankB99
That's unfortunate but I suppose a consequence of a less active ecosystem. I don't recall dealing with that back in the day but it doesn't surprise me now, particularly with more recent technologies like MQTT.
I have written MQTT clients in Python and the module support was good. But then I discovered it was easier (for the most part) to use the Mosquitto cli utilities and pipe stuff to/from them. For cases where that was awkward, it was easy enough to write in C and use the PAHO libraries directly.
petre
Yes, Python, Ruby and JavaScript have better MQTT libraries. I managed to write an async Perl client using POE (the networking code was already heavily using it, otherwise I wouldn't even pick POE since it's awful and also dead) and Net::MQTT::Message. Piping output into mosquitto_pub/sub was out of the question, since this was no hack but rather a service that streams data into the broker.
I suspect writing it in Ruby with async would also prove problematic, but there are the ruby-mqtt and async-io gems and one would use the MQTT::Packet for formatting messages and Async::IO for the networking code. Still a lot less painful than what I did with POE and Net::MQTT::Message.
MQTT.js is async already, you just import and use it in the browser, Node.js, probably Deno as well. Easy. It took literally five minutes to get the client enpoint working in the browser over WebSockets. One could even do it from the browser console.
thatwasunusual
> I'm surprised CPAN is not mentioned. I wonder if it is still active.
CPAN is indeed alive and kicking; https://metacpan.org/
cutler
The thing is back in the day 35,000 modules on CPAN was a big deal but if you look at https://modulecounts.com that's since been dwarfed by Python/PyPI (398,000), Ruby/Rubygems (173,000), PHP/Packagist (351,000) and JS/npm (2,116,000).
leejo
CPAN is still where the most interesting work is happening with Perl. Often blog posts like Dave's here will highlight features added to recent perl versions, which from outside the community looks pretty underwhelming. Probably it is, but that isn't as compelling as what you can get from outside the core.
While the core devs of perl concentrate on optimisation of the language and slowly add new features, the strong backwards compatibility approach constrains what can be done with it. The backwards compatibility is so important that development builds of the core will run against the entirety of CPAN's distributions' test suites to see if changes break anything there. This is know as "BBC" - blead breaks CPAN. If a change breaks something on CPAN then it needs to be reevaluated. I don't know if any other languages have an equivalent - running not just the internal test suite but also an enormous external one?
The nature of Perl means external modules can bend the language in some pretty interesting ways and build atop a strong foundation. The new features added to the language are slowly being used by more module authors to create features and libraries that are what you want to focus on.
See https://metacpan.org/pod/Task::Kensho for some of these.
mayankkaizen
I am not much into JS but I have seen countless jokes about JS/NPM having so many modules. I never understood why JS/NPM ecosystem has so many modules? I guess JS isn't that versatile language.
0xbadcafebee
I still use Perl whenever I need to get something complex done quickly. Whether it's the handy command-line switches and features for easier one-liners, or just easier stream text processing, or easier external command execution, or the huge library of modules that often support things Python doesn't, Perl is my "fuck it, I just need to get this done" language.
I can't wait for the day that programming languages as a concept are obsolete. It feels exactly like hand-tool woodworking. I would love to stop building tables and chairs over and over, instead just buy them from Code IKEA.
wainstead
For me it’s any kind of text processing; especially code generation for some one-off task, like churning out SQL or bash scripts/shell commands. Faster than doing it by hand. __END__ is one of my best friends because I can dump the input data right into the script. On the rare occasion I am irked whatever language I’m working in does not have format/write, which comes from the Fortran tradition iirc.
LordKano
When I was an intern, my boss insisted that I learn Perl. I had not yet been introduced to the ways of the monks but I learned quickly.
Perl is still my go-to language when I need to write something quickly.
I have so many purpose driven utilities that I have written in Perl, that it saves me several man-hours of work every month.
wistlo
"Bare bones" seems to be a good thing for Perl. I use Strawberry Perl on Windows and it is orders of magnitude faster than Powershell for processing large files of text strings using regular expressions.
I hope the addition of a "new object-oriented programming framework" won't take away the "bare-bones" speed of the current release.
rurban
The best OO frameworks Mouse and cperl make it faster. Moose, Moo and Corinna signicantly slower. Guess which frameworks are recommended
justinator
Corinna is essentially the working spec of the new class system in Perl. I’m not sure being performant was ever the goal.
cutler
I think this is where Ruby's reputation for being slow is a bit misleading. Perl is faster because it doesn't have OOP baked-in. Pre-load Moose and Perl's performance isn't that different than Ruby's.
cutler
Don't worry. The Perl community, which I love BTW, has bee fighting over Moose, Mouse, Moo and the inclusion of a Meta Object Protocol in the core since the mid-2000s which, I would argue is partly responsible for its decline. So for Perl OOP will always remain an option unless you count blessed hashrefs.
anthk
Perl's bindings for Win32 and OLE are amazing.
jug
Really? This is interesting! I had completely written off Perl for Windows due to its heritage. But we still use COM objects in our scripts here and while I like PowerShell conceptually, I really never got to have fun with it as a scripting language. It just has so many quirks like “implicit returns” etc. and is just so verbose it’s bordering on hard to read at times.
jandrese
While you can use them, I do not recommend it. The problem is when you want to convert a script into an EXE so not everybody has to install Strawberry Perl. Apparently some viruses are written in Perl because Windows Defender flags any exe you build as a virus and deletes it. Also, changing the application icon doesn't work, so you're always distributing a Camel app.
It's a shame too because as you say the Win32 API stuff works great up until the antivirus kicks you in the nads.
anthk
Not a Perl issue, but a Windows Defender one.
csdvrx
Would you have some interesting examples?
I love Win32 because it's the closest we have to a universal GUI format for software.
cutler
Perl enabled me to take a business-owner's disorganised national spreadsheet of teachers, locations and contact details and turn it into a web application, freeing him from fielding phone calls all day and boosting conversions over a period of 15 years. Perl's superb regex handling was essential in extracting and gradually refining the data until it was fit to be entered into a database. From that point on Perl, along with PostgreSQL, literally ran the business while generating opportunities for hosting promotions with bigger companies. Those who (m|kn)ock Perl usually haven't spent a significant amount of time using it to add real value to a business.
JackFr
Maybe I’m missing the point of this piece, but it’s probably because I’m still reeling from the author’s idea that adding “say()” which is “print()” with a newline added, is somehow an improvement to the language.
lloeki
The point is not about `say` itself (which has been there since Perl 5.10, released on 2007/12/18), it's only an example of how much Perl uses modularity (via `use`) to enable new features while ensuring a) code dependent on a new feature alerts on Perl versions without the feature and b) backward compatibility of new Perl versions with old Perl code.
Compare:
# Perl
use feature 'say'
# Python
from __future__ import print_function
IOW py2 code doesn't run on py3, barking at you in obscure ways if you try, and py3 code doesn't run on py2, barking at you in obscure ways if you try. (or worse, partially runs and either explodes in mid flight or silently corrupts data).
Whereas Perl code written targeting vX runs on Perl vY as long as Y >= X, and if Y < X then Perl tells you "unsupported feature foo" or "your perl is too old, update to at least X".
$ perl5.18 sig.pl
Feature "signatures" is not supported by Perl 5.18.4 at sig.pl line 1.
BEGIN failed--compilation aborted at sig.pl line 1.
And not just that, Perl alters its parser behaviour live (and scoped to the module!) so remove `'signatures'` from `use` and you get:
$ perl5.30 sig.pl
Malformed prototype for main::my_subroutine: $foo, $bar, $baz = 'fury' at sig.pl line 7.
To invoke strict mode for an entire script, put the exact statement `"use strict";` (or `'use strict';`) before any other statements.
(They had to make it a string in void context instead of a comment because comments are removed by JS obfuscators, but it's essentially a magic comment/preprocessor directive)
[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
hpcjoe
This. So much this.
At the $dayjob, writing some python assuming late model 3.10.x, and discovering that the API has changed when I have to make sure it works on 3.6.x and 3.7.x.
Nevermind important libraries like pandas changing the API so some functions you 've used for years just disappear.
I've got 30+ year old perl 5, that just works. And is readable. I wish 2 year old python could just work.
brazzy
Say what you want about Java, but back- and forward compatibility have always been a big priority and part of its success story. No Java developer would be surprised at 30 year old code just working (ironically, it's more likely than for 10 year old code).
csdvrx
Even on modern hardware with vectorization, the speed of perl is hard to match for stream processing.
I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!
wistlo
I'm working in Windows (employer's choice) and need to process some huge data files on the desktop.
Perl (Strawberry Perl for Windows) is much faster than native Powershell (or CMD) scripts. A few Perl one-liners and I have 2 GB processed in a couple of minutes.
Big fan of Perl here.
csdvrx
> A few Perl one-liners and I have 2 GB processed in a couple of minutes.
This matches my experience: my task is IO bound, processing tens of GB in a matter of minutes.
> I'm working in Windows (employer's choice)
Work prefers MacOS, Windows is my personal choice :)
Windows 10 and 11 are a pleasure to use: between the Windows Terminal and tools like AutoHotKey, there's no Linux equivalent, even for a commandline geek.
Using Windows (and Perl, and other weird things I like) may not be fashionable, but it's hard to beat.
wistlo
Full disclosure: Work has been Windows centric, but I recently moved to a new group with some Mac users. I'll have that choice, next time I swap hardware, but probably will stay with Windows because
* Would miss too many amazingly useful utilities like arsclip.
* Easier to patch into my home network, which is NTFS-based.
* Employer is now wedded to Microsoft and Azure, so having Powershell and native access to NTFS AD on my native desktop is proving more useful.
* I actually like the Windows interface, even with the Control Panel and other system utilities caught in a weird split between Windows XP and WIndows 10 UIs.
* Some things, like certificate management and hosting a personal database, I do in Ubuntu or Debian as a VirtualBox guest under Windows.
* Wife uses Windows on her laptop. She doesn't know it, but it's actually running as a VM on Debian, very stable, and can easily take her Windows to a new machine.
* [I keep coming back to add items to this list] Remote Desktop Services have improved vastly, and I can manage remote servers or 12 year old client machines at a remote site with equal ease. (XP/7-era machines got a second life when I converted Windows OS disk to SSD). Also find screen sharing via 3rd party VNC (TightVNC) useful.
* The keystrokes have become second-nature. Try as I might, I can never get fully comfortable on a Mac OS desktop. Now get off my lawn.
hpcjoe
> > A few Perl one-liners and I have 2 GB processed in a couple of minutes. > This matches my experience: my task is IO bound, processing tens of GB in a matter of minutes.
Huh. Windows is usually anywhere between bad to horrible at IO compared to alternatives. 2GB processing (usually mixtures of regex, summarizing data, summing fields extracted) shouldn't take more than a few seconds. Even on a slow disk, say 100MB/s, we are talking 20s. On faster SSDs, and NVMe, its very snappy.
If you are waiting minutes ...
> Windows 10 and 11 are a pleasure to use: between the Windows Terminal and tools like AutoHotKey, there's no Linux equivalent, even for a commandline geek.
Huh. I'm happy that $dayjob gave me the option of getting off my horrible Dell workstation laptop (8 core, 64 GB ram, nvidia graphics) and onto a mac pro m1. While the keyboard diff is annoying, karabiner elements fixes most of that. I still ask for a linux laptop at ever opportunity though, as this is what I'm most functional with. Easily the best/fastest experience I've had for dev/admin, and the most stable. Mac is a close second.
anthk
Perl is the Unix utilities' replacement for Windows. It can do awk/sed in one place.
What I miss it's a "strings(1)" replacement for Perl.
kal247
There's a "strings" implementation in the PerlPowerTools : https://metacpan.org/pod/PerlPowerTools
bluedino
I don't think you could be slower than Powershell if you tried.
avyjit
When you refer to modern hardware with vectorization, are you saying perl beats software that makes use of vector instructions? If so wow! Afaik perl is a plain old interpreted language with no JIT, what makes it so fast? I had an idea of perl as in the same performance category as Python, Ruby and friends.
cogman10
My assumption (and I could be wrong) is that whenever you do something that's ultimately CPU intense, perl dives into C code. The sort of stuff you do with perl tends to be a lot of string manipulation and it turns out perl is pretty hyper optimized for that sort of workload.
Other languages could do the same, but often they have a few more layers before they start running that C code.
I'd be curious to know if the perl grammar also somehow lends itself to being fairly optimizable for it's interpreter.
jandrese
Perl does a kind of half JIT when you start a script. It doesn't compile fully down to native machine code, but it does parse and lex the script to build an internal representation. The code is then interpreted, but since it doesn't have to parse each line again it runs very fast and also you can interpret code on the fly in a variable so you get the best of both worlds.
int_19h
This has been the usual way to implement interpreted languages for decades; Perl isn't special in that regard. JIT generally refers to generation and execution of native code specifically.
csdvrx
> Afaik perl is a plain old interpreted language with no JIT, what makes it so fast?
IDK. I didn't waste time checking why.
My guess is that due to the much smaller code size, it reaches a sweetpoint where it fits nicely in the L1 or L2 cache.
But it's just a hunch, I couldn't prove it.
kstrauser
Perl likely spends a lot more time in C than a lot of other bytecode-compiled languages like Python.
while(<STDIN>) {
print $_;
}
qsort
What's the difference when compared with other scripting languages? Is it just all-around faster or it's about some particular application?
csdvrx
> What's the difference when compared with other scripting languages?
Compared to every other scripted languages I've tried, it's always faster - so much that it often rivals compiled code (even with extra optimizations as explained before)
> Is it just all-around faster
Yes - also faster to deploy, and harder to break in deployment due to dependencies rarely evolving. No need to pip install whatever.
Consequently, tracking modules' versions (say in python) and their break in compatibility is a thing of the past. Some may say it's because it's dead. I guess I'm a necrophiliac then, because it makes my life so much easier that I'm loving it :)
clscott
1. What's your top technique for keeping it fast?
2. Are you hiring?
csdvrx
> 1. What's your top technique for keeping it fast?
Using the stock install as much as possible.
Since a perl interpreter is available about everywhere, this makes the scripts cross platform very easily too.
> 2. Are you hiring?
Maybe? You have no email in your profile. Can you please send your CV to my nickname at outlook dot com?
auraham
Any chance to make it open source on GitHub?
xani_
Uh,those features are here for almost decade now, some longer IIRC.
But man, just being able to write
use v5.10
In vast majority of cases the code changes were just "well, the new version of lib gives some warnings about deprecation, might as well clean it up a bit". The minority of cases has been Mojolicious breaking stuff again.
Get the top HN stories in your inbox every day.
With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've been writing Perl.
What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO.
Solo project with ~23K LOC of Perl and counting here. Bless you, Larry Wall and Perl maintainers. Keep it up!