>An engineer's model must be tightly bound to the laws of physics and chemistry.

Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too.

>Software is a lot like math,

Probably referring to computer science. Computer science is neither about computers nor is it a science. It is a math. Software is like math but applied.

>The only limitation is the imagination of the creator of the virtual world (and perhaps the pesky limitations of computer resources)

computer resources: AKA physical laws. And these "laws" highly limit us in what we can do. We are definetely not operating in some kind of playground where we can be virtual gods, not even close, that's why entire swe teams are involved and paid a lot in software.

Honestly the main difference between "Software Engineering" and "Engineering" is that software is more an "art". We make up a bunch of technical nomenclature for it (like design patterns which sounds technical but is mostly made up and more artsy then say statistical mechanics) but it's mostly similar to sculpture or some artistic creation as we sort of piece everything together by instinct.

The difference between this and engineering is usually engineering involves mathematical modeling and testing heavily in development, while software engineering (usually) does not involve mathematical modeling and software testing is more of a catch-all to find bugs.

Type checking is mathematical modeling, but I wouldn't call it the core of software engineering. I guess this is where the categories get blurry.

> software engineering does not involve mathematical modeling

it absolutely can, approximately nobody was doing that because it was insanely expensive. if we narrow down the definitions, modern static typing (where modern means universally accepted nowadays) is a form of mathematical modeling and proof construction that software does what it says it does.

the economic calculation is changing extremely rapidly now with LLMs though. some of my software is now proved to be correct at some levels, e.g. I heavily (that is, LLMs I pilot) use TLA+ for tricky but nowhere near foundational distributed systems work (as in, I don't work on core S3, but do distributed transaction stuff).

> Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too.

Agreed. If I have to guess, the relevant fields in physics for software engineering would be quantum mechanics and thermodynamics. Of course, we don't see any direct relation as of now but it feel it should be important to determine the physical basis of software. The basis of software cannot be just math. It has to be physics.

> Computer science is neither about computers nor is it a science.

https://youtu.be/-J_xL4IGhJA

Also person month is a very solid limitation.

> > An engineer's model must be tightly bound to the laws of physics and chemistry.

> Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too.

No. Software is only loosely bound by physics and chemistry. Sure, the bounds exist - they're real - but most software, most of the time, does not bump into them much at all.

But

> > An engineer's model must be tightly bound to the laws of physics and chemistry.

is also wrong. This is using a pre-software definition of engineering to try to define software engineering. It would be like trying to use a pre-Faraday definition of physics to define microwave engineering.