5 ms·

I think us programmers have a tendency to see things as all or nothing, even while we work daily with a number of technologies and languages that do things diff

by hvs 11y ago

I think us programmers have a tendency to see things as all or nothing, even while we work daily with a number of technologies and languages that do things differently. There is no reason that everything has to be declarative while benefiting from the advantages of declarative/functional languages. Most programmers use SQL on a daily basis and we don't hear arguments that it should be procedural to be inline with our other languages.

deleted 11y ago
[deleted]
0xdeadbeefbabe 11y ago
You do hear about ORMs though, which I think supports your point that SQL is better at what it does (than an ORM).
- lfowles 11y ago
  Are there notable ORMs that don't map to SQL? (Not familiar with databases at all)
  - 0xdeadbeefbabe 11y ago
    Anything is possible. My point is often you'd rather have SQL over an ORM that maps to SQL.
jerf 11y ago
I ranted a while ago on HN about how I don't believe in the existence of declarative: https://news.ycombinator.com/item?id=3507281 https://news.ycombinator.com/item?id=3507281 As I re-read it, read this article, and pondered some more, I'm revising my view a bit, and beginning to think of "declarative" as something like probability. This is debatable, but I tend to agree with the idea of probability as a measure of knowledge of a given agent, and all probabilities must be understood in the context of some agent for whom those are the correct probabilities, as opposed to being free-standing numbers. Similarly, declarative can be seen as relative to the programmer. Haskell code that looks like map (+1) . filter isEven . map (*2) may be declarative to one programmer while writing it, who doesn't care about the details, yet be essentially imperative to someone who, say, is tasked with optimizing that, and cares about exactly what the compiler does with that code and how. It's not a characteristic of the code, but the programmer's relationship to the code, which may even change over time. From this perspective, most things that proudly wear the label "declarative" can be seen as over-forcing you to be ignorant about their implementation details by making this unnecessarily opaque, for the purpose of wearing that label. Still not a tradeoff I like, vs. the same tech except transparent.
- tel 11y ago
  Another way of looking at this, which is well loved in the PL community, is that there is no one exact interpretation of a fragment of syntax. Haskell is interesting because it has both operational and equational semantics and you can choose which you'd like to apply at any given time. What's nice about this is that it removes the "programmer" from the equation and instead augments language with a bouquet of interpretations. Another Haskell interpretation, e.g., is the static nature of its typing relation. This is a good way of "understanding monads" as well. They're an algebraic structure which captures just enough to let us talk about a variety of sequential/operational semantic choices for our syntax. At the end of the day, though, they're just data and we can imbue them with all of the semantic notions we enjoy via the interpreter pattern. This is even more emphasized with the "Free Monad" pattern which lets the structure of the monad be very, very close to the syntactic notion.
  - jerf 11y ago
    "What's nice about this is that it removes the "programmer" from the equation and instead augments language with a bouquet of interpretations." Implicitly, I'm invoking the idea that a programmer is looking at a particular runtime. I feel like I have to put that in, or the whole distinction between declarative and imperative completely collapses anyhow. "X.sort()" conceptually simply invokes sorting behavior, possibly with a certain set of guarantees, but in practice, it's very unusual for that to be running so abstractly that the programmer can not penetrate down to relevant runtime details. And when that does happen, generally forces are created that start pushing all the switchable runtimes towards bug-for-bug compatibility, e.g. the web browser's Javascript runtime. It's not a "bad" thing that it collapses in that case, it just does, that is, consider this the mathematical "collapses" rather than the architectural. You have to have a certain amount of specificity in my opinion or there is no reasonable way to discuss "declarative" vs. "imperative".
    - tel 11y ago
      I think you do need "bug for bug" compatibility between semantics—because the other choice is worse—but that drives home what it takes to genuinely have alternative semantic choices: sufficient concision of definition to be able to maintain the choices! This is standard for programmers, though. It's architecture like any other.

by hvs 11y ago

deleted 11y ago

[deleted]

0xdeadbeefbabe 11y ago

You do hear about ORMs though, which I think supports your point that SQL is better at what it does (than an ORM).

lfowles 11y ago
Are there notable ORMs that don't map to SQL? (Not familiar with databases at all)
- 0xdeadbeefbabe 11y ago
  Anything is possible. My point is often you'd rather have SQL over an ORM that maps to SQL.

jerf 11y ago

I ranted a while ago on HN about how I don't believe in the existence of declarative: https://news.ycombinator.com/item?id=3507281 https://news.ycombinator.com/item?id=3507281 As I re-read it, read this article, and pondered some more, I'm revising my view a bit, and beginning to think of "declarative" as something like probability. This is debatable, but I tend to agree with the idea of probability as a measure of knowledge of a given agent, and all probabilities must be understood in the context of some agent for whom those are the correct probabilities, as opposed to being free-standing numbers. Similarly, declarative can be seen as relative to the programmer. Haskell code that looks like map (+1) . filter isEven . map (*2) may be declarative to one programmer while writing it, who doesn't care about the details, yet be essentially imperative to someone who, say, is tasked with optimizing that, and cares about exactly what the compiler does with that code and how. It's not a characteristic of the code, but the programmer's relationship to the code, which may even change over time. From this perspective, most things that proudly wear the label "declarative" can be seen as over-forcing you to be ignorant about their implementation details by making this unnecessarily opaque, for the purpose of wearing that label. Still not a tradeoff I like, vs. the same tech except transparent.

tel 11y ago
Another way of looking at this, which is well loved in the PL community, is that there is no one exact interpretation of a fragment of syntax. Haskell is interesting because it has both operational and equational semantics and you can choose which you'd like to apply at any given time. What's nice about this is that it removes the "programmer" from the equation and instead augments language with a bouquet of interpretations. Another Haskell interpretation, e.g., is the static nature of its typing relation. This is a good way of "understanding monads" as well. They're an algebraic structure which captures just enough to let us talk about a variety of sequential/operational semantic choices for our syntax. At the end of the day, though, they're just data and we can imbue them with all of the semantic notions we enjoy via the interpreter pattern. This is even more emphasized with the "Free Monad" pattern which lets the structure of the monad be very, very close to the syntactic notion.
- jerf 11y ago
  "What's nice about this is that it removes the "programmer" from the equation and instead augments language with a bouquet of interpretations." Implicitly, I'm invoking the idea that a programmer is looking at a particular runtime. I feel like I have to put that in, or the whole distinction between declarative and imperative completely collapses anyhow. "X.sort()" conceptually simply invokes sorting behavior, possibly with a certain set of guarantees, but in practice, it's very unusual for that to be running so abstractly that the programmer can not penetrate down to relevant runtime details. And when that does happen, generally forces are created that start pushing all the switchable runtimes towards bug-for-bug compatibility, e.g. the web browser's Javascript runtime. It's not a "bad" thing that it collapses in that case, it just does, that is, consider this the mathematical "collapses" rather than the architectural. You have to have a certain amount of specificity in my opinion or there is no reasonable way to discuss "declarative" vs. "imperative".
  - tel 11y ago
    I think you do need "bug for bug" compatibility between semantics—because the other choice is worse—but that drives home what it takes to genuinely have alternative semantic choices: sufficient concision of definition to be able to maintain the choices! This is standard for programmers, though. It's architecture like any other.