karamazov

Does anyone know how large the codebase is?

The answer is, Kyle was entirely comfortable granting 50% equity because it was subject to standard vesting, and everyone involved understood that Jeremy would own no part of the company if he left in the first year.

Here's a non-paywalled link to the ratchet explanation: https://www.cooley.com/files/TechIPOsTriggeringMore'Ratchets...

My guess: train operators are probably a much lower percentage of the total cost of running a train than drivers are for trucks or cabs, removing the incentive for automation.

That's dedication. I wonder why they're going around aggravating mailboxes, though.

Garry, thank you for everything!

My goal was to make the paper more approachable for people not comfortable with formal mathematics. I think the insight comes from understanding the paper directly.

Do you have an example of a comment, on this or another paper, that you found insightful?

I had a chance to add the first few annotations. Happy to answer questions on the paper as best I can.

I just finished "So Good They Can't Ignore You" and "Little Bets", both of which were great.

Banks make keeping track of the money in your account intentionally difficult. You can't just check your balance and assume that you can spend what's there.

Instead, your balance includes only processed transactions, whereas your account also has a list of pending transactions that can hit your balance at any time. Pending transactions can also disappear from your account, only to come back as a confirmed transaction. In effect, you can't be sure of exactly what's in your account unless you manually keep track of every charge you've made.

Banks do more than this to make overdrafts difficult to deal with. For example, Bank of America intentionally processes your transactions from largest to smallest, ensuring you'll git hit with the maximum number of overdraft fees.

e.g: if you have $10 in your account, and you make a $3 purchase, a $4 purchase, and a $12 purchase, they'll run the charges in the order of $12, $4, and $3, hitting you with three fees instead of one.

tl;dr: banks love overdraft fees and do whatever they can get away with to hit you with them.

I've only used TAOCP for reference. Working through it is on my to-do list, but I'm not sure when I'll get there.

The problems are ranked by difficulty, so you might be able to work your way up to the harder ones.

I try to work through hard technical material. Personally, I enjoy both technical books and MIT OCW lectures. There were a number of courses in school that I was interested in and didn't have time for, so I've been looking at the online equivalents.

"Working through" means doing exercises and projects. Reading or watching material without applying it doesn't help.

I aim to spend an hour a day on this. It doesn't always happen, but it's a reasonable enough goal that I can find time for it most days. Occasionally, I'll take a full day to study on the weekend.

Some specific recommendations:

  books:
    SICP (https://mitpress.mit.edu/sicp/)
    K&R
    The Art of Computer Programming (if you have lots of time)
    On Lisp (http://www.paulgraham.com/onlisp.html)
    Learn you a Haskell
    Types and Programming Languages
    CLRS
    The Dragon Book (Compilers, http://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811)

  OCW Courses:
    6.172 (High performance engineering)
    6.046 (Algorithms)

This is just what I've been interested in and is by no means comprehensive. Outside of CS, math is great to learn if you haven't studied it formally.

I've found it's best to pick a topic you know enough about to be motivated to study it, but haven't done serious work in.

It's about time someone took this seriously.

Eventually, some of your code will make a call to IO: reading from or writing to disk, responding to a web query, updating a DB, drawing something on the screen, etc, etc.

For example, you could put up a web server written entirely in Scheme or some other dialect. This would process and respond to queries entirely in Scheme, including some sort of engine for generating and serving html. Hacker News itself is an example of this: it's written in a lisp dialect called Arc.

Incidentally, Haskell is functional, but it isn't a lisp.

If AWS posts a loss it'll be because Amazon is reinvesting resources into its growth, not because they're subsidizing each user's costs.

I suspect the other party gave LinkedIn their address book, and they're trying to maximize the odds of a connection.

First, this sidesteps the question. The writeup implies owners will be able to buy out indie.vc, rather than feed them a perpetual stream of dividends. Regardless of how they do this, what is the buy-out amount? It will have to be an integer multiple of the money invested to reach breakeven.

Second, many companies, especially tech companies, do not pay dividends.

In particular, a growing company would be foolish to distribute dividends; dividends are for companies that have reached a steady-state. Waiting for a company to hit steady-state from inception can take a very long time.

I'm curious to know how they plan to compensate for the failure rate of startups.

If half of the portfolio fails (a good outcome), the cashout option would need to be 2x the original investment for them to break even. More if failing companies are likely to use up the entire line-of-credit and successful companies are not.

Setting the payout to be a percent of revenue might work, but could also kill a company with thin margins. Setting it to be a percent of profit will encourage companies to post zero profits. I'm not sure what the other options are.

By not requiring the company to be in Canada, for one.

We wrote a static optimizer for spreadsheets - this looks at the entire sheet and reduces computational complexity where it can.

Excel's built-in functions are optimized to run fast individually, not to work in concert. (Also, some of them are just slow for no good reason.)

We're hoping that better performance will let users build well-designed spreadsheets - they'll be able to show more steps and use less archaic formulas without having to worry about slowdowns.

The high kyu/dan level programs are worth playing against. The ones under 20 kyu aren't - they don't play the sort of game you can learn from, especially when you're getting started and don't know what things are supposed to look like.

There aren't any useful AIs to have games with at that level - the mistakes they make are totally unlike how real 30 kyu players play. That's why it's not worth playing them.

Plus, the folks on KGS are friendly, and there are always plenty of other 30 kyus to play with. No need for it to be tense.

For those interested in learning to play, Kiseido Go Server (https://www.gokgs.com) has a fantastic community of users - from total beginners to professional players. It also has an intro you can skim, but don't spend too much time with it - just like programming, the best way to learn Go is to dive in headfirst.

(Don't make the mistake of practicing against a computer to start. AI plays very differently from humans, and you'll develop weird habits.)

If you're in New York and interested in an in-person game, send me an email - ben at datanitro dot com.

Thanks for the offer, but I'm on the East Coast.

I'd like to try Soylent. Is there a way to order, say, $10 worth to check it out?

The point is that we don't see eggs break at some times and reassemble themselves at others. Whether time is flowing "forwards" or "backwards" is just a label - if you decided to start calling "tomorrow" "yesterday", it wouldn't change anything except what you say.

However, if you could break an egg and then unbreak it, that would be remarkable (and observable), whether you did it tomorrow or yesterday.

Python is very readable; those users can usually understand it if they try.

Not at all, it's great to see more products helping people get away from VBA. xlwings is well-done and has some features we don't (e.g. Mac interop), and likewise we have some features they don't (e.g. UDF's).

(I'm one of the DataNitro founders.)

We produce the correct result rather than duplicating buggy behavior.