troglodynellc

I make my entire living modernizing various firms' perl stacks.

There is a never-ending amount of work for people who are good at modernizing older mod_perl/cgi stacks into psgi, and profiling/optimizing stuff.

Where I see perl going:

I see the big firms running away from it as fast as they can, and getting pikachu face when they inevitably get second-system effect, but nevertheless doubling down, because admitting failure is a no-no unless during a reorg.

I see the mittlestand and small biz expanding their existing use of perl, as they cannot afford to re-tool. Perl programmers will continue to have active careers for another 20 years, which is at least as long as I need to remain employed.

The language itself will continue to evolve at a snails' pace due to being design-by-committee since our BDFL retired. Thankfully this doesn't seem to be a particularly serious problem, as no advances in programming language design have come forth which are the kind of quantum leap in either dev productivity or performance to matter for our use cases.

A lot of the "dogmatically tied" comes from experience; it's why the common refrain is that IDE means "It Doesn't Exist" (where you have to fix the code). E.G. a "this is why we can't have nice things" situation.

This is why a lot of us still use vi/emacs; it's just what's available where we have to fix the problems.

I'll give you an example. I used to contract with booking.com, where they gave us a crippled little windows "amazon workspace" over vnc which we had to use to talk to their systems. They're transitioning from a perl shop into a java one, so naturally they use an IDE. Unfortunately, they have configured this little workspace such that SSH mounting your dev VM into an IDE isn't possible (due to it not having a workable ssh agent), and you can't install anything not pre-approved (so x11 forwarding a locally installed IDE is right out).

Minor changes could have been made to these workspaces to address this; requests for which went ignored for years.

The only thing I could rely on was what I am used to writing perl in. An SSH console session with vim and tmux.

I was quite glad to have java experience from before the days when java IDEs were any good. I'd have been screwed if I didn't know how to use the debugger and javac directly.

We've all had to work with our hands tied behind our backs often enough we just "skip to the end" and use the tools we know for a fact will always be available.

It's probably that same reason that perl persists to the level of popularity it has. Like vi, I know it's going to be there on basically any server I have to work on, and the client probably doesn't care/want or even know how to provision me something less primitive.

The constitution makes no reference to citizens with regards to what congress can and cannot do. Nearly all these things are couched with "congress shall pass no law" -- the focus is restricting the behavior of congress rather than the citizenry.

This is a totally bunk argument. If you want an argument that does work against the constitution, SCOTUS' "empty shell" or Lysander Spooner's "Constitution of no authority" are of far more weight, but have more disturbing implications (e.g. You can disregard it completely; our system is precisely the "odious arbitrariness" the founders denounced).

The core problem with DNSSEC adoption has always been what happens when your ZSK/KSK expires, which it ought to for the same reason SSL certs expire.

Rolling this over in an automated fashion is desirable, as if this just happens to slip your mind, too bad, NXDOMAIN

This is obviously a non-starter for most people; otherwise this would just be automagic like letsencrypt is now.

CDS and CDNSKEY records basically solve this problem, but last I checked only a tiny minority of registrars implement them. Even then, some of them require things like 3-day windows in which the CDS/CDNSKEY must not change before they obey. It's basically a recipe for raising your blood pressure 10mmHg.

So, everyone ignores it for this very good reason. As long as it's essentially installing a landmine in your office chair nobody will touch it.

Back when I worked at TI we had a neat machine that used X-Rays to map and reverse competitor chips (mostly to discover they were duping ours). It would work down to just short of a 10nm resolution.

You'd need to use gamma spectrography to map out more modern chips. I'm sure someone's got the equipment somewhere; the chip manufacturers themselves must verify they got a good etch somehow.

Most of the bickering about this or that programming language is no different than "should I buy the bosch or craftsman table saw".

Use whatever has the lowest TCO to you that lets you get the job done.

Perl is usually that tool for me, but yanno TIMTOWTDI. Basically every programming language is quite expressive and has adequate tooling to profile, test, cover, format and lint & run thru CI these days.

I have noticed pretty much everyone using X language still thinks the others don't have said features though. Good for a chuckle in dev chats.

It's to distinguish between references and non-references. pass-by-reference rather than only COW (such as in some languages) is quite useful.

You would prefer *ref like in C? You can actually do that (it's a GLOB type).

The place people get tripped up is that $scalar can be a string, or a ref.

You check that easily with ref $scalar eq 'ARRAY' or whatever guard you want.

Double colon would make talking about perl even worse (:: is namespace separator) -- it's already bad enough that any namespace starting with D becomes an emoticon in pretty much all online editors.

This stuff should just stop. Operating Systems / Browser vendors should instead standardize on a hotkey to bring up an emoji selector that steals focus to filter via typing and inserts on enter key.

Drop the therapy and start lifting weights. I'm not kidding.

If the problem is that you feel things are gonna be a slow decline from here, then fight it. Make that your new goal, even if you know it to be a losing battle. It will focus your mind on demonstrable milestones like hitting new deadlift personal best.

Even if you do something else, at the very least recognize that you've gotten to the point where you don't need to focus on the "work" and "money" part of life; as such treat this as an opportunity to focus on something new. After all, we only have a limited time on this earth to experience the things you want to do. This crisis is your mind's way of saying "I haven't done something I wished I had done." It isn't bad, it's just cognitive dissonance. Find the root of that dissonance and do that which would resolve the problems keeping you from finding fulfillment. This process will be emotionally painful but also cathartic.

Best of luck; know that every man has it within them to pull through this and come out the other end happy and fulfilled. So long as you are willing to question everything about why you are the way you currently are, you will eventually seek out the truths you need to proceed.

In my experience, playwright is a lot, lot better on this than selenium.

You can even choose different events to wait for!

That said, there's no accounting for developers who think FOUCs are normal, etc and generally make your life as a tester and end user difficult.

Puppeteer does a few more things, but only works for chrome.

Both of them are essentially wrapping devtools protocols. AFAIK, much of the playwright approach was guided by trying to Hew as closely to the puppeteer approach, but cross-platform. Both the APIs are very similar.

That doesn't really surprise me to be honest.

Most of this is invisible to end-users of selenium, as it's just a hammer they pick up; the struggles of the maintainers is not (nor should it be) something they have to worry about.

Nevertheless, they probably could get some hay mentioning that their API implements a significant amount more functionality versus every other cross-browser testing framework.

That said, they really don't have to, the work really stands by itself.

Cypress appears to have more features dedicated specifically to making testing easier, such as a user interface and various debugging additions and integrations into various other tools.

Playwright is just an API for controlling the browser, and appears to be far more powerful in that regard.

Compare the api documentation, and it's not even close: https://docs.cypress.io/api/table-of-contents

https://playwright.dev/docs/api/class-playwright

Playwright is a breath of fresh air next to selenium. And I maintain the perl selenium client and have written thousands of selenium tests!

So much so that I wrote what may? be the first third-party client for it: https://metacpan.org/pod/Playwright

Here's my writeup on why I like playwright versus selenium: https://troglodyne.net/posts/1617057517