Programming and Computer Science: an imminent divorce?(blog.txus.io)
blog.txus.io
Programming and Computer Science: an imminent divorce?
http://blog.txus.io/2014/10/programming-and-computer-science-an-imminent-divorce/
10 comments
Maybe if the functional types had a bit more understanding of the situations where it's not appropriate, they'd get more traction in the real world in the places where it is appropriate.
Could you elaborate on that?
Functional programming (with immutability) is a really bad match for my world, which is event-driven embedded systems. (Garbage collection is also a bad idea if the system is real time. Yes, there are ways of working around it, but it's making your problem harder. Why do it?)
Even more, I wouldn't use immutable functional programming for writing an OS. An OS is all about mutating state that keeps track of resources.
For that matter, I wouldn't use functional programming in any situation where the nature of the problem cried out for mutating state.
I wouldn't use garbage-collected code to write a memory manager. I wouldn't use it to write crypto code (leaving old crypto data hanging around in memory is a major no-no).
But we get these loud zealots who tell us that FP is The One Right Way, and that we're stupid and/or ignorant if we don't convert at once. I suspect that a lot of people with experience just tune them out, because it's so obvious that what they're saying is unrealistic. But if they were a bit more aware of the variety of the real world of programming, and knew where FP worked and where it really didn't fit, they might get more of a hearing.
Even more, I wouldn't use immutable functional programming for writing an OS. An OS is all about mutating state that keeps track of resources.
For that matter, I wouldn't use functional programming in any situation where the nature of the problem cried out for mutating state.
I wouldn't use garbage-collected code to write a memory manager. I wouldn't use it to write crypto code (leaving old crypto data hanging around in memory is a major no-no).
But we get these loud zealots who tell us that FP is The One Right Way, and that we're stupid and/or ignorant if we don't convert at once. I suspect that a lot of people with experience just tune them out, because it's so obvious that what they're saying is unrealistic. But if they were a bit more aware of the variety of the real world of programming, and knew where FP worked and where it really didn't fit, they might get more of a hearing.
So where does it fit?
Here's the thing that the immutable folks get absolutely right: Constrain your state space or die. So FP fits pretty much every place it helps you do that.
Even in embedded systems, is it useful to have functions that don't depend on state? Can they simplify design, reasoning, and testability? Certainly.
So even in the domains I mentioned, you can do FP to the extent that the problem domain allows, and benefit from the smaller state space. My quarrel is with the "you must use it everywhere or you're just an ignorant heathen" zealots, not with FP itself.
Even in embedded systems, is it useful to have functions that don't depend on state? Can they simplify design, reasoning, and testability? Certainly.
So even in the domains I mentioned, you can do FP to the extent that the problem domain allows, and benefit from the smaller state space. My quarrel is with the "you must use it everywhere or you're just an ignorant heathen" zealots, not with FP itself.
Given your embedded background I wondered if you have any opinion of Ivory Tower, a Haskell EDSL developed by Galois for writing embedded C programs:
http://ivorylang.org/ivory-introduction.html
http://ivorylang.org/ivory-introduction.html
I have no opinion at this time. The web page didn't show me very much - it has Haskell syntax, OK; it won't cons on you all the time, good; it intends to be useful for systems programming, well and good. That's fine for the intent.
I'd want to know a bit about how it held up in practice before I gave a real opinion, and I don't know anything about that at present.
I'd want to know a bit about how it held up in practice before I gave a real opinion, and I don't know anything about that at present.
In my opinion/experience, functional programming is great for web applications. However, I believe it is much more generally applicable than AnimalMuppet.
> impressive levels of abstraction and composition
It's nice to see these two words used to describe the benefits of functional programming. One often hears "expressivity" and it's less clear to me what that means, precisely.
It's nice to see these two words used to describe the benefits of functional programming. One often hears "expressivity" and it's less clear to me what that means, precisely.
Since when does Functional === Computer Science?