Notably, it refers to answers, not the invalidity or duplication of a question.
I think it’s too much to close a question just because a different question happen to have the same answer. There might be a future answer that might apply to one, but not the other.
What’s different between Vscode and other editors like Vim is how easy it is to make it a fully fledged IDE. Usually a notification pops up about analyzers being available, and if you click accept it’s done. Just one click of a button.
With Vim it’s not that easy. You need to install many separate plugins just to make it a fraction of an IDE.
What functionality is Vscode lacking for it to be an IDE?
Where’s NumIcrementorFactory?
Writing maintainable code is an art form. Like most art forms it can mostly only be learned by practice. So if you don’t have much experience maintaining long lived systems, it’s difficult to know what works and what doesn’t. Most universities don’t teach this as well, so it’s mostly something people learn in the industry.
Then I believe there’s also some aspect of pride in writing overly complicated code. It’s the belief that ”other people can’t comprehend my code because they’re not as smart as me”, when it’s actually ”I suck at writing comprehensible code”.
Yeah, computer science is the more about theoretical side of computation and the analysis of algorithms. For example, proving that a certain algorithm is a solution to a problem and has a particular time complexity. That’s more mathematics than practical programming.
I’ve haven’t had a burnout (knocks wood), but the most toxic environment I’ve worked in had tight deadlines, unclear requirements and many last minute changes on features that ultimately didn’t mattered. Combine this with long and tedious release processes and narrow release windows. If a bug slipped through our (not so robust) testing process, it was difficult to fix it.
It felt like the priorities were all wrong. Instead of improving the product for existing customers and improve our release process, it was all about adding pointless features some ”potential buyer” asked for (they never bought the product either way).
Now I work in a much better workplace, thankfully.
It’s just example code to demonstrate the idea of the optimization explained in the article. I also based my code on the code used in the article (and made some major changes to better fit my attempt of explanation).
Basically it’s just an optimization of a double nested for loop. It’s a way to avoid running the inner for loop when it is known there will be no hit.
This is useful when we for example want to find all product orders of customers in a particular country. The way we can do this is to first filter all customers by their country, and then match orders by the remaining customers. The matching step is the double for loop.
Something like this:
for order in orders:
for customer in customers_in_country:
if order.customer_id == customer.id:
…
Many orders won’t match a customer in the above query, so we want to single out these orders before we run the expensive inner for loop. The way they do it is to create a cache using a Bloom filter. I’d recommend looking it up, but it’s a probabilistic cache that’s fast and space efficient, at the cost of letting through some false positives. With this particular use case it’s ok to have some false positives. The worst thing that can happen is that the inner for loop is run more times than necessary.
The final code is something like this:
bloom_filter = create_bloom(customers_in_country)
for order in orders:
if bloom_filter.contains(order.customer_id):
for customer in customers_in_country:
if order.customer_id == customer.id:
…
Edit: this comment probably contain many inaccuracies, as I’ve never done this kind of stuff in practice, so don’t rely too much on it.
I hate when coworkers tell we should do thing in a particular way because it’s ”better”. We try the thing and there’s no measurable difference. Well, it was a good idea in their mind, so it must be an improvement. Therefore, they insist it should be kept, even if it makes the code extra convoluted for no reason at all.
And yes. Profiling is great. Often it is a surprise where most time is spent. Today there’s few excuses not to profile since most IDEs have good enough profiler included.
Nice article. For the optimization related ones there’s a good rule of thumb: it’s not an optimization if you don’t measure an improvement.
That’s how DRY is described in Pragmatic Programmer, where DRY was first coined. They’re clear that just because code look similar, doesn’t necessarily mean it’s the same.
I agree with the first point. Always go for clarity over cleverness.
I somewhat disagree with the second point. Consistency is important. Stick with the same name when possible. But I think mixing camel case and snake case should be avoided. It can make the code less ”greppable” IMO, because now you need to remember which casing was used for each variable.
Kind of agree on the third point. I think flatness should be preferred when possible and when it makes sense. Easier to find the variables with the eyes rather than having to search through nested structures.
From a professional perspective I’d say: don’t rewrite if you’re unsure about it. Rewrite if there’s a particular problem you need to solve and a rewrite is the only way to do it.
For example, you need to make major changes in the tech stack. Like switching from PHP to NodeJS. This is difficult to do without a complete rewrite.
Rewrite for the sake of rewrite is usually a waste of time, and it’s not certain that the code will turn out better in the end. You might end up with a similarly convoluted system either way. And the worst part is: now you have two systems to maintain at the same time.
Likewise, refactor if there’s a particular problem you want to solve. Don’t refactor just for the sake of refactoring. If you don’t have a clear goal, then you’re just scrambling the code around.
From a hobbyist perspective: do whatever you feel like. A complete rewrite can be a good learning experience.
It’s a hyped language because it solves many problems that has persisted with C and C++ - without having to rely on garbage collection.
If anything, it’s underused. Not that I believe everything should be rewritten in Rust. That’s just stupid.
Shadow of the Erdtree would be my pick. Mostly because I haven’t played that many other games from 2024.
And I think it deserves to be nominated even if it’s DLC. The amount of new content is more than most games.
I’m at the point where I think I can engineer anything. But I also know that it takes effort and I ain’t gonna do that unless there’s a paycheck.
Java with Spark.
Although I feel like I’m doing less of data science and more of data processing.
I don’t really know how to describe him. I guess Casey is proof that one can be skilled in programming, but still have a fundamental lack of understanding in software engineering.
Then it should be closed for being a duplicate question. I don’t think it makes sense to close any question for having a duplicate answer.