Traditional program development is based on text files, except Smalltalk and some other alike environments. Computer user interface was textual in the past, text file is the first portable inter-computer format. For several decades of history general text editors and accompanied utilities grew up to powerful development tools what can outmatch the latest IDEs by productivity.

But time goes. All development platform has graphical interface. Text files became the only format that require decoding through the Net. And raw text never was a good medium for such highly structured data as program source. All that buzz about block representations (begin or not begin, what line place braces), various types of comments, delimiting semicolons, lost enclosing braces, strings with special symbols and without it, The One True Method of Indenting. So many noise in newsgroups and all that about how to code structure of language in raw text and not as how to code algorithm in particular language.

Another annoying thing is files itself. I think in terms of my projects, compilation units, it's sharing, dependency and versioning. A need to deals with unit's filenames and it's placement in directory tree brings up a whole new unnecessary affair, restrictions and maintenance difficults.

Now consider how we distribute software. We distributes sources (readme + H, C, CPP etc), object code (readme + H, LIB, OBJ etc), DLLs (readme + H, DLL, spare LIB etc), COM servers (some form of H and readme are bungled in as resource), EXEs (just EXE, user guide is never programmer's concern). Every way we exports parts of development environment that should be assimilated by similar user environment but we rarely has a tool to organize and automate this task in unified way. Well, Microsoft .NET provides several solutions by packaging various information in DLL files but for me it is not enough.

Dreaming from a blank list I has a following proposals (with Borland-like terminology).

Software packages
Software should be developed and distributed by package files which contains all necessary information together. All that is needed to include new package to development environment is to place it somethere nearby and then pick it by some name. A contained units then will be addressed by usual dot-name scheme.

A package itself is a general type container that supports tree-like hierarchy of units, with multiple versions of units and multiple record types for unit. So this features will be available irrespectively of underlying file system. Some patent-free compression may be optional. Any file or data can be added to package as resource -- graphics, HTML documentation etc.

When a newer version of package is available then update package with only newer components can be build automatically and then distributed to merge with older packages.

Compilation units
A unit is merely a smallest entity of project space and versioning system. It's up to developer how many classes, routines or other information will be included in one unit. Generally unit contain editable source record and may contain other derived and compiler-dependant information.

A source is stored as preparsed and always correct structure of nested blocks and statements. Any block or statement can be viewed by a number of ways: expanded, condensed, one-liner, closed etc. The block decoration (begin...end, identing) can be setted to various fashions (C-like, Ada-like, outline graphics etc). Statements formattes fluidly and are separated by pressing Enter key, exactly as typical text paragraphs.

A string/text constants has appropriate in-place editors (ASCII, Unicode, HTML etc) and doesn't have problems with special symbols. And so are comments what can be assigned to any structure element (whole interface, method or particular parameter), has a rich set of visibility rules and becomes a perfect self-documentation tool.

A source can contain parts what are purposefully excluded from compilation and uncompiled parts also. Compilation is doing on the fly when editing and wrong places are marked directly in source, exactly as typical text spellcheckers do.

A units can depend one on another in a number of ways. Typically a unit reference other unit so that presence of second is required when first is used. Or unit can be build upon another (alike Frankenstein) so that first once compiled can be used without second.

Loadable modules
A loadable module is important kind of unit what describes piece of code what can be loaded to memory, dynamically linked to other modules and executed. Again it can be anything from single method to full-functional application. A module interface describes what programming interfaces should be linked at run-time and what are provided by this module.

A module can be not intended for actual deploying. It can be formed so for unit test and better clarity of project. A module can be build upon set of other modules. Module compilator can use already compiled code, change statical links to direct calls or inlines, do global analysis and code optimization, remove any code and constant what falls out of usage graph, remove any code or constant duplicates.

Compiled module code consist of pseudo-code instructions what cover simple integer and logical arithmetic, data moving and control flow. Also it can contain various optimisation hints, for example, marks of loop body what can be executed in parallel. All the more complex instructions as floating point are coded as calls to external interfaces.

A module code can be interpreted but it isn't designed for this. For actual execution a module code should be compiled to native code of specific platform. On this stage any platform-specific optimization can be done, include using of parallel processing and complex instructions (floating, decimal, multimedia or 3D). This compilation can be done at load time or beforehand. A single module in package can contain several records of native code for various platforms.

So there exist an opportunity for alternative.