5 ms·

> If a bank is still using Cobol, it is interesting and a testament to how a Cobol programmer can still make a good living on it. But if a scientist is using Pe

> If a bank is still using Cobol, it is interesting and a testament to how a Cobol programmer can still make a good living on it. But if a scientist is using Perl to carry out calculations, this is somehow bad? Yes. The negative externalities of doing scientific analyses in Perl are much greater than a bank having a legacy COBOL codebase. Only a handful of engineers within the bank will ever see that COBOL codebase. Science is globally collaborative; many people at many different institutions across the world would have to deal with some idiosyncratic scientist’s decision to write their analysis in Perl. Also, the bank only has a COBOL codebase because it’s reluctant to make major changes to an extremely important system that’s been working flawlessly since the early 60s. There’s absolutely no reason to start a totally brand new project in Perl (or COBOL, for that matter), when far superior alternatives exist.

caslon 5y ago
Perl is shipped in virtually every Linux distribution; it's much closer to standard than, say, Node.
- MontyCarloHall 5y ago
  So is ed. That doesn’t mean it’s a better coding environment than modern IDEs, even though it’s far more “standard.”
  - caslon 5y ago
    Actually, line editors are really nice, and UNIX arguably makes a better IDE than any purpose-specific one.
    - CyberDildonics 5y ago
      To be clear, you program using ed and the command line instead of ever using an IDE? The said programming environment, you said 'line editors are nice'. This is the same nonsense game people play where someone says "that's like taking a ship to cross the ocean instead of a plane" and someone else says "I like taking ships, I want to get fresh air for three weeks of solitude instead arriving the next morning"
      - caslon 5y ago
        I do for every language that isn't Common Lisp! I learned to program on a machine that had a copy of vi that refused to go into visual mode; instead of trying to fight it, I started using ed. Everything about UNIX is oriented toward being a programming environment in itself. There are plenty of developers who just use UNIX as their IDE. Drew DeVault, as an example, is pretty notorious for it. Complexity distracts and makes efficiency impossible. Modern IDEs are nothing but complexity. UNIX-as-IDE simplifies.
        deleted 5y ago
        [deleted]
        thesnide 5y ago
        Confirms that the brain is incredibly plastic. It can learn to compensate for a missing tool, arm, eye, ... And after a while it feels just natural.
        caslon 5y ago
        UNIX has all of the tools, and unlike IDEs, it allows you to seamlessly add them on. UNIX is more "cybernetic enhancement" to the IDE's "prosthetic limb." ed is actually really useful if you're wanting to rapidly iterate on a program. There's a reason Ken Thompson advocated for it up to his retirement (which was very recently, mind).
        anthk 5y ago
        - ed/nvi - bc|dc/perl/little of C - Gnuplot - entr + make Amazing performance with very little usage of resources.
- pklausler 5y ago
  Or Fortran, ironically.
  - caslon 5y ago
    This is mostly because of the compiler situation. Intel forbids redistribution of theirs, and GNU's isn't up to snuff, which continues to handicap the language.
- fmakunbound 5y ago
  This is a big plus compared to Python. I dread installing Python for some project that needs it. Is it wheel, pip, pip3? pip3.7, apt install pip, poetry? Maybe pyenv? Good god what goes in my .bashrc? What in my PATH?
  - anthk 5y ago
    Also, on Perl: Install cpanminus and then install local::lib. cpanm local::lib cat >> ~/.profile << EOF eval $(perl -I ~/perl5/lib/perl5/ -Mlocal::lib) EOF done.
    - aduitsis 5y ago
      Please take a look at Carton too.
nanis 5y ago
> idiosyncratic scientist’s decision to write their analysis in Perl. In my experience, looking at "scientist" produced code, the programming language matters very little. It is not hard to produce something completely inscrutable and non-replicable in Python and R the same way it's been done for ages using SAS, Stata, MatLab etc. I still see people rolling out their regression computations using matrix inversion and calculating averages as `sum(x)/n`. I really like PDL when I can use it. I have had problems building it from source on Windows in the past, but it is actually a very well thought out library. Also worth mentioning, you can get a lot of mileage out of GSL[1]. [1]: https://www.gnu.org/software/gsl/ https://www.gnu.org/software/gsl/
- MontyCarloHall 5y ago
  > It is not hard to produce something completely inscrutable and non-replicable in Python and R the same way it's been done for ages using SAS, Stata, MatLab etc. It’s possible to write inscrutable code in any language, but some languages sure make it easier. Syntax issues aside, the main advantage of Julia/Python/R (the latter’s syntax might even be worse than Perl’s) for scientific computing is their ecosystems. A language for a particular use case is only as good as the packages available for that use case. The scientific package ecosystems for Ju/Py/R are far richer than that of Perl, simply because their userbases are much larger. Thus, a scientist using Perl would likely be forced to roll a lot of their own functions, which makes the code idiosyncratic and more likely to contain bugs. (To use one of your examples, people might implement OLS regression by manually computing the hat matrix because no stats package exists for the language they’re using. Now imagine their language lacks something more complicated, like a robust MCMC sampler package à la PyMC3 or STAN, and they have to roll that themselves. Yikes.) And that’s not even getting into the value of the languages for interactive scientific computing, which is how most of it gets done these days. For instance, there’s no official Jupyter notebook support for Perl (although unofficial plugins exist, they don’t support inline graphics/dataframes/other widgets), and the REPLs for Julia/Python/R are much more modern and fully-featured than PDL2. BTW, I agree the GSL is great for building standalone tools, but it’s totally irrelevant for any interactive work.
  - 5y ago
worik 5y ago
"The negative externalities of doing scientific analyses in Perl" What do you mean?
- MontyCarloHall 5y ago
  I mean that someone using Perl for scientific computing makes it harder for others to collaborate on the project, which in turn makes the project less scientifically valuable. This is due to two main reasons. For one, Perl’s incredible syntactical flexibility makes it easy to write “clever” one liners that are hard to comprehend. Speaking from experience, scientists tend to be the sort of people who value “clever” code over “clean” code. Secondly, the Perl package ecosystem for numerical/scientific methods just isn’t as fully featured as the Julia/Python/R ecosystems. This leads to individuals having to reimplement methods themselves, which leads to idiosyncrasies and likely bugs. For instance, I see no way to generate Wishart random variables (or RVs from other distributions beyond the common ones) in PDL. Julia, Python (via SciPy), and R all have full featured support for many different distributions beyond the common ones. A Perl user would thus have to implement this themselves. Someone else reading their code would have to both familiarize themselves with the custom function’s syntax (as opposed to immediately recognizing the standardized scipy.stats.wishart, which behaves like any other scipy probability distribution class) and likely check for any bugs, since a standard package is far more likely to be correct than some random one-off function. I’ve had the unfortunate experience of working with someone who refused to use off-the-shelf libraries for numerical methods, and unsurprisingly their code was not only hard to read (since there was no standardization) but also full of bugs.
  - pvaldes 5y ago
    > Someone using Perl for scientific computing makes it harder for others to collaborate on the project Just to the other people that never have the ambition, desire or toke the time to develop new valuable skills. This is not a bad thing necessarily. Those people are time sinks. In any case you can take the decision to document or not your code in any language. "; # this line does that" is not hard to write. And different science teams collaborate, but also compete for money. So everybody doing the same can lead to "the more dishonest takes all" and kills all the other teams. Sometimes is useful to protect yourself from the people trying to backstab you and steal your best tools. Tools that toke you decades to develop and polish. Not ALL is freely shared in science. And yes, my Perl scripts were a triple headache to write, but still work flawlessly after all this years. Perl is just a tool to do something, and you should never use one (and the same) tool for everything unless your goal is to be a mediocre scientist sucking from other people's efforts all the time.

caslon 5y ago

Perl is shipped in virtually every Linux distribution; it's much closer to standard than, say, Node.

MontyCarloHall 5y ago
So is ed. That doesn’t mean it’s a better coding environment than modern IDEs, even though it’s far more “standard.”
- caslon 5y ago
  Actually, line editors are really nice, and UNIX arguably makes a better IDE than any purpose-specific one.
  - CyberDildonics 5y ago
    To be clear, you program using ed and the command line instead of ever using an IDE? The said programming environment, you said 'line editors are nice'. This is the same nonsense game people play where someone says "that's like taking a ship to cross the ocean instead of a plane" and someone else says "I like taking ships, I want to get fresh air for three weeks of solitude instead arriving the next morning"
    - caslon 5y ago
      I do for every language that isn't Common Lisp! I learned to program on a machine that had a copy of vi that refused to go into visual mode; instead of trying to fight it, I started using ed. Everything about UNIX is oriented toward being a programming environment in itself. There are plenty of developers who just use UNIX as their IDE. Drew DeVault, as an example, is pretty notorious for it. Complexity distracts and makes efficiency impossible. Modern IDEs are nothing but complexity. UNIX-as-IDE simplifies.
      - deleted 5y ago
        [deleted]
      - thesnide 5y ago
        Confirms that the brain is incredibly plastic. It can learn to compensate for a missing tool, arm, eye, ... And after a while it feels just natural.
        caslon 5y ago
        UNIX has all of the tools, and unlike IDEs, it allows you to seamlessly add them on. UNIX is more "cybernetic enhancement" to the IDE's "prosthetic limb." ed is actually really useful if you're wanting to rapidly iterate on a program. There's a reason Ken Thompson advocated for it up to his retirement (which was very recently, mind).
        anthk 5y ago
        - ed/nvi - bc|dc/perl/little of C - Gnuplot - entr + make Amazing performance with very little usage of resources.
pklausler 5y ago
Or Fortran, ironically.
- caslon 5y ago
  This is mostly because of the compiler situation. Intel forbids redistribution of theirs, and GNU's isn't up to snuff, which continues to handicap the language.
fmakunbound 5y ago
This is a big plus compared to Python. I dread installing Python for some project that needs it. Is it wheel, pip, pip3? pip3.7, apt install pip, poetry? Maybe pyenv? Good god what goes in my .bashrc? What in my PATH?
- anthk 5y ago
  Also, on Perl: Install cpanminus and then install local::lib. cpanm local::lib cat >> ~/.profile << EOF eval $(perl -I ~/perl5/lib/perl5/ -Mlocal::lib) EOF done.
  - aduitsis 5y ago
    Please take a look at Carton too.

nanis 5y ago

> idiosyncratic scientist’s decision to write their analysis in Perl. In my experience, looking at "scientist" produced code, the programming language matters very little. It is not hard to produce something completely inscrutable and non-replicable in Python and R the same way it's been done for ages using SAS, Stata, MatLab etc. I still see people rolling out their regression computations using matrix inversion and calculating averages as `sum(x)/n`. I really like PDL when I can use it. I have had problems building it from source on Windows in the past, but it is actually a very well thought out library. Also worth mentioning, you can get a lot of mileage out of GSL[1]. [1]: https://www.gnu.org/software/gsl/ https://www.gnu.org/software/gsl/

MontyCarloHall 5y ago
> It is not hard to produce something completely inscrutable and non-replicable in Python and R the same way it's been done for ages using SAS, Stata, MatLab etc. It’s possible to write inscrutable code in any language, but some languages sure make it easier. Syntax issues aside, the main advantage of Julia/Python/R (the latter’s syntax might even be worse than Perl’s) for scientific computing is their ecosystems. A language for a particular use case is only as good as the packages available for that use case. The scientific package ecosystems for Ju/Py/R are far richer than that of Perl, simply because their userbases are much larger. Thus, a scientist using Perl would likely be forced to roll a lot of their own functions, which makes the code idiosyncratic and more likely to contain bugs. (To use one of your examples, people might implement OLS regression by manually computing the hat matrix because no stats package exists for the language they’re using. Now imagine their language lacks something more complicated, like a robust MCMC sampler package à la PyMC3 or STAN, and they have to roll that themselves. Yikes.) And that’s not even getting into the value of the languages for interactive scientific computing, which is how most of it gets done these days. For instance, there’s no official Jupyter notebook support for Perl (although unofficial plugins exist, they don’t support inline graphics/dataframes/other widgets), and the REPLs for Julia/Python/R are much more modern and fully-featured than PDL2. BTW, I agree the GSL is great for building standalone tools, but it’s totally irrelevant for any interactive work.
- 5y ago

worik 5y ago

"The negative externalities of doing scientific analyses in Perl" What do you mean?

MontyCarloHall 5y ago
I mean that someone using Perl for scientific computing makes it harder for others to collaborate on the project, which in turn makes the project less scientifically valuable. This is due to two main reasons. For one, Perl’s incredible syntactical flexibility makes it easy to write “clever” one liners that are hard to comprehend. Speaking from experience, scientists tend to be the sort of people who value “clever” code over “clean” code. Secondly, the Perl package ecosystem for numerical/scientific methods just isn’t as fully featured as the Julia/Python/R ecosystems. This leads to individuals having to reimplement methods themselves, which leads to idiosyncrasies and likely bugs. For instance, I see no way to generate Wishart random variables (or RVs from other distributions beyond the common ones) in PDL. Julia, Python (via SciPy), and R all have full featured support for many different distributions beyond the common ones. A Perl user would thus have to implement this themselves. Someone else reading their code would have to both familiarize themselves with the custom function’s syntax (as opposed to immediately recognizing the standardized scipy.stats.wishart, which behaves like any other scipy probability distribution class) and likely check for any bugs, since a standard package is far more likely to be correct than some random one-off function. I’ve had the unfortunate experience of working with someone who refused to use off-the-shelf libraries for numerical methods, and unsurprisingly their code was not only hard to read (since there was no standardization) but also full of bugs.
- pvaldes 5y ago
  > Someone using Perl for scientific computing makes it harder for others to collaborate on the project Just to the other people that never have the ambition, desire or toke the time to develop new valuable skills. This is not a bad thing necessarily. Those people are time sinks. In any case you can take the decision to document or not your code in any language. "; # this line does that" is not hard to write. And different science teams collaborate, but also compete for money. So everybody doing the same can lead to "the more dishonest takes all" and kills all the other teams. Sometimes is useful to protect yourself from the people trying to backstab you and steal your best tools. Tools that toke you decades to develop and polish. Not ALL is freely shared in science. And yes, my Perl scripts were a triple headache to write, but still work flawlessly after all this years. Perl is just a tool to do something, and you should never use one (and the same) tool for everything unless your goal is to be a mediocre scientist sucking from other people's efforts all the time.