Live data from Hacker News

93% of Paint Splatters Are Valid Perl Programs (2019)

mcmillen.dev

151–160 of 170 posts

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#151
post #62

As a Perl programmer and painter I must point out that the programs show in this article are not smeared, and not on a wall. Nor on a Wall. Some of them are not even paint: https://www.mcmillen.dev/sigbovik/splatters/646f93a2d62ad819...

The "future work" section of the paper covers the smearing part! The authors acknowledge that it is unknown whether the results translate to smeared paint.

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#152

Earlier quoted context omitted.

That is what bash/pipeline programming felt like for me the first time I mastered it. I missed the Perl boat by a few years, riding the Python2/Java wave at Uni instead, but I did encounter it a few times in legacy (read: 5-years old) code and could only marvel at its string manipulation capabilities. I like to think of it as the extended bash that I never took the time to learn

I'm not super familiar with Perl, but I gather that it shares much of bash's, er, ergonomic hurdles. Is there something about gaining scripting power that requires such poor usability? I resisted it for a while, but I just write all my workaday scripts in Python now, and I'm honestly a little baffled as to why I stuck with bash for so long.

Perl's usability is far higher than bash and more consistent. Admittedly, there is a bit of memorisation regarding special variables, but those variables are well-documented and have a strong UNIX heritage. (and they have named versions too..)

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#153

Recently I had to do some simple flat file parsing and aggregation - for some reason, I picked up Perl for a it and it was as easy and performant as ever. It just felt natural and got the job done in a few lines of code. For all the hate Perl gets, I think for specific tasks like these, it is pretty much only rivalled by Python (and compared to Perl even with strict on/avoiding magic variables etc, Python still feels…

Perl is excellent for string parsing/text manipulation (makes sense as that was its original design goal). I agree on Python; "the Pythonic way" of doing things seems to result in lots of useless boilerplate.

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#154

Earlier quoted context omitted.

That is what bash/pipeline programming felt like for me the first time I mastered it. I missed the Perl boat by a few years, riding the Python2/Java wave at Uni instead, but I did encounter it a few times in legacy (read: 5-years old) code and could only marvel at its string manipulation capabilities. I like to think of it as the extended bash that I never took the time to learn

I'm not super familiar with Perl, but I gather that it shares much of bash's, er, ergonomic hurdles. Is there something about gaining scripting power that requires such poor usability? I resisted it for a while, but I just write all my workaday scripts in Python now, and I'm honestly a little baffled as to why I stuck with bash for so long.

I would say that Perl burst on the world about 30 years ago, and that what it allowed one to do was so compelling that it spread at tremendous speed. It was out there, it was in use, and any development had to avoid--as far as possible--breaking existing code.

It is possible to write lucid, maintainable Perl, something I have occasionally managed. It is easy to write ugly, unmaintainable Perl, and that I have too often done. If one looks at the Perl found on CPAN or in various good books on Perl, you can see how to do the former.

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#155

Earlier quoted context omitted.

tbh, I'm still sad that Python won against Perl during the heyday. Perl was and is still a fun language.

If Perl had offered proper OO without all that convoluted bless stuff, offered proper linting, good data-science libs like pandas, easy concurrency, ergonomical web-frameworks to beat PHP and did not get lost in the "everything will be solved by Perl 6" argument, it could have ruled as the Camel of the Web. Sadly it was not to be.

> proper OO without all that convoluted bless stuff

Moose[1], and more lightweight versions in Mouse[2] and Moo[3], have been around for ages by this point, almost 15 years in some cases. Unfortunately it was never made core (but something like them is supposed to be core in Perl 7), so it was always one of the "best practices" things that you had to be in contact with other people about Perl to know or read some Perl community stuff for, as it wasn't in the official docs.

> good data-science libs like pandas

To my knowledge Perl with PDL[4] was the go-to solution for bioinformatics people for a long time. I never did anything with it or Python's Pandas though, so I don't know how they compare (or more importantly, how they compared back when people actually used Perl for this stuff much).

> easy concurrency

While somewhat wonky, Perl's concurrency has been around in forms for a long time (the Coro[5] library was first released in 2001), if a bit harder to use until recently when like every other language the async/await stuff took over.

The parallelism story has always been pretty good, even if also slightly weird (the ithreads system used forks on Unix to emulate threads, but essentially it's an abstraction you can mostly ignore). Notably, the fact you actually had a threading system[6] with locks and semaphores that worked put it above Python and Ruby in that category.

> ergonomical web-frameworks to beat PHP

This took longer, but Mojolicious[7] seems to fit this category well, easily being used as simple as something like Sinatra to stuff close to Rails (IMO, and without ActiveRecord).

That's not to say Perl is perfect and should have always won out, just that I think the problems Perl experienced (and still experiences, and which recently "Perl 7" is trying to address) are more along the lines of the trade off that was made with regard to backwards compatibility and legacy support, and the effect that had long term on the community.

Perl's absolute adherence to backwards compatibility to the point that 20 year old scripts often run without issue on the latest release of the interpreter was always a boon to those that wanted stability and support. It's still used in some places (for example, where I work) as the primary scripting language for server based utilities that are expected to run in a Unix environment. The problem is that this is a trade-off that hurts more for new users and new technologies as time advances. It's great that our (literally) 20 year old scripts to clean up and do server management still function, but it's not as great that ergonomically Perl requirement to opt-in to many new features (so they don't cause old code with conflicting sub names to fail, as an example) means that there's been an ever increasing list of things you must enable in new Perl lest you deal with annoying old behavior makes it's use for new projects annoying at best. Having a good object system is only the first step, and you're right to call it out because as it was never moved to core, it never got as much use as it could have.

> Sadly it was not to be.

It is sad, because it's a nice language and I love using it most of the time, but I also feel like it wasted well over a decade of what should have been major advances because it was deemed less important than backwards compat and everybody just said "well there's a module for it, that's good enough" when it definitely wasn't sufficient. For chrissakes, Perl only got the most simplistic form of function signatures relatively recently, and what we got is far inferior to what was available and I used as a module a decade ago[8]. Perl's problems were always much deeper than not having some solution or equivalent to some nice tool or way of doing things in other languages. Those came, usually fairly quickly, it was all the other stuff that shed the users to the point that now it's hard to know if there's enough left to drive the change that's needed to keep it alive (in the sense that it's not just in bug maintenance mode).

Sorry for the rant. Obviously I'm sad about the current state of things... I've even mostly decided that I might as well do new projects in other languages, but it makes me sad that it feels like I'm doing so not because they're mostly superior at a level that's hard to compete with but because the Perl community (and this includes myself) couldn't get their shit together long enough to steal the good bits in a way that actually mattered to people looking to try a new language.

1: https://en.wikipedia.org/wiki/Moose_(Perl)#Examples

2: https://metacpan.org/pod/Mouse#SYNOPSIS

3: https://metacpan.org/pod/Moo#SYNOPSIS

4: http://pdl.perl.org/

5: https://metacpan.org/pod/Coro#SYNOPSIS

6: https://metacpan.org/pod/threads::shared

7: https://mojolicious.org/

8: Function::Parameters, as in the bottom of this comment https://news.ycombinator.com/item?id=11633961, as the CPAN page does a crap job of showing it with types which is my favorite part.

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#156

Earlier quoted context omitted.

tbh, I'm still sad that Python won against Perl during the heyday. Perl was and is still a fun language.

In my heart, Perl has won a long time ago. Python is nice and all, but it's too much of a jack of all trades language, that doesn't neither suck nor shine at anything. Also, the fact you can write a Perl script, run it everywhere and just not concern yourself with versioning and stuff is beautiful. If one of my .sh script gets over 40 lines, it becomes a .pl file, that's the rule.

Yeah, same. I start off as a shell, but if it starts to get beyond simple text manipulation of variable, I switch it up.

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#157

That's a fun read. I once wrote an entire CMS in Perl. I still wake up, screaming, sometimes. [UPDATE] It appears as if my flippant remark caused upset. I am sincerely sorry that this was the case. No offense was meant. @peteretep, you have my sincere apology. It was a flippant remark. At the time I wrote it (mid-1990s), Perl was the best way to write portable server-side code. I took the time to learn it, and got fa…

I used perl years ago for all sorts of text processing and glue. I remember struggling with lists of lists. I just checked the docs[1] again to see if I've grown at all as an engineer in the last 15 years.

>Now you should be very careful that the outer bracket type is a round one, that is, a parenthesis. That's because you're assigning to an @array, so you need parentheses. If you wanted there not to be an @AoA, but rather just a reference to it, you could do something more like...

Still pretty tricky!

[1] https://perldoc.perl.org/perllol#NAME

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#158

Earlier quoted context omitted.

If Perl had offered proper OO without all that convoluted bless stuff, offered proper linting, good data-science libs like pandas, easy concurrency, ergonomical web-frameworks to beat PHP and did not get lost in the "everything will be solved by Perl 6" argument, it could have ruled as the Camel of the Web. Sadly it was not to be.

> proper OO without all that convoluted bless stuff Moose[1], and more lightweight versions in Mouse[2] and Moo[3], have been around for ages by this point, almost 15 years in some cases. Unfortunately it was never made core (but something like them is supposed to be core in Perl 7), so it was always one of the "best practices" things that you had to be in contact with other people about Perl to know or read some Per…

>> proper OO without all that convoluted bless stuff > >Moose[1], and more lightweight versions in Mouse[2] and Moo[3]

I found all those frameworks, and hacking with inside-out objects to be too cumbersome and got in the way, so I just went back to blessed hashes. I liked to keep things simple.

> easy concurrency

I never got into Coro, but AnyEvent was wonderful to work with, and shaped my thinking in other languages... though you could get away with much more in Perl.

> ergonomical web-frameworks to beat PHP

I don't know how anything could be more ergonomic than Dancer (Perl's Sinatra equivalent).

> but I also feel like it wasted well over a decade of what should have been major advances

This, but thinking back at the time, I think what killed Perl was Google choosing Python. At the time, CPAN was the killer app and still had the lead vs all other higher-level languages. But then Google chose Perl instead of Python and as it was the hottest startup at the time where everyone wanted to work at, people started learning Python. Then the data scientists (except the geneticists) migrated over and NumPy, Pandas (and now TensorFlow) kept the momentum.

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#159

Earlier quoted context omitted.

Nah. Wasn't edited, but it was definitely a slap at me, personally. I touched a nerve, and was reprimanded. It was not a "fun" response, and it made me realize that I had caused offense. Teh Internets tubes are a difficult landscape to navigate. It's almost impossible to write stuff without causing some offense. Some folks take that as an admonition to never write anything fun. Others (like me) learn to apologize. I'…

you really make life way too hard for yourself? why the heck would u care if random stranger is offended over a simple joke regarding a programming language? waste of energy man

> why the heck would u care if random stranger is offended over a simple joke regarding a programming language?

Ooh. I know this one!

Because they are human, and humans are important.

I care, though that won’t always stop me from writing stuff that may or may not cause offense.

But I care about others. I know that makes me apostate, in today’s rage-fueled insane asylum of society, but that’s how I roll.

Re: 93% of Paint Splatters Are Valid Perl Programs (2019)

#160

Earlier quoted context omitted.

Perl is cool but it's got a hell of a lot of cryptic operators for its syntax. They make sense after you learn them but for beginners it's clear why python gets picked up way easier. They're not having to think in symbols and stuff, it just looks more like a list of instructions rather than a mess of dollar signs and 'my' (my what? just not retrospectively intuitive...) That said I like perl (And lately, awk/sed) a l…

Perl might be weird, but it's logic and it makes sense. References are not automagical, but explicit, so you don't get an inconsistent function calling model. If you call a sub like `something(%h)`, it will get a copy of the hash. If you use `something(\%h)` the sub will receive a reference to access the hash instead. This is way better than Python or Java where everything is "pass-by-reference" until it isn't, and t…

Ive only used Perl for one story at work but I don't fully grok yet why we $ a @ or a %

Getting a hash passed by ref to a sub was a true syntactic challenge that I haven't experienced in a different language. Have to say though, using regex in Perl is chef's kiss

Post reply on HN