The objective of Mathematics is to produce theorems, stated generally as possible.
The objective of Applied Mathematics is to produce examples from theorems. Sometimes, the examples are general enough to be, themselves, theorems.
- There is a big overlap of Mathematics and Applied Mathematics. Examples often lead to new theorems, and vice versa.
The objective of Physics is to do calculations that predict physical phenomena. Physics uses theorems to produce examples. It's a lot like Applied Mathematics.
The objective of Engineering is to build stuff and processes. Engineering uses Physics to make sure stuff will work. Making sure that processes work is a lot like designing games. Games are a big part of Mathematics and Applied Mathematics.
Stated differently, Mathematics uses axioms to produce equations. Physics uses equations and machines and games to produce knowledge about the physical world. Engineering uses equations and knowledge about the physical world to produce machines and games.
-
Old joke: "If you know what you're doing, it ain't Science; if you don't know what you're doing, it ain't Engineering."
-
New joke: "If you have only examples, it ain't Mathematics; if you have only theorems, it ain't Physics." Ok, this isn't funny. But it is analogous to the Old Joke.
There is another middle ground: Mathematical Physics. The objective is to produce theorems in the corners of Mathematics most relevant to Physics, to produce more Mathematical knowledge. Calculation is seldom the objective of Mathematical Physics. It might be better called Physical Mathematics, but that sounds weird.
I've been a connoisseur of Mathematica since 1982, long before it was a product. It was called SMP back then. I borrowed it from a Caltech professor to check my calculations of GPS clock corrections. I realized, then, that it was an extraordinary programming language on top of being a great calculational tool. I was right! It's stood the test of time and presaged many of the great advantages of functional programming by decades. Notably absent from Mathematica is native object-oriented programming (OOP). Far from being a deficit, in my opinion, it's a strong demonstration that OOP really isn't necessary. Sure, there are many nice things in OOP, best being data abstraction and interfaces, but it's easy to do those in functional style. Nevertheless, I use Mathematica routinely to design and debug code that I eventually write in C, Python, or Clojure for real-world deployment or for sharing with others.
The following links are to problems that I find perticularly interesting by other people in Engineering, Physics, Mathematics, and General Computing.