sago

How realistic is it to have no joined letters? Do many people really write large scale texts letter by letter with space between each?

Sadly, the screenshot looks obviously artificial to me. Like handwriting fonts, I'd be very surprised if anybody thought it was really handwritten.

It's not open source (because it is my handwriting (because my progressive MS means I can't do it manually)), but here's my hack: https://imgur.com/a/frqG0cu

As sjv says above, there are still plenty of tells in mine. So I think this module is very unconvincing.

Maybe I've spent too much time being finicky or am just being braggy (definitely not beyond me, sorry), but 'realistic'?

All these worlds are yours except Ceres. Use them together. Use them in peace.

> I always get the feeling that people love ORMs because they don't want to learn SQL.

I suspect that's the problem. It's neither my feeling or my experience.

Every platform/language/OS/chip I know has annoyingly apparent problems. In my experience high-self-conidence-low-self-awareness folks are too keen to drop-level and 'make it right'. And love feeling how smart they are ('everyone who disagrees is obviously not as smart!) Too often 'smart-guys' cost more, long term. And I'm not ragging on you. That was me in my 20s. Embarrassingly.

Meh. All analogies are partial.

If there was an ORM that dealt with everything but a flaky end of life database, sure start working on it.

But this is advocating picking one platform. Like creating Chrome-only JavaScript. I guess the nearest thing with Electron.

Yeah the analogies breakdown at some point.

I don't think anything is black-and-white. I just think the vast majority of Django apps are fine with Django's ORM. This article smacked of premature optimisation.

"Imagine hating databases" ... "just so you don't have to deal with them"

Do you normally respond to issues by trying to characterise people?

Imagine this fictional world where anyone that disagrees with me is incompetent.

In my experience, I think working with database specific functionality is like dropping to lower-level of code generally. Something I have done in ORM->Raw SQL and C->Assembly. There is a point where the price in development cost, testing development time, platform lock-in, reduced code reuse IP, subset of experienced programmers within the team/salaries/training, loss of access to future updates and bug fixes, and so on is worth it. But almost never in my experience. Almost but not entirely.

> That's because you are not using the power of postgresql...

Isn't that a potential positive?

I mean, yeah, and those darn programmers with their 'platform independent languages'. Why are you not using the power of assembly?

tldr: If you don't want to scroll down the massive header and repeated statement of the title:

1. Double asterisk is the exponentiation operator.

2. _ can be used in numbers, e.g. 1_000_000

Also (and not in the article) both are also true in Python.

If you are using a negative numbers you can do it in three ways.

1. positive numbers represent the default for an account (A positive number in a debit account is a debit, but a positive number in a liability say, is a credit). This is done a lot. But he causes a lot of rules about when to add and went to subtract what the balance with what. I think this is why they lot of double entry bookkeeping and has a hard reputation. Certainly if you coded it you would have to code all those rules manually.

2. The approach I'm used to of having negative numbers in the debits and positive credits. This makes all the double accounting balancing much simpler. But I can see it may confuse some people when assets are negative.

3. Make credits at the beauty of an debits positive (incidentally I only today learned that beancount does it this way). Again balancing and double-entry accounting becomes simpler. Now money in the bank would be positive, like your bank statement. But sales income would be negative (it is a credit). I wonder if that would confuse people.

So maybe that's why UI should make everything positive and undifferentiated. But given the amount of time the Accounting 101 has to drill in all the rules of what

> Signed values are the way to go!

100% agree!

> For one example, read the docs for Beancount, which is mentioned above.

Do you have other examples too?

You are dead right with this one. It is the opposite way to the way the systems I'm familiar with did it. Debit is positive, And credit negative.

Thanks so much for the link.

I'm still not sure what I would concede that it is conventional ;) But my assumption it was nothing but the other way is definitely incorrect!

I wonder if they did it this way because they felt people would understand negative income being a good thing better than a negative bank accounts being a good thing. The bank account is usually the big problem with understanding debit and credit.

As usual, the world is more complex and interesting then I assume!

Neat. Thank you. I get what you're saying now.

And that makes sense. You can see the balance. Because it will balance. Or you'd know which of the things were debit accounts and which went credit accounts.

Yep.

But I definitely bet it's not raw unsigned/untyped numbers behind that document! I suspect we've just been mismatching on different levels: I began this discussion about developers understanding double entry bookkeeping. I would be surprised if you could get very far if you didn't understand the difference between debit and credit. But your pushback makes sense. Thank you.

> Did it displayed assets

It's an API. There are many tools built on top of it, many with UIs. I'm sure they display things in many different ways for people internally and externally. The system I was working was back-end. It used negative numbers for debits. And it was really important you didn't confuse credit and debit numbers.

> Was that accountant fine with assets as negative numbers?

I find it hard to believe they didn't understand that's what Using negative numbers for debits means. They would be pretty aware that assets are debit accounts.

> The did have $1tn in their balance sheet. No DB, no CR. Just $1tn.

Did they have a complex balance sheet (I.e. beyond that just a couple of lines summary) with no columns? How do they represent a balance if you couldn't tell which were credits and debits?

It's definitely not my idea! It wasn't Goldman Sachs, but I did a consultancy 15 Years ago for a large bank (my little job was a long way from programming the core, but used it extensively). Their system stored debit as negative numbers. That's when I learned it and had the aha moment when everything instantly simplified. Since then all the accounting software I've seen the inside of do.

Most lay-people find double entry in accounting idiosyncratic. It has this bad reputation for being full of special case rules.

It is interesting that the one comment I got from an accountant on here it seemed fine with debit as negative numbers.

Goldman Sachs absolutely know that they have DB$1tn! Anyone who thinks it is either a credit account or just a bare number is not going to be dealing with that!

Thanks for carrying on the chat.

This has been an interesting conversation with several people. I am really surprised how much negative numbers are confusing or interpreted as my idiosyncrasy.

> I’ve seen financial accounts quite more complex than two lines

Definitely.

For hundreds of years the convention has been columns. Credit values in the right-hand column, debit values in a left-hand column. The column is the label of which type of money it is. Most accountancy software (other than very simple personal tracking apps) use this when displaying.

Your printed bank statement probably does (and it may label the columns credit and debit as well, though never line by line, iirc). Mine did back when paper was the thing.

Digital bank statements usually do use negative numbers (DB being negative, as I've been saying). You are used to seeing this, but not used to thinking in your own accounting terms rather than theres. Which is fine. But there is a reason that accountancy education has to undo that assumption.

> Equity is similar to a liability. Ít is owed to the owners of the entity.

You can kind of see the easy rationale there. I'm not sure it's very deep though. Revenue is in the same group (Credit). And the assets are like expenses (Debit). That is a bit more of a just-so-story in my mind.

> Making assets positive in code is conventional.

Are you sure? What code are you talking about?

Making everything positive in the UI is certainly common. And not showing whether a value is credit or debit. But I really hope my accountancy software isn't coded that way! It needs to track whether a number is a credit or a debit. It could do it with an unsigned value in a struct with a 'is_cr' Boolean and some custom operations to combine the money structs. But I've only ever seen code using signed values, because it is so much faster and less errorprone. Doing it manually is just reinventing the math of negative numbers. And then, the overwhelming convention is the former is positive, the latter negative, not the other way round.

If the things you're doing are so simple that you don't have to worry about credit or debit, you are free to show it that way.

But if you are doing accounting, debits and credits and balancing is important.

So yes, if you are happy to ignore debit/credit/balanced books, you are welcome to view asset as $2m. And lots of the simple accounting software will show it that way.

But by the time you are having to understand different types of accounts and different types of money in it, I think it is easier to use negative numbers are rather than CR/DB.

In a conventional double accounting system:

  Deposit
  Asset>Cash in Hand CR$1m
  Asset>Bank: DB$1m

  House purchase
  Asset>Cash in Hand CR$1m
  Asset>Property: DB$1m

So all I'm suggesting is to use of negative numbers instead of tracking everything in terms of credits and debits.

  Deposit
  Asset>Cash in Hand $1m
  Asset>Bank: $-1m

  House purchase
  Asset>Cash in Hand $1m
  Asset>Property: $-1m

In either case the value of your assets at the end is unchanged, because you're just turning assets into different kinds of assets.

But let's say you started with DB$2m (inheritance say, or you won the lottery). You end with DB$2m assets.

I'm not reinventing anything here. Where do you want to label your $2m as 'debit' every time, or use negative numbers, either way is the same.

People do always struggle when learning accounting to comprehend how money in their assets is debit. Because they are so used to seeing 'credit' on their bank statements. But it is only credit because there was from the banks point of view.

A=L+E

is true because L and E are Credit dollars and A is Debit dollars. And the total Debit is equal to the total Credit.

But instead of using debit and credit unsigned dollars, you can use negative numbers: Credit is Positive, Debit negative.

In that case

(-Assets) = Liabilities + Equity, so A+L+E=0

-Assets because you've made those debit dollars negative.

In fact you don't even have to remember which. Sum(Everything)=0. 'Balancing' means summing to 0.

The software I am aware of that does large-scale double entry calculations for large banks works this way (I did some consulting 15 years ago on data laundering for that system). And all those accounting rules about what accounts are debit or credit accounts, whether a credit increases the debit account, etc, it all isn't needed at a low-level. The confusing bits are only in the UI. Where a number stored as -10 is displayed as 10DB, while +10 becomes 10CR.

So it's definitely not 'just simple maths'. It is the convention you use to express numbers: turning debit numbers into positive, and having rules to keep the math consistent in other places. And since the original article was aimed 'at developers', I think that the widespread negative number format is much stronger.

Yes on both fronts. Thanks for continuing until we've got on the same page.

The only slight curve ball in your part one is that transactions are not always between two accounts. The joke is that 'double entry' sometimes has more than two.

The classic example is sales tax. E.g. a transaction:

Revenue>Product $100CR

Liability>Sales tax $5CR

Asset>Bank $105DB

(Although the specific form/standard categories will massively depend on how sales tax works in your jurisdiction.)

There are plenty of other examples (in my consulting: the customer paid some their bill in advance, or I pay a bill in a different currency and have to pay a fee).

So I like the idea of making it a topology question, but it would be nice if it were only two.

I suspect the misconception might be that you think individual accounts must balance (Or think that what I'm saying). Transactions always balance, companies always balance.

In double entry accounting you track where money came from to you. You are right in not having to worry where they get their money from. But you do have to track how/why it came to you.

You will have an account in your accounting of 'income' (it's usually called 'Revenue'). If you have even the slightest complexity in your business, you will have many income accounts. Some businesses will definitely track at the level of detail where they have accounts for each customer, so they can see who purchased how much.

Each transaction balances.

Each line in a transaction is associated with an account.

So if you have done 50 weekly transactions of:

Revenue>Consulting $1,000CR

Assets>Bank $1,000DB

Each one balances.

But in total you will have $50,000CR in Revenue>Consulting and $50,000DB in Assets>Bank, but your company will still balance.

If you pay yourself $45,000 in salary from that, let's say in one go at the end of the year (to save me typing) you would have a transaction:

Assets>Bank $45,000CR (it came from your bank account)

Expenses>Salary $45,000DB (it went to your salary)

So at the end, your accounts are:

Assets>Bank $5,000DB

Revenue>Consulting $50,000CR

Expenses>Salary $45,000DB

This still balances. Double accounting always balances companies and transactions.

Historically it balances credits and debits. All I'm saying is it makes more sense to think of debits as negative and credits as positive, and all the math becomes much much simpler. Which is how accounting software is written.

I see, sorry. Thanks for clarifying your question.

Transactions always balance. Money always comes from somewhere, and it always goes to somewhere. Total debit always equals total credit.

In a double entry accounting system you have to say where that $200 came from.

Did it come from a sale (you sold your work, an item), a loan you took, someone you loaned money yourself, or an investment in your company.

In double accounting it always balances.

Here I am talking debit and credit because this is nothing to do with my point about positivity or negativity. This is how double entry bookkeeping works.

If you make all the numbers positive, then the total credit has to equate ('balance') with the total debit.

So treating debit as negative and credit as positive, means 'balancing' is just summing to 0.

Before double entry bookkeeping was invented in the Renaissance, single entry accounting just kept separate lists for all things. This works for basic tracking of money. For individuals particularly. But has massive weaknesses for tracking where money is coming from how it moves around, and making sure there aren't errors. Money doesn't come out of the blue. Which is why it is the business standard. And the legal requirement in most of the world. One of the most amazing and significant human innovations, IMO.

The credit and debit/what to add/what to subtract rules are only because double entry accounting was invented before use of negative numbers (they were only a weird mathematical curiosity at the time).

So I am not reinventing anything.

Debit is where you put money. Credit is where it came from.

I am not inventing this. Money in your bank is debit in _your_ accounting.

You are very welcome to treat it as positive and add. As long as you keep track of where every positive number is a credit or a debit, and you learn all the rules about which accounts to add and which ones need taking away.

Or you can just treat credits as positive numbers and debits as negative.

Literally the only 'weirdness' is that money you have put somewhere for future use (like a bank) is negative.

Your initial reaction might be "that's just nonsense and ridiculous!" But I guarantee that is how your accountant and accountancy software is storing it. Your bank balance is debit from your accounts. Legally and intuitively. The only reason it is weird is because you receive statements from the bank from their perspective (a credit because they received the money from you).

If you have made it to junior high school you are quite capable of the math. Treat debits as negative and credits as positive. No accountancy ed / special rules needed.

If you want to get it more intuitive you can think of it as: Negative numbers are money that you put somewhere and is now owed to you. If you have $1000 in 'your' account, legally that means you are $1000 down because you are owed that money by the bank. It is your debit. You have given them credit.

It may not feel like a loan because it feels like you can get the money any time you want. But loans you have given and bank accounts are both assets in your accounting. They are both debit. They are both money you have put somewhere.

Transaction:

Income > Work: $200 (or $200CR)

Assets > Bank Account: -$200 (or $200DB)

This is exactly how it would be stored in any software system behind-the-scenes, and how it would be submitted in statutory accounts. The only thing that makes this look weird is that you are used to seeing your bank account statement with 'credit'. But that's only because the bank account statement is from their accounting perspective.

Money comes from somewhere (Positive, Credit); it goes somewhere (Negative, Debit).

The entire confusion about signs and what to add and remove, and what categories 'increase' with debit or credit, it all disappears when you allow negative numbers. I guarantee your accounting software _will_ simply store them as positive or negative. It is frustrating that it appears so complex simply because of avoiding negative numbers.

Except in your case you need all the rules about income and expenses. And loads of grey cases get weird (it is possible to have assets or liability of the wrong sign), and require serious accountancy expertise to know all the rules to get them back to the signs that you expect.

Or you can use negative numbers and everything just works.

Your financial software _will_ use my approach. As do the most sophisticated software of the most complicated companies. But their presentation gets mangled through a complicated series of rules for archaic reasons.

It is not incorrect. To make everything positive (and use the subtraction as you have) you need to have two different types of 'positivity' Credit and debit. And then you have to remember which things are subtracted and added so it gets back to balancing. That's why it gets so complicated.

Money in your bank account is _negative_. It is a _debit_ in your accounts (this is not my invention this is true). Your bank account statement is from the bank's perspective. The money came from you, so it is a credit from their perspective only. Try to submit your statutory accounts with 'bank credit' and you'll get in trouble! Your software or accountant will definitely flip it to become a debit!

Your transaction to start your account:

Equity: $100 (or $100CR)

Bank account: $-100 (or $100DB)

Loan:

Debt: $100 (or $100CR)

Bank account: -$100 (or $100DB)

Accounts:

Assets > Bank account: $-200 (or $200DB)

Liabilities > Debt: $100 (or $100CR)

Equity: $100 (or $100CR)

I agree. Except I think you're being generous :)

It would not work for a bank. The only reason they 'sort of flip' is that they give your account from their perspective. Your statement is a slice of their accounting.

I always felt that equation was confusing. Because then the sign has to be taught separately, or numbers have to have two columns (credit and debit) and you need to understand where each one is.

assets + liabilities + equity = 0

Seemed much more general. Double entry just became: everything (transactions, whole companies) sum to zero. Then just one other little thing (where money comes from in a transaction is positive, where you put it is negative) and you have the math.

IMH(and not accountancy)O

> If someone has a fuzzy logic that definitively answers questions such as "what is the boundary between an individual and a system?"

Ah, I see. That was our disconnect. That's the opposite of the idea. The logic is just to abandon a discrete boundary (physics does this in many cases). I think my use of 'fuzzy' might have sparked a different debate.

Not one I find convincing (if Science then Philosophy, not Philosophy ∴ not Science ? um...) but I don't much rate 'fuzzy logic' for mathematical reasons. That's another rabbit hole! Thanks for clarifying.

Weird.

> Because they're trying to find a solution to the sorites paradox,

Exactly and explicitly the opposite!

Why assume that dynamics are crisp if 'individual' isn't?

I suspect the science isn't quite 'seeking the individual'.

Rather than trying to find fancier ways to define the lines, are there lines at all? Perhaps fuzzy grouping opens up more powerful models. What began as co-evolutionary theory is way more continuous.

I was at SFI in the 90s, before the big push mentioned in this article. I remember a conversation about it, discussing perhaps there isn't such a thing as an individual. It wasn't even said as if radical (e.g., by that point the Selfish Gene (1976) and The Extended Phenotype (1982) were well established, and way behind any 'cutting edge'). So I suspect it isn't quite 'finding the individual' that the article author keeps focussing on. But more 'models that abandon individuality'.

I generally suspect that a problem with large swathes of human thought are discretising continuous reality. That's definitely a core SFI view too. Or at least was in the 90s.

> I've heard that a major use case

It was. At peak perhaps 10 years ago. It is telling that the game engine citation in that article is from 2009.

Now the ecosystem of game engines is very different. Very few games are written in raw C/++ and have to have their own tiny scripting language packaged. They are mostly based on more established engines. 'Small studios' have gone, niched out of end-to-end dev, or re-invented as the 'indie game' world, and pretty much none have their own multi-game engine.

In fact, I've only come across Lua used in Pico-8 gamejam games in the last 2 yrs, personally. (Though I'm retired now.)

It was a phenomenal language for gamedev. I commissioned a Lua consultant to extend the language in a small way for a game, I ended up paying for about half the hours I expected.