Why would one would like to truncate an existing file? To overwrite it. It's a very common use case.
What I have never found any use for personally is opening a file in read-write mode, while also truncating it, which is the full extent of w+ behaviour. I cannot think of many reasons to have an output stream to also function as an input.
> Why would one would like to truncate an existing file? To overwrite it. It's a very common use case.
Yeah, but we have plain "w" for that already.
> What I have never found any use for personally is opening a file in read-write mode, while also truncating it, which is the full extent of w+ behaviour. I cannot think of many reasons to have an output stream to also function as an input.
Exactly my point. If I am about to fully overwrite the file content, why would I want to re-read them without even an intermediate fclose()? I know that content already, I've just wrote it out! The only fringe use cases I can think of are really the edge cases of some general scenarios that would normally use "r+" (e.g. databases) but could occasionally go "okay, let's drop everything and start ab initio" — but those can just call ftrunc() in those circumstances. Or just open the file twice with different modes, the filesystem being what it is (global shared mutable state), you'll see your changes through.
Well, if the point is to have something that works well and follows the standard, he shouldn't have done anything at all and just use what was already made.
This could just be from a classic issue that comes up with organic intelligences. Where do people most commonly see ‘touch’ used, after all? It's very common to see it in build processes, used only on empty files, whereas using it to update the timestamp of a file with contents is more obscure (I don't know if I've ever seen it in the wild, personally). If you asked random developers “what does ‘touch’ do?”, and they weren't primed to think unusually carefully about it, you might well get something around creating empty files as the dominant answer, via extrapolating from a biased pile of examples rather than going to an authoritative source.
In natural language, this leads to semantic drift. In programming languages, semantic drift leads to bugs.
That's my personal suspicion, why there's no real coding tutorials like that on YouTube.
Having so many eyes to basically rip to shreds your output is probably the reason.
Except now that no one cares about handwritten code, maybe instead people will celebrate the diversity of ways one can write code to do things. Might see a resurgence in little artisanal videos like these
I really don't. I've realized I never liked coding. I liked designing and watching manual tasks become autonomous.
So AI software development is basically giving me everything I want: see a problem, iterate on the design I think will fix it, try it out. And then it works.
I have personal Android apps which "I developed" by having Claude update the react native hot reload view as I used them for the main application, and the biggest change in my home server infrastructure has been retooling it to support the fact that almost all the apps I use going forwards will be built and hosted locally.
I kind of expected this to happen: Coding will become an "artisanal craft" - much like woodworking for example. Sure for most of your furniture you can just go to ikea but every now and then you might get joy from making something with your own hands.
While I like the analogy, I'm not sure it holds how I think of AI. I'd do woodworking because I want better quality for less money, and that's why I use AI now. "Hand crafting" code might be fun but it doesn't get you it cheaper or better anymore IMHO
Better quality for less money? No. You do woodworking (if in fact you do) because you enjoy it. The time spent making a decent piece of furniture you could work at McDonald’s and buy a nicer piece in less time it takes to master woodworking.
So, don’t kid yourself! You enjoy it, and if you’ve mastered the skill then naturally you can save money over time. But I’d wager you spend more in hours mastering the skill than if you were to buy a couple pieces of furniture. ;)
It most certainly gets you better. Arguably not cheaper, though that depends on whether you're writing the code yourself (in which case it's cheaper) or hiring it out (in which case it's more expensive). But it's definitely better, because LLMs still are worse than humans at programming.
I'm not sure that societal trends can be extrapolated from YouTube videos, certainly not from one YouTube video, or channel. There's a lot of oddball stuff on YouTube that, if taken to be definitive would have you, for example, believing that the human race is becoming MMORPG players from New Zealand.
What it might illustrate is that "No AI" and long-format are currently seen as ways of attracting attention.
Having purchased furniture recently, it is not easy to get what you exactly have in mind or get matching things for a room. So there is value in building furniture by hand.
Not sure about coding though. There could be some thing which humans will do better. Maybe humans will always be better at understanding intent of other humans as they share same biology.
I'm kinda bored to read these pro AI arguments, which seem to come by waves. Suddenly everyone seems to say the same thing at the same time and it's been like this for months. Previously it was "it's there to stay", and then "you will be left behind if you don't use it", and this week its "coding yourself is for hobbies" or "is like artisanal work [which is cute but not really productive]".
Is it the $3B anthropic pretends to spend on marketing doing its job?
Yup. As a principle SWE with over 30 years writing code, I can say that the business case for hand-written code is now almost completely gone. If you are still writing code entirely by hand and expect to profit from that labor, you are doing yourself or your employer a gross disservice.
As an engineer with 20 years experience, I can say this is bogus. LLMs still - right now, today, with the latest model - make errors that humans would never make. They cannot be trusted. So you have to carefully review everything they produce, which negates the productivity gains. You may as well just write your own code, it will be similarly fast and better quality.
As a manager with 20 years experience, I can say this is bogus. Employees still - right now, today, even with the newer graduates - make errors that managers would never make. They cannot be trusted. So you have to carefully review everything they produce, which negates the productivity gains. You may as well just do their job, it will be similarly fast and better quality.
I tend to agree with the fact that there seem to be a lot of what are essentially talking points, that recur.
I think this comes from any widespread difference of opinion. The people generally do believe what they are saying, but when it gets to the point where arguments and counterarguments go back and forth unchanged it seems more like declaring their position than trying to convince others.
People can legitimately share a common belief and talk about it. So similar thinga can turn up in good faith. We just have to remember not to talk past each other.
Just like how IKEA furniture is plasterboard trash compared to the quality that we used to have with furniture (and can still get if we pay large sums), so has ai reduced code quality to this messy homogeneous pulp.
I am sorry, but this kind of comment has become too common on this site. It underestimates the kind of code a highly efficient human being code is capable of writing and managing over a long period of time ( which is what is required in a real job, btw ).
The only thing that I think coding agents are better than good human coders is the ability to generate a lot of usable code in a shorter period of time.
But can they maintain it over a long period of time? I highly doubt that, given the evidence that I have with me. Coding agents under-perform quite often in my line of work. They overproduce and yet are not able to cover the given requirements.
Sometimes they do 100% of the given task, but miss a slight detail ( given clearly in the prompt ), that renders their product unusable. This quite often results in a complete rewrite - consuming more, guess what, tokens!!!
So anyone who thinks that right now, coding agents can replace human coders completely, is really not working with these agents long enough or hard enough.
Once you start demanding from agents the same quality of code and the added responsibility/liability that you would associate with a human code, you will sure see the difference and I can tell you that its a lot.
I work with Opus 5.5 and Codex Astra 6 on a wide range of projects and they are found completely wanting in certain situations where a human would be more trustworthy and produce better results.
The difference is that Ikea is made out of cardboard, while that expensive woodworking table is still made out of solid wood, and the whole construction is quite different too. The manual process still has many benefits over the industrial one, even if its more expensive and labor intensive.
Code on the other side is just text files, if AI writes them or a human makes no difference. You still end up with the same old files. At least for me, AI has long crossed the point where I feel like I can contribute anything useful. The AI understands my own programs better then myself and is far faster and more flexible than I could ever hope to get anywhere near.
I can, but I can also find problems with all the analogies offered by AI apologists.
To me it's not the human in the loop that's weak, it's programming tools that fail to create and utilize bandwidth in the human/computer interaction cycle. Look at how much raw UX bandwidth people can show off when they're pushed to the limits! https://www.youtube.com/watch?v=Ki9EeaF4MLI
I just think the people selling the idea that AI will outstrip people's abilities to express themselves haven't actually considered what the practical constrictions on self-expression are and whether or not the limits we experience in practice are really the limits of human expressive capability.
Or things will settle down enough that people start looking at the numbers and doing the math. LLM tooling can generate code and often that code is correct. In my experience it takes about as long for the tooling to generate the code as it would for me to write the code myself and it also costs more money (my time plus the token cost). The more complicated the task the more likely I have to go back and get the model to re-work the majority of it as it made some assumptions that, after a little thought, turn out to be problematic.
IMHO, at the end of the day it's been about the same amount of time, the cost is a little higher and I don't feel as confident in the end product. I suspect that I am not the only one that feels this way!
We are not sure yet.
As every tech we show the benefits first then we see the cracks.
I think we might see more soon.
I think the fact the are hiding the harness and the "real" model is a signal they are not confident they will keep improving.
openai reported 95%+ on some benchmarks with an unpublished harness but when running with public harness and public model it is not a 30%+ improvement it is a 6% if that much...
maybe code will go the way of preciesely specified requirements. I guess that kind of exists already with formal proving, but maybe new languages will along that merge the two even closer. For example, instead of specifying a map data structure, you will specify a way two data elements associate, and AI will try various DS until it hones in on the "best" (highly dubious word there) one.
A lot of people have recently started smoking with the expectation that cancer will soon be a nonissue. He just promised not to use AI for the coding itself, but for fixing problems created along the way... ;)
We mostly saw the guy typing. The clicking sound is very distracting. Using vim didn't do him any favour. I would be much more impressed if we could get more insight into to the thinking and problem solving process. Also smoking is not commonly accepted productivity booster. He could have watched porn instead.
IYKYK. Zero rice. Zero rizz. Sort of person who does things like this would have at least a little rice. Look at Tsoding’s i3status to see what I’m talking about.
I'm not as certain as you seem to be, but I agree it's at least suspicious. The keypress sounds are admitted to be fake in the comments. The way the camera shakes (or doesn't) in response to keypresses seems odd and physically inconsistent over time; same goes for his apparent manual adjustments of its position/angle. Also the way his eyes track when he looks at his notes doesn't seem to be consistent with the screen layout as shown - he looks noticeably far downward when the notes pane on the screen is horizontally level with vim.
I only watched the first few minutes and thought no way touch is that simple! It isn’t. Because most of these utilities have a lot of scar tissue handling years of various edge cases and conditions. Something to be said for software engineering. If you try to build for all the edge conditions then getting a somewhat working example out would take too long
I did appreciate the ways he used the man pages to build out the tools.
if it only needs to work on his PC then its not tok bad. these utils are often full of crap because they need to work on everyones pc with wacky locales and filesystems and all sortsof crap this guy wont run into.
its always the case if ud implmenet everything just for your case you can skip most edge cases and software can be much more lean.
granted his claim is maybe a bit broadly worded regardin this point ofcourse.
70 comments
[ 3.7 ms ] story [ 30.5 ms ] threadWill this actually update the 'last modified' date for an already existing file?
Also, there's a standard way of processing command line arguments on Linux/Unix, which is not being followed here.
Major bug in the first command.
What I have never found any use for personally is opening a file in read-write mode, while also truncating it, which is the full extent of w+ behaviour. I cannot think of many reasons to have an output stream to also function as an input.
Yeah, but we have plain "w" for that already.
> What I have never found any use for personally is opening a file in read-write mode, while also truncating it, which is the full extent of w+ behaviour. I cannot think of many reasons to have an output stream to also function as an input.
Exactly my point. If I am about to fully overwrite the file content, why would I want to re-read them without even an intermediate fclose()? I know that content already, I've just wrote it out! The only fringe use cases I can think of are really the edge cases of some general scenarios that would normally use "r+" (e.g. databases) but could occasionally go "okay, let's drop everything and start ab initio" — but those can just call ftrunc() in those circumstances. Or just open the file twice with different modes, the filesystem being what it is (global shared mutable state), you'll see your changes through.
In natural language, this leads to semantic drift. In programming languages, semantic drift leads to bugs.
So AI software development is basically giving me everything I want: see a problem, iterate on the design I think will fix it, try it out. And then it works.
I have personal Android apps which "I developed" by having Claude update the react native hot reload view as I used them for the main application, and the biggest change in my home server infrastructure has been retooling it to support the fact that almost all the apps I use going forwards will be built and hosted locally.
So, don’t kid yourself! You enjoy it, and if you’ve mastered the skill then naturally you can save money over time. But I’d wager you spend more in hours mastering the skill than if you were to buy a couple pieces of furniture. ;)
What it might illustrate is that "No AI" and long-format are currently seen as ways of attracting attention.
To be fair this is just about everyone I meet these days. Nzgdc was just full of them.
Not sure about coding though. There could be some thing which humans will do better. Maybe humans will always be better at understanding intent of other humans as they share same biology.
Is it the $3B anthropic pretends to spend on marketing doing its job?
I think this comes from any widespread difference of opinion. The people generally do believe what they are saying, but when it gets to the point where arguments and counterarguments go back and forth unchanged it seems more like declaring their position than trying to convince others.
People can legitimately share a common belief and talk about it. So similar thinga can turn up in good faith. We just have to remember not to talk past each other.
Talk to other Devs face to face around you. "AI" is suddenly not that great, but a good tool nonetheless.
That's my experience anyway.
Maybe it’s also folks adapting to the new landscape ahead of them, not desperately holding on to the old norm.
You get what you pay for. With Ikea, it’s at least obvious up front what quality band it’s in.
The only thing that I think coding agents are better than good human coders is the ability to generate a lot of usable code in a shorter period of time.
But can they maintain it over a long period of time? I highly doubt that, given the evidence that I have with me. Coding agents under-perform quite often in my line of work. They overproduce and yet are not able to cover the given requirements.
Sometimes they do 100% of the given task, but miss a slight detail ( given clearly in the prompt ), that renders their product unusable. This quite often results in a complete rewrite - consuming more, guess what, tokens!!!
So anyone who thinks that right now, coding agents can replace human coders completely, is really not working with these agents long enough or hard enough.
Once you start demanding from agents the same quality of code and the added responsibility/liability that you would associate with a human code, you will sure see the difference and I can tell you that its a lot.
I work with Opus 5.5 and Codex Astra 6 on a wide range of projects and they are found completely wanting in certain situations where a human would be more trustworthy and produce better results.
Code on the other side is just text files, if AI writes them or a human makes no difference. You still end up with the same old files. At least for me, AI has long crossed the point where I feel like I can contribute anything useful. The AI understands my own programs better then myself and is far faster and more flexible than I could ever hope to get anywhere near.
Like writing! Everyone knows that after the printing press, nobody needed to know how to read or write anymore
To me it's not the human in the loop that's weak, it's programming tools that fail to create and utilize bandwidth in the human/computer interaction cycle. Look at how much raw UX bandwidth people can show off when they're pushed to the limits! https://www.youtube.com/watch?v=Ki9EeaF4MLI
I just think the people selling the idea that AI will outstrip people's abilities to express themselves haven't actually considered what the practical constrictions on self-expression are and whether or not the limits we experience in practice are really the limits of human expressive capability.
IMHO, at the end of the day it's been about the same amount of time, the cost is a little higher and I don't feel as confident in the end product. I suspect that I am not the only one that feels this way!
I think we might see more soon. I think the fact the are hiding the harness and the "real" model is a signal they are not confident they will keep improving. openai reported 95%+ on some benchmarks with an unpublished harness but when running with public harness and public model it is not a 30%+ improvement it is a 6% if that much...
I really wonder why they need to do that
Just this morning, I was wondering if it would make sense to share it on HN. And here it it on the front page. What a small world.
the Bob Ross of programming
https://news.ycombinator.com/item?id=50319510
I did appreciate the ways he used the man pages to build out the tools.
Actual touch.c source: https://github.com/coreutils/coreutils/blob/master/src/touch...
its always the case if ud implmenet everything just for your case you can skip most edge cases and software can be much more lean.
granted his claim is maybe a bit broadly worded regardin this point ofcourse.
Swapping to printf("Usage: %s ...\n",argv[0]); could easily save 60 key presses.
Let us know when somebody creates a No-ABE category.