They certainly are. Also, geometric proofs are considered the origin of all mathematical proofs. They might seem crude, but open up to any chapter in Elements and you'll see many difficult problems solved using those 5 axioms.
My high school calculus teacher was really great at this. He didn't just teach a bunch of transformations to memorize. That was part of it, naturally, as you aren't going to use the definition of limits and the FToC in all your problem solutions. He actually made us construct volumes from pieces of poster board, measure the segments and calculate the Riemann sum. When we did function analysis, he didn't allow us to use the Cartesian plane at first. We had to show visually how a function deformed the one-dimensional real line. How x^2 squished values between -1 and 1 toward 0 and stretched the other values toward +infinity.
It gave me a good "visual" grasp of the concepts and made most of my higher math classes much easier.
I do agree diff eq instruction sucks. I got an A in that class and didn't understand a thing. "This equation has this form; this is the canned solution."
I kind of feel the same way. I read "Age of Spiritual Machines" 15 years ago and thought it was interesting. But now I don't believe most of what he says or predicts. Some of the stuff will come true, but we won't be Matrix-like entities. I also don't like how he downplays (or completely neglects) social backpressure to technology adoption.
Edit: His health regimen is also completely ridiculous.
Our AWS rep is nice and cheery. He'll come into our office twice a year and bring sales engineers to hear about our upcoming projects. There's one lead developer on our team who keeps imagining systems that use half a dozen AWS services for "big data". The AWS dudes always end up talking to him the most and they definitely bait him with various pitches and, of course, feed his ego. Good thing that he's so disorganized and delayed that he never has a chance to waste company money on all that bullshit.
"we don't have the time or skills to maintain these open source components" translates to "we don't want to install a monitoring solution that restarts a service when it fails, or think about design in regard to component failure".
It's such a poor argument. I was a developer long before AWS appeared and I've used so many open sources packages that were profoundly reliable. In many cases it just takes a daemon restart. And while it's not exciting to set up some of that stuff, it's far more tolerable than writing a CloudFormation template.
I warn other developers at my company about this. When new projects spin up they're often very excited about using new Amazon services and will make any excuse to choose an AWS product over a stable open source solution. If I were a manager, I'd be very worried over the vendor lock-in.
I don't understand the preference for AWS over open source in many cases. Their services are "reliable", but they often have minute restrictions that will eventually bite you. You also end up having to pay for something you could get for free. Why use SNS/SQS when there are free pubsub/message buses out there? Most of the other devs justify this with the argument of not having to maintain the software themselves. "But RabbitMQ might crash! We don't have to worry about that with AWS!"
Anyway, I typically minimize the AWS services I use (S3, EC2, ECS) so I don't dread the day AWS blows up or, more likely, some VP or exec says we're moving to GCP/Azure because we got a better deal.
>Why use SNS/SQS when there are free pubsub/message buses out there?
Free is never really free. There's always a tradeoff in engineering time and money when you choose to run your own stack instead of paying to use a stable, well-established service. Oftentimes running your own will be cheaper overall, but you have to do that cost-benefit comparison for yourself.
You're also forgetting that if you set up something on your own you also have all the hardware concerns as well. You need to procure hosts, provision them properly, deploy them, monitor them, scale them, fix them. That infrastructure cost doesn't go to zero but it is significantly reduced using a cloud provider.
I'm not arguing against cloud platforms in general; just the irrational use of very specialized services they offer. I can run a containerized service that uses open source packages on any of the cloud computing platforms. Now if I used Athena, SQS/SNS, DynamoDB, ELB, Lambda, EC2 that would make me very nervous, and I see other devs designing these stacks all the time. I guess I shouldn't care as much, because I'm not going to be the one to migrate that when the company gets a better deal from another platform service.
> "But RabbitMQ might crash! We don't have to worry about that with AWS!"
I can confirm that not only can RabbitMQ get into an unusable state, it will do so extremely rapidly and with little warning unless you sit an engineer or two on it to monitor and manage the incoming/dead letter rates.
