Comment by ninetyninenine | Hacker News Reader

Comment by ninetyninenine | Hacker News Reader

Parent Full thread

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 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.

You don’t agree because you likely aren’t utilizing static checks to the extent that I do. Like there are no strings or numbers in my code. Everything is operating on strict union type boundaries. The only place where you have unbounded types like strings is on the interface to IO or state.

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.

That's an interesting approach, I'd like to see an implementation of what you're talking about. What language are you using that has such an expressive type system?

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.

Typescript is capable of dependent typing, union types, exhaustive matching and everything needed to achieve this style of programming. It's just not strict.

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%...

Thanks, I haven't touched Typescript in a while so it might be the occasion for that. When do you feel like you have a handle on the behavior, do you have complex integration tests then?

I write a big web application with a fairly type-oriented language, and I still write lots of unit tests. Mostly to do with parsing.

Yeah. That's where it should be. Usually though you don't need much parsing as it's coming in as json or a protobuf. But the interface between IO and your code program is where exceptions and errors can occur. Beyond this boundary your code should be pure and deterministic.

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.

What you’re describing isn’t exactly new territory for me. Maybe you’re writing for the room, and not immediately for my benefit.

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.

I wouldn't because the deserialization library is tested to death by the library maintainers.

I don’t think you are understanding me.

Here is a clear example of what I am talking about.

https://jezenthomas.com/2022/12/at-least-roundtrip-serialisa...

> "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."

Thanks for saying this. I've never stopped rolling my eyes at the assertion that web programming is an engineering discipline.

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.

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.

Reply on news.ycombinator.com