Doc Avid Mornington

Not actually a doctor.

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

help-circle
  • What? Your colleague sounds like they may be struggling with some serious cognitive issues, they may want to see a doctor about that. As for me, I’ve been living with my brain my entire life, and have kept several different sleep schedules in that time, for one reason or another, including rigid adherence to a schedule you would certainly approve of, and at no time has the basic fact that my brain works better later in the day ever changed. Some people never learn that their own circumstances and experience are not universal. Maybe try not to be one of those people.



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





  • Programming is the art of juggling of state and control flow

    Sure, stateless functions deal with and impact state in some way. If that’s what you meant by your previous comment, that’s fine, but that’s honestly not what would typically be meant by “juggling” state.

    The part about declarative languages has nothing to do with state. Declarative languages do not give the programmer control over flow, the other part of your definition.

    Learn Lisp, and you will never again be so certain about the difference between a programming language and a data format.


  • No, my question does not imply a pure functional language at all. Pure functions exist in languages which are not purely functional. Most of the functions I write are pure functions. I could have a workflow where I work with another programmer who handles the minimal stateful pieces, and I would only write stateless functions - would that make me not a programmer?

    (There are also purely functional languages, by the way. I just didn’t remotely imply there were, or make any claims about them, at any point in this thread, prior to this parenthetical.)

    The part about declarative languages has nothing to do with state, or functional languages. Declarative languages are a whole different thing. Of course declarative languages handle state. The comment I was replying to said “Programming is the art of juggling of state and control flow”. Declarative languages don’t involve juggling control flow.