←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 #
1. dkersten ◴[] No.11959665[source]
It's unfortunate that the order of the clauses in SQL is "wrong"

SQL is written goal-oriented.

You start with what you want (the goal). Then you specify from where (which can also be read as "what", since each table generally describes a thing) and finally you constrain it to the specific instances you care about.

SELECT the information I want FROM the thing that I care about WHERE condition constrains results to the few I want

Having said that, I would personally still prefer it in reverse like you say. I can see the value of how SQL does it, though, especially for non-programmers who think less about the process of getting the results and more about the results they want (because they haven't been trained to think of the process, like programmers have).

It makes sense for someone who isn't thaaaaat technical to start with "well, I want the name and salary of the employee but only those that are managers": SELECT name, salary FROM employee WHERE position = 'manager'

Admittedly even that isn't perfect and I assume that it wouldn't take much for someone to learn the reverse.