A seductive idea, but ultimately of stunningly limited use in software engineering. By far the most costly defects in software creation are due to incorrect requirements or poor systems design. Knowing with mathematical certainty that your software component does exactly what you have specified it to do helps little when what it does is still the wrong thing.
And that doesn't even touch on the fact that crafting components is but a tiny part of the work required to produce software.
Absolutely. Most of the code being produced around me is of the "When button X is clicked, send an XML message to service Y letting it know the contents of textbox Z."
I'm sure this can be modelled mathematically, but I'm not convinced this would help.
I'm not sure. The OP raise the fact the SQL is modeled after set theory. I happen to have learnt set theory a very long time ago, and to use SQL as much as any web developper around. Then I read a book about foundations of SQL, and found out it can and should be seen as an implementation of the set theory.
And you know what? It was like a revelation to me. It is incredibly helpful. And, by the way, it make me laughing inside each time I query MySQL (because MySQL is sadly /not/ a correct implementation, while PostgreSQL is). The "dots connecting" between set theory and SQL made also much clearer to me the NULL "mess" and why it has to be like that.
So, on this part I'd push the same way as the author, and would go as far as saying that doing correctly a "button X pushed -> notify API Y + persist the action to Z" simple glue code thing /is/ requiring a mental activity that (probably) uses the same parts of your brain as any mathematics and the use them the same way.
However I don't get why the author seem to be ranting against Test Driven Development. In my experience it is unrelated to how you model you data and interactions, except TDD will do exactly as the author is advocating: it will force you to write stateless atomic functions, to make them testable.
NB: From all I have read about mathematics on HN, it seems to me possible that we are not talking about the same thing. Maybe you and many other refer to some "sin a + sin b = cos sin ..." memorization exercise, and some multiple choice questions one have to check as fast as possible in order to get some good enough ranking.
I am talking about a teacher spending around 20 hours a week during several years in front of young people, telling them step by step how the world can be described, analyzed, understood with their brain. It started with: first predicate, there is something, at least one thing. Let's take this thing in your hand, and nothing else: you have a set. In your other hand let's take nothing: you hold now another set, the empty one. Then you have two different things. And on this the teacher built the set theory. (I was educated in France, when math were still on their pedestal).
"""I'm sure this can be modeled mathematically, but I'm not convinced this would help."""
Why would a mathematically modeled system of key-value observing would not help? For one, it would enable one to prove and examine all kinds of assumptions about the model working correctly.
> By far the most costly defects in software creation are due to incorrect requirements or poor systems design.
I'm willing to bet those can be fixed with math. By formalizing the requirement, you're bound to spot any inconsistency, and probably even some other kinds of errors. Same with systems design. "Small is better" and "low coupling is better" for instance, can be formalised and measured.
By the way, you can't escape the fact that ultimately, the final program is supposed to be a formalization of the requirements. Inevitably, the messy ideas in the brain of the customer are bound to be reduced to math. Better use simple math as early as possible, so you can easily check them against the requirements. (Of course it won't happen because most people either won't be able to see the math behind the requirements, or won't bother).
That implies that you can specify all requirements in a mathematical form, which is not the case. How do you specify a usability requirement? Software is for humans, that makes it messy, even down to the requirements level.
> That implies that you can specify all requirements in a mathematical form, which is not the case.
I concede that requirement themselves can't be completely reduced to math. But most of them can. Also, the system itself (excluding human operators) can definitely be reduced to pure math.
What I was proposing was to check the pure math specification against the mostly math requirements. If such math are simple enough, it should be easy enough to make sure the specs match the needs.
Agree, bur if you don't know how that relatest to math, then you will not discover how math fixes "poor system design" and, as a side effect "incorrect requirements"
Here's the devastating truth: people with a half-assed knowledge of CS but with good other skills (project management, communications, customer service, people interaction, etc.) can and will often make unarguably better software than people who just get the fundamentals right.
You can spend all your life building the perfect implementation of a crappy system, but that won't rescue it. Good CS fundamentals (even provably correct algorithms and implementations) has its place in the software craft but that place is a fairly small niche, not the top of the heap.
gathering requirements has more in common with psychology, sociology and communication skills than mathematics. to make good software, you need to know what it needs to do much better than your customer, unless it's a really small thing.
Correct. This does not oppose my original statement.
Math is not just arithmetic or geometry. Is also a way of thinking and a way to sort and structure your analysis. Which helps you to know how to use psychology to ask the right questions, which leads to understand what needs to be done better than the customer.
And that doesn't even touch on the fact that crafting components is but a tiny part of the work required to produce software.