Get rid of the 'file' concept for sourcecode!

After the recent sourcecode control debate I started thinking: why on earth are we still using the 'file' as the base unit to store sourcecode in? The whole 'file' concept is pretty bad and limiting when it comes to sourcecode control, code reuse and overall code management. Much better would it be if we could work with a code repository as the container for our sourcecode which would work with sourcecode elements like we know, e.g.: namespaces, classes, assemblies, resource objects etc. etc.

In your IDE, for example Visual Studio.NET, you then would work with solely a view on the sourcecode in the repository, thus a subset (or all) of the elements in that repository. The list of advantages of this approach is practically endless. First of all, because the repository contains elements, not files, you can include elements like classes or enums into your code without having to browse through files and wondering where a particular class is located. Second, you can enable sourcecode control on the element level rather than the file level. Also, sourcecode control can be build into the same medium you use to store the actual code in the first place: the repository itself. Of course you can think of many other advantages.

Why we're still using files for sourcecode, especially sourcecode written in OO languages, is beyond me: the concept of using an IDE for software development is very common, so offering a new way of looking at where sourcecode is stored should be considered in the IDE of at least tomorrow, but frankly, it should already be build into the IDE of today.

And the file focussed developer who's not using an IDE? He still can store his code in files, an IDE working with a repository can also use a file driver which reads all files in a project, and works with those files as one single repository. Let's hope at least in the Longhorn release of Visual Studio.NET, Microsoft considers this approach as an alternative to the 'file' concept. After all, the file system of longhorn is a database , so using that functionality for a repository would be the logical thing to do.

14 Comments

  • How would you script the builds on a machine without the IDE? Would the "elements" be pulled out of the repository to recreate the local "files"?

  • No, the tools are not working on the filesystem but with code elements retrieved from the repository, f.e. by calling the repository webservice. The concept of 'file' is not used when building the software.

  • Nice idea that would probably work well in some situations but I'm not sure how practical it would be for web applications.

  • I would have thought we'd have moved to the document repository scheme by now. I was hoping that was what's now SharePoint was going to give us.

  • When you change a function name in "refactor" mode, all uses of that function name should then change to the new function name. That is, when a function is called, it's automatically converted into a function# by the system, and just referred to by string name for the user.

  • A lot of Smalltalk implementations already work in this way - you save an image of the project, and work, class view like, with programming elements through the IDE. There is no notion of a file. I have not seen and source control systems for Smalltalk though that allow you to track back through changes to elements in the image.

  • There are IDEs that work this way. Check out the Smalltalk environments, e.g. IBM VisualAge for Smalltalk or even VisualAge for Java. Working in such an Environment indeed provides many benefits when searching or following references. It's nice. I worked several years with VisualAge for Java and found it very comfortable. Much better than what JBuilder or Netbeans had to offer 5 years ago. Very sad that VA couldn't keep up with the JDK updates ( it was a closed environment hardwired to a specific JDK version). Because of that we had to move on to inferior IDEs.

  • Very good feedback! I didn't know it was already common knowledge in the smalltalk world, I never used smalltalk myself...





    Knowing that smalltalk IDE's have had this feature for years already, makes it even more weird why current IDE's for other languages still use the file concept.

  • Eric: the current concept of a 'file' is already a view of sectors on a harddisk. With the plugin system of the filesystem stack you can create a FS driver for the repository if you truly want backwards compatibility.





    It's true that if it ain't broke, don't fix it is written all over it, but I also think that when a major IDE vendor (like MS) introduces it, plus with all the benefits that come with the concept, I think there will be a market for this. But it's a long road, admitted.





    I wonder though how MS will set up WinFS in longhorn: after all it's a database which provides views ('files') of the objects inside the database, which can (IMHO) be compatible with the concept of the code element of my blog.

  • I've used VisualAge for Java, got to say, it really sucks when you actually want to get at the files - web applications are the most obvious example. It becomes very tricky when you have to work with lots of files - like images, stylesheets etc...

  • When using Eclipse with Java, mostly you are dealing with projects, packages, classes, interfaces not folders and source files.

  • .NET gives everything we need for something better: System.CodeDom. We simply have to build an IDE that will handle the object graph directly instead of relying on those damn flat files.

  • Being a smalltalk developer, I found your comment amusing :)



    I've been developing with these new age features for more than 10 years. As far as I'm concerned, Visual Studio, Intellij, Eclipse, etc. They are all a major leap backwards for me.



    The ability to write code anywhere in the "IDE", select it, run it, test it, debug it, reload it, modify it, without having to stop/restart is incredibly productive.



    I can't understand why more people are ignorant to smalltalk.



    Take my advice. Take it for a test run. Get over the syntax hurdle and embrace the past.

  • As a former Smalltalk developer, I must say very much like it (used IBM's VisualAge for Smalltalk), but I think we must look forward. I reckon the way to go right now should be adapting our current IDEs (#develop?) to work with repositories instead of mere files....maybe by starting out a related sourceforge project?

Comments have been disabled for this content.