7 ms·
I can see in the page that last PDL release was on February, okay. Probably the presence of activity indicates that there are people using PDL, and more than th
by aduitsis 5y ago
I can see in the page that last PDL release was on February, okay. Probably the presence of activity indicates that there are people using PDL, and more than that, maintaining it. Since PDL existed for many years, I would speculate that these people presumably didn't jump into PDL yesterday. There can very well be large codebases using it for a long time.
All the comments suggesting that this somehow shouldn't be and that people should move away from PDL, are depressing in the way that, in a split second, years of effort and thousands lines of code that are probably doing good work are dismissed just like that.
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?
- MontyCarloHall 5y ago> 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 agoPerl is shipped in virtually every Linux distribution; it's much closer to standard than, say, Node.
- MontyCarloHall 5y agoSo is ed. That doesn’t mean it’s a better coding environment than modern IDEs, even though it’s far more “standard.”
- caslon 5y agoActually, line editors are really nice, and UNIX arguably makes a better IDE than any purpose-specific one.
- CyberDildonics 5y agoTo 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 agoI 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 agoConfirms 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.
- pklausler 5y agoOr Fortran, ironically.
- caslon 5y agoThis 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 agoThis 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?
- 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 agoI 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.
- stabbles 5y agoIt's unlikely to perform well, so it may not be the right tool for the job.
- natch 5y agoCan't speak to this library but in general Perl stands out as being extremely performant, if that is the goalpost you want to go with.
- pvaldes 5y agoPDL was created to improve the perl performance when working with n-dimensional matrixes so should be even better than plain perl
- deleted 5y ago[deleted]
- ajsnigrutin 5y agoThis is the sentiment I've been seeing online, especially here. 1/3 of the posts here are "<old tool that already exists in a stable, mature codebase> in {rust|go|whatevernewlanguagecomesnextweek} released v0.0.1" Perl is a great language, that does it's job for many, many things, especially with CPAN, and it has been doing so for years. You can buy a 20yo book on perl, and 99.99% of the example code from that book still works, and same goes for projects from that era (which cannot be said for python, where developers and distro mainanters seem to enjoy removing usable, mature projects, just because they're written for python2.7 and incompatible with 3+). If I have to write a script once, that I can forget about, and just expect it to run for years, perl will always be my first choice.
- ocschwar 5y agoAccording to Google, a one off I wrote in Perl in 1998 is still in use at the lab I wrote it in.
- anthk 5y ago>99.99% of the example code Orelly's Perl books from the CD bookshelf still work. Just declare a variable with "my =" in front of it (just once), and everything will work as usual: old: $num = 3; print $num; new: my $num = 3; print $num;
- ajsnigrutin 5y agoIt works without "my" too :) $ perl $num = 3; print $num; 3 (perl v5.32.1, without "use strict" of course)
- anthk 5y agoAh,TIL. As I always used use strict; use warnings; as something like muscle memory, I didn't know this.
- b2gills 5y agoOne of the things that `use strict` does is enable `use strict "vars"`. use strict; no strict qw(vars); $foo = $bar; That's part of the reason `use strict` is recommended. --- The other major reason is `"refs"`, which disable symbolic refs. Honestly this is *THE* main reason I recommend `use strict`. Symbolic refs are how you did arrays of arrays prior to Perl5. (Among other uses.) use 4.0; @a = 'b','c'; @b = (1, 2); @c = (3, 4); print $a[1]->[1], "\n"; # 4 That can be a security risk if an attacker can insert or change strings in `@a`. It isn't (generally) needed anymore of course. use 5.0; my @a = ( \[1,2], \[3,4] ); print $a[1]->[1], "\n"; # 4 (The only reason `@b` and `@c` existed was to symbolically reference them.)
- ocschwar 5y agoI loved using Perl for projects in the early days of the Web. For anything even remotely expressive or artistic, Perl was the way to go. But if you want to communicate scientific insight, using the write-only language is something I have to maintain my doubts. But, if Inline::Python works as well as the comments above indicate, then I might be tempted again. Number crunching in Python, pretty pictures and presentation in Perl.. Hmm.
- worik 5y agoHow is Perl write only and Python not? I am biased. I love Perl and hate Python. Makes me feel very old....
- R0b0t1 5y agoDon't worry, I think Perl is good. I like the freedom you get when writing it. It's especially good at tasks that shell is just not quite expressive enough for. I used it heavily in a sysadmin job and it was way easier than writing ansible scripts. The only thing holding me back is if I want to use ${library} I probably can't do so from Perl.
- TurboHaskal 5y agoWhat can I say, Perlphobia is real.
- lmm 5y ago> 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. No it isn't. It's a testament to how backward that bank is. You'll see upvoted contrary takes here, sure, but that's because middlebrow contrarianism is a good way to get upvoted on HN.