Principal Engineer for Accumulate

  • 4 Posts
  • 13 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

  • That’s a hot take. If you want your code to be maintainable at all, it needs comments. If you’re part of a team, write comments for them. If someone else may take over your project after you move on, leave comments for them. And have you ever tried to read uncommented code you wrote a year ago? Leave comments for yourself.





  • Of course, but OOP is typically about putting methods on classes, inheritance of behaviour etc.

    You’re referring to one subtype of OOP. That may be what most people mean when they say OOP, but that doesn’t make it correct. Object-oriented programming is programming with objects, which does not require inheritance or classes.


  • I’ve done a little bit of Python in the past, the biggest thing being an automation task that borderline became an app. I certainly can imagine using it for scripts, though I default to bash because that’s almost always available but TBH mostly because inertia. Beyond that my default is Go because inertia (and I love Go). I watched a video by the Primeagen (on YT) - in his view, Rust is better for text/data pipelines and CLI tools. Being very familiar with Go and not at all familiar with Rust, that’s an interesting take because honestly writing a CLI in Go is kind of meh.



  • For references within a scope, you’re probably right. For references that cross scope boundaries (i.e. function parameters), they necessarily must consume memory (or a register). Passing a parameter to a function call consumes memory or a register by definition. If a function call is inlined, that means its instructions are copy-pasted to the call location so there’s no actual call in the compiled code.


  • Making good UX is fucking hard. I say UX because making it good is really about the user’s experience, not graphic design. An ugly front end can be good if it’s intuitive and easy to use. But a visually gorgeous front end will still be garbage if it’s clunky and confusing.

    It’s really something you have to experience to fully understand. Ultimately it comes down to this: front ends have to deal with people, backends only have to deal with computers. So backends can be cleanly organized and well structured. Applying backend design principles to a front end will get you a CRUD interface - something that’s usable but no one really wants to use.


  • I think the degree of footgun danger depends a lot on the language and the application. I agree that C and C++ are dangerous until you really know what you’re doing, though IMO most of the danger comes down to memory management and that’s a portable skill, once you’ve learned it. That being said, I don’t have a lot of experience with C++. C was my first language so I’m used to plain old normal boring pointers (are those “dumb pointers”?) and I’ve never understood why C++ needs 9 billion types of pointers.

    Go has one particular footgun - loop range variables. Other than that, IMO high-level, garbage collected languages don’t have major footguns like that. My first job was writing a bespoke inventory system for a manufacturing company, and I wrote it in a language I’d never used before - C#. In five years the only major issue that had was due to my inexperience with SQL and had nothing to do with C#. And though I haven’t written nearly as much code, I’d say the same about Java, Ruby, Python, and JavaScript.



  • Counterpoint: knowing a programming language doesn’t matter if you can solve problems. A competent programmer can pick up a new language and be productive within a few months. That is, a new language within the same paradigm - going from a imperative language to a functional language can be a drastic shift, but going from one imperative language to another is easy. If you can’t do that as a intermediate to senior developer, you’re not a competent programmer IMO.

    The real skills of a good programmer are things like problem solving, debugging, understanding how to write readable and maintainable code, etc. Having deep knowledge of a specific programming language or languages is helpful and enables you to work faster, but if you’re only a skilled developer in the languages you know - if you aren’t capable of pivoting those skills to another language - you aren’t a skilled developer IMO.