|
in reply to A meditation on the naming of perl6
My verdict would be: too little, and far too late. The damage -- significant damage -- to both language variants was done and dusted a long time since. Sad to say, but I think recovery at this stage is impossible for both camps.
In part, the marginalisation of Perl(X) has come about because different parts of its once hugely broad domain wanted different things from it.
Even without the self-inflicted wounds caused by the naming, delays and infighting, Perl was always going to have a tough time to compete on all fronts. With them, it stood no chance.
Whilst I still use Perl5 for prototyping, I haven't produced a 'production program' in it for over 2 years.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit |
Re^2: A meditation on the naming of perl6
by RonW (Parson) on Jul 11, 2017 at 22:39 UTC
|
When I was still a university student, the CS department was steeped in Scheme. Meanwhile, in engineering, we were using C and a little assembly language as needed. One of the CS classes I took also used some Pascal (because the professor was steeped in Pascal and still learning Scheme). A few of the engineering libraries were written in FORTRAN, still around because "if it ain't broke, don't replace it". But mostly, we coded in C.
Now, many years later, as a professional developer in the embedded market, still using C. In the testing group, many of the tools they use have various dialects of Lua as scripting languages. Several use Excel spreadsheets as their scripting "language". A few use "Labview" (National Instruments' graphical programming system for their test controllers).
Perl is our data munging and "build script" language. It gets the job done, usually very nicely.
The IT departments of my current and past 2 employers code in Power Shell, C# and SAP Scripting language.
The network admins, though, use Perl and bash.
I don't know what other companies use.
| [reply] |
|
|
Perl's utility hasn't and won't go away. In 10 years or 20 it will still be as good a language as it ever was; and that's very damn good. The problem will be finding companies that are prepared to accept it's use on their projects & systems.
Eg. For anything that needs to work with AWS until very recently you were totally out of luck. As of 2015, a community effort started to put together a Perl interface to it in the shape of PAWS. By roughly the beginning of this year, they had something that could be seen as reasonably robust; for those AWS services it covers. But that set is only a subset of those available; and the delay between AWS adding new ones and those becoming available via PAWS grows longer.
These problems do not occur for the users of Go, Java, JavaScript, PHP, Python, Ruby, Windows and .NET, C++; for which AWS write and maintain the interfaces and mostly release simultaneously with the announcement of new APIs.
As an in-house perl programmer, you will tend to move between companies that use Perl; as a specialist consultant, the pieces of work I choose from tend to come from a small range of organisations many of whom are now outsourcing the type of workloads I code to AWS/GCP/MAS; none of whom offer Perl support, thus the Perl opportunities in my field have dried up.
I hate to say that the battle is lost; but I see no way back when those 3 cloud vendors cover 9x% of that market place and they -- for pretty sound reasons -- have rejected Perl.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
| [reply] |
|
|
But that set is only a subset of those available; and the delay between AWS adding new ones and those becoming available via PAWS grows longer. These problems do not occur for the users of Go, Java, JavaScript, PHP, Python, Ruby, Windows and .NET, C++; for which AWS write and maintain the interfaces and mostly release simultaneously with the announcement of new APIs.
That kinda sounds like they're doing it wrong, as new services/apis ... should mostly be generated rather than "written" from scratch
| [reply] |
|
|
|
|
