> Thinking in terms of generic computing concepts is equally as easy.
This is the trapdoor in this discussion. The degree to which a concept has been thought of in terms of generic computing (or just generically; modeled abstractly), before code is written, is different for every programmer. Not only is the degree different, but the deliberation and levels of awareness vary as well.
If your mental process explicitly models in the abstract, translating and typing out to code can absolutely feel like a bottleneck, and the specific language involved matters.
> If your mental process explicitly models in the abstract, translating and typing out to code can absolutely feel like a bottleneck, and the specific language involved matters.
Unless you're talking about raw typing speed or using an unfamiliar language, I don't think that it is. Most languages have few tokens and syntax rules. The next layer is the symbols from the standard library and the dependencies. After came the conceptual models, which is where the abstract thinking happens (like how does an hashmap works or what writing to a file entails).
Speed at the level of the first two layers can be greatly improved by very basic completion (syntax and symbols), or by just copy pasting. Integration like vim's quickfix or emacs' compilation mode helps because that's where compilation errors happens.
My opinion (anecdotally verified) is that people that feel like coding is a bottleneck have no editor fluency.
The degree to which my statement is true depends on the degree to which a programmer's abstract model incorporates _machine realities_. If your model takes into account the process model, and what is required for those process models to communicate, you are already modeling with mechanical sympathy. Programming languages (von nuemann languages) are all opinionated expositions of the same machinery, so the cost of translating the model to the language is a real cost.
My anecdata is the opposite of yours; the people that feel like the _actually coding_ is the bottleneck tend to be the people that have the _most_ editor fluency, as they are(were?) motivated to remove the bottleneck.
> Programming languages (von nuemann languages) are all opinionated expositions of the same machinery, so the cost of translating the model to the language is a real cost.
I don't think so unless you're talking about raw assembly. Even with C, you got structs (clump of data) and functions (which give us nice abstractions over pieces of logi) as well as syntactic sugar for branching and looping. OOP is a whole different model of design. And FP has a whole other basis of computation theory (evaluation and reduction from lambda calculus).
It's kinda like drawing in a sense. People think they know what something is and you ask them to draw a chair or a bike and they can't do it. So you ask someone to give you the specs of something like an attendance form, and they can't readily give it. Drafting the specs is the real cost, not implementing it.
> My anecdata is the opposite of yours; the people that feel like the _actually coding_ is the bottleneck tend to be the people that have the _most_ editor fluency, as they are(were?) motivated to remove the bottleneck.
If it were, we wouldn't have a drought of editor models. Vim and Emacs are decades old. Then VSCode is basically the same thing as sublime, kate, notepad++, and the various IDE out there. Coding isn't the bottleneck.
Who cares if it is a bottleneck or not? Can you type faster than an LLM? Send the code to the real bottleneck and spend your time taking a walk outside or something.
it's all software, not just sass. the "application harness" is emerging, which bundles up the application, the operations of the application, and the sdlc of the application all into one deployable thing. agents/people just plug into it, and it looks _mostly_ like an org chart / task board.
i think part of this is a shortcoming of our programming languages. generally, languages allow for the expression of partial graphs, which makes the verification problem technically challenging. my take is that a language that only exposes closed-graph semantics could help bridge the gap between the model and the implementation, even if not absolute.
What you say reminds me of the "Von Neumann Languages Lack Useful Mathematical Properties" section in John Backus's Turing award paper. One of his criticisms of what we would now call imperative languages is that they make it exceedingly difficult to formally prove facts about a program.
Personal responsibility will always exist at the touchpoints of software and human activity. Concentration and scope of responsibility may vary, and the degree to which that person needs to understand the code will vary as a result, but the need for a human to be able to read and understand code is going to be around for a very long while still.
People said the same thing about higher level interpreted languages. I wouldn't be surprised if we saw the same movement into a new abstraction like we did when people moved from assembly or C and into Python, Java and C#. This is probably also why LLM's are so good at low-abstraction, explicity, fail fast programming in something like Rust.
Considering how digitally inclined workers are already building various tools on their own. Even though these tools are completely vibe coded and the creator has absolutely no idea how to build things. I imagine we're going to look into a future where the LLM and the prompting becomes the "programming langauge".
I also think we'll see the personal responsibility shift because of this, and I think some traditional IT and software companies will struggle with this. We're an energy company, and where we would've bought a specialized piece of software and a team of consultants to implement it. We can now, not only build a better tool but also rewrite it enough to actually deploy it, all with a handful of people doing other tasks and 4000 Euro worth of credits. 6 months ago I would've laughed into your face if you told me this woud happen, but now, here we are.
I suspect that in a few years (if not sooner) you'll not need any form of software developer in the process for this. You need a buisness domain expert and you need it-architecture + cybersecurity, and most of the architecture + cybersecurity can be done through company wide AI skills. But the code itself never really has to be read for a really large part of software running in companies. You wouldn't do that for something critical, like the software running on your plants, but the web portal with a dashboard containing the status of your devices? Sure, especially because AI lets you do these things with 0 external dependencies.
I think that's just extra detail on the _degree_ of human responsibility depending on the environment. Even in what you suggest, if something goes wrong, who's responsible? AI are not persons in our society; the IT-architecture/cyber security expert is ultimately responsible for the code, regardless of how it's written.
> The tech industry has accidentally invented the initial stages a completely new kind of mind, based on completely unknown principles, using completely unknown processes that have no parallel in the biological world.
This is just false? Language emerged from biology, we've brute forced some version of that model. Knowing that this is a new kind of mind requires that we are able to differentiate these different kinds of minds in the first place.
Totally agree with the first part of that. The second less so. LLMs are able to maintain a cohesive idea across multiple metaphors, which is basically the same as walking abstractions.
Narrowly, I think you're spot on. The effort required to understand the machinery around formal verification is a function of the surface area of the thing being formally verified. Specifically, formally verifying the surface area of general purpose programming languages is difficult.
My approach with Hale (shameless self plug) is that the programming language itself first offers another strata of structure to program within, a type of graph. Once the structure of the program is expressed as a graph, understanding how formal verification works is a clean encapsulation of graph activities.
My bet is that we'll see a second layer of harness emerge, as self-driving codebases become the target. There will be an application facing harness, orthogonal to the agent facing harness. The app harness will represent the software factory that is emergent for the specific application being developed.
I suspect it won't be a harness, but just a more specific LLM trained in the universe of user-selected context of vetted resources.
Why? Because LLMs are always going to be dumb when they're trained at scale. Their ability to speak software diverges from their friendly user input layer. A harness won't overcome that, but an LLM saddle ontop of a larger model would provide the type of feedback loops you'd want to look into.
I don't think you'll find two deterministic systems will produce much.
I think that dissolves the "self driving" distinction, though? The mechanisms for driving the codebase must be present in the codebase itself. Otherwise its just a regular out-of-band development process.
I’ve definitely had a hunch about a software factory harness kind of thing.
Your thoughts on the matter seem clearer than mine.
I’m kind of relieved to see so many stages; that’s something I’ve grappled with conceptually. The volume of (sometimes optional) stages has made it hard to resist the temptation to hack something together with a GHA workflow.
I salute your choice to support distributed; that’s a requirement in my book.
This seems like way too caustic of a reaction, OP is correct.
If you actually know what you're doing in $language, and you know how $language wants to emit the assembly or whatever, there's no huge advantage to just programming directly in assembly.
This is the trapdoor in this discussion. The degree to which a concept has been thought of in terms of generic computing (or just generically; modeled abstractly), before code is written, is different for every programmer. Not only is the degree different, but the deliberation and levels of awareness vary as well.
If your mental process explicitly models in the abstract, translating and typing out to code can absolutely feel like a bottleneck, and the specific language involved matters.
reply