This meme was written by a novice that does not yet know true pain. An error that takes fifteen minutes to find! In your own code! Ha, you young whipper snapper... just wait until you have to debug an unforeseen edge case in a library... especially if it's compiled. And once you've seen that, once you've known that horror, come and talk to me about DLL hell.
Unless you're working with installers and, probably, in C++ it's unlikely you'll ever meet this Cthonic horror. Zalgo? Tony the Pony comes? You have met that friendly demon of development? They are but the apprentice... DLL hell is a span of time measured in days.
... Alternatively talk to me about trying to track down an extra newline at the end of a PHP file, that (against all advice) has a closing tag, that causes some output to be sent preventing you from sending headers to the client. There's no error detection for that and PHP is an interpreted language... you just need to check files manually!
Not really programming but I once had an issue that lasted for months like that:
I'm working with a software specific to our industry that generate quotes, sales order and production orders.
For quotes and sales order a PDF can be created and archived in the right folder automatically, or you can use the windows "Print to pdf" printer to do that manually which take closes to a minute for the sales person to create the right folder, with the right name and put the PDF in there with the order number.
The automatic PDF creation fail to include our logo each time and I battled for months with the software company that was telling me that everything is working fine.
Until I looked in the metadata of the PDF the company was sending us, few of the PDFs they were sending is did not have any logo and were created by their software, some had their logo and were created with an external PDF printer.
After I realized they had the same problem internally but were lying about it I just took a day to create a python script running as a service on the server that automatically add the logo on the PDF created and that was it.
Well, what most of us do... manage to reproduce it by chance one out of twenty attempts and then remove any evidence that you managed to trigger it and mark the ticket "unable to reproduce". Bury the ticket by removing any good tags or keywords and hope it's at least three months until anyone else reports the error so you can repeat the dance.
Clang won’t tell you if you’re missing a return statement, even with all warnings on and will just let it crash during runtime. Static analysis won’t save you from all stupid mistakes.
Static analysis won't save you from all of them, but they will definitely save you from the great majority of the ones ProgrammerHumor seems to get worked up about.
I still see people sharing ancient memes about pouring over code for hours looking for mismatched curly braces, missing semicolons, and greek question marks. These and the bulk of minor syntax problems like them should all be complete non-issues with modern tooling.
It's on the company computer, but I have a backup from earlier today that seems to have the same code.
bool load_metadata() {
uint8_t marker_field = EEPROM.read(0);
// Write to ROM if marker has not been set
if (marker_field != MARKER) {
metadata = {
0,
};
EEPROM.put(1, metadata);
EEPROM.update(0, MARKER);
}
else {
EEPROM.get(1, metadata);
}
}
I have to admit, my experience with C++ is rather limited, last Monday was the first time in my life that I used a C++ compiler. I had some issues getting it to work with Visual Studio, so I ended up using VS Code WSL with clang 😅.
Does this compile with -Wall -Werror? (might not be an option if your dependencies’ headers contain warnings)
Looks like it may be embedded code for a SoC or similar. The only things I can think of is that the tool chain you’re using maybe non-standard… or you’re invoking the dreaded Undefined Behaviour somewhere :(
I didn’t use -Werror but no warning about it showed up either. The project uses a semi-custom toolchain for a microcontroller, but I’m not using it to compile this code. I have another file with an entrypoint which tests some classes to be used by the microcontroller. The EEPROM in the code example is actually a macro for a class I’ve written that emulates the EEPROM library by writing and reading to a file on disk.
It’s a bit of a mess but this dual toolchain setup seemed easier than emulating the board and peripherals in it’s entirety. I might have to retry that though using Wokwi.
That's nerve wracking. But you know what's worse? Finding code that shouldn't work, not being able to figure out why it works, and having to leave it in production because of you "fix" it, the whole damned thing will come fluttering down like a house of cards in a slight breeze.
There is actually an approach for this. Leave the cursed code in, but implement it again in the same file, from scratch, without looking at the cursed code. You'll either unthinkingly fix the combination of conditions that led to bad code being correct, or you'll realize why that was what you needed the whole time.
More often than not you'll actually learn that the code is never really ran and it just looks like it does something, while the real code runs somewhere entirely else.
Time to delivery is important. Moving quickly withing a language and frameworks that prioritise speed over safety gets a product out the door is important when testing whether a business idea holds merit. Once you're established with a better scope of the project you should be rewriting this in a static language.
Dynamically typed interpreted languages should never be used for long term support imo
Why make fun of it though? If you make typing and being checker-clean mandatory on a Python project, you get most of the benefits of static typing. The biggest hole is if the libraries you're using aren't properly type annotated. Perhaps I'd feel differently if the meat of my projects was the use of badly or un-typed packages, but thankfully it isn't.
I would rather have a statically typed language with equivalent clarity, ease of use and extensive libraries, but the benefits of Python along with comprehensive, enforced type annotation are strong. Proper thread handling could be good, but since that forces you towards avoiding monolithic executables, and using asyncio (which is a delight to use), it's almost a benefit.
Idunno, Ruby was my first language and the other day I was trying to write a one-file script to wrangle some CSV data and even that got irritating. What does this function need? What does it return? Who the fuck knows! Is it even a function? Run it and find out, loser
And I’ve got reasonably popular projects in ruby, I’m not a beginner.
Yeah I completely agree with you, but sometimes there are other things that jankier languages allow you to do. Say in python, you can do direct property assignment. This is gonna be annoying for someone later to figure out why their object has suddely changed, and without getters and setters, you'll have a harder time picking apart what's going on. The benefit though is that it's very quick to just tack on a property onto some global object and then have that read elsewhere down the road.
It sucks, and you will curse yourself later, like you don't even know what type it is, or maybe it's just null, however it did allow you to ship a project. Maybe that bodge solution is indicative of needing a complete overhaul on how you structure your project, but until you get to that point where you've scoped out what the final idea looks like, it might not be time for static typing and good code design.
I also think that static typing and such makes you move a lot slower when making changes. I love rust to bits, but maintaining an old project is like wading through treacle. I only jump towards using it now once I've got a really great understanding of all the needs of the system, and have the time to really think about the problem in its entirety. Maybe you suddenly need a mutable self in somewhere that you didn't before, perhaps that means going and refactoring a whole load of traits that were designed without mutability (for good reason).
If I'm stuck on something for more than a few hours, I ask one of the more junior developers on my team if they have any ideas. Sometimes, a new perspective helps a lot!
You should switch to Rust. Through massively impressive feats of compiler engineering and a phenomenal amount of novel syntax constructs that make Rust the hardest language for existing programmers to learn, the rustc team has successfully managed to move this agony from after the program compiles to before.
Then when it's a job, you can replace that with weeks. But instead of a silly syntax error, it's a slow memory leak that nobody seems to have noticed for years, but that now forces you to restart your service every day at the very least. And we just spent an afternoon, six people, looking at it and only making it worse.
I spent 4 hours today trying to figure out why a calculation to get a percentage (in decimal) was always returning exactly 1 no matter what parameters I tried passing to it.
Turns out I'd forgotten to cast the ints being provided to decimal, even though I've had to do that so many times before.
I'm not a sharp man
"Okay, everything looks good, time to run it"
Code fails
"What? Let me try again…"
Code fails
"What the fuck, where's the issue???"
Checks syntax error
"GOD DAMN IT TELL ME WHERE THE FUCKING ISSUE IS YOU PIECE OF SHIT"
Hopelessly tries to fuck around with the code and find the error
"PLEASE PLEASE JUST WORK WHY WON'T YOU WORK-"
Notices obvious error that I should have noticed like 15 minutes ago
"Oh. I'm a fucking idiot."
Code works now
"I have gained nothing from this experience and I will do it again"
The thing is, you don't make syntax mistakes on purpose. Especially if you know a language extremely well, a syntax error will happen at random, you won't notice it (if you did, you would have fixed it), and it therefore becomes invisible to you.
Part of your brain "knows" there's no error, because you know the language extremely well, and because if you had made an error, you would have fixed it.
This leads to acute, irrational frustration. It's very human.
There's not really a solution, just smoke more weed and take your eyes off the screen occasionally.
Hey at least they didn't have to trace a bug in their core framework. Only to find it is both in the issue tracker and 10 years old, and there is no offical fix. So you have to make a hacky patch yourself
I've had this experience in other languages, but never python. Find the missing semicolon and getting a cryptic error message is a very common programming experience.
The reason I never had this problem in python is that by the time I learned it, I was already a fairly experienced developer, and I used better tooling from the get go. This kind of error is reallllllly hard to make in a modern IDE using a linter and formatter.
That suggests to me that this is more likely a fairly language agnostic experience. It might even bias people against the languages they learn first.
I mean, I guess, it depends on your perspective. Some folks work in garbage/proprietary languages all day and would be very glad to have Python-levels of compiler help. Others work in JS/TS and do have similar nonsense to deal with as in Python.
But lots of languages, e.g. JVM languages, Rust etc., don't struggle with semicolons and the like.
And they don't have to compile at runtime, so they can easily outclass Python for more complex error reporting, which is at least my experience.
Personally, I have pretty much only had the experience of "tell me where the error is" in Python and TS.
As someone who has taught people a variety of languages. No. This happens regardless of what language you choose. It's just a universal programmer experience to get frustrated at your work
This sounds like they did not or could not explicitly compile it. Pretty much all popular languages are compiled. JS isn't, but people are less likely to say that they 'run' that one. Ruby isn't, but it's not as popular as Python.
Well, and my preferred version of "everything looks good" is "everything compiles", which with a strict enough language does also make failure during the first run much less likely.
I'm also not saying that these aspects are unique to Python.
The language failing to tell you where the issue is also happens in JS/TS, C/C++ and I'm going to presume Ruby, too.
Python is just again rather popular and some of these choices don't make sense with my first hunch.
Honestly man it just sounds like you have struggled with dynamic languages and by extension prefer static (compiled) ones. Which is totally fine you don't have to like everything. But I do think you're missing the real issue with "everything looks good." It's a lack of experience with the tool. It doesn't matter if you're using something as strict as Rust or dynamic as Lisp. "Everything looks good," is always bad. You should know "this is how this works," which is just not something a newbie can handle when they still don't know the difference between pass-by-reference and pass-by-value (or that those words even exist!)
This meme was written by a novice that does not yet know true pain. An error that takes fifteen minutes to find! In your own code! Ha, you young whipper snapper... just wait until you have to debug an unforeseen edge case in a library... especially if it's compiled. And once you've seen that, once you've known that horror, come and talk to me about DLL hell.
Unless you're working with installers and, probably, in C++ it's unlikely you'll ever meet this Cthonic horror. Zalgo? Tony the Pony comes? You have met that friendly demon of development? They are but the apprentice... DLL hell is a span of time measured in days.
... Alternatively talk to me about trying to track down an extra newline at the end of a PHP file, that (against all advice) has a closing tag, that causes some output to be sent preventing you from sending headers to the client. There's no error detection for that and PHP is an interpreted language... you just need to check files manually!
Not really programming but I once had an issue that lasted for months like that: I'm working with a software specific to our industry that generate quotes, sales order and production orders.
For quotes and sales order a PDF can be created and archived in the right folder automatically, or you can use the windows "Print to pdf" printer to do that manually which take closes to a minute for the sales person to create the right folder, with the right name and put the PDF in there with the order number.
The automatic PDF creation fail to include our logo each time and I battled for months with the software company that was telling me that everything is working fine.
Until I looked in the metadata of the PDF the company was sending us, few of the PDFs they were sending is did not have any logo and were created by their software, some had their logo and were created with an external PDF printer.
After I realized they had the same problem internally but were lying about it I just took a day to create a python script running as a service on the server that automatically add the logo on the PDF created and that was it.
Hey now, lots of us still...
I see what you did there.
For anyone reading along who has not experienced DLL hell, don't believe this account on face value.
xmunk is clearly understating the horrors, as a kindness, to protect you from what we went through.
It's 2023. If you're not using an IDE or a highly extensible text editor with simple static analysis features, I really don't know what to tell you.
I had to read it repeatedly and check if it really said "syntax error". What will those people do if they encounter their first race condition?
Well, what most of us do... manage to reproduce it by chance one out of twenty attempts and then remove any evidence that you managed to trigger it and mark the ticket "unable to reproduce". Bury the ticket by removing any good tags or keywords and hope it's at least three months until anyone else reports the error so you can repeat the dance.
I see myself in this comment, and it makes me uncomfortable. Lol.
They insert sleep(1) and print statements. No shit. I had to fix this in two projects. One was a complete rewrite.
Reading this made me nausesous. I feel your pain.
Clang won’t tell you if you’re missing a return statement, even with all warnings on and will just let it crash during runtime. Static analysis won’t save you from all stupid mistakes.
Static analysis won't save you from all of them, but they will definitely save you from the great majority of the ones ProgrammerHumor seems to get worked up about.
I still see people sharing ancient memes about pouring over code for hours looking for mismatched curly braces, missing semicolons, and greek question marks. These and the bulk of minor syntax problems like them should all be complete non-issues with modern tooling.
clangdshould have warned you about this before you even considered compiling.Thanks, I’ve tried it and it works a lot better than the built in intelli-sense.
Is this C++? Have you got some code examples?
I’ve been writing C++ for 20+ years and the last compiler I encountered this with was Borland’s. In the late 90s.
It's on the company computer, but I have a backup from earlier today that seems to have the same code.
I have to admit, my experience with C++ is rather limited, last Monday was the first time in my life that I used a C++ compiler. I had some issues getting it to work with Visual Studio, so I ended up using VS Code WSL with clang 😅.
Does this compile with
-Wall -Werror? (might not be an option if your dependencies’ headers contain warnings)Looks like it may be embedded code for a SoC or similar. The only things I can think of is that the tool chain you’re using maybe non-standard… or you’re invoking the dreaded Undefined Behaviour somewhere :(
I didn’t use
-Werrorbut no warning about it showed up either. The project uses a semi-custom toolchain for a microcontroller, but I’m not using it to compile this code. I have another file with an entrypoint which tests some classes to be used by the microcontroller. The EEPROM in the code example is actually a macro for a class I’ve written that emulates the EEPROM library by writing and reading to a file on disk.It’s a bit of a mess but this dual toolchain setup seemed easier than emulating the board and peripherals in it’s entirety. I might have to retry that though using Wokwi.
Read your errors fully, kids
That's nerve wracking. But you know what's worse? Finding code that shouldn't work, not being able to figure out why it works, and having to leave it in production because of you "fix" it, the whole damned thing will come fluttering down like a house of cards in a slight breeze.
There is actually an approach for this. Leave the cursed code in, but implement it again in the same file, from scratch, without looking at the cursed code. You'll either unthinkingly fix the combination of conditions that led to bad code being correct, or you'll realize why that was what you needed the whole time.
More often than not you'll actually learn that the code is never really ran and it just looks like it does something, while the real code runs somewhere entirely else.
thank you so much
Dynamically typed/interpreted language?
I've never understood why so many languages insist on a feature that causes such a obtuse and tedious programming experience.
Python is great, until you don't remember a function call, and can't guess using your LSP to tell you. :/
Time to delivery is important. Moving quickly withing a language and frameworks that prioritise speed over safety gets a product out the door is important when testing whether a business idea holds merit. Once you're established with a better scope of the project you should be rewriting this in a static language.
Dynamically typed interpreted languages should never be used for long term support imo
Or bolt MyPy to it, right?
Edit: Wow. Somebody out there has no sense of humor about their bolt-on type solution.
Hey its better than nothing? Haha
If performance isn't an issue, I'd take it over nothing for long term support
Yeah. I live to make fun of MyPy - or rather of Python for needing MyPy, but it's "good enough" in many situations.
Why make fun of it though? If you make typing and being checker-clean mandatory on a Python project, you get most of the benefits of static typing. The biggest hole is if the libraries you're using aren't properly type annotated. Perhaps I'd feel differently if the meat of my projects was the use of badly or un-typed packages, but thankfully it isn't.
I would rather have a statically typed language with equivalent clarity, ease of use and extensive libraries, but the benefits of Python along with comprehensive, enforced type annotation are strong. Proper thread handling could be good, but since that forces you towards avoiding monolithic executables, and using asyncio (which is a delight to use), it's almost a benefit.
That's a good point. I do love options.
I'll still jest a little at Pythons expense until a type system is natively available.
Having the option of not using types is great.
Having to go discover how to do basic typing in a 3rd party library is not great.
I adore Python, though - Right down to it's painful Logging modules.
Idunno, Ruby was my first language and the other day I was trying to write a one-file script to wrangle some CSV data and even that got irritating. What does this function need? What does it return? Who the fuck knows! Is it even a function? Run it and find out, loser
And I’ve got reasonably popular projects in ruby, I’m not a beginner.
Yeah I completely agree with you, but sometimes there are other things that jankier languages allow you to do. Say in python, you can do direct property assignment. This is gonna be annoying for someone later to figure out why their object has suddely changed, and without getters and setters, you'll have a harder time picking apart what's going on. The benefit though is that it's very quick to just tack on a property onto some global object and then have that read elsewhere down the road.
It sucks, and you will curse yourself later, like you don't even know what type it is, or maybe it's just null, however it did allow you to ship a project. Maybe that bodge solution is indicative of needing a complete overhaul on how you structure your project, but until you get to that point where you've scoped out what the final idea looks like, it might not be time for static typing and good code design.
I also think that static typing and such makes you move a lot slower when making changes. I love rust to bits, but maintaining an old project is like wading through treacle. I only jump towards using it now once I've got a really great understanding of all the needs of the system, and have the time to really think about the problem in its entirety. Maybe you suddenly need a mutable self in somewhere that you didn't before, perhaps that means going and refactoring a whole load of traits that were designed without mutability (for good reason).
As someone with 20+ years coding experience, this only gets worse as you get more experienced.
Yes. I tell my mentees this all the time.
Decades ago, as a new developer, I expected to stop getting stuck like this.
Instead I get stuck, like this, on really interesting problems with really valuable solutions.
So that was a fun surprise, I guess. Lol.
I was stuck on a problem for six months, and after figuring that out I banged it out in an afternoon. If anything you get stuck for even longer
If I'm stuck on something for more than a few hours, I ask one of the more junior developers on my team if they have any ideas. Sometimes, a new perspective helps a lot!
Unfortunately it was for a personal project and nobody else understands the system so, haha
You should switch to Rust. Through massively impressive feats of compiler engineering and a phenomenal amount of novel syntax constructs that make Rust the hardest language for existing programmers to learn, the rustc team has successfully managed to move this agony from after the program compiles to before.
This is clearly an improvement.
There are way too many Notepad enthusiasts out there.
Whichever vendor or framework puts that on a shirt will get free advertising from me.
This is why linting and static typing are mandatory
Then when it's a job, you can replace that with weeks. But instead of a silly syntax error, it's a slow memory leak that nobody seems to have noticed for years, but that now forces you to restart your service every day at the very least. And we just spent an afternoon, six people, looking at it and only making it worse.
Don't you love programming? I sure do!
I spent 4 hours today trying to figure out why a calculation to get a percentage (in decimal) was always returning exactly 1 no matter what parameters I tried passing to it. Turns out I'd forgotten to cast the ints being provided to decimal, even though I've had to do that so many times before. I'm not a sharp man
Write smaller units. Test those units. Save time.
Me and my cs prof i'm TA'ing for trying to debug two swapped lines for an hour yesterday be like
Image Transcription:
number-1-haxorus-fan
[In large text]
The coding experience:
"Okay, everything looks good, time to run it"
Code fails
"What? Let me try again…"
Code fails
"What the fuck, where's the issue???"
Checks syntax error
"GOD DAMN IT TELL ME WHERE THE FUCKING ISSUE IS YOU PIECE OF SHIT"
Hopelessly tries to fuck around with the code and find the error
"PLEASE PLEASE JUST WORK WHY WON'T YOU WORK-"
Notices obvious error that I should have noticed like 15 minutes ago
"Oh. I'm a fucking idiot."
Code works now
"I have gained nothing from this experience and I will do it again"
#coding #coding pain #python #coding hell
#this is from painfully personal experience
#but replace 15 minutes with a fucking hour
57 notes
15 minutes.. rookie numbers
I've spent more time wondering if I farted and forgot or if it was the guy in the cube next door.
The thing is, you don't make syntax mistakes on purpose. Especially if you know a language extremely well, a syntax error will happen at random, you won't notice it (if you did, you would have fixed it), and it therefore becomes invisible to you.
Part of your brain "knows" there's no error, because you know the language extremely well, and because if you had made an error, you would have fixed it.
This leads to acute, irrational frustration. It's very human.
There's not really a solution, just smoke more weed and take your eyes off the screen occasionally.
There are solutions, just use a LSP or read carefully compiler/interpreter errors or run your code through a linter
Or skip the weed a few times and with money saved buy some JetBrains IDE.
Hey at least they didn't have to trace a bug in their core framework. Only to find it is both in the issue tracker and 10 years old, and there is no offical fix. So you have to make a hacky patch yourself
I've learned that in these scenarios, show it to somebody else. They'll see the stupid mistake you made within seconds.
Just use a debugger.
I mean, it's not unlikely for a programming beginner to write Python, but I certainly had a hunch this was Python before reading to the end.
So, yeah, this is at least partially the Python experience, not generally the programming experience...
I've had this experience in other languages, but never python. Find the missing semicolon and getting a cryptic error message is a very common programming experience.
The reason I never had this problem in python is that by the time I learned it, I was already a fairly experienced developer, and I used better tooling from the get go. This kind of error is reallllllly hard to make in a modern IDE using a linter and formatter.
That suggests to me that this is more likely a fairly language agnostic experience. It might even bias people against the languages they learn first.
I mean, I guess, it depends on your perspective. Some folks work in garbage/proprietary languages all day and would be very glad to have Python-levels of compiler help. Others work in JS/TS and do have similar nonsense to deal with as in Python.
But lots of languages, e.g. JVM languages, Rust etc., don't struggle with semicolons and the like.
And they don't have to compile at runtime, so they can easily outclass Python for more complex error reporting, which is at least my experience.
Personally, I have pretty much only had the experience of "tell me where the error is" in Python and TS.
I can suggest using pylint, it can find a lot of the syntax errors.
As someone who has taught people a variety of languages. No. This happens regardless of what language you choose. It's just a universal programmer experience to get frustrated at your work
I am not saying that you don't get frustrated at your work in other languages. I'm saying this particular frustration is characteristic.
What issue is that you think is unique to python?
Well, I'm not just talking about issues.
This sounds like they did not or could not explicitly compile it. Pretty much all popular languages are compiled. JS isn't, but people are less likely to say that they 'run' that one. Ruby isn't, but it's not as popular as Python.
Well, and my preferred version of "everything looks good" is "everything compiles", which with a strict enough language does also make failure during the first run much less likely.
I'm also not saying that these aspects are unique to Python.
The language failing to tell you where the issue is also happens in JS/TS, C/C++ and I'm going to presume Ruby, too.
Python is just again rather popular and some of these choices don't make sense with my first hunch.
Honestly man it just sounds like you have struggled with dynamic languages and by extension prefer static (compiled) ones. Which is totally fine you don't have to like everything. But I do think you're missing the real issue with "everything looks good." It's a lack of experience with the tool. It doesn't matter if you're using something as strict as Rust or dynamic as Lisp. "Everything looks good," is always bad. You should know "this is how this works," which is just not something a newbie can handle when they still don't know the difference between pass-by-reference and pass-by-value (or that those words even exist!)