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.
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.
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.
There wasn't pressure to write concise code exactly, but if you posted your code somewhere the odds were good that somebody would reply with a way to do the same thing with less code, followed by someone else who managed to shave several lines/characters off of that, etc.
While almost all of the time it was all just people having fun (perl is fun and play was encouraged) and not an admonishment of the code you'd posted or an example of how it should have been written I can see how some folks might have gotten that impression. Especially if they were new to perl and were more used to languages where TIMTOWTDI wasn't thing
There was strong cultural pressure to be able to write perl in as few bytes as possible, ideally as a CLI one-liner. Books[1] were written on the topic.
> There was strong cultural pressure to be able to write perl in as few bytes as possible
Hard disagree. Many Perl programmers enjoyed engaging in code golf (always just for fun, in my experience), but in my nearly 30 years of programming Perl, I never encountered anything that I would call pressure to do so -- not from anyone.
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.
I lived it. I'm sure there's still some Mailing List archives and IRC snippets that still endure, demonstrating the utter vicious 1-upmanship of how to do something in Perl as succinctly as possible. Why do X and Y when you can just do Z? What are you really trying to do? etc.
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.
Those experts were horrendously vicious. I can name them and can still describe their dismissive cruelty, since I spent ten years socializing nonstop in the Perl5 core communities (and have a CPAN id, and have an Authors entry in Perl5 core). Think “Linus before he learned to stop insulting people’s worth and focus on critiquing their work instead”. It was absolutely intended as a form of cultural propagation: I can do this more succinctly, so You Should Be Ashamed Before Me. If somehow you weren’t exposed to that aspect of it, I envy you.
Interestingly, that same prideful “my way is so obviously better that it’s a ridiculous waste of my time considering yours” ended up carrying forward to Mozilla, which was launched in part by cultural exports of the Perl5 conservative-libertarian community, and for a decade developer hiring was filtered for cultural sameness, leaving a forest of TMTOWTDI trees that viewed meadows as an aberration to be reforested back to their sameness.
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.
It was primarily the exhaustion of experts at tireless waves of newbies who hadn’t studied the available materials.
IRC being async if the client is run locally, modem delays made no difference (just as with QWKmail and forum posts). And for remote host IRC, I don’t remember what the IRC line length limit was but at 300bps you could get an entire message and the buffer scroll updates accompanying it in 1 second, which was well-sufficient enough to support peak volume with no relevant latency. And, I can still type a paragraph at clock seconds of input latency and remember where I’m at when backspacing. So, I would definitely not ascribe a desire for brevity as an outcome of modems.
It's just very non-obvious what the code does when you're skimming it.
Especially in a dynamic language like Perl, you wouldn't know that you're passing down an integer instead of a function until the code blows up in a completely unrelated function.
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.
Seems like you and a few other posters are making the article's point – that Perl's culture is hermetic and that new programmers would rather learn Python, Ruby or Javascript rather than figure out which sigil means what.
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.
