Isn’t problem solving mostly put things together of what you’ve learned before?
Isn’t problem solving mostly put things together of what you’ve learned before?
I didn’t read everything, but I mostly agree with the author, especially on this point:
While you can definitely abuse exceptions, functional-style error values are not a one-size-fits-all solution.
There are time and place for both. I think exceptions are good for bigger errors. Like database connection errors. Things that shouldn’t happen without any easy backup plan. Those errors might need to be escalated as high as possible where proper action can be made (like resetting the database connection and everything relying on it).
Functional style is great for smaller stuff. Like key not found in hash maps. In many cases there might be good defaults that can be used instead.
It’s a concept of a plan
Haven’t read through this, but this sounds like what C++ is to C. I’m not sure adding more complexity and features to an already complex language is the right way forward. What is needed is a language that cuts down all the burden that has accumulated in C++ over 3 decades.
Something like Zig sounds like the better path forward to me. A completely new language from scratch with cross interoperability to C++. I’m surprised it’s not mentioned even once in the page.
Yes, I think so. The downside with Python comes when refactoring the code. There’s always this double checking if the code is correctly indented after the refactor. Sometimes small mistakes creep in.
It’s really hard to tell when Python code is incorrectly indented. It’s often still valid Python code, but you can’t tell if it’s wrong unless you know the intention of the code.
In order languages it’s always obvious when code is incorrectly indented. There’s no ambiguity.
I don’t like YAML because it’s overly complicated. The specification is like 80 pages long. How the hell did they think that was a good idea?
JSON on the other hand is super simple. It doesn’t do more than it needs to.
Just compare this: https://yaml.org/spec/1.2.2/
With this: https://www.json.org/json-en.html
The entire JSON specification is shorter than just the table of contents of the YAML specification!
Another thing I like about JSON is that you can format it however you want with the whitespace. Want everything on one line? Just write everything on one line!
If data can be represented as a JSON, then there’s generally only one way to represent it in JSON (apart from whitespace). In YAML the same data can be represented in 1000s of different ways. You pick one.
It doesn’t matter, why the present is garbage, it’s garbage and we should address that.
The problem is fixing it without inadvertently breaking for someone else. Changing the default behavior isn’t easy.
There’s probably some critical systems that relies on old outdated practices because that’s the way it worked when it was written 20 years ago. Why should they go back and fix their code when it has worked perfectly fine for the past two decades?
I think the general rule of thumb is: Keep it Simple, Stupid.
Don’t include fields “just in case”. If you don’t have a use for a field right now, then don’t include it. It’s often easier to add fields than removing.
Avoid having fields that can be derived from other fields. Code “UNAUTHORIZED” can be derived from 403. Having both adds confusion. It adds the question whether the code field be something other than “UNAUTHORIZED” when the response is 403.
Just 403 with empty body is fine. Add message in a JSON in case it’s useful for the user. If the user needs more fields in the future, then it’s easy to expand the JSON.
Only from the comment saying it was a duplicate. The question wasn’t even the same and the answer was barely touching my question.
I haven’t asked that much on SO. Often I can find the answer myself. In other cases my question is so niche I don’t know how to formulate it into a good SO question.
One of my questions got closed for being duplicate because it was tangentially related to a different question. I got the answer, but it left me a sour taste.
Steam stats are the only stats available, and they probably correlate pretty well with console stats.
Helldivers 2 is doing really well on Steam despite being a PlayStation game.
Neon is the choice if you want cutting edge plasma versions but don’t want to use a non-LTS version of Ubuntu. I use Neon and I’m overall happy with it.
I’ll revise my opinion when Valve changes to a more overtly predatory model of capitalism
I believe as long they’re not publicly traded )and Gabe is in charge), that’s not a concern.
Being public (or owned by a publicly traded company) tend to bring out these nasty traits. It’s more about finding ways to bring value to shareholders than the customers.
For each steam power there are thousands of similar inventions that never see the light of practical use cases. We just remember those that had significant breakthroughs.
That doesn’t mean cryptocurrencies is like steam power.
The picture only shows one hype cycle. AI has been through multiple hype cycles. Same will happen with quantum computers, once a new major breakthrough is reached.
Quantum computers have already had its hype, so plateau of productivity. It’s just that the plateau is really low.
What’s happening is that support from VC money is drying up. Tech companies have for a long time survived on the promise that they will eventually be much more profitable in the future. It doesn’t matter if it’s not profitable today. They will be in the future.
Now we’re in a period where there’s more pressure on tech companies to be profitable today. That’s why they’re going for such anti consumer behaviors. They want to make more with less.
I’m not sure if there’s a bubble bursting. It could just be a plateau.