FRESH
Hacker News
Hacker News Hacker News> There's a really interesting approach in the Oberon system where a text file is a type called Text that's fundamental to the system. You typically interact with text files through the Texts module similar to the way you get a file pointer from fopen and nose your way through using fread in UNIX/C's stdio.h.
> One thing that's easy to miss (even when you're reading an explanation of it) is that Text is an abstract data type, and so while it may feel like you're interacting with a plain text file like on any other system, the reality is that the actual bytes on disk don't matter; as long as the Text ADT is able to support it (read: the Texts API gives you what you need), then hypothetically the file could be gzip-compressed binary serialization of XML for all it matters. (NB: It's not, though.)
> Oberon exploits this by having a "looks" subsystem in the same Texts module that's entirely orthogonal to the read (and write) operations of the textual content of the file. This means the Texts module is able to include APIs that let you adjust the color, font, and spacing of an arbitrarily selected range in any "text file"—even source code. So you can have italics, bold, etc. in your program's source, but because the compiler, like any other program, interacts with the files using the API from the Texts module, it doesn't matter that they're there, and the compiler's tokenizer is able to proceed through it all totally unaware.
I disagree. My experience is that most problems require a very thorough understanding of a specific slice of a system. It is rare (again, in my experience) that solving a problem involves understanding the whole system. This becomes more true the larger and more complex the system is. Abstractions allow you to ignore the irrelevant pieces and focus on what matters.