|
|
Subscribe / Log in / New account

Book: Perl 7: A Risk-Benefit Analysis

Dan Book has done a detailed analysis of the Perl 7 transition. "Large amount of CPAN modules will not work in Perl 7; plans for working around this would either involve every affected CPAN author, which is a virtual impossibility for the stated 1 year time frame; or the toolchain group, a loose group of people who each maintain various modules and systems that are necessary for CPAN to function, who either have not been consulted as of yet or have not revealed their plans related to the tools they maintain. Going into this potential problem sufficiently would be longer than this blog post, but suffice to say that a Perl where highly used CPAN modules don't seamlessly work is not Perl."

to post comments

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 3, 2020 20:33 UTC (Fri) by jafd (subscriber, #129642) [Link] (9 responses)

At first I thought someone already published a book, and my first thought was, “Wow! That was quick!” :-)

The biggest pain in the behind when transitioning to a new Perl release usually is that a small obscure module which is a fourth-order dependency to a library you absolutely need, breaks.

The problem is not endemic to Perl, but while in Javascript modules grow and die overnight like weeds, Perl modules are like oak trees in the forest, decade-old ones are considered relatively new, and if the maintainer responds to you in the same quarter you wrote to them, it’s considered a quick response.

It’s more likely, though, that the module’s author has moved on to something else. Or that the module is a hostage of a feud between prominent “community members”. (My god, they are the reason I despise being a part of any “community”.) The efforts to give new life to such modules and bolt-on something like this to CPAN do look like they were bolted on and clunky (alt::Devel::CallParser::ButWorking, really?)

The whole illusion that CPAN is really comprehensive is hinged on the fact that Perl is extremely backwards-compatible. Introduce a slight incompatibity you cannot mitigate with an env variable or a clever option you can propagate down to all call levels, and the house of cards falls.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 3, 2020 21:39 UTC (Fri) by bobsol (subscriber, #54641) [Link] (7 responses)

What happened to Perl 6?

I'm still waiting for it. What did I miss?

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 3, 2020 21:59 UTC (Fri) by jafd (subscriber, #129642) [Link] (2 responses)

It’s called Raku now and to date I’ve heard of no production code it’s running.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 8:22 UTC (Sun) by niner (subscriber, #26151) [Link] (1 responses)

There is plenty of production usage of Raku. We now use it even in mission critical code. It's very nice to use a language that unlike Perl or Python doesn't pretend it's the 90s anymore.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 15:37 UTC (Sun) by dskoll (subscriber, #1630) [Link]

Are there any major open-source projects written in Raku? Like the GP to this comment, I've never seen any production projects using it.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 4, 2020 12:25 UTC (Sat) by cesarb (subscriber, #6266) [Link]

> What happened to Perl 6?

It was released at the end of 2015 (see https://developers.slashdot.org/story/15/12/26/0354235/pe... which pointed to what now can be seen at https://web.archive.org/web/20151228135402/https://perl6a...). It had an specification/implementation split, the first release of the implementation after the specification was released seems to have been at the start of 2016 (https://web.archive.org/web/20160209023713/http://rakudo....).

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 4, 2020 16:14 UTC (Sat) by vadim (subscriber, #35271) [Link] (2 responses)

It had a long and tumultuous development process, with multiple projects that didn't work. There was Pugs, Parrot, Rakudo, and a bunch of others I'm forgetting. Rakudo is the one that survived.

Based on some googling around, the main reason seems to be that there wasn't a good process in place. The project attracted a lot of theorists and experimentalists that didn't have much of an interest in releasing stable code, while the people that did were pushed out, or left on their own. Larry Wall was unwilling to crack the whip, and thought that things would work out by gently nudging people.

The problem is that as soon as Perl 6 was announced, lots of people started waiting for it. Especially once it became clear it would be quite different. The fact that Perl 6 wasn't released promptly was combined with the fact that the rest of the world didn't want to wait, so people moved on to greener pastures, considering Perl 5 to be dead, and Perl 6 to be too far away.

Finally, the idea that Perl 6 wasn't really Perl 6 but something else took hold, and it got renamed to "Raku". For instance, Raku doesn't support XS because the guts are completely different. That means a lot of Perl5 can't ever be ported to Raku without redoing the binary bits.

Overall, I think this was a good decision but might have been too late. It needed to happen soon after Perl 6 started. Also even then, it'd probably have had a detrimental effect on Perl5, so a stable release would need to come out as soon as possible.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 4, 2020 17:32 UTC (Sat) by bobsol (subscriber, #54641) [Link]

Vadim, thank you for this answer.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 4, 2020 19:53 UTC (Sat) by martin.langhoff (guest, #61417) [Link]

Also - Larry and Damian Conway had unfortunate personal circumstances, different for each of them, and at different times. Nobody's fault, but they could not give Perl 6 and the community the TLC it needed at a critical juncture.

Very unfortunate. I cut my teeth with Perl 5, and built some fantastic stuff with it. For all its faults, I could be writing messy one-off scripts in the morning, and cranking styleguide-strict production grade code in the afternoon. I used to maintain some CPAN modules.

With Perl 6 stalled, people moved on to Python, or Ruby (which looked very close to the Perl 6 vision, with simpler sigils), or more exotic stuff - Elixir, Go... and bash matured a bit (but not enough).

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 6, 2020 13:11 UTC (Mon) by smonff (guest, #139961) [Link]

> At first I thought someone already published a book, and my first thought was, “Wow! That was quick!” :-)

It's actually the case, brian d foy published Preparing for Perl 7 : https://leanpub.com/preparing_for_perl7

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 8:36 UTC (Sun) by cyperpunks (subscriber, #39406) [Link] (7 responses)

It's hard not to say Perl (any major version) will be next decade's Cobol.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 10:20 UTC (Sun) by thumperward (guest, #34368) [Link]

In terms of job opportunities ("maintain this legacy codebase forever" or "contract around to emergency-fix this code nobody else can read") it already is, with commensurate compensation.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 14:11 UTC (Sun) by tjc (guest, #137) [Link] (5 responses)

I think Java is on track to become the next COBOL.

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 14:14 UTC (Sun) by amacater (subscriber, #790) [Link] (1 responses)

I'm not so sure - as we're occcasionally (re)discovering, COBOL remains useful knowledge ...

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 23:15 UTC (Sun) by ncm (guest, #165) [Link]

Exactly the point.

COBOL is, itself, the next COBOL, to be joined by Perl and Java as peers. If this evokes visions of the Lava Flow anti-pattern writ large, we are in agreement. COBOL's next generation will need to be facile in all three.

Certainly, most new projects that would once have been done in COBOL are not, anymore. It looks like Java inherited that mantle. New projects are still started in Java, hard as Oracle tried to kill it. Perl, Python, and for a while Ruby picked off the top, but a great deal of such work migrated to web tech and Javascript.

We can't identify Javascript as a COBOL inheritor yet because nothing appears poised to supplant it for new development, howsoever lucky we would all be if at least Typescript were.

Meanwhile, for systems programming, nothing will touch C++ for at least twenty years(*), present Rust enthusiasms notwithstanding. Rust has passed the point where it might have Jumped the Shark, but it can still become Erlang just by not growing its user base quite fast enough. It is not yet growing at anywhere near a sufficient rate, but still might, and must.

Rust enthusiasts should seek new users from among the best Java and Go coders, frustrated at those languages' limitations, even though most on those could never make the jump. C coders would be prime candidates (and we would all be better off if they switched) but any who might have jumped ship did long ago.

(*) Provided civilization even lasts so long. Not looking good.

Java: here to stay

Posted Jul 6, 2020 2:32 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

From the perspective of making below average, 9-5 developers produce somewhat readable code[1] with minimum education and effort, reasonable performance, reasonable number of bugs and a fairly low number of security issues I don't think there is much that comes close to Java. Except maybe C# which is or used to be a (more; now less?) proprietary clone of Java or Kotlin which is a very impressive Java++ with that makes programming it almost enjoyable https://www.youtube.com/watch?v=X1RVYt2QKQE
The sweet spot between human vs machine readable and the lack of kludges like pre-processing also allow extremely powerful IDEs.

Its small market share on the desktop is just the tip of an "enterprise" and Android[2] iceberg that is everything but melting. If not in Java itself, new projects will still be started in something very close to it for the next couple decades. Programming in Java is rarely fun or exciting or ground breaking but almost always "good enough".

I wish the COBOLs of the next decades will be unsafe languages but considering people prefer buying "security products" rather than secure products I'm not holding my breath.
https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

[1] Try showing random pieces of Java code to non-Java developers. Try the same with Perl or COBOL.
[2] BTW, how is starting up a Java app on a mobile generally faster than a JVM on a PC? What is the Android "magic" there?

Java: here to stay

Posted Jul 6, 2020 2:42 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> [2] BTW, how is starting up a Java app on a mobile generally faster than a JVM on a PC? What is the Android "magic" there?
Android keeps an initialized copy of JVM in a special process ("zygote"). When it wants to launch a new application, this process is forked and the new instance uses all the pre-initialized classes.

Modern Android versions also precompile DEX classes into native code.

Java: here to stay

Posted Jul 6, 2020 4:17 UTC (Mon) by marcH (subscriber, #57642) [Link]

Thanks!

Conversely, this is another reason why we are (like it or not) near the end of Java: https://en.wikipedia.org/wiki/List_of_JVM_languages
The reason why so many languages target the JVM is because of the quality of the specification a.k.a "It Just Works". A probably boring but solid engineering foundation, exactly the opposite of:

> The project attracted a lot of theorists and experimentalists that didn't have much of an interest in releasing stable code,

Book: Perl 7: A Risk-Benefit Analysis

Posted Jul 5, 2020 23:53 UTC (Sun) by gerdesj (subscriber, #5446) [Link] (4 responses)

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.


Copyright © 2020, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds