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 …
Like the vicious foaming-at-the-mouth hatred of OO programming that suddenly seems to be filling my tech news feeds? I mean, sure let’s discuss shortcomings and failed promises of OO, but some of those seem to rank OO somewhere worse than genocide and child abuse and kicking puppies combined.
I thought Perl was just a wrapper to add functionality to regex, because you can't quite write a program just with a regex.
I'd not realised that Perl6 wasn't just a later version of Perl5. I've written one Perl program and I'd no idea what version. So I checked:
perl -v
This is perl 5, version 22, subversion 1 (v5.22.1) built for x86_64-linux-gnu-thread-multi
(with 73 registered patches, see perl -V for more detail)
Copyright 1987-2015, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
So the only issue is a new name for Perl6?
you can't quite write a program just with a regex
You can with the "extended regex" language popularized by Perl; it's Turing-complete.
(Real regular expressions are, of course, of the same formal power as deterministic finite automata and transition graphs. Whether a DFA constitutes a program depends on your definition of "program".)
I'm a big fan of and user of perl, because it lets me write code so clearly that people who see it ask what fancy mods I've made to their language of choice to make things so obvious. Enough rope to shoot yourself in the foot is a double-edged sword, and what people are really complaining about with perl is that some people think writing "line noise" code is job security for the sinecure-minded losers of the world, of which there are all too many.
But not everyone - I DO maintain and support my own code, which generally has more comments than code in the source, with the "why I did it this way" along with the "how". Because I forget and that's not language dependent at all - my arduino C/C++ looks very similar. And when I had coders working for me (in any language) if they didn't do the same, they got a talking to or terminated. And for some reason our consulting firm became so popular that when we all retired, the oldest of us was 45.
Because customers will pay for quality and the ability to modify quickly to suit, or at least we found a few that would.
=for smartpeople
That said, this new language currently known as perl 6 should no way be named perl, that's idiotic. It's really not even close to the same language - I've looked, I've paid attention for example to Damian etc - I'd go with his suggestion if for no other reason than he's generally the smartest guy in the room.
=cut
Perl and Javascript have that in common -- they're both expressive languages in which it's possible to write very clearly structured code, but they get a lot of hate because they don't *force* you to.
Perl in particular was designed for a wide variety of use cases, with a big one being short, simple programs for data transformation. When you're writing a one-liner you don't want a lot of syntactic sugar in the way. There *are* language constructs that were clearly a bad idea (the default argument comes to mind), but they're not mandatory.
As for the name...Perl++? ;)
I like the & for reasons perl programmers will know...Although some of the indirection syntax HAS improved with later versions.
To the poster one up - ask Larry - perl was written - and became the p in lamp stack for a long time - because it's the best duct tape there is out there. Using it for larger programs is tempting, and I've been tempted...and failed to resist, but that's getting outside the main intended use cases...it's a lot more useful than sed and awk as duct tape, and I even have it as fastcgis on raspberry pi servers around here.
As to javascript, it's (in my rarely humble opinion) mostly grown because what else got into all the browsers? It was like a weekend project, with design flaws to match. Uses beyond that I've seen seem terribly wasteful, and maybe we'll get some relief from JS in browsers...
There's a rather interesting interview out there with Guido and Larry that shows philosophy. Guido insists his way is best (maybe, for some things) and lays out the roads and rules and all that. Fine.
Larry's response was, well, we just built some of the buildings, and then built the roads after we watched everyone and saw where they walked anyway...
Here you go - this is a raw stream and I set this to skip nearly an hour of advertising and backpatting intro. Might be informative to those interested in language design philosphy and all the big guys (for scripting languages) are there. https://youtu.be/csL8DLXGNlU?t=3060
Guido van Rossum, James Gosling, Larry Wall & Anders Hejlsberg
I'm upvoting for part of the comment, but the remark about use cases? No.
PERL was designed for one use case: turning logfiles into legible reports. Everything else was added to it because people who knew it for that purpose kept trying to use it for other things, rather than learning more appropriate languages.
(How do I know? I'd already been coding nearly twenty years when PERL was created.)
I'm retired, so no danger of me writing production code. I just tinker on my home systems. I write in C or Perl.
For utility scripts, I use Perl because I don't know shell syntax very well. But all my Perl looks like C, so that the structure of the code is obvious. Well, there's one compact and cryptic construction I've used more than once (I got it off the internet) which, with about 12 characters, reads and parses a text file of name-attribute pairs into an associative array.
My working career involved a lot of regexes, so I mostly get them right, but they're a bugger to debug if they don't work as planned.
"That said, this new language currently known as perl 6 should no way be named perl, that's idiotic. It's really not even close to the same language"
I was thinking maybe they could call it SWINE. Super Wide Information Notation Edition. They could cast some Perlisms into the front end.
But Version 10 would clash with the classic Perq computer! https://en.wikipedia.org/wiki/PERQ">https://en.wikipedia.org/wiki/PERQ
So we have families of incompatible programming languages called BASIC, Algol, C++, Java, C#, Perl, Ruby, and Python. What to do about it?
"Pathological Eclectic Rubbish Lister" arouses negative feelings, so you would want to rename it to the much nicer 'Pearl' (like Ruby, it could be a gemstone or a lady's name), rather than 'Prul' (Dutch word), Peril, or Leper.
Perl has been my bread and butter for many years. Obviously I'm not well fed.
Waiting for an improvement in the language/interpreter for 10-20 years has led me to greener pastures where pythons may lurk. But never to those nourished by the redmond beasts.
Inquiring minds want to know.
Because, honestly, both suck. In different ways, though.
Want a simple, efficient and elegant programming language? C.
Perl, Python, Ruby, Rust, Go, etc, two-mile long list of me too! languages. That's deffo not where simplicity and/or elegance are at.
It definitely seems like that to me as well. But programming is indeed an area that seems to attract lots of emotion from lots of people, so I'm not surprised that it is not that easy to change.
I am, however, surprised that the splinter team kept with the same name. I don't understand how they thought it would not be confusing given that they knew from the start that they would be creating something incompatible. I would have wanted a different name from the start.
By taking the Perl 6 moniker, whether intentionally or not the team made it nearly impossible to create a major revision to Perl 5. Instead the "original" Perl has been incrementally building out to the current 5.30.0 version. If the Rakudo/Camilia quit refering to themselves as Perl 6 then perhaps a proper successor to Perl 5 will be developed (Perl 7, Perl X?) and I won't have to explicitly declare features that have been around since Perl 5.10 (can you say "say").
"I am, however, surprised that the splinter team kept with the same name"
It was not their intention to deliver something so different from perl5, but feature creep and a commitment to get it right took the language down a very long path. The intent was to have the community adopt the changes provided by Perl6, but by the time there was product it had become a significant leap.
"Programming languages are just that - tools to get a job done."
That's all very well, but if every screwdriver had to be examined carefully, odd features looked up, and the whole thing rebuilt before someone else could use it, that wouldn't be a very good screwdriver, would it?
So basically, in the context of your previous "why doesn't everybody just use C" comment, it would be difficult not to surmise that this particular hammer is the only item in your toolbox.
Different languages have their strengths and weaknesses and are more or less appropriate for different functions at different project stages, but let me tell you a little story.
Recently, I was at this client site and they were using this C++ programme to crunch some numbers. A programme that had been written by one of the guys over many weeks (during which time he was neglecting his actual job).
This guy left and nobody else had the foggiest idea how the programme worked. The thing wasn't quite finished and the guy had clearly been relying on a very strict set of assumptions for the thing to run at all, with lots of copying and manipulating data files all over across the place. It was a right mess (and of course, no source code).
So I grabbed the nearest computer and wrote a Python replacement, which actually did more and with nearly no assumptions as to how the data was organised, etc., so you pointed it in the general direction of the data and it figured things out. It took me a bit less than two hours.
And I had NEVER used Python before. This was literally my first Python script. I don't know why, I've always disliked Python; but that was the only tool that was readily available on this occasion.
So, if you're one of those who think that "your" programming language is "better" than somebody else's, please know that a bunch of us will think of you as a very unprofessional cretin we wouldn't want to work with.
A bit of a post-scriptum:
Was C++ the right choice for his programme?
No, for a number of reasons. I would say the most important was that he had an actual job to do which wasn't trying to pretend he was a professional developer. That's why the software was never actually finished and never run properly.
Why did he use C++?
From what I've seen and heard, he probably considered it some sort of status thing. Also allowed him to empire-build a little, as none of his colleagues (all non-coders) was going to put that much time into learning (properly) something like C++.
Why an orders of magnitude difference between the time taken to develop his tool (estimate 200-400 work hours, plus whatever else in his own time) versus its replacement?
As I said, he wasn't a professional developer and didn't seem to be aware of things such as libraries / frameworks. So every little bit was hand-coded, from scanning a directory for files, to the graphic routines. Although I haven't seen the code, it is clear that he knew few if any of the "tricks of the trade" (how to structure code, patterns, reference algorithms, testing and validation, etc.)
At the end of the day, pretty much all the thing had to do was going into a bunch of proprietary formatted files and get a bunch of counts for different things. All you needed was a bunch of regular expressions (other pattern matching tools available) and a bit of glue. Bash + regular Unix tools would have done the job if they'd been available in that particular environment.
Perl was really the first attempt at a scripting language (I exclude Bash etc. here) and it was not orthogonal e.g. there are different structures for IF statements which could have been regular without too much effort.
It's just that no one had an example to learn from.
> Perl was really the first attempt at a scripting language
Awk precedes Perl by at least a decade. As in Aho - Weinberger - Kernighan. Bell Labs and UNIX.
Aho as in egrep and fgrep and the Dragon Book. If you don't write compilers for a living you don't need to know what that is. And it's pretty outdated at this point, but it was the go-to reference for compiler implementations for quite a while.
Weinberger as in FORTRAN 77, digital photography and then Google.
Kernighan as in C.
AWK is fundamentally different, in that it was designed to match patterns and insert replacements rather than to perform sequential operations with its own robust flow control. Virtually every "shop" had something like that which it used to do things like systematic modification of source files before they were compiled/assembled: I used something called Stage2 (W.M.Waite) for that sort of job.
And irrespective of whether it really was the first, by the time Perl reached v4 it offered a vast improvement when compared with the alternatives. /Much/ more significant than that offered by Python when compared with Perl etc.
Perl's major problem, leaving aside the perennial tendency of twits to advertise their superiority by writing impenetrable one-liners, was the sigil prefixes. Python's major problem is the significance of tabs and indentation, which can make it virtually unusable as a component of some larger system which emits code fragments. Quite frankly, the World deserves something better.
> AWK is fundamentally different, in that it was designed to match patterns and insert replacements rather than to perform sequential operations with its own robust flow control.
Yes. But for the practical purposes of this discussion (?), the vast majority of Perl use cases is pattern matching and substitution.
> Python's major problem is the significance of tabs and indentation [ ... ]
That. We tried this once with Make. Everyone hated, and still hates, it. But no, Python had to do it again, because once is not enough. And it has nothing to do with helping code readability.
And then there's the Python Global Interpreter Lock (GIL). Yay for scalability.
Python2 - Python3 incompatibility. And then Python 3.5 - Python 3.7 incompatibility. I have to have three different versions of Python in Fedora 29: 2.7, 3.5 and 3.7. Oopsie.
How many versions of GCC and/or LLVM do I have on the same Fedora? Just one.
> Yes. But for the practical purposes of this discussion (?), the vast majority of Perl use cases is pattern matching and substitution.
I'd suggest that that's unfair, and I'd point out that most of the substantial corpus of add-ons in CPAN can't be invoked directly from a search which implies that most developers recognise that Perl- once it had started to move away from its AWK heritage- was something more general.
It certainly has exemplary pattern-handling capabilities for something spawned in the 1990s. So exemplary in fact that most languages developed since are at least as comprehensive in that area.
> > Python's major problem is the significance of tabs and indentation [ ... ]
> That. We tried this once with Make. Everyone hated, and still hates, it. But no, Python had to do it again, because once is not enough. And it has nothing to do with helping code readability.
Actually, we tried it with FORTRAN which required that ordinary statements started in col 7. And in ALGOL and COBOL which might have been more relaxed about start column but in most early implementations still reserved a chunk of each input record for a line number.
"Some [preferred] the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause." -- Rob Pike https://talks.golang.org/2012/splash.article
And finally, for another 2d worth, I'd add that Dijkstra's comment about "coding bums" AIUI echoed John McCarthy's words and sentiment which were originally inspired by a certain type of student who obsessed about shaving an instruction or so off a sequence of operations in the same way that a downhill "ski bum" obsessed about shaving a second off his run.
I'm quite sure that you can write impenetrable code in any language, and would suggest that if a language comes along that prevents you from turning a hard-to-understand algorithm into a difficult-to-follow instruction sequence that there's probably some severe downsides to it. But while I'd certainly agree that some of the things in Perl give sloppy workers much more rope than they deserve, I think that the real problem is managerial: most fields of applied science /require/ adequate documentation and review, and the complexity and pervasiveness of computer software makes that requirement even more important.
Ultimately, saying "this code works even though nobody really understands it" is neither an excuse to allow the situation to continue, nor adequate justification to rip it out and redo from scratch. And selecting Python or Javascript for the sole reason that they're popular with inexperienced users is asking for trouble.
On Slash Dot I was downvoted into oblivion for making the remark, "The best programming language is the one your present client is paying you to use."
In 45 years in the business I've had to use an equal number of distinct languages. Each client had a compelling reason for their choice, within the framework of their own priorities.
So: the best programming language is the one which at present feeds your family. Period.
So don't let inexperienced programmers code your projects in C. Simples.
On the other hand, why stifle the experienced programmer? If a professional deems C to be the language required for a project, let her use C ... And yes, I know, "What about maintenance‽‽" you rightfully ask. My answer is that a Pro wrote it in C, you should probably hire a Pro to maintain it. You wouldn't hire a kid right out of a high school shop class to maintain your Lear Jet, now would you?
Ha, funnily the only bit of paid work I've ever had related to Pearl was to run a training class for some developers on the language. Late in the class I got chatting with them about the project and it turned out they were learning Pearl to allow them to maintain a piece of SW from a developer I knew and who was definitely in the class of programmer who you'd be happy to board the plane if he'd done the control code. I said that I'd have expected that if this guy had written the code then the documentation would also have been extremely good. The reply was "Oh the documentation is superb, it was reading that which made us realised how little we knew, so we thought we'd get you in to train us"
I did for some years, as part of larger jobs, my main thing wasn´t programming perl,
Perl is the language that could, but failed. Python is much much better.
My preference? Something simple, like VB6, but with proper inheritance and support for multithreading and pointers.
I mostly program in Java right now, and while it has way to much boiler plate, it is ok.
Downvotes --> This is the reason it is not on my CV.
People have an instant dislike for VB, hate I would say.. and for its time, it was ok.
Could it be terrible? of course, same as perl, or C/C++, but more amateurs used it than other languages.. so it got terrible publicity.... and it seems it perdures.
Look how much flak I got!
I went from C to mostly VB as it was way faster to develop than Visual C++, then got away from that for business reasons.. but it was OK.
... definitely in the class of programmer who you'd be happy to board the plane if he'd done the control code.
I've worked with some devs who I would be glad to see board a plane for which they had written the control code.
The one with train tickets in the pocket please------->
> I've worked with some devs who I would be glad to see board a plane for which they had written the control code.
A previous employer of mine insisted on doing exactly that: the mechanic who signed off any complex work on one of our aeroplanes was on board on the first post-maintenance flight.
I have to say our mechanics were always *very* thorough!
"You might want to pass that concept on to the likes of Crapita, DXC & IBM"
Is this some sort of matching game?
If a pro writes the code, hire a pro to maintain it.
If a mouth breather writes the code......get them to write it 1000 times and hope you're lucky when you choose the winner?
You got the same situation in aviation. How to you get to have experienced pilots without allowing inexperienced pilots to fly passenger planes ? Answer: selection, training, certification, periodic re-certification. Otherwise it's let's invent a programming language that would allow the most inexperienced programmer to write quality code. This is how/where AI and robots will replace what we use to call code monkeys.
This post has been deleted by its author
"What do the inexperienced programmers code in to become experienced programmers?"
It's not germane to the situation. It's not about their journey, it's about their reaching the destination. Where, exactly, the destination is is in the eye of the beholder. Caveat auditor.
> What do the inexperienced programmers code in to become experienced programmers?
Anything that's available, but not on live projects.
That might be the reason that so many large projects these days run into enormous problems: industry and government isn't prepared to support an infrastructure of dummy runs and experiments most of which are expected to fail, so instead of cutting their teeth on- for example- a moderate-sized program which is one of many running on a bank's mainframe novice programmers are expected to be effective members of a team writing a comprehensive integrated system: and if their collective inexperience breaks it there's no fallback position.
"If a professional deems C to be the language required for a project, let her use C"
grammar note: the correct pronoun to use, when the sex of the subjwect is not known, is 'he' (as a subject) or 'him' (as an object). If you don't want to specify a sex, "the programmer" would work, even though it has an awkward style.
In any case, using 'she' sounds like SJW/political-correctness *EXCREMENT* and if, in fact, it *IS* politically correct *EXCREMENT*, it should be shunned, ridiculed, etc. until he who uttered/wrote such an abomination is COMPLETELY EMBARRASSED.
there. I said it.
(but I agree, allow the programmer to use whatever language HE is familiar with in order to provide a useful and maintainable solution within the shortest amount of time and least amount of effort, balanced against reliability).
This post has been deleted by its author
I can see your point, but there's a lot of significant ignorance there. The "they"/"their" construction has been used for the same purpose for several hundred years, and it sidesteps the gender issues completely. I'll concede it might be still an SJW fix, but I am not sure I can find polite words to describe somebody pushing the "he"/"him" version.
There is a pattern I see, in many fields, where the loudest shouting comes from men who are not competent enough to compete with women. And you can mirror that, though there are far fewer women it can apply to. There is a bias, and it protects incompetent men
Sure, string management is really simple and efficient, and especially safe, in C...
Probably that's the first reason Perl exists.
It would have been simpler and better to add a proper string type in C (and related operators), but you know, in *nix world useless complexity is what people like, and some designs are more revered and immutable than the Ark of the Covenant and its contents - for no better reasons than "tradition".
No - don't use wstring unless you have to, as it's mostly broken. You'd either need 32 bit characters for the whole of unicode (on linux), wasting enormous amounts of space, or encode things into 16 bit characters (on windows). For example: https://stackoverflow.com/questions/11107608/whats-wrong-with-c-wchar-t-and-wstrings-what-are-some-alternatives-to-wide
Instead, the best approach is to use std::string, and encode everything as UTF-8.
> No - don't use wstring unless you have to, as it's mostly broken.
[citation needed]
> For example: https://stackoverflow.com/questions/11107608/whats-wrong-with-c-wchar-t-and-wstrings-what-are-some-alternatives-to-wide
Please talk to Microsoft and ask them nicely to fix their broken UTF stuff. UTF encoding is not broken on Linux. It's broken on Windows.
> [ ... ] use std::string, and encode everything as UTF-8.
That works if you need UTF-8 encoding. If you need UTF-16 you can use std::wstring, and for UTF-32 you'll need std::u32string and C++11 or higher.
Only char arrays."
which is JUST FINE and MORE FLEXIBLE, especially when you're not LAZY and/or spoiled by Java or BASIC.
mastering strings in C/C++ is *SIMPLE*. I've been doing it for YEARS. DECADES even. More than TWO decades.
I suppose this means we need more COMPETENT programmers in the world...
maybe it should be like CW for HAM operators. Code in C only until you're competent in it.
"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)
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.
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.
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.
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."
@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.
"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 :-)
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.
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.
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.
"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.
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.
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"?
> 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.
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.
> [ ... ] 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.
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.
"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.
This post has been deleted by its author
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…
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.
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.
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.
"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.
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.
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.
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.
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
I was amazed when I read about the alleged "jif". I still think the J is a leg pull. Also in many languages the initial J was an I, so pronounced sort of Y. Some languages don't even have a J sound!
Surely it's Graphics Interchange Format, so G as in gravy or graft, not J in as in Gillian!
Why do some people believe etymology determines pronunciation? That's as unreliable a rule for English words as you could hope to find.
As has been widely documented, Steve Wilhite, who invented the format, has always pronounced it with a soft "G" as a pun on the name of JIF brand peanut butter. That's at least as strong an argument for the soft-G pronunciation as any of the (mostly spurious) ones for the hard-G one.
Ultimately, of course, it doesn't fucking matter, because the dominant pronunciation will be determined by use, and both forms are recognizable to pretty much the same audience.
"I assume, then, that you pronounce CMOS with a hard C, and IMAP with a short I?"
Of course. Don't you? What are you, some kind of weirdo?
Also, Gigabyte is pronounced with a soft G, as the root is the same word as that of Gigantic. Doc Brown got it right, in spite of the ignorance of the script writers ...
Shall we discuss rooter/rawter while we are at it?
Quite right too, far better to leave it to the professionals.
Correct.
Burroughs used to have a 4GL called Linc. In the early days it had no graphical development environment, everything was specified via text files.Then a colleague of mine developed a way to graphically describe LINC components. He called it Direct Input of Linc Definitions Online. And sold it to several companies.
Marketing weren't too impressed.
Ha! Dammit. I never read it as you did, but now I can't un-see it!
Maybe because of the previous programs UCLUST (for clustering) and USEARCH (for searching), I have always read the name of this one U-PARSE... (all very powerful and popular bioinformatics programs, by the way)
A slightly less silly reason not to call it "the Camelia Programming Language" is that if it is called that, you can be absolutely certain that some dolt will start abbreviating it to CPL. If the reason this name change has been suggested is to avoid confusing it with another version of Perl, making it possible to confuse it with another language altogether seems a bit silly.
While Larry -Wall is one of the greatest guys ever, I always though of Ruby as a new version of Perl.
The creator of Ruby even admitted that the Name "Ruby" was inspired by "Perl", because apparently in the japanese culture each month has a Crystal (again, no computer-language pun intended) with the Ruby month being the successor of the Perl month. Please feel free to correct me if I'm wrong on the details, I have only very limited knowledge of the japanese culture!
<(_ _)>
Ruby has a lot of Perl idioms: like $pecial symbols, built-in r/egexes/, `backticks`, optional parentheses and so on.
And of course both are related to Tim Towtdis philosophy: "there are many - and preferably many - ways to do it".
Wait, I'm not telling you to use Ruby instead of Perl. I want people to stay curious and use whatever they want. Ruby is an amazing language but so is Perl.
..FIVE
;-)
Python 2 has a backticks feature, but all it ever did was call repr(). It never invoked a command in a shell like backticks do in bash, Perl or Ruby.
In Python 3 the backticks feature was taken out because it's so rarely used that most Python users didn't know it exists - and the thing it did wasn't particularly useful, and it was kinda confusing anyway. You can just type repr(), it's only 4 more bytes. :)
Oh welp, I found them incredibly useful for scripting:
puts "There are #{ `awk -F ':' '{print $1}' /etc/passwd | grep -v 'sys'`.split.size } lusers on this machine.."
Notice how well it interacts with Ruby ("split" and "size" being ruby methods).
Time to step up your Command Line Fu, sempai?
Perl is the most hated programming language.
I suppose you can come to hate it if you misapply it. The mistake here is using it for any large projects. But it is perfect for small scripts, argument modifying wrappers for commands, mangling text from one format to another, and the like. Most of the features you need are built-ins (usually no need to require tons of modules), no boilerplate and grandiose declarations are needed. As they say, Perl is the Swiss Army Chainsaw.
Indeed.
My recall of Perl 5 was it was fast for an interpreted language and with all CPAN, powerful enough to build a full compute jobs queuing system, with a lot of feature. You had syscalls for low-level stuff and everything else, unlike all the rest of interpreted languages. And we needed flexibility, so compiled lang were out of question.
This turned out very well, and since it was only 200ish lines per agent, and I'd stay clear from the dark arts of regexpr and friends, still maintenable.
I only learnt in this article that Perl 6 was another language actually. So, yes, shouldn't even have been called Perl at all ! Time for its own name.
As for Java/JS/Perl comparison, to me, a language (java) which never was compiled nor interpreted, instead mixing the worst of both worlds, has always been non sense.
And, JS /SPIT
So, end of the day, Perl 5 is better than those 2. The hate has to come from Perl 6 incompatibility with 5.
Oh, for people comparing 5->6 with the very ol 4->5 evolution, there is no comparison. 4's scope was minimal (quick scriptie) while 5 was a full blown thing. 6 should have been compatible with 5.
> What is/was wrong with TCL? Good at string processing (like Perl) and a lot more readable.
Maybe because it was primarily "marketed" as an embeddable extension language. The package always came (and comes, it has not disappeared) also with a stand-alone interpreter, which is nice for exploring (and with tck/tk you can make a gui program with just a few lines). One of my favourite programs is tkdiff, a GUI file comparing and merging tool. Old but still works great. Just 9739 lines of clearly laid out tcl/tk, which is amazingly low considering its functionality.
(But I disagree a bit about readability. Tcl has very few syntactic niceties. It is a like LISP but without the parentheses. On the other hand, that makes it far more consistent than Perl).
Yep, I am not a programmer, and I was using Perl from the late 90s onwards to do Windows scripting because I could not get my head around vbs (vbs was useless with regexes, hashtables/"dictionaries" are just awful, etc).
Perl had Win32, ldap and smtp modules, which meant I had simple means of doing 95% of my work with no fuss. The O'Reilly books were great. For the other 5% of stuff I couldn't figure out readily, sites like Perlmonks were excellent for giving good advice with very little "RTFM n00b" smackdowns, and I found the obfuscation and poetry parts pretty amusing (since, hello, you're not supposed to do that kind of stupidity in real code).
Yes, the move from Python 2 to Python 3 was botched but the changes in the syntax were minimal. They were still enough to cause problems and more work than should have been necessary to migrate but the core developers did at one point take the blame and do something about it. Now, with Python 2's EOL rapidly approaching the vast majority of projects should be okay. Some, of course, will continue to Python 2.7 (I know of some places still using Python 1.5) but these are large legacy systems with no access to the internet, so security aspects are minimal. But basically there was never really much of a discussion of 2 versus 3, but more one of "why should I invest the resources to switch?" and it took a while for answers in the form of features and perfomance to appear.
Mostly it was a chicken-and-egg problem, where no one wanted to switch until all the libraries they used were ported.
Even now a lot of Python code just comes with a make script to transpile from 3 to 2 or vice versa, which is kind of an ugly hack.
The library issue was a key problem, which is why the PSF sponsored some ports, but even then adoption was hindered for a long time (until Python 3.5) because Python 3 used more memory and was slower for many things and didn't offer anything new. That was never going to help overcome software maintenance inertia.
But I think that, in the end, we learned from the experience as can be evinced by the vastly improved release process.
I personally don't know of many libraries that transpile, though I'm sure there are some. For most developers without C-extensions six or something similar and universal support for u'' and b'' prefixes was enough. Certainly less work than, say, switching from unittest to pytest.
Apparently they can't spell "camellia" any more than they could "pearl".
At least "perl" was an acronym, even if all lower-case in some kind of flower-power-era rebelliousness. (By the way, many English speakers from outside the US would naturally pronounce "perl" to rhyme with "peril" if they didn't already know what it was.)
Perhaps stick with "perl++" as suggested by several commenters in the linked blog entry. That will make the pedigree, such as it is, immediately obvious.
This is generally my order of language based on complexity of requirements on POSIX systems:
sh -> awk -> perl -> c
Is it because I prefer Perl and C to Python, Perl6 and Rust? Hell no; it is because they are there and don't require additional dependencies. Perl6 and Python are annoying to install. Python has that weird Javascript/NPM inspired cancer called PIP that ensures every bit of code you write today; probably wont work on Python in a few months.
It is nice to see Perl not going through the same mess as Python 2.x -> 3.x. I find that kind of language breakage unacceptable. Like VB6 -> VB.NET. It is basically an abrupt death of a programming language and how replacing it with another of the same name actually manages to trick some "non"-developers is beyond me.
Also Perl 5 has a cooler logo: https://github.com/kraih/perl-raptor
... yes, but the discussion is not new and the video just demonstrates how inward looking the Perl6 supporters have become.
An early discussion on the topic:
http://blogs.perl.org/users/zoffix_znet/2017/07/the-hot-new-language-named-rakudo.html
Whether or not they finally agree a name change, the rest of the world by and large has moved on to pastures new.
Most of these various coding and scripting languages look to start by hacking at a free 'C' compiler as their basis. Thus preserving the worst features whilst larding on complexity. Python and Perl and the like all make a great argument for Fortran and COBOL.
Interesting exchange on that Github issue thread--someone suggested renaming Perl_6 as "NuPerl".
But then a Perl_5 aficionado chimed in that that would be BAD, since it would imply that Perl_5 is "old" Perl (which it is).
How to resolve this issue when Perl_5 people would rather not see Perl_6 retain the word "perl" at all???? Maybe have Perl_5 be renamed to "Perlx" at exactly the same time.
Then at the command line, type "perlx" for one and "nperl" for the other.
(Or go with Aaron Sherman's April 1, 2011 article to Perl_6 "Clamchowder": http://essays.ajs.com/2011/04/clamchowder-ne-perl-6-to-offer-shell.html)
Using Perl 5 for new projects now is introducing significant technical debt right off the bat, Pearl 6 I've never used but it wouldn't be my first (or even fourth) choice because it's not very popular and 3rd party support for a where a language lives and dies.
I know it's a round-about way to say this, but what I mean is that it doesn't matter what Perl 6 is called, very few people care.
"...with Ada in the top 100 girls' names for the first time in a century."
The ONS said girls named Alexa also halved in a year, possibly due to potential confusion with Amazon's Echo."
If you've had any exposure to Perl, you've probably heard of Tom Christiansen.
Twenty years ago, I wrote the letter below to him. He was kind enough to suggest that I write more.
Well I'm still coding in Perl now, more or less all day every day.
I'm not sure that was what he meant. :)
8<-------------------------------------------------------------------------
Date: Thu, 18 Nov 1999 23:46:19 +0000 (GMT)
From: "G.W. Haywood" <xxxxxxx@xxxxxxxxxxxxx>
To: Tom Christiansen <xxxxxxx@xxxxxxxxxxxxx>
Subject: Re: using function prototypes w/ mod_perl.
Hi there,
If pressed, I'd admit I'm a C programmer.
I probably speak C as well as I speak English, having been at it since it was invented.
Yes, I'll admit I'm over 40. Well over.
C has got better over the years. To start with the compilers were a bit dodgy and the linkers didn't know about type.
Now that's all sorted out you can write code knowing that if you pass a string to a function that's expecting a double you'll never get it past `make'.
As a result, some of my programmes have been running for over a decade without stopping.
Some of my code sits monitoring nuclear reactors and patients in hospital laboratories.
My financial well-being is tied to my proficiency in C because my software currently sends out invoices for any of the 120,000 products that I now sell to a sizeable portion of my 18,000 customers, daily.
It tells me who owes me money, how much, since when, and where I must go if necessary to get it from them.
Sometimes it's necessary.
It has to work. If I need a program that's bullet-proof, that will take absolutely anything that's thrown at it, then I will pull out my trusty old C libraries and get coding.
When it's finished, a hyperactive kitten jumping on the keyboard will result in nothing more sinister than a couple of bleeps.
Such extreme duress might possibly cause an invoice to be printed that should not have been printed, (although it wouldn't make it out of the door), but it definitely wouldn't put an entry in the error log.
In short, I believe in C because I've been at it for 25 years.
Well, I'm new to perl. About 18 months now. You'd think I'd hate it because it's such a completely different thing from C, but, I don't.
I love it. I can do things in perl in twenty minutes that would take hours in C, if it were realistic even to consider coding them that way.
What will it be like when I get to be competent?
When I talk to that absolutely fantastic interpreter it talks back to me, telling me where I made silly mistakes, sometimes showing me a better way to do it, holding my hand as I stumble along.
At 400MHz, it's quick enough.
Would I convert any of my hardcore financial stuff to perl?
Would I put perl in a diagnostics laboratory? On a reactor?
Never.
But would I mess about with C to get something running on our Website? Why bother?
There are so many things waiting to go wrong between the user's browser (which is probably a M1croS0ft product so it will almost certainly crash within the next ten minutes or so)
and my servers (which probably will not survive even the most ham-fisted of attempts by a second-rate undergraduate to gain illegal access) that the idea of my writing a Robust Piece Of Code to do something as mundane as serving pages is simply laughable.
The Web is moving so fast I'm sure that if I try to do what I need to do in a language like C, I'll never catch it. So I say let's get it done, make a few bob, and on to the next job.
Tell your C programming friends that function prototypes are for people in air-traffic control and petrochemicals.
If they're really fussy, tell them they should be looking at RTL/2 anyway. Tell them what the p in perl stands for. It doesn't stand for `prototypes'.
Kind regards,
Ged.
8<-------------------------------------------------------------------------
VB is the language that put me right off trying to get back into programming, many moons ago (I had been fairly good at programming in BASIC, 6502 assembler, 6502 machine code and I messed about with FORTH and LISP a little). I did look at Python a year or two after my encounter with VB (seemed OK, what little I saw of it), but by then had decided Helldesking was my forte, and I was sticking to it! But VB - (shudder). After three days of effort, I still couldn't get a program that would've taken me half an hour to code in old-school BASICs (granted, sans nice UI) to do anything useful at all!
My hat's off to all you bright sparks that can make all this stuff (waves hand around to indicate t'internet, OS's, etc) work, whatever language you're using to do it!
It looks like you fell for Microsoft's trap.
VB is no longer BASIC, it is VB.NET; a weak gateway drug to a shite language C#, copying off an awkward language Java.
If you liked BASIC, then try out the VB dialect (VBA) that comes with Microsoft Office.
For all those so far up themselves who consider that you shouldn't be programming if you can't write in C.
Bollocks!
Perl is the next step up from shell scripting which turned out to be so useful that people kept extending it and extending it.
I've used it in the past for simple things like automating the copying of files, and running a Telnet script to monitor an early ADSL modem on a line which had a wobbly signal.
The nice thing is that scripts are portable between different OS where shell scripts aren't/weren't.
I've worked on much larger systems written mainly in Perl where I questioned why it was used (I suspect a demonstrator may have morphed into production) but still, it worked.
I'm not a professional programmer so although I have written in C it isn't my language of choice when reaching for a book to help me write 10-20 lines of one off ditty.
Oh, and if you want similar name incompatibility try writing in C shell after learning C.
Perl's problem is not its name. Perl 5 gained a reputation for being a free form, write-only language. There were about 10 ways to do any simple task and some of them were extremely esoteric. That became a problem since any given script was likely cobbled together from cut and pasted snippets from a google search.
Unsurprisingly, developers gravitated to more readable, maintainable (and potentially structured) languages. It doesn't help that Perl 6 is not code compatible with Perl 5 but historically Perl has always done that so I don't see that as the main reason for disinterest. There just isn't the audience or demand for it any more and I don't see much that would persuade or sell the language to anybody with an existing codebase in Python, JavaScript or Ruby.
Her preference would be to rename it "the Camelia Programming Language. No, no and NO! That is just so 'ist to use a name that is so similar to my name. How dare they / her / he / it, change the name. Oh my goodness! While we are at it, WHY not change all the languages all together? All the books that are out there will need changing too, Python, Ruby, C##, C++ and many others. Some change is good, some not so good.
As Perl.org puts it, Perl 6 is "not intended as a replacement for Perl 5, but as its own thing."
Here's Toasting to ITs Hosting of Advanced IntelAIgent Themes ........ Virtually Streamed via Capture in Captivating Media Streams.
AIRealities for Terrestrial Television to Introduce and Co Host with Secret IntelAIgent Services .... [if anyone needs to know mutter MuI7 Attends and Extends Future Feeds and Seeds]
The Ponder here is whether it be an AI for Boris to Borrow and Ply with Plunder? :-)
Who ever would have athought it, ....... Future Remote Real IT Command and Control, Mercifully Mercilessly Available at One's Fingertips.
Now that News Today for Tomorrow will allow you to Tune In and See and Try Out NEUKlearer HyperRadioProACTive IT [Future Remote Real IT Command and Control, Mercifully Mercilessly Available at One's Fingertips.]
What a lovely situation to be in, El Reg........ with Clear AIMagic Roads Ahead for All. Follies Think Secrecy and Stealth are Both Necessarily Desired because of Knowledge Discovered Uncovering All Manner of Instantly Available Facilities.
It never rains but it pours, Boris. Give a bulldog a bone and it aint going anywhere it isn't needed. ...... https://www.zerohedge.com/political/brexit-gloves-come-let-massacre-begin-says-eurointelligence
It does have one wondering who and/or what supplies leading future intelligence for/to the masses to/for Governments/Churches/Cabals/Markets/Private Elitists/Piratical AI Pioneers.
But amfM, what thinking man pays any attention to the clowns over at Zero Hedge? As far as I'm concerned, anything that comes out of that camp is extremely biased, to the point of being fiction, and thus is a non-starter as far as serious conversation is concerned.
Care to make whatever point you were attempting to get across, but this time in your own words?
Hi, jake.
Re any of your concerns, it is probably impossible to do better than just reiterate and wholeheartedly agree with these few words .......
So we are evolving rapidly. Cyber is now our fastest-growing directorate. We are shifting our focus to the nexus between humans and technology. And for the first time, through the National Security Strategic Investment Fund, we are pursuing a completely different type of partnership with the tech-innovation community, giving the private and academic community the role we need and they deserve.Ironically, the most profound consequence of the technological challenge is a human one. We are determined, of course, to attract people with an even higher level of technical skill to join our ranks, in the best traditions of Q. But my organisation will need to adapt even faster if it is to thrive in the future. And that will require people with new perspectives, capable of harnessing their creativity in ways that we can’t yet even imagine.
It is why we are determined to attract people from the widest range of backgrounds to join SIS. This will enable us to bring the widest range of approaches to bear on solving complex problems and so make our missions even more effective. .... Alex Younger [MI6 "C"] St Andrews University speech Dec 2018
You'll just have to imagine where all that is at, a further year on down the line.
I stopped reading at "cyber". It's always a sure sign of the cluelessness of the author. Kinda like the idiots who use the word "snowflake" when not discussing snow, don't you think? ...... jake
Wow! ..... To think so, jake, has one surely catastrophically disadvantaged and quite unnecessarily so too. It is thus an idiotic mistake to make and barren path to take ...... imagining the chief of the Secret Intelligence Service, and coincidentally and collaterally Queen Elizabeth II by virtue of her private support and public reward, clueless in fields in which they are intelligently designed to stealthily excel, don't you think?
The chief's field is economics, and the figurehead's degree is inherited. Neither are exactly what I would consider technically inclined, so why should you or I listen to them when it comes to technical matters? They are just paper-pushers, mouthing words that have no meaning to them.
Face it, virtually everything that has ever been written about cyber-this and cyber-that has pretty much been forgotten within days or weeks of the comment(s) being uttered. It is a meaningless word, only useful as a filter.
Any "C" worthy of heading Secret Intelligence Services will be right royally chuffed to realise the Almighty Stealth available in Virtualised Operations with Advanced Future Controllers, which as you have beautifully confirmed, are both Invisible and Unbelievable. Is ever there an Almightier Friend or More Fearsome Fearless Foe?
The fact that one doesn't/can't believe such as is shared, when a well enough known nugget of information in any number of other locations into macro managing Islands of Treasure and Pleasure where Simple and Undeniable Truth is AIMastering Universes, is always discovered to be malfunctioning communication channels/still silent witnesses.
I think you misunderestimate the Secret Intelligence Service, jake. They'll just love that too. :-)
Misunderestimate an induhvidual? Nah. Ol' Bill of Occam says no.
So does the Peter Principle.
To say nothing of decades of actual observation, working in the industry.
Doubly so for military/government.
That is as may be, jake, and it is then just time wasting to disagree, but we are not talking here of misunderestimating figure heading individuals whenever dealing with tip top top secret secure secretive virtual entities.
And even though one might recognise your pain and disillusionment, to not imagine and realise the future is a completely different space place to populate and present with prime novel content displaying premium intelligent information, is to admit that one is stuck in a deep and dark bankrupting rut of overwhelming despair and illogical hope.
And that leaves one catastrophically vulnerable and helpless against everything that is not status quo establishment controlled via the facility and utility of the Main Stream Media Channels', Poxed Chunnels and Deceitful Tales ....... Increasingly Desperate and Ultimately Self-Destructive Trails.
My pain and disillusionment? Last time I checked, I felt no pain or disillusionment ... and I am certainly not stuck in a deep and dark bankrupting rut of overwhelming despair and illogical hope.
I'm terribly sorry, amfM, you seem to have me confused with somebody else. Might want to check your notes and try again.
During the meanwhile, relax and have a homebrew ... it'll do you a world of good.
Camelia is a nice, pleasant name, and it can draw people in via the sexual-emotional route.
Raku can bury the language.
Technical merits? They don't matter that much. Would you rather tell people that you do Camelia or Raku? Sounds to me like I'd rather admin to writing Perl than Raku.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
