So you’re arguing that “Object oriented” shouldn’t apply to languages that are oriented around objects?

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.

It’s hard to distinguish whether a line is wrongly indented or not.

That’s very much not my experience. I use YAML regularly and while I’ve had copy paste indentation errors when I look at the offending line it’s always obvious to me how to fix the indentation. The only indentation thing that’s ever given me trouble is embedding YAML as a string within a file that uses tabs.

If you have a solid idea of your competence, GitLab uses a calculator for salary and they make it public. If you don’t have a solid idea, ask someone who’s worked with you and who will be honest.

BTW someone said mid-level in SF is $200k, so my number may be way out of date.

A competent mid-level developer in San Francisco should be making in the ballpark of $120k salary. There are approximately 50 work weeks in a year (2 weeks of vacation) so 40 hours a week means 2000 hours a year or $60 an hour (for a full time employee). 2x for being a contractor and adjust appropriately for your level of competence/expertise and cost of living.

As someone whose first language was C, I plan to never use C++ for anything more than programming an Arduino precisely because of the multitude of pointer types. A pointer should just be a pointer. Having five hundred different flavors of pointers is confusing as fuck.

Ananace and the article they linked are using their dislike of Go to conclude that it’s a bad language*. It is not a bad language. Every language has hidden complexity and foot guns. They don’t like Go. Maybe you won’t like Go. That’s ok. But that doesn’t make Go a bad language. The language designers are very opinionated and you might dislike them and their decisions.

I haven’t used Rust but from what I’ve seen, it’s a lot less readable than Go. And the only thing more important than readability is whether or not the code does what it’s supposed to do. For that reason I doubt I’ll ever use Rust outside of specific circumstances.

*I’m using “a bad language” as shorthand for “a language you shouldn’t use”. Maybe they don’t think it’s bad but amounts to the same thing.

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.

so you have to catch all exceptions then do extra work to tell what the specific situation is

That’s horrifying. That’s a solid reason to avoid Python like the plague.

I think it’s a joke about the song being copyrighted

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.

The whole point is that random character sequences are often valid Perl

When I read the headline I also assumed “valid Perl program” meant it did something interesting. I was expecting to read an article about an interesting image to text conversion process that produced non-trivial Perl programs.

“Feeding garbage to OCR” is a really boring way of generating text. I was assuming it would be something more interesting, like creating a symbolic representation of the splatters and generating text from that. Using OCR is basically piping /dev/urandom to perl and seeing what happens. The fact that they’re valid perl programs is worth a laugh but the generation method is totally uninteresting.

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.

Agreed. Even self-reviewing a few days after I wrote the code helps me see mistakes.

Ah, yeah that makes a lot more sense

Better to not have version control!? Dear god I hope I never work on anything with you.

I used this tutorial for shaders: https://learnopengl.com/Lighting/Colors

This one also has useful stuff about how lighting works: http://www.opengl-tutorial.org/beginners-tutorials/tutorial-8-basic-shading/

These are both about OpenGL, but the theory is the same regardless of the environment.

“Flagged as spam”, “Publication Not Available”. I can’t see the article.

True, but if you read the article the point is clearly not about source code vs non-source configuration. There’s an implicit assumption that source code is something the developer will be modifying as time goes on, but the real point is, “Don’t make users merge changes.”