201–210 of 220 posts
Are there examples of how this would work when you need the pseudocode to reference abstract application concepts? I'm not totally convinced this is a useful way to express something like "Change the data flow so that we bulk query from the DB upfront and pass it down to all callsites"
None of the existing ones (that I've used at least) are good editors designed to work with agents.
I do dearly miss the days of only having access to copilot and the acceleration being available, but the intention that was still necessary.
I think "the pseudocode is persisted alongside the generated code" just reinvented jira/linear tickets and PR descriptions. We have ways of using git and tracing the code write to the thought process behind it.
This is a step in an interesting direction for many reasons. First of all it reduces the "conversation in english" aspect and goes back to kinda "writing code" which I think would reduce a lot of fatigue and bring back some joy in making software. But then it also gives more control over the output in a way that makes sense: I know how i want to code this, but I can save time not having to deal with the syntax/boiler…
> an advantage of agents in huge codebases is that they can find where to make the change and draft it, which wouldn't work with this system. I think you could go meta here and ask the agent in English to modify your pseudocode for larger changes.
There are good reasons for doing this: I might want to write something in Ruby (the way I think about problems might fit that language best), but might want the artefact I check in to be Python (my colleagues might prefer it), and my build pipeline might want to transpile it into C, and then throw it through a compiler with a pile of optimisations to make it all scream at 100x the performance my original code could run in, in Ruby.
Hell, why not make the Ruby interpreter just a call out to an LLM to get it turned into byte code?
Of course this is all starting to sound a little absurd because it is. We're reinventing a domain that has had decades of research into it using an expensive, slow, stochastic black box.
Where there's some utility is in a language where I can be a little vague, but that doesn't have all the semantic confusion of natural language. But without defining that as a formal grammar (and therefore implementable in LLVM, JVM, whatever), you may end up with the worst of both Worlds.
the hardest part of programming is the logic errors, as a result i tried a few times to use a formal verifier to write the pseudo code and have the llm translate it into the language i wanted. the problem with this however is that llms do not necessarily know the best techniques for speed and like to overcomplicate the problem/solution.
how does this language help with prevention of overcomplication?
I had this idea 25 years ago, except that I wanted to use the AI available at the time, which would have probably been genetic algorithms. The idea was to write the expected outputs for some input examples and have a Lisp-like language use evolution/mutation to generate a paragraph or so of code that meets the spec. Then probably do some fuzzing or SAT solving to formally enumerate the known-good cases and possible e…
For a while people were talking about the necessity of UBI in response to the potential elimination of jobs. I tend to take your view (I think it's your view) that it's more worthwhile to automate our basic necessities. Food, water, shelter - use technology to drive those costs down to zero or near zero so that an economically risky solution like UBI doesn't even need to be proposed.
Earlier quoted context omitted.
I don’t mean to imply that making things with these tools is lesser, or that it doesn’t require some skill, but it is fundamentally different to programming. I’m glad you’re able to bring new things to life with these tools, that’s a great thing :) My broader philosophical take is that we, programmers, lived through a golden age where our skills used on our terms were some of the most valuable skills. The golden age…
The age of "programmer tyranny", as you call it, was over long ago. Product manager tyranny has been the de facto regime in Big Tech for years. That's how we ended up with subscription models everywhere, enshittification, and infinite data tracking. Imagine that x1000. That's where we're heading, IMO.
The current biggest problem is reputation and QA. Ie I see hundreds of same kind of apps when I search for open source stuff on F-Droid, but I can't really say whether it was properly audited with current influx of vibe-coded stuff, whether it contains malware, is it fully vibe-coded or human evaluated the result, etc. which one of those hundreds is actually good?
When we solve the slop recognition problem, we can actually see a positive turn from enshittification, because copying products overnight without spyware became almost trivial.
Interesting idea! I wonder if, after some iteration, a variation on this could help curb some of the LLM spaghetti mess