Should Perl 7 Be Backwards Compatible?

Long-time Slashdot reader destinyland writes: What's up with Perl 7? Perl Foundation board member Ricardo Signes tried to sum up the state of the community in a detailed post to the "Perl 5 porters" mailing list. And in a section titled "To Break or Not To Break," he writes that "The central Perl 7 question is not about version numbering, but rather about backward compatibility guarantees..." And more specifically, it's how to respond to the question of whether Perl 5 "is too constrained by backward compatibility to grow significantly in utility or rate of use." He presents three possible responses:

— Reject the premise. "There is a lot of room for forward motion without breaking changes, if we would just stop trying to change the rules and move forward."

— Accept the premise, but then "let Perl continue along its current course, becoming ever more stable as it is used by an ever-diminishing audience until it is given its rightful place in the Hall of the Honored Dead."

— Or, "figure out which constraints can, like chains, be shrugged off so we can move ahead..."

While he sees merit in all three positions, the core hope of the Perl 7 plan is choice #3. "Maybe there are kinds of backward compatibility that can be shrugged off without disrupting the vast majority of Perl users, while making the language easier to use and (very importantly) easy to *continue* to improve." And more to the point, "We aren't picking up new core developers for a bunch of reasons, but one is 'it's just too much of a slog to -do- anything.' So I am in favor of making selective breakages in order to make the language better and the implementation more workable. I think this is the core of the Perl 7 plan, and the big question is 'what are those selective breakages.'"

That section is followed by another one titled "How Shall I Break Thee?" ("The impact on existing code is a big question to be answered. Nobody is arguing that we'll attract a new set of users and developers by first alienating all the existing ones.") While there's good suggestions, right now "The plan is to come up with a plan."

And this starts with creating a document to formalize the governance model of the Perl Steering Committee as their way of pre-forming some early consensus and refining ideas before they're then put up for general discussion on the mailing list, with a project manager giving final approval to the larger community's decisions. This will then be followed by "producing a clear set of intended changes..."

"Until that happens, I just hope for a little period of calm and good faith."

Fourth option

[NicknameUnavailable]

Change the starting line from #!/usr/bin/perl to #!/usr/bin/perl7 and maintain backward compatibility while adding new features.

Fifth option

[goombah99]

Just stop developing perl. Keep it maintained.
Perl is a freaking awesome language for many many uses. It's so much better than Bash for example. It's not like Bash has to keep developing. So why does perl? Just let it be the awesome language it is without people needing to learn new useless things just to read other people's code.

Because regexes don't have whitespace, so hard?

[raymorris]

I've wondered why more people don't use Perl. It was the most-used language for web development, by a large margin. I've programmed a lot of things in a lot of languages and Perl is my main go-to for tasks where that general type of language is suited. So why don't more people use it? What could be improved or adjusted to make it better for more people? I have two theories. I wonder what everyone else thinks it might be.

First, I hear "it's hard to read". People don't say that for no reason, something must actually be hard to read, at least for people who aren't used to it. Is the general syntax hard to read:

for $person ( @people ) {
        print "Hello $person\n";
}

I don't think they mean that is hard. Am I right? I think what's hard to read is the way most people write regular expressions. Most people write regular expressions without any whitespace, and without meaningful names. Yeah that's hard to read! Any language is hard to read if you don't ise any whitespace!

A lot of people write regular expressions like this: /([0-9]+)(.+@.+)(.+)/
$s = $1
$e = $2
$n=$3

That matches some pattern of characters, but what - what is it?

That's a very short regex, but it definitely harder to read than it needs to be. You can (and should?) use whitespace and meaningful names, just like any other language. Here is the same regex, with whitespace:

/
    (?[0-9]+)
    (?.+@.+)
    (?.+) /x

That's the same regex, with whitepace and meaningful names. I think that's much clearer (though of course it helps if you know the regex language). Does that make it easier? I think so, especially as the regular expressions get longer.

Funny thing, that regex is also just the same in .Net and Python. Python and .Net are no more readable for regex - they are just the same. It just so happens that Perl is often used for processing structured text, and regular expressions are used for text processing, so many times people use them together. If you don't want to use regular expressions, you don't need to. Perl doesn't force you to use regex any more than Python or .Net does. Yet, traditionally Perl programmers have used them often.

My other theory has something to do with perceptions and "the hot new thing". Perl stopped being THE language for web development when PHP caught on. (Which is funny because PHP was originally a CMS written in Perl and C.) People liked PHP because they could arbitrarily mix PHP programming code with their HTML UI code. PHP became the hot new thing and Perl was seen as "old-fashioned".

Later, people started recognizing the problems with PHP. The PHP designer, Rasmus Lerdorf, has said that he wasn't trying to design a programming language and he doesn't have any know anything about how to design a programming language. It shows.

So we had the "old-fashioned" Perl and somewhat crappy PHP available when Python showed up on the scene. Python was easy. So easy, it's what Lego chose to let kids control their Lego Mindstorms toys. Lego is an easy way build things and so is Python, so they are popular and they work well together.

When Python was introduced, Perl was more mature, stable, powerful, etc, but there was seen as "old fashioned" after the PHP fad.

* For anyone wanting to claim Python has always been mature and stable, let me remind you of three different mutually incompatible languages you might have forgotten about:
Python 2.6
Python 2.7
Python 3.0

Ugh! Slashdot ate the example code!

[raymorris]

That more-readable example should have been:

/
  (?<score>[0-9]+)
  (?<email>.+@.+)
  (?<name>.+)
/x

Re:

[raymorris]

Email addresses starting with digits are perfectly valid. Most ASCII characters are allowed other than whitepace and control characters. Once upon a time domain names couldn't start with a digit. Now they can.

That said, .+@.+ is too general. For example, it allows this invalid email address:

----@....

Re:

[phantomfive]

Everyone chooses their programming language for their own reasons, but a lot of people choose Python because it's the language they first learned in college. Why do colleges teach it as a first language? Again, each college has their own reason, but when they started, Python had a more mature class model than Perl, at a time when Object Oriented Programming was very important to professors.

Re:Because regexes don't have whitespace, so hard?

[raymorris]

> a lot of people choose Python because it's the language they first learned in college. Why do colleges teach it as a first language? Again, each college has their own reason, but

If I'm teaching Programming 101 (which I do at times), I'm going to choose a language that is easy to learn and easy to do simple things. Python is easy in this way. Python is a good intro language, to learn the basics of programming.

If I'm teaching Programming 102, I might well continue to use the same language students learned in 101. So it makes sense that schools would choose Python for the first couple of classes teaching programming concepts. It's well-suited to that need.

Having said that Python is easy, I should be clear about the down sides of that as well. In Python, it's easy to make simple things, including mistakes. Including bad mistakes. Python is an easy way to build simple things; Lego is an easy way to build simple things. You don't build your enterprise-grade products from Lego. Python is easy for simple things and quick to write because it doesn't demand rigor. Just for one example it's untyped / dynamically typed. That means it's *harder* to make more complex things, bugs happen more. It takes less time to make something simple in Python than in a language that is more careful (and will avoid time-consuming bugs in more complex software).

I'm not trying to put Python down nor be a cheerleader for Python - different tools for different tasks. Python is well suited to teaching the basics and scripting simple tasks that aren't business-critical. It's also great for working with very large integers quickly and easily, such as used in cryptography.

  Personally, I use it for breaking crypto and doing crypto POC because it's a quick way to do those things. For other tasks, I use a language designed to have fewer bugs by being more explicit.

Re:

[phantomfive]

Personally, I use it for breaking crypto and doing crypto POC because it's a quick way to do those things

It's quit mainly because there are libraries available for that in Python.

Re:

[raymorris]

> It's quit mainly because there are libraries available for that in Python.

I think I missed your message, probably due to a typo messing up one word.

Anyway, the cool thing about Python for crypto is you don't NEED to use a cumbersome large integer library - big ass numbers "just work" in Python. In Python I can do this:

847493639462036303602630362037936 - 749360372036026394

Re:

[Dutch Gun]

Pfft. I can do that in C as well. Watch:

847493639462036303602630362fi$2$%$*++-+---- NO CARRIER

Re:

[aralin]

You teach Python in schools because people work on their own or in small 5-10 member teams at most. Choosing this language handicaps the students in major way because it is really problematic when working in large teams. Work in large teams is something universities already struggle to teach and when it is coupled with teaching a language that is just really bad at that, they multiply their current problems.

Re:

[sjames]

You don't build your enterprise-grade products from Lego.

Of course not, Lego isn't nearly brittle enough or brutal enough for the enterprise.

Re:Because regexes don't have whitespace, so hard?

[phantomfive]

Because in preschool they keep byting each other.

It's funny because they do

[raymorris]

Funny thing is, they do. In preschool, they teach "in the small", kids learn "move" and "copy", which is assembly level. They learn individual letters (bytes). It's only later that learn sentence structure, which in programming is:

customer = (new person).initialize-type('customer')

Or whatever.

Learning programming via Python is kinda like learning to write journalism without ever learning the difference between letters, such as "a", and numbers, such as "5".

In preschool and assembly they learn that letters

Re:

[AleRunner]

What is comes down to is this, people who've learned Python it's because they were told by somebody to do so and then just kept using it as the tool they needed. People who've learned Perl simply were just trying to get shit done so they could get back to slacking off. The perl hacker doesn't care about language purity, he cares that it does what he needs it to do.

Yeah - maybe for many? Well I moved to Python because it allowed me to get perl stuff done but wasn't perl. I specifically liked the cultural differences, where almost arbitrary choices are made the opposite way to perl, ("There should be one-- and preferably only one --obvious way to do it." vs "There's more than one way to do it") but i didn't care that much about most of them in specifics. What drove me away was the lack of commitment to delivering a working programming environment that meant I no long

Re:

[theCoder]

You must be looking at Python through rose colored glasses. When I first had to edit some Python code, I needed to get the length of a string. I looked through the str class docs for some method that would return the length. There are dozens of methods on that class; surely one of them returns the length, right? Not really. I did eventually find __len__(), which returns the length, but it's kind of ugly. It turns out that you're supposed to pass the string object to a global len() method to get the le

Interesting. My 20-year Perl is fine on new system

[raymorris]

I'm surprised. My first two years of experience with Python is that EVERY time I tried to run a Python script from the internet, I had to wither install yet another version of Python or re-rewrite the script to run in a version of Python I had. Every time.

I learned that these are three separate totally incompatible languages:
Python 2.6
Python 2.7
Python 3.0
(Also, Python 2.8 isn't technically Python at all)

These were not changes to little aracane things. Three times in three years they broke stuff used in e

Re:

[AleRunner]

I can imagine what you say is true. However, I don't think it means what you think it means. When I was writing lots of perl I had similar issues to the one you describe up to and including having to get involved in the interpreters to a limited extent. I think that's inevitable for any language that is moving forward and where developers care about the new versions of the language - the developers will use the new features and so you will find you have to get the latest version of the language. I also

Re:

[raymorris]

If you were trying to use what was then called Perl6 or perl-dev in production, years before it's release, I imagine you WOULD have problems. When a language was released with the full Perl6 design, it was called Raku, not Perl. It wasn't named Perl because it's not Perl. It's Raku.

At work, do you have dev servers, then staging, then production? So does Perl. Perl6 was "here is where we try out new ideas". Kinda like Fedora and Red Hat Enterprise Linux. There never will be a Fedora version that's appropri

Re:

[AleRunner]

I'm not using perl6/raku it, never have. What you say is now true, but "raku", the prototype environment, is not how it was originally sold. This was the future of Perl at a time when I was getting really frustrated with the perl community's attitude to packaging. Around 2001/2 (if I remember right) I decided to leave it until the Perl 6 vision stabilised since the things I cared about working on would have been completely transformed by perl6 if delivered. I'm still waiting.

Re:

[raymorris]

I see.

> Around 2001/2 (if I remember right) I decided to leave it until the Perl 6 vision stabilised since the things I cared about working on would have been completely transformed by perl6

Probably a tad later because it was 2001-2004 that Larry wrote the first draft of the "Apocalypses", which outlined in general terms what Perl6 should be. That is, in 2004 he decided more or less what objects should be in Perl6. You're probably thinking of somewhere 2003-2006 if you had any concrete expectations. (A

Re:

[sjames]

The only breakage I have ever seen in Python is between 2.x and 3.x. There are tools available to update and the manual fixups required afterwards aren't THAT bad.

You forgot they broke print in 2.6 also? And 3.7?

[raymorris]

I guss you forgot, they broke print formatting (Python's equivalent of printf, used in most scripts) in Python 2.6. Until 2.6 broke it, you'd print string like this:

print 'Name: {} Score: {}'.format(name, score)

They friggin broke it in 2.6, so anything that outputs ... broken.

Then they broke it again in 3.0. So every script ... broken.

Then in 3.7 ....

Re:

[kbrannen]

I don't have the details like Ray does, but he's right.

We had a Python 2.4 program that broke all over itself when moved to 2.6. The original programmer was gone and I didn't trust the only remaining Python developer with it as he had guided the original programmer (the program ate memory & CPU like a starving person). So I write the tool in Perl under 5.14. We're now on 5.30 and I haven't had to change a line of code for it to continue working.

Re:

[sjames]

I guess I never saw that because I used the form: print "Name: %s Score: %d"%(name, score)

A tangent on the relationship of Perl and regex

[raymorris]

I mentioned that Perl and regex are often used together because they are good at processing text-based data. While that's true, ot occurred to me that's not the full story of why they are often used together. The tradition of knowing and using regex is based on the history of a series of related languages.

In the beginning was the text editor, named ed.

For use in pipelines, McMahon made stream-ed, or sed.
Sed mostly used regex to specify which lines to operate on, and how.

Sed had a command to globally print lines matching a regex, g/re/p
g/re/p was used so much, a grep command was created

Sed and grep were good for text streams.The Unix creators, Bell Labs, wanted to add better handling of numbers, so they extended sed and grep to make awk.

Awk was so useful, Bell programmers wrote large programs in it, despite the fact it had originally been designed primarily for one-liners.

There was a need for a language with the strengths of awk, plus language features for longer programs. Larry Wall created Perl to fill this need.

Perl was immensely popular, and so quickly grew to be much more than just awk plus.

So:
ed -> sed -> grep -> awk -> Perl
And regex was important in sed, so people who used this line of tools knew how to use regular expressions.

Re:A tangent on the relationship of Perl and regex

[TechyImmigrant]

My problem with regex is that it is so unmemorable. I've been using regexes is various languages on and off for over 30 years. But each time I return to it I have to get my regex reference out to remind myself of which symbol means what. If full keywords had been used instead of random punctuation symbols, it would have been a lot easier to remember.
 

Re:

[toddestan]

The other issue with regex is that it seems that everyone has an implementation that is slightly incompatible with everyone else's. A good portion of that is also syntax-related, as different things either need or not need to be escaped.

That's mostly fixed lately with PCRE

[raymorris]

That was a problem. Over the last few years, most things have either switched to or added PCRE (Perl Compatible Regular Expressions). If you find the native regex in any given tool awkward, check to see if it doesn't also have a PCRE function/mode.

Re:

[raymorris]

That's an interesting point. I wish some key people had read this comment 40 years ago. :)
Just as Perl has the English module which gives plain-English names for the special variables, it would have been easy to add a "verbose" or "English" syntax for regex, which would translate directly to the symbolic representation.

Personally, I use Linux a lot, so I use regex frequently with sed, grep, awk, etc, so I remember all of the regex stuff that is used by any but a small number of people. I could see how it c

Because PHP is a better option for the Web.

[Qbertino]

I've wondered why more people don't use Perl.

Because PHP is a better option for the Web. PHP is basically Perl as a template engine. With Perl you still had to jump through some hoops, with PHP it's beyond trivial to programm SSI for the Web. Hello World in PHP is "Hello World!", deployment in PHP is "copy, paste, finished". PHP has no memory leaks, only the occasional timeout. And because it's a template language, you can keep your static documents and slowly infuse them with logic whenever the need arises

Re:

[AmiMoJo]

Perl is great for processing arbitrary text but most of the world has moved on to structured text where stuff like regex isn't needed. Data is stored in JSON or XML.

Other languages have additional benefits like a clearer syntax, better debugging tools, more modern libraries etc. Perl also has some issues like tending towards becoming unmaintainable as time goes on due to programmers using too many clever regexes and loosely structured text formats for data storage.

Perhaps it's a bit like C, ideal for some t

Re:

[h33t l4x0r]

Because everything is done in teams these days, and getting Perl developers to work together is like herding cats.

Re:

[jrumney]

I've wondered why more people don't use Perl. It was the most-used language for web development, by a large margin.

You forgot to qualify that. Between 1993 and 1995 would probably be about accurate.

Peak was 2002-2006, king on the web 1992-2006

[raymorris]

TIOBE shows Perl's peak was 2002-2006, with over 10% of *all* programming during those years.
https://jaxenter.com/perl-tiob... [jaxenter.com]

It was the language for server side (cgi scripts) from about 1992-2006, when PHP took over the web. Then Python came along later.

Re:

[jrumney]

By the early 2000's, Java was the language of server side. PHP was making serious inroads around then also. Perl, stuck in the CGI past, was already fading for web use. Python has never been significant for web use, its dominance has always been in test automation and now AI.

Re:

[raymorris]

I love how you absolutely ignore the hard data, and just repeat what your guess was. Bernie voter?

Re:

[doom]

I've wondered why more people don't use Perl.

More people don't use perl because the computer science intelligensia regarded him as a weirdo outsider who had the temerity to suggest they don't always know what they're doing.

Larry Wall intentionally used elements of human languages in perl's design (meaning inferred from context, pronouns), and ignored the mathematical elegance that's a religious obsession among the CS gang.

They responded with what amounts to a smear campaign that dragged on for many

Re:

[gweihir]

Indeed. Perl 5 is not broken. Please stop trying to fix it. It makes things worse.

Re:

[kbrannen]

Perl 5 IS broken, but not in the way those who want to "fix it" consider it.

The worst of all is the syntax error handling: Forget a semicolor? get smacked with 1000 error messages where 500 keep repeating that some variable "won't stay shared", and the one referring to the actual simple error is neither at the end nor at the beginning, but /somewhere/ in the middle. The only way to find it is to iteratively comment out chunks of code with =pod and =cut.

Talk about exaggeration. I don't think I've ever seen 1 syntax error put out more than about 20 lines of text. I do agree that the line to help you may not be the first one, but the answer isn't commenting out chunks of code until you find it. Find the smallest line number mentioned (let's call it $linenum) and then look on $linenum-1 or $linenum. That's where the issue is 99.9% of the time.

Third, perl always had a lot of toy-language quirks, with syntax which is not orthogonal (why does push $cond ? @array1 : @array2, $item not work?),

My first thought was because you're not clear on the concept of Arrays -v- Lists, but I seem to be wrong because it wo

Re:

[Z00L00K]

Breaking backwards compatibility is bound to cause headache for users of legacy solutions that then no longer works when the new script engine comes out and nobody can figure out why because it was written in some obnoxious way and the developer of that has moved on or passed away.

Re:

[account_deleted]

Comment removed based on user account deletion

Python 2.7

[backslashdot]

Have enough changes to make it look like a simple change in print statements is sufficient when the reality is that there are a bunch of subtle deprecations. Itâ(TM)ll really work out well as it did for python.

Re:

[AuMatar]

Forget Python 3, look at Perl 6- they dropped backwards compatibility, and nobody ever used it. The confusion and long stagnation of Perl caused it go from the most commonly used scripting language to sub COBOL levels of use.

You can deprecate a library. You can't deprecate syntax features. If you feel the need to do that, its time to write a completely new language rather than co-opt an existing one.

Re:

[Megane]

I didn't realize just how out of control the Perl 6 design was until I found this thread. [thedailywtf.com] They went full retard with Unicode characters in the syntax. (Everybody knows you never go full retard!) It makes APL look easy to type, at least they made keyboards specifically for the set of funny characters that APL used. You shouldn't have to have a Unicode code palette open when writing code.

No. ... What's the big deal anyway?

[Qbertino]

Perl 5.x has been around since forever and is doing just fine. I get that they want "Perl 7" because it's a cool number, but the truth of the matter is, Perl is mature and only needs incremental updates, which still trickle in and probably will for another century or so. That's great! Keep it that way!

If you want to build yet another PL, do *not* break syntax, just build another PL.
Better yet join another language team or focus on regex libraries or something because if there's one thing we definitely do *not* need is yet another PL. So please don't.

Perl 5.x is perfect as it is and if you insist, do some additions to the existing project and name it Perl 7 for crisakes, if it makes you happy. But don't break it. Perls popularity is still strong with old school admins, you do *not* want to piss those off and become a footnote of PL history, because they're your only remaining userbase.

Re: No. ... What's the big deal anyway?

[Martin Blank]

Perl used to be the de facto scripting language. Python has taken that place and very few people have any interest in learning Perl because of its reputation as being difficult to write, let alone edit someone else's work. It's still used in some major projects (I think DuckDuckGo still relies heavily on it), but overall, it's fading away with little chance of coming back, mostly getting replaced by Python.

Re:

[drinkypoo]

Perl is easy to write. I submit as proof that I have written perl scripts which did useful work. And it's as easy to maintain as your comments are good.

You're right that Python has gained dominance, but I would still use Perl, especially if I had to process a lot of text... unless I needed some module that was available for Python and not Perl. But so far, Perl has done everything I needed a scripting language to do.

Re:

[master_kaos]

I work at a company worth 20+ mil. All of our backend code is perl. I dont mind it too much, there is definitely quite a few symbols you have to learn and get used to though.

I much prefer writing python or php.

Re:

[Megane]

It's still used in some major projects

I heard there's this one site that uses it, slash-something...

How about a programmatically executable upgrade

[davecb]

Define a language, let's call it Oyster, that has semantics that can be satisfied by perl expressions, then mechanically translate between the languages. It could look like anything you like, including (funcname arg arg), but the operations in the runtime are a proper superset of perl. Done? OK, now rename it to perl N (;-))

Re:

[WhoBeDaPlaya]

Not just sysadmins. I work in EDA (physical design) and use Perl almost everyday (my colleagues do as well though indirectly via the various EDA flows that I wrote)
Learned it in middle school, and haven't stopped using it since.

Re:No. ... What's the big deal anyway?

[gweihir]

Some people apparently cannot let a thing that works well alone. Hence they try to "make it better" and all they do is create a big mess. Perl 5 is not broken, stop trying to fix it.

Re:

[bill_mcgonigle]

> Perl 5.x is perfect as it is and if you insist, do some additions to the existing project and name it Perl 7 for crisakes, if it makes you happy.

Nobody is taking your Perl 5 away for a while.

I learned on Perl 4 and updated my code. The world didn't end. I just got rid of an indirect reference a few days ago.

Frankly %hash{'sub'){'thing'} was better syntax, but oh well.

There are things in advanced Perl that still suck and require underlying knowledge of the object system to get the syntax right. I see

It will break something but what?

[thogard]

Perl 7 will be mostly backward compatible in all cases. The question is how much stuff will it break? There are some constructs that need to go away because they introduce parsing ambiguities and it can be argued that they are already broken. Some of those break if newer concepts about the OOD system are to be introduced. An example of this is the bare word file handles and which cause a bunch of parsing grief but go all the way back to Perl 1.

Re:

[misnohmer]

What does "mostly backwards compatible in all cases" mean? Sounds like an oxymoron to me. "mostly compatible " == "not always compatible". So "not always compatible in all cases", which just means "not compatible" as far as running large legacy code base. It doesn't matter even if there is a clear bug in Perl 5, but fixing it breaks existing scripts. What's easier, go through thousands of lines of code to port to a new language, or just keep using the old language? New stuff will continue to get written fo

Re:

[thogard]

A vast amount of perl code lines will be backwards compatible. 99% of all existing code lines will work in perl 7. The problem is that 1% that won't come from the oldest parts of perl and those parts must change for the language to progress. Part of that 1% includes stuff like while() but best practice has been to write that as while() for a long time now. There are other issues of bare word names that allowed shell scripts to migrate into perl scripts with little work and some of that needs to go away

Re:

[AleRunner]

As a hint, if it hasn't been giving an obligatory warning for at least two language versions you must not break it. No -w flag - preferably a warning you can't hide, but maybe one that can be hidden with an explicit --dont-warn-about-wierd-variables-just-now-I-really-promise-I know-I-have-to-fix-them-now flag.

The perl community has become small and dated. This is not the moment to break it into two incompatible groups (perl5 and perl7). Code from perl5 just needs to come over and work. Any non-backwar

Fork it all

[bobstreo]

Why not just toss in a GUI that generates large BLOBS without doing actual coding, creating synergy and a blazing new path to future non-supported obsolescence?

Has PERL gone the way of COBOL already? As a legacy support language?

Aren't all the cool kids coding in Rust or Go or Java or C* nowadays?

Re:

[Samantha Wright]

Would you be shocked if I told you the media has only just very recently reinvented this concept [bbc.com] as though it had never been tried before?

Re:

[tmmagee]

HTML and CSS could be defined as a large blobs of text that do no coding (although I acknowledge CSS is borderline there) and they are what made perl what it is today (at least HTML is).

If perl 7 is not compatible with perl 5

[93 Escort Wagon]

Then I don't see the point in perl 7.

Re:

[Dorianny]

The point of it would be that we would have modern language unconstrained by old baggage but a much quicker learning curve (when coming from perl 5) due to it keeping the with the design and methodology whenever possible.

Re:

[Waffle Iron]

They'd need to be very careful going that route, since that's exactly the same reasoning that drove the development of Python 3. We all know how smoothly that transition went.

Re:

[93 Escort Wagon]

The point of it would be that we would have modern language unconstrained by old baggage but a much quicker learning curve (when coming from perl 5) due to it keeping the with the design and methodology whenever possible.

To me, that sounds like a recipe for repeating perl 6. Which is great, it you don't want anyone using your language.

Re:

[gweihir]

To me, that sounds like a recipe for repeating perl 6. Which is great, it you don't want anyone using your language.

Delayed second system effect all over with Perl 6. And then they apparently do not learn from their mistake and are now trying to make it again.

Can we make it python compatible

[140Mandak262Jamuna]

eom

Re:

[iggymanz]

python 2.7 or 3.x?

My employer's code base is 2.7 and that will be supported in the major distros for a loooong time.

Re:

[BobC]

The key here is the Py3 breakage decision was made with a long commitment to 2.7, which gave 3 the time it needed to mature with minimal industrial pressure. And also to evolve the tools to simplify 2.7 conversion.

But as the process proceeded, I often found myself wondering: "You created breakage and kept the GIL? WHYYYYYYYY??!"

hahaha, the failure of Perl

[iggymanz]

20 years for Perl 6 to come out, while Larry threw in everything that caught his fancy including the kitchen sink. That language from Mars was a flop, so it was retroactively named to something else, but it was Perl 6. Now that they've lost mindshare after that two decade circle jerk they claimed they'd make a language to be the natural backwards compatible successor, Perl 7. But now they're going to go off on the path of madness again, and make yet another irrelevant curiosity that will be used by no one.

Re:

[Dorianny]

perl 6 was designed with "response 1." Lets just change things to work this way instead of the old way for no particular reason than that's the way I want it. If I understand "response 3" correctly, old behavior will only be changed if there are very good reasons to do so.

Re:

[gweihir]

Indeed. Second system effect, complete failure, and they seem to have learned nothing from that disaster.

Ask the users?

[slipped_bit]

How about they just ask the two users what the would prefer?

Perl 7?

[NateFromMich]

I'm waiting for Perl 8, personally.

Sure...

[feepness]

It's just as readable in that direction.

Stick a fork in it

[magzteel]

I loved Perl but it's done, a victim of stagnation after the Perl 6 debacle.

I haven't done any serious Perl in years and it's unlikely I ever will again. Just considering it makes people roll their eyes.

Re:

[93 Escort Wagon]

Good job - if everyone follows your lead, we'll never get proper UTF support on Slashdot!

Re:

[cas2000]

perl has had unicode support (including utf8 & utf16) for over 17 years now - native (i.e. built-in) since 5.6 in 2003 (greatly improved with the release of perl 5.8 in 2008), and via modules like Unicode::String long before either of those.

don't blame the language for what the programmers fail to use. or, more likely, for what management doesn't give a shit about or want to spend money/developer time on.

if they cared, they could have implemented unicode support in a few weeks....over 10 years ago.

Even

Re:

[Megane]

slashdot.jp (now srad.jp) has had Unicode support for a long time. The main two problems in main-line Slashdot are:
1: wanting to white-list character ranges because people will post art (hint: they already do with regular ASCII) to the point of even blocking most named HTML character entities, then white-listing almost nothing, and
2: apparently advertising the wrong encoding for the web page, causing the wrong encoding to be returned in the POST, or interpreting it as the wrong encoding, and then it becom

A Clean Destination

[crahman]

Perl started as a combination and extension of sh and awk. It was amazing and innovative, as all of Larry's projects were. I ported perl 1 to the PDP-11, and I loved it. Things that were hard to do became enjoyable. Most of you have no idea what things were like before perl.

But as the years went by one kludge was pasted atop another. The language became unwieldy with horrible quantities of 'magic' incantations. It went from a wonderful extension of the Bourne shell to something dreadful. The endless extensions added vital functionality but made the language ugly and strange. It became a horrible mess.

Larry used to wonder what would become of it, hoping of course that his child would prosper. Well it did, but now it's decrepit.

What would be good? Well, keeping the important elements learned after many years of development but creating something new, designed with all that knowledge and experience. This new thing would most certainly not be backwards compatible. Perhaps it would be like Python but without invisible things only the computer can see to parse. This was probably a reaction to Perl's awful and noisy excesses of '$' and "::' and so forth.

I still love perl for generating reports and for small projects. I would not use it again for something large; there are better options.

Perhaps the time has not yet come for this new language. Perhaps perl 7 should be more about discovering what should come next than cranking out code. Perl really was about discovering what should come next all along. Thank you, Larry (and all the rest of you).

What specifically will be broken?

[zkiwi34]

Thatâ(TM)s the key.

Do #3, but better

[ufgrat]

My vote is for sane backwards compatibility, with options.

By default, "/usr/bin/perl" should be Perl 5 compatible.

That doesn't mean code can't contain a "options perl7" or equivalent that enables new features.

That means it's up to the code author to use perl5 or perl7 constructs, and if you pass a perl7 program to an actual perl5 interpreter, it should halt with "Sorry, this code uses unsupported features".

One of the reasons I still prefer Perl over python, is all of my systems can handle perl5 scripts. So

Why not both?

[scrib]

Make `compatible_with_perl_5_33_0` a config option or better yet make it something you can apply per file with `use perl5ish` or `use perl7ish`.
That way Perl can continue to be all things to all people.
And continue to be utterly awful.

I've been a profession programmer for more than 25 years and last year got an otherwise great job working to maintain and migrate an old Perl project. I'll sum up my experience with the following phrase:
The more I learn about Perl, the less I know about good coding practices.

YES / Both like before

[bussdriver]

turning on some features including ones that have some breakage has been done before in perl with "use" statements at the top of the file.

The minimum extreme can be to simply EMBED a separate perl5 as overhead within perl7 and maintain a strong bridge between the two with "use perl5.08" as the mode flipper. So legacy modules almost entirely work without change.

perl1-4 eventually were migrated to perl5. similar would happen but the few things that didn't could still function.

A solid scheme for handling bre

Just give up

[DrXym]

If backwards compatibility is so important then just keep Perl 5 going, even just for maintenance. Because it should be obvious from the reaction that Perl 6 (Raku) got that interest in the language is mainly for legacy uses.

Not backwards compat, DEFAULT backward compat.

[holophrastic]

Welcome to Perl. This conversation is completely irrelevant to anyone from any other language, for the simple reason that it SOUNDS like their talking about removing backwards compatibility. They are not doing anything of the sort.

They are talking about removing backwards compatibility BY DEFAULT.

Currently, a very old-school (~30 years) perl programmer starts with an empty file.

Currently, a reasonably old-school (~20 years) perl programmer starts with a file of ~5 lines. Things like "make me declare vari

Re:

[GreyishBeard]

This can be solved with a single character:
#!/usr/bin/perl
is Perl 5 compatibility mode.
#!/usr/bin/perl7
is Perl 7 mode.
... or perhaps this is not simple enough...

Re:

[holophrastic]

That requires having two different versions of perl installed on the same system. That's one way. But it's not the best way. Much simpler:

use v5.24.1;

https://perldoc.perl.org/funct... [perl.org]

Re:

[holophrastic]

That's actually kind of pretty. Non-obvious to someone stepping into your system, but really very pretty indeed.

Have old Perl apps been abandoned?

[QuietLagoon]

If so, then breaking compatibility will be the death knell for those apps. However, if the Perl application development community is still vibrant, then bring on the incompatibilities and let the community keep up with progress. My guess is that Perl is looked at mostly in the rear-view mirror nowadays, so it should really just be Perl5 going forward in maintenance mode.

Python 2/3

[aralin]

Maybe we should learn the lesson from the Python 2/3 fiasco. Perl is when it comes to features and the language capabilities still much ahead of both Python and Rails. The main problem that I see is not in the language, but in its use. Namely the way coding standard you can see at CPAN and in most example perl code, with heavy use of "use" statements and pre-compilation of most code in BEGIN blocks and the chaos created by importing way too many methods and constants into the main:: namespace. Well written

Re:

[Joey Vegetables]

My opinion, as one who is admittedly not an expert and doesn't have huge systems using Python; I use it for scripting of up to moderate complexity:

We were warned that Python3 would not be backwardly compatible; we were given tools to manage and assist with the migration; we were given YEARS after deprecating Python2 before it stopped being officially supported.

Some part of the Python ecosystem held out and didn't update to 3, even though they had years of warning that v2 would eventually stop being supporte

Re:

[aralin]

Well, that is sort of the thing. It did not cause any inconvenience for those working on small to moderate projects.

I am an SRE at Cisco and I previously worked at Oracle and other companies, always supporting the development process for up to about 20k developers. So many things still depend on Python 2.7, you would be absolutely floored to see that. Python 3 is just now starting to break into the conscience of those organizations. Just starting. You have to understand that everything is running on at lea

Re:

[Joey Vegetables]

My sympathies. I do work on some software that old, but it's not Python. Most of it is C, C++, and C#.

Should Perl 7 Be

[Zappy]

Should Perl 7 Be.

Or should it have been put out of its misery somewhere around version 3~4.

Re:

[Anonymous Coward]

Their ego is bruised because their userbase is shrinking. Perl 6 already tried to be a fresher language without backwards compatibility and where is it? Nowhere that's where. Nineteen fuckin' years of wasted effort.

Most of Perl 6 in now in Perl 5, like Fedora and R

[raymorris]

Most of what was first introduced in Perl 6 is now in Perl 5.
Whatever was widely agreed to be "good", someone added it to 5. From the beginning Perl 6 wasn't about getting a new version out at a particular time, it was about thinking about and trying new ideas.

Re:

[Required Snark]

perl--

Re:

[93 Escort Wagon]

Which will soon after be followed by Microsoft Perl# .

Re:

[misnohmer]

C++ is backwards compatible with C. If Perl 7 was in fact Perl++, we would not be having this conversation. The problem at hand is that it's more like Perl# (analogous to C#) - looks like the non # language, but not 100% compatible.