Live data from Hacker News

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

mcmillen.dev

161–170 of 170 posts

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

#161
Good thing I gave up Perl5 years ago (after 15 years) and switched to Python. I can't even read the new Perl code, it's so obtuse. Now I like Python, it's much easier to parse because there aren't 1000 ways to do a simple thing. Perl was a write only language.

What I liked about Perl when I started using it was dictionaries, lists, regexes and CPAN. Coming from a statically typed language like C or Pascal it was freedom. Writing modules was weird, objects weird - so that meant messy code. And when they did implement something, it was always a sophisticated flavor of some rarely used programming concepts.

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

#162

Earlier quoted context omitted.

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.

i think you could use your energy better. if people are offended because of bullshit, its their fault. not yours

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

#163

Earlier quoted context omitted.

> I write software for Apple systems. It’s modern, high-quality code, but it’s for Apple. There are people that have never met me, and have never had any prior interactions with me, that hate (and that’s not hyperbole) me; simply because of that one fact. I'm fascinated to hear this. I quite dislike Apple quite a bit as a company/entity, for a variety of pragmatic and philosophical reasons, but the idea that that wou…

Shouldn't be. It's fairly classic human nature. There's lots of folks with axes to grind, that are excellent spinners, and lots of people that are maybe...a bit insecure , shall we say, that eat that spin, and turn it into venom. The old "Ford vs. Chevy" spat can get like that. People kill each other over which football teams they like. It's easy to see why folks don't like Apple; just as it's easy to see why folks d…

Deeply evolved back from when splitting into group A and group B could be followed by war breaking out and one lot killing the other. Thankfully these days it's more flamewars than sticks and stones.

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

#164
post #8

This is obviously just a bit of fun, but looking at the output examples, I think the OCR used may be flawed in that it's heavily optimised to produce characters used in natural language (alpha & spaces) rather than to produce e.g. operators common in code. The number of "special characters" output is extremely small. This will bias it heavily toward producing identifiers, which will be valid in most common programmin…

yes. the paper is really just sampling the OCR software's underlying distributions, combined with perl's acceptance of a wide range of things that look like line noise.

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

#165

Earlier quoted context omitted.

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

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

My understanding it that they're very equivalent in many respects, and popped up at about the same time. Often they're mentioned together as modern options, I didn't for brevity and I'm familiar with Mojo. I think Mojolivious tries to require only core modules with optional upgrade to non-core versions if supplied. Not sure how that compares with Dancer, been a long time since I looked at it.

> I think what killed Perl was Google choosing Python.

Possibly. I saw that as the natural extension of "python is the new teaching language" stuff that started happening in colleges at around the same time, and I think that had a lot to do with it as well. I'm the end it's all about users, and new users, as old users have a natural attrition through finding other things that interest them (whether a new language or non programming pursuits) or retirement or even death. Without new users eventually the community starves. And even if you get enough new users to replace the old ones, without enough new to keep a relevant position relative to all new users, the language will be relegated to a slow decay. That is, even if perl had enough new users to replace old ones, the total programmers grew manifold over the last decades, and without a slice of that pie you're stuck as a has-been language, and eventually people leave due to the natural pull of popular and vibrant language communities.

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

#166

Earlier quoted context omitted.

I have kids of my own, and I think it's absolutely possible to do both. My daughter is 4 now, and loves to splash in mud and do all of that stuff. At the same time, she loves doing puzzles and art, which is still normal kid stuff. I think the problem is that the original tweet seems to think that "coding" is only a vocational skill, and it's definitely not. When you're that age, coding is just another form of express…

That lady probably thinks programmers are the way they're depicted in Dilbert lol. Anyways, I agree. It's another form of expression. Just like Math or Music. But I do also agree, in part with her point, that kids should explore possibilities and be kids instead of having to worry about their vocation so young and being put on a track to become something.

Hi! I'm the author of the Perl paint-splatter paper.

"That lady" is Adrienne Porter Felt, who started as an engineer working on Google Chrome security a decade or so ago, and is now a Director of Engineering who manages a sizable chunk of the Chrome team.

I never worked with her directly, but she has a reputation as a good manager and I'm pretty sure she knows how programmers work.

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

#167

Earlier quoted context omitted.

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

Because an array is a list of scalar, and an hash a map of scalars. If you want to access a scalar inside the list, you write $a[1], which means "the scalar at the first position of list @a". If it was @a[1] it would have been inconsistent, because then a @ expression would have returned a scalar and not a list.

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

#168

Earlier quoted context omitted.

One person’s tool is another person’s livelihood, the corner stone of their professional experience, and the basis by which other people will (apparently) judge their technical expertise

> the basis by which other people will (apparently) judge their technical expertise You lost me here. Even if someone thinks that Perl is an unholy abomination to work with, it doesn't follow that those with expertise in it are less skilled. If anything, it seems like it implies the opposite: expertise in it is harder. The counterpart would be something like claiming that Python is a toy language, simple to use but n…

I cut my teeth on stuff that would have a lot of folks 'round these parts, crouching under their Uplifts, clutching their teddy-bears, peeing their pants, sucking their thumbs, and sobbing. I started off doing Machine Code and embedded stuff, back when that was still fairly new.

I am very happy to use a nice, safe, memory-avoiding, strongly-typed language like Swift as my principal language, and on a GUI system.

I don't particularly care whether or not some rando on teh Internets tubes thinks I'm a "wuss."

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

#169
post #94
post #91

Most of this appears to be Perl's tolerance for "barewords" if you don't "use strict;". I suspect this dates back to the Perl4 -> Perl5 transition, when they removed the requirement to call a subroutine using an ampersand, like &somesub could just be somesub. Unlike, say Python, Perl doesn't require subroutines to be defined before they are called. For reasons I don't fully understand, barewords preceded by '-' are s…

> For reasons I don't fully understand, barewords preceded by '-' are still allowed, even with "use strict". I believe the primary motivation for this is so you can pass argument lists to subs in a key => value format without having to quote the key. For example: someSub( -opt1 => $opt1val, -opt2 => $opt2val ); [edited for formatting, which I never seem to get right the first time]

You don't have to quote the LHS of the => operator, even if "use strict" is on. (That's the only way that it differs from a regular comma.)

> The "=>" operator (sometimes pronounced "fat comma") is a synonym for the comma except that it causes a word on its left to be interpreted as a string if it begins with a letter or underscore and is composed only of letters, digits and underscores. This includes operands that might otherwise be interpreted as operators, constants, single number v-strings or function calls. If in doubt about this behavior, the left operand can be quoted explicitly.

> Otherwise, the "=>" operator behaves exactly as the comma operator or list argument separator, according to context.

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

#170
post #38

Earlier quoted context omitted.

It's 2021, stop writing legacy code that others will have to maintain.

Code is never legacy at the time of writing. That's... Not what legacy means.

Yes it is. If you write a COBOL program you're writing legacy code. Contrary to what you might think about Perl it's quickly approaching the same fate.
Post reply on HN