> My main observation from such things as baking directions seems to be that functional (being a highly declarative style) is great for high level, but that you need a way to carefully logic about the lower level details as well.
To go with my baking example. The declarative would be, "Dinner should be enough pizza for X people..." This is great and all, especially if you are strictly at the management "high level" view of the task at hand. (Especially since this is likely to be part of a whole other set of declared outcomes. "Party room with X tables, etc...") However, one is not going to be able to actually get pizza for the crowd this way.
Functional programming is very declarative, while still being totally specific. It is declarative in the sense that it describes what things are (as opposed to do this and that to get this thing), not in the sense that you give a list of constraints to a program and leave it to the program to make sense of those constraints - such as logic programming and linear programming. Descriptions like 'dinner should be enough pizza for X people' sounds like a constraint, like 'no more than 20 onions, at least 10 potatoes, potatoes are 0.5 currency per potato, you should have less cabbage than cod; maximize the nutritional value according to (linear function)'... Of course languages like Prolog has an understandable way of finding if a program satisfies all your constraints, but it is different from the execution model of an imperative language. Functional languages have the same execution model (well, from those that I've seen), only with a more functional style (and tools to do the functional style in a non-horrible looking way). The mathematical way of defining factorial is very declarative, yet it is also as specific as any imperative program you'd want to write to define factorial.
So I don't see what you mean about low/high level here.
I was referring to level of abstraction. At an abstract level, many functions simply describe what something is, not how to get it. Easiest example for me is X to the Y. The naive implementation of calculating that is terrible compared to a good way. Yet both are mathematically the same.
Essentially, the difference between a descriptive equation and an algorithm. :)
> I was referring to level of abstraction. At an abstract level, many functions simply describe what something is, not how to get it.
All functional programs describe what something is and how to get it (the what is the semantics of how you get it).
> Easiest example for me is X to the Y. The naive implementation of calculating that is terrible compared to a good way. Yet both are mathematically the same.
"X to the Y"? Are you talking about time complexity? That is just as much a problem in imperative programming as in functional programming. Or are you talking about some constant inefficiencies, such as using recursion instead of a loop? Even though you might write the algorithm in a functional manner, that doesn't necessarily mean that it is all cons lists and recursion all the way down. Those things might have been translated to a more efficient, imperative form by the compiler (GHC for Haskell will do that). The compiler can do more aggressive optimizations for a pure function than for a method that is restrained by a type signature like "takes a String, returns a Boolean, and can do everything from turning on the kitchen light to blowing up the Universe in between".
> Essentially, the difference between a descriptive equation and an algorithm. :)
All pure functions are algorithms. It's all programming, after all. I don't get the distinction in this context.
Yes, I was referring to the time and space complexities of actually calculating the values. If the pure function were the algorithm, then there would be no separating the two. However, since a pure function can be calculated by several algorithms, then we are really just putting off some of the major points, no? (Hell, even in the simple 8 * 2, we are glossing over what really happens. Few programmers really appreciate the way in which that math happens on the computer. And fewer still are aware of when this changes in their architecture. And for anyone that thinks this is just some elementary exercise, I challenge that you have not seen the effort it takes children to really appreciate how to calculate 8 * 2.)
This is all really missing my main assertion, though. What is your function for getting in your car and driving somewhere? Could this be written in such a way that everything was a "pure" function? Probably. My hunch is that it wouldn't really be that readable, though. Now, if we shift the paradigm such that one of the "primitives" is your current location, suddenly the directions are a lot more readable.
For an easy example on what I mean here, just look elsewhere in the thread where folks were writing the program for cooking things. By far the most readable is the imperative one.
> Yes, I was referring to the time and space complexities of actually calculating the values. If the pure function were the algorithm, then there would be no separating the two. However, since a pure function can be calculated by several algorithms, then we are really just putting off some of the major points, no? (Hell, even in the simple 8 * 2, we are glossing over what really happens.
Again: both imperative and functional algorithms can be implemented in several ways. Both imperative and functional algorithms can solve the same problem, but have different time complexities.
"However, since a pure function can be calculated by several algorithms, then we are really just putting off some of the major points, no?"
What? The semantics of a pure function shouldn't be changed when you actually compute it - there is no "functional algorithm execution algorithm". The actual code that gets evaluated can be pretty different from the actual code you wrote, though - maybe your lazy lists got implemented as for-loops. Maybe you used a list in some way that made it look like you had O(n) space complexity, but it got turned into a loop that didn't store intermediate values so the space complexity is actually O(1). So yes, time complexity can be a little decieving, in some cases, if the compiler is sufficiently smart. However, there is no magic about the actual semantics of a functional algorithm.
> This is all really missing my main assertion, though. What is your function for getting in your car and driving somewhere? Could this be written in such a way that everything was a "pure" function? Probably. My hunch is that it wouldn't really be that readable, though. Now, if we shift the paradigm such that one of the "primitives" is your current location, suddenly the directions are a lot more readable.
Maybe you could. I don't think many care, though, not even functional programmers. The only decently widespread language that I can think of that actually enforces purity is Haskell, and some people even prefer to write imperative code in it over other languages. I don't get this obsession of yours with trying to argue against pure functional programming in the very, very strict sense of the whole program being pure, if that is actually possible. I think there are very few that are upset about having to write imperative code for code that has to do with sequential commands. They might use pure functional programming for the computations that they need, but they'll effectively write imperative programs at the top level.
What they probably do want, though, is to be able to clearly distinguish what parts of their programs are pure and what parts of their programs are potentially effectful.
Ah, I think I see the misunderstanding I am causing. I am not arguing against pure functions as a whole. Just acknowledging the weakness that they can not often be the whole. Many of the arguments for pure functions seem to be based on the "if your application is nothing but a collection of pure functions, then it will be easier to logic about." My assertion is "use that which is easier to reason about where you can." In some cases, this will actually be mutable state based entities. In others, it will be pure functions.
I also fully grant that when one is trying to work in a massively shared state application, pure functions have massive benefits. Seems the real win is typically identifying that which can be easily shared and that which can not. And partitioning the program accordingly. (Which, is what you ended with. So, I believe we are actually in fairly violent agreement. :) )
To go with my baking example. The declarative would be, "Dinner should be enough pizza for X people..." This is great and all, especially if you are strictly at the management "high level" view of the task at hand. (Especially since this is likely to be part of a whole other set of declared outcomes. "Party room with X tables, etc...") However, one is not going to be able to actually get pizza for the crowd this way.
Functional programming is very declarative, while still being totally specific. It is declarative in the sense that it describes what things are (as opposed to do this and that to get this thing), not in the sense that you give a list of constraints to a program and leave it to the program to make sense of those constraints - such as logic programming and linear programming. Descriptions like 'dinner should be enough pizza for X people' sounds like a constraint, like 'no more than 20 onions, at least 10 potatoes, potatoes are 0.5 currency per potato, you should have less cabbage than cod; maximize the nutritional value according to (linear function)'... Of course languages like Prolog has an understandable way of finding if a program satisfies all your constraints, but it is different from the execution model of an imperative language. Functional languages have the same execution model (well, from those that I've seen), only with a more functional style (and tools to do the functional style in a non-horrible looking way). The mathematical way of defining factorial is very declarative, yet it is also as specific as any imperative program you'd want to write to define factorial.
So I don't see what you mean about low/high level here.