Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We were wizards – a foreword to Learning Perl (1993)

jwgoerlich.com

Post reply on HN
Print view View original

51–60 of 130 posts

Re: We were wizards – a foreword to Learning Perl (1993)

#51

Post by fouc »

silisili wrote: post #11
andrewl-hn wrote: post #8

About 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…

For anyone who cares, sed -i'' should be compatible on both mac and linux.

I install gnutils in mac, gsed on mac is compatible with sed on linux.

Re: We were wizards – a foreword to Learning Perl (1993)

#52

Post by doublerabbit »

WesolyKubeczek wrote: post #38
thisislife2 wrote: post #5

The worry with any language dying is the loss of knowledge that accompanies its demise. CPAN has a lot of great libraries that once used to power the early internet. Decades ago, it was in a Perl group / forum that I first heard the term "do not re-invent the wheel" when someone enquired about making some kind of their own CGI framework along with a great write-up about all the unique edge cases that the existing lib…

Unfortunately, "do not reinvent the wheel" coupled with "there is more than one way to do it" leads to a proliferation of wheels that you pull in in any medium-to-large project. There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it d…

No difference to Python dependencies nowadays.

Re: We were wizards – a foreword to Learning Perl (1993)

#53

Post by 7thaccount »

doublerabbit wrote: post #52
WesolyKubeczek wrote: post #38

Earlier quoted context omitted.

Unfortunately, "do not reinvent the wheel" coupled with "there is more than one way to do it" leads to a proliferation of wheels that you pull in in any medium-to-large project. There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it d…

No difference to Python dependencies nowadays.

Not really. There is typically just one import for CSV, JSON...etc. It can be hell to get the various libraries to work though.

Re: We were wizards – a foreword to Learning Perl (1993)

#54

Post by 7thaccount »

noisy_boy wrote: post #10

Like everything else, Perl has its warts - tacked on object orientation, crude way of handling errors, lack of a decent REPL, way too much expressiveness (I have seen what happens to a few hundred thousand lines of Perl code written by developers who, instead of writing in a maintainable consistent style, tried to show their cleverness and the language was a willing ally to that) etc. Many words have been spent on th…

I love the glyphs in APL, but not so much with Perl as they don't seem consistent. Like there is an "of that's an array, but you're accessing it with scalar context" or some catch.

With Python, you have lists, tuples, and dictionaries. Those are data structure objects that are useful for different things. Tuples use (), lists use [], and dictionaries use {}. After you learn that, you just learn the few methods and manners to populate them and you're done.

There's nothing wrong with either way of course. Both appeal to different kinds of folks.

Re: We were wizards – a foreword to Learning Perl (1993)

#55

Post by heresie-dabord »

larodi wrote: post #14

We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. And we had too many sigyls and weird symbols and we didn’t see farther than our nose, so we weren’t that good with foretelling things, but only with practical magic. Even though wizards foretold nPm by inventing CJAN - like Cpan for JavaScript. And also IO::Async and Lehman’s work was very much ahead of NodeJS…

> We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world.

The submitted post exemplifies the worst characteristics of what we can call coding culture. Larry Wall was a polarising character. He could be witty but also tiresome.

The C and C++ coding cultures have had their problems too.

Python has been successful as a language and as a coding culture. I don't like the bigotry of the Python community towards other languages, but the openness and focus on coding ergonomics has been different from most (all?) other prominent languages.

It can't hurt to have a couple of MAANA (was FAANG) giants providing material support.

> And we had too many sigyls and weird symbols

This I think is an unfair criticism frequently aimed at Perl by people who haven't reached fluentness. The language is expressive. To attain higher complexity, languages will adopt new symbols and forms. Anyone who knows Python and uses DSLs such as pandas and numpy knows that "sigils and weird symbols" make their appearances in the mutant notation.

Python has its own TIMTOWDI at this point.

Re: We were wizards – a foreword to Learning Perl (1993)

#56

Post by marcus0x62 »

heresie-dabord wrote: post #55
larodi wrote: post #14

We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. And we had too many sigyls and weird symbols and we didn’t see farther than our nose, so we weren’t that good with foretelling things, but only with practical magic. Even though wizards foretold nPm by inventing CJAN - like Cpan for JavaScript. And also IO::Async and Lehman’s work was very much ahead of NodeJS…

> We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. The submitted post exemplifies the worst characteristics of what we can call coding culture . Larry Wall was a polarising character. He could be witty but also tiresome. The C and C++ coding cultures have had their problems too. Python has been successful as a language and as a coding culture. I don't like t…

> Larry Wall was a polarising character. He could be witty but also tiresome.

To whom? Unless you were working on the Perl language itself, there was no need to interact with him.

Re: We were wizards – a foreword to Learning Perl (1993)

#57

Post by __s »

singingfish wrote: post #6
getcrunk wrote: post #3

Earlier quoted context omitted.

Stream of consciousness programming?

As a medium long time perl guy who's been dragged kicking and screaming to do a bit of python recently I'm going to repeat this here: Python and perl are actually pretty much exactly the same - analogous to the Judean People's Liberation front versus the People's Liberation front of Judea. However the languages are optimised for a slightly different purpose. Python helps you to think more like the computer does, wher…

This can be nice in Python. The `dis` module makes execution pretty transparent, & it's easy enough to know what bytecode a given line will compile to (granted, comprehensions creating closures does make that a bit harder)

CPython's implementation is also straightforward enough that you can look up ceval.c to get a gist of what an opcode is doing

Re: We were wizards – a foreword to Learning Perl (1993)

#58

Post by okwhateverdude »

WesolyKubeczek wrote: post #38
thisislife2 wrote: post #5

The worry with any language dying is the loss of knowledge that accompanies its demise. CPAN has a lot of great libraries that once used to power the early internet. Decades ago, it was in a Perl group / forum that I first heard the term "do not re-invent the wheel" when someone enquired about making some kind of their own CGI framework along with a great write-up about all the unique edge cases that the existing lib…

Unfortunately, "do not reinvent the wheel" coupled with "there is more than one way to do it" leads to a proliferation of wheels that you pull in in any medium-to-large project. There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it d…

>There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime.

I think this is hyperbole. Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.

There was a progression to things, mostly because of performance reasons why there is a bit of a proliferation. Moose (and the underlying Class::MOP) were about providing a meta-object protocol for Perl which didn't exist before it. As such, it was focused on being correct over fast. A whole community sprang up from stevan's art. Then sartak's Mouse came along and made some performance improvements with some compatibility caveats. Finally, mst's Moo stripped away the "reflection" aspects of Moose to really squeak out even more performance.

MooseX::Declare was always a (beautiful) research project. I spent some time in that space welding POE and MooseX::Declare together. But these weren't suitable for any kind of production code. If you see this live somewhere, you should definitely rip it out lol.

As for TIMTOWTDI, this is sorta why project Andy Lester's Phalanx came about (it was trying to bless a chunk of modules as a sort of smoke test for Ponie (perl5 implementation on the Parrot VM (which was the first step toward a Perl 6, now Raku)). It was trying to provide an opinionated set of high quality libs for SWE.

Unfortunately, working in Perl really requires a bunch of skill and discipline if you want a long-term maintainable project. This means really looking at your dependency tree and making difficult decisions on which libs to use specifically to avoid installing all of CPAN. npm's installing the world behavior was foretold by Perl.

Re: We were wizards – a foreword to Learning Perl (1993)

#59

Post by jppittma »

LegibleCrimson wrote: post #47
naniwaduni wrote: post #20

Earlier quoted context omitted.

It is not. -i'' is exactly the same thing as "-i", and while GNU sed interprets this as an empty suffix, BSD sed expects -i to take an argument normally, and will treat the next argument as the extension. If you instead use sed -i "", as is appropriate with a BSD sed, GNU sed will interpret that as the empty program and try to read from a file named your actual script.

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.

Re: We were wizards – a foreword to Learning Perl (1993)

#60

Post by okwhateverdude »

martyvis wrote: post #41

I was interested to learn on a recent episode of FLOSS Weekly [1] that Randal Schwartz had moved on from Perl somewhat and is now effectively an MVP and trainer of Dart and Flutter. [1] https://hackaday.com/2024/01/09/floss-weekly-episode-765-tha...

Schwartz basically rode his early fame into the ground. While the world was moving on from Perl (especially after the community completely fractured and started disintegrating during the early days of Perl6, now Raku), he doubled down, but also didn't really produce much or engage with community. The Perl work around the world was drying up. He ended up begging online instead of pivoting. Glad to know he finally did pivot.
Post reply on HN