Windows does care about file extensions but is mildly embarrassed about it, hence the "show" default that has existed from Win 8 (?) onwards.
Linux and co generally work with magic bytes which is just another way of doing file formats. Is it better to signify your file format with a .ext or otherwise?
I find myself turning on file extensions if I have to use Windows and on Linux, I don't care and it just works.
I think the UIs for Linux are better. I think that MS are hung up on trying to suggest their stuff so it gets in the way a bit. On Linux, you just get the best option based on what is installed.
I have gone and ticked the “stop hiding file extensions” since they were introduced in ~98 (or was it Windows 95?)
When antivirus weren’t widespread, having a person click on a virus was just so easy: create a program with the icon of an image file. God forbid people learn that .exe means executable program. Learning new stuff is scary!
> I have gone and ticked the “stop hiding file extensions” since they were introduced in ~98 (or was it Windows 95?)
I think Windows 95, although even selecting that option still hides some file name extensions (such as ".lnk"). However, I have found that it is possible to use the registry editor to force all file name extensions to be displayed.
But even on system where they aren't needed they're useful IMO, for me as a user. Magic bytes mean you have to seek into each file, and if you care about file types, it means anything that lists files has to do that.
Personally, I'm not against file extensions, and I like to see and use them, however when something (i.e. magic bytes of a file) is used a lot system-wide, the underlying mechanisms optimize towards the use case as a natural tendency.
The interesting, or more accurately neat thing about EXT family of filesystems is, the file header is always one pointer away from your inode structure for that file.
With NVMe disks or SSDs in general, this is a very cheap operation, even when done en-masse. Even when we were using HDDs, anti-fragmentation features of EXT3/4 kept that one seek pretty cheap.
As a test, I fed my whole documents folder (~3500 files) into "file" tool to see what it does (via "file -f $filelist"). It finished in ~1,5 seconds. I redirected the output to /dev/null to eliminate the overhead incurred by printing things over SSH, though.
While everything is fast for small n, the consideration of small for this operation goes a long way, AFAICS.
A cheap operation is still infinitely more costly than no operation at all though. And not everything is on a local SSD, even just with a NAS, not to mention FTP, I really wouldn't want there to be no file extensions.
How would webdev look like? At first the HTML goes into "document", the style into "style", and before you know it, you're re-inventing extensions as prefixes or suffixes anyway, and I prefer users.sqlite to users_db. I honestly don't even see a problem to solve, so even the "cheapest" solution seems needlessly costly to me.
I don't see file extensions as a problem to be solved, either. My point is, it's nice that Linux (esp. Desktop Environment) ecosystem embraced magic byte parsing as a solution where having no extension creates problems.
I'm just happy to have the option around, I don't want to deprecate or against file extensions.
If you're interested, I can run some benchmarks on NFS and FTP as well, however.
I personally am of the opinion that both make sense and should exist. Extensions are for a first pass filtering/displaying, while magic bytes should be the source of truth, which is extra important when parsing a file anyway. Linux's binfmt_misc[0] even supports matching on either.
A lot of the time, what I want to build, doesn't have a succinct English sentence to describe it. If I describe the user requirement I just get a Fisher-Price toy thing that kind of ignores most of the adjectives and adverbs in my requirement. So I'd have to prompt with a big list of specs and algorithms for the specific thing I want. Then what's the point?
I've not had that problem, but I have 35 years of programming experience, so I can describe exactly what I want. Maybe that's the difference. It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to start writing and I'll give it feedback and keep it on track. If it tends to overthink a problem, I'll interrupt it and have it talk over the issue, until it gets a clear understanding of what I want. You have to treat it like a coworker more than just a code monkey.
> It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to start writing and I'll give it feedback and keep it on track. If it tends to overthink a problem, I'll interrupt it and have it talk over the issue, until it gets a clear understanding of what I want.
That sounds like programming with extra steps.
Here's my No-AI workflow: I read the requirements and devise pretty much instantly have a solution. I Check the web/manuals/docs/source code for missing information so I can refine the solution from a hunch to an implementation plan. This can be pretty fast or can be the slowest part. I start coding, building a small subset that work and iteratively adding on top, feeling the design as I go, refactoring if necessary. Then after testing, I send it to review.
The "finding information" part is the most important one as accuracy is paramount. And for most AI workflows, it seems that's very much an afterthought.
The "coding" part is the relaxing one, except for a few moments where some nuggets of information are lies or misleading. Again, there's no practice to catch those in AI workflows.
If you have a good testing methodology in place, the last part can be fast tracked, where you mostly scanning for bad practices and modifications to important areas. Again in AI workflows, you see that either they rely on preexisting test suites (the big rewrites), or mostly trust the generated suite with no evidence that it's actually suitable.
The questions I have are: How do you ensure the accuracy of the software's model of the domain? And What do you do to retain the knowledge of that model (as in you have a good intuition of the current behavior of the software or at least can easily locate the code responsible)?
The dream is "I have an idea for some awesome software, I will set an army of lemmings out to do all the tough work of figuring out how it actually works".
Well I do have an idea for some awesome software, I know exactly what the user experience should be, but the lemmings are producing useless software that resembles my idea in the way a Fisher-Price phone resembles a real phone. With frontier models, now far less buggy useless software following code conventions perfectly.
Even though the translation from English algorithm to code is the "boring" part that an LLM can do, the process of doing that works as a kind of REM sleep where I'm coming up with ways to make the program better
And for a lot of simple tasks, there's plenty of stuff where it's quicker to type a command than an English description of the same thing.
Maybe we could all pitch in on the most evil book ever, with instructions on how to do every possible horrible thing. Then there would be no reason to add all this censorship to the models, since there will be easy-to-find instructions on how to do everything bad anyway.
Lots of copies of the Windows source code still on GitHub, which is problematic if you're interested in NT and want to contribute to Wine or something...hard to avoid running into restricted code
