Ask HN: What are your unpopular opinions about programming?

That's fascinating. You should do a writeup about it!

I had thought (perhaps incorrectly? it's not something I've spent a lot of time pondering) that a stateful connection like this is fragile in the real world compared to HTTP because it requires some sort of manual reconnection to the server on network changes (like if you're on a phone in a train or in a car), and that it would require both the server and app itself to be aware of what is dynamic realtime data, what is cacheable, what is stale, etc. Like kinda related to your other statement about state... doesn't this mean you're sharing and syncing state across both the server and the client?

Competitive video games operating over UDP are the closest everyday analogy I can think of, where the server handles most state (and is the ultimate source of truth) but the client optimistically approximates some stuff (like player movement and aiming), which usually works fine but can lead to rubber-banding issues and such if some packets are missed. But most gaming happens between one server and just a small handful of clients (maybe 100 or 200 at most?).

In a web app, would the same sort of setup lead to UI jank, like optimistic updates often flicking and back and forth, etc.? I suppose that's not inherent to either HTTP or websockets, though, just depends on how it's coded and how resilient it is to network glitches.

And how would this scale... you can't easily CDN a websockets app, right, or use serverless to handle writes? You'd have to have a persistent stateful backend of some sort?

One of the things I like about the usual way we do HTTP is that it can batch a bunch of updates into a single call and send that as one single atomic request that succeeds or fails in its entirety (vs an ongoing stream), and it doesn't really matter if that request was one second or one minute after the previous one as long as the server still knows the session it was a part of. Like on both the client and the server, the state could be "eventually" consistent as opposed to requiring a stable, real-time sync between the two?

Not disagreeing with you per se (hope it didn't sound that way), just thinking out loud and wondering how the details play out in a setup like this. I'm definitely intrigued!

I have realized this morning, when I was riding in the bus, that my habit of creating a new side project every 6 months, working on it for maybe 2-3 months of relatively high productivity, and suddenly losing interests afterwards (usually not finished, or not polished), probably means that programming is an addiction to me.

No one is using my project, and I'm not exactly learning a lot from them, except in the first half of each one because whatever afterwards is just polishing (e.g. I did an interpreter project on a Python subset a year ago, and TBH the whole concept was pretty straightforward once my brain got it in the first few weeks). It's more of an obsession and that probably explains why I got burned out after 2-3 months and COMPLETELY lost interests in it. Looking at my GitHub commit history, it is always 2-3 months of almost daily commits compensated by 3 months of absolutely non-activity.

I don't think this is the right path for me if I want to leverage my side projects to get a job in low-level programming. Either I figure out how to drill deeper into each of my projects, or I need to figure out how to remove the burnout every 2-3 months. If the market is good I'd go straight to apply for system programming jobs but right now it's even tough to keep my own job.

So this is my unpopular opinions about side project programming -- if you are like me, maybe it's time to rethink the strategy. We only have one life, and I'm already 42. Gosh! Maybe I (we) should just find another hobby.

Strong types are not orthogonal to dynamic types, but I'll assume you're referring to static typing instead. My opinion on this is static type systems are great and provide amazing fit when you can model an entire system (e.g. a compiler). I think they are overrated for typical business software subject to change over time. IMO this is because business data tends to outlive any particular code base, or compiler version.

The way I see it is there's a spectrum of ways of handling this, from type systems, validation code, documentation, integration tests (validating runtime behaviour), and static analysis tooling, but I don't agree that a static type system is the best (and is often only barely adequate) way of integrating modules. The optimal solution is going to vary based on each project's requirements: e.g., is the modular code going to be consumed via networked API or as a library, and is it internally controlled or third-party? How many teams are going to be working on it? How much care has been taken with backwards compatibility? If we break the interface of some random minor function every update, a static type system may help, then again if it's just for our team: who cares? I'm sure we've all seen updates make internal modifications that break runtime behaviour but don't alter data models or function signatures in a way that get's picked up by a compiler.

Even in the most extreme type systems, interfaces are eventually going to need documentation and examples to explain domain/business logic peculiarities. What if a library interface requires a list in sorted order? Is it better to leak a LibrarySortedList type into the caller codebase? The modularity starts to break down. The alternative is use a standard library generic List type, but you can't force the data to be sorted. To encode this type of info we need dependent types or similar. A different example would be a database connection library, every database supports different key/value pairs for connection strings. If the database library released a patch which deprecated support for some arbitrary connection string param, you wouldn't find out until someone tried to run the code. Static analysis tools may catch common things like connection strings, but IME there's always some custom "stringly" typed values in business applications, living in a DB schema written 10+ years ago.

We also have to consider that the majority of our data arrives serialised, from files or over the wire. It's necessarily constrained to generic wire protocols, which have lower fidelity than data parsed into a more featured type system. Given that this type of data is getting validated or rejected directly after deserialisation, how much extra value is derived from having the compiler reiterate your validation code? Non-zero for sure, but probably not as much as we like to think.

It is the same level of fragility compared to HTTP because most HTTP connections now are stateless keep-alive connections. The solution to this fragility is to open a new connection after the prior connection breaks. You will know when the WebSocket connection breaks in both the browser and Node because there is an event exactly for that. That new connection request can occur via timed intervals or as needed at next message, depending upon concerns of directionality and urgency.

Transmission is not a function of state. Your application gains greater durability when those two qualities become fully independent of each other.

Transmission jank is a concern for web servers that come down and then back up with restoration of many concurrent connections. The solution to that is stagger connection establishment in batches and intervals. This is not a normal operating concern though, because how often does your web server crash on you in production if you have 10,000 or more active connections.

As for CDNs leave static asset requests to HTTP. For performance these files should be consolidated to the fewest number of requests balanced against initial rendering concerns in the browser. This should also typically be limited to initial page request.

This is surprisingly popular among programmers