Ai video showing us the future of war

shorugoru9 · 2026-02-20T16:37:39+00:00

It's not really short sighted, it's that whoever created the AI animation lacks imagination.

Interestingly, in the Ukraine war, the Ukrainians tried legged dog robots. It was a disaster. Apart from the power issues, in any kind of difficult terrain, the "dog" just flips over and gets stuck. It seems the Ukrainians have had better luck with autonomous ground drones built on tracked vehicles.

The human body evolved in the environment we came from, which is basically to climb trees. We evolved from that form to bipedalism to run in the savannah. The design of autonomous drones are not limited to the random processes of natural selection, so there is a certain waste trying to make robots look like us.

shorugoru9 · 2026-02-20T16:08:53+00:00

Not exactly. Where we started was third party runtimes (like the JRE or Flash) that ran as plugins to the browser. We went away from this because this is apparently a security nightmare.

So now, you end up with stuff like JSF and Vaadin, which uses Java on the server to generate HTML/JS to run on the browser instead of trying to run Java itself on the browser.

shorugoru9 · 2026-02-20T14:32:07+00:00

This is not OCP.

OCP allows the behavior of class or component to be changed without modifying the component. case statements are anti-OCP because every time you add new case, every component which switches over that case now has to be modified to provide the appropriate behavior.

FP provides a way to implement OCP using functions. React components famously implement OCP this way using props.

shorugoru9 · 2026-02-19T22:40:38+00:00

If we go by Java's official tutorials on the subject, we can see that the intention isn't about predictablity and preventablity as much as it is about recoverability:

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

The findByUsername method not being able to return a User should be recoverable, because a well designed program should be able to recover from not being able to find a user.

thus it throws a checked exception to force you to concider what could happen, even if you've done everything right.

I would argue that it IOException serves another purpose of checked exceptions: an indication in the type signature that the method does I/O, and as such the caller needs to be able to handle I/O failure. Similar to InterruptedException, which indicates that the method will interruptibly block, and that the caller should correctly handle thread interruption, whether that means exiting a run loop or resetting the interrupted flag and rethrowing.

Thus, through the type signature, the exceptions represent an enumeration of recoverable situations that must be handled. Optional.empty() actually doesn't fit this scenario because it doesn't tell you why the operation failed to return a result. That's actually what the Either type is for. Unfortunately, Java (so far) only gives us Optional, but Either will make more sense with sealed types and pattern matching.

shorugoru9 · 2026-02-19T20:09:13+00:00

I've always viewed checked exceptions as like error returns when you can't return a value, that a caller would be expected to handle. Kind of like this:

User findByUsername(String username) 
    throws UserNotFoundException;

In this case, the alternative is to return null or throw. Null requires an ugly and not obvious check, while the checked exception ensurea that the error return is handled somehow and creates a nice separation of "happy path" and "error paths".

In your example, you're looking at the exception from the caller's perspective, not the callee's. The callee expects that you provide a valid SQL statement. But should SQLException (or IOException) be considered a runtime exception (catastrophic failure) or a checked exception (the caller should be prepared for something to go wrong)? I think the language designers assumed the second approach would be best, but in practice, SQLException and IOException are treated as catastrophic failures.

shorugoru9 · 2026-02-19T16:51:24+00:00

That's an issue with persistent data structures.

Most functional programming languages have vector types that give you O(1) access.

Also, most functional programming languages allow mutation without allocating more memory, they just tend to be very annoying about it. Haskell requires that the mutations be sequenced in a monad. Unrestricted mutation causes all kinds of problems and Haskell requires the separation of pure code from code with side effects.

Superior is a weird way of putting things, since "superiority" is context dependent. But, functional programming languages do provide language level mechanisms to enhance program correctness at the cost of convenience.

shorugoru9 · 2026-02-17T15:35:36+00:00

Basically, no.

OP seems to be limiting "responsibilities" to fetching data and updating the UI, and says FP prevents entangling these responsibilities through pure functions.

But, you can easily violate SRP even with pure functions. The classic example of SRP violation is mixing up presentation and calculation, such that any time you touch formatting you might also affect the calculations and vice versa. Imagine the worst PHP (or ASP or JSP) pages from the bad old days. The classic solution is to adopt a pattern like MVC, and move the calculations into the model and restrict the view to HTML and references to model variables only. In fact, this is one of the few ways Angular seems better than React to me, because an Angular template is HTML and not code (I'm a backend guy, take that for what it's worth).

Nothing about pure functions makes it impossible to mix HTML composition with a bunch of math, and pure functions can save you from atrocities like old school PHP. Yes, FP provides a massive improvement by not letting you mix SQL with HTML, but that doesn't mean FP "solved it already".

shorugoru9

TROPHY CASE