3 ms·

> 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

> 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.

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.