I regularly get codex to do multi hour tasks with a single prompts I don't think thats a big deal anymore. But you don't want a single agent doing all the work. The root agent needs to delegate the work to sub agents. For example, a sub agent for context gathering, then one for planning, then one (or more) for implementation, then another for review. This way the root agent doesn't use up its context window and it just manages from a bird's eye view. I do have the $200 plan though.
Kick a ball, throw a ball, hit a ball, jump over the ball, stick a ball somewhere. A ball, a stick, a ring, a board. I hate that football is the default sport and was forced myself to play it in my childhood.
It is the default sport because the barrier to entry is basically having a ball. Random rocks, backpacks, whatever you have can serve as the goalposts.
Most other sports require other equipment too (volleyball needs the net, basketball the hoop, etc. etc.).
It's also easy to understand, and being the most popular sport by far in most countries, allows for an easy appropriation to a community and sense of belonging.
> was forced myself to play it in my childhood
So you're just trauma dumping your childhood issues?
also football can be played in basically any number, from 1:1 to 11:11, which means you can go out with a ball, meet one other kid and play, and random other kids can just join in.
I've literally seen kids unable to speak with each other because of different languages able to join a match :)
I was terrible at football as a kid so it's not like it did much for me, but one cannot deny how universal the game is.
Look, I disliked football for the reason that it made me an outcast. All males in my class in elementary school played football on a regular basis. I did not. It made me associate more with another guy (only 1, yeah) and girls. It made me just pick up a book and read while others were playing sports (happened to be football).
... but I did make myself an outcast as I was growing up as I would rather use my PC (for programming) than go outside.
I loved OS/2 but I also remember the dreaded single input queue... but it didn't stop me using it until about 2000 when I realised it was time to move on.
You actually mis-remember. One of the things that was a perpetual telephone-game distortion during the Operating System Wars was people talking about a single input queue.
Presentation Manager did not have a single input queue. Every PM application had its own input queue, right from when PM began in OS/2 1.1, created by a function named WinCreateMsgQueue() no less. There were very clearly more than 1 queue. What PM had was synchronous input, as opposed to asynchronous in Win32 on Windows NT.
Interestingly, in later 32-bit OS/2 IBM added some desynchronization where input would be continued asynchronously if an application stalled.
Here's Daniel McNulty explaining the difference in 1996:
Because of that, I got good at creating multi-threaded GUI apps. Stardock were champs at this - they had a newsgroup reader/downloader named PMINews that took full advantage of multithreading.
The rule of thumb I had heard and followed was that if something could take longer than 500ms you should get off the UI thread and do it in a separate thread. You'd disable any UI controls until it was done.
You're probably right. It was long long ago... I keep meaning to look at ArcaOS but I never seem to have the hardware to dedicate to it at the same time my interest returns.
> devs had hardly any experience with using AI tools.
I love it, here come the "you are using it wrong" arguments!
I thought these tools are so great, so awesome, that even without much experience they will help you? Or are they not so great and you actually gotta spend a considerable amount of time of learning them to see some return? Which one is it:
- are LLMs groundbreaking and democratizing development making it so much easier (which doesn't correspond to the results of the study)
- or do they need months of practice to give a modest return (or loss) of productivity back?
"You are using it wrong" is the cheapest cop-out when somebody questions the productivity benefits of LLMs. I'd like the LLM fanbase community to come up with better arguments (or ask their little assistant for assistance).
>I thought these tools are so great, so awesome, that even without much experience they will help you?
I never made that claim, I don't think it's generally true, but I do think it can be true for some people.
Regarding the study, I pointed out why I thought it was limited in its scope. If someone did a study on the potential productivity gains of using emacs and they based the study on people who had only used it for a week it wouldn't be a particularly useful study. A Piano is not a useful tool for making music for someone who has only used it for a week either.
I do have a customer with no prior programming experience that has created custom software for his own small manufacturing business automating tedious tasks. I think that's pretty amazing and so does he.
One side effect of writing most of my code with an llm for the past six months is that I'm so much better at reading code I didn't write. It's also forced me to split my code up in smaller more modular files to make it easier for me to understand, which has the happy side effect of having a better designed system. It's counter intuitive but I think I've become a better programmer for it because it's forced me to level up my weaknesses.
I'm of the same opinion as the op and I'm programming in Rust(api) and Swift(client) right now.
I entered a vibe coded game hackathon a few months back and in a little over a week I was at 25k lines of code across both the client and server. It all worked (multiplayer) even though the game sucked.
