Eh, strict typing makes debugging way, way easier. Saint Grace brought us compilers for a reason. If all you have is assembly, you should start writing one.
this post was submitted on 01 Apr 2025
106 points (88.4% liked)
Programmer Humor
34806 readers
272 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
Ferris smirking You sure?
For NASA, data types don't matter when you're programming Voyager 1 and 45 years later it gets hit by an energy burst causing 3% of the RAM to become unusable, and it's transmitting gibberish. It's awesome they were able to recover it.
When I learned Python I thought that not having a statically typed language was the way to go, but then it just became an issue when I was trying to ensure that everything was at least something like what I was expecting. Going back to statically typed languages even harder with Rust has been a dream. I love it.
Python with type hints and mypy and ruff = <3
Large Python codebase without types = nightmare
I'm too lazy to insert the "look what they need to mimic a fraction of our power" meme here, so.... Please imagine it instead.
I'm switching jobs in a couple of months, and I am SO glad to be leaving a (very well maintained!!) python codebase with type hints and mypy for a rust codebase.
It is just not the same.
Nice! I'd love to use Rust at work, I was a Haskell guy for hobby things, rather recently switched to Rust for that, and I enjoy it a lot. Taking 80% of the good lessons from functional programming while staying performant and practical and just have nice tooling - whoever designed Rust are wise people who know what is important for happy developers.
My job is mainly C++, and if you have seen the bright side of life, it is difficult not to be frustrated by the language and tooling. I think C++ without clang-tidy is almost as horrible as Python without types and linters. Undefined behavior and foot guns everywhere!
Oh yeah rust tooling is insanely good ootb
It's documentation. I'm a strickler to type in python so later when I look at my code and go what does this do it's easier.
juniorest of memes
Fr, though, duck typing in Python is one of my biggest annoyances.
I love duck typing! dynamic typing is my issue...
“Assume it’s a map and treat like a map and then catch the type error if it’s not.” Paraphrased from actual advice by Guido on how you should write Python. Python isn’t a bad language but the philosophy that comes along with it is so fucked.
This is just preferring runtime validation instead of compile time validation.
And relying on runtime validation is a horrific way to write production code
Why though? I've genuinely never had a problem with it. If something is wrong, it was always going to be wrong. Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?
I’ve genuinely never had a problem with it. If something is wrong, it was always going to be wrong.
Have you worked on a production code base with more than a few thousands of lines of code? A bug is always going to be a bug, but 99% of the time it's far harder to answer "how is this bug triggered" than it is to actually fix the bug. How the bug is triggered is extremely important.
Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?
If you don't validate types you can easily run into a situation where you write a value to a variable with the wrong type, and then some later event retrieves that value and tries to act on it and throws an exception. Now you have a stack trace for the event handler, but the actual bug is in the code that set the variable and thus is not in your stack trace. Maybe the stack trace is enough that you can figure out which variable caused the problem, and maybe it's obvious where that variable was set, but that can become very difficult very fast in a moderately complex application. Obviously you should write tests, but tests will never catch every weird thing a program might do especially when a human is involved. When you're working on a moderately large and complex project that needs to have any degree of reliability, catching errors as early as possible is always better.
I worked on OpenStack back in the day: millions of lines of untyped Python.
Let's say you've got an X509 certificate. You know you can probably pull the subject out of it - how? Were I using Java (for instance), the types would guide my IDE and make the whole thing discoverable. The prevalent wisdom at the time was that the repl was your friend. "Simply" instantiate an object in the repl then poke at it a bit.
And it's not just that kind of usability barrier. "Where is this used?" is a fantastic IDE tool for rapid code comprehension. It's essentially impossible to answer for a large Python codebase.
Don't get me wrong: python is still a great go-to tool for glue and handy cli tools. For large software projects, the absence of type enforcement is a major impediment to navigation, comprehension and speed of iteration.
And as for your specific question: typechecked code doesn't get to production with a type error; it won't compile. There's a common phrase, "left-shifting errors". It means catching bugs as early in the development cycle as possible. In terms of things like developer time (and patience), it's far more cost-effective to do so.
👆 This.
nasm? the x86 assembler from the 90s?
let comment: String = String::from(“lol”);
println!(“{}”, comment);
println!("{comment}");
C'mon, it's 2025!
Not inside a main function, won’t pass rust compiler check
Just a snippet from a bigger function.
I was actually tempted to try learning nasm for funsies a year or two ago until I discovered it doesn't support ARM processors 🥲
Assembly languages are always architecture specific. Thats kind of their defining feature. Assembly is readable machine code.
nasm is an assembler though, not a 'languages', that only supports x86/x64. gas for example supports a wide range of architectures so you can write risc-v, arm, x64, etc.
nasmis an assembler though, not a ‘languages’
That's like saying "clang is a compiler though, not a language". It's correct but completely beside the point. Unless you're writing a compiler, "cross platform assembler" is kind of an insane thing to ask for. If want to learn low level programming, pick a platform. If you are trying to write a cross-platform program in assembly, WHY!? Unless you're writing a compiler. But even then, in this day and age using a cross-platform assembler is still kind of an insane way to approach that problem; take a lesson from decades of progress and do what LLVM did: use an intermediate representation.
Are you arguing that assembly languages are not architecture-specific? I don't think that's the typical definition.
Nasm is an assembler, but it also represents a specific assembly language targeting x86 architectures.
Gas is an assembler of a higher order. It can emit code for many architectures, and thus it accepts many different architecture-specific assembly languages.