3 ms·

> 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 d

by Dewie 13y ago

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

taeric 13y ago
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.
- Dewie 13y ago
  > 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.
  - 13y ago

by Dewie 13y ago

taeric 13y ago

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.

Dewie 13y ago
> 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.
- 13y ago