It took me way too long to get this..

Oh yes my brain also automatically assumed 24 goes over to 0

Luckily unit tests can quickly catch this :D

Haha that's some mindfuck right there

@yowhatthefuck Really? That's a bit fucked up

@yowhatthefuck If it's a special type only dealing with time, then fair enough (although a bit weird), but if it's a numeric comparison, it's a true mindfuck indeed.

@yowhatthefuck the && should prevent that.

hour = 22

22 > 21 = true
22 < 5 = false

true && false = false

The if statement can never be true.

|| makes more sense... ;)

@yowhatthefuck It's not a valid check because the && should be ||.

@yowhatthefuck Yup what @kamen said. If there is a special hour type, sure. But then comparing that with an integer like that? Feels weird

Always assume you got the logical operators wrong if you didn't triple check them one and two times.

It gets easier to catch it the more you see/use it.

Way too obfuscated method of commenting out a code block. Not readable at all. Just use a plain "if (false) {" next time.

@Oktokolo At least that's what IDEs would say

Human brains are quite bad at boolean logic.

I recently dove into the mess that is package/dependency management... Fun weekend project: Write a semver-compatible SAT solver.

https://en.wikipedia.org/wiki/...

what is happening here?

@bittersweet @wiki Boolean satisfiability problem

@ZeldaFan69-2 The Boolean satisfiability problem is a kind of problem in math-based logic. In propositional logic, a formula is satisfiable if the variables it uses can be given values so that it becomes true. If however for a given formula, no values exist so that the formula becomes true and the formula will always be false no matter what values its variables have it is called "unsatisfiable".

https://simple.wikipedia.org/wiki/...

@ZeldaFan69-2

And how that relates to package management — imagine you need picresizer v2.1, and csvparser v3.6.

picresizer can work with a package called logmessages v1.*, while csvparser needs logmessages v4.*

That means both can't use the same subdependency... And worse: in some cases the package manager might need to check hundreds of packages with each other to verify that there is no subdependency which all dependencies can live with.

There are multiple ways to solve this.

1. SAT solving. This is what PHP's composer does, and when comparing version ranges, time complexity is exponential. For small projects determining whether there are conflicts can be done in reasonable time, and there are heuristics ("guesses") to speed things up... But for large projects with many packages, composer can use gigabytes of RAM and hours of time.

2. Fuck it, everyone gets their own subpackages. You just build a very fat tree, in which multiple versions of packages can live. This is what JS NPM does, hence the 10 Terabyte npm_modules directory. Another issue is that if one package publicly returns a LogMessage object in format v4, and the other in v1, you have a problem when trying to handle these objects — a problem which JS can afford to ignore because everything looks like a duck anyway to JS.

3. You namespace package versions in the code. This is what Go does, to some extent — you can import v1 and v2 of the same package into a single sourcefile. This obviously has some benefits, but also drawbacks: Specifying versions within sourcecode makes maintenance in larger projects a total hell.

4. You take a hybrid approach: Rust does a quick heuristics-enhanced DFS (depth first search), which rapidly decides on compatibility (if SemVer is used correctly). Otherwise it fails fast, and installs two conflicting versions, after which the compiler checks if those versions are functionally isolated from each other in the code. If not, the compilation will fail.

@bittersweet thanks for the excursion. I learned a thing.

And using composer and npm within the same project will probably and in apocalypse soon?

@ZeldaFan69-2 Different programming languages, so you can't really use them for the same codebase.

@bittersweet 🤦