3 ms·
> Programming is like building a bridge. Not quite. When you build a bridge, you'd better doing according to spec, or it will collapse. The specs better be s
by loup-vaillant 13y ago
> Programming is like building a bridge.
Not quite. When you build a bridge, you'd better doing according to spec, or it will collapse. The specs better be sound according to the known (mathematical) laws of physics, or it will collapse. Lot's of theorems to use, and lots of proving your design is sound.
Software is often more lenient, and as such less mathematical than bridge building.
But that doesn't help my point.
How would you go about proving a mathematical conjecture? You think, you talk to colleagues, you try approaches, you design tools (notations, programs that do math…). That's less formal than you might think. Heck, the proof you provide in the end is often not even machine checked! Coq users are often more rigorous than the most die hard mathematician in this respect.
Just like software writing and bridge building, the process of doing math is not mathematically formalized. In that sense, there is a lot more to math than math.
- seanmcdirmid 13y agoOnly a bit of math goes into building a bridge, though. It's not like the construction workers are continuously solving differential equations. Even when the specification is being written, math is just a tool to deal with constraints that are not identified using math. Quite similar to programming actually.
- loup-vaillant 13y ago> Even when the specification is being written, math is just a tool to deal with constraints that are not identified using math. I beg your pardon? You have to model the weather, come up with a whether distribution over the years, a probability of collapse each time you encounter such and such circumstance… The constrained are not only identified using math, they're often pinned down with math. > It's not like the construction workers are continuously solving differential equations. Sure. But when the differential equation tells them to screw that bolt here, they better screw that bolt here, or compromise the integrity of the bridge.
- seanmcdirmid 13y agoRight, but how many mathematicians does it take to build a bridge? Probably just a few engineers, and the process is probably very standardize. That architect probably isn't using much math in his/her design. Software is similar: there is some math involved, but it is often abstracted away and you might not ever be exposed to it.
- brudgers 13y agoSoftware practice is more lenient than bridge building practice, but only by virtue of being so new as to escape regulation. There's nearly four fucking millennia worth of precedent for regulating construction because people die from blunders. The lack of accountability for the consequences of programs is unlikely to remain the context for practicing development. But even 25 years ago The Morris Worm was a treated as a felony and the list of actions for which there is criminal or civil liability has only grown. At some point normal programming activities will entail the risk of such liabilities to a degree that programming entails a formal standard of care like architecture and civil engineering and orthopedic surgery. https://en.m.wikipedia.org/wiki/Code_of_Hammurabi https://en.m.wikipedia.org/wiki/Code_of_Hammurabi
- dagw 13y agoLot's of theorems to use, and lots of proving your design is sound. If you've actually tried to build an actual bridge you'll know that that is just a small, but very important, part. Getting the structural math right is necessary, but far from sufficient, for getting a bridge built. You've also got bridge and landscape architects designing how to make the bridge work in the existing landscape, you've got traffic and city planners working on exactly where the bridge should start and end and which roads it should connect to. You've got traffic analysts trying to work out the traffic flow implications on the large area based on the different placements of the bridge. You've got building engineers that are trying to work out how to build this thing on time and on budget. You've got logistics people working on designing the building schedule so that the right amount of people and building materials get to the right point at the right time. And then there are the finance people and the insurance people doing their magic money dance in background. Oh and lawyers arguing about land use and building permissions and whatever else lawyers like to argue about. And each of these decisions feed back into the structural calculations, and the results of these calculations feed back into all these parts and so on. And yes there is math involved in many of these steps, but that doesn't make the whole process a field of mathematics. Not everything that uses math is mathematics. PS: While I've never had the word "mathematician" on a business card, my Masters was in mathematics and much of the work I've done has involved modeling and data analysis, so I know in broad strokes how math gets done.
- loup-vaillant 13y ago> Not everything that uses math is mathematics. Of course not. And I never intended to say so. I originally said that "programming is applied math" (I insist on "applied"). Because if you ignore the math behind programming, you're running into trouble. Same goes for bridge building, by the way: you can't ignore math. It's like Dracula: you may not see it often, but it is ever present, and influences everything. (I'm not talking about the laws of physics here, but about a bunch of people doing math, then using the results to make far reaching decisions.) Saying that programming is a branch of mathematics is a stronger claim, but not such an outlandish one either. After all, it is all about the manipulation of a formal system. But I wouldn't go that far. Rather, I'd say computer science is math (not applied, just math).