The programming thread.

For me, self-hosted web-apps are a great solution, and then the server backs up everything fully-encrypted to the cloud. The various apps run as dockers on one main server, which really simplifies things. I like consolidating everything on my private server, and then when I want to do a fresh install on my PCs it's dead easy, because there's no data to worry about as it all lives on or is synced to the server, which rarely requires attention.

Top 10 highest paid programming languages in early 2022: https://www.devjobsscanner.com/blog/…in-early-2022/

Solidity, eh?

pibbur who ,since nobody pays him for working, will stay with C# (11) and C++ (17).

Solidity… never heard.

If they only base that on the jobs their scanner has found, I'd be very cautious with the relevance of the results. Besides, most of the interesting jobs are not advertised.

11&17 are closer to 1 and 2 at my company

For some reason I choose to post this xkcd in the programming thread in stead of the daily smile (to give watchers a pause from stupid jokes):



pibbuR who suggests using the SIMPLE programming language if you want to create error free code.

pibbuR whose long time favourite job has been to sit alone, with a PC for 15 years and then maybe come up with something useful. And who realizes that as a retiree he can now do excactly that. Only requirements is reaching level 82 (which should be possible), and getting acceptance from the wife (may be more difficult).

Originally Posted by pibbuR
getting acceptance from the wife (may be more difficult).

It's all a matter of perspective, and how you could potentially spend your time if you couldn't be in front of the PC. I remember my father buying a brushcutter (hope it translates well - image to illustrate the point) and using the same approach regarding flowers - he learned enough to break everything but not enough to mend it.

I really appreciate how Kotlin makes asynchronous programming "easier", or less difficult.

The code is clean and very easy to write, but sometimes it's still a bit crazy to get everything properly synchronized between the threads, coroutines, flows, observables, callbacks…

Not sure where to put this, or whether to post it at all.

I stumbled on a couple of cute discounted puzzle/programming games: Human Resource Machine and 7 Billion Humans, both from Tomorrow Corporation.

I finished the first one and only looked at the intro of the 2nd. They're very funny and well polished, though without much pretention.

EDIT: The 2nd is about parallel programming, and has an even darker humour than the first

HRM is really like a simplified assembly language that you use to program typical algorithms (division, filter, sort, …). A human executes the instructions in a setting of big corporation's inbox / outbox emails (just a simple input / output of numbers and/or letters). You can solve the problem, and if you want, try the two typical challenges to get under a limit of lines or cycles.

It reminded me of some long-forgotten assembly language optimizations with code and loops that end up in a real spaghetti code A lot of fun, and not too difficult.

Ran into an unexpected problem when in VSC 2022 prevew editing a small c++ program I'm creatig (for training). Suddenly the program wouldn't build. No compile error, just the linker reporting that it couldn't find the project assemby. Turns out that Bitdefender claimed the file was infected (Some Gen:Variant.Lazy thing) and quarantined it.

Other projects compile and link just fine, so I suppose it's a false positive in the assembly. Similar things have happened to others. But what to do about it???

piibbuR who scratches his head and vigorously searches the net.

EDIT: Found the solution, just added the rekevant paths to the list of exceptions in Bitdefender.

Originally Posted by pibbuR
Ran into an unexpected problem when in VSC 2022 prevew editing a small c++ program I'm creatig (for training). Suddenly the program wouldn't build. No compile error, just the linker reporting that it couldn't find the project assemby. Turns out that Bitdefender claimed the file was infected (Some Gen:Variant.Lazy thing) and quarantined it.

Other projects compile and link just fine, so I suppose it's a false positive in the assembly. Similar things have happened to others. But what to do about it???

piibbuR who scratches his head and vigorously searches the net.

EDIT: Found the solution, just added the rekevant paths to the list of exceptions in Bitdefender.

White-listing the project directories is always a good idea.

I had that a few times when compiling native code with gcc and McAfee. Thankfully it gave big alert pop-ups so it was hard to miss (first time I thought my compiler was infected).

When it was still possible, I disabled the heuristic detection, or whatever they called it, to avoid all those false positives and to unload the CPU. I noticed that the AV could make my scripts run for about one hour to do the job instead of a few minutes.

Paradox made an interesting dev diary #92 for Crusader Kings III .. for people interested in S/W development.

It's rather technical so I don't think it's interesting for the news but I'll post that here.

Don't be afraid, it's long but there are pictures and even a cartoon

CK3 Dev Diary #92: Anatomy of a Game: From Report to Resolution

[. . .]

Today we are here to tell you about the process a bug goes through from being reported to being resolved and put into an update. Grab yourself the beverage of your choice, and enjoy this little expose on how we go about resolving bugs on Crusader Kings 3!

[. . . skipping the technical and interesting bit . . .]

And now we know which language they use.

On a side note, I'm very tempted by this game.

I had that happen once, too, making a VB program. To fix it, I just changed the order of a bunch of functions/subroutines in the program. That was enough to change whatever byte string the heuristics were finding.

Fixing bugs is a daunting task. People often think that solving a bug is just rewriting a piece of code correctly, but it's all about finding it, or even being able to reproduce it in the first place.

I like the idea of merge requests, that's something I could never convince others to adopt at work (at several places).

At least I could convince them to do the automated build & tests, which I see they mention in this log. It must be harder to do for a game though, in particular for everything related to real-time controls. I never had to deal with that so I don't know exactly how they proceed. I never heard one talking about it, maybe they just test it visually.

Originally Posted by Redglyph
Fixing bugs is a daunting task. People often think that solving a bug is just rewriting a piece of code correctly, but it's all about finding it, or even being able to reproduce it in the first place.

And after all that, if the code is written in a spaghetti manner and there's no proper separation of concerns or not doing things at the proper abstraction level, then you get into the realm where fixing this over here, breaks that over there.

It becomes even more daunting when that fix you made is in a piece of code that is also used by another part of the program, which you were not aware of, but is now broken after your fix.
Having a CI pipeline is a good way to try and capture those things, but no CI pipeline has a 100% code coverage, as that would be too expensive and probably also impossible.

Designing and maintaining the list of tests is a delicate task indeed.

TDD methodology is a good tool to at least have an acceptable list and to avoid neglecting that part. Being old-school and taught to plan the whole architecture ahead, it felt counter-nature to design incrementally at first. But it showed enough merits to counter-balance the apparent lack of planning, so I've quickly adopted it. It is a more motivating flow, too.

Originally Posted by Myrthos
It becomes even more daunting when that fix you made is in a piece of code that is also used by another part of the program, which you were not aware of, but is now broken after your fix.
Having a CI pipeline is a good way to try and capture those things, but no CI pipeline has a 100% code coverage, as that would be too expensive and probably also impossible.

Yeah, usually out of a need to not have code repetition you couple things together, without considering if they should be. It's a very delicate act to balance the two.

Originally Posted by Redglyph
Designing and maintaining the list of tests is a delicate task indeed.

TDD methodology is a good tool to at least have an acceptable list and to avoid neglecting that part. Being old-school and taught to plan the whole architecture ahead, it felt counter-nature to design incrementally at first. But it showed enough merits to counter-balance the apparent lack of planning, so I've quickly adopted it. It is a more motivating flow, too.

Yeah, also with regards to tests it's really important what you test, and to make sure you, ideally only test the public surface of your apis. Otherwise you start coupling tests to internals, and when those change (and they will) then you're gonna be spending time fixing brittle tests, which is how you get the syndrome of spending an equal (or more) amount of time into just making the tests pass.

Of course, all of this sounds well and fine in theory. Then comes the real difficulty in knowing when to do what (and sometimes just making a decision without knowing everything). And after that, the other test is to be able to do all of this, while you're pressured by your superiors to ship, ship, ship. Nevermind the issues you're creating, ship it and fix it later. And later never comes.