Most active commenters
  • numlocked(3)

←back to thread

Alan Kay has agreed to do an AMA today

1401 points alankay | 13 comments | 20 Jun 16 18:04 UTC | HN request time: 0.001s | source | bottom

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 ◴[20 Jun 16 19:25 UTC] 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 #
1. numlocked ◴[20 Jun 16 20:14 UTC] 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 #
2. niftich ◴[20 Jun 16 20:22 UTC] No.11941223[source]▶
Along this point, C# and VB.NET have SQL-like expressions that can be used for processing, called LINQ [1]. They even get the order of the clauses correct!

A feature like this may help your programmers who are used to thinking in terms of filter -> select -> order.

[1] https://msdn.microsoft.com/en-us/library/bb397927.aspx

replies(2): >>11941644 #>>11955161 #
3. macca321 ◴[20 Jun 16 21:06 UTC] No.11941580[source]▶
It may be that its easier for people to define the desired result set, then tweak the query until it gives them what they want.
4. numlocked ◴[20 Jun 16 21:15 UTC] No.11941644[source]▶
Yes! Absolutely what I was thinking of when I wrote this :) Getting that right is one of my favorite parts of LINQ.
5. taneq ◴[21 Jun 16 01:39 UTC] 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 #
6. dangoldin ◴[21 Jun 16 02:25 UTC] No.11943092[source]▶
To play devil's advocate Prolog is considered much more similar to SQL than any other language and I suspect that will have an extremely high learning cost. That may be me being biased due to learning procedural languages first. At the same time I consider myself well versed in SQL.
replies(1): >>11946278 #
7. qb45 ◴[21 Jun 16 05:22 UTC] 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.

8. tomp ◴[21 Jun 16 12:12 UTC] 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 #
9. iajrz ◴[21 Jun 16 13:55 UTC] No.11945581[source]▶
But a list comprehension is a declarative construct, which can be best appreciated when porting some list comprehensions into loops. Especially nested comprehensions.
10. deong ◴[21 Jun 16 15:19 UTC] No.11946278[source]▶
I think Prolog suffers in that comparison mostly because of its much more ambitious scope. Most non-developer/DBA people have no concept of what a SQL query is actually doing, whereas most nontrivial Prolog programs require conceptualizing the depth-first-search you're asking the language to perform in order to get it right. If you restricted your Prolog world to the kind of "do some inference on a simple family tree database of facts" that people first learn, Prolog would be pretty easy too.
11. moosingin3space ◴[22 Jun 16 16:35 UTC] No.11955161[source]▶
Ecto (Elixir) does the from-in-where syntax as well.
12. numlocked ◴[23 Jun 16 00:20 UTC] 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))
13. dkersten ◴[23 Jun 16 08:56 UTC] 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.