Quite the contrary, in my opinion. Lots of what makes various parts of the physical hard are in the infrastructure surrounding them. This is very similar to the complexity in software setups.
Take game systems, as an example; far far more effort will be spent in the art and general asset management than is true for many business software setups. Which is why many of the business best practices haven't necessarily moved over to games.
Similarly, look at the general practices around building and maintaining bridges in physical world. We call all bridges by the same name, but reality basically dictates that what works in some locations cannot and will not work in others.
Now, you are right that we can grow large software out of smaller in ways that the physical can't do. But, it is a common fallacy to stall out a project by trying to be at google's scale from the start. Ironic, in many ways, as not even google was built to be at their scale from the start.
I'm not sure what you're trying to say. Something like "the software world is complex, and so is the physical world, so comparing the two makes sense"? If that's what you meant, you're right, but the problem is that comparing the two doesn't lead to better insight in those. If that's not what you meant, then sorry, I didn't understand.
I think that in general we should stop using so much metaphors in the software world. There's no need to go look for a shed. If we had to statically type and test every shell commands we typed, we would lose lots of productivity. On the other hand, maintaining those very large scripts that started as a simple line and are now used for deploying all of our application, and tend to fail in surprising ways, would be easier.
The other problem with metaphors is that they are also hard to refute. I've never built a shed, nor worked on a high rise. I don't see why that experience would be relevant to building software, or necessary in a discussion about static typing.
I'm claiming that most of the complications that will actually influence many of the intrinsic choices of both, will be dictated by external factors. Static typing being an intrinsic fact of software, I couldn't tell you what most of the software I use, used.
Calling for lack of metaphor is interesting. In many ways, our industry is nothing but metaphors, so it is surprising for me to see them called down.
I agree that no metaphor is perfect. But, by that same logic, I would argue that no specified type is perfect. Especially if done so in a taxonomy that does not admit exceptions. (And again, I'm not against types.)
> Calling for lack of metaphor is interesting. In many ways, our industry is nothing but metaphors, so it is surprising for me to see them called down.
I don't think that's true. There are lots of metaphor because people love using metaphors, but it's not inherent to our industry. Abstraction is, but abstraction and metaphors are different. Metaphors seem to mostly come from blog-post type content, where people want to give you an intuition for something in less than 10 minutes. There's a really good article about this, in the context of monad tutorials, which are some of the most proheminent victims of these metaphors https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti....
> I agree that no metaphor is perfect. But, by that same logic, I would argue that no specified type is perfect. Especially if done so in a taxonomy that does not admit exceptions. (And again, I'm not against types.)
I would call types an abstraction rather than a metaphor, though I agree with you that they are not perfect, in that all abstractions trade precision and exhaustiveness for speed. There are interesting alternatives to this with property-based checking and whatever clojure.spec is, and type systems themsleves are getting better, but we're still not at perfection. And even then, I don't think we will ever reach it. The "best" type systems currently all seem to have some structural parts, and some nominal parts, so there's no silver bullet.
I mostly use types to avoid stupid mistakes (I make lots of typos, and Typescript helps a lot here), and to improve developer tooling. I'd like to try some approach with DDD and types, but my current company isn't big on DDD, so I can't really judge it. I also like using unit and integration tests. All of these make me feel safer when doing changes. But some people are fine with catching errors in production and quickly fixing them.
What I meant in our industry being nothing but metaphor is basically me staring at so many OO taxonomies. Even if you ignore deep OO trees (and I think you should), it is hard not to see the way we define most data and simulations as anything other than a very formal metaphor.
That said, I was not trying to say that abstractions and types are directly metaphor. I agree with your points. My argument there was that, like metaphors, types/abstractions are never perfect.
I use types to avoid type errors. Which is a big class of error, to be sure. But they do little to help with logic errors, in my experience. And they are flat detrimental if they require pulling in more and more formalism to cover cases that are of increasingly limited ROI.
If anything, I think our industry would do well to embrace many of the modelling domains that allow use of SAT solvers to find answers. And I don't think I've ever seen a strongly typed one of those that wasn't hard to follow. (I am interested in counter examples.)
> Take game systems, as an example; far far more effort will be spent in the art and general asset management than is true for many business software setups. Which is why many of the business best practices haven't necessarily moved over to games.
You're right that game development involves a lot of asset stuff that other business software doesn't have to worry about as much. (And, conversely, a lot of business software has to worry about large mutable datasets much more than most games.)
But I don't think that has much bearing on why some business software practices haven't made their way to games. I think the reasons are mostly:
* Games are structurally different from business software, so the patterns that work for the latter aren't always great for the former. MVC makes sense when the "UI" is a relatively thin layer insulated from the "logic". In most games, the "UI" (rendering, animation, VFX, audio, etc.) is huge and more deeply coupled to the game state.
* A lot of enterprise software practices are about maximizing developer productivity in a single codebase over a very long period of time at the expense of runtime performance. Game codebases often have a shorter lifespan and can't afford to sacrifice runtime speed for developer speed.
* Game developers can be insular and are often either oblivious to what's going on outside of games or think it's beneath them and not applicable to their "real" code.
I can't say with any authority on why practices are different between the different environments. So, to that end, I should have offered it as /a/ reason, as I don't think it is the sole one. I can't shake that it contributes, though. I mainly meant it is a counter to the implicit "devs at office job are too lazy to learn different ways."
For other examples, I would dip into major logistical simulations/optimizations. Which basically drop into linear algebra as soon as they can, where much of the idea of typing is basically thrown out, so that we can solve equations and constraints, with no real tracking of which is which at different locations. There is a tranlation in/out, but once in, things are effectively "matrix of values.
(As an amusing aside, I love that I get to message with the authors of books I'm reading on places like this. I have your Crafting Interpreters. Working through it at a glacial pace. Plan to pick up the other one next. Kudos and thanks!)
Take game systems, as an example; far far more effort will be spent in the art and general asset management than is true for many business software setups. Which is why many of the business best practices haven't necessarily moved over to games.
Similarly, look at the general practices around building and maintaining bridges in physical world. We call all bridges by the same name, but reality basically dictates that what works in some locations cannot and will not work in others.
Now, you are right that we can grow large software out of smaller in ways that the physical can't do. But, it is a common fallacy to stall out a project by trying to be at google's scale from the start. Ironic, in many ways, as not even google was built to be at their scale from the start.