In my example, the tax rate isn't the point though, it was used just to illustrate the math.

The main point is that it makes no sense to require amortization of software development expenses. The idea that this letter is an attempt to restore rationality in the tax code.

- A business is usually taxed on its profits: you deduct your revenue from the cost of producing that revenue, and the delta is what you are taxed on.

- In software businesses, this usually means if you spend $1M in software development to develop a web app, and it makes $1.1M in that year, you'd get taxed on the $100K profits.

- However, a few years ago, the IRS stopped allowing the $1M to be deducted in the year it was incurred. Instead, the $1M was to be amortized over 5 years, so now the business can only count $200K as the deductible expense for that year. So now it's going to be taxed on "profits" of $900K. Assuming the tax rate is 20%, that means the business owes $180K in taxes, even though it has a total of $100K in the bank after the actual expenses were paid. So it would have to either borrow to pay taxes or raise venture capital, meaning that VC-funded companies would be advantaged over bootstrapped ones!

- The letter's goal is to bring things back to how they were (and how they are for all other businesses): let businesses deduct their actual expenses from their actual revenue, and tax that actual profit.

I am neither a lawyer nor an accountant, this is just my understanding of this issue.

Edit: Switched the tax rate to 20%. The logic is still the same.

And, zooming out a little more, free market healthcare is just part of the problem.

We have a system where we’re only treating people once they have a disease, and not working to prevent the disease, so it would be helpful to look at the effects of for-profit companies on making healthy people sicker. Fast food, snacks, alcohol, there are so many industries that are incentivized to succeed by making people sick.

This is the system “working” according to the current rule set.

It’s time to look for a better algorithm than a purely profit maximizing one.

What’s far more “normal” is storytelling (with heroes and villains), rhythm & rhyme, and lots of repetition. But even simple conversational interfaces are way more normal (and fit our mental hardware well) than terminal-y interactions.

http://www.cs.cmu.edu/~jsherwan/pubs/orality-hcid-itid09.pdf

Comments URL: https://news.ycombinator.com/item?id=29667817

Points: 3

# Comments: 1

Based on the discussion, we're going to look a lot deeper into finding ways to reduce Electron's memory bloat especially when idle, and reduce CPU usage when screen sharing by attempting to offload the most computationally intensive parts to purely native code, while still leveraging Electron as a unified, cross-platform presentation layer. We'll report on our progress on this front, and our goal will be to get the best of both worlds: one cross-platform code-base, coupled with native levels of performance.

[1] https://news.ycombinator.com/item?id=28230542

Based on the feedback today, we're going to look into how we can reduce memory usage overall (especially when idle), and CPU usage especially when screen sharing. We already modify Electron, so we may be able to work out a good middle ground that reduces the footprint significantly, while still giving us the advantages of a shared codebase across our 4 platforms (Mac, Windows, Linux, web).