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

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.

This is going to end well

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

What sells it for me is the mativation: end game you can use a calculoter to create the most efficient blueprint (or just watch nilaus). Hopefully this extends the time when you are designing a base rather than plopping prints

This new mechanic is going to add a ton of depth. I’m super excited.

Also, even without quality mechnics at all, recyclers will itroduce a nice qol bump.

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.

You can do typing through the compiler at build time, or you can do typing with guard statements at run time. You always end up doing typing tho

Programing is a lot less important than people and team dynamics

I don’t agree and I don’t disagree, but I thinkcontext matters a lot here. Some teams and codebases need deep knowledge, some don’t. Some nned sql performance, some don’t. Your conclusion is only true some of the time

We’v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams

I don’t really know the strong points of either, I’m not a cryptographer. Bcrypt gets recommended because its relatively fast, its decent, and most importantly its already in most environments

Yes its bad programing. These restrictions suggest that the company is either doing improper storage and processing, or does not understand how to deal with passwords.

The proper password storage is a hash. This is a cryptographic function that is easy to do and imbossible to undo. The hash function operates on the underlying binary representation of your password, and doesn’t card what letters or symbols are in it. A program should take your password, hash it, and compare the result to the hash they have in their detebase.

The current recomended hash algorythm is called ‘bcrypt’. Depending on the implementation, the input is between 50 and 70 bytes (the spec was a little unclear so people defined the inputs diferently, but the algorithe is the same). This means a password should be able to take at least 50 normal keyboard characters, including letters, symbols, and spaces. Anything less than that indicates a poor practice on behalf of the website.

(a lot of this is simplified. There is some variation and nuance that I don’t think affects the main idea)