5 ms·

Completely disagree. Composing SQL queries even on multiple levels (as in subqueries) might involve a way of thinking that remotely resembles to functional prog

• fusiongyro 14y ago
  I disagree with both of you. I think you're underestimating what can be done in SQL--recursive queries and correlated subqueries are not part of most competent developers' "standard toolkit"--but I think you're illustrating the problem with the OP's point, which is that most competent developers get through joins and outer joins (usually inheriting a lot of weird mythology like "joins are expensive") and can select/project and that's about where the skills end. So while I disagree with you in principle, in practice most people's SQL skills are inadequate even for an analogy to functional programming. I would not say that the thought process I use when writing SQL queries is "more like" my thought process when doing functional programming than imperative programming. In truth, the similarity is all in what isn't present: I'm not deeply worried about what the machine is going to do with my request and how it's going to process it. I remain cognizant of what's "really happening" to the extent that I want to avoid obvious performance pitfalls, but it doesn't become the overriding obsession that it is with procedural programming. With declarative programming I worry much less about whether the result is correct, and this is the primary benefit to me.
• tel 14y ago
  Haskell isn't just FP. It has a lot of other stuff, orthogonal stuff---most notably the HM type system---which really helps to take advantage of "pure" FP. Getting bogged down in Haskell doesn't mean that SQL doesn't have a lot of great compositional aspects that are inherited from its "more functional" nature.
• jeffdavis 14y ago
  "[SQL] is way too simplistic for comparison with real world functional programs" Another way of interpreting that is that the ideas behind SQL are so powerful that it's able to be one of the most successful programming languages of all time without all the bells and whistles of a language like haskell. It's so successful that it can get by with horrid syntax, a ton of special cases built in, and the mess of SQL NULL semantics. Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful. I don't necessarily disagree with you, depending on what you mean by "real world" programs. I just think that if there is already an area where the concepts are useful (whether you call that a "real world program" or not), it makes a lot of sense to keep trying to build from that. Trying to convince someone to learn haskell to build a website when they already know and like ruby is an uphill battle.
  • martinced 14y ago
    "Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful." But some do. For example Rich Hickey used Clojure (which both users and encourages FP but still allows to bend the rules when needed) to create Datomic. It's a DB but it's CRA instead of CRUD. Making it just so much easier to reason about. The DB is ever-growing and any query becomes "query at time t". And later on, when you query again "query at time t", you CANNOT get a different answer. Typical CRUD DBs are place-oriented mutability mess and, honestly, reading about MySQL fanbois vs PostgreSQL fanbois arguing about which one is the best looks, from a CRA point of view, as a blind man arguing with a one-eyed about who has the best eye vision. Datomic is ACID, has infinite read scalability and can use SQL DBs (and many others) as their persistence stores. It is as Real-World as one can get since that Rich Hickey as seen exactly what we're all witnessing daily in the real-IT-world: a gigantic ball of mutability mess. To me the revolution is on and there's no going back for those who switched. From there it's just a matter of time.
    • jeffdavis 14y ago
      Thank you. I knew that Datomic existed, and some of the basic things you pointed out here, but I'll take a closer look. It seems like you really think it has a lot of promise. That being said, I don't think CRA is a panacea. Databases will always have a "read, decide what to do, write" pattern (because that is what happens in the real world, and databases model the real world). If the read happens at time T, and the write happens at time T+100; then you could have a race condition if something happens at time T+50. Postgres can detect such race conditions by using true serializability (based on a technique called Serializable Snapshot Isolation[1]). It gets tricky to apply the same technique for temporal databases, though I believe it's possible. Do you happen to know what techniques Datomic offers users to help avoid/detect/resolve race conditions? Don't get me wrong. I think it's a very useful direction to go in. I've done a lot of work on temporal features in postgres. I'm also aware of some of the limitations, however. You still need some kind of coordination and something resembling locks or a conflict detector. (By the way, please avoid derogatory comments about people who make different technology choices than you do. An argument could be made that postgres is CRA. And even if not, CRA versus CRUD is a small part of what is actually important to users; many of whom face a different set of trade-offs than you do.) [1] http://drkp.net/papers/ssi-vldb12.pdf http://drkp.net/papers/ssi-vldb12.pdf