Comment by tbatterii
13 years ago
I sometimes worry that a new generation of "programmers" will emerge who have no understanding of how the underlying anything works.
For as useful as sites like stackoverflow are for sharing knowledge, it is potentially encouraging a generation of copy/paste coders who's job it is to find and glue snippets together until they get the desired outcome.
Maybe I'm getting old, but I'm starting think some knowledge needs to be earned. [get off my lawn].
If you aren't comfortable slinging files and directories around, you probably aren't a very productive software developer.
As far as ide's go, this concept is definitely intriguing. But I believe putting too much faith in abstractions like what is implied by being function focused(there is no "file") rather than file focused(these are your "files") has the potential of blowing up in your face. I think you need both.
Anyone who had to code on a team using VB6 remembers the pain of *.frx files and how they needed to be version controlled, but you didn't need to worry about them because it was an implementation detail required by the ide. UNTIL, 2 people made visual edits to the same screen and then the project wouldn't open. GOOD TIMES.
I think it would depend on the language to a certain extent. For example, good luck writing anything complicated in Python without touching files and directories, because every file is a module and every directory is a namespace.
A programmer obviously can't be expected to know how everything works, which is why we have abstractions. But I think abstractions need to be leak-proof to a certain extent before you can justify not knowing what lies below. The current state of file system abstractions is nowhere near that. They leak all over the place.
Speaking of file conflicts:
I'm picturing an alternate universe in which 'the database' stands in for 'the filesystem'. Data is laid out in a manner logical for its origins. Most programs use the library-provided implementation, of course, but there is a little more variability than in our world.
People have spent the past fifty odd years writing utility programs for manipulating databases instead of files, so concerns like 'moving' data between programs are still basically trivial.
In that universe functions really are the basic building block of code, and the database engine's consistency guarantees handle editing conflicts implicitly (with logging for version control, of course). Too bad, perhaps, that we're here rather than there.
Thoughts, criticisms, elaborations?
Reminded me of something Jaron Lanier wrote... found it:
"For instance, there is the idea of the computer file, which was debated up until the early 80s. There was an active contingent that thought that the idea of the file wasn't a good thing and we should instead have a massive distributed data base with a micro-structure of some sort. The first (unreleased) version of the Macintosh did not have files. But Unix jumped the fence from the academic to the business world and it had files, and Macintosh ultimately came out with files, and the Microsoft world had files, and basically everything has files. At this point, when we teach undergraduates computer science, we do not talk about the file as an invention, but speak of it as if it were a photon, because it in effect is more likely to still be around in 50 years than the photon."[1]
http://www.edge.org/documents/day/day_lanier.html
wasn't micorsoft supposed to roll something out with Vista that was sql server standing in for the filesystem?
http://en.wikipedia.org/wiki/WinFS#Development
I don't use windows anymore, but I hang with some .NET developers, and they aren't raving about WINFS, or Power Shell, or Sharepoint. Generally they seem pretty miserable.
Your mention of .frx files just gave me a potent flashback, complete with psychosomatic hives.
yeah sorry about that. I wish I could forget about *.frx and regsvr32 and VSS.
Registering versioned DLLs in Microsoft Transaction Server so that IIS could proxy requests from IE5.5's RDS ActiveX control to allow async callbacks on your 1999 intranet? Priceless.
Those DLLs calling functions in highly specific versions of the library that talks MS Exchange Server's data store protocol? Even more priceless.
Rebuilding an NT box from scratch because a junior developer accidentally installed a new version of Outlook Express which overwrote the working Exchange DLL with a slightly different version that exposes entirely different interfaces (but none that allow VB to access Exchange, curiously enough)? Priceless++
1 reply →