this post was submitted on 02 Feb 2024
1029 points (98.5% liked)

Programmer Humor

32710 readers
600 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 91 points 10 months ago* (last edited 10 months ago) (7 children)

I would swap Python with C++. Constantly dealing with stupid runtime errors that could’ve been easily captured during compile time.

Did you forget to rename this one use of the variable at the end of the program? Sucks for you, because I won’t tell you about it until after 30 minutes into the execution.

[–] eager_eagle 47 points 10 months ago* (last edited 10 months ago) (2 children)

you need a linter, bro

when integrated into the editor it'll highlight stupid mistakes as they're typed

I recommend Ruff for real time checks, and pylint if you need a comprehensive analysis.

[–] [email protected] 16 points 10 months ago (2 children)

sure, but thats just outsourcing the problem.

[–] [email protected] 30 points 10 months ago

It's also a solution...

[–] eager_eagle 20 points 10 months ago* (last edited 10 months ago)

As if that's a bad thing... it means you're not locked in with a tool you don't like and the language itself doesn't dictate your workflow.

There's very little benefit and a lot of potential problems in using a single tool for everything.

[–] aidan 1 points 10 months ago

Yea and C++ is the same thing, you just need to enable all the warnings on clang-tidy

[–] [email protected] 20 points 10 months ago (4 children)

My brother. That's why you do unit tests.

[–] [email protected] 30 points 10 months ago (1 children)
[–] eager_eagle 16 points 10 months ago

👆 definitely linting first 👆

finding errors as you type is even better than finding errors at compile time

[–] [email protected] 7 points 10 months ago

But are you even a real programmer if you don’t test in production?

[–] [email protected] 6 points 10 months ago (2 children)

I shouldn’t need to do unit tests for quick one off scripts

[–] c0mbatbag3l 8 points 10 months ago (1 children)

Shouldn't be forgetting for one off scripts either, if that's the logic you want to go with.

The tool exists, either you do it or you don't and end up getting an error until the interpreter hits that line. It's just the nature of being compiled at runtime.

[–] [email protected] 5 points 10 months ago* (last edited 10 months ago) (2 children)

“Ohh, I got all these numbers I want to crunch using numpy or pandas and plot it using matplotlib. Hold on, I just need to write unit tests first.”

[–] [email protected] 2 points 10 months ago

Then maybe use an editor with a decent linter and check the problems tab or just red line markers?? I also have those kind of runtime errors sometimes but I take the blame.

[–] [email protected] 2 points 10 months ago (2 children)

Well. Yeah. That's test-driven development. It's a very good practice.

[–] [email protected] 6 points 10 months ago (1 children)

TDD only works well if the problem is clearly specified before the first line of code has been written, which is rarely the case when I need Python for something.

[–] [email protected] 1 points 10 months ago (1 children)

So which is then? You want a one off script to just quickly crunch some numbers on a problem you still need to understand? Because that is where it is perfectly normal to get some errors and doodle around. That is the entire point of it.

Or you have a concise concept of what you are going to do, and how and why? Because that is what you do, when you program more than a "one off".

Either you go to the store with a shopping list and you work through that list or you go browsing and see what comes up. But don't expect to be as fast and have everything you needed, when you dont write your shopping list at home.

[–] [email protected] 1 points 10 months ago* (last edited 10 months ago) (1 children)

Often I use Python for exploratory purposes. Like, I got a bunch of data, and I want to know if a particular algorithm might work or not. I implement the algorithm, but realize the results don’t look good enough. So I tweak the algorithm, maybe even do major refactoring. Or maybe I realize my visualizations or metrics don’t capture what I need to see. Or maybe I must settle for some compromise?

I iterate on this repeatedly until I find something I’m happy about (or until I give up). Sometimes I end up with something completely different from my initial idea.

TDD won’t help me much here because the end result is unknown. For each iteration of this idea process I might even need to rewrite all the tests because none of them are valid anymore.

[–] [email protected] 1 points 10 months ago

in this process it is just normal to get runtime errors. Your expectation is too high imo.

[–] rambaroo 1 points 10 months ago

TDD is not appropriate for everything or everyone

[–] [email protected] 7 points 10 months ago (2 children)

What kind of quick one off scripts have large complex scopes where variable renames are difficult to track?

Besides, these days Python has great LSPs and typing features that can even surpass the traditional typed langs

[–] [email protected] 2 points 10 months ago (1 children)

Mostly number crunching and data exploration tasks. Just so I can make informed decisions about the data I got. I do this rarely enough so it hasn’t been worth for me to install all these extra third party support wheels.

[–] [email protected] 2 points 10 months ago* (last edited 10 months ago)

Those support wheels are for your own (and apparently systematic) errors...

[–] Blue_Morpho 2 points 10 months ago

It doesn't need to have large complex scopes. I have the brain of a goldfish. I program because it's challenging. It's challenging because I'm bad at it.

[–] scarilog 1 points 10 months ago

What's that?

/s

[–] [email protected] 13 points 10 months ago* (last edited 10 months ago) (1 children)

You can solve this with git:

git gud

Seriously though, writing a monolith of a function and not testing anything until you run it the first time isn't the way to go. Even with a compiler you're only going to catch syntactical and type issues. No compiler in the world is going to tell you you forgot to store your data in the correct variable, although it or a a linter may have helped you realize you weren't using it anywhere else.

[–] [email protected] 6 points 10 months ago (1 children)

Python was typeless. And it was common to reuse variables with different types of content.

So you at some point never knew what actually is within the variable you are using.

Using typing in python solve 95% of your problems of having runtime errors instead of compile errors

[–] Whelks_chance 2 points 10 months ago

Agreed. Mypy pre-commit hooks are very useful if you're starting a fresh project. Adding typing to an existing project which reuses variables with different types... We lost weeks to it.

[–] fidodo 7 points 10 months ago (1 children)

Seriously, in what way does the python interpreter protect you?

[–] [email protected] 1 points 10 months ago

It doesn't. It carries you by having a module for absolutely everything even shooting yourself in the foot.

[–] Trollception 2 points 10 months ago

I guess as a C# guy I've never had to deal with an issue like this. Most of the time the exceptions are pretty easy to diagnose unless it's in the UI or in some async function.

[–] [email protected] 2 points 10 months ago (1 children)

Yeesh. I mean, perl would tell you about that immediately, I'm just saying... :-P

[–] [email protected] 16 points 10 months ago (1 children)

Yeah, but then you have to use perl

[–] [email protected] 14 points 10 months ago* (last edited 10 months ago)

Using perl is not the problem, now trying to read perl code later? That's the challenge! :-P