4 ms·

> program hiding state in layers of objects is often counterproductive Do you think it was counterproductive to hide OS-specific file handles, CRT level of ca

> program hiding state in layers of objects is often counterproductive Do you think it was counterproductive to hide OS-specific file handles, CRT level of caching, and many other things CRT does behind these opaque FILE* object pointers? Such hiding allowed to have very similar and quite easy to use <stdio.h> across all platforms. The implementation of these fopen and fwrite functions relies on kernel calls like open/write on Linux and CreateFile/WriteFile on Windows. Do you think it was counterproductive to hide all the lower-level stuff like OS caches, inodes (linux) / NTFS (windows), and the rest of them, behind these OS kernel calls? If you’ll decide to unhide them, your OS won’t have any security at all, the OS file system cache is security sensitive. Modern OSes implement strict access control while they hide that piece of state, every file has permissions, every process accessing them has user identity, and the OS checks these things when process access files or file system cache.

jstimpfle 8y ago
> Do you think it was counterproductive to hide OS-specific file handles, CRT level of caching, and many other things CRT does behind these opaque FILE* object pointers? To answer that question for parent, no, he obviously doesn't think so. And yes, streams are basically OOP (they are implemented using "method dispatch"). Streams are one of the few successful abstractions out there. And when I say "successful" I mostly mean "necessary". Because they're leaky. Consider fseek(3), ftell(3), fileno(3), fflush(3), fclose(3), fsync(2), posix_fadvise(2), isatty(2), fcntl(2), ioctl(2) and many more. All operations that are not supported for all streams, but necessary for some (like file system files, network connections, terminals devices...). Essentially when you use any of these you concede to break the abstraction. It's incredibly hard to handle these streams correctly, and the vast majority of programs are faulty in that they don't handle most error conditions correctly. In some cases, it isn't even possible to handle errors through the API! See close(2) So again, not saying we shouldn't have a stream abstraction. But abstractions come at a huge price, and therefore it's incredibly misguided to make every program a layering of thousands of pseudo-isolated objects that bring their own bug-prone abstractions and idiosyncrasies.
- Const-me 8y ago
  > Streams are one of the few successful abstractions out there. I don’t think they’re few. I think all modern software uses OOP-based abstractions heavily. For example, for GUIs, it’s visual trees everywhere. HTML DOM is the most widely used one now, but pretty much every GUI framework have something conceptually similar, even 30 years old WinAPI is built on very OOP-like concepts, you have HWND handles but the state is completely hidden and can only be accessed by calling functions. > Because they're leaky. No abstraction is 100% waterproof, but some are useful enough for many practical applications, despite they leak occasionally. These particular file I/O API is less leaky on Windows, but they still leak, and there’re many weird low-level APIs to bypass these abstractions: DeviceIoControl, defragmentation API, backup API, and many others. > abstractions come at a huge price I’m not convinced the price is > 0. We can always skip any abstraction we don’t like and use the next lower-level one. We don’t often do that because developing code based on these lower-level things is often more expensive than using the abstractions, despite they leak. That’s why people use Electron & JavaScript, Java & .NET, game engines. They all made from large count of the layers you’re talking about, and when they leak that’s indeed can be very expensive to diagnose and fix/workaround. However, dropping them and developing something from lower levels is usually way more expensive.
  - jstimpfle 8y ago
    The last Electron app I've used (one of these new chat apps, forgot the name) was dog slow (on my $700 computer from 2018), and gave my computer a hang up (probably triggered a graphics driver issue, or sth related with too much memory consumption).
    - Const-me 8y ago
      I don’t like Electron too much, and I don’t program Electron apps (I mostly code C++ and C#), but I saw good products built on Electron. For example, visual studio code is fine. It’s the same story with all high-level tools. They’re easier to use and have lower barrier to entry, used by less skilled programmers who fail to deliver good products. For example, Unity3D has very low barrier and there’re many low-quality games built with that. But if developers know what they’re doing it is possible to build great games, e.g. cities skyline.

jstimpfle 8y ago

> Do you think it was counterproductive to hide OS-specific file handles, CRT level of caching, and many other things CRT does behind these opaque FILE* object pointers? To answer that question for parent, no, he obviously doesn't think so. And yes, streams are basically OOP (they are implemented using "method dispatch"). Streams are one of the few successful abstractions out there. And when I say "successful" I mostly mean "necessary". Because they're leaky. Consider fseek(3), ftell(3), fileno(3), fflush(3), fclose(3), fsync(2), posix_fadvise(2), isatty(2), fcntl(2), ioctl(2) and many more. All operations that are not supported for all streams, but necessary for some (like file system files, network connections, terminals devices...). Essentially when you use any of these you concede to break the abstraction. It's incredibly hard to handle these streams correctly, and the vast majority of programs are faulty in that they don't handle most error conditions correctly. In some cases, it isn't even possible to handle errors through the API! See close(2) So again, not saying we shouldn't have a stream abstraction. But abstractions come at a huge price, and therefore it's incredibly misguided to make every program a layering of thousands of pseudo-isolated objects that bring their own bug-prone abstractions and idiosyncrasies.

Const-me 8y ago
> Streams are one of the few successful abstractions out there. I don’t think they’re few. I think all modern software uses OOP-based abstractions heavily. For example, for GUIs, it’s visual trees everywhere. HTML DOM is the most widely used one now, but pretty much every GUI framework have something conceptually similar, even 30 years old WinAPI is built on very OOP-like concepts, you have HWND handles but the state is completely hidden and can only be accessed by calling functions. > Because they're leaky. No abstraction is 100% waterproof, but some are useful enough for many practical applications, despite they leak occasionally. These particular file I/O API is less leaky on Windows, but they still leak, and there’re many weird low-level APIs to bypass these abstractions: DeviceIoControl, defragmentation API, backup API, and many others. > abstractions come at a huge price I’m not convinced the price is > 0. We can always skip any abstraction we don’t like and use the next lower-level one. We don’t often do that because developing code based on these lower-level things is often more expensive than using the abstractions, despite they leak. That’s why people use Electron & JavaScript, Java & .NET, game engines. They all made from large count of the layers you’re talking about, and when they leak that’s indeed can be very expensive to diagnose and fix/workaround. However, dropping them and developing something from lower levels is usually way more expensive.
- jstimpfle 8y ago
  The last Electron app I've used (one of these new chat apps, forgot the name) was dog slow (on my $700 computer from 2018), and gave my computer a hang up (probably triggered a graphics driver issue, or sth related with too much memory consumption).
  - Const-me 8y ago
    I don’t like Electron too much, and I don’t program Electron apps (I mostly code C++ and C#), but I saw good products built on Electron. For example, visual studio code is fine. It’s the same story with all high-level tools. They’re easier to use and have lower barrier to entry, used by less skilled programmers who fail to deliver good products. For example, Unity3D has very low barrier and there’re many low-quality games built with that. But if developers know what they’re doing it is possible to build great games, e.g. cities skyline.