And that doesn't even touch on the fact that crafting components is but a tiny part of the work required to produce software.
And that doesn't even touch on the fact that crafting components is but a tiny part of the work required to produce software.
I'm sure this can be modelled mathematically, but I'm not convinced this would help.
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).
Of SQL maybe, but of Relational Algrebra/Set Theory, neither PostgreSQL is.
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.
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).
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"
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.
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.