If you want to drive Perl adoption, don’t tell the world to use Perl, tell the world about problems that Perl is better than any other language at solving.
If you want to drive Perl adoption, don’t tell the world to use Perl, tell the world about problems that Perl is better than any other language at solving.
Meanwhile, Javascript and Python are eating everyone's lunches. .NET and Swift are doing pretty well too, but JS in particular is derided as a "bad" language with tons of problems, yet it's bursting at the seams with developers. How can this be so?
Frankly, it's because you can take a random person off the street and turn them into a decent JS developer in like two weeks. JS may be formally inconsistent, but it's seems easy enough for most people to get it. It's quick to see and get results, so new developers don't get discouraged.
If Perl wants to be popular, it needs to attract users on how easy it is. This was one of the shifts Python has made over the years (getting easier for new users) and it continues to grow its userbase.
What you say is true for Python though.
In QBasic, if you wanted to draw a circle, you wrote SCREEN 1; CIRCLE (100,100), 10 and then hit F5.
Trying to do the same thing in C++ had me poring through offline Win32 API .chms for days to understand event loops, windowing, brushes, bitmaps, and memory management, then fighting with linkers and header paths to get it to actually compile.
Good languages are fundamentally at odds with how most software companies do business. They don't want to train people, they don't want to do rewrites, and they definitely don't want to hire people who can change jobs at the drop of a hat (highly skilled persons). They want the bare minimum of all of that, and maximum billings.
I think the biggest factors in adoption are: being in the right place at the right time and app/platform exclusivity.
That's a lot harder to overcome these days. I'm starting to doubt if we'll ever see another popular language displace the status quo.
That sounds a bit the end of progress. After all, Go, Rust, and Swift haven't been around for that long.
I might be open to an argument that ecosystem effects (libraries, training, etc.) lead to power law effects. But I'm not sure I believe that. I could equally well believe that the sheer scale of software development today lends itself to a lot of viable niches.
Programming languages are simply interfaces into a particular tech stack. The stacks will shift as the trends come and go, and the languages will go with it. Perhaps the lowest levels of the stack have settled nice and snugly, with little hope for displacement except by extreme measures (cpu archs, kernel/os implementations, etc) but the higher layers are still rapidly changing, and dragging along new languages with them.
That is, kernel devs got into bed with C before it was a "clear winner", and now they're stuck with it.
Ecosystems that are still developing, layered on top of these older more stabilized systems, have the freedom of choice, and they certainly make use of that freedom.
And of course, by nature of a non-stabilized ecosystem, most choices made are done before a clear winner exists -- because no clear winner exists just yet. But the choice will stick, unless it was dramatically harmful to the project.
The older the ecosystem, the less viable it is to select anything other than the clear winner, because the ecosystem is coupled to that clear winner, and the ecosystem is the fashion.
That excuse reflects very poorly on the planned future of the company I work for, but I don't think my bosses recognize that.
It's apparently less important that our applications are crash-resistant by design of the platform rather than the application itself. I'll admit I'm a bit of a diva with regards to available tools but it's getting really tiresome.