Editing Programming Language (section)

=Everything as an interface=
* For example, file access.
** No global fopen("filename");
** Instead open(os::filesystem, "filename"). Although a os.open wrapper could be used for the lazy, maybe it should be avoided since it's use should be discouraged, especially in libraries. You don't want to use a library that forces a config file to be stored in a specific location when you want to use a database as a backend store for configuration files.
** In many ways a file over a network connection is  the same as a file on a harddisk.
*** A hdd can die, become full or be removed. A network cable can be unplugged (plus the files on the other end are going to be stored on a harddrive anyway which have the same problem).
*** Differences?
**** Metadata stuff.
***** Rename files, can't normally rename HTTP. Renaming doesn't effect the actual file, it effects the filesystem's index.
***** Linking files. Can't link a HTTP file, locally (well not without the OS doing it, or a virtual filesystem library but that's out of the scope of a programming language). Once again not about files, but about the underlying filesystem.
***** Timestamps, ditto.
***** synchronisation and atomic operations. A file stored on a disk can be fsynced so you know it's stored. An atomic operation can allow a file to be replaced in place. A database on the otherhand might be holding the file in ram.
***** Files are lockable. Prevent multiple processes trying to write to the same file at the same time.
* println("This is bad as it's pain to override and isn't testable...");
** fprintln(stdout, "This is better but more typing");
** Monkey patching can work but deals with globals which adds threading issues...

==Stop allowing stuff in 'empty space'==
* Syntactically quarantine globals/singletons/statics (if they are allowed). A better idea might be to make them a 'context', but syntactically hide it (Same idea as main's environment context).
 globals {
    int hello = 0;
 }
* Do need things like function calls and so on.
* Don't syntactically need to specify the module namespace if it's determined by the filename/location.