←back to thread

1401 points alankay | 2 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 #
1. taneq ◴[] No.11942931[source]
> 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.

Procedural vs. functional phrasing in no way changes the basic fact that if you ask a computer the wrong question it'll give you the wrong result.

"go through the list of all users and add the ones which are active to a new list"

vs.

"the list I want contains all active users from the list of all users"

replies(1): >>11943664 #
2. qb45 ◴[] No.11943664[source]
In imperative you don't ask questions but give instructions.

As long as the instructions are longer than the question (and they often are, even in your example ;)), you are bound to make more errors here.

Plus, it requires some understanding of how this damn machine works in the first place.

When turning questions into instruction is decidable it pays off to automate it.