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 …
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
