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.
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.
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.
The great thing about Slack is how easy it is to make automations. I guess this one just reads RSS feeds.
At my work we have automations notifying us about production errors for example.
I have a great uncle. The best uncle. He’s telling I’m the best Pokémon player by the way. He works at Nintendo. It’s a wonderful company I tell you. And do you know what he say? It’s all true!
Imagine doing whatever I want with my free time.
It’s an entertaining video. I watched it to have something in the background while doing chores.
I like to mix between OOP and FP for different levels. OOP is great for higher architectural problems. FP is great for everything under it.
And yes, inheritance was a huge mistake. Just use composition and interfaces instead.
I agree that people shouldn’t have to die over this, but Putin is dedicated to the invasion on Ukraine. He won’t stop just because someone kindly ask him to stop over the phone. He’ll continue until there’s no Ukraine anymore, and then he might also go for Moldova and other former Soviet countries.
Ukraine has to defend themselves for as long as Putin is willing to continue the war.
Go tell Putin and his friends to stop the invasion and hand back all the Ukrainian territory they’ve stolen. It’s easy!
I agree, and I count that as “key information that’s difficult to understand from the code”.
IMO, comments should be used to provide value to the code. If they’re used too much, then readers of the code will more likely stop reading them altogether. They already got what they need from the code itself and the comments usually don’t add much value.
If they’re sparse, then that’s a good indication they’re important and shouldn’t be missed.
I think JSON is more robust than XML by now. Mostly due to its simplicity. There are few reasons why anyone would pick XML over JSON these days.
I think comments are good as a last resort when it’s difficult to communicate the intention of the code with other means.
If I find code that’s hard to understand, I’ll first try to find better variable or function names. Often this is enough.
If it’s still too difficult to understand, I try to restructure the code to better communicate the flow of the code.
If that doesn’t help (or is too difficult), then I might add a comment explaining key information that’s difficult to understand from the code.
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.