I'm sympathetic to this concept, and it's one I employ from time to time in the various codebases I own, but the type of person to advocate for this kind of thing is also the kind of person to write stuff like
> Types delineate the set of legally representable states |ℝ| in your application
and
> |ℝ|≥|ℙ|
Which sets off my "math" alarm. The less out-and-out math used to make a point about programming, the better, I think. This article is actually fairly good and doesn't get very mathy beyond the intro, but it still jumps out at me and made me wary to continue.
Why should math trigger an alarm in engineer's mind? The only thing that triggered my alarm is that it's a pretty bad math - why thinking in terms of cardinalities when we are really talking about subsets? And why use ℝ - which is an agreed symbol for a set of real numbers - for anything else than that?
It's a fair question, and in this particular case the math both light and irrelevant. But sometimes I see useful topics being discussed that are for whatever reason, marred by mathematics. Often these topics arent even particularly complicated, but the author's desire to give it (or themselves?) more credibility leads them to make it mathematical when it didn't need to be. See also, every discussion involving Haskell. A monad is just a Monoid in the category of Endofunctors, after all.
In most cases, especially cases of software engineering, as opposed to computer science, the math gets in the way of the point. It was never needed, it just served to obscure the topic. Plus, I'm not an engineer, and I'm not doing mathematics in my daily life. I don't think like a mathematician, I don't work with cardinalities, or set theory, or integrals. At most I deal with some multiplication and powers-of-two. Maybe a ratio here and there. If I was a graphics programmer, which I thankfully am not, I'd toss in some matrix algebra maybe. But my career doesn't involve anything requiring the use of ℝ. What it does involve, is thinking about composability of systems, debugability, simplification of processes, and otherwise making sure things work and can be understood by future maintainers. The article's topic is useful, but making things mathy for the sake of it is a navel gazing distraction.
> But sometimes I see useful topics being discussed that are for whatever reason, marred by mathematics.
it's not marred, but formalized by mathematics.
Maths is very unambiguous. It makes it so that you cannot interpret it wrong, as long as you learn the meaning of the symbols. The transformation of these symbols are logical operations, and follows on from previous operations.
By describing processes or thoughts this way, it ensures that what you say is formal - aka, someone else can follow the logic _exactly_ from the assumptions/axioms.
It also allows you to overlay proven theorems from other fields of maths and apply it to your current situation. By doing so, you can transform your problem to a known solved problem, and therefore, have a solution. This solution might be complicated and require knowledge from that field unrelated to your problem, but i dont think that's a problem with maths itself - it's a sign of your own deficiency.
Finally, maths forces you to think systematically. It forces your brain to adopt a style of thinking that most people find difficult, but it is what it takes to solve problems wholistically.
Two main reason: 1) I will never be able to easily type the fancy R. Anytime I need to type it I’ll need to google it or find a previous reference to copy paste. It presents bad UX for continued communication, and plain English would suffice given the math isn’t the point. Similarly, it would be inappropriate to use overly grandiloquent language if the writing wasn’t the point.
And 2), most engineers are not super comfortable with even relatively basic mathematical notation like this. If your audience is software engineers (and specifically not mathematicians), it’s better to say what you mean, in plain terms. While 80% of folks might know what you mean, it’s not worth losing the other 20%.
On the other hand, if the math is the point, then it is more than appropriate.
> most engineers are not super comfortable with even relatively basic mathematical notation like this.
I might be a bit out of date here. I can imagine how it could be true for bootcamp developers who never had relevant formal education, but I don't think they are a majority. Most engineers go through some kind of higher education program, be it CS or CE, and it normally includes a significant amount of math. How can you get around getting comfortable with it?
are we really at a point where “software developers should be competent in math” is a hot-take?!
If most engineers truly are not familiar with basic math notation, the solution should be to teach more math to engineers, not purposefully explain things in a less formalized way.
~~I KNOW I used the terms developer/engineer interchangeably, don’t kill me~~
So only mathematicians use math to explain concepts?
The actual example in the article isn’t that great but my point is generally it’s a valid way to explain or demonstrate something. That’s part of the reason we learn it.
> So only mathematicians use math to explain concepts?
No, only an audience of mathematicians grasp concepts explained exclusively with maths.
Why do you find this surprising? It's no more surprising than "Only an audience of carpenters grasp concepts explained exclusively with joinery terms".
Would you, with a a straight face, make the claim that explaining something using terms like "Cheek", "Mortise & Tenon", "long grain", "Dado" and "Birdsmouth" is a valid way to explain something unrelated to carpentry?
Why then claim that using mathematics terms to explain something unrelated to that specific maths is a good idea?
I mean, this article is a good example: not only does the article get the maths wrong, the maths involved is unrelated to what it the article is trying to explain.
I second this as I find that usually the solution that is the most mathematically pure is usually also the one completely inadequate at handling the complexities of real-world applications and end up having various extremely impure additions bolted onto them (as shell scripts or Excel spreadsheets on a shared network drive if necessary) because refactoring them into an equally pure solution for the real-world case would take too long.
Okay but the solution here is to identify and parcel your cases into discrete entities. The article doesn't say "don't accept anything odd", it says "clearly identify what you accept". If you have to accept odd cases, identify them so it's clear what's happening.
So this isn't about purity, it's about being declarative. i.e. make your code say what it accepts, instead of writing board/implicit acceptable inputs that inevitably forget cases and crashes.
If you limit what you accept as inputs then you can stop worrying about downstream error handling and debugging.
I think in many cases it's "pseudomath": all the information is carried in the explanation, and the notation isn't doing any actual work, so you could drop the decorative notation and just leave the explanation in English.
Yeah, yeah, yeah, software engineering is not Real-Hard-True engineering, we get it.
With that out of the way, isn't it better if software development concepts can be explained with less math-heavy notation while keeping the math notation for the cases precision is needed?
I for sure remember a dwindling amount of the math from my statistics bachelor in my head after 15+ years. I'm able to recollect it after re-reading some material, things usually click back in place but I won't be doing that unless it's very necessary.
Don't reject the not real engineering folk. I'm fairly certain the only reason companies are so eager to label all software developers as engineers is because there are often loopholes in overtime laws specifically for engineers, with the logic that the engineer was in charge of the project and the schedule, and if there are problems, that's on them.
I've yet to see a software project where an software engineer was given much leeway in how a project was run, scoped, or where any of their concerns about the scope, schedule, or lack of an actual plan were taken seriously... I'll gladly trade being falsely labelled an engineer for overtime pay to cleanup the mess on schedule yet again.
> Types delineate the set of legally representable states |ℝ| in your application
and
> |ℝ|≥|ℙ|
Which sets off my "math" alarm. The less out-and-out math used to make a point about programming, the better, I think. This article is actually fairly good and doesn't get very mathy beyond the intro, but it still jumps out at me and made me wary to continue.