9 ms·

The fact that something like this is necessary just goes to show you how much of a failure SQL is compared to what it was supposed to be. Remember the promise

The fact that something like this is necessary just goes to show you how much of a failure SQL is compared to what it was supposed to be. Remember the promise of a "declarative language" where you just had to tell it what you want, and it took care of the details?

sokoloff 13y ago
SQL is a reasonably declarative language in that it will give you the correct answer without you knowing all the gory internal details. This quiz is about performance tuning, not correctness. For plenty of valuable real-people use cases, it's plenty fast without any performance tuning.
Guvante 13y ago
As much as we would love to have a magical language that knows exactly how to take anything and make it performant enough, there is a decent amount of evidence to say that is impossible. Honestly though the nice thing about SQL is you can quickly get something that works, and then use tracing tools to figure out what is taking longer than it should.
jcampbell1 13y ago
I reach the opposite conclusion. These are premature optimization tweaks which means tons of people are using SQL successfully without knowing them. You could argue CSS is a failure, because designers don't know that #sidebar .widget is slower than .widget I'd argue that it is evidence CSS is a success because it makes no real difference, and people opt for the more readable solution.
- taeric 13y ago
  Do you have a good link for numbers on this css point? I would expect speed differences, but my naive view would be that they wouldn't be much.
  - rimantas 13y ago
    The difference is not worth talking about at all.
  - jcampbell1 13y ago
    The difference is probably .1us. You may find it interesting why browsers match CSS selectors from right to left (though this is a useless bit of trivia). see: http://stackoverflow.com/questions/5797014/why-do-browsers-match-css-selectors-from-right-to-left http://stackoverflow.com/questions/5797014/why-do-browsers-m...
- bduerst 13y ago
  I tried to think of an analogy of someone dragging CSS into this conversation, but I couldn't. Maybe like throwing a dead cat into a room full of aristocrats?
  - rschmitty 13y ago
    You said cats and aristocrats and all I could think of was the movie The Aristocats.. so to me they seemed related :x
- nousernamesleft 13y ago
  >These are premature optimization tweaks How can you apply a blanket "premature" to this? The questions are simply "can this be improved?". There's nothing premature about it, it is a quiz.
  - jcampbell1 13y ago
    It is a reference to this well known quote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." --Donald Knuth
    - nousernamesleft 13y ago
      I am aware of that quote. And that is precisely my point, he is talking about premature optimization, not optimization. What could possibly make you think that the questions in this quiz are examples of premature optimization?
    - skyebook 13y ago
      Except using indexes is a major part of developing for a database. In many simple schemas, performance will completely break down without proper indexing. That's a bit different than spending time investigating if for-each is faster than a traditional loop.
      - jcampbell1 13y ago
        > Except I am not sure what the exception is about. I agree 100% with the rest of your comment.
        skyebook 13y ago
        My exception was to the idea of this being a premature optimization (sorry, I probably should've replied directly to your comment with the CSS example)
deleted 13y ago
[deleted]
Spooky23 13y ago
Promise delivered. Think of the first question. If you're going to use a function to transform data, you're going to take a performance hit vs. just doing and indexable operation against the data. If you want a facility that will magically figure out what you want when you are unable to express what you want, good luck. That's unicorn territory.
- thwarted 13y ago
  Reminds me of this Babbage quote: "On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." ~ Charles Babbage
fleitz 13y ago
SQL is a query language and an RDBMS is an implementation. It's like calculus, you can compute efficiently or inefficiently it has nothing to do with calculus. The same developers that make retarded SQL queries make god awfully slow programs with their pointer chasing mess because they don't understand that their programs run on actual real hardware and that a cache miss is pretty much the single most expensive operation a modern CPU can make by 2 to 3 orders of magnitude. They just go on and on about interfaces, inline methods, virtual methods, etc, and never check whether their fancy smancy object fits on a cache line. Its the same with databases they just talk about 'webscale' and 'big data' abandon SQL and then wonder why their DB explodes once it reaches 100 GB.
cleaver 13y ago
SQL is a bit deceptive in that it cloaks set-based operations in something apparently simple. Iterative operations are easier for most people to conceptualize—you could create a flow chart, whereas sets require a bit of math. Once you can think in terms of sets, SQL becomes a lot clearer. The issue with sets is, in my opinion, the root of problems in Object-Relational Mapping. There were other query languages that were less of a messy compromise. QUEL, for example was based more rigorously on relational calculus. I think it never took off because the dumbed-down SQL was a little easier for programmers to conceptualize initially.
- eru 13y ago
  Actually SQL gives you bag semantics, not set semantics. (But otherwise, yes.)

sokoloff 13y ago

SQL is a reasonably declarative language in that it will give you the correct answer without you knowing all the gory internal details. This quiz is about performance tuning, not correctness. For plenty of valuable real-people use cases, it's plenty fast without any performance tuning.

Guvante 13y ago

As much as we would love to have a magical language that knows exactly how to take anything and make it performant enough, there is a decent amount of evidence to say that is impossible. Honestly though the nice thing about SQL is you can quickly get something that works, and then use tracing tools to figure out what is taking longer than it should.

jcampbell1 13y ago

I reach the opposite conclusion. These are premature optimization tweaks which means tons of people are using SQL successfully without knowing them. You could argue CSS is a failure, because designers don't know that #sidebar .widget is slower than .widget I'd argue that it is evidence CSS is a success because it makes no real difference, and people opt for the more readable solution.

taeric 13y ago
Do you have a good link for numbers on this css point? I would expect speed differences, but my naive view would be that they wouldn't be much.
- rimantas 13y ago
  The difference is not worth talking about at all.
- jcampbell1 13y ago
  The difference is probably .1us. You may find it interesting why browsers match CSS selectors from right to left (though this is a useless bit of trivia). see: http://stackoverflow.com/questions/5797014/why-do-browsers-match-css-selectors-from-right-to-left http://stackoverflow.com/questions/5797014/why-do-browsers-m...
bduerst 13y ago
I tried to think of an analogy of someone dragging CSS into this conversation, but I couldn't. Maybe like throwing a dead cat into a room full of aristocrats?
- rschmitty 13y ago
  You said cats and aristocrats and all I could think of was the movie The Aristocats.. so to me they seemed related :x
nousernamesleft 13y ago
>These are premature optimization tweaks How can you apply a blanket "premature" to this? The questions are simply "can this be improved?". There's nothing premature about it, it is a quiz.
- jcampbell1 13y ago
  It is a reference to this well known quote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." --Donald Knuth
  - nousernamesleft 13y ago
    I am aware of that quote. And that is precisely my point, he is talking about premature optimization, not optimization. What could possibly make you think that the questions in this quiz are examples of premature optimization?
  - skyebook 13y ago
    Except using indexes is a major part of developing for a database. In many simple schemas, performance will completely break down without proper indexing. That's a bit different than spending time investigating if for-each is faster than a traditional loop.
    - jcampbell1 13y ago
      > Except I am not sure what the exception is about. I agree 100% with the rest of your comment.
      - skyebook 13y ago
        My exception was to the idea of this being a premature optimization (sorry, I probably should've replied directly to your comment with the CSS example)

deleted 13y ago

[deleted]

Spooky23 13y ago

Promise delivered. Think of the first question. If you're going to use a function to transform data, you're going to take a performance hit vs. just doing and indexable operation against the data. If you want a facility that will magically figure out what you want when you are unable to express what you want, good luck. That's unicorn territory.

thwarted 13y ago
Reminds me of this Babbage quote: "On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." ~ Charles Babbage

fleitz 13y ago

SQL is a query language and an RDBMS is an implementation. It's like calculus, you can compute efficiently or inefficiently it has nothing to do with calculus. The same developers that make retarded SQL queries make god awfully slow programs with their pointer chasing mess because they don't understand that their programs run on actual real hardware and that a cache miss is pretty much the single most expensive operation a modern CPU can make by 2 to 3 orders of magnitude. They just go on and on about interfaces, inline methods, virtual methods, etc, and never check whether their fancy smancy object fits on a cache line. Its the same with databases they just talk about 'webscale' and 'big data' abandon SQL and then wonder why their DB explodes once it reaches 100 GB.

cleaver 13y ago

SQL is a bit deceptive in that it cloaks set-based operations in something apparently simple. Iterative operations are easier for most people to conceptualize—you could create a flow chart, whereas sets require a bit of math. Once you can think in terms of sets, SQL becomes a lot clearer. The issue with sets is, in my opinion, the root of problems in Object-Relational Mapping. There were other query languages that were less of a messy compromise. QUEL, for example was based more rigorously on relational calculus. I think it never took off because the dumbed-down SQL was a little easier for programmers to conceptualize initially.

eru 13y ago
Actually SQL gives you bag semantics, not set semantics. (But otherwise, yes.)