Every time I see a Polish domain name I am reminded at how obsessed that country is with Perl.
We were wizards – a foreword to Learning Perl (1993)
71–80 of 130 posts
Re: We were wizards – a foreword to Learning Perl (1993)
#72Bashing Perl is now a meme, but I can never get over what could have been… Python 3000 and Perl 6 had the community all abuzz. CPAN was the amazing Wild West where people were sharing amazing libraries in such a simple way compared to how every other language was still using the likes of Source Forge and possibly even Fresh Meat (GitHub didn’t exist yet). Don’t fall into the meme trap of hating on Perl. Although it’s…
Interesting this stream of consciousness analogy.
I use Perl a lot because it doesn't get in the way. The functional aspect of it lets you map from problem to solution easily.
Re: We were wizards – a foreword to Learning Perl (1993)
#73Earlier quoted context omitted.
Perl has a weird way of letting you go from thought to code, and disappearing in between, unlike any other language I've ever used. You really can go from idea to functioning system as fast as you type without a lot of pre-planning. It's hard to describe, and the style has fallen out of fashion for more formal, easier to share between humans languages like Java or python, which feel like they introduce an inherent fr…
I love this subthread; I've tried to explain this for years and I've concluded it's simply impossible to convey to someone who never experienced it. It's sad, and really frustrating, to just hear the same clueless comments and memes repeated. So I'm glad to see there are still people around who know what it was like to work with a truly expressive language. About 15 years ago I was put on a Java project that ran for…
Large teams themselves become boat anchors towards progress. But you’ve inspired me to spend a little time with Perl.
Re: We were wizards – a foreword to Learning Perl (1993)
#74About 5-6 years ago I found a new niche for Perl in my day-to-day work. I did a lot of shell scripting at the time and was constantly getting annoyed by subtle differences between macOS and Linux. Sed is especially difficult, because the flags in BSD version and GNU version for in-place search and replace do not match. Plus, sed regexes are more primitive compared to most other languages. I decided to switch from sed…
I wonder, is Perl more ubiquitous than Python for these cases?
I switched from Python to Perl for a lot of these use cases as the Perl across many target devices is gonna be much the same/largely compatible, and virtually always present, while Python could be some random fucking version or broken or not present.
Re: We were wizards – a foreword to Learning Perl (1993)
#75Earlier quoted context omitted.
I'm bashing Perl because I'm using it daily today . I have the moral right. People waxing poetic about their time using Perl back in the late 1990s/early 2000s don't have a vote because they clung onto good bits and have long forgotten the ugly. > it really makes Stream-of-Conscious programming the norm Are you sure it's a Good Thing? Really sure? What if you have teammates? What if you have a life? What if you need…
I have written Perl solo, and then migrated that Perl into a team setting, and the mindset shift needed is HUGE. I agree with you. The happy medium is to write your program twice: Write it solo in Perl for rapid thought-to-code, figuring out architectural issues along the way. Then, write it again in Python for scalable collaboration using the revised architecture. This gives you a working solution for the problem FA…
I’ve never done Perl but would writing solo in Perl and then rewriting it again in Perl with a team be an option?
I have an affection for both Forth and Lisp, two languages that have also been called highly productive but write only.
I think a working early version- even if its a spreadsheet- is 10x of a supposedly 80% done version of something else. The latter of which I must now return to unfortunately…
Re: We were wizards – a foreword to Learning Perl (1993)
#76I liked Perl for text parsing and that kind of work.. Used it professionally for about 3 years. Two things i didn't like about it which i still don't 1. It's a conceptually huge language. There are several things to learn to be effective or you fall into the problem when the 10% that you use is different from the 10% that your teammates use. I found python attractive because of this. 2. I disliked Walls book. It was…
IMHO, Python is also huge nowadays. :( (The language itself, that is, not counting the 500K+ third-party libraries that it has nowadays.) As for the Camel book, what I liked about it is that it explains why Perl is the way it is... the underlying philosophy. Once you know that, it starts making a lot more sense. You usually didn't get that with books like "Learn Perl in 21 days" or something.
You will look up how to interpret `match` whenever you see it and you will like it.
One way to do things? Pfffft.
Re: We were wizards – a foreword to Learning Perl (1993)
#77[dead]
Re: We were wizards – a foreword to Learning Perl (1993)
#78Earlier quoted context omitted.
I hate that behavior of GNU sed (and also of mktemp). Having a flag optionally take an argument is just so weird and surprising, and the syntax is always unexpected and inconsistent.
I don't see it as a flag that optionally takes an argument, but rather a flag that makes an optional argument mandatory.
No, that's how optional flags should work. I mean how specifically -i works. With GNU sed:
-lN, --line-length=N, -l N, --line-length N
All work the same, set line length to N.
-iSUFFIX --in-place=SUFFIX, -i NEXTARG --in-place NEXTARG
Don't all work the same. The argument is only actually taken if it's attached to the flag directly. In the latter two forms, no backup is made.
GNU mktemp is similarly annoying, but different, with the --tmpdir flag.
-pDIR, --tmpdir=DIR, -p DIR, --tmpdir NEXTARG
Only the last one is different. If you use --tmpdir literally without attaching an argument to it, it defaults to $TMPDIR, otherwise it takes in DIR.
This is inconsistent and unpredictable. A flag should either take an argument or not.
I also dislike Python's argparse variable-length nargs behavior for similar reasons. Even with an integer nargs, it makes for an ugly command line, but with variable-length ones it just gets hideous, and can make it impossible to pass an argument beginning with a hyphen to a flag.
Re: We were wizards – a foreword to Learning Perl (1993)
#79Re: We were wizards – a foreword to Learning Perl (1993)
#80Yeah, while everyone still discussing on how to do FP in mainstream languages, Higher-Order Perl was published in 2005, placing many of such ideas how we were already doing that stuff in Perl into paper. Perl allows to come at peace with UNIX being done in C, by exposing similar programing language capabilities, mixed with Lisp like wizardy, without having to deal with C security faults unless required for performanc…
Higher Order Perl is such a gem, one of the best programming books in general.
Forgot most of the Perl I've learned, but I really should go through this book, thanks for bringing it up.