“…third place.”

It’s a time-honored tradition among dictionary publishers.

Welcome to the Third Place (David Lynch)

Curious. When I last looked (quite a while ago) most of the tested pills were MDMA, with many containing caffeine as well. I guess it varies a lot over time.

https://dancesafe.org/

https://www.drugsdata.org/

It was basically too easy for people to post there just because, well, they could.

I expect the difference you’re describing was partly due to moderation (and lack thereof), but also partly due to the barrier to entry imposed by the forum signup process.

Unfortunately, the signup barrier cuts both ways: Despite loving high-quality discussion forums, I seldom bother participating in them these days, mainly because jumping through signup/captcha/email-validation hoops and then having to maintain yet another set of credentials for yet another site, forever, became too much hassle once I had more than a couple dozen. (I have hundreds, so I’m very reluctant to add to the pile.)

OpenID managed to solve a good deal of that hassle, but it’s mostly forgotten these days. I think well-moderated federated services have the potential to solve it completely, though. Here’s hoping.

I imagine the reasons include convenience (for the ISP) and the possibility of upselling.

There is at least one advantage to customers: address rotation makes it harder for third parties to track you.

Because it’s the foundation of a lot of cross-platform code, from the standard libraries in various programming languages to innumerable shell scripts.

Unless all the computing devices you use run Windows, you probably depend on POSIX, whether you have direct contact with it or not.

Yes.

desktop application for Windows, macOS, and Linux

Nothing does cross-platform desktop apps as well as Qt.

Definitely not Electron, which is very wasteful of system resources and has endless desktop integration bugs. Not Flutter. Not WxWidgets. Not Gtk. Not any of the various Java or Rust frameworks. Not Dear ImGui. Nothing. (Well, I haven’t tried Lazarus yet, but it requires a language that’s not on your list, so is probably not relevant here.)

Some of the newer frameworks might shape up eventually, but it would take years of focused effort. This is an area of computing that is difficult to do well.

I’ve been considering Ruby, Python, Golang and JavaScript

Of those languages, I would choose Python with either PySide or PyQt. If my interface needs were very simple, I might also consider Qt Quick, which lets you build GUIs with JavaScript and a declarative language called QML.

Not a bad shallow introduction to the package structure, but it leaves out more than a little, and doesn’t address compiled software at all.

Fortunately, Debian has extensive documentation. It’s worth a look for anyone wanting to build packages suitable for publishing.

https://www.debian.org/doc/devel-manuals

The New Maintainers’ Guide might be a good next step for understanding more use cases and available tools.

The full Guide for Debian Maintainers is more up to date, including relatively new tools like dh that considerably simplify packaging software that uses common build systems.

Most of what comes to mind has already been said by others, but I want to add one thing…

the overall code seems so convoluted to me that I don’t even know where to start to analyze a solution, even though if it’d probably take ten lines to implement.

One of the most important things to understand about software development is that (outside of small hobby projects) the vast majority of the work is not writing code. Most of the hours will be spent on a combination of other tasks, including:

• Understanding the desired behavior
• Understanding what has been tried before
• Understanding what has and hasn’t worked well in past attempts
• Considering unexpected ways in which the software might legitimately be used
• Imagining needs that might emerge in the future
• Imagining problems/circumstances that might emerge in the future
• Devising a solution that you think will work well
• Predicting limitations of your design
• Communicating the reasons and goals behind your design choices
• Listening to feedback from others, and understanding it
• Collaborating with others to find common ground
• Conducting research to prove your assumptions or answer open questions
• Learning the ins and outs of surrounding code that is only tangentially related to yours
• Learning unfamiliar tools
• Learning unfamiliar languages
• Learning unfamiliar algorithms and data structures
• Revising your design
• Coming up with succinct and clear names for things
• Testing your implementation (making sure it works now)
• Devising and writing automated tests for your implementation (making sure it will keep working when someone else changes something)
• Composing comments to explain why non-obvious things are done a certain way
• Reformatting your code to fit the style of the project
• Writing documentation, and rewriting it
• Answering questions
• Waiting for others to get back to you

The time and effort required for all of this multiplies when modifying an existing codebase, and multiplies again when most of that code was written by other people. Shepherding a contribution from idea to final merge often requires not only technical skill, but also study, diplomacy, empathy, and immense patience.

But I have no reference for how long a feature should take to implement in someone else’s code for the average Joe who does this for a living.

It varies quite a lot. I have had dozen-line changes take months, and thousand-line changes take a day or two. Just know that if it’s taking much longer than you expected, that is completely normal. :)

That’s overly complicated to my eyes, and not really relevant. The point I was trying to make is just that a join table is unnecessary in the situation you originally described.

Conceptually, the benefit of a join table is to allow many-to-many relations. That’s it.

If I understand you correctly, your relations are one-to-many, so a join table would just be needless complexity.

Not to be confused with Macrovision. :)

easily readable

Bash

This makes me wonder if you might benefit from exploring more programming languages.

I’ve never found shell scripts (beyond the most trivial tasks) to be especially readable. Bourne-style shells in particular (e.g. bash) have a lot of easy-to-miss nuances that will lead to bugs if not carefully managed.

Hats off to you if you can do a good job of it, but it sounds to me like a recipe for pain when it comes to long-term maintenance.

Whenever I find myself wishing for a tool to do (whatever), I habitually add its description and distinguishing features to a list that I keep for this purpose.

Then, when I want to try a new language, I already have a list of project ideas.

Not every new language is a keeper for me, so the project I choose doesn’t necessarily get finished in that language. That’s okay, because the process still gives me the real-world experience to find what I like and dislike about the language. It also leads to improved design and faster development when I pick that project up again in some other language, because I’ll have already explored the underlying issues.

I really like some things about Nim, but I think it’s held back by its BDFL, its documentation, and the complexity of using some of its advanced features. I wonder if the Nimskull project will eventually become a more popular choice.

Condemning apples for having seeds doesn’t make a reasonable case for choosing other fruit, which also have seeds.

One can’t rescue a design by just adding things to it (regardless of the kind of design), that’s just a simple truth.

This statement could also be applied to Perl, PHP, JavaScript, and most other languages that eventually add new ways of doing things, especially if they preserve backward compatibility. I’m not sure that this is a condemnation of C++ so much as an inevitable consequence of being successful for a long time.

To be clear, I’m not defending C++. Just pointing out that it’s not unusual in this regard. I have no doubt that Rust will also have vestigial warts in time, if it doesn’t already.

Upvoting because Foundry VTT was an excellent virtual tabletop when I used it for online D&D sessions a year or two ago. (Good features, great extensibility, both managed and self-hosting available, no client app required, no subscription fees.) If I were going to play The Witcher RPG, I would be happy to see it available for Foundry.