Doc Avid Mornington

Not actually a doctor.

  • 0 Posts
  • 51 Comments
Joined 1 year ago
cake
Cake day: July 5th, 2023

help-circle
  • If your SQL model has nulls, and you don’t have some clear way to conserve them throughout the data chain, including to the json schema in your API contract, you have a bug. That way to preserve them doesn’t have to be keeping nulls distinct from missing values in the json schema, but it’s certainly the most straightforward way.

    The world has more than three languages, and the way Java and Python do things is not universally correct. I’m not up to date on either of them, but I’m also guessing that they both have multiple libraries for (de) serialization and for API contract validation, so I am not really convinced your claims are universal even within those languages.

    I am not the other person you were talking to, I’ve only made one comment on this, so not really “hellbent”, friend.

    Yes, I am pretty sure I read the comments, although you’re making me wonder if I’m missing one. What specific comment, what “case specified above” are you referring to? As far as I can see, you are the one trying to say that if a distinction between null and a non-existent attribute is not specified, it should universally be assumed to be meaningless and fine to drop null values. I don’t see any context that changes that. If you can point it out, specifically, I’ll be glad to reassess.




  • At the (SQL) database level, if you are using null in any sane way, it means “this value exists but is unknown”. Conflating that with “this value does not exist” is very dangerous. JavaScript, the closest thing there is to a reference implementation for json serialization, drops attributes set to undefined, but preserves null. You seem to be insisting that null only means “explicit omission”, but that isn’t the case. Null means a variety of subtly different things in different contexts. It’s perfectly fine to explicitly define null and missing as equivalent in any given protocol, but assuming it is not.





  • It’s better to have useful comments. Long odds are that somebody who writes comments like this absolutely isn’t writing useful comments as well - in fact, I’m pretty sure I’ve never seen it happen. Comments like this increase cognitive overhead when reading code. Sure, I’d be happy to accept ten BS useless comments in exchange for also getting one good one, but that’s not the tradeoff in reality - it’s always six hundred garbage lines of comment in exchange for nothing at all. This kind of commenting usually isn’t the dev’s fault, though - somebody has told a junior dev that they need to comment thoroughly, without any real guidelines, and they’re just trying not to get fired or whatever.



  • Pretty sure they meant to not have review. Dropping peer review in favor of pair programming is a trendy idea these days. Heh, you might call it “pairs over peers”. I don’t agree with it, though. Pair programming is great, but two people, heads together, can easily get on a wavelength and miss the same things. It’s always valuable to have people who have never seen the new changes take a look. Also, peer review helps keep the whole team up to date on their knowledge of the code base, a seriously underrated benefit. But I will concede that trading peer review for pair programming is less wrong than giving up version control. Still wrong, but a lot less wrong.



  • Saying that some projects, at some point in their lifecycle, don’t need certain things, is not saying that those things have no place. Also, if one can’t design a monolith that isn’t bloated and tightly coupled, one definitely has no business designing microservices. Using microservices is neither necessary, nor sufficient to achieve decoupling.

    Monolithic services are the ideal way to begin a project, as using basic good practices, we can build a service that does many things with minimal coordination, and as it grows and requirements change or are discovered, we can easily refactor to keep things simple. As the software matures, we find the natural service boundaries, and find that certain pieces would perform better if they were separated out and could scale independently, or act asynchronously. Since we have followed good practices, this should usually be a simple matter of removing a class or module to a new service, and replacing it with a facade, such that the rest of the monolith doesn’t have to change at all.


  • I think Vim is more popular with sysadmins because, historically, you could count on Vi or Vim being available on just about any server you had to do some work on, while Emacs might not be. That’s still probably somewhat true, although in the world of clouds, containers, and source-controlled, reproducible configuration, it’s probably less common to edit files in place on a server.

    However, with Emacs tramp, you can edit files just about anywhere you can access, by any means, even if there is no editor installed there at all, using your local Emacs, with all your accustomed configuration. Like popping open a file inside a container running on a remote server by ssh, something I’ve done a lot of lately, debugging services running on AWS ECS.






  • At the same time capitalism has built almost everything we have.

    Almost everything I can see and touch has been delivered by a for-profit business operating in a capitalist society

    There’s a couple ways to interpret these statements.

    Are you talking about innovation, progress, invention? Realistically, no. Occasionally capitalists put enough resources in the right hands that somebody working under capitalists manages to invent something good, but most real innovation doesn’t happen without government funding. Capitalists are very hesitant to risk their capital on the kind of critical R&D that is necessary to make progress. Even when it happens under capitalism, there’s no reason to think that capitalist control of the market caused it to happen - any system that gives creative people the time and resources to work on things will have as good results, at least, and it’s easy to construct a system that gives that time and resources to more creative people, with fewer bosses interfering and squashing anything that’s not seen as profitable. Capitalism is, though, very good at capturing and controlling innovation, sometimes even just killing existing innovations outright - see “embrace, extend extinguish”.

    Are you talking about manufacture and delivery of final products? Sure, under capitalist systems, of course it’s all done by capitalism, as other options aren’t available, or at least, aren’t given any room. If somebody builds a fence around the lake that everyone fishes in, and takes over the fish and sells them to people who used to catch their own, do you praise that person for providing fish? Do you think landlords are providing housing?

    Capitalism isn’t just commerce. Capitalism is an antidemocratic economic trait, where the production and distribution of goods, services, and information is controlled by unelected, private owners of capital. Does it “destroy everything we build” as the person you were replying to said? No, not everything, but it does destroy a lot, and control and pervert most of what’s left.