Because the government has all the fucking data it needs to just tell me how much I owe, but no they force me to calculate it myself every year. Or to pay an accountant because it's a horrible mess of a form.
My main issue is with taxes in general. Well over half of my income (some sources suggest up to 70%) ends up being paid as some kind of tax.
Which is a real shame.
Well, just the usual, slightly less optimistic every year. I believed that world is fair even if it sometimes takes a while, that I'll be rich, that you can achieve anything if you try enough.
Over time I learned that the world isn't fair, that you can't be rich if you have a conscience and that you can only achieve what the ones with power over you will let you.
All of that of course has an exception: you might get lucky.
The most recent change was when I started watching two kinds of cases and what is the usual resolution / punishment. It's rape cases and who gets to keep the kids when people break up. Rapists usually walk away with very lax punishments with bullshit reasons and women almost always get the kids, even if the woman is straight up a psycho and the man is just a regular guy.
I wasn't under the impression that judges were somehow better than the average person, but this kinda showed me that they're actually much much worse than the average person.
So because you do it correctly, everyone else should get fucked or what? Like, you know how many people have bad parents?
So, congrats, your kids won't suffer from that (or maybe they will once they have their own money because the path way of "spend a $1, get an in-game item, get an instant rush of feel-good hormones" is forming even with moderation). But other kids may, unless of course you think that it's somehow their fault they have shitty parents.
So no, I really don't want this around kids whose lives will be ruined just so your kids can have a fun time (which they can have in other ways, including other games).
Nah, I'm obsessed with corporations not ruining kids lives just to get few more dollars.
Also, please, stop putting words into other people's mouths.
Cool, that's why half the games you listed are just gambling machines in disguise?
Ah, the classic "world hunger is a myth, I have eaten today."
I'm not saying there are not the rare gems in mobile games (just bought Don't Starve on Android last month!), but like 99% of games for mobile are just s money making scheme using dark patterns to influence your brain to give them money.
And congrats on not spending on micro transactions! You do realize the world doesn't revolve around how your perceive things, right? If young people are exposed to micro transactions like that, it alters their brains and not in a good way. And that's science, there really isn't much you can argue with.
Because the games are intentionally made with micro transactions as the main feature.
Like, if you play Witcher or Control or whatever, the focus is on you enjoying the game. If you play Fortnite, the main focus is on getting you pay. The game is probably still fun, but every single thing in the game is meant to make you pay.
Who would've thunk, young people with brains that are not fully developed tend to prefer games with addictive elements.
They mean push notifications where you need to store a device identifying URL to push your notifications to.
If traceability is a concern, using the native iOS notifications is not much better, you just move the burden to Apple (which I assume will be more than happy to cooperate, given they're an American corporate), so nothing is really solved.
The only good solution is your own backend which knows nothing and each app installation maintains a permanent WebSocket connection, then you push them to each client.
The time flies really fast! Exactly 2 years ago I was the one and only user of this instance and now there are thousands of us! So happy birthday to Lemmings.world and hope you all enjoy our small corner of the internet!
cross-posted from: https://chrastecky.dev/post/16
Starting with PHP 8.5, you'll be able to do the following:
public function __construct( final public string $someProperty, ) {}This wasn't possible before, as promoted properties couldn't be declared
final.Perhaps the more interesting part is that you can now omit the visibility modifier if you include
final. In that case, the property will default topublic:public function __construct( final string $someProperty, // this property will be public ) {}Personally, I’m not a fan of this behavior — I prefer explicit over implicit. Fortunately, it can be enforced by third-party tools like code style fixers. Still, I would have preferred if the core required the visibility to be specified.
What do you think? Do you like this change, or would you have preferred a stricter approach?
cross-posted from: https://chrastecky.dev/post/16
Starting with PHP 8.5, you'll be able to do the following:
public function __construct( final public string $someProperty, ) {}This wasn't possible before, as promoted properties couldn't be declared
final.Perhaps the more interesting part is that you can now omit the visibility modifier if you include
final. In that case, the property will default topublic:public function __construct( final string $someProperty, // this property will be public ) {}Personally, I’m not a fan of this behavior — I prefer explicit over implicit. Fortunately, it can be enforced by third-party tools like code style fixers. Still, I would have preferred if the core required the visibility to be specified.
What do you think? Do you like this change, or would you have preferred a stricter approach?
cross-posted from: https://chrastecky.dev/post/13
This change is quite straightforward, so this won’t be a long article. PHP 8.5 adds support for annotating non-class, compile-time constants with attributes. Compile-time constants are those defined using the
constkeyword, not thedefine()function.Attributes can now include
Attribute::TARGET_CONSTANTamong their valid targets. Additionally, as the name suggests,Attribute::TARGET_ALLnow includes constants as well. TheReflectionConstantclass has been updated with a new method,getAttributes(), to support retrieving these annotations.One particularly useful aspect of this change is that the built-in
#[Deprecated]attribute can now be applied to compile-time constants.As promised, this was a short post, since the change is relatively simple. See you next time—hopefully with a more exciting new feature in PHP 8.5!
cross-posted from: https://chrastecky.dev/post/13
This change is quite straightforward, so this won’t be a long article. PHP 8.5 adds support for annotating non-class, compile-time constants with attributes. Compile-time constants are those defined using the
constkeyword, not thedefine()function.Attributes can now include
Attribute::TARGET_CONSTANTamong their valid targets. Additionally, as the name suggests,Attribute::TARGET_ALLnow includes constants as well. TheReflectionConstantclass has been updated with a new method,getAttributes(), to support retrieving these annotations.One particularly useful aspect of this change is that the built-in
#[Deprecated]attribute can now be applied to compile-time constants.As promised, this was a short post, since the change is relatively simple. See you next time—hopefully with a more exciting new feature in PHP 8.5!
cross-posted from: https://chrastecky.dev/post/15
PHP has long had a levenshtein() function, but it comes with a significant limitation: it doesn’t support UTF-8.
If you’re not familiar with the Levenshtein distance, it’s a way to measure how different two strings are — by counting the minimum number of single-character edits (insertions, deletions, or substitutions) required to change one string into another.
For example, the following code returns
2instead of the correct result,1:var_dump(levenshtein('göthe', 'gothe'));There are workarounds — such as using a pure PHP implementation or converting strings to a custom single-byte encoding — but they come with downsides, like slower performance or non-standard behavior.
With the new
grapheme_levenshtein()function in PHP 8.5, the code above now correctly returns1.Grapheme-Based Comparison
What makes this new function especially powerful is that it operates on graphemes, not bytes or code points. For instance, the character é (accented 'e') can be represented in two ways: as a single code point (
U+00E9) or as a combination of the letter e (U+0065) and a combining accent (U+0301). In PHP, you can write these as:$string1 = "\u{00e9}"; $string2 = "\u{0065}\u{0301}";Even though these strings are technically different at the byte level, they represent the same grapheme. The new
grapheme_levenshtein()function correctly recognizes this and returns0— meaning no difference.This is particularly useful when working with complex scripts such as Japanese, Chinese, or Korean, where grapheme clusters play a bigger role than in Latin or Cyrillic alphabets.
Just for fun: what do you think the original
levenshtein()function will return for the example above?var_dump(levenshtein("\u{0065}\u{0301}", "\u{00e9}"));
cross-posted from: https://chrastecky.dev/post/15
PHP has long had a levenshtein() function, but it comes with a significant limitation: it doesn’t support UTF-8.
If you’re not familiar with the Levenshtein distance, it’s a way to measure how different two strings are — by counting the minimum number of single-character edits (insertions, deletions, or substitutions) required to change one string into another.
For example, the following code returns
2instead of the correct result,1:var_dump(levenshtein('göthe', 'gothe'));There are workarounds — such as using a pure PHP implementation or converting strings to a custom single-byte encoding — but they come with downsides, like slower performance or non-standard behavior.
With the new
grapheme_levenshtein()function in PHP 8.5, the code above now correctly returns1.Grapheme-Based Comparison
What makes this new function especially powerful is that it operates on graphemes, not bytes or code points. For instance, the character é (accented 'e') can be represented in two ways: as a single code point (
U+00E9) or as a combination of the letter e (U+0065) and a combining accent (U+0301). In PHP, you can write these as:$string1 = "\u{00e9}"; $string2 = "\u{0065}\u{0301}";Even though these strings are technically different at the byte level, they represent the same grapheme. The new
grapheme_levenshtein()function correctly recognizes this and returns0— meaning no difference.This is particularly useful when working with complex scripts such as Japanese, Chinese, or Korean, where grapheme clusters play a bigger role than in Latin or Cyrillic alphabets.
Just for fun: what do you think the original
levenshtein()function will return for the example above?var_dump(levenshtein("\u{0065}\u{0301}", "\u{00e9}"));
Congrats on the US defaultism! I'm not from the US, so stick your crack comment up your arse.