Comment by benwerd
13 years ago
I can't get my hands on this soon enough. It makes so much sense: we're moving away from the files and folders metaphor everywhere, so why not in the IDE too?
13 years ago
I can't get my hands on this soon enough. It makes so much sense: we're moving away from the files and folders metaphor everywhere, so why not in the IDE too?
We might not want the hassle of dealing with files and folders all the time, but I sometimes worry that a new generation of "programmers" will emerge who have no understanding of how the underlying filesystem works.
Why is that a bad thing (aside from the "I had to walk uphill both ways through the snow" aspect)?
A significant portion of this generation doesn't understand CPUs and buses. They wouldn't have been able to write anything remotely complex 20 years ago). That doesn't seem to be hindering things much, though. There are still system programmers out there who dive into it, but our abstractions have gotten good enough that all programmers don't need to understand the details to be successful.
(FWIW, I am conflicted on this topic. I wrote a little more here[1].)
1. http://news.ycombinator.com/item?id=3826551
CPUs and buses have been abstracted away pretty successfully by now, especially if you use a high-level language. But I can't imagine that the same will happen to file systems, at least not in the next 10 years. Too many of our critical tools, like all version control systems, depend on knowing where in the file system hierarchy your stuff is stored. Even if your IDE hides that from you, you'll need to know where to look as soon as something goes wrong. And things go wrong at the file system level a lot more often than they do at the CPU level.
4 replies →
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?
2 replies →
Your mention of .frx files just gave me a potent flashback, complete with psychosomatic hives.
3 replies →
Maybe that is a good thing? If programmers have no assumptions or presumptions about files and filesystems, then they are open for innovating new stuff without the burden of legacy.
I'm sad to see the current generation of programmers who don't understand that a hierarchical filesystem is one possible choice for organizing data on an underlying storage medium.
I think there are (at least) two different viewpoints of what is required for people to be able to program (and do it well).
First, an explosion in the power of the hardware being programmed on has made people think less of the efficiency that coding once required and more about getting something done. This feels sloppy, but can be a good starting point for iteration (+1 buzzword).
Similarly, the number of tools out there to get someone (like me) started on programming has EXPLODED in recent years. This results in a lot more people at least starting to code in whatever limited way.
I think it's naïve to think that people who start to code "the simple way" will always code that way. If they're actually pursuing as a career, they will always be digging more and trying to find out why something works a particular way.
Not seeing the filesystem/structure at first glance also isn't necessarily the same as NEVER looking at it or being interested in how the pieces all fit together. it simply means you don't have to worry about it RIGHT NOW.
How 'bout this: have a file system which can contain aggregating symbolic links, with configurable ordering schemes. We can edit functions in their own files and tell the compiler to compile the aggregation. This would be usable for C & C++ as well.
Less likely than our generation having no idea how CPU branching mechanisms work. Files are still how the vast majority of people, coders and non-coders, interact with their documents and data artifacts and organize backups. Anything deeper than that should be abstracted away, since it's subject to change.