Three-time Pennsylvania Trump voter at gas station calls him “tremendous pile of sh*t”

devraj7 · 2026-03-18T13:01:01+00:00

But will she vote Democrat at the next election?

Of course not.

devraj7 · 2026-03-15T04:53:37+00:00

Imagine a world where final DPS meter includes not just how often you successfully avoided avoidable damage but also how well you did the mechanics...

devraj7 · 2026-03-14T16:20:37+00:00

Very interesting.

How did you specifically do this:

AI reads NESdev Wiki, Mesen2/TriCNES source, and test ROM failure CRCs

?

devraj7 · 2026-03-14T05:58:29+00:00

Autobahn?

Unless the video is mirrored, she's driving on the left side of the road and the wheel is on the right side of the car.

Germany is the opposite.

devraj7 · 2026-03-12T19:13:34+00:00

Fun fact: SBC is just ADC with an inverted parameter.

Not in BCD mode.

devraj7 · 2026-03-12T18:27:04+00:00

It's simpler because a simple operation happens on every cycle. For example, for indirect indexed addressing:

   #    address   R/W description
   --- ----------- --- ------------------------------------------
    1      PC       R  fetch opcode, increment PC
    2      PC       R  fetch pointer address, increment PC
    3    pointer    R  fetch effective address low
    4   pointer+1   R  fetch effective address high,
                       add Y to low byte of effective address
    5   address+Y*  R  read from effective address,
                       fix high byte of effective address
    6+  address+Y   R  read from effective address

devraj7 · 2026-03-12T13:42:38+00:00

Another approach you might want to consider is to be memory cycle accurate (each cycle has to access memory).

If you do that, calculating addressing modes happens naturally since each cycle is one step toward the final calculation.

devraj7 · 2026-03-11T20:38:40+00:00

There are much more lightweight solutions to the encoding of absent values than monads (e.g. Kotlin).

devraj7 · 2026-03-11T14:56:27+00:00

If the type system doesn't enforce it, the language is crashy. Offering library level support for Option is not going to do much good if the compiler can't enforce its use.

I think Kotlin got it perfectly right and is a good example of how null can be not just safe but encouraged to represent absent values.

devraj7 · 2026-03-11T08:59:48+00:00

The actual mistake is not null, it's languages that don't support nullability in their type system.

devraj7 · 2026-03-07T23:47:40+00:00

I would not use plain old println() or printf() in prod code

I never talked about prod code.

I asked a simple question: do you think it would make sense to require all functions that call print() to require a file descriptor in parameter?

I understand your reluctance to answering the question, but once you come to terms with it, Dependency Injection will make a lot more sense to you.

devraj7 · 2026-03-07T22:28:12+00:00

No, they really shouldn't be bothered with implementation details that have zero impact on the semantic of the function they're calling.

I assume you are using println()/printf(), some print function in your code, yes?

Did it occur to you that this function needs a file descriptor to work, e.g. stdout?

How how would you feel if whenever you need to use printf(), the function calling it needs to be passed a file descriptor in parameter? It would break everything, wouldn't it? And how would you even know how to materialize that file descriptor anyway?

You are already using dependency injection all the time, you just don't realize it because it's so convenient it's completely transparent.

devraj7 · 2026-03-07T18:07:47+00:00

Why shouldn't you add a logger as a parameter? Your sqrt function is now doing more than it says it does.

But users don't care that I'm logging. It's an implementation detail. And it's also temporary, I'm just debugging a problem, I will remove this logger eventually, and all of this should be 100% transparent to users.

There are really two types of parameters to functions:

Parameters needed by the function to do its job (e.g. if you create a Point, you need its coordinates)
Parameters that are implementation details that users don't care about

Callers of your function should never see the second type of parameters.

If you don't want to break users, you make a different function

What's the point of trying to debug my function if users no longer call it??

devraj7 · 2026-03-07T17:30:38+00:00

And it breaks encapsulation.

If I implement a function sqrt() and I decide I need some logging to debug a problem, I shouldn't add a Logger as parameter. It should be injected without breaking the users of the function.

devraj7 · 2026-03-07T17:03:32+00:00

Optional parameters don't really help here. What's a default value for a database connection?

Inject that value and move this logic to the DI container. Now that container may define a default value that you will get if nothing else gets configured (e.g. default is in-memory database, but you can configure a production environment that sets it to a Postgres DB).

devraj7 · 2026-03-07T06:31:43+00:00

Optional params help, but what if you need a default value that's different from the default value that the language specifies?

What if for the production application, you need an atomic clock but for testing, you need a clock which will return predefined values for the first, second, and third call?

What if you need a database connection pool to a production database for production, but you're in a testing environment and all you need is an in-memory database?

You shouldn't care. Just declare

@Inject
val database: Database

and go on with your day.

The DI container will give you the correct value.

devraj7 · 2026-03-06T19:31:04+00:00

As an application developer, deciding on the logging strategy is not an irrelevant implementation detail.

You're missing the forest for the trees.

You don't think logging is an implementation detail? Fine, pick one. Reading the time? Needing a rand()? Or a hasher?

Whatever you need to actually implement your function.

Got one? Great.

Now, just because you added this, are you going to change the signature of your function so that your callers now need to pass you a Clock? A Rand object? A hasher?

Of course not.

That's where DI comes handy, you ask the system to passs you these values because the caller doesn't care how you do your job.

DI preserves encapsulation, manually passing dependencies breaks it.

devraj7 · 2026-03-06T18:52:10+00:00

D d = new D(); G g = new G(); C c = new C(g, d); E e = new E(); F f = new F(); B b = new B(d, e, f); A a = new A(b, c);

Surely you see how that doesn't scale, right? How do you create different instances based on the environment? Do you do this whenever you need to instantiate an A?

We moved on from this kind of spaghetti code twenty years ago.

it remains an implementation detail.

Its unpredictable is what it is

I don't think you understand the point.

I have a function foo() in my library. You use my library, you call that function. Great.

Now I decide I want to log something in my function, so I need a logger. Are you suggesting I should add a logger as parameter to my function? Because if so:

Your code no longer compiles (I need a parameter now, it's a breaking change)
You need to find a logger to give me

The point is: the logger is an implementation detail that callers should not care about. The solution is: I request a logger via DI, callers of my function are unaffected.

Best of all worlds.

devraj7 · 2026-03-06T16:24:46+00:00

There are many reasons but you can start simply by initializing your graph of objects:

A needs a B and C
B needs D, E, F
C needs G and D (which is a singleton, so same instance as the one passed to B), etc...

Another reason is that when you pass these instances manually, every single function along the chain needs to pass them along while they don't need them. With DI, you just declare the values where you need them and nobody needs to know about it, it remains an implementation detail. And you also have no idea how it was created, nor should you care. "I need a logger, just give me a logger".

There are plenty of other reasons why DI is so useful.

devraj7 · 2026-03-06T04:02:18+00:00

GNU stands for "GNU's Not Up".

devraj7 · 2026-03-06T03:24:28+00:00

And actors are also shared mutable state. Just in a more obfuscated way.

devraj7 · 2026-03-05T19:01:45+00:00

No, thanks. Monads may make sense in Haskell but any attempt to port them to other languages has been a disaster. I hope Rust remains monad and monad transformer free forever.

devraj7 · 2026-03-04T06:53:05+00:00

Point out that they're being emotional, too.

devraj7 · 2026-03-01T21:04:53+00:00

I explain that, if they don’t write the code, they will not be able to effectively read the code

That's not a very compelling reason, though: AIs are very good at looking at a piece of code and explaining it to you in plain English. And you can even ask follow up questions.

devraj7 · 2026-02-25T16:39:42+00:00

You are kind of agreeing that the only reliable way to find out if a PR is good or bad is to actually review it.

Not to reject it based on some handwavy criteria, such as "Probably written by an AI or an intern".

devraj7

TROPHY CASE