3 ms·

> you impose the restriction of knowing all logic in advance. > That's a grim constraint. That's the only way of writing a least buggy code, at least in my ex

> you impose the restriction of knowing all logic in advance. > That's a grim constraint. That's the only way of writing a least buggy code, at least in my experience. Changing the behavior of the codebase without any clue of how it works is nearly always leading to bugs and errors. > Now your software is not extensible by users. What? Of course it's extensible, you could reuse ML's module as well, it just imposes valuable restrictions, aka, if you have a mutually recursive functions, you can't simply add another mutual call, which is imho a good thing. Just look at OCaml's mirage OS, where there is alot of code reuse, and one modules extending others.

millstone 7y ago
> Changing the behavior of the codebase without any clue of how it works is nearly always leading to bugs and errors If you insist that all involved software components be in "the codebase," then you couldn't write this website, or the web browser you're using to read it, or the OS that my browser is running on. > What? Of course it's extensible, you could reuse ML's module as well, Users, I said. Plugins, scripting, OS, etc. Functional languages tend to be pretty bad at this stuff. For example, "call a function if it exists at runtime" is trivial in JS and Python, but hard to even formulate in Haskell.
- 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 ago
    Therefore 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.

millstone 7y ago

> Changing the behavior of the codebase without any clue of how it works is nearly always leading to bugs and errors If you insist that all involved software components be in "the codebase," then you couldn't write this website, or the web browser you're using to read it, or the OS that my browser is running on. > What? Of course it's extensible, you could reuse ML's module as well, Users, I said. Plugins, scripting, OS, etc. Functional languages tend to be pretty bad at this stuff. For example, "call a function if it exists at runtime" is trivial in JS and Python, but hard to even formulate in Haskell.

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