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 …
"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.
int main(enter the void)... The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
