exactly this. If I need to do development, i’ll use a jetbrains product. If i’m in a pure text editing situation, I want the most powerful thing for manipulating text, and I want it to be available.

Vim can have some IDE-like qualities, if you bolt enough plugins in to it, but by default it affords buttinx text in a file and manipulating it.

I woudn’t classify it as an ide though.

Also, remember Human Resources Machine. Its a puzzle game thats actually a progamming language

A major aquisition is how apple launches a lot of stuff

Scare pieces like this are created by people who have no actual understanding of software.

Software is the automation of conceptual tasks. Some of these, like taxes or text editing, were fairly procedural and automated early. Others, like identifying birds or deepfaking celebreties, are dificult and were done later.

Creating software is another conceptual task, and it might be possiple to automate it. But once we have automated creating software, automating any other task becomes trivial as well.

If this ever comes to pass, there are no safe majors.

Oh, this is the popular conception of anarchy as a political project, but doesn’t really reflect anarchist thought much at all.

Anarchy is the project of volentary, participatory, and minimally coercive government. You can’t really have “no government” in any largish group of people. What you can do is structure that government to have the least amount of heirarchy and control with the greatest amount of participation.

Counter to popular conception, this actually means a lot of rules, just rules that everyone has a say in making. The goal will be that the rules serve to protect and promote wellbeing while having the minimum impact onthe choices people have available,

This statement confuses me

One of our right-wing parties has figured out that most people are not as right-wing as it is, but it can still win if only the most extreme people vote. So they try to make voting more difficult even. The opposite of compulsory

CBO projects that the majority of population growth overthe next two decades is from immigration. It seems our friend here is in favor of a shrinking population

https://www.cbo.gov/publication/58612

Both styles have advantages and disadvantages. Fully procedural code actually breaks down in readability after a certain length, some poeple suggest 100 or maybe 200 lines, depending on how much is going on in the function.

Blanket maxims tend to to have large spaces where they don’t apply.

Additionally, the place where the code on the right is more likely to cause bugs and maintainability issues is the mutation of the pizza argument in the functions. Argument mutation is important for execution time and memory performance, but is also a strong source of bugs, and should be considered carefully in each situation. We don’t know what the requirements for this code are, but in general we should recomend against universal use of argument mutation (and mutability in general).

The vast majority of wall time for most uses is io. You need someone on your team to care about big o, but for most teams, its not the problem

A wall of feathers and silk cloths hanging up

I feel like, with this reply, you are willfully glossing over my point. The issue at hand is that open source software is short on the ux design expertise. My claim is that by centering the programing expertise, and in fact by not going out of the way to be inviting to the non-programming expertise, open source projects are self-perpetuating these cycles.

We can find ways to invite good designers in, or we can continue with the “sufficient” design ost projects currently have.

I’m happy if people have ather strategies for overcoming the current problem, but the current aproach is not doing it

Design of UX is a separate craft from programing, to follow your own analogy, you don’t need to know electrical engineering to design an airplane control panel

Sure, you can pr the design files, but thats not how the messaging comes across. Even the “how to contribute” for most projects, if they have one, is usually entirely technical. The majority of designers (not all) I have worked with have been very shy about technical work, so having no clear “non-technical” contribution pathway is a deterent.

that second part is exactly why there is a lack of hci work in the linux space. Hci is a specialty, just like coding is. The standard ask of “create a pr with the code” is asking peopae who don’t typically code to do so, in addition to doing the work of researching the problm, designing a solution, and then testing that solution for suitability.

Since the only mechanism most open source projects have for accepting contribution is code, and the ask is usually for code, there is never even an opportunity to submit design work.

Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters.

Gitflow is has the same issues

Got asked about this twice so I’m cut/pasting my answer, but happy to discuss further

Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.

Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.