I wrote most of the code the day it launched, and I had to get it done that day because I had to help the startups prepare their Demo Day pitches.
Thanks for saying the site is high quality, but if so it's despite (or possibly because of) the fact that much of the development happens in the repl of the live site. There are not a lot of whitepapers around here. We tend to think by writing code.
But HN has a persistent bug where the next button on the first page expires and doesn't work. That's the difference between doing something for work and doing something for fun.
There's the same 'feature' which works against insightful commentary. Spend too long crafting a response, get "unknown or expired link". Not particularly endorsing of a considered, pensive response.
Surely there are better ways. For example, you keep track of which posts a user has already seen, and when they hit the next page button, show them the X most highly ranked posts that they haven't yet seen. Breaking the link is just the easiest way to deal with the problem.
Actually I don't think any of the outages have been caused by this. The prospect does add an edge of excitement to programming though. Gamification for programmers!
Good catch. But strictly speaking that wasn't doing development in the repl, but repairing data. The live server is the only place you can repair data on the live server.
Yep. That's the kind of thing which is fun for hn but wouldn't be a good idea at all on a financial system -- where you optimize for least bad likely worst case, not best best case.
For everyone who claims there is one true way to write successful software, it should be noted that one of the most popular (or least influential) sites frequented by developers was built on the live server using the REPL!
Maybe PG is the exception that proves the rule, but damn that's awesome.
One of the major benefits touted by the proponents of Agile was that it modeled how successful software teams worked. Well here's a successful software team and this is how it works.
For most teams it is probably a truly bad idea. But it shows there is more than one way to do it.
Update: The more I think about it, maybe this isn't so crazy. Wasn't Erlang built to work this way, so engineers could modify a telecom switch without taking it offline? As systems get gigantic it gets very difficult to have a staging environment that mimics the live site.
Thanks for saying the site is high quality, but if so it's despite (or possibly because of) the fact that much of the development happens in the repl of the live site. There are not a lot of whitepapers around here. We tend to think by writing code.