3 ms·
I don't buy this. The paradigm I use often depends on the level of abstraction I'm working with. A functional runtime is ultimately built upon an imperative f
by davexunit 11y ago
I don't buy this. The paradigm I use often depends on the level of abstraction I'm working with. A functional runtime is ultimately built upon an imperative foundation. I write mostly purely functional code in Scheme, but from time to time I add my own imperative components to the foundation. I don't really want to use languages that restrict me to a single paradigm.
- TazeTSchnitzel 11y ago> A functional runtime is ultimately built upon an imperative foundation. Not necessarily. Functional language compilers are very sophisticated and do not necessarily compile code the way you might think.
- knz42 11y agoThe functional runtime (i.e. not compiler) is built upon an imperative foundation. This is necessarily so as long as hardware computer are built upon state-modifying processors and random access, in-place updatable memories.
- innguest 11y agoSo what? It's Turing-complete so it can simulate any non-Von Neumann machine that can compute. And in fact it does so very well, see Forth, Lisp, and other languages from different paradigms for which there are dedicated processors. If you use an abstraction (your job as a programmer) the innards of the processor should approach inconsequential.
- davexunit 11y agoThat code is ultimately compiled to run inside of a register machine. A language may give you a functional interface to something like disk I/O, but the underlying implementation is inherently imperative. Or how about the purely functional programming language Elm, whose runtime is imperative JavaScript? For the record, I prefer purely functional programming, but it's not the only tool in the tool box.
- TazeTSchnitzel 11y ago> That code is ultimately compiled to run inside of a register machine. It is, but the code barely resembles the code most imperative programmers would write.
- DanWaterworth 11y ago> A functional runtime is ultimately built upon an imperative foundation. Memory safe languages are ultimately built upon an unsafe foundation.
- davexunit 11y agoSorry if I'm being dense here, I understand the pattern of argument you're using, but I just don't understand what point you were trying to make. Could you explain?
- DanWaterworth 11y agoIt's an abstraction. If it's solid, it doesn't matter what's underneath.
- davexunit 11y agoSure, I agree. My point is that sometimes we have to build these abstractions, so I like to use languages where I can program mostly in a functional style, but use another paradigm when appropriate.
- TazeTSchnitzel 11y ago> but from time to time I add my own imperative components to the foundation Why? Do you not know how to perform a specific task within functional code? In which case, you should probably take that opportunity to find out how to do it.
- davexunit 11y ago>Do you not know how to perform a specific task within functional code? It's not that I didn't know, it's that the process was imperative at its core. For example, I am working on a rendering engine using OpenGL. The high-level scene graph interface is purely functional, but rendering such a scene graph is an imperative process: binding textures, vertex arrays, shaders, writing to a framebuffer, etc. This low-level rendering code is the functional runtime for the high-level API.
- TazeTSchnitzel 11y agoAh, I see. You could do that within a purely functional language (via monads), but given how locked to C and the imperative paradigm OpenGL is, it would make sense to simply write that in C, yes.
- davexunit 11y agoI think monads are orthogonal to this issue. Using a monad would provide a pure interface around the imperative stuff, but the imperative stuff would still be there. Someone's gotta write the gross stuff so that we can build our pleasant, pure world on top of it.