Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
Async/await turns the concepts from the [CSP] (https://en.wikipedia.org/wiki/Communicating_sequential_processes) that are useful into an overcomplicated mess in every language that implements it, and golang is a prime example of how clear and intuitive an implementation aligned with CSP can be without requiring arcane typing and language infrastructure that comes with async/await approaches.
If you don't prematurely optimize your code you'll never optimize your code.
I know people are advised against premature optimization because it risks you wasting time on something that ends up unused.
But let's be honest, once you get something into a working state will you ever be afforded the time to go back to it? Even if you are, are you really gonna choose to uproot code and do a refactor on it and potentially everything relying on it?
Rather than waiting until your hacks and workarounds run out and you absolutely have to do a refactor, I would prefer spending more time upfront to make sure it is efficient and flexible before moving on.
The unless keyword is an abomination
x = "I disagree."
y = false
puts x unless y
I miss it when writing python.
My masochistic tendencies brought me back to say:
One reason python is a great language is that most LLMs are particularly good with it
I like local LLMs. I got to try one recently and it felt different using open ones than corporate ones.
This is the only way I would ever use one. Local, open, more ethically trained.
I've talked about it before, but I really hate PDFs. Specifically the things PDFs are used for. If you aren't planning to print something and will only ever look at it on a screen, HTML is better. It's so frustrating when you're going to a website, you know, a thing that serves content in HTML, and then some piece of information is in a PDF.
If you're sharing graphical elements then I prefer pdfs when you know it's final, and you want to make sure people see it how you intended, and you want it to be vector format. Similar thing if the information is some complex format/layout. People can zoom in instead of having their device messing it up.
But I agree on simple contents like documents, tables, and such
A PDF file being "final", displaying the same everywhere, and being reliable is a myth.
I have never worked with a messier file format, and I have seen many PDFs displaying in as many ways as I have applications able to view PDFs.
I just got out of an interview where they pretty much told me they will ask me to vibe coded the tool they're working on. LLMs do not make your code faster, and you are not more productive using it. I will never change my mind. We coded for 70+ years without it. You're gonna end up with some subtle hard to reproduce bugs that are intermittently reproducible, and code that is nearly unmaintainable, and nobody knows what it does or how it works.
Good luck with that.
Object oriented programming is dogshit.
How about overrated instead of dogshit?
The overlap between those circles is not insignificant.
This is gonna make me sound crazy, but always pass functions when possible, and use case statements for how the passed-in functions are applied.
As a simple example, imagine you want to take the average of a set of numbers. Instead of doing sum(numbers)/len(numbers), do:
Quotient_reduce(sum, lambda x,y: x+1, numbers)
then, inside the definition of quotient_reduce,
Def quotient_reduce(accumulate_by, normalize_by, list):
If accumulate_by==sum and normalize_by==(lambda x,y:x+1):
return [some efficient implementation of average]
Else:
Return reduce(accumulate_by, list)/reduce(normalize_by, list)
I know it must look insane, but it generalizes normalization, mean, geometric mean, etc, and on the outside there's no taste of the horrible concrete implementation!
Apologies about formatting, I'm on my phone.
Okay, I do think this makes you sound crazy.
I'm putting my question first before I rant about this cause I think I got way more into this response than is warranted.
What problem does this design of just creating bespoke functions have that your design solves?
def mean(numbers):
return efficient calculation
def normalization(numbers):
return efficient calculation
def geometric_mean(numbers):
return efficient calculation
Rant starts here:
With your design, every time someone wants an average of a set of numbers, you're reimplementing the actual logic. Then if someone forgets the +1 and writes:
quotient_reduce(sum, lambda x,y: x, numbers)
A bug is introduced that's hard to spot in a review, won't give an error, and is hard to write tests for. Turning the lambda to an enum meant to be passed around would solve a some of the accidental bugs, but keeps the interaction with the function more complicated.
I really just don't understand why you wouldn't just write each efficient implementation as it's own function and call it directly.
It has to do with how you decompose problems. In the example I gave, I was trying to point out that arithmetic average, geometric average, and normalization are related problems. Consider applying this technique to something more complicated than averages: pathfinding. You could create a dozen different efficient functions, each with different considerations, but the core of the algorithm will always be the same. You can write pathfind_land(src, dest), pathfind_sea(src, dest), pathfind_air(src,dest), pathfind_sea_and_land(src,dest) etc. but it's obviously better to write it as pathfind(src,dest, is_traversable) and select the most efficient implementation inside the function. It also allows you to use a not-optimized implementation automatically if you haven't made an efficient implementation.
Linux should be forked at a pre-ai date.
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.