I have to admit that I never understood the need for bashrc and bash_profile. I hated that with a passion when I started to set up my bash configuration. I never saw the need to have so many files and so much complication to have a consistent shell whenever I logged in the console or spawned a konsole in KDE.

The paths shown on that diagram are 7 for bash, and 4 for zsh, so it’s surely an improvement. However, now that I have set it all on a git repository, I don’t see it as a big deal. I have a profile that sources bashrc, and then I do it all in bashrc. I’ve checked /etc/skel and it seems the distro does roughly the same (and I’ve never switched away from Debian or Debian-based in 20 years). I’m not sure if it’s such a big deal. But I’m still curious about trying zsh some day. :)

Thanks for the blog post. I’ll check it out.

Yes. There is already an answer with many votes saying so, but I’ll add myself to the list.

I don’t have to like all the language, and not even all of the standard library. I learnt C++ with the Qt library, and I still do 99% of my development using Qt because it’s the kind of software that I like to write the most. I can choose the parts that I like the most about the full C++ ecosystem, like most people do (you would have to see how different game development is, for example).

I’m also learning Rust, and I see nothing wrong with it. It’s just that I see C++ better for the kind of stuff that I need to write (at this time at least).

Correct. Backwards compatibility is both its biggest asset and its bigger problem.

In syntax alone, you can check what Herb Sutter is doing with cppfront. Specifically, the wiki page on the postfix operators is quite enlightening. It shows some interesting examples of how by making everything a postfix operator you drop the need of -> and the duality of pre/post increment and decrement operators.

Excuse me, what?

Klipper was entirely a different program, process, etc. that was using the system tray. Nowadays it seems to be a plasmoid in the system tray. How can that be less of a UNIX philosophy than the Windows alternative? Because it’s developed by the same community that makes the shell? That doesn’t make sense to me.

They are. Registers are just “named boxes” where you can store some text and/or keystrokes. When yanking and pasting, the unnamed register is used if you don’t specify a name (you can still see or edit it explicitly). For recording a macro there is no default register, though. You need to give it a name.

Meanwhile, this was a feature on KDE-land since Klipper, which goes back (as far as I know and if I remember well) to KDE 3 or sooner.

I’ve been compiling apps depending on newer Qt and/or kdelibs versions for ages (back when the repository was literally called “kdelibs”, about 20 years ago).

This has never been an issue for me. Even with autoconf/automake, I just compiled everything to its own prefix, so it doesn’t interfere with the system at all. You don’t even need to fix the build system in the cases where it’s broken/lacks features, if you leverage all the “path” variables (CPATH, LIBRARY_PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH, etc.). But autotools, cmake, qmake, and every build system I’ve used so far supports this out of the box.

Not claiming it’s a skill issue, but I have to say I’m very surprised by reading any of this.

Specifically, for Debian, I was told 20 years ago by a very wise person “you never do make install on Debian, specially not for the kernel”, and taught me how to use make-kpkg (or something like that, I don’t remember the name of the tool), which was a way to make a debian package of a self built kernel, which is obviously something that can’t be installed to its own prefix.

https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/

Related: There is an article on LWN called Lua and Python, which is mostly about the approach of the two languages WRT being “batteries included” or not.

I think Lua being a bit barebones is 100% fine… if you just pair it with a good helper library, or set of libraries with a coherent API, that allows it to thrive. Then you can either use the framework library or not, depending on whether your project requires the extras, or can do without.

As a parallel, I’ve been doing C++ development for almost two decades, and I cannot imagine doing anything non-trivial without Qt. For example, Qt has a debug framework that pretty prints automatically most containers, and adds the newline also automatically. Also, QString is an actual string type, whereas std::string is more like QByteArray. It’s functionality that it’s essential for me (and it’s just the minimal examples… then Qt has all the GUI functionality, of course, but I use Qt even in console-only programs!).

This is surely opinionated on my side, and most C++ devs don’t see it this way, but my point is that a language with a “core experience” that it’s lackluster to you should not be a bad thing if the language is capable enough to provide an ecosystem with a good 3rd party library that adds exactly what you want. In the Lua ecosystem that maybe it’s Penlight.

But I totally get your point. Penlight doesn’t even seem to have a math library, so I found no round implementation there. This can be not a problem for some, but deal breaking for others.

I’m not fully sure what the intent of the joke is, but note that yes, it’s true that a header typically just has the prototype. However, tons of more advanced libraries are “header-only”. Everything is in a single header originally, in development, or it’s a collection of headers (that optionally gets “amalgamated” as a single header). This is sometimes done intentionally to simplify integration of the library (“just copy this files to your repo, or add it as a submodule”), but sometimes it’s entirely necessary because the code is just template code that needs to be in a header.

C++ 20 adds modules, and the situation is a bit more involved, but I’m not confident enough of elaborating on this. :) Compile times are much better, but it’s something that the build system and the compilers needs to support.

Precisely, Gary Bernhardt has given a talk on ideology. I don’t think he’s precisely someone who thinks in absolutes. It’s just preaching that some stuff is (probably) used more than it should. I’ve seen way, way, way worse projects that over engineered things and made things slow and unmanageable, than the opposite. Of course, everyone has seen different things, and our perceptions are amplified and biased by that.

I’ve wanted to start a project in Rust, but for the ideas that I have (and the time that I have for a hobby project, as for work it’s rarely starting a new one, but continuing and existing one), Rust seemed a viable, but not ideal alternative to just doing it all in C++, for which I already have enough knowledge and very well proven libraries. I will look again soon, and I will keep looking because eventually something will surely click, it’s just that so far, the time has not been right.

Note that my point is not that it’s unusable for everyone. Just that it’s false that “some people just can’t seem to let [C or C++] go”, as the previous comment said. I can’t let go something that works well for something that doesn’t, given the projects that I have to work on.

It’s just time to move on from C/C++, but some people just can’t seem to let go.

The Rust community has 2 websites that I keep periodically checking: Are we game yet? and Are we GUI yet?. The answers on those sites are respectively (as of February 2024, when this comment is written) “Almost. We have the blocks, bring your own glue” and “The roots aren’t deep but the seeds are planted”. I’ve seen the progress in Bevy and Slint, but it’s still the same, those websites don’t change, and my situation WRT to making a Rust project for fun or work it’s the same.

I’ll be happy to start doing Rust projects whenever I get the chance (which will be when it’s a sufficient tool for my use cases). But I’m tired of smoke sellers.

The github project page is for developers, and Github already gives you tons of ways to make a user website. Don’t ask your users to visit github.com/group/project, make them visit group.github.io/project, like any sane person.

Same with Gitlab, BTW.

And if you don’t like the full static site, use the wiki, or guide your users in the first paragraphs of the README so they find the user information if they must.

The very first moment that I had to use JSON as a configuration format, and I was desperate to find a way to make a long string into a JSON field. JSON is great for many things, but it’s not good at all for a configuration format where you need users to make it pretty, and need features like comments or multi-line strings (because you don’t want to fix a merge conflict in a 400 character-wide line).

Doesn’t YAML have a (seldom used) feature of a start and end of document marker? The “YAML frontmatter” that a few markdown documents have, uses this.

Thanks. I should have linked to that myself, perhaps.

Norway.

Ups. Sorry, I meant “NO”.

Radon, the “handwriting” one, seems like if someone wanted to have Comic Sans but for code.