7 ms·

Point 2 is kind of nonsense. The ecosystem is incredibly big and keeps up with most things. Name something then search here https://metacpan.org/ https://metacp

Point 2 is kind of nonsense. The ecosystem is incredibly big and keeps up with most things. Name something then search here https://metacpan.org/ https://metacpan.org/ The main missing stuff is anyone marketing heavily their libraries and there being communities around them etc. Like probably no one knows what PDL is, even though it was around long before numpy+scipy etc. Before data science trended in the mind of hipster VCs and coders. The naming was to try and win over people from the IDL language, used mostly in image analysis in physics/geography. A niche crowd to be sure. Perl sort of never caught on to the modern style of advertising what its got. In the same way no one really advertises grep, awk or sed but lots of people still learn and use them.

jasode 9y ago
>ecosystem is incredibly big I wasn't talking about the size of cpan because it's not relevant to my point. I was talking about Perl not being at the forefront of everyone's minds and being used as a 1st-class environment as computing entered new domains. E.g. instead of Sun or Microsoft taking an existing language like Perl and giving it a canonical IDE to let programmers write data entry GUI applications, they create Java & C# instead. When Google/Android decided on a development language for their smartphone SDK, they chose Java instead of Perl. It doesn't matter if cpan has mobile phone libraries now. You seem to be taking my observations about Perl as some sort of veiled attack. I'm just reporting why and how Perl got to the state of being "disliked" today in programmer surveys. It's not about the "undecidability".
- Ultimatt 9y ago
  Ok then your definition is corporate ecosystem then? Perl in general is hardly the stuff of scaled soft eng. in a mega corp. It wasn't designed for that, but to empower an individual to be highly productive quickly. With that in mind the ecosystem is super healthy, even by your definition. I'm more shocked Python has managed to bridge that gap, but so did Pascal at one point so I guess designed to be a teaching language wins out!
  - jasode 9y ago
    >It wasn't designed for that, And I'm not "penalizing" Perl for that. >I'm more shocked Python has managed to bridge that gap, That's more to my point. Old languages like C++ and Python keep getting rejuvenated as 1st class drivers of innovation but Perl (the language -- not the cpan) keep getting ignored. I was surprised when Google chose Python as one of the 1st class languages for its new Tensorflow instead of a new language like Julia. I do understand why they chose Python but nevertheless was surprised. Same for C++. It gets rejuvenated in things like graphics programming (NVIDIA's CUDA SDK is C++ not Perl). And when Bitcoin showed up in 2009, it's canonical client was C++ not Perl. Also, updates to C++ via C++14 and C++17 were discussions that turned into reality whereas Perl 6's long development became a running joke about vaporware. Perl5 and Perl6 don't really have any new stories like that where it gets rejuvenated. Therefore, it keeps dropping off everyone's radar as "legacy". Whether Perl programmers are highly productive with Perl isn't really the issue.
    - kbp 9y ago
      > Same for C++. It gets rejuvenated in things like graphics programming (NVIDIA's CUDA SDK is C++ not Perl). And when Bitcoin showed up in 2009, it's canonical client was C++ not Perl. Perl is not competing with C++; they're entirely different languages with entirely different usecases. Comparing it to Python is reasonable; comparing it to C++ is silly. > Also, updates to C++ via C++14 and C++17 were discussions that turned into reality whereas Perl 6's long development became a running joke about vaporware. Newer C++ versions are more akin to newer Perl 5 versions like 5.26 (May 2017), 5.24 (May 2016) etc. Perl 6 is a new language using some of the same ideas; comparing Perl 5 and Perl 6 is like comparing C++ and C#, not C++ and C++17.
      - jasode 9y ago
        >Perl is not competing with C++; they're entirely different languages with entirely different usecases. Yes, I understand that C++ does not compete with Perl. My point is the rejuvenation stories, not the runtime or use case differences. I use a utility every day called ExifTool[1] that's 100% Perl source code or very close to it. However, ExifTool does not keep Perl at the top of mind the way Tensorflow brings Python relevancy to a new generation of programmers. [1] https://www.sno.phy.queensu.ca/~phil/exiftool/ https://www.sno.phy.queensu.ca/~phil/exiftool/
zbentley 9y ago
The size of the CPAN is certainly impressive. However, past a certain point, a big, multipurpose, monolithic Perl codebase being worked on by a ton of different developers is going to have significant problems caused specifically by the use of different CPAN libraries: many, many quite common libs do not "play well" with each other in quite simple cases. And I'm not talking about "I'm trying to glue together two third-party tools that weren't written with each other in mind", I'm talking "I have a request handler that once, an hour ago had to load and call a function in a given module, and is now issuing cryptic errors on all requests of a certain type because they happen to call a function in a different, totally unrelated module that worked before". This is largely because of the sheer volume of weird global state inspections/mutations you can do in Perl--or I guess it's more accurate to say that Perl has a conveition of it being "OK" to heavily and frequently inspect and mutate global state. You can monkey patch in many languages, and sometimes it's even encouraged (Ruby), but only in Perl is it not uncommon to see monkeypatch removal or seriously altering replacement of core functionality. I've had modules hackily unload other already modules because the loaded modules' names matched a buggy load-time regex. I've had packages clobber text handling or encoding routines in other packages at compile time, or only after calling a certain function a certain way. I've had modules change the behavior of the core signal handling APIs so that any code that talked to them . . . didn't actually handle signals. And those are just the pithy examples that fit in a single sentence. Now granted, this isn't a criticism of Perl-the-language but more of (depending on how you choose to interpret it) library authors who don't prioritize or even consider interoperability with other tools, or of Perl-the-community's conventions regarding when it's OK to go mess around in globally-stateful guts of code you don't control. You could also just as easily say that it's a symptom of the big, multipurpose monolith I had to maintain--which is valid, but other not-designed-for-huge-projects languages don't, in my experience, have problems quite this bad when they're forced to scale. My goal isn't to cast blame, but to point out that CPAN is incredibly bloody far from a high-quality, stable, or usable code repository for certain very common use cases.
- Diederich 9y ago
  > CPAN is incredibly bloody far from a high-quality, stable, or usable code repository for certain very common use cases. Citation needed.

jasode 9y ago

>ecosystem is incredibly big I wasn't talking about the size of cpan because it's not relevant to my point. I was talking about Perl not being at the forefront of everyone's minds and being used as a 1st-class environment as computing entered new domains. E.g. instead of Sun or Microsoft taking an existing language like Perl and giving it a canonical IDE to let programmers write data entry GUI applications, they create Java & C# instead. When Google/Android decided on a development language for their smartphone SDK, they chose Java instead of Perl. It doesn't matter if cpan has mobile phone libraries now. You seem to be taking my observations about Perl as some sort of veiled attack. I'm just reporting why and how Perl got to the state of being "disliked" today in programmer surveys. It's not about the "undecidability".

Ultimatt 9y ago
Ok then your definition is corporate ecosystem then? Perl in general is hardly the stuff of scaled soft eng. in a mega corp. It wasn't designed for that, but to empower an individual to be highly productive quickly. With that in mind the ecosystem is super healthy, even by your definition. I'm more shocked Python has managed to bridge that gap, but so did Pascal at one point so I guess designed to be a teaching language wins out!
- jasode 9y ago
  >It wasn't designed for that, And I'm not "penalizing" Perl for that. >I'm more shocked Python has managed to bridge that gap, That's more to my point. Old languages like C++ and Python keep getting rejuvenated as 1st class drivers of innovation but Perl (the language -- not the cpan) keep getting ignored. I was surprised when Google chose Python as one of the 1st class languages for its new Tensorflow instead of a new language like Julia. I do understand why they chose Python but nevertheless was surprised. Same for C++. It gets rejuvenated in things like graphics programming (NVIDIA's CUDA SDK is C++ not Perl). And when Bitcoin showed up in 2009, it's canonical client was C++ not Perl. Also, updates to C++ via C++14 and C++17 were discussions that turned into reality whereas Perl 6's long development became a running joke about vaporware. Perl5 and Perl6 don't really have any new stories like that where it gets rejuvenated. Therefore, it keeps dropping off everyone's radar as "legacy". Whether Perl programmers are highly productive with Perl isn't really the issue.
  - kbp 9y ago
    > Same for C++. It gets rejuvenated in things like graphics programming (NVIDIA's CUDA SDK is C++ not Perl). And when Bitcoin showed up in 2009, it's canonical client was C++ not Perl. Perl is not competing with C++; they're entirely different languages with entirely different usecases. Comparing it to Python is reasonable; comparing it to C++ is silly. > Also, updates to C++ via C++14 and C++17 were discussions that turned into reality whereas Perl 6's long development became a running joke about vaporware. Newer C++ versions are more akin to newer Perl 5 versions like 5.26 (May 2017), 5.24 (May 2016) etc. Perl 6 is a new language using some of the same ideas; comparing Perl 5 and Perl 6 is like comparing C++ and C#, not C++ and C++17.
    - jasode 9y ago
      >Perl is not competing with C++; they're entirely different languages with entirely different usecases. Yes, I understand that C++ does not compete with Perl. My point is the rejuvenation stories, not the runtime or use case differences. I use a utility every day called ExifTool[1] that's 100% Perl source code or very close to it. However, ExifTool does not keep Perl at the top of mind the way Tensorflow brings Python relevancy to a new generation of programmers. [1] https://www.sno.phy.queensu.ca/~phil/exiftool/ https://www.sno.phy.queensu.ca/~phil/exiftool/

zbentley 9y ago

The size of the CPAN is certainly impressive. However, past a certain point, a big, multipurpose, monolithic Perl codebase being worked on by a ton of different developers is going to have significant problems caused specifically by the use of different CPAN libraries: many, many quite common libs do not "play well" with each other in quite simple cases. And I'm not talking about "I'm trying to glue together two third-party tools that weren't written with each other in mind", I'm talking "I have a request handler that once, an hour ago had to load and call a function in a given module, and is now issuing cryptic errors on all requests of a certain type because they happen to call a function in a different, totally unrelated module that worked before". This is largely because of the sheer volume of weird global state inspections/mutations you can do in Perl--or I guess it's more accurate to say that Perl has a conveition of it being "OK" to heavily and frequently inspect and mutate global state. You can monkey patch in many languages, and sometimes it's even encouraged (Ruby), but only in Perl is it not uncommon to see monkeypatch removal or seriously altering replacement of core functionality. I've had modules hackily unload other already modules because the loaded modules' names matched a buggy load-time regex. I've had packages clobber text handling or encoding routines in other packages at compile time, or only after calling a certain function a certain way. I've had modules change the behavior of the core signal handling APIs so that any code that talked to them . . . didn't actually handle signals. And those are just the pithy examples that fit in a single sentence. Now granted, this isn't a criticism of Perl-the-language but more of (depending on how you choose to interpret it) library authors who don't prioritize or even consider interoperability with other tools, or of Perl-the-community's conventions regarding when it's OK to go mess around in globally-stateful guts of code you don't control. You could also just as easily say that it's a symptom of the big, multipurpose monolith I had to maintain--which is valid, but other not-designed-for-huge-projects languages don't, in my experience, have problems quite this bad when they're forced to scale. My goal isn't to cast blame, but to point out that CPAN is incredibly bloody far from a high-quality, stable, or usable code repository for certain very common use cases.

Diederich 9y ago
> CPAN is incredibly bloody far from a high-quality, stable, or usable code repository for certain very common use cases. Citation needed.