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.
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.
I can code and not test behavior and have that behavior work reliably without tests. Key word is the unit trst. Typically IO and things that live outside these boundaries need integration tests.
Most of web programming today actually doesn’t need much unit testing. You’re not doing much processing. The web layer functions as a router and that layer is a meta layer that writes code that executes somewhere else.
Over half the code executes as sql. Integration tests are by far more important.
Boiling it down to an art is not reductionist. It’s true. Where is the scientific method in programming? How was a pattern deduced using the scientific method? If it was not deduced using the method then was it created from axioms and logic like math? Is it a theorem?
No. It’s all just made up. And we have no quantitative way of verifying why one design is better than another design. That’s why software technology often moves horizontally. There’s no way to verify the current design was better than the last.
Even both you and I have a disagreement and are at a stalemate. Can you prove your unit testing is superior to my static testing? Not really. Actually tbf static checking is provably better if you don’t count the dimension of effort required to use dependent types.
Oh, I agree that there usually isn't a scientific method to programming. I think there could be though. Not for everything of course, some things will always be up to personal taste and interpretation but the cursor could probably be moved with some effort in analyzing existing codebases at scale, doing surveys, internal testing of different approaches in large companies. Something more akin to what you see in social sciences, even if it might be a bad word in some circles!
We probably won't agree but I legitimately enjoy hearing about how people code.
The other language is rust. Though it's type system is not as expressive as typescript it is strict meaning nobody can really cheat their way out of it. In general Rust code requires less unit tests then typescript because of this.
The other language is Idris and Haskell. But these languages are rarely used.
This article can shed some insight into what I'm talking about: https://wiki.haskell.org/Why_Haskell_just_works#:~:text=The%...
Since you're doing your own parsing rather then using schema validators and existing formats like json, yes your code is doing A LOT of data processing and thus requires a lot of unit tests. Most of the time developers can trust the parsing libraries.
Parsing is kind of… everywhere. Path piece instances? Parsing. Forms? Parsing. The whole point of smart constructors is parsing. Deserialising from the persistence layer? Parsing. Sure, JSON and Protobuf also, but even when relying on a robust library like aeson, we still write tests. Why wouldn’t you? The types you define can be serialised in different ways, and the way you deserialise needs to roundtrip with the way you (or an external system) serialise(s), which also necessitates more tests.
Here is a clear example of what I am talking about.
https://jezenthomas.com/2022/12/at-least-roundtrip-serialisa...
No. It’s all just made up. And we have no quantitative way of verifying why one design is better than another design. That’s why software technology often moves horizontally. There’s no way to verify the current design was better than the last."
Thanks for saying this. I've never stopped rolling my eyes at the assertion that web programming is an engineering discipline.