I’ve stumbled into this problem before while drafting a language I want to make*. A lot of the design philosophy is “symbols for language features” and as such import/export is handled by `<~`and `~>`. An example of an exported function:
```
<~ foo := (a: int) { a - 1 }
```
Then at the import site:
```
~> foo
```
* some day it’ll totally for real make it off the page and into an interpreter I’m sure :,)
I think the key to understanding why people want this is that those people care about results more than the act of coding. The easy example for this is a corporation. If the software does what was said on the product pitch, it doesn’t matter if the developer had fun writing it. All that matters is that it was done in an efficient enough (either by money or time) manner.
A slightly less bleak example is data analysis. When I am analyzing some dataset for work or home, being able to skip over the “rote” parts of the work is invaluable. Examples off the top of my head being: when the data isn’t in quite the right structure, or I want to add a new element to a plot that’s not trivial. It still has to be done with discipline and in a way that you can be confident in the results. I’ll generally lock down each code generation to only doing small subproblems with clearly defined boundaries. That generally helps reduce hallucinations, makes it easier to write tests if applicable and makes it easier to audit the code myself.
All of that said, I want to make clear that I agree that your vision of software engineering Becoming LLM code review hell sounds like… well, hell. I’m in no way advocating that the software engineering industry should become that. Just wanted to throw in my two cents
Probably the most unfortunate thing is that the whole AI garbage trend exposes how little people care about the craft leading to garbage results.
As a comparison point I've gone through over 12,000 games on Steam. I've seen endless games where large portions of it are LLM generated. Images, code, models, banner artwork, writing. None of it is worth engaging with because every single one has a bunch of disjointed pieces shoved together combined.
Codebases are going to be exactly the same. A bunch of different components and services put together with zero design principal or cohesion in mind.
It really feels the same as weed/nicotine/alcohol/sex/other vices. If history has taught us anything, outright banning them only makes them into forbidden fruit. We need to explain (and frequently reinforce) these negative effects of modern phone use so kids can grow up understanding them. Right now, it seems like a lot of people really only start to understand the impacts of this kind of phone use long after they're addicted. Hopefully informing them before that happens would help.
Of course, this kind of thing is easy to do wrong. Programs like D.A.R.E. and THRIVE tried going the way of fear tactics which seems to really not work well. We need to have an open and honest discussion about "yes, this is fun. But it DOES have a bad side" instead.
The last sticking point there is that it assumes people will be rational and come to the conclusion of using with moderation. Hopefully people can be rational... Otherwise I think there's no hope for us in solving the brainrot epidemic.
From my own experience and that of fellow parents that I talked to, explanations will be dismissed outright by the all-knowing teenagers, and any attempt to have a rational conversation on the topic will fail. Just like any addict, kids will deny that they are addicted. I had to act once the smartphone addiction reached a disaster level. What worked the best for me was "no you cannot bring your phone to school or use it before the homework is done, that's my decision and I don't have to provide you with any explanation." Did this generate some resentment and a few tantrums? You bet, but I got the result I wanted, peace of mind and homework done on time.
I disagree with you.
> outright banning them only makes them into forbidden fruit
I think it should be fine to outright ban them in certain contexts, like classroom learning; just as they are outright banned (usually) in theaters or playhouses or places of worship.
And to cite your example, even in the most liberal jurisdictions I think it's not acceptable for students to take drugs in the classroom. Phones are basically the same thing.
Oop, I totally missed the "during the school day" part of the grandparent comment. I totally agree with banning them during the school day. My argument was against the point that the grandparent wasn't making which was banning phones from K-12 students both during and after the school day
Oh I just realized I missed the "during the school day" part of the comment I cited. That's totally my mistake. For what it's worth, I agree with banning during the school day but (although no one is making the point here) I would disagree with banning them from children everywhere always.
What is really needed is parents that teach their kids impulse control and how to prioritize, to know what is extracurricular and what is not. You can play video games, smoke weed, do whatever on your phone once your work is done, not before or during.
There was no mention of an outright ban, merely restrictions on use. Much as we have restrictions on where and when one can indulge in weed, nicotine, alcohol, and so forth.
The core idea of what I am working on is to build a solution that can generate programs capable of converting arbitrary input to arbitrary output (bytes to bytes) based on a reasonable quantity of training data.
I'm trying to determine if a more symbolic approach may lend itself to broader generalization capabilities in lieu of massive amounts of training data. I am also trying to determine if dramatically simplified, CPU-only architectures could be feasible. I.e., ~8 interpreted instructions combined with clever search techniques (tournament selection & friends).
I don't have anything public yet. I am debating going wide open for better collaboration with others.
> I figure evolution-designed languages might come up with things that are hard to pattern match for more complex operations.
I think I agree with this - once you hit a certain level of complexity things would get really hard to anticipate. The chances you would hit good patterns would probably drop over time as the model improves.
I've been looking at an adjacent idea wherein a meta program is responsible for authoring the actual task program each time, but I haven't found traction here yet. Adding a 2nd layer really slows down the search. And, the fitness function for the meta program is a proxy at best unless you have a LOT of free time to critique random program sources.
I feel like a lot of people are forgetting how good llms are at small isolated tasks because of how much better they've gotten at larger tasks. The best experiences I've had with llms all involve sketching out the interfaces for components I need and letting it fill in the implementation. That mentality also rewards choices that lead to good/maintainable code. you give functions good names so the AI knows what to implement. You make the code you ask it to generate as small as possible to minimize the chance of it hallucinating/going off the rails. You stub simple apis for the same reason. And (unsurprisingly) small, well defined functions are extremely testable! Which is a great trait to have for code that you know can very well be wrong.
In time the AI will be good enough design whole applications in this vibe-code-y way... But all of the examples I've seen so far indicate that even the best publicly available models aren't there. It seems like every example I've seen has the developer bickering with the ai about something it just won't get right - often wasting more time than they were slightly more hands on. Until the tech gets over that I'll stick to it being the "junior developer I give a uml diagram to so they can figure out the messy parts".
``` <~ foo := (a: int) { a - 1 } ```
Then at the import site:
``` ~> foo ```
* some day it’ll totally for real make it off the page and into an interpreter I’m sure :,)