Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 23:53 UTC (Sun) by gerdesj (subscriber, #5446)
Parent article: Book: Perl 7: A Risk-Benefit Analysis

I love to see this sort of thing. IT bods in general are the laziest bunch of tossers I have ever met. We sit pontificating on xyz whilst the world burns. We will whitter on about "moving fast and disrupting (the food trolley)". IT is still growing up. It needs to understand that and grow up.

Perl is one of our building blocks. It is term served. Is there anyone here who has not heard of or not used Perl? There are several other equivalents to Perl that can generate code that our CPUs can work with.

If the devs behind Perl decide to change things to suit themselves then fine. If you want to use Perl then you have to accept that it might change a bit. If your business depends on Perl then you will be one of those devs or you will keep an eye on things.

Grow up!

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 6, 2020 12:45 UTC (Mon) by ledow (guest, #11753) [Link] (3 responses)

Before you get close to that, you have to convince users that "software" is not a static item that you buy once and it magically works forever, taking account of every system change along the way, *and* automatically stay secure.

And then you have to convince them that they don't own anything unless they literally have a full source code to the software, license to use it, a working development environment that can compile it, and someone on staff who knows how to do that.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 6, 2020 12:59 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> Before you get close to that, you have to convince users that "software" is not a static item that you buy once and it magically works forever, taking account of every system change along the way, *and* automatically stay secure.

s/users/accountants/

Most of the malaise in IT comes from the ones holding the purse strings, not the poor sods who actually have to *use* the final pile of bovine droppings.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 8, 2020 5:41 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

In some industries, we are now reaching the point where the accountants know perfectly well that the software will not evolve to meet changing circumstances. The problem is that they have responded to this by attempting to prevent circumstances from changing.

For example, in October of last year, the United States Air Force announced that it had just figured out how to launch a nuclear missile without the use of 8-inch floppy disks.

To give an example more obviously* related to accountants, the financial system of the United States is still critically dependent on a variety of hilariously outdated systems. They have the unusual property of being so old that they are paradoxically secure against the internet's "background radiation" of opportunistic non-targeted scans and attacks (because they use EBCDIC instead of ASCII). Or at least, they would be, if the banks were foolish enough to let them anywhere near a live internet connection in the first place. Instead, my understanding is that they are entirely confined to a series of air-gapped private networks, with limited internetworking for ACH processing etc.

* The (discretionary) US military budget for fiscal year 2019 is approximately $686 billion. For context, that is substantially greater than the entire GDP of Belgium (as of 2018).

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 8, 2020 16:19 UTC (Wed) by jccleaver (guest, #127418) [Link]

Honestly, whether all that is a bug or feature depends on your design philosophy more than anything else.

Well-engineered code takes time -- a lot of time -- to lock down. If you're of the "move fast and break things" mentality, then you can do a lot quickly. If "move fast and break things" means the bank goes under, that's not going to fly.

A well-rounded software engineer or systems engineer should be familiar with the benefits and drawbacks of both worlds, have some experience in both words, and be able to call on others when the design parameters exceed their comfort and abilities in either direction.