

Programming and Computer Science: an imminent divorce? - eLobato
http://blog.txus.io/2014/10/programming-and-computer-science-an-imminent-divorce/

======
rnovak
_learn functional programming, learn Clojure, Elm, Haskell, Idris and whatnot.
Introduce a functional programming language into your organization 's tech
stack_

Since when does Functional === Computer Science?

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

~~~
tome
Could you elaborate on that?

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

~~~
tome
So where does it fit?

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

~~~
tome
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)

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

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

