Re^3: A meditation on the naming of perl6

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.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

Comment on Re^3: A meditation on the naming of perl6

Replies are listed 'Best First'.
Re^4: A meditation on the naming of perl6 by Anonymous Monk on Jul 12, 2017 at 01:44 UTC
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]
Re^5: A meditation on the naming of perl6 by BrowserUk (Patriarch) on Jul 12, 2017 at 03:02 UTC
If you'd care to suggest how to "generate" interfaces to the 7 new AWS apis introduced just in the last week, I'm sure they'd be all ears. That said, ime, code generators are the very worst of all worlds. A cool sounding idea, but they take longer to specify; much longer and far more coordination and discipline to code; are hugely more complex, thus contain far more bugs; and are truly horribly complex and difficult to debug. Instead of just writing code to interface to the vendor specified api; you have to: Write a parser for the vendors api specification notation. And vendors specifications are rarely self-consistent, let alone rigourous. Every time the vendor releases a new api, you have to modify the parser to accommodate it and all its vagaries without upsetting any of the previous parsing. That's not just difficult, it can be simply impossible. Vendors are under no obligation to write consistent or even cross-compatible apis or specifications thereof. Then you need a code generator that can produce working and consistent code whilst mixing and matching any and all possible combinations of api sequences. That's an M^M-1ⁿ combinatorial problem for testing and verification. Ie. impossible to test without you write a generator and test statistically; which simply compounds the problems further. Debugging is a nightmare. First you have to reproduce the bug as normal and then find the cause. If you're lucky, manual inspection of the input will tell you what is wrong, but not how to fix it. Most times you'll need to inspect, trace and debug the generated code, which is invariably verbose, badly formatted, illogically composed with massive duplication and cut&paste code reuse. And once you find the cause and work out a fix at that level, you've then to work out how to modify some combination of the parser and code generation to implement that fix. 7 out of 10 times that means adding a special case 'recogniser', post-tokeniser but pre-generator to output a boiler-plate sequence in place of what would normally be generated. And if you've had to add an optimiser stage in order to make the generated code run at anything like reasonable performance; you've compounded all the problems once again. In short: Yuck! 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. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit	[reply]


Just another Perl shrine
	PerlMonks