creer

And for very small amounts too (compared to the whole mess). Fantastic return (on that little bit, out of the whole mess). Same for medical research.

In particular, investors often like to see the contrast of infrastructure development (investing in future GDP), as opposed to paying day to day operating costs, retirements, interest on debt (never mind larger debt as far as the eye can see), and other creative ways to prevent future GDP. And there is very, very little infrastructure development in US budgets.

Sure, if you have too much business that you can't be bothered to check these other leads. Same for browser incompatibility: you end up with a form which demands no blocking of anything, many specific js capabilities, MSIE only (I kid - you would think), etc, etc. Each incompatibility might only concern 2% of the population, but the whole mess mostly works flawlessly on the CEO's computer.

A single qualifying question like "What sport does your team play?" is a good direction - instead of the data fetishism of these forms.

They ARE suggesting such things (including forms of "not looking") even for deadly ones. In these cases, it is couched in terms of what follow-up is "deemed necessary" (see later) depending on stage classification of that cancer. There is a range of responses that's possible and new research and procedure advancement coming online on a 5-yearly basis in addition to variations in capabilities from hospital to hospital - so a pretty volatile environment - yet the staging recommendation gets changed often based on what health care professionals estimate they can sustain society-wide - i.e. manpower - rather than what might be optimal from a survival point of view for that patient.

To pick one specific example, skin cancer visual screening seems currently recommended on a frequency based not on the speed of evolution of, say, melanoma - which can start and evolve pretty fast -, but on the manpower availability of dermatologists.

Perhaps BOTH the "money-grubbing hospital admin" and the "very well-respected and honor-bound doctor" are wrong for not involving their patients in these decision? And their insurance for that matter.

Recently my US-system, world-ranking university hospital complex was first convinced that my insurance would not pay for XXX (and consequently did not recommend it and delayed it). Then after I insisted and got that done, they told me how surprised they were (1) that my (US) insurance did in fact cover every single bit of everything we eventually got done and (2) how MUCH that same US insurance in fact paid them for each of the bits. On the first try. That insurance company has horrible problems, but I can't complain that they didn't cover the hell out of the thing. You know - on the same year we read everyone else's horror stories.

The whole system is very sick.

One-liners is one of the ways you can use perl. You can also use it as the embedded language in some larger project. As perl CGI. As mod_perl. etc. There is no "cultural pressure" to use any of these. You can choose to mess around with one-liners and you can choose to spend time shaving a few characters off your code. Or not. None of this is the one true way. This is not python.

You indeed ran into toxic environments. I don't feel that the common, new perl programmer intake path was anything like that. Not what I ever ran into.

Support in forums and such was needlessly short in using RTFM as an answer. People could have pasted a one paragraph pointer to the documentation intake path and that would have helped.

I wouldn't call it hermetic in that the many forms of documentation are insanely thorough and accessible - if not well advertised. There is no gate-keeping (from my point of view). New users are welcome. It's easy to learn (for the people for whom reading is not an obstacle).

But yes, no contest that the world has been on a simplicity binge. Python won by pushing simplicity and by having giant software corporations choosing it (and not complaining about the line noise nonsense). If you want to go into programming professionally, for now many years, you need python.

I don't know that I would put Javascript in the same bag. I mean, it's the other way: it looks simple and it isn't.

But python, yes, python won because it looks simple and google pushed it.

Many other languages now have to reckon with the python supremacy. This is not specific to perl / raku. It will take work for anything to replace python.

> The whole point of crypto

There is a common confusion in this (perhaps?). Most businesses get created primarily to make money. Not primarily to solve the world's problems. It's easy to say "if they really had their customers at heart...". Well, yeah, but that's not and has never been the priority. It's not a cynical view, it's being realistic.

All kinds of mayhem follows. All the way to fundamental research papers such as "on average actively managed mutual funds do not beat XX index". Well, yeah, mutual funds don't get created because someone is good at it. They get created because someone wants to make money. Beating XX is not the first objective, or competence, of the entrepreneurs. Hopefully that fund doesn't last too long but often it does, and anyway there are many of them.

So anyway, there are plenty of ways to try and leverage ideas of cryptography, crytocurrencies, block chain - most of which are still accessible - and most of the ventures in the field are not going to be primarily about solving the users' problems.

You can't do that if you gave up at the very first sigil puzzle.

I'm fine with that: to program in Perl you need to be able to follow manuals, man pages, expert answers, - and even perl cookbooks, or CPAN or web searches. It's a technical tool. The swiss army chainsaw. It's worth it.

You COULD, if you wanted, and spent quite a bit of effort in the pursuit of that hobby, participate in one-liner, or obfuscation, or golfing friendly contests. Which were enabled by perl's expressiveness constructs. Nobody pushed anyone into that. On the contrary "there is more than one way to do it" was there to legitimize that getting the problem solved was the goal - instead of trying to force a one true way (like python).

After that, experts would often propose multiple ways to do something when they answered questions. THEY found that intellectually playful and exciting. They still do. And for the rest of us, that was an amazing way to learn more and understand more of that tool we were using daily. Still is.

You apparently saw viciousness in this and that certainly sucks.

Mostly - from here - python is so incredibly slow to write. Who has this kind of time?

Which is (sadly) hilarious because that was the reason most people seem to have gone with python: they were told "this is what we use here" or they bought the "line noise" nonsense. They never put much effort into this.

But I also think that people who are truly interested in programming immediately learn that there are many different paradigms. And the net makes it dead easy for them to explore different directions and, I don't know, fall in love with haskell or something. Perl is plenty visible enough for THAT. I don't know about perl 6 / raku though.

There was no such pressure. That's ridiculous. There were a lot of things people could grab as reasons to form an opinion without even reading articles, never mind the tutorial. They then ended up with php or python, even java for crying out loud, and years later THAT was a problem.

What exactly is complex or "super subtle" about this? It's the textbook example from the 1st chapter in the tutorial or something?

> in 2026, it'll be 11 developers writing it over 11 years.

Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.

It would be nice if academics would move to BOTH publishing the technical write up, AND a more understandable write up of their interpretation of the result (in more detail than the one liner which is in all abstracts.)

The technical writeup is necessary. It's what spells out what they specifically claim to have done, and the specific results. "Specific" being highly technical and fundamental in the scientific community understanding the paper correctly. In particular, the in-depth statistics of many such papers is simply too complex for most of the population to understand, and that's fine. The technical write-up uses terms of art which do not mean what civilians read in them. (And while it's hard to do studies larger than this one, this is all the more essential in smaller studies.)

The interpretation would be useful because it's just plain dangerous to let your PR department write that. Even if they consult you. And it is interesting to focus on what the scientists themselves think they achieved. Both what they deliberately went for, and any ancillary result they think they notice. In this case in particular, they are very focused on this safety aspect, and they seem to not want to give too much attention to the efficacy aspect (which they probably did not plan for and is then suspect.)

> Make an S&P10 then instead

How do you pick these 10? After the fact, necessarily. So then meaningless for tracking the economy.

"Now it's different". Is it really? One aspect of these stories is that we all do age and we do climb into higher positions. So we run into "too old" and "too qualified" and "will leave asap for something better". And the reason is not that the economy or job market are different. The reason is that we are older. Nothing wrong with both happening at the same time but this "I never ran into this problem before" does have a common difference which is "I was never that old before".

I use "old" for shock value here while being totally in the camp that companies would do well to find ways to use older, more experienced talent at a lower cost than "normal". (Even after I have run into "older" as inflexible and a pain to work with.)

But there is also another problem in many of these reports: Older and still applying by sending resumes in response for job postings! If you are older you should have a network you can use. If they find nothing for you - or don't care to talk to you, then THAT is the better signal. And still not necessarily a signal about the job market.

4. Overqualified can also be seen as you are seeking this job purely temporarily. While continuing to seek better. You may be gone within weeks. A more alert project might seek to use your experience at low cost for that little while. But a harried manager already had a problem and might see it as now having two problems.

The very specific example you chose: payroll, shows how it can be difficult to incrementally step from small to huge. As you grow from town to national, you will run into all the disadvantages without really hitting the advantages. I feel that incremental does help you move from one level to one just a few above. But only if there are enough customers at these starting levels exactly.

When developing for towns, you will have all small random subsets of the variations imposed by year after year of legal changes BUT small sales. You will have to implement niche variations in arbitrary aspects for all the towns you have to support AND you will not have the customer size on which to amortize this work. Each new customer will bring a new arbitrary set of legal aspects to be met. Each new customer may be arbitrarily difficult to support.

By the time you reach national, you will have already covered most of the historical legal quirks - but that will have been done in one kludgy manner after another - and then you will hit one more set of legal quirks at the level of national organizations (some of them will have their very own laws). You will now have a very large budget to finalize things but you will be burdened by an illogical software base.

So I agree that you will need experience and subject matter experts that have worked at the various levels. BUT, now that you have this experience you now know the degree of flexibility that is required (you know where and what needs to be variable and quirk-friendly and how far the quirks can go = "any size") as well as size-related issues (mailing, transaction, user support volume) and you can now plan for all this AS YOU restart a new development from scratch. Because at this new "master" level you need both systematic flexibility AND relience at size.

Payroll is exactly the kind of topic where "adding features" will be "fun" - I mean bewildering - while you learn, but probably economically difficult to manage, until it kills you "as you climb up"?

You will be killed by a large software project that can afford to hire out a bunch of your subject matter specialists (or hires new ones) and uses them in a "from scratch" project. If you are lucky, this large project will be from the same company but only if you are lucky.

Now. AFTER you have done the one top level project - for one country -, you will probably be in a good situation to sell service to all kinds of organizations. Because you now have a system in which you can implement ridiculous quirks without breaking everything. And if you have done the job just right, you can onboard smaller customers (towns) economically enough that they can afford your solution.

That's different from where you deploy your solution first. Sure, deploy a national-design solution first at a subset of the target employees - although that does impose more requirements still: now you need to coexist with the legacy solutions. Which would be another hard to meet handicap when developing for towns first.

I am agreeing with you that there was a mismatch between the expectations on using the elaborate documentation in its various forms and the tutorials and the stellar course - and a large set of potential users. Nobody expected "the entire book" but perl 5's rise came at the time when many stopped reading man pages, and many projects stopped providing them.

I agree with you that this probably was a contributor in some people giving up perl quickly. For python or php.

Like I mentioned elsewhere, for people for whom using a book would be a barrier - perl would have been a poor choice anyway. You can't program in perl without using the man pages and books. It's a large language, with lots of features purposely made less visible to the newcomer.

In addition, many people were exposed to perl from web scripts. And it was sooo tempting to just paste in a perl script, and then want to modify it, without spending any time on learning the language. Perl makes that frustrating (and compensates with a stellar course book). I still defend perl by arguing that (in perl) there is no point in discussing what $| might mean even before having covered the basics, for example sigils. The course book is layered, and for good reason: to let you write a program in useful order, fundamentals first. The special variables come up fairly early but then again the course book had an extensive index which includes these special variables first in a symbol section, and then again in the alphabetical order for their wordy version $| or $OUTPUT_AUTOFLUSH. I'm not trying to beat you over the head with the manual. Just pointing out that the course book was throrough and intelligently written.

I'll point out that throwing a question at a forum without poking around it a little to figure out the local mores - well, still now, that will get you barked at. Lesson: Forums would do well to provide a more useful paste-in than "RTFM" - ready to go for their users. Instead of "RTFM". At least if they want to foster adoption. Does any forum do that particiularly well, that you have noticed? Most discords for example, do NOT do that well: it's possible to create stickies and they are really not visible. So people create onboarding documents which then get too long and get skipped. A problem not solved there.

> none of them supported mod_perl

Once mod_perl existed (it was late, after lots of CGI perl) - I feel that my clients and I never had significant difficulty in finding providers. PHP was all over the place - it felt - more because there was demand. But there was enough demand for mod_perl that it was always there when we wanted it. We never had to really hunt for a hosting vendor.

> But at least for me, I realized with Perl 5 I wasn't smart enough for it.

I feel like you but I love it: I am not limited by the language. Not by perl 5 and not by perl 6: When I am willing, I can dig deeper and find more to work with. When I am willing I can try and follow presentations or books by Damian Conway, Mark Jason Dominus, etc and I can get new ideas and inspiration. I can always learn more about this fundamental tool that's at the center of what I build. The tool challenges me in a good way. It does not slow me down. It does not limit me. If anything in there is going to limit me, it's going to be my own brain.

And perl does that without tripping me. Because in perl, the intuitive way is one that's not likely to hurt you. While if you know better, you can work with the more elaborate, deeper features.

I hate it when I have to use a language that constantly limits me. It has happened. I am not always free to choose the programming language or platform. For some, it's so frustrating that I charge more. And it's still frustrating.

> flamed for not reading the full manual!

It was not for not reading the full manual. It was for not using the manual. Somewhere between "not at all", "not competently", "not persistently". And he was pointed to a perl-specific tool which is made for searching the doc. Not the same thing?

And he/they had missed an entire category of symbols. That none of the responses pointed at - their bad on that. That is, all these symbols are described in the same manual section. And used in illustrative examples all over the place. They are not exactly a deep hidden thing.

Also, regarding "flamed". No. Not really. They were handed the same response that countless other questions were getting. Anyone frequenting these forums saw them countless times. It is quite possible that it was their first time on that forum / chat and then that the answer was shocking and traumatic. Yes to that. So that in hindsight, the standard response should have included a pointer to a "how to use the doc" doc. That would have helped. Since it was a generation was seemed unaware of the man pages.

> I just didn't feel the need to stick with it.

So, to touch on that, no contest that for a while now, you can have a well paying job only writing python. (And perhaps even never going through a formal course on it.) That has worked for many people.

> There must be a reason why they made sigils more "traditional" in Perl 6, for example.

Eh. Sigils are even more present / visible in perl 6. And other compact notation devices. All the way to making up your own unicode-based line noise when it serves. Which it does.

I know you are not serious but let's go with it anyway. Since we have to be welcoming to newbies :-) Not expected to read cover to cover. Cover to cover would be the tutorial / course work. And even then in a layered language like perl 5, the later chapters only when needed. Layered: the language and coursework is written to add one layer of the language after the previous ones. So you can start writing things that do function after just the first layer.

Expected to know it's there, navigate through it to find the operators or system variables and that you can search through the thing. There are ~260 perl man pages on this computer - not expected to read them. For damn sure expected to use them.

Do read one more section from top to bottom now and then - if the thing is the one fundamental tool in your job!

I have exactly zero functions that are written in both. So comparison is just intuitive:

My current projects make extensive use of numerical functions AND of regexes and grammars. Both used extensively. I am very satisfied with the performance on both aspects. It does the job. And there is no question that for the regexes and grammars, what I have goes FAR beyond what I ever dared to run in perl 5. Performance is good, including on this stuff that I feel would have been pushing perl 5.

Still, I write for expressiveness. It matters to me how fast I can write. And I am NOT satisfied with "searching through the doc". That's the main sore point for me. The doc is very good but online-first and local... eventually. So I am stuck using an online search function... which constantly falls short.

> Perl 6 would have had to be a better Perl 5 and a better Python 2 to win.

Don't sell perl 6 short. I am using perl 6 for significant projects now (after a career of perl 5) - and it's fundamentally different. I describe it as perl to the power of perl.

For me, expressiveness is fundamental. And perl 6 gives me that.

Perl 6 is simply suffering from python being everywhere. And perl 5 was always easy to lampoon as "line noise". It's a stupid quip, but it leaves a mark on new programmers. You don't even need to read the course and you can already have an opinion. Stupid kills? And then perl 6 doubled down on that anyway. Then I doubled down on that ALSO and I get to use (carefully chosen) unicode symbols in my line noise :-) So there.

> It has a logic but it's its own logic.

Which is covered in the very first section of the course book? Yes it has its own logic. So do lots of programming languages.

How far do we need to take "not reading the doc"? That the very first chapter is too far? People who gave up on perl because of that... really would not have survived the rest of the course anyway?