Is porcelain inherently different from API?

Completely distinct, yes.

An API (Application Programming Interface) is specifically for application developers who are writing an application that interfaces with this system. By definition, this is not the action of an end user.

An end user, on the other hand, is someone who cannot be assumed to know anything about the internals (plumbing) and needs a user interface that, ideally, hides all the plumbing entirely and presents an abstracted interface (a porcelain) that makes sense for the task they want to perform, regardless of whether or not the concepts there actually represent what’s going on in the plumbing.

high assets and live off borrowed money

Right. Count assets as wealth and tax them as such.

Fortunately, government has an excellent method that it can use to take away unearned wealth from the wealthiest first: Progressive wealth taxation.

Now we need to demand our governments do that. I’m in favour of at least 90% rate wealth tax at the top, similar to what USA income taxes were.

It’s a long-established term in design of software that is intended for use without awkward interaction with the complex internals (the plumbing); we acknowledge that a decent user interface that presents strong, coherent abstractions designed for typical use (a porcelain) is needed.

The reason it gets so much discussion in the context of Git is because Git desperately needs a good porcelain, and its initial developers agreed one was needed but were profoundly uninterested in writing one; they said other people should do that. And then went on to heavily promote its use, before any decent porcelain existed, so that the plumbing de facto became what people had to use directly.

So, with Git particularly, no matter what porcelains get created, people are pretty much stuck with learning all the plumbing. It could have been better.

So this is an Emacs extension it seems.

That’s right. I have taught many people to use Magit, who have then loved it so much they go on to learn Emacs :-)

Are the Git commands it produces usable outside Emacs?

Yes, Magit is a porcelain to Git, meaning that Magit uses Git commands as its internal plumbing. Any option you select is shown (de-emphasised) as the corresponding Git command-line option; and any operation Magit does, you can optionally pull up the window where it’s running the Git commands.

This is a very good way to learn Git! The Magit interface is highly coherent and comprehensive, so it’s relatively easy to discover what you can do; and then you (optionally) look behind the scenes while it does it.

None of this saves you from the burden of learning the mental model of how a Git repository operates. But at least you can learn that after getting your work done, by asking “okay and how did happen?”.

Magit: press l in the Magit window.

The grain truck collision that is the Git command line is still visible in everything Magit does, and I can learn a lot by dipping into that. But I don’t need to look up the commands or combine weirdly disjoint options; Magit has a coherent, superior porcelain.

Make is fine unless you want to build on Windows. Then you kind of need something else.

I agree, you kind of need something else instead of Windows if you want to build software.

It is the very slow process creation infrastructure that kills Make as a tool on Windows.

s/Make as a tool on //

Give me a Make that

• properly handles filenames with arbitrary names (Make today breaks if filenames contain whitespace)
• uses space-based indentation level (Make today depends on the invisible difference between U+0008 TAB versus other whitespace, and refuses to process any other indentation)

Give me that, and… well, I’d probably still stick to current-day Make, because those improvements would cause my Makefiles to be backward incompatible. Make is just reliably available on pretty much any arbitrary system, unlike any candidate replacement.

Explaining every mild joke sure is a way to flesh out a garbage ad-target article

Now I definitely know you haven’t seen a real professional codebase.

Extremely wrong. So much for your assumptions.

Professional git repos are full of one sentence commit messages with little to no explanation of what’s in the change set.

Yes, humans can communicate poorly, of course. But people letting the LLMs do it do not understand what is in the change, and the LLM certainly doesn’t. There’s no one at all to ask because no one understands what was changed or why.

I’ll take “sometimes lazy but they wrote it and their understanding of it can be interrogated”, all week.

Yes. Except without attribution or record of provenance, and we get to charge you and everyone else arbitrarily for access! Are you excited now?

Working professionals are, if at all competent to be committing code to a professional code base, entirely capable of writing their own commit messages.

If they can’t write the commit message, they can’t sufficiently explain in writing the commit they just made to anyone. So, they should not be working professionally on a code base.

If they are capable of writing the commit message with their own understanding in their own words, but they choose not to communicate their understanding in the commit message? Also disqualifying, they should not be working professionally on a code base. Human communication is essential to this work.

That this is a controversial position, is a clear sign of the Slopocalypse.

Easier way to avoid waste of time: Stop wrestling with the unreliable word guessing plagiarism machine, and think for yourself.

Also, I’m hardly Mr Torvalds, I can barely get my machine to work properly.

Don’t be too hard on yourself. Now that Torvalds has opened the gate to AI slop in Linux, he doesn’t know how to get it working properly either.

This is the correct answer.

Anything a computer is doing, the software that does it is doing that because someone(s) programmed it.

You’re not looking for a programming language specific to a task; those exist, of course, but it’s better to know how systems are programmed, and what APIs are used to program the system you’re interested to control. Choosing which programming language to use should come after knowing what you want the computer system to do.

I’d like to have open forums for public discussion and feedback, but restrictive voting for board members. […] but I don’t want to worry about all the moderator tools and restrictions and BS either.

These are not compatible. If you’re providing a place for collaboration and for users to post their own expression, you are responsible for moderation of that expression, like it or not.

Any place where different people come together will be a site not only of on-topic genial collaboration; it will be also a site of content that is off-topic, or time-wasting, or community-harming, or ignorantly harmful to some members, or deliberately malicious, etc. And there will be disagreements about the definitions of all these, and you’ll need to come up with policy that resolves those.

You’ll either begin with tools (technical and policy decisions) to deal with this before opening the doors; or you will be obliged to deal with these issues with no tools to help, while the system is live and the disagreements are festering in real time. Hopefully you’ll prefer the former.

I seriously feel like I’m going crazy since it seems to me like I’m the only one who isn’t satisfied with the “capabilities” of LLMs.

This is an unsurprising impression to form. But it’s false.

You are seeing a lot of people boosting the LLM’s capabilities, for many reasons.

Some of them are sincere, to a degree: they feel like they are doing more, because they’re churning out code so much faster! But they’re discounting or ignoring the downsides: They have far less comprehension of that code, they can’t possibly review it effectively, they don’t perceive the lost time trying to work the extruded output into something they can use; etc.

Some of them are insincere, because they’re grifting: hoping to hype others into committing more to this technology and to their apparent experience, for clout or money. Those people can die in a hole.

A lot of them are insincere, because they perceive it will hurt their short-term career to not spout enthusiastically about using LLMs for coding. Their bosses demand it be used, measure its use and rank employees based on token burn, and job adverts overwhelmingly seem to require use of LLMs. People pretend to love this stuff just to stay employed.

Don’t believe it just because people say it. Believe your own experience: you have seen how godawful is the code extruded from these slop machines. You have seen how voluminous and ignorant of context it all is, making it worse than useless to try integrating into an existing project. You have seen how the LLM can’t effectively maintain its own code medium-, let along long-term. It’s all a colossal waste of effort and resources, a dead end.

Let people use the LLM for their own code if it makes them happy. But don’t accept it into your project if you don’t want it; and definitely don’t trust their self-reported productivity unless they bring the code, and you independently assess it. You’ll find very few claimed successes survive that simple scrutiny.

Thanks for coming back to report this. I’m sure others here were, like me, hoping we could reach you with positive messages and give you the confidence in yourself you deserve.

Stay strong and find your way. Write more articles here if you like. We’re wishing you well.

@super_user_do@fedd.it, don’t fall for the (insanely voluminous) hype around LLM capabilities.

LLMs aren’t better than you even today. They will extrude mediocre code, far too verbosely, and inevitably lose track of what they are supposed to be doing. When asked to make a change, they will frequently change far too much. They will make a mess that no one understands, least of all the LLM.

You can do better than them, today and in the future, by being curious, reading to understand, intending what you write, and improving from mistakes. LLMs can do none of this, their design does not allow them to.

deleted by creator