Your quote is missing a crucial bit. The full quote is «we're not registered to do so, so we are on the wrong tracks».

You were supposed to take the last exit, to be on the local road instead of the highway. No, we cannot let you off on the highway. We are not allowed to stop here. There are no stops. We wait for another exit. Sorry.

Was that the situation?

My sympathies. And it’s sad to see you call it “what it is you did wrong”. Thus, also my apologies, for whenever I am on the wrong side of such interactions.

What’s with all the periods, one at the end of each paragraph? Fully wasted.

Is the full proposal available online?

Check the latest proxy statement for the AGM. This is where these votes are brought up in advance and then at the meeting they’re voting on, along with board seats.

Yes. Here is the proxy statement with the proposals: https://www.sec.gov/ix?doc=/Archives/edgar/data/0000789019/0...

You have to scroll down a bit to page 83 to get to the one the article is referencing.

My message here is off-topic, probably a rule violation, but…

I love this. I love how the users of Hacker News provide deep, real insights on pretty much any topic. Thank you!

Maybe it's ease of development, and resulting readability?

I did enjoy the example code, compared to the native javascript (both shown in the article):

  var draw = SVG().addTo('#drawing')
    , rect = draw.rect(100, 100).fill('#f06')

why would the native JavaScript not be something like (probably errors here, so like, not necessarily this precisely)

const div = document.getElementById('drawing');

div.innerHTML = `<svg width="100%" height="100%"><rect width="100" height="100" fill="#f06"/></svg>`;

obviously if the what is going in can have user input in some way then open to attack using innerHTML but otherwise it seems like the structure of the example native JavaScript is made in such a way as to make the SVG.js version seem super cool in comparison.

Let me reference fields as I create them:

  select xxxxx as a
       , a * 2 as b

This will be great! One of the things ClickHouse has had since 2016.

SQL needs to have `select` as the _last_ part, not the first. LINQ has had this for 2 decades by now: "from table_a as a, table_b as b where ... select a.blah, b.duh".

This is not relevant to GP's point. This is a separate topic, which... I don't really care, but I know a lot of people want to be able to write SQL as you suggest, and it's not hard to implement, so, sure.

Though, I think it might have to be table sources, then `SELECT`, then `WHERE`, then ... because you might want to refer to output columns in the `WHERE` clause.

WHERE clauses are pushed down into the query planner before the SELECT list is processed, that’s why HAVING exists.

The logical order, in full, is:

FROM

WHERE/JOIN (you can join using WHERE clauses and do FROM a,b still)

SELECT

HAVING

That's the order in which the processing happens, but this doesn't need to be reflected in the language. The language has this ordering so it sounds like a natural language which SQL was invented for.

See u/cyberax's comment below. It would be nice to be able to create scalar (as opposed to table-valued) bindings that can be referred to in a WHERE (or JOIN) clause. Currently it's SELECT that establishes such bindings, and... well, it's not terribly clear where they can be used (certainly in HAVING, but first you have to GROUP BY, no?). u/cyberax's idea is to have a LET for this that can come before WHERE and before SELECT.

I mean, I get it, but the big problem is, again, the different phases of execution. The projections you perform with a select can be absolutely arbitrary and do crazy ass things (like do more subqueries that return scalar values, and query planners are notoriously bad at pushing these down), which is why I was trying to say SELECT before WHERE (project before filtering) may be linguistically intuitive, but full of foot guns.

Something like a ‘let’ binding after the FROM/JOIN list would make sense, though - from the query planners perspective it’s nothing more than a token substitution and everything would compile the same.

Ideally, it needs to be "from", then arbitrary number of something like `let` statements that can introduce new variables, maybe interspersed with where-s, and then finally "select".

"select" can also be replaced with annotations, something like: `from table_1 t1 let t1.column_1 as @output_1 where ...` and then just collect all the @-annotated variables.

I need to write a lot of SQL, and it's so clumsy. Every time I need a CTE, I have to look into the documentation for the exact syntax.

> Ideally, it needs to be "from", then arbitrary number of something like `let` statements

Isn't that what a CTE is?

Not quite. u/cyberax wants scalar bindings, not table-valued bindings.

Something like

  FROM foo
  LET a = (x + y) * z
  SELECT a;

whereas CTEs are... Common Table Expressions.

That was kind of my first thought...

https://prql-lang.org/ and compile to SQL.

Thank you! This is indeed close to what I want from SQL!

The Pipe Query Syntax in GoogleSQL implements this elegantly as well:

https://docs.cloud.google.com/bigquery/docs/reference/standa...

Also in the Kusto Query Language (KQL) as used by Azure Log Analytics.

It sounds like we know the water usage for growing almonds.

It feels reasonable that we should have the same detail of information for data centers.

Norway, too.

Supported by who? Microsoft?

If a file server breaks basic Unix tools it should be unplugged and put in the garbage.