4 ms·

I quiet like declarative code. SQL, regex, and recently XLST just seem to click in my head. It's like telling the computer what output you want. Like providing

I quiet like declarative code. SQL, regex, and recently XLST just seem to click in my head. It's like telling the computer what output you want. Like providing the output scaffold and leaving the computer to fill it. The more I read about functional programming the more it seems like that. Am I correct in my assumption? Is functional programming declarative? Is all functional programming declarative? APL seems a little like this from my research. The thing that confuses me is that under the hood isn't the computer doing those loops? It's just hidden from you?

dkarl 4y ago
Declarative versus imperative is sometimes in the eye of the beholder. Helping a C++ friend of mine with some Scala code the other day, there was a line like this: val requests = availableDrivers.filter(notPhonedHome).map(pleasePhoneHomeRequest) When I explained filter and map to him, he thought of them as imperative. "Okay, filter loops over the array of available drivers and collects the ones that haven't phoned home in a new array. Then map loops over that array, creates a status notification for each one, and collects them in another array." I thought of this line in a more declarative way: requests is a list of phone home requests for the drivers that haven't phoned home recently. Both of us used a simplified mental model that didn't fully reflect what the computer is doing. My model didn't account for memory allocations. His model didn't account for potential optimizations. Neither of our models accounted for type-level trickery, possible side effects of pleasePhoneHomeRequest, or error handling (although his was closer to accounting for side effects and error handling.) Does the intermediate array actually get constructed? What happens if pleasePhoneHomeRequest throws an exception? Is requests a concrete collection type, or is it something akin to an iterator? In practice, a language like SQL has similar concerns. Occasionally you may need to be aware that an awkwardly constructed query requires space that exceeds the size of the relevant data, or that a delete cascades in a way that is inherently slow. tl;dr Functional programming idioms are designed to let you think more declaratively when you read and write code, but sometimes the declarative view isn't adequate for understanding the code.
valenterry 4y ago
No it is not. Functional programming (at least before the term got watered down) is all about referential transparency, which has some major implications of how you read and write code, e.g. allowing to apply equational reasoning and making effects explicit. Because it requires some more abstract concepts to be practically useful, you will also see the same people tending more in the direction of declarative programming - but strictly speaking the two things are independent of each other. > The thing that confuses me is that under the hood isn't the computer doing those loops? It's just hidden from you? No. Under the hood the computer is doing conditional jumps. And yeah, those are hidden from you. :)
- account-5 4y ago
  > No. Under the hood the computer is doing conditional jumps. And yeah, those are hidden from you. :) Of course my apologies. I was more thinking about in the language it's written in (C for some of it?). But yes at the assembly level. It took me a while to get my head around it for J (array language written in C), which under the hood must be using a loop but you don't explicitly loop in array languages.
  - valenterry 4y ago
    > was more thinking about in the language it's written in Depends, but does it matter? It's usually recursion that is executed fast and with little overhead.

dkarl 4y ago

Declarative versus imperative is sometimes in the eye of the beholder. Helping a C++ friend of mine with some Scala code the other day, there was a line like this: val requests = availableDrivers.filter(notPhonedHome).map(pleasePhoneHomeRequest) When I explained filter and map to him, he thought of them as imperative. "Okay, filter loops over the array of available drivers and collects the ones that haven't phoned home in a new array. Then map loops over that array, creates a status notification for each one, and collects them in another array." I thought of this line in a more declarative way: requests is a list of phone home requests for the drivers that haven't phoned home recently. Both of us used a simplified mental model that didn't fully reflect what the computer is doing. My model didn't account for memory allocations. His model didn't account for potential optimizations. Neither of our models accounted for type-level trickery, possible side effects of pleasePhoneHomeRequest, or error handling (although his was closer to accounting for side effects and error handling.) Does the intermediate array actually get constructed? What happens if pleasePhoneHomeRequest throws an exception? Is requests a concrete collection type, or is it something akin to an iterator? In practice, a language like SQL has similar concerns. Occasionally you may need to be aware that an awkwardly constructed query requires space that exceeds the size of the relevant data, or that a delete cascades in a way that is inherently slow. tl;dr Functional programming idioms are designed to let you think more declaratively when you read and write code, but sometimes the declarative view isn't adequate for understanding the code.

valenterry 4y ago

No it is not. Functional programming (at least before the term got watered down) is all about referential transparency, which has some major implications of how you read and write code, e.g. allowing to apply equational reasoning and making effects explicit. Because it requires some more abstract concepts to be practically useful, you will also see the same people tending more in the direction of declarative programming - but strictly speaking the two things are independent of each other. > The thing that confuses me is that under the hood isn't the computer doing those loops? It's just hidden from you? No. Under the hood the computer is doing conditional jumps. And yeah, those are hidden from you. :)

account-5 4y ago
> No. Under the hood the computer is doing conditional jumps. And yeah, those are hidden from you. :) Of course my apologies. I was more thinking about in the language it's written in (C for some of it?). But yes at the assembly level. It took me a while to get my head around it for J (array language written in C), which under the hood must be using a loop but you don't explicitly loop in array languages.
- valenterry 4y ago
  > was more thinking about in the language it's written in Depends, but does it matter? It's usually recursion that is executed fast and with little overhead.