Guys, can we add a rule that all posts that deal with using LLM bots to code must be marked? I am sick of this topic.

How would you like them to be marked? AFAIK Lemmy doesn't support post tags

1. Programming language invented: Everyone can code now! Programming is dead!
2. Cobol invented: Everyone can code now! Programming is dead!
3. BASIC invented: Everyone can code now! Programming is dead!
4. UML to Code/Executable UML: Everyone can code now! Programming is dead!
5. Low code: Everyone can code now! Programming is dead!
6. AI: Everyone can code now! Programming is dead!

Yep, any day now...

Aren't professional tools using node-based compositing, which ends up being just as complicated as code in big projects? They'll do anything to hide the code, because code is scary, even if it's the same.

Thing is, cleaning up slop, AI or otherwise, is miserable, slow, difficult work. It's why we get caught in rewrite traps.

I'm one of those the fits in both categories. I've been blown away by what these AI agents are capable of. I've "written" a bunch of scripts that involve parsing and generating code for another tool to consume and it's been able to take over the tedious parts, like writing a function to parse the parameters out of this code, then follow the code it goes into and extract the relationships between the parameters and recreate them another way. It's something I could write the code for, but that code will be mostly undocumented, will contain "quick version that I'll come back later and fix up (but I never get to it because if it works, there's other more productive things to do)", plus some debug code that I'm not sure if I'll need again so it's just there so I can uncomment it instead of writing it again. Not to mention all the typos and sloppy errors along the way that may or may not be easy to find later during compile and testing.

I consider myself a competent coder. AI makes me better, more focused and less sloppy. But that said, my prompts reflect that. I understand that these models aren't really programmers but just correlation engines that have been trained on a ton of programming material. It can tell you the traveling salesman problem is NP but won't necessarily realize that the problem you've asked it to solve is equivalent to the traveling salesman problem. It will happily spit out an identical function to one it did before, just with name differences that are specific to the current thing it is doing rather than just calling the same function. It will pick the least efficient way to do some things. It's not a problem solver, it's a solution predictor, which sounds better but isn't.

So I consider them more like force multipliers rather than adders. If you have the skills, I believe you could use an LLM to make anything (as a development cycle, not "spits out perfect implementation first try"), but if you don't have the skills, you'll struggle a lot even on fairly basic shit simply because you don't how to direct the LLM properly.

But I still watch it produce code with a mixture of awe and fear. I don't think the above will be true forever. Maybe not even for the rest of the 20s.

Probably two distinct circles that don't touch if I base it on people I know and myself.

LLMs don't add an abstraction layer. You can't competently produce software without understanding what they're outputting.

I've had this problem with abstractions for the longest time. Of course whenever I say anything negative about abstractions I just get dog piled so I don't usually like to discuss the topic.

I think abstractions as a tool is fine. My problem with abstractions is that most developers I meet seem to only talk about the upsides of abstractions and they never take into account the downsides seriously.

More often then not, I just think people treat abstractions as this magical tool you cant over use. In reality, over use of abstractions can increase complexity and reduce readability. They can greatly reduce the amount of assumptions you can make about code which has many many additional downsides.

Of course I'm not saying we shouldnt use abstractions. Not having any abstractions can be just as bad as having too many. You end up with similar issues such as increased complexity and reduced readability.

The hard part is finding the balance, the sweet spot where complexity is minimized and readability is maximized while using the fewest amount of abstractions possible.

I think too often, developers would err on the side of caution and add more abstractions then necessary and call it good enough. Developers really need to question if every abstraction is absolutely necessary. Is it really worth it to add an additional layer of abstraction just because a problem might arise in the future vs reducing the number of abstractions and waiting for it to become a problem before adding more abstractions. I don't think we do the latter enough. Often times you can get away with slightly less abstractions than you think you need because you will never touch the code again.

I feel like they kind of lost the thread here, even though I think I agree with the idea that vibe coding is a fundamentally different thing than another layer of abstraction. There's no need to punch on the web developers. We've all known, for the last several decades at least, that we don't have to understand the entire mechanism completely. No one is out there doping their own silicon and writing JS apps to run on it. The whole point of layered abstractions is that you can build on a set of assumptions without having to know all the implementation details of the layers below. When an abstraction leaks, then it can be useful to have some facility with the lower levels, but no person alive is a master of the full stack. The beautiful thing about abstractions is that you don't have to be. That's still true with vibe coding, just with the extra complexity of having a ticker tape spitting out semi-coherent code faster than any human could type it, which moves the dev from a creative role to more of an administrative one, as they mention earlier in the piece, which 1) is not nearly as fun, and crucially 2) doesn't help you build the muscles that make one good at code administration.

Of course there is, it is fun!

What else do you think the "point" of living is?

You could also try microcontroller programming. There you have control over everything and i guess it should be similiar to programming in early days. I started around ten years ago with Arduino and also directly programming them and it still interests me. And with a little hardware you could do some interesting projects. I would even say it could be relevant for career if you want that.

This guy disagrees: https://www.youtube.com/watch?v=Ws4twUyt-MY&pp=ygUNYzY0IDkgc3ByaXRlcw%3D%3D

There's a thriving C64 scene today. I'm more in the gameboy/DMG side of things but videos like that make me want to check it out further.

It's so much better! Tooling is many orders of magnitude better and so many libraries give you deep power from an easy API. What used to be a team and 18 months is a library install and a day so you're free to do much bigger things.

Christ even version control. The shit I put up with over the years.

You can still program in those platforms, if you want to.

That might explain why there’s so much crap coming out of the gaming industry.

not really, it's more of an economic situation instead of a tech one. Indie games are doing just fine, more or less (the choose 1 of 3 fad is a pain).

The modern game industry was being run by pedophile billionaires, two of the worst adjectives you can apply to a human being. I'd say that's more of a factor than not having enough "creative constraints"

high level code generating tools have come and mostly gone

he's talking about languages that don't touch bare metal, not WYSIWYG editors

EDIT: WYSIWYG stuff continues to live , fucking salesforce