Thanks, I’ll give that a shot.

Ah ok, thanks!

Thanks, it makes me feel relieved to hear I’m not the only one finding it a little overwhelming! Previously, I had been using chatgpt and the like where I would be hunting for the answer to a particularly esoteric programming question. I’ve had a fair amount of success with that, though occasionally I would catch it in the act of contradicting itself, so I’ve learned you have to follow up on it a bit.

I turned on copilot in VSCode for the first time this week. The results so far have been less than stellar. It’s batting about .100 in terms of completing code the way I intended. Now, people tell me it needs to learn your ways, so I’m going to give it a chance. But one thing it has done is replaced the normal auto-completion which showed you what sort of arguments a function takes with something that is sometimes dead wrong. Like the code will not even compile with the suggested args.

It also has a knack for making me forget what I was trying to do. It will show me something like the left side picture with a nice rail stretching off into the distance when I had intended it to turn, and then I can’t remember whether I wanted to go left or right? I guess it’s just something you need to adjust to. Like you need to have a thought fairly firmly in your mind before you begin typing so that you can react to the AI code in a reasonable way? It may occasionally be better than what you have it mind, but you need to keep the original idea in your head for comparison purposes. I’m not good at that yet.

What caused the jump in the first place? I only just opened an account myself because the folks who run my home instance lemmy.ca started up pixelfed.ca about a week ago and I decided to check it out.

Ouch. Well if you wanna take your chances in Canada, definitely advertise your senior COBOL dev skills! ;)

Lol yeah she’s in insurance! I bet you could probably also infer from the fortran that I work for a science-y outfit.

My wife was telling me at her work they’re desperate for cobol programmers, as they’re all retiring boomers leaving behind a giant code base. At my work, it’s legacy fortran that’s all over the place, but we’re a much smaller company.

I have no doubt that renewables are the lowest hanging fruit at the moment, and that we could get to net-zero mostly using them. But there is a big difference between mostly and entirely. As you approach the higher-hanging fruit, things get exponentially more expensive, and there may come a point at which some form of carbon capture is needed to cover that last segment of emissions? Also, I see no mention of nuclear here. I suspect it will need to play a role, though how large that would be remains uncertain. It should definitely be included in any cost analysis though.

That’s the point, when programming with immutable structures you always pass the mutability onto the enclosing structure.

I guess the point I was trying to make here was if the data type is already mutable, there is no point in sticking it in a list just so you can replace a reference with an identifier. You’re just adding an extra level of indirection. But sure yeah, if the type is inherently immutable, you have to do something.

A list is an antipattern here IMO. Just wrap it in some dedicated object (see e.g. Java’s StringBuilder).

Interesting. I’m not aware of anything like StringBuilder in the standard library for either Python or JavaScript. Looks like it wraps a list of characters and tries to behave as string-like as possible? You could presumably write your own class like that or download an implementation from someplace.

I guess in most cases in my own code, where I need a mutable string is usually as part of a larger data structure which is the thing that gets passed around by reference, so it’s easy enough to replace a field within that.

For building up a string, I would tend to use an io.StringIO in Python with file-writing calls, but those aren’t meant for sharing. What you don’t want to do is use the += operator a lot on strings. That gets expensive unless strings are mutable (like they are in say C++'s std::string).

Well, but then you’re basically just pushing the mutability onto the container, since you need to be able to replace elements within it.

It’s a good strategy at times though. Like say you’re working in a language where strings are immutable and you want a string you can change. You can wrap it in a list along the lines s=['foo'] and pass references to the list around instead. Then if you go s[0]='bar' at some point, all the references will now see ['bar'] instead.

As others have pointed out, there is the issue of breaking references to objects.

There can also be a lot of memory thrashing if you have to keep reallocating and copying objects all the time. To some extent, that may be mitigated using an internment scheme for common values. In Python, for example, integers are immutable but they intern something like the first 100 or so iirc? But that doesn’t work well for everything.

Any container you want to populate dynamically should probably be mutable to avoid O(N²) nastiness.