←back to thread

1401 points alankay | 1 comments | | HN request time: 0s | source

This request originated via recent discussions on HN, and the forming of HARC! at YC Research. I'll be around for most of the day today (though the early evening).
Show context
losvedir ◴[] No.11940630[source]
At my office a lot of the non-programmers (marketers, finance people, customer support, etc) write a fair bit of SQL. I've often wondered what it is about SQL that allows them to get over their fear of programming, since they would never drop into ruby or a "real" programming language. Things I've considered:

    * Graphical programming environment (they run the queries
      from pgadmin, or Postico, or some app like that)
    * Instant feedback - run the query get useful results
    * Compilation step with some type safety - will complain
      if their query is malformed
    * Are tables a "natural" way to think about data for humans?
    * Job relevance
Any ideas? Can we learn from that example to make real programming environments that are more "cross functional" in that more people in a company are willing to use them?
replies(7): >>11940734 #>>11940944 #>>11941125 #>>11941144 #>>11941516 #>>11942268 #>>11942793 #
numlocked ◴[] No.11941144[source]
SQL is declarative. Compare:

    for user in table_users:
        if user.is_active:
            return user.first_name;
vs:

    SELECT first_name FROM users_table
    WHERE is_active
It's unfortunate that the order of the clauses in SQL is "wrong" (e.g. you should say FROM, WHERE, SELECT: Define the universe of relevant data, filter it down, select what you care about), but it's still quite easy to wrap your mind around. You are asking the computer for something, and if you ask nicely, it tells you what you want to know. Compare that to procedural programming, where you are telling the computer what to do, and even if it does what you say, that may not have been what you actually wanted after all.
replies(6): >>11941223 #>>11941580 #>>11942931 #>>11943092 #>>11945089 #>>11959665 #
tomp ◴[] No.11945089[source]
I fail to see a meaningful difference between these two approaches, especially if we transform the first one in a list comprehension:

    [user.first_name for user in table_users if user.is_active]
replies(2): >>11945581 #>>11958062 #
1. numlocked ◴[] No.11958062[source]
Totally meaningful difference! With the list comprehension, you're still telling the machine how to go about getting the data; there is an explicit loop construct. With SQL, I'm simply declaring what results I want, and the implementation is left to the execution engine.

For instance, the SQL query can be parallelized, but not so with the Python list comprehension. If you wanted to create a version that could be run in parallel in Python, you'd have to do it with a map()/filter() construct. Ignoring readability for a sec (pretend it's nice and elegant, like it would be in e.g. Clojure), you are still specifying how the machine should accomplish the goal, not the goal itself.

    filter(lambda x: x is not None, map(lambda u: u.first_name if u.is_active else None, table_users))