Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Not Your Grandfather’s Perl

stackoverflow.blog

Post reply on HN
Print view View original

221–230 of 257 posts

Re: Not Your Grandfather’s Perl

#221

Post by liveoneggs »

fomine3 wrote: post #165
btilly wrote: post #94

Earlier quoted context omitted.

Due to poor coding practices (eg monkeypatching) and a weaker testing culture (by default Ruby does not run unit tests when installing libraries) I've found Ruby to be substantially less reliable than Perl. However the world has moved on to Python. So I curse every time I again have to look up how subprocess works for what I'd do in Perl with backticks.

TIL (as a light Perl user alternative to awk) CPAN runs test on install. Is there any other language package manager runs tests by default?

that is super dangerous, just like some other dangerous parts of perl where it can run code during the compilation phase

Re: Not Your Grandfather’s Perl

#222

Post by jandrese »

anthk wrote: post #218
jandrese wrote: post #141

Earlier quoted context omitted.

While you can use them, I do not recommend it. The problem is when you want to convert a script into an EXE so not everybody has to install Strawberry Perl. Apparently some viruses are written in Perl because Windows Defender flags any exe you build as a virus and deletes it. Also, changing the application icon doesn't work, so you're always distributing a Camel app. It's a shame too because as you say the Win32 API…

Not a Perl issue, but a Windows Defender one.

True, but people are going to be calling you, not Microsoft, when the app is instantly deleted when they download it. The worst part is that it isn't even consistent. It will be ok for a few months and then end up back on the virus list again.

Re: Not Your Grandfather’s Perl

#223

Post by xyzzy4747 »

I used a lot of Perl at various jobs.

Nowadays I have my own startup and my code is a mixture of JavaScript, TypeScript, and Rust.

Rust is good for anything sufficiently complex that you want to run quickly, have a small footprint, and want to be sure it works, while allowing for easy refactoring due to the strong type safety.

JavaScript is good for anything you want to write quickly and the code quality doesn't matter as much (e.g. test scripts). It's also much easier to write than Perl syntax-wise and has great async support (unlike Perl). Also it has a much larger ecosystem of libraries and easy to use in IDEs like VSCode. Obviously JS/TS can also be used in both the frontend and backend which is another big advantage.

TypeScript is sort of in between - if the JS codebase gets too large it should be written in TS instead. This makes the code less "write-only".

Perl and PHP were pretty good solutions as scripting languages until JS added good async/await support, map/filter/reduce, and destructuring syntax in my opinion. JS probably requires the least lines of code to get a program working.

Re: Not Your Grandfather’s Perl

#224

Post by HankB99 »

petre wrote: post #193
HankB99 wrote: post #75

I've used Perl off and on throughout my career, even working at one job that was pretty much exclusively Perl. I've also used Java and C/C++. I've done a lot of work with embedded systems where C was the order of the day. But back to Perl. I always thought one of the best things about Perl was CPAN. I could nearly always find a module that would accomplish a specific task I needed and then I was just left to write th…

> nearly always find a module that would accomplish a specific task I needed Then you didn't have to write PC/SC smartcard code in Perl. Also most of the MQTT clients are crap, only Net::MQTT::Message is useful but then you have to write the network client yourself and if you also need TLS, good luck, the modules doing that have like 200+ failed tests. CPAN is great but if you need anything out of the ordinary you'll…

That's unfortunate but I suppose a consequence of a less active ecosystem. I don't recall dealing with that back in the day but it doesn't surprise me now, particularly with more recent technologies like MQTT.

I have written MQTT clients in Python and the module support was good. But then I discovered it was easier (for the most part) to use the Mosquitto cli utilities and pipe stuff to/from them. For cases where that was awkward, it was easy enough to write in C and use the PAHO libraries directly.

Re: Not Your Grandfather’s Perl

#225

Post by wruza »

LudwigNagasena wrote: post #216
wruza wrote: post #204

Earlier quoted context omitted.

This is my experience as well. I have a side project in its prototyping state and tried to use typescript in it. The result was exactly what I was afraid of - the first half of a weekend spent on fine-tuning tsconfig and tsserver integration, the second half on type acrobatics and investigating wrong narrowing issues. No code was written that day. I have a decent experience with both typed and untyped languages to se…

I agree with the first part (I generally hate the devops situation with JS, TS, nodejs, modules, etc). But I don't understand the part about type acrobatics. TypeScript's typing is robust to the point of being Turing complete, so you can express things that are generally not expressable in your typical typed language. And if TypeScript cannot pin down your types, it is probably a code smell. But you can revert to "an…

I’ve ran into situations where pretty obvious “if (typeof + condition)” chain over-narrowed a type so that further else-ifs were inferred as “never”. The logic was sound and triple-checked, I only struggled with convincing tsc that it’s okay. Sure, it was my fault somewhere in my types and not in typescript, but the progress doesn’t care which part of a development site fails or spends too much time in research.

unidiomatic js trickery

  type Foo = undefined | false | Unit | Foo[] | FooObject
This was a part of the issue, afaiu. FooObject being “partial” either fell through obvious typeof guards, or removed other essential types from a branch, depending on what I tried. I ~understand why the issue persisted, but had no clear way to tell tsc what I mean there. The perspective to meet a similar issue in a much more complex case feels unpleasant.

While types make intents formal (which is a pro), they require to specify irrelevant edge cases. Dynamic typing serves as “code is law”, and when you meet an edge case in the wild, it’s much easier to explain it than to formalize.

I also remember many cases of prototyping in other typed languages and it never felt “focused on the job” to me there either, even when (or despite?) a type system wasn’t turing-complete.

Also, my best hope for typescript was that it would allow me to create type-only “header files”, which would serve as a source of truth and a sort of auto-validated documentation. It turned out that forwards are not first class citizens in ts, and it was sunday evening already, so I gave up.

Re: Not Your Grandfather’s Perl

#226

Post by wazoox »

gyulai wrote: post #210
wazoox wrote: post #209

Earlier quoted context omitted.

> Thanks for posting the happily ignorant code snippet that I have been waiting for. Thank you from being so civil. IMO displaying a badly encoded string beats crashing on a runtime error most of the time. I'd rather see "hôpital" than "Error 500", if you will. Maybe don't think your personal assumptions carry any validity out of your own choices, preferences, or uses. I imagine the difficulty working with a huge co…

But that's precisely the point: Python 2.5 realized that something was fundamentally broken and the community went through a painful transition process. Transitioning to Python 3 meant getting your house in order where string encodings were concerned. Any python programmer would tell you: Starting a new project in 2022 in Python 2.5 is professional malpractice. But that's what the original post seems to be saying: Th…

> But that's precisely the point: Python 2.5 realized that something was fundamentally broken and the community went through a painful transition process.

It's still not done for many, many projects. "python2" is still installed on 99% of systems I touch. Off the top of my head, the only machine missing it is my laptop, actually.

So your last perl codebase had the choice of not going through this painful transition process. Maybe it's what makes the best sense from a business point-of-view? "Worse is Better", remember, that's why we're running this sloppy Linux everywhere and not the almost-perfect OpenVMS or Genera.

>But without the interpreter helping you out on that front, it'll produce ugly code, and take mental discipline and disciplined code reviewing practices on a team.

"Ugly code" is in the eye of the beholder. For many a python project I'll have to add long series of elif or try/catch to check for the type of some incoming data returned from some API, where it could have been easily managed through duck typing in python 2.7 or Perl. Most programmers won't catch it until the error occurs in production, if the value returned switches types infrequently enough.

> The point that the article is trying to refute, namely that Perl is for dinosaurs, in my mind just absolutely stands.

Try C someday :)

Re: Not Your Grandfather’s Perl

#227

Post by otabdeveloper4 »

gyulai wrote: post #210
wazoox wrote: post #209

Earlier quoted context omitted.

> Thanks for posting the happily ignorant code snippet that I have been waiting for. Thank you from being so civil. IMO displaying a badly encoded string beats crashing on a runtime error most of the time. I'd rather see "hôpital" than "Error 500", if you will. Maybe don't think your personal assumptions carry any validity out of your own choices, preferences, or uses. I imagine the difficulty working with a huge co…

But that's precisely the point: Python 2.5 realized that something was fundamentally broken and the community went through a painful transition process. Transitioning to Python 3 meant getting your house in order where string encodings were concerned. Any python programmer would tell you: Starting a new project in 2022 in Python 2.5 is professional malpractice. But that's what the original post seems to be saying: Th…

> Transitioning to Python 3 meant getting your house in order where string encodings were concerned.

They renamed "string" to "bytes" and "unicode" to "string".

(And still managed to make file and path encoding broken, and added a few bugs in the process.)

No, nothing about Python 3 is "in order". That was just your Stockholm Syndrome speaking.

Re: Not Your Grandfather’s Perl

#228

Post by petre »

HankB99 wrote: post #224
petre wrote: post #193

Earlier quoted context omitted.

> nearly always find a module that would accomplish a specific task I needed Then you didn't have to write PC/SC smartcard code in Perl. Also most of the MQTT clients are crap, only Net::MQTT::Message is useful but then you have to write the network client yourself and if you also need TLS, good luck, the modules doing that have like 200+ failed tests. CPAN is great but if you need anything out of the ordinary you'll…

That's unfortunate but I suppose a consequence of a less active ecosystem. I don't recall dealing with that back in the day but it doesn't surprise me now, particularly with more recent technologies like MQTT. I have written MQTT clients in Python and the module support was good. But then I discovered it was easier (for the most part) to use the Mosquitto cli utilities and pipe stuff to/from them. For cases where tha…

Yes, Python, Ruby and JavaScript have better MQTT libraries. I managed to write an async Perl client using POE (the networking code was already heavily using it, otherwise I wouldn't even pick POE since it's awful and also dead) and Net::MQTT::Message. Piping output into mosquitto_pub/sub was out of the question, since this was no hack but rather a service that streams data into the broker.

I suspect writing it in Ruby with async would also prove problematic, but there are the ruby-mqtt and async-io gems and one would use the MQTT::Packet for formatting messages and Async::IO for the networking code. Still a lot less painful than what I did with POE and Net::MQTT::Message.

MQTT.js is async already, you just import and use it in the browser, Node.js, probably Deno as well. Easy. It took literally five minutes to get the client enpoint working in the browser over WebSockets. One could even do it from the browser console.

Re: Not Your Grandfather’s Perl

#229

Post by uhtred »

gyulai wrote: post #190

So, this is on the stack overflow blog. And Joel Spolsky famously thinks that to rewrite a codebase from scratch is the "single worst strategic mistake that any software company can make" [1]. I wonder if this is how you end up being a Perl user in 2022. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Eh? He's not wrong. for any serious (in production and actually being used by paying customers) software it _would_ be crazy to rewrite a codebase. I can't think of a compelling reason to.

For the record, I became a perl user (for fun!) in 2022 because I was attracted to the text processing capabilities, the awesome documentation, the baked in regex handling, the way it's so integrated into unix culture, the fact that it feels like a nice and natural step up from awk or bash when I want to process text files or work with the filesystem, and also the fact that I just find python so boring.

Oh, also Perl is a very powerful command line tool that can be easily piped into on linux. I don't think python or ruby are as powerful in that regard but I could be wrong.

Re: Not Your Grandfather’s Perl

#230

Post by btilly »

liveoneggs wrote: post #221
fomine3 wrote: post #165

Earlier quoted context omitted.

TIL (as a light Perl user alternative to awk) CPAN runs test on install. Is there any other language package manager runs tests by default?

that is super dangerous, just like some other dangerous parts of perl where it can run code during the compilation phase

A lot of languages allow the running of arbitrary code on install, so it is not particularly dangerous that Perl allowed it.

However you have no idea how many bugs got caught because the test run uncovered platform specific bugs. This is exactly what gave Perl a good name for being portable. Doubly so given that Perl always did this, starting back in the 1980s.

Post reply on HN