The whole notion of CSDs is a blueprint example of what happens when UI designers try to think things through too hard. They come up with grand solutions to trivial problems that are so poorly thought through that they create even bigger problems.

Realistically, nobody is going rewrite their entire application just because of what a tiny cabal of Gnome developers think. Just read this post that was linked elsewhere in this thread. At the end, Tobias is basically arguing that people should go out there and harass the developers of all Linux desktop applications (including the entire KDE project!) to follow through on this ridiculous idea:

Thus, our goal is for as many apps as possible to have the following properites [sic]

• No title bar
• Native-looking close/maximize/minimize icons
• Respects the setting for showing/hiding minimize and maximize
• Respects the setting for buttons to be on the left/right side of the window

Which apps are affected? Basically, all applications not using GTK3 (and a few that do use GTK3). That includes GTK2, Qt, and Electron apps.

If that alone doesn’t alert people of how out-of-touch the Gnome developers are, then I don’t know what would.

Your post is a succinct summary of the “study” of economics. It’s just supporting a conclusion in exchange for taking a bunch of bribes and cherry-picking data to support your argument.

I know what you mean, just beware: in lots of cases it’s not as universal (as in distro-independent) as some still think it is.

This is especially true when we start talking about BSDs and other non-GNU platforms.

Interesting. Were you using a Jenkinsfile? I’m not sure I completely understand your use case, but using a Jenkinsfile would mean that your entire pipeline would be defined in a file in source control, so you could roll it back if you made a change that didn’t work quite right. Seems to be what your looking for if I’m understanding what you’re looking for.

https://www.jenkins.io/doc/book/pipeline/jenkinsfile/

I looked at it for 5 seconds. The UI looked pretty hideous. Even new reddit looks better than it.

I’ve found the edit/test/debug loop in Jenkins to be much faster than Github Actions. It was quite a refreshing change when I made that transition.

The best way I found to do this is by commenting out the portions of the build that take the longest.

Which is stupid, but that’s what you get with Microsoft products.

(I get that there may be ways to test this locally, but I found this method to be the easiest.)

I thought they renamed their entire product line to “Copilot” by now, didn’t they?

Uninstalling it at this point would leave absolutely nothing left!

It’s called tivoization and started with a device called “Tivo” which was the first of its kind to attempt this procedure.

There are probably lots of hardware devices in your house that use GPL software but prevent you from actually modifying it because the hardware will refuse to run modified copies. If a piece of software is licensed GPLv3, it would violate the license terms to do something like this.

Yeah, I’ve seen a lot of those videos where they do things like {} + [], but why would anyone care what JS does in that case? Unless you’re a shit-ass programmer, you’re never going to be running code like that.

By this same logic, memory safety issues in C/C++ aren’t a problem either, right? Just don’t corrupt memory or dereference null pointers. Only “a shit-ass programmer” would write code that does something like that.

Real code has complexity. Variables are written to and read from all sorts of places and if you have to audit several functions deep to make sure that every variable won’t be set to some special value like that, then that’s a liability of the language that you will always have to work around carefully.

Another thing, he confirms something I was worried about, in his comments on parallelism / Python without the Global Interpreter Lock (aka GIL): Some developments in the language serve rather the big companies, than the community and open source projects. For example, lock-less multi-threading in Python serves mostly the largest companies, while having little value for small projects.

Absolutely agree. The significance of the GIL is heavily overstated in my opinion. There’s a narrow set of use-cases where it matters, ie. if you must use threads and something like multiprocessing or a message queue (ie. Celery) doesn’t do what you need. These are pretty rare circumstances, from my experience at least.

One principle I try to apply (when possible) comes from when I learned Haskell. Try to keep the low-level logical computations of your program pure, stateless functions. If their inputs are the same, they should always yield the same result. Then pass the results up to the higher level and perform your stateful transformations there.

An example would be: do I/O at the high level (file, network, database I/O), and only do very simple data transformations at these levels (avoid it altogether if possible). Then do the majority of the computational logic in lower level, modular components that have no external side effects. Also, pass all the data around using read-only records (example: Python dataclasses with frozen=True) so you know that nothing is being mutated between these modules.

This boundary generally makes it easier to test computational logic separately from stateful logic. It doesn’t work all the time, but it’s very helpful in making it easier to understand programs when you can structure programs this way.

Interesting, I had never heard of ccache before, though yes, all good build systems (CMake, Ninja, etc.) should cache intermediate object files.

But the projects I was working on were so large that even binary and unit test executables were so large that even they would take ~20 seconds to link. You can’t use caching to alleviate that buildtime cost unfortunately.

I think it’s just because it is always recommended as an “easy” language that’s good for beginners.

The only other thing it has going for it is that it has a REPL (and even that was shit until very recently), which I think is why it became popular for research.

If that’s the case, then why didn’t Javascript take its place instead? It’s arguably even better at Python in both of those areas…

Agreed. I have seen a lot of Python code that was really painful to massage back into a more structured object hierarchy. Java certainly does a bit better in that respect, and as a language, it does a much better job of encouraging better practices, but I think it’s also largely due to the kinds of people that use those languages as well.

Sure, but as with all things, it can depend on a lot of factors. All code needs some degree of testing, though one could certainly argue that Python needs more than Java and Java needs more than Rust/Haskell/etc. So you could argue that the productivity gain of using Python is offset by the productivity loss of extra testing. It’s still hard to say which one wins out in the end.

It can scale though. It parallelizes really well if you use queuing systems to distribute the load. You just have to make sure that the hot loops are in C/C++, and it is very easy to interface with compiled binaries via the C API.

Python’s type system is dramatically better than Javascript’s though. Try doing things like '' + True and Javascript will do incredibly stupid things. Python will just give you a type error. Also, look at things like == vs === in Javascript as well. That’s the biggest reason why Typescript replaced it overnight. Python has found a better balance between productivity and error safety.

In my opinion, the biggest shortcoming of Python’s dynamic typing system is that you need to have very thorough test coverage to be sure that your code doesn’t have semantic errors (a lot more than, say, Java). It has gotten better with the introduction of type hints, those I don’t have much experience with them, so I can’t say how much.

Having worked on large C++ projects, the solution to this issue is using a good IDE with an LSP. But it is quite a regrettable situation because setting up an LSP can be a difficult, and they also tend to break quite easily. Understanding how to make an LSP work is an important productivity skill in those kinds of positions.

Distribution usually isn’t considered a strong point for Python, though.

It depends. If it’s a simple script with no external dependencies, then it’s very easy to distribute. But if your application has external dependencies and you are trying to install it on your host (and you aren’t using docker or similar technologies), then yes, it’s harder than just shipping an executable or .jar file. The fact that Python’s standard library is so comprehensive helps a lot in this regard, but it only works up to a certain point.