4 ms·
>If you insist that all involved software components be in "the codebase," Where did I insist on that? Again, I could reuse ML modules just fine, as simple as
by ernst_klim 7y ago
>If you insist that all involved software components be in "the codebase,"
Where did I insist on that? Again, I could reuse ML modules just fine, as simple as I could reuse Objects.
> Users, I said. Plugins, scripting, OS, etc.
I'm a mirage OS user and I extend it quite fine, I could extend filesystems, block devices, write my own plugins to it. Why would I need OOP for plugins and scripting? Why can't I use modules instead? You don't need open recursion for extendability, a decent module system is fine enough.
> call a function if it exists at runtime
It's a very bad practice leading to calamities. A good half of Gstreamer bugs I've met were like that: use one function if it's defined or use another code path otherwise.
This is exactly an explicitness I'm talking about, an obfuscated control flow, and I don't want to work with the codebase which employs that.
Late binding could be easily emulated in Haskell/OCaml with environment (hashtable or map) of functions. People just don't do it because it is malicious.
- AstralStorm 7y agoTherefore people do not do dynamic binding at all, making this worthless for most kinds of system programming. Dynamic binding was introduced to allow code sharing. (With concomitant DLL hell which is still better than the hell of patching statically linked packages.) Until FP grows some sort of schema (for type and functional safety) + dynamic loading functionality, it is dead as disco. As in impossible to use or you have to run through C or C++ making it an integration overhead. Native level function interface is the killer feature. It is why C, C++, secondarily Fortran, Java and C# are alive. It is why Haskell is not even close to being as popular as Lua or Python or Ruby or perhaps even Rust. OCaml is better but it just drops all your warranty when native code is involved.