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.
Imagine if an electrical engineer said this. Or an aerospace engineer. Or any real engineer.
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.
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.
So?
Lambda calculus and number theory are significantly hairier.
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.
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.
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.
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.
But I think it is often counterproductive when evangelizing a concept or explaining something to software developers.
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.
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?
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~~
Curry and Howard have some bad news for you https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspon...
> 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.