4 ms·

> 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

by Dewie 13y ago

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

taeric 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. 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. :)
- 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.

by Dewie 13y ago

taeric 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. 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. :)

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.