magic_lobster_party @ magic_lobster_party @kbin.social

Posts

2

Comments

580

Joined

2 yr. ago

It was the same for GTA5 a decade ago or so. Same with GTA4. The trailer for a new GTA is a big thing.

Seems like they’ve fixed it now, but there was a time when they had proof of stake without withdrawal functionality

Haven’t checked it in a while, but is it still impossible to withdraw staked coins?

That’s basically it, except everything is darn expensive.

0.999… means infinitely repeating 9s. There’s no more 9 to add that hasn’t already been added. If you can add another 9, then it’s not infinitely repeating.

The difference is zero, so they’re equal.

One way to tell if two numbers are equal is to show there’s no real number between them. Try to formulate a number that’s between 0.999… and 1. You can’t do that.

Fusion and Dread are also real good stuff if you want more. Although they’re both more story focused and action oriented than Super, they’re still great in their own ways.

Holy moly! Squaresoft really bet hard on FF7

My job title is actually a data scientist. I’ve seen few pieces of code that couldn’t have been made more explainable by just using a more clear and concise naming of variables and functions. Don’t try to be so overly clever with your single letter variables and Greek alphabet. Just explain what it is with a good name.

If I’m lucky I get to write a cool new algorithm once per quarter or so. Usually it’s just a standard algorithm that has an explanation in a Wikipedia page, so I just give the name of the algorithm and a link to that page.

Most of the time we’re just doing basic data processing building on the preexisting solutions. These generally don’t need comments.

The worst code is usually when someone has tried to be overly clever (including myself). Often a simple and straightforward solution had been overlooked. Simple solutions are easier to understand and maintain. Anyone can just look at the code and get a sense of what’s going on without any comments. In many cases a simple solution has also more accurate and faster to compute.

In my work, having explainable results far outweighs anything else, and you don’t get that by writing difficult to understand code.

If you’re working in embedded I guess you can probably make an inline function or a macro so it’s taken care of at compile time.

One example was when a method's documentation said that it would throw a certain exception. Turns out it was actually throwing a different exception (deep into the code), so no wonder why we never captured it in time.

It’s probably a little bit slower, but there are other things more worth to optimize than to shave off a few microseconds from a 15 minute delay.

I think most people fail to understand what code smell really is. They think code smell means bad code. A code smell is actually an indication that something else might be bad with the code. The code smell itself might not be bad.

So when a code smell appears, it means you should identify the reason it exists and potentially fix it. In this case the bad code is a buggy external library, which is difficult for you to fix. Therefore, leaving the “code smell” is the best course of action.

Your manager was in the wrong and you were right to write comments.

Bill writes spaghetti code.

Bill is not smart.

Don’t be like Bill.

I can feel it coming in the air tonight, oh Lord

I’ve seen it. That’s why I’m opposed to comments unless they really bring value (like explaining the why instead of the what).

So you implement A type of algorithms every day in your work?

Or just name the variable delaySeconds if you really want to store it as an int. Bonus is that every use of the variable perfectly communicates what it is.

Chances are that the comments quickly turn out of date and become incorrect. Misleading comments is worse than no comments.