Both you and the sibling common by buzzwords have the same contexte: You’re both using someone’s configuration framework, which goes bery much against the vanilla emacs’s way. Most package assumes something standard and you can expect something to break if your configuration isn’t.
I've used Doom Emacs for years and it rarely breaks. Sometimes things get out of sync, and I delete the git repo and clone it again. That happens once every few years.
People holding your attitude is one thing that keeps people away from Emacs. Very few people want to get into the weeds of customizing their editor. They want to do whatever it is they are interested in and the editor is tool to get it done. Doom Emacs, and other approachable "distributions" are the way to make the power of Emacs accessible.
> You’re both using someone’s configuration framework, which goes bery much against the vanilla emacs’s way
I heard a similar argument about vim's billion configuration options.
At some point I simply got tired of having to tweak it and switched to a better editor (not emacs though; both vim and emacs are losing in any debate, but it's a fun debate nonetheless since both camps think software can only be written with these two editors; everyone else must be clueless and skillless).
> People who do understand how software works should absolutely be having agents code it.
I don’t think there’s such people.
Either you’re writing a software for the first time and so the premise is not true. Or you’re writing it a second time and what would be the point? Just reuse the code you already have.
Maybe we need a definition of “understanding how software works”. There’s the technical aspect (computation theory, computer organization, compilation, executable format, …) and there’s the necessity aspect (the domain).
The technical aspect can be learned although you can stop at the top of the abstraction tower (the programming language and its ecosystem). The domain aspect encompasses the whole world pretty much. Contributing to Blender does not qualify you to review a Krita patch. You have to learn the latter’s code first.
Relevant to the problem you’re trying to solve. If it’s only relevant to what you’re using for solving it (i.e. choosing a different tool would have make those issues disappear), then that make them irrelevant.
Each tooling set will bring its own irrelevant details. But you can rank them according to the amount and complexity of the irrelevant of details you have to think about.
I was not hired to write code, but to solve problems (where often the end result is code, but it’s not the whole process). But the message from management is that our bottleneck was coding, and by using AI to code, we’ll be 10x faster and all the company problem will be solved. Essentially 1. Use AI everywhere 2. ??? 3. Profit.
Because it’s rarely so black and white. Knowing the inputs and outputs is merely the first steps, you need to think about the transitions too as they have their own costs.
Those costs don’t disappear and it’s truly naive to think they don’t matter. Take security issues, they may arise because what you thinks was the input is merely a subset of the true input range. And the extra possibilities lead to unforeseen behavior.
A lot of programming is about ensuring that the input and the output are the sets defined in the specs. And the rest is that the transition/relation is the right tradeoffs of performance, correctness, and costs.
> Can you type a hundred lines a second? If not, then it is.
No one has ever needed to do that for something that is new. And if it’s not new, you want to do it repeatedly with some guarantee of reliability. Not just in an uncontrolled manner.
That is why we have snippet systems, macros and code generators. And the best with code is to solve problem once and reuse the solution. Which we have done with libraries, frameworks and supporting software.
> And now that they have the tedium wrangled, they are freed from all of these arguments that start: we can't do that because it would take forever.
I'm strongly skeptical of this argument, as there's only a few things you can not build a rough version and get something to ideate upon. Even with 3d games you can do design with blocks and buy models to have something to pinpoint the design.
This is still an incomplete model, in my opinion. You're still holding up what is possible as a non ai assisted developer as equal to the assisted one in the abstract, before adding in real world things like tedium, boredom, distraction, the ephemeral nature of novelty, frustration, and everything else that has derailed human software development, but inference engines are perfectly impervious to.
I can give you a concrete example: this week at work, it occurred to me that the 16 channels of expected and measured binary on or off test data I need to collect could benefit from a visualization because matching expectations will have visual properties that failures will not. So I had my AI agent create a script that encodes 16 channels of expected and measured binary wave forms over time, as a 32 channel 1Hz sampling frequency wav file, which I can view with audacity, which also has the necessary controls to measure time between transitions in the waveformms.
From hindsight, one could argue that since all of that solution consisted of rudiments of perfectly normal software that didnt need AI to be written or integrated, it was equally possible to create without AI. But knowing that could do it with the greatest of ease, for the total price of naming it, converted this from a project that required the motivation to figure out all of the necessary steps to one that just needed a good description.
I do get your point about speeds and ease of producing working code. This kind of quick win can be a good example of AI assisted tooling. But I don't generate scripts that way as I prefer to have composable blocks that I can reuse later. AI is not great at reusable code.
Another things I noticed with AI assisted programming is the one track thinking. Someone has an idea, generate a working sample and then it becomes like a sunk-cost fallacy where they don't envision any other implementation choice or design. It's about adding more feature without taking a step back and assessing the overall goal of the project and if that feature is really needed.
Antoine de Saint-Exupéry has said it best:
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
This kind of cohesiveness is often missed in projects that are AI assisted because there's no refinement step. The product and the efforts are not tempered by real world usage.
But what about compositions of your reusable blocks an order of magnitude larger than you were ordinarily willing to manually compose? A lot of this misnaming Im circling around comes down to demanding that the ai user must be giving up their agency. Whatever you can name as a good practice you don't think an AI agent is a capable of employing on its own, I can retort that a human can demand the agent employ it, along with all of its other capabilities that outstrip the human typist.
Theoretically they can. There are people that use Paint to draw masterpieces. But your argument is only true if they’re willing to do so. AI is a slop enabler, having the discipline to funnel the slop into something concise and useful is not a given.
Sudoku’s constraints are knownn and easy to build an harness for. Software has a more malleable structure. An harness is hard to build and the tests cases for the constraints can be a lot.
As soon as you’re specifying instructions for the computer to do a task automatically, you’re programming it. It can be recording a macro, writing a script, describing it in something like Shortcuts,… The core thing is automation.
Copy-pasting is not programming, no more than clicking the save button is. But text expansion may be seen as such, especially when it involves dynamic elements (like current date and time). It may not be a clean delineation but, IMO, it's the difference between writing a recipe and doing the dish. Copy-pasting twice is making a dish. Creating a button that let the computer do it is writing a recipe.
Why are you looking to contribute to open source projects? If you have a fix or a new feature, you can share the diff in variety of ways. The maintainers are not obligated to review, discuss, and accept your changes.
I’m not entirely following you. I generally don’t contribute anymore, but in the past I’ve found a lot of maintainers are not actually looking for collaboration, rather free labor.
I certainly understand things are different nowadays, I’m talking pre-LLM proliferation.
> I’ve found a lot of maintainers are not actually looking for collaboration, rather free labor.
Do you think that maintainers lack domain expertise? A nice bug report is way more helpful than a random pull request. A patch, even when correct, can be counterproductive, if it conflicts with the roadmap and goal of the project.
The goal of open source is to give you freedom in maintaining your own version and extending it. Collaboration is not a requirement.
reply