The reasoning might not sound crazy, but the result is that a founder based in Hong Kong, opening a holding in Singapore, and creates a subsidiary in Germany is much much better off than a founder running the same business out of Germany - and that's before considering personal income taxes or similar
how did you do it? My co-founder is in a similar situation, and his tax-lawyer said the only way was via a trust - they also have a German holding. Do you have to declare that somewhere? or how does this work? Thanks!
This means the person has to move to a country with 0% income tax for this to make any economic sense, so that's either Monaco or the UAE then. Very difficult for me to understand why someone is supposed to pay this tax in the first place, the business paid a whole bunch of other taxes in its lifetime.
I would understand if they'd tax the sale of the business.
apart from those weird file attach issues I actually think they've got a much better UI than anthropic as well - much much snappier even with extremely long chats (in addition to much higher limits obviously, totally different league). I love using it
just a question for understanding - if we say 'it learns', does it mean it actually learns this as part of its training data? or does this mean it's stored in a vector DB and it retrieves information based on vector search and then includes it in the context window for query responses?
yes, it's a form of double-entry bookkeeping - that's the base. If it weren't double-entry then indeed it would be a pretty poor choice. This design enforces double-entry at a fundamental level, it's never possible to create a record that doesn't affect 2 accounts - and that's actually the whole point of it :)
You have a single USD (or other) value - so in the simplest form it just looks like this:
From: Alice
To: Bob
Amount: 10
Currency: USD
And the balances are simply sum(transactions where account is receiver) - sum(transactions where account is sender)
you simple create two records linked by one 'transaction', the source in both cases is the same account, while the destination for one of those postings is the fee account and the other destination is a merchant or similar account. And you can link as many of those postings under a single transaction
yes, agree, I think a 'source' 'destination' model is significantly more straight-forward. Just record the 'source' account and the destination account and you essentially end up with a ledger as a directed graph (Martin Kleppmann wrote a great post on it)
Blockchain actually kinda nails it, that's in essence a source/destination ledger, no 'postings' or similar needed, and from a balance calculation POV has been working pretty well
One reason this model isn't applied in accounting, in my personal view :), is simply historical and the fact that the number 0 didn't exist when accounting principles were created.
It's very straight-forward, you just have to accept that asset accounts have negative balances and present the absolute amount instead of a negative amount in a view.
absolutely not true btw - the largest use-case for stable-coins atm are people evading capital controls in emerging markets, including China, India, Nigeria, and similar, and in many latin American countries.
this is the thing with JS and TS - the types and stuff, it's all good until you realise that all integers are basically int 52 (represented as float 64, with 52 bits for the fraction).
Yes, it's nice and flexible - but also introduces some dangerous subtle bugs.
People just have less tolerance for errors using apple products.. that doesn't mean that other LLM companies sell snake-oil, people just have a higher error tolerance for them and are learning to work 'with' those LLMs
Yes, all true - apart from treating errors as values and including them function signatures... That should simply be something every modern language should ship with
We've been building a source/destination ledger at nxos (and I've worked with similar systems in the past). The relationship between debits and credits in such a ledger wasn't always clear to me. However, writing this post did help me to show how these concepts map and how it's fairly straightforward to model accounting standards on such a ledger. While exploring this topic, I also learned significantly more about why debits/credits affect different account types differently and why different account types exist in the first place. I hope you might find it as interesting as I did!
Hey everyone! I wrote a blog post about building a simple double-entry ledger using just simple SQL. It covers implementing a ledger with source and destination accounts, using a simple table structure and straight-forward SQL queries for balance calculations. I use negative and positive amounts instead of traditional debit and credit columns. In my opinion, this from/to model is easier to reason about and visualize in graph form, while still allowing credit/debit terminology to be built on top if needed. Would love to hear your thoughts!
maybe that's really where the business here is.. working through a whole bunch of custom data-sets and trying to generalise from there. It'll be hard to generalise all of it, but I'm sure there'll be pockets of functionality that can be shared across more than a single data-set.
And maybe that's at the core of the issue here, namely that this service in its current form doesn't scale like b2c internet tech
and once again - another year with a great iPad Hardware wise but essentially unusable for coding tasks software wise.. Would love a reason to buy one and use as a travel coding machine but without local support it remains a non-starter
GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain to merge multiple different graphql-schemas into a single one (or at least I'm not aware of an elegant way to achieve that).. The worst of two worlds is a micro-services back-end with a graphql Api interface, it makes testing individual services and the Api as a whole quite annoying.
I do really like the Api definition part of it though - but I found something like typespec now to be the perfect middle-ground, it allows out you describe your apis similar to a graphql Api without enforcing the graphql engine on you though.