The new Naked Gun, actually. The idea falls in to the same FUCK NO camp as every other god damn nostalgia grab from Hollywood in recent years. The plot is stupid, even compared to some of the old Leslie Nielsen movies that worked the plot developments in to jokes a bit better and naturally had more of their own humor than references … buuuuut, the execution still had me straight up laughing out loud at quite a lot of it.
What is that? Chicken noodle soup with gelatin crafted in to a jello dog/thing?
lol such a child. You probably get bullied with that hilariously shitty of an attitude. Pathetic.
I know it’s not about Christmas, but kindly fuck off with Christmas in October even as a reference… God Christmas sucks ass. Invading every other holiday because it’s the most commercialized and profitable for dumbass capitalists…
lol Me telling you why you’re being made fun of outside of your shitty attitude isn’t snark. Just further proving that lack of reading comprehension…
Unit tests have never been fun to me beyond the satisfaction of having good coverage. I mean good coverage that exercizes and asserts behavior, not just line/branch coverage!
Maaaybe the closest I’ve come to TDD was in JavaScript, not even TypeScript. Something about strict languages needing to be described a bit more explicitly seems to make code more tightly coupled in the general sense. Somehow, even beyond the literal code changes necessary. On one hand, that’s great because it’s harder to dig your own pits to fall in (see every reason TypeScript is even popular or ‘necessary’), but on the other, code definitely ends up less… portable? On a version to version change level within the same product, even.
In order to “properly” do TDD, I feel like I should only have to minimally tweak the tests once they’re defined, or else it’s not really “driving” the development. It kinda’ always ended up that I’d write the tests in tandem, which just doubled or worse the amount of work when an edge case or implementation detail popped up that wasn’t already factored in. Then I’d have to address the functional issue and then go fix/add a test(s) for it. The process just ended up being slower than finishing the impl first, and THEN writing the actual tests, because the little tweaks along the way simply have less code to cascade in to.
It’s really task-dependent on whether it pays off, IMO. If it’s new code/functionality, it really takes well broken down issues so you’re not writing multiple classes/features/concerns at once in order for TDD to feel remotely worth it. Which then has tradeoffs with extra task grooming time anyways. If it’s existing code you have to enhance or fix a bug of? TDD can pay off in droves when the tests keep you from breaking other things or missing side effects, and makes it very clear when you’re done with the task at hand to reduce the desire to refactor ugly code and whatnot. lol
IMO, how much trouble it is, is more about how testable the code is in general and whether you already have good test coverage, more than having tests defined first.
Not sure where writing tests fits on the problem solving spectrum. At least it helps as described for updates and bug fixes: you don’t have to focus on or check on nearly as much stuff to get a task done well. Writing new stuff, it’s always been more about how well structured and testable the design is than having the tests implemented first.
I suspect it ultimately comes down to the application’s complexity over all. When tasks and code can stay simple, like with proper microservices arch or similar simplifying practices, I suspect it could be easy enough to TDD “properly” in any language and maybe even enjoy it. Sadly, I haven’t had the pleasure of working on a clean project like that outside of pet projects where I’m too inconsistent on my work ethic to judge it. lol
Ohh executing examples and whatnot in the comments/docs is a good idea. I know a few frameworks/doc tools try that at least on a component level, but of course when you involve whole extra tools, it’s sometimes a big learning curve cost even if the boilerplate/setup is trivial. That would be neat to have functional comment examples and formal unit tests at a language level.
I think I tend to agree on bad comments. There has definitely been a few memorable occasions where I’ve axed multiple paragraphs of comments simply because they were old and a touch nonsensical after years of updates.
Yea I cheated a bit by bringing in API documentation, but then in my defense a lot of that I also write, or at least write the formal comments that end up compiled in to those docs. lol It’s also still a bit true when digging in to libraries to contribute, though. If the inline comments suck, most will probably not contribute unless it really legible code. lol
To me, there is almost always something worth documenting about a function, unless it’s boilerplate or just obvious data handling, of course. Though even then, if it’s at an app or library boundary, there is almost certainly some ‘why’ and limitations/etc to describe. After all, even basic CRUD at an API/app boundary will have multiple known modes of failure that have to be described somewhere.
Like I said. Reading comprehension. Lacking.
Snark just makes you sound 12.
Read the comic again. One day you’ll understand that you’re defending the butt of the joke. You’re the, “leave Britney alone” person of this post.
Even if you were correct (and you’re not), you’d still be wrong.
Yea he sounds like he wants to be contrarian on TDD if he’s thinking that equals no design. lol
IMO, thinks like factory constructors are just typical over-engineering things. I’ve yet to meet a programmer (that actually became one as a career) that learns a new pattern and doesn’t implement it somewhere it doesn’t need to be. (hell, I’d say that’s the entirety of the existence of blockchain and NFTs… outside of the money-grubbers/launderers, of course)
Why do you think TDD is so bad in Java and what makes it so easy in Ruby? My experience is mostly from Java, and there, TDD seems easy enough for a strongly typed language? At least when leveraging modern libraries/frameworks and coding practices so the pieces are actually accessible. I’m sure doing TDD with raw Java would suck ass for the patterns that don’t jive with IOC-adjacent design. lol
It sounds more like you straight up disagree with Ousterhout?
I agree with you, though. Inaccurate comments are tentamount to bad documentation, and nobody says bad documentation is remotely good for something…
In fact, that’s sometimes the biggest difference between different libraries/frameworks, and the one with better documentation almost always wins.
IME, single-line comments that deserve to stay are ones warning about unobvious context, like why a certain function call has funky parameter prep, or why a var is being treated differently, or even just a healthy reminder that ‘this’ math statement does actually need all those type casts.
Of course, if I find myself simply stating only what the code is doing, I’ll look for things to restructure/rename (because why the F did I feel the need to write a comment if it’s straight forward?), but they’re useful far more often than certain types (“code should be self-documenting!”) like to admit. Hell, some code ends up looking funky solely because it’s using a weird language feature or working around a language-specific issue and those usually-obvious things still sometimes deserve comments!
Just like how simple, elegant psudo-code can explode in to a mess when dealing with the real-world edge cases, sometimes simple code does deserve an explanation. Give the dev enough context to connect the simple conceptual idea to the complex state during the code’s execution.
Only time I remove such comments is when they’re referring to something that is already well documented somewhere. Like if it’s a method call with some funky parameter requirements, but they’re already thoroughly explained in the method’s own comments/docs, then that might get removed. Still though, if it’s funky enough that a coworker might have similar refactoring thoughts should they come through on their own, I might leave/add a comment about why the crappy statement(s) remain as they are (with reference to any docs) so the coworker doesn’t have to literally re-search why the code wasn’t refactored last time through. Promise it’s not 'cause I’m lazy!!
Your reading comprehension is severely lacking.
They’re commenting about how the name is bad and how that X is ruined in the public zeitgeist. Yes, X the display framework has been around for decades, but Random Joe 28507 still doesn’t know what that X is.
The result in the end should be an organized series of events, a process, that takes or produces data. The data can be anything from a single number in a calculator, to a text message, to your entire social profile. The process can be anything from basic math, to advanced math (i.e. machine learning, rendering, cryptography, etc), to performing simple operations on that data like shuffling that data somewhere else.
These processes are stacked on top of each other and utilized with basic logic (if, else, loops, scope, etc) and combined together with a myriad of programming patterns and algorithms, to produce higher and higher orders of complexity, that eventually solve a real-world problem.
The result is an ever increasing complexity of useful tools and processes that can either solve specific problems directly or at least provide discovery for other useful tools and processes that might.
It’s translating higher order problems from something understandable at the task level all the way down until a piece of specialized rock that only understands on and off can eventually spit out a meaningful result.
ok ok electrical engineers get the claim for the last sentence, and plenty of the real-world complexity, but hopefully it illustrates my point that ‘nothing’ is … just wrong. We cannot discount the absolute importance of abstract things. Everything from “imaginary” numbers to completely abstract things like philosophy have real- world consequences. If programming produces nothing, then MOST jobs that aren’t manual labor produce nothing.