vnorilo

I find it strange that the antidotes to a lot of the bad stuff going on today is basic enlightement stuff: cultivating a citizenry who value evidence-based worldview, education and rule of law. Yet it feels like that is increasingly slipping from our fingers.

I use LLMs at work without much thought by now. I'm also contributing a little bit to Sourcehut and keep my personal projects there.

While I'm not necessarily in the "LLMs are evil" camp, I find I respect this position a lot. I wish more people would do what they feel is right, even if that's going to result in a backlash from those who disagree.

When it comes to my personal projects, I realize I haven't really touched many of them in the LLM age. In a way, AI has made me uninterested in programming. This might actually be a nice demarcation line: keep my free range organic code on sourcehut and actively not use AI for my personal stuff. After all, LLMs (may) mostly help with speed (sometimes) - which was never the issue for the stuff I create "just because".

Totally agreed; I was talking from the POV of someone designing an iOS app. Apple could fix a lot of this jank with better design, individual apps less so.

Screenshot and share functionality get massively overloaded on iOS, but it's not because a product person / designer lacks the necessary taste, vision or "courage". It's because the OS is not capable of composing apps well: "I want to X, but with Y". As a result, functionality like screenshots, sharing, clipboard get overloaded with all kinds of adhoc half-baked workflows to work around the single app mindset.

If solutions come naturally to you in OOP, why not just roll with it?

Personally I find it easiest do design data flows: think about what we need in order to compute the result. The less I have to think about state the better. Functional patterns fall out and it feels simple and easy to me, so I do it. I'm way over the phase I thought that's somehow cooler than the OOP folks, however.

When you need a configuration step, cmake will actually save you a lot of time, especially if you work cross platform or even cross compile. I love to hate cmake as much as the next guy, and it would be hard to design a worse scripting language, but I'll take it any time over autoconf. Some of the newer tools may well be more convenient - I tried Bazel, and it sure wasn't (for me).

If you're happy to bake one config in a makefile, then cmake will do very little for you.

The wireless used for pro audio is never bluetooth, however.

Indeed, which is not all that different from LLM code generation, to be honest.

Yes. LLMs are search engines into the (latent) space or source code. Stuff you put into the context window is the "query". I've had some good results by minimizing the conversational aspect, and thinking in terms of shaping the context: asking the LLM to analyze relevant files, nor because I want the analysis, but because I want a good reading in the context. LLMs will work hard to stay in that "landscape", even with vague prompts. Often better than with weirdly specific or conflicting instructions.

When something is hundreds of megabytes, it is very unlikely to be mostly compiled code. A lot of that fits in each megabyte.

Probably true for many. When thinking about hard problems I'm usually not thinking in language, at least not the kind we speak between us humans, so it can be incredibly distracting if I have to "translate" back and forth while both thinking and communicating.

>I seriously doubt anyone who has written projects in assembly would make such comparisons...

With genuine respect, I believe this type of insinuation is rarely productive.

Someone might still have silly opinions, even if they have been paid to write assembly for 8-24-64 bit cisc, risc, ordered and out of order ISAs, and maybe compilers too. Peace :)

sure, I was thinking of large OO cores. "Correspondd to the instructions the cpu runs and their observable order" is how I'd characterize C as well, but to each their own.