> only recently have agents started getting Rust code right on the first try
This is such a silly thing to say. Either you set the bar so low that "hello world" qualifies or you expect LLMs to be able to reason about lifetimes, which they clearly cannot. But LLMs were never very good at full-program reasoning in any language.
I don't see this language fixing this, but it's not trying to—it just seems to be removing cruft
Universal basic income by itself is just a stick propping up the consumer economy. We need a real welfare state, not the pathetic half-attempt we have today. We must take care of each other.
Such a model likely would not be referred to as "ownership". This is a relatively recent metaphor for memory management that came well after the concepts you mentioned. The fact that such a metaphor is core to rust's memory model is no coincidence.
Another Emacs user here. I would argue that even Emacs is a bit of a struggle sometimes. More modern editors like Sublime Text, Kate, or even Notepad have an advantage of being intuitive. Typing on a letter always outputs that exact letter. The shift key does one thing and one thing only. Mouse integration allows for rather precise cursor placement in a way that utilizes a human's natural hand-eye coordination. The shortcuts that they do use are common across the OS (no need to remember if the copy you need is Ctrl+A - W, Ctrl+W, Ctrl+Shift+C, or Ctrl+C).
Part of the issue is that operating systems have gotten more advanced and more standardized since Vi and Emacs were originally built. However, there is the case that UI designers have learned a lot over the decades. I like Emacs as well, especially when I am doing sysadmin work. However, I have to admit that it is not always intuitive. And even Emacs is more intuitive compared to the modal-nature of Vi.
Emacs is incredibly intuitive - with a caveat. Once you internalize the model, things become incredibly intuitive. I love that EVERY single keypress, mouse movement and button press is nothing but the association to a piece of Lisp - documented, always available, fully modifiable, debuggable, profilable source. The intuition required is for Lisp only; once you grok that part, Emacs becomes an irreplaceable ally - nothing even comes close to what you can do in it with text.
And btw, Emacs is inherently a modal editor - just like Vim. Only because you're not using modality for "text editing", it doesn't mean it is not.
What does it imply that the other term does not? Enshitification is the inevitable result of the tendency of profit to revert to zero. This is basic schumpeter (not to mention marx).
This is the problem. I'm skeptical of all our sides of government, they haven't done a lot for us to trust them, and keep chucking our trust into the bin.
But that doesn't mean we should resolve into skipping nuance, not understanding situations and critically evaluate what everyone is claiming. Mixing together two networks in order to score some cheap internet points, when the point doesn't even hold up to the most basic scrutiny, does the opposite of helping the case of proving how shit the government is.
You no longer have to be very specific about syntax. There's now an AI that can translate your idea into whatever language you want.
Previously, if you had an idea of what the program needed to do, you needed to learn a new language. This is so hard that we use language itself as a metaphor: It's hard to learn a new language, only a few people can translate from French to English, for example. Likewise, few people can translate English to Fortran.
Now, you can just think about your program in English, and so long as you actually know what you want, you can get a Fortran program.
The issue is now what it was originally for senior programmers: to decide what to make, not how to make it.
The hard part of software development is equivalent to the hard part of engineering:
Anyone can draw a sketch of what a house should look like. But designing a house that is safe, conforms to building regulations, and which wouldn't be uncomfortable to live in (for example, poor choice of heat insulation for the local climate) is the stuff people train on. Not the sketching part.
It's the same for software development. All we've done is replace FORTRAN / Javascript / whatever with a subset of a natural language. But we still need to thoroughly understand the problem and describe it to the LLM. Plus the way we format these markdown prompts, you're basically still programming. Albeit in a less strict syntax and the "compiler" is non-deterministic.
This is why I get so mythed by comments about AI replacing programmers. That's not what's happening. Programming is just shifting to a language that looks more like Jira tickets than source code. And the orgs that think they can replace developers with AI (and I don't for one second believe many of the technology leaders think this, but some smaller orgs likely do) are heading for a very unpleasant realisation soon.
I will caveat this by saying: there are far too many naff developers out there that genuinely aren't any better than an LLM. And maybe what we need is more regulation around software development, just like there is in proper engineering professions.
> Anyone can draw a sketch of what a house should look like. But designing a house that is safe, conforms to building regulations, and which wouldn't be uncomfortable to live in...
And now we have AIs that can take your sketch on paper and add all these complex and technical things by themselves. That's the point.
> Programming is just shifting to a language that looks more like Jira tickets than source code.
Sure, but now I need to be fluent in prompt-lang and the underlying programming language if you want me to be confident in the output (and you probably do, right?)
No, you have to be fluent in the domain. That is ultimately where the program is acting. You can be confident it works if it passes domain level tests.
You save all the time that was wasted forcing the language into the shape you intended. A lot of trivial little things ate up time, until AI came along. The big things, well, you still need to understand them.
> You can be confident it works if it passes domain level tests.
This is generally true for things you run locally on your machine IF your domain isn't super heavy on external dependencies or data dependencies that cause edge cases and cause explosions in test cases. But again, easier to inspect/be sure of those things locally for single-player utilities.
Generally much less true for anything that touches the internet and deals with money and/or long-term persistent storage of other people's data. If you aren't fluent in that world you'll run software built on old versions of third party code with iterations to make further changes that have to be increasingly broad in scope against a set of test cases that is almost certainly not as creative as a real attacker.
Personally I would love to see stuff move back to local user machines vs the Google-et-al-owned online world. But I don't think "cheap freeware" was the missing ingredient that prevented the corporate consolidation. And so people/companies who want to play in that massively-online world (where the money is) are still going to have to know the broader technical domain of operating online services safely and securely, which touches deep into the code.
So I, personally, don't have to be confident in one-off or utility scripts for manual tasks or ops that I write, because I can be confident in the domain of their behavior since I'm intimately familiar with the surrounding systems. Saves me a TON of time. Time I can devote to the important-to-get-correct code. But what about the next generation? Not familiar with the surrounding systems, so not even aware of what the domains they need to know (or not know) in depth are? (Maybe they'll pay us a bunch of money to help clean up a mess, which is a classic post-just-build-shit-fast successful startup story.)
You can get some of the way writing prompts with very little effort. But you almost always hit problems after a while. And once you do, it feels almost impossible to recover without restarting from a new context. And that can sometimes be a painful step.
But with learning to write effective prompts will get you a lot further, a lot quicker and with less friction.
So there’s definitely an element of learning a “prompt-lang” to effective use of LLMs.
> Sure, but now I need to be fluent in prompt-lang and the underlying programming language if you want me to be confident in the output (and you probably do, right?)
Using a formal language makes the problem space unambiguous. That is just as much a benefit as it is a barrier to entry. Once you learn this formal language, the ability to read code and see the surface area of the problem is absolutely empowering. Using english to express this is an exercise in frustration (or, occasionally, genius—but genius is not necessary with the formal language).
Again, I don't think most people are prepared to articulate what behavior they want. Fortran (and any other formal language) used to force this, but now you just kind of jerk off on the keyboard or into the microphone and expect mind-reading.
Reactionarily? Sure. Maybe AI has some role to play there. Maybe you can ask the chatbot to modify settings.
I am no fan of chatbots. But i do have empathy for the people responsible for them when their users start complaining that programs don't do what they want, despite the chatbots delivering precisely the code demanded.
This is such a silly thing to say. Either you set the bar so low that "hello world" qualifies or you expect LLMs to be able to reason about lifetimes, which they clearly cannot. But LLMs were never very good at full-program reasoning in any language.
I don't see this language fixing this, but it's not trying to—it just seems to be removing cruft
reply