Clutching at its Perl 6, developer community ponders language name with less baggage

Earlier this month, Elizabeth Mattijsen, a Dutch software developer and contributor to the open-source Perl programming language, opened an issue in the GitHub Perl 6 repository seeking to rename the project because having "Perl" in the name is "confusing and irritating." To understand why that's so, it's necessary to know a …

[Psmo]

Re: add a proper string type in C

"Only char arrays."

...which is JUST FINE and MORE FLEXIBLE...

...mastering strings in C/C++ is *SIMPLE*. I've been doing it for YEARS. DECADES even. More than TWO decades.

Sooo...I take it that this (written in 2003) passed you by?

The last century called, they want their encoding and overflow bugs back.

(€Éôû - bravo ElReg)

[Doctor Syntax]

Re: "Want a simple, efficient and elegant programming language? C"

"in *nix world useless complexity is what people like"

Maybe, but here in the Unix world we like simplicity. Guess what we think of systemd.

[Anonymous Coward]

"but here in the Unix world we like simplicity"

Sure, for the Unix meaning of "simplicity" - which often is very different from the general meaning.

The hate for systemd is an evidence of it. It may be badly implemented, but the previous system was really old, ugly, brittle and cumbersome.

Did it work? Sure, as a lot of old. ugly, cumbersome and brittle software (with a lot of care) but it didn't mean it didn't need an update just because "traditionally we always did it that way" - and there result was that I've see not a few Linux developers unable to run a daemon properly.

Just like C string management. It puts today a huge burned on the developer uselessly. A lot of that can be easily moved to the compiler, and avoid a lot of issues, bugs and vulnerabilities - from which we suffer every day.

But "Hey no! We always did that way" - just it was done that way when most software wasn't interactive and didn't process a lot of strings.

World changes, and smart people and software adapt and improve. Others try to keep people tied in a past they believe was a "golden age". especially to ensure they don't need to learn anything new and change the way they work.

[ibmalone]

Re: "but here in the Unix world we like simplicity"

Did it work? Sure, as a lot of old. ugly, cumbersome and brittle software (with a lot of care) but it didn't mean it didn't need an update just because "traditionally we always did it that way" - and there result was that I've see not a few Linux developers unable to run a daemon properly.

That's a good argument for replacing or updating init. It's not a good argument for what systemd has become. https://www.theregister.co.uk/2019/01/10/systemd_bugs_qualys/ https://moss.sh/name-resolution-issue-systemd-resolved/ badly reinventing or reimplementing systems that work because it's easier than trying to interface with them is not a good long term plan.

[DCFusor]

Re: "but here in the Unix world we like simplicity"

Here's an oldie but goodie on systemd. Someone else shared this in a forum, and got excoriated for its age. And replied with "and in all this time, not one issue it raises - and no one disagrees with those - has been fixed". Good read, on a par with "PHP, a fractal of bad design".

I haven't seen a perl me-too language yet that's as good, sorry.

https://ewontfix.com/14/

Pretty definitive description of truly fundamental design flaws in systemd - ones that amount to cheats to make life easier for the writer temporarily by breaking all the rules in a power grab. Just read it.

[AdamWill]

Re: "but here in the Unix world we like simplicity"

All the points in that post are really the same point - "it's a complex process that runs as PID 1". And of course you can't 'fix' that with systemd because that's what systemd is. If you 'fixed' that it would be something else instead.

[ibmalone]

Re: "but here in the Unix world we like simplicity"

What it needs is a Node.JS implementation.

[ibmalone]

Re: "but here in the Unix world we like simplicity"

Good read, on a par with "PHP, a fractal of bad design".

I don't think anything is on par with that. Whenever I'm reminded of its existence I re-read it just for entertainment.

"And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door."

and

"Even JavaScript doesn’t do this."

[jake]

Re: "but here in the Unix world we like simplicity"

""result was that I've see not a few Linux developers unable to run a daemon properly."

"That's a good argument for replacing or updating init.""

No. That's a good argument for replacing your Linux developers.

[ibmalone]

Re: "but here in the Unix world we like simplicity"

Maybe I should have cropped that sentence. It's the 'brittle' bit I was thinking of. It's definitely possible to imagine classic init could be improved. Systemd even did that in some ways. And then it became grey goo.

[bombastic bob]

Re: "but here in the Unix world we like simplicity"

@AC - I don't know which parts to quote to give an example why I give you a ZILLION DOWNVOTES but full-quoting the entire post is kinda dumb.

So "everything in that post of yours" - a big fat THUMBS DOWN

You obviously DO NOT USE the things you appear to act like "an expert" on. I bet your C coding skills are 101-level at best.

[jake]

Re: "but here in the Unix world we like simplicity"

"It may be badly implemented, but the previous system was really old, ugly, brittle and cumbersome."

Old? Not really. I'm older than init and I'm not old. Or am I? Hmmm ...

Ugly? Not at all! Quite elegant, in fact. (Insert "eye of the beholder" stuff here.)

Brittle? Hardly. Its as robust as the administrator makes it.

Cumbersome? Not even close. It's actually quite nimble ... But then when I ice-dance with my Wife, I wear my hockey skates ... maybe I'm seeing it from an orthogonal point of view :-)

[Anonymous Coward]

@AC - Re: "Want a simple, efficient and elegant programming language? C"

Simple, if you don't know Unix just stay away from it. It's not such thing as complexity in Unix, it's either you get it or not.

[Dave Bell]

Re: @AC - "Want a simple, efficient and elegant programming language? C"

I use Linux, and it can be as good a desktoip OS as any other. But Linux still has different desk top implementations that are different enough to be awkward. An analogy: we have a standard user interface for the motor car, things like foot pedals and steering wheel. But writing a program for Linux is like refuelling a motor car. You have to care about how the engine works.

[Charlie Clark]

Re: Why exactly is Perl any worse than Python?

Languages are not all me too. They're generally written as a response to different problems.

There are lots of good comparisons of the two languages, highlighting the pros and cons of each, but at the end of the day it largely comes down to personal preference but C definitely isn't the answer for everyone's problems. While at the silicon level computers haven't changed, at the user level they have. For decades now we've had people needing to program as part of their day job and they simply don't have the education or aptitude to be able to use something like C correctly. But that doesn't mean that they can't write perfectly reasonable code in something else that internally relies on C.

[Anonymous Coward]

@Charlie Clark - Re: Why exactly is Perl any worse than Python?

Bingo! That's it, people who don't have the education or aptitude should stay away from coding. You know, I'd like very much to fly a Boeing-777 and I know that the auto-pilot can do all the job for me, still you wouldn't board a plane knowing I'm in the captain seat.

[Michael Wojcik]

Re: @Charlie Clark - Why exactly is Perl any worse than Python?

still you wouldn't board a plane knowing I'm in the captain seat

How would we know? You're anonymous.

Man, as if commercial air travel weren't bad enough already...

[Glen 1]

Re: @Charlie Clark - Why exactly is Perl any worse than Python?

"You know, I'd like very much to fly a Boeing-777 and I know that the auto-pilot can do all the job for me"

Can you name a modern jetliner that doesn't use fly-by-wire? All those assists and features that let you get on with flying the damn plane?

Compare to something like writing a web scraper in python, or even a simple 2d game engine. If it solves the business problem (flies the plane), then why would I pay someone to juggle memory addresses?

I'm paying someone to solve a problem, not to give themself a blowjob over how smart they are - that's how LISP happened.

Sure there are times when you *want* to juggle memory addresses, but a regular CRUD app? Nah. If there are performance issues somewhere down the road, there are several layers of abstraction to peel back before I start looking at (for example) C SELECT calls. Thats commonly called "premature optimisation" is is frowned upon by those with a clue.

[Trixr]

Re: @Charlie Clark - Why exactly is Perl any worse than Python?

The more accurate analogy is that some of us just need to drive, while others of us know how to build a car engine as well. I'd rather rely on engineers to do the latter while making sure the engine is efficient and safe and is capable of getting us from a to b. On top of that, we have an easy-to-understand interface to allow us to actually drive and get ourselves where we need to go.

Frankly, writing a simple web page or a script to grab a list of users out of Active Directory/LDAP by criteria shouldn't require ops people like me (the mechanics in this scenario - we fix the crap that people use and sometimes perform upgrades or add features) to spend years of studying programming to perform a relatively simple task. Tasks that actual devs would be bored to tears doing. And in the case of systems operations, they are often not great with the application stack as it gets used either - a engineer isn't necessarily a good driver. The amount of devs who apparently have never heard of an LDAP filter or how construct an efficient search query never fails to grind my gears.

For your financial system or air traffic control system, sure, you want to design a bespoke engine with custom components and capabilities tuned to specific requirements and the underlying environment.

[Glen 1]

Re: @Charlie Clark - Why exactly is Perl any worse than Python?

RE: Search queries

That comes from Googling a one liner to do what we want, without looking at the caveats.

Sometimes those caveats are not well documented, sometimes the call is an abstraction outside our expertise, sometimes the dev is just a bad dev.

I've never had to call LDAP before (or AD for that matter), so my search queries would probably suck. For the sake of our fellow commentards, how would I "construct an efficient search query"?

[MarkMLl]

Re: Why exactly is Perl any worse than Python?

> For decades now we've had people needing to program as part of their day job and they simply don't have the education or aptitude to be able to use something like C correctly. But that doesn't mean that they can't write perfectly reasonable code in something else that internally relies on C.

It also doesn't mean that their preference for Python or Javascript should carry as much weight as the opinion of somebody who through long experience and study knows what he's doing.

[disgruntled yank]

Re: Why exactly is Perl any worse than Python? : About efficiency.

C is efficient as far as the machine is concerned. As far as the developer's time, though?

Back in the early 1990s I had a look at Perl 4, and discovered that, no, I did not have to fool with flex and bison to handle regular expressions--I could write

if (/whate+ver, du+de/)

And I could use "unpack" to parse funky minicomputer logfiles--could I have done it in C? Eventually? Would it have been faster? Sure. But parsing the logfiles with Perl on a SparcStation was vastly faster than using the vendor's log-reading program on the mini.

[Anonymous Coward]

Re: Why exactly is Perl any worse than Python? : About efficiency.

> [ ... ] could I have done it in C? Eventually?

%> man strtok

Unless you're writing a compiler from scratch, you don't need flex/bison to parse log files.

Beware the misleading friendliness of Perl regexp. Might not always do what you thought it would.

In one of my previous jobs I was a "mentor" for one of our summer interns. I made him learn flex and bison (O'Reilly book) because we had to parse some relatively unstructured text files. He didn't know flex/bison.

He learned flex/bison in 3 days and in another 5 he had the parser written, done, debugged, tested and checked with the static analyzer.

And this was a Junior year undergrad intern.

[bombastic bob]

Re: Why exactly is Perl any worse than Python? : About efficiency.

Unless you're writing a compiler from scratch, you don't need flex/bison to parse log files.

agreed. But I wouldn't use those libs for a compiler either. Bloatware. unnecessary.

parsing text files with a pair of pointers is easy. Typically I'll write a function like this:

char *p1 = the_buffer;

char *p2;

while(*p1)

{

while(*p1 && *p1 <= ' ') p1++; // ltrim

p2 = p1;

while(*p1 > ' ') p1++; // end of term

// pass p1 and p2 to a function that copies or compares

// if((p1 - p2)==5 && !strncmp(p2, "thing", 5)) <-- string 'thing' is first term

etc.

not hard. look for '\n' to terminate a line. in fact, simple. pretty bullet proof, too. You're welcome. I do this a LOT.

you can also use scanf if you only want simple parsing.

if you need something more complex, you can parse columns and/or quoted strings pretty easily. I've even witten a full blown XML parser. It could fit on a microcontroller if it had to. I've seen similar kinds of simple parsers used for JSON [not written by me] so there are others out there doing this sort of thing. The fact is that string parsing is NOT hard, there are basic techniques you can use (like what I did above, the 2 pointer method), and you can use standard libc functions and pointers to parse just about ANYTHING that's text. Switch to mbcs functions if you need that for UTF8, no big deal.

no need for bloatware, OR Python. Or special Perl modules, either.

''awk' does a good job too.

[BinkyTheMagicPaperclip]

Re: Why exactly is Perl any worse than Python? : About efficiency.

For log files and regular expressions, I'd rather use awk. It's also installed on practically every Unix system (although admittedly it's not always the considerably more useful GNU awk)

[bombastic bob]

Re: Why exactly is Perl any worse than Python? : About efficiency.

"C is efficient as far as the machine is concerned. As far as the developer's time, though?"

most of th3e time I can crank out C code faster than Python or Perl. I am admittedly not that good at Perl.

For those things that can be done with a shell script, though, I normally do "that". And I've been known to write my own quicky utilities for that shell script to invoke, for special case things that aren't already part of the operating system.

So "the developer's time", at least if it's ME, isn't hampered by using C. In fact, on my resume I *BRAG* about being faster than most people and getting things DONE. And I do. And I use 'C' most of the time.

[Charlie Clark]

Re: Why exactly is Perl any worse than Python? : About efficiency.

Actually lots of parsers written in Python or Perl are as fast as those written in C, because they're largely wrapping C libraries. And this is one of the points of these languages: they're encouraging you not to reinvent the wheel. Yes, there will be times when you reach for a library and it turns out to be a dog so you do need to write your own code, but that will generally be the exception that proves the rule.

Of course, parsing gets harder and slower if you have to deal with unicode…

[AdamWill]

Re: Why exactly is Perl any worse than Python?

Well, one obvious one right off the top of my head: the way in perl you can assign a variable to an object or a reference to an object, and you deal with them in different ways. Dealing with references is syntactically ickier, but you have to use references in all sorts of cases, so you're forever creating and then dereferencing the damn things. In Python, they're just *always* references, but you really don't have to worry about it. A corollary of this is that in perl you can have a subroutine called tags which puts a string called $tags in an array called @tags in a hash called %tags and they're *all different bloody things*. (yes, this is an almost-real example, exaggerated only slightly for effect...)

perl also has more immediately-obvious weirdness to it than python, stuff you will rapidly run into as soon as you start trying to work with existing perl, like the whole $_ thing.

I hate perl a lot less than many people, and way less than I hate PHP (how does that not top all of these lists?!) but I would say it's definitely somewhat more of a pain to work with than python overall in most ways.

[DCFusor]

Re: Why exactly is Perl any worse than Python?

Because you can really confuse people with "use Inline::Python" or several other languages, actually.

Talk about making porting and re-using code written by kidz in the new fad language easy!

Only thing is, the beginners who use python for drivers on devices on the raspberry pi often just use a micro-sleep because, being beginners, they don't realize there's a ready bit to be checked. Since perl precompiles inline code - it runs faster under perl than natively and often that abortion of a design then fails and you wind up fixing it anyway.

[Tomato42]

Re: Why exactly is Perl any worse than Python?

C stops being simple or elegant as soon as you need to actually do error checking

and don't tell me that you are checking in your code if printf() succeeds

[Sam Adams the Dog]

La Dame aux Camelias

I guess that makes Elizabeth "La Dame aux Camelias"....

[Warm Braw]

Re: La Dame aux Camelias

It would also imply a programming language that stops working at certain times of the month.

Which does seem to be a natural trait of software.

[Flywheel]

Re: La Dame aux Camelias

Bank holidays usually, or if the code author travels more than 200 miles away from the application.

[Anonymous Coward]

@Warm Braw - Re: La Dame aux Camelias

Please remain within the scope of this discussion.

[Warm Braw]

Re: @Warm Braw - La Dame aux Camelias

The entire narrative premise of La Dame aux Camelias is that a prostitute downs tools, as it were, once a month and signals her temporary unavailability by means of coloured flowers.

My assumption is that the original poster didn't realise how infelicitous it might be to liken a respected IT pioneer in the Netherlands to the character of Marguerite Gautier, which is why I didn't exercise a knee-jerk down-vote, but having brought it up as a subject, it's hardly then out of scope to refer to the precise plot in the context of an inanimate object.

If you object to the subject matter of the original literary work, then take it up with Dumas fils.

[Kubla Cant]

Re: La Dame aux Camelias

It just occurred to me that the butterfly is called Camelia because the original Perl book had a camel on the cover.

[Claptrap314]

RTFM?

"Having two programming languages that are sufficiently different to not be source compatible, but only differ in what many perceive to be a version number, is hurting the image of both Perl 5 and Perl 6 in the world," she wrote. "Since the word 'Perl' is still perceived as 'Perl 5' in the world, it only seems fair that 'Perl 6' changes its name."

1) https://semver.org/

2) The EXACT same thing could have been said about the Perl 4 -> Perl 5 transition, which, incidentally, was before semver was something that had to be explained.

3) People saw the periodic table of operators about fifteen years ago, and said, "Nope. Nope. Nope." No one ever expected Perl 6 to run Perl 5 code. There was some initial hope for sanity, but nope, nope nope.

[Jove]

Re: RTFM?

Not really.

The Perl5 community have supported the renaming of Perl6 so that progress can be made with the true Perl6 (well perhaps Perl7) and end the current constraints limiting changes to Perl5 to being just point releases.

Regarding the reputation of Perl; a lot of the damage was caused by the community itself over the farce with the delivery of Perl6. That did not contribute much to businesses perceptions of the language and caused the loss of a lot of support.

[Nick Kew]

Re: RTFM?

Perl4 is a historic footnote. It was only with Perl5 and CPAN (and the rise of the Web) that it attained a Big Community and Ecosystem, and maintainability became an issue.

When I first hacked Perl, both 4 and 5 existed in parallel depending on what system you were using. At the level of a quick&dirty hack (erm, I expect that'll be pretty-much any pre-CPAN perl) the differences are immaterial.

[Anonymous Coward]

Re: RTFM?

The EXACT same thing could have been said about the Perl 4 -> Perl 5 transition ...

Except it could not have been: Perl 5 did run the vast majority of Perl 4 code with a few minor tweaks. It was also possible to ignore most the new additions and features if you didn't need or want them, and to contunue using Perl 5 as a somewhat bloated Perl 4 - which is exactly that I do to this day.

For many messy but in principle simple tasks, the Pathetically Eclectic Rubbish Lister was already the perfect tool in 1994. It still is.

[Anonymous Coward]

The COW says.....

## Many perls, eek!

[bombastic bob]

Re: The COW says.....

it's Perl, so CAMEL

[Daniel von Asmuth]

Re: The COW says.....

Camel sounds too much like CAML; dromedary is still available.

https://en.wikipedia.org/wiki/Caml

[Anonymous Coward]

Idiosyncratic choice

I picked up Perl and Javascript at about the same time back mid 90's. One had style, literacy, and élan. The other was much more constricted and immature. Both were unsuited for many people. But was that a problem with the languages? Apparently not, as 'everyone' who embraced the client end of the web decided Javascript was okay enough after all. Sorry, Java.

Please do remember we've seen exactly the same zeal in the past attacking Javascript as for Perl. So somehow the never-JS people got over their jihad in order to get work done anyway.

I've done Python too, though having to read it quite a bit more than write in it. (You know, bug fixing) I keep thinking on one strange comparison between English and French. One has 170,000 words, the other 60,000. Simpler having less choice, yes? Oh, and the orthography and pronunciation is more straightforward in French (except when it isn't).

It really comes down to a personal, idiosyncratic choice. Some people want a language anemic and hypoglycemic to mutter in. Others a language that can be poetical. It is at all remarkable that there are very loud people who hate poetry? Or English?

Oh well, waiting to see what is next becomes the "most hated". Oh dear, I'm programming in Javascript! Noooo

[Jove]

Re: Idiosyncratic choice

TLTR: Please just post a link to your blog, then we can all ignore it.

[Flywheel]

Re: Idiosyncratic choice

Oh well, waiting to see what is next becomes the "most hated"

Hmmm.. probably node.js ?

[jake]

Why would anybody argue?

The thing currently known as perl6 quite clearly isn't the programming language known far and wide as perl ... it should have had its own name right from the git-go.

[Jove]

Re: Why would anybody argue?

... unfortunately the community has been arguing the topic for years, and may continue to do so because of those amongst the Perl6 supports that seem to want to impose it on the Perl5 supporters.

[JoeySter]

Re: Why would anybody argue?

The choice is obvious... s/Perl//