I don’t think, it’s open-source…

This does not look to be open-source. The webpage lists open-source licenses for the libraries used by this app, but there’s no open-source license for the app itself.
And while there’s a GitHub repo, it’s empty. It seems to be used just for hosting the APK files.

An open-source app with decent editing capabilities is Fossify Gallery: https://f-droid.org/en/packages/org.fossify.gallery/

OpenOffice has seen essentially no development since 2011, when the trademark got transferred to Oracle after they bought Sun Microsystems.

The project got forked into LibreOffice to dodge the trademark issue, but it’s the same devs, practically the same project, but now under a non-profit organization. Well, and with 14 more years of development.

So, use LibreOffice instead of OpenOffice. It will most likely come pre-installed on whichever Linux distro you go with. But you can also try it out on Windows beforehand, if you have concerns.

On KDE, I’d recommend getting a KWin Script for tiling. Krohnkite is what people use currently.

It’s not as buttery smooth as dedicated tiling window managers and it can be a bit glitchy at times, but it is better than one might expect and significantly easier (and likely less glitchy) than trying to get bspwm to work in Plasma.

Yeah, after writing that comment, I was thinking, if I do promote it, that means there’s a certain expectation that I’ll integrate or implement functionality that others want. At that point, it becomes less of an egoistic thing. And I’ll be doing more communication and whatnot, therefore less programming.

Maybe that’s the puzzle piece that OP is missing? If you don’t promote it, you have practically no extra work compared to developing it under a proprietary license. In fact, it often reduces the workload, if you can just post it publicly without having to secure the repo.
And you don’t incur costs from giving it away either. So, if you make sure to only put in the work that you want to put in in the first place, you have no disadvantage from publishing it with an open-source license.

Incidentally, you can also play !dcss@lemmy.ml to train Vim navigation with HJKL keys.

I mean, DCSS does also have diagonal movement keys, which are most definitely not a thing in real Vim, but uh, you can probably just ignore those. So long as you’re not trying to win the game, anyways…

Many people enjoy programming, you know. I’ve got like ten reasonably-sized projects and I haven’t posted about them anywhere. Because I built them to scratch my own itch, both in terms of functionality I could use and the itch to build something, no matter what it is. I’m not wasting my time, because I’m doing something I enjoy.

Man pages are displayed in less (which acts as the so-called “pager” here), so you can search man pages interactively like you search in less. And you do that by pressing /, then typing your search term and pressing Enter. Then you can jump between results with n and Shift+n. This is also how search works in vim, by the way.

Perhaps another tip in this regard, to search in your command history with Bash (for re-running a command you’ve previously used), you can press Ctrl+R, then start typing your search term. Pressing Enter will run the displayed command. To skip to older search results, press Ctrl+R again. If you want to edit a command before running it, press → or Ctrl+F instead of Enter.
This UI is a bit fiddly in Bash, but worth figuring out.

As for Fish, it’s great for new users, because:

• it has a much more intuitive Ctrl+R UI, displaying all the search results interactively and not behaving weirdly in certain situations.
• it automatically sifts through your command history as you type and suggests the most recent command which starts with the prefix you typed. You can fill in its suggestion with → or Ctrl+F, or only use the next word from it via Alt+F. You can skip to older matches with ↑, which is then a proper search like Ctrl+R in Bash, so not just prefix-matching. And yeah, overall just really useful, because it’ll both make it quicker to run frequently-used commands, and sometimes suggest a complex command which I didn’t even remember that I once ran.
• its tab-completion shows short descriptions of what most (sub-)commands or arguments do.

But:

• don’t set it as your system-wide default shell or there’s some chance of shell scripts not executing correctly. What you should do instead, is to set it as the startup command to run in your terminal emulator.
• the syntax of Fish is somewhat different to that of Bash, which can be confusing when you’re still learning the Bash syntax. It’s not the worst thing in the world, as it basically only affects scripting and more complex command chains.
  Scripting is not a problem, because you can throw a shebang into the first line to use Bash syntax (#!/bin/sh or #!/bin/bash). You should add a shebang to your scripts anyways.
  And running more complex commands isn’t too big of a deal either, because you can run bash in your terminal to launch Bash, then paste the command into there to run it, and then quit back to Fish with exit or Ctrl+D. Typically you’ll know to run bash, because Fish’s syntax highlighting turns red after you’ve pasted a complex command.

It’s the same thing as ternary, just without the ? : syntax.

Oh yeah, I’m in favor of using type hints. People here are also saying that Pyright is more useful, which I haven’t used yet.

I was involved as the unlucky bastard supposed to sprinkle software engineering on top of a Python project 2+ years ago, and I just remember how much I understood right then and there why Python devs thought static typing was cumbersome. Felt like I had to write Java again, except it also didn’t work half the time.

Interesting. If it’s only in the type checker, can IDEs/editors correctly show the type information of inferred types then? Do they call the type checker themselves to retrieve that info?

Yeah, I only used Mypy so far. I thought it was inherent to the language spec, not the type checker.

I guess, some of your colleagues might have also just used Mypy so far, though…

In the case of Rust, you can also omit the type annotation in the vast majority of cases and the compiler will infer it.

It feels more solid to have a complex program covered by tests, yes, but how can this be confirmed in an objective way? And if it can, for which kind of software is this valid? Are the same methodologies adequate for web programming as for industrial embedded devices or a text editor?

Worth noting here that tests should primarily serve as a (self-checking) specification, i.e. documentation for what the code is supposed to do.
The more competent your type checking is and the better the abstractions are, the less you need to rely on tests to find bugs in the initial version of the code. You might be able to write code, fix the compiler errors and then just have working code (assuming your assumptions match reality). You don’t strictly need tests for that.

But you do need tests to document what the intended behaviour is and conversely which behaviours are merely accidental, so that you can still change the code after your initial working version.
In particular, tests also check the intended behaviour of all the code parts you might not have realized you’ve changed, so that you don’t need to understand the entire codebase every time you want to make a small change.

To be fair, Python doesn’t have type inference, so the type hints are quite obnoxious, and the type checkers for Python are also not as reliable as in languages with native static typing (even if that is often caused by libraries not providing type hints).

Interesting and valid point, but Kotlin’s when is not actually pattern-matching. It really is just syntactic sugar for if-else, like you’ve demonstrated.
Actual pattern-matching allows matching on the structure of a data type. So, you formulate a pattern to describe the structure and then you can choose different code paths based on whether the pattern matches or you can also access fields inside of this data type.

Rust allows pattern-matching even in variable assignments, which is going to look funky, but I think it shows quite well that pattern-matching isn’t just a fancy switch statement: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=3a8d126fa0cb9736597793915b00dd5d

So what happens is that:

• there’s a check whether the data type has the described structure, and
• where the pattern contains wildcards (like variable ‘slots’), the corresponding field values from the data type get put into those wildcards.

When someone writes this in Rust:

let x = 1;

It’s still pattern matching under the hood, but the pattern x is just a singular wildcard, so the right-hand side just gets ‘assigned’ to that variable name.

And with these simple examples, you might think that being able to access field values this way is silly, since you can also access them via my_data_type.foo, but it becomes more useful with deeply nested data types, and in particular in statically typed languages, it allows you to work with different data types without type casting. So, it would be more useful of a feature for TypeScript than it might be for JavaScript.

Those Spectacle changes look good. The old UI made some amount of sense, if the primary use-case was taking complete screenshots, but even for that, there’s probably a single shortcut to do that directly.
And I do find, I generally want a smaller cutout these days, because you can just fit more stuff onto modern displays, some of which is going to irrelevant.

Yeah, the wording is confusing. A long time ago, there was no paid software, there was only software where you got the source code and other software where e.g. it was pre-installed on some hardware and the manufacturer didn’t want to give the source code.

In that time, a whole movement started fighting for software freedom, so they called their software “free”.

Well, it didn’t feel like I’m tweaking to my needs (that came afterwards on top), it rather felt like I’m just undoing design decisions that someone made to cater to their specific needs.

And I named the time mainly to give an idea of how much there was to tweak. My main problems were:

• That I could not undo some of those unusual design decisions.
• That it doesn’t exactly make the system more robust when you need lots of non-default settings.

Well, that was just kind of one example to illustrate that it isn’t just a static screenshot, you actually see what’s going on in real-time. It’s also useful when you’re running a longer operation, like OS updates or encoding a video, and want to see when it’s done or that it hasn’t failed. You can just tell when the command output has stopped moving or a popup has appeared…

But thanks for the recommendation anyways!