magic_lobster_party

Drawing hands is hard

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.

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 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 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.

It makes you want to die on a hill

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 was featured in a PlayStation showcase last year. The most notable part of the trailer was a burger. I’m not kidding.

Joseph Anderson has made a similar trolley challenge. It’s a cinematic masterpiece: https://youtu.be/RgqRIFj4Zrk

Turn on a lamp

Right now I’m mostly using the Xbox One controller (on PC). It’s a controller that feels really good to hold. No weird gimmicks like motion control either. I think it’s one of the all time greats.

Runner up is GameCube.

Shit in terms of having no players and being pulled back after just two weeks.

From what I understand, the game itself was alright. It had no major technical or gameplay problems. At least the team of programmers and game designers were competent.

The main issue is that the game was incredibly unappealing, and I believe this can only come from poor leadership.

It’s probably not even the artists fault it turned out this shit. My gut feeling is that the game is victim of incompetent leadership. Indecisiveness on important matters and micro management on stupid things.

It’s also the same incompetent leadership who will get bonuses and promotions after this.

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.