5 ms·

That may have been the case in 1979, but in 1980, we got Smalltalk. This environment was (almost) completely without the concept of a file. Code was stored in

by t1m 13y ago

That may have been the case in 1979, but in 1980, we got Smalltalk. This environment was (almost) completely without the concept of a file. Code was stored in a persistent 'image', like everything else, and was accessible through normal object based data structures. This, and the fact that all of the source code for the system was immediately available, made it extremely easy to build and extend language level tools like browsers and debuggers. I would say the downside of this 'rich' environment is that your tools tend to become language dependent. Early Smalltalk code versioning tools were fairly easy to build (I'm guessing), but would definitely be Smalltalk centred. The unfortunate advantage of an ASCII text file is that it very difficult to have more than one interpretation of it's non-existent meta-data.

williamcotton 13y ago
Thank you for mentioning Smalltalk! My comment was heavily inspired by that "computing environment". If you look at JavaScript and the web browser... well, it's more like a Smalltalk system than a UNIX system! There are no files! It has a weird little dynamic multi-paradigm language! The web browser become the spiritual offspring of Smalltalk as soon as Brendan tacked on JS. :) Look how WEIRD package management gets for JS when you try and make it supported by UNIX and the filesystem! As for tools becoming language dependent... what about sourceMaps? Look at how CoffeeScript integrates with our workflow tools these days! The biggest problem with Smalltalk was that it was made for Personal Computing, and ALWAYS had issues running other people's code or integrating well with collaborators. The web browser and JavaScript solve a lot of these issues with the whole sandboxed code environment... The web has NOTHING to do with files, so it seems like the perfect place to just forget about them and move forward... Relays and switches only got us so far... Machine code only got us so far... UNIX only got us so far... Why have we lost the courage to continue looking for better solutions and being brave enough to throw away certain concepts? I mean, look at mobile and touch computing! iOS and Android are completely abandoning the concept of files! Why? Because they don't really have to be there... Again, look at Smalltalk... and I know, it "failed", but do you really think it failed because it didn't have files? Is that the one reason? Is it even a reason at all??
- kyllo 13y ago
  The web has NOTHING to do with files, so it seems like the perfect place to just forget about them and move forward... What? I really don't understand this comment. The web is almost totally file-based. Visiting any website is just downloading and executing files. Including Javascript and CSS files is really just like a copy-paste operation--it just spews everything into the global namespace, which is that of the HTML file that you're currently viewing.
  - icebraining 13y ago
    They're representations of resources, not files. Some of them are stored as files on the server, but that's purely incidental and irrelevant to the browser; it treats them just the same as it treats the runtime generated representations, such as this HTML we're viewing.
    - boomlinde 13y ago
      Files are representations of resources as well. Some of these are mapped to data stored on disk blocks, but others aren't. Some file systems are not disk abstractions at all. While I agree that calling HTTP resources "files" is not entirely correct, they're presented in a very file system-like hierarchy, and in most cases I'd say that they are not meaningfully distinct from files in a file system. I definitely find "The web has NOTHING to do with files" less agreeable than what kyllo is saying.
      - williamcotton 13y ago
        Think about files in the context of a filesystem and an operating system. You can move them around, read to them, write to them, execute them... Now think about what the browser runtime can do with "files". Well, next to nothing, because the browser doesn't have access to a filesystem. For a browser to communicate with a filesystem it has to do so through HTTP and only in a very limited way.
        13y ago
ansible 13y ago
While Smalltalk is awesome, do keep in mind that in 1980 it only ran on very expensive machines, and the software license was also expensive. This was still true 10 years later. I've been thinking about a programming system that stores all the code in a database instead. Versioning would be easier that way too.
- icebraining 13y ago
  Version control is a database for storing code.
- Argorak 13y ago
  These kinds of systems already exist for a long time in widespread use: https://en.wikipedia.org/wiki/ABAP#ABAP_runtime_environment https://en.wikipedia.org/wiki/ABAP#ABAP_runtime_environment It is far less enjoyable than it sounds, especially as no standard tools can manage that code.
gngeal 13y ago
I would say the downside of this 'rich' environment is that your tools tend to become language dependent. That does not necessarily have to be the case. Just like you have abstract collections capable of handling values of any type, I don't see why it should be impossible to have a model of versionable, editable code into which you could inject your own implementations for the particular language you're coding in right now. I realized the other day how close persistent collections and tools like Git actually are. And given how most modern languages have programs that are essentially trees or groves, and given that said persistent collections tend to be trees...? Well, what do you think?

by t1m 13y ago

williamcotton 13y ago

Thank you for mentioning Smalltalk! My comment was heavily inspired by that "computing environment". If you look at JavaScript and the web browser... well, it's more like a Smalltalk system than a UNIX system! There are no files! It has a weird little dynamic multi-paradigm language! The web browser become the spiritual offspring of Smalltalk as soon as Brendan tacked on JS. :) Look how WEIRD package management gets for JS when you try and make it supported by UNIX and the filesystem! As for tools becoming language dependent... what about sourceMaps? Look at how CoffeeScript integrates with our workflow tools these days! The biggest problem with Smalltalk was that it was made for Personal Computing, and ALWAYS had issues running other people's code or integrating well with collaborators. The web browser and JavaScript solve a lot of these issues with the whole sandboxed code environment... The web has NOTHING to do with files, so it seems like the perfect place to just forget about them and move forward... Relays and switches only got us so far... Machine code only got us so far... UNIX only got us so far... Why have we lost the courage to continue looking for better solutions and being brave enough to throw away certain concepts? I mean, look at mobile and touch computing! iOS and Android are completely abandoning the concept of files! Why? Because they don't really have to be there... Again, look at Smalltalk... and I know, it "failed", but do you really think it failed because it didn't have files? Is that the one reason? Is it even a reason at all??

kyllo 13y ago
The web has NOTHING to do with files, so it seems like the perfect place to just forget about them and move forward... What? I really don't understand this comment. The web is almost totally file-based. Visiting any website is just downloading and executing files. Including Javascript and CSS files is really just like a copy-paste operation--it just spews everything into the global namespace, which is that of the HTML file that you're currently viewing.
- icebraining 13y ago
  They're representations of resources, not files. Some of them are stored as files on the server, but that's purely incidental and irrelevant to the browser; it treats them just the same as it treats the runtime generated representations, such as this HTML we're viewing.
  - boomlinde 13y ago
    Files are representations of resources as well. Some of these are mapped to data stored on disk blocks, but others aren't. Some file systems are not disk abstractions at all. While I agree that calling HTTP resources "files" is not entirely correct, they're presented in a very file system-like hierarchy, and in most cases I'd say that they are not meaningfully distinct from files in a file system. I definitely find "The web has NOTHING to do with files" less agreeable than what kyllo is saying.
    - williamcotton 13y ago
      Think about files in the context of a filesystem and an operating system. You can move them around, read to them, write to them, execute them... Now think about what the browser runtime can do with "files". Well, next to nothing, because the browser doesn't have access to a filesystem. For a browser to communicate with a filesystem it has to do so through HTTP and only in a very limited way.
      - 13y ago

ansible 13y ago

While Smalltalk is awesome, do keep in mind that in 1980 it only ran on very expensive machines, and the software license was also expensive. This was still true 10 years later. I've been thinking about a programming system that stores all the code in a database instead. Versioning would be easier that way too.

icebraining 13y ago
Version control is a database for storing code.
Argorak 13y ago
These kinds of systems already exist for a long time in widespread use: https://en.wikipedia.org/wiki/ABAP#ABAP_runtime_environment https://en.wikipedia.org/wiki/ABAP#ABAP_runtime_environment It is far less enjoyable than it sounds, especially as no standard tools can manage that code.

gngeal 13y ago

I would say the downside of this 'rich' environment is that your tools tend to become language dependent. That does not necessarily have to be the case. Just like you have abstract collections capable of handling values of any type, I don't see why it should be impossible to have a model of versionable, editable code into which you could inject your own implementations for the particular language you're coding in right now. I realized the other day how close persistent collections and tools like Git actually are. And given how most modern languages have programs that are essentially trees or groves, and given that said persistent collections tend to be trees...? Well, what do you think?