21–30 of 274 posts
In Norway, we've had a more or less automated tax system for many years; every year you get a notification that the tax settlement is complete, you log in and check if everything is correct (and edit if desired) and click OK.
It shouldn't be more difficult than this.
While a great article, I actually found this linked post [0] to be even better, in which the author lays out how so much modern tooling for web dev exists simply because XML lost the browser war. EDIT: obviously, JSON tooling sprang up because JSON became the lingua franca. I meant that it became necessary to address the shortcomings of JSON, which XML had solved. 0: https://marcosmagueta.com/blog/the-lost-art-of-xml…
I read both, but I feel like they both miss what it was like to work with APIs back in the bad old XML days. Yes, XML is more descriptive. It's also much harder for programmers to work with. Every client or server speaking an XML-based protocol had to have their own encoder/decoder that could map XML strings into in-memory data structures (dicts, objects, arrays, etc) that made sense in that language. These were ofte…
> There is a distinction that the industry refuses to acknowledge: developer convenience and correctness are different concerns. They are not opposed, necessarily, but they are not the same thing. … The rationalization is remarkable. "JSON is simpler", they say, while maintaining thousands of lines of validation code. "JSON is more readable", they claim, while debugging subtle bugs caused by typos in key names that a schema would have caught immediately. "JSON is lightweight", they insist, while transmitting megabytes of redundant field names that binary XML would have compressed away. This is not engineering. This is fashion masquerading as technical judgment.
I feel the same way about RDBMS. Every single time I have found a data integrity issue - which is nearly daily - the fix that is chosen is yet another validation check. When I propose actually creating a proper relational schema, or leaning on guarantees an RDBMS can provide (such as making columns that shouldn’t be NULL non-NULLable, or using foreign key constraints), I’m told that it would “break the developer mental model.”
Apparently, the desired mental model is “make it as simple as possible, but then slowly add layer upon layer of complex logic to handle all of the bugs.”
At the cost of a slightly more complex schema, the JSON representation can be made much more readable: { "path": "/tentativeTaxNetNonRefundableCredits", "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.", "maxOf": [ { "const": { "value": 0, "currency": "Dollar" } }, { "subtract": { "from": "/totalTentativeTax", "amount": "/totalNonRefundableCredits" } }…
It's completely unbelievable that so-called developed countries are struggling with this in 2026. In Norway, we've had a more or less automated tax system for many years; every year you get a notification that the tax settlement is complete, you log in and check if everything is correct (and edit if desired) and click OK. It shouldn't be more difficult than this.
invoice "INV-001" for "ACME Corp"
item "Hosting" 100 x 3
item "Support" 50 x 2
tax 20%
invoice "INV-002" for "Globex"
item "Consulting" 200 x 5
discount 10%
tax 21%
XML is better than yaml. …note this doesn’t really say much. Both are terrible.
What hurt XML was the ecosystem of overly complex shit that just sullied the whole space. Namespaces were a disaster, and when firms would layer many namespaces into one use it just turned it into a magnificent mess that became impossible to manually generate or verify. And then poorly thought out garbage specs like SOAP just made everyone want to toss all of it into the garbage bin, and XML became collateral damage of kickback against terrible standards.
I have been playing with DSLs a little, here is the kind of syntax that I would choose: invoice "INV-001" for "ACME Corp" item "Hosting" 100 x 3 item "Support" 50 x 2 tax 20% invoice "INV-002" for "Globex" item "Consulting" 200 x 5 discount 10% tax 21% In contrast to XML (even with authoring tools), my feeling is that XML (or any angle-bracket language tbh) is just too hard to write correctly (ie XML syntax and XMl s…
grammar InvoiceDSL {
token TOP {
^ + % \n* $
}
token invoice {
\n
+
}
token header {
'invoice' \h+ \h+ 'for' \h+
}
token line {
\h**4 \n?
}
token entry {
|
|
|
}
token item {
'item' \h+ \h+ \h+ 'x' \h+
}
token tax {
'tax' \h+ '%'
}
token discount {
'discount' \h+ '%'
}
token string { \" * )> \" }
token num { \d+ [ '.' \d+ ]? }
token int { \d+ }
}It's completely unbelievable that so-called developed countries are struggling with this in 2026. In Norway, we've had a more or less automated tax system for many years; every year you get a notification that the tax settlement is complete, you log in and check if everything is correct (and edit if desired) and click OK. It shouldn't be more difficult than this.
how much do Norway tax preparation companies spend on lobbying Norway Politicians each year? :)