Comment by ninetyninenine
9 months ago
Well I mean they wrote books about it and one guy had the audacity to call his opinion a “philosophy” even though it’s just an arbitrary opinion.
Most of software is about assigning big words and over complicated nomenclature to concepts and these things masquerade as things with deeper meaning when in reality it’s just some made up opinion.
Software design is an art. It is not engineering and it is not science. That’s why there’s so much made up bullshit. The irony is we use “art” to solve engineering problems in programming. It’s like ok we don’t actually know the most optimal way to program a solution here so we make up bs patterns and philosophies. But then let’s give this bs pattern some crazy over complicated name like Scientology or inversion of control and now everyone thinks it’s a formal and legitimate scientific concept.
Well cats out of the bag for Scientology. Not yet for a lot of the bs in software. A “philosophy” is the biggest utter bullshit word for this stuff I’ve ever seen.
But there are typical practices we agree are good: using a VCS, writing tests, write comments when needed, separate different level of abstractions, etc. Right? This comes from years of common experience in software.
Over time we get to find patterns, common issues and ways to fix them, etc. It doesn't have to be strict patterns but overall strategies.
If we don't do that then it's just vibes right? Where's the engineering part?
Nothing is fixed in stone. If you have strong typing and program with pure functions and immutability while utilizing union types and matching to the full extent you typically need very few unit tests for your code to work. You just need integration and e2e tests.
I write very little unit tests as my coding style that employs static checks as viciously as possible doesn’t necessitate it.
I would say only 30 percent of patterns are good and shared. The other stuff is just artistry and opinion. Like method name length or comments or OOP.
I don't really agree, unit test should test behavior, having types or not should not be a defining factor in the coverage.
I don't think patterns as a whole are good but there are known issues and structures to existing problems so boiling it down to art seems reductionist imo.
Could you give an example where you've used a "static check" where someone else might be likelier to use a unit test? I'm curious.
I don't really agree, unit test should test behavior, having types of not should not be a defining factor in the coverage.
I don't think patterns as a whole are good but there are known issues and structures to existing problems so boiling it down to art seems reductionist imo.
10 replies →
The issue is that programming is communication. Communication is indeed a form of art. Programming is not just giving instructions to machines, if that was the case we would be happily using binary code. So we have two dimensions, the first one is giving the binary instructions, but the other one is how to make these instructions understandable by humans, including ourselves.
No there are other dimensions to coding. Communication is ONE dimension only.
There is optimization and there is modularity. All 3 of these dimensions are intimately tied and correlated.