5 ms·
Came here to say this. But then realised my wife. She did a year of com sci. She learned SQL at work. She can Excel with the best at her bank, with some VBA he
by richardw 9y ago
Came here to say this. But then realised my wife.
She did a year of com sci. She learned SQL at work. She can Excel with the best at her bank, with some VBA here and there. Still I had to coax her into learning Python for some bigger-than-Excel datasets. She wanted to for ages but just couldn't make the leap to "real" programming (her thinking, obviously not true).
Even when she tried we had issues installing things. She made good progress and almost got it. I sat an evening with her and we solved the issue. She had a lot of support to get over the various hurdles, support many don't have.
Obviously it's one data point but it highlights the issue. I think we've forgotten how hard it can be. Anything that helps should get a shot.
- dustingetz 9y agoThis is great, thanks. I think the issue is, things quickly turn bullshit. Programming math is high school stuff, but imperative programming is bullshit. Memory leaks. Exceptions. Callback chaining. Asynchrony. Model-change listeners. Spooky action at a distance. Legacy interfaces. Functional programming fixes all that. Programming excel is college stuff. RDBMS is bullshit. JOIN pain, batching vs caching, ORM, pressure to denormalize for performance at scale, eventual consistency at scale. Non-RDBMS solutions generally make sacrifices regarding ACID vs consistency vs performance. Bullshit. Immutability in the database fixes that too.
- collyw 9y agoForgive my imagination, but an immutable database sounds pretty useless.
- dustingetz 9y agoUseless like git? :) Immutable here just means append-only. If old history is fixed it is really easy to have pervasive caching, which helps make chatty queries faster (e.g. solve N+1 problem)
- collyw 9y agoWell why not say append only?
- lcedp 9y agoWhy? Just create a new db if you want to make a change :-)