Remix.run Logo
7thaccount 8 hours ago

It's been discussed before, but Python just seemed more straightforward to a lot of people. It had a built-in object oriented model as well when that was the rage instead of the weak default one and dozen modules on CPAN to do object oriented programming. There was generally one way to do something and that was easier to learn than TIMTOWTDI.

BeetleB 5 hours ago | parent | next [-]

Yes, the answer is Python, Python, Python.

There's a reason the Zen of Python includes this:

"There should be one-- and preferably only one --obvious way to do it."

It also came with batteries included, which really lowered the learning curve.

Perl was well known for being a pain to read months after you wrote it. Most Python code in those days was readable by people who did not even know Python.

When I started my job in 2010, I took a class at work on Perl. I had done some Perl years before and had grown sick of it, but I thought I was just doing it "wrong" so I thought the course would tell me how to code in Perl "properly".

Nope - I'd been doing it "right" all along. I just hated the language. At the end of the course, I told the instructor (a graybeard) that he should just use Python, and that one day I'd teach the Python course and he should attend. He scoffed at the notion: "Languages will come and go, but Perl will always prevail!"

I never did teach that course, but I bumped into him about 7 years later. He had completely (and willingly) abandoned Perl for Python, and was a big Python advocate.

liveoneggs 5 hours ago | parent [-]

if only python stuck to any of those ideals

BeetleB 4 hours ago | parent [-]

Python has grown some warts, but I can still read code I wrote 20 years ago.

People who don't know Python will have a harder time reading modern Python, though.

ok123456 2 hours ago | parent | prev | next [-]

TIMTOWTDI broke down with trying to do OOP in Perl. You could either bless a hash, or use a meta-object framework (moose?). You could end up with hierarchies of different types of objects with their own behavior.

cestith 8 hours ago | parent | prev [-]

One of Python’s killer features is how easy it is to find a Python library wrapping some native code library written in C or Fortran. Those used to be notoriously difficult to write for Perl.

autarch 8 hours ago | parent [-]

I was writing a comment asking if it was really easier. Then I took a look at Cython. Yes, this looks easier than Perl's XS, which I have some experience with! There are ways to do something similar in Perl these days, notably https://metacpan.org/pod/FFI::Platypus. But these are relatively new (starting in the 2010s) compared to the history of Perl, and Cython goes back to the early 2000s.

cestith 8 hours ago | parent [-]

Somewhere in the continuum from SWIG through XS and on to Platypus there are also the Inline modules these days. They allow one to put inline sections of other languages into Perl code the way many language tools used to allow one to inline assembly into C or Pascal code.

There are some of these modules for other languages than those listed here, a lot of them as high level as Perl (including Raku and even another Perl system for some reason).

https://metacpan.org/dist/Inline-C/view/lib/Inline/C.pod

https://metacpan.org/dist/Inline-ASM/view/ASM.pod

https://metacpan.org/dist/Inline-CPP/view/lib/Inline/CPP.pod

https://metacpan.org/dist/Inline-CPR/view/CPR.pod

https://metacpan.org/pod/Inline::Lua

https://metacpan.org/dist/Inline-Java/view/lib/Inline/Java.p...

https://metacpan.org/pod/Inline::Guile

https://metacpan.org/dist/Inline-SLang/view/SLang.pod

There are even tools to convert from Inline to XS for C and C++.

https://metacpan.org/dist/InlineX-CPP2XS/view/CPP2XS-Cookboo...

https://metacpan.org/pod/InlineX::XS

autarch 8 hours ago | parent [-]

True. For whatever reason, these never displaced XS. For wrapping C libraries in particular, it's not clear to me how much Inline::C helps with this. You're still stuck using a lot of Perl C API calls, AFAICT, which I think is the biggest challenge of using XS (I still have nightmares from trying to figure out where and when to add `sv2mortal` in my XS code).

cestith 6 hours ago | parent [-]

I haven’t done nearly as much of this as you.

One or two calls into a library with a simple C interface isn’t that bad with Inline. You just use Inline to handle the Perl to C to Perl part, and actually do the interfacing in the inline C. It’s a lot more mess if you’re doing complex things and bringing complex data structures back to Perl, or having Perl make a lot of intermediate decisions and doing a lot of round trips. So if you use Perl to get the data ready to pass in, pass it in, do all the work in C that you need the library for, then pass the results back to Perl once it’s not terrible.

I’ve tried not to get into XS, so I couldn’t really compare.

Using Inline::C with your own C code in places where Perl is too much overhead is certainly easier than wrapping a complex existing library with a lot of interactions across the boundary.

FFI::Platypus or something like it really is the way of the future though for existing C calling convention libraries in other languages.