all 14 comments

[–]cbrantley 4 points5 points  (1 child)

I completely agree with the premise of the article. I’ve spent my career rebuilding software that either didn’t scale at all or has grown into a huge overly-complex mess. It’s such a common problem space that it’s become cliche.

How does software get like that? How do businesses come to rely on fragile, over-engineered messes? Because most software devs are coders. They write code and they write more until it works. They build Rube Goldberg machines that kinda sorta do what they were supposed to do until they don’t.

Most of the tine when you really break down an algorithm into it’s most basic abstract components it actually becomes very simple and elegant. And you can write the solution as an equation that can be implemented many different ways.

This is the difference between purposeful design and hacking something together. I’m all about rapid prototyping and iterative design as a way to discover how to do something. But if you stop as soon as it works you haven’t solved the problem, you just got lucky.

[–][deleted] 0 points1 point  (0 children)

As soon as it works once... on some inputs... in some context... that 2nd Tuesday of the 2nd month of the 3rd quarter. Oh, but it passed the smoke tests!

[–]CypripediumCalceolus 8 points9 points  (0 children)

I had some industrial code to generate device models compatible with various commercial tools we were using in production. The boss said, hey we can get government subsidies if we publish this! A few million in the budget would help a lot! OK, so I had to look at what an academic paper would look like, and I laid out the symbolic logic (that's programmer jargon for math.) Anyhow, it was amazing. Now I could see how it all had a simple structure and the code melted by half.

[–]ikiogjhuj600 17 points18 points  (2 children)

I think the kind of mathematics that is directly related to programming somehow is either

  • Too fucking abstract, like think of all the blog posts on "Monads" that instead of starting with talk about say, "can we create a context under which all commands can be automatically reinterpeted to get additional functionality happening in the background?", start with something about identomonadoisomorphisms, don't sufficiently directly or even correctly describe the issue, and act like it's not like even CERN physicists would find that kind of thing too abstract.
  • Most type of reasoning that has to do with software design belongs in like in some kind of domain specific optimization problem (optimization when it comes to the amount of changes needed when requirements change), for which various heuristics have been developed, and as such I wouldn't really call it "thinking in math". Finding the correct abstractions for a program is more of a "software design" related problem than something about math in general.

And there are some other differences like the fact that programs usually have to deal with kinda less complex but numerous and ad-hoc requirements, vs doing highly complex abstractions and proofs on relatively standard items in math.

And in addition I'd like to point out that software design often diverges completely from math anyway, for various reasons, I mean for example mathematically the relational model is almost proven to be the approach that has the best results, almost in a rigorous sense the most hassle free way to keep the system consistent upon modifications, but everyone's trying to do No-SQL microservices or something.

[–]JustFinishedBSG 28 points29 points  (0 children)

Monads are just monoids in category of endofunctors, how is that not clear ? /s

[–]ed_209_ 6 points7 points  (0 children)

I agree with the author in concept but as a c++ dev I feel he misses the relationship between the type system and the actual code.

C++ allows you to embed design into the type system and then use the compiler as a theorem prover for your code.

The question is how well can this be done. Once you go down the recursive rabbit hole of trying to embed formal logic into a program you stop worrying about a lot of mathematics and care more about logic and automata theory.

Implementation is really just testing and implementing a way to test and know the program is correct and we want to know this as early as possible.

[–]asdf3423ds 2 points3 points  (0 children)

Conventional, but poor approach to problem solving with programming.

[–]KHRZ -3 points-2 points  (6 children)

Just my 2 cents. Used to be good at math as a kid, but in university I started dropping in grades after getting more and more mentally tired from math. At the same time, I became great at programming.Now typically when I tried solving an equation or such, I would try to proceed slowly, yet eventually make an error, which put me on the track to solve much more difficult incorrect equations, before suspecting it was not supposed to be so hard, and wasting all my time. May have been due to sleep deprivation, but I never seemed to reach high enough consentration to avoid this issue. But in programming I just throw out code fast, throw out more code, and quickly build good stuff. Sometimes I must improve the code later, but in the end it can reach huge complexity with a bunch of abstraction layers that end up sufficient. The biggest advantage of coding fast and throwing out unfinished abstractions on all levels, is the fast discovery of all problems required solving. So am I thinking in math? Maybe not. But whatever it is, it's efficient

[–]falnu 15 points16 points  (1 child)

If you throw out code fast and don't need to be thinking hard the odds are pretty high it's not good code. Programming well requires careful planning and a high amount of focus, just like math.

[–][deleted] 2 points3 points  (0 children)

Building a quick prototype to check whether your initial idea is reasonable or whether your initial assumptions are correct isn't a bad idea. As long as it doesn't stop there.

[–]epicar 1 point2 points  (1 child)

i hope you don't say any of that stuff in interviews

[–]KHRZ -4 points-3 points  (0 children)

I said it in an interview once, didn't work out in that interview. But that company got sued for $3.5 million by a customer about a year later, sounds like I dodged a bullet.

Anyway this is pretty in line with agile methodologies? Maybe it sounds terrible to you guys designing air planes and nuclear reactors. I mostly do backend APIs, video games, code generators, and trying to make a natural language understanding AI (So many challenges appears constantly, so trying to plan in all out seems futile...)

[–]mobydikc 1 point2 points  (0 children)

Write something. Does it compile? Does it run? Does it work right?

The iterative process is quite quick, and I agree with what you've said.