I think they are solving two different problems at the same time. One is the order of elements in a single operation (SELECT then FROM then WHERE etc), and the second is the actual pipelining which replaces the need for nested queries.

It does seem like the former could be solved by just loosening up the grammar to allow you to specify things in any order. Eg this seems perfectly unambiguous:

  from customer
  group by c_custkey
  select c_custkey, count(*) as count_of_customers

Yeah, exactly. You don't need literal pipes

Space-wise, as long as you compress it, it's not going to make any difference. I suspect a JSON parser is a bit slower than a CSV parser, but the slight extra CPU usage is probably worth the benefits that come with JSON.

Example? I know there's some ambiguity over whether literals like false are valid JSON, but I can't think of anything else.

That _shouldn't_ be ambiguous, `false` is a valid JSON document according to specification, but not all parsers are compliant.

There's some interesting examples of ambiguities here: https://seriot.ch/projects/parsing_json.html

Trailing commas, comments, duplicate key names, for a few examples.

Trailing commas and comments are plainly not standard JSON under any definition. There are standards that include them which extend JSON, sure, but I'm not aware of any JSON library that emits this kind of stuff by default.

I'm not aware of any CSV library that doesn't follow RFC4180 by default, and yet... this whole thread.

I'd tone it down a little via:

“I'm planning on migrating the build system on Wednesday (26th); please let me know if you have any concerns.”

The original wording makes it sound like it's already been settled, so nobody will bother responding. But by saying planning, you might get some feedback.

I ran into exactly this the other day trying to browse a website from a browser app on an android-powered TV. Just couldn't get to the website.

Even if that worked, using these in a map/set would be a lot like using floating point numbers in a map/set - which is generally a bad idea.

Avoid scheduling events for January is just a good idea regardless. CES is the worst date possible.

This is a dumb position though because all logic would suggest the two ratios are proportional. Civilians are not significantly more likely to die of their injuries than non-civilians. While 12 is a bit of a small sample, it's not unreasonably small to make extrapolations.

> What if we could somehow design systems so that the people who use them evolve to use them in better ways?

I hate when people suggest that there is something insecure about using the password reset feature. Whether I chose to use it to get into my account without a password has no impact on the security of the account. The mere presence of this feature is what’s determining the security of my account.

Similarly, some services I use prompt me to verify via SMS or Email after I input the password, but oddly imply that using SMS is more secure than email. Makes no sense to me since either way the OTP should only be usable on this one session, and even if one is a less secure channel, it’s the presence of the weaker option in the first place that’s the problem, not the choice made by the user.

> Furthermore, what audience and level of mathematics education are we discussing?

I wonder this too, I think they might mean university-level as well. For younger audiences, I feel one of the biggest problems for most people to understand math is they don't understand why any of it is relevant. If educators can make it seem more like teaching general problem solving abilities, that will likely improve the overall acceptance and lead to better overall math skills as a result.

As a specific example, our high-school math curriculum taught a lot of calculus, but framed it incorrectly as being a useful tool that people would use. Eg as if a business man would write down an equation for their revenue based on inputs, and then take the derivative to compute the maximum. I'm assuming they told students this to try and get them motivated, but it clearly was a lie since everybody knows you could just plot a graph and look at it to find the maximum. If they instead were honest that the point of learning calculus was to help with understanding more advanced concepts in math/engineering/science, while also being a valuable learning tool for general problem solving, I think that would have been a better result.

> As a specific example, our high-school math curriculum taught a lot of calculus, but framed it incorrectly as being a useful tool that people would use.

One day at FedEx the BoD (board of directors) was concerned about the future of the company and as part of that wanted an estimate of the likely growth of the company.

In the offices there were several efforts, free-hand, wishes, hopes, guesses, what the marketing/selling people thought, etc., and none of those efforts seemed to be objective or with a foundation or rationality.

We knew the current revenue. We could make an okay estimate of revenue when all the airplanes were full. So, the problem was essentially to interpolate over time between those two numbers.

For the interpolation, how might that go? That is, what, day by day, would be driving the growth? So, notice that each day current customers would be shipping packages, and customers to be would be receiving packages and, thus, learning about FedEx and becoming customers. That is, each day the growth would be directly proportional to (1) the number of current customers creating publicity and (2) the number of customers to be receiving that publicity.

So, for some math, let t be time in days, y(t) the revenue on day t, t = 0 for the present day, and b the revenue when all the planes were full. Then for some constant of proportionality k, we have

     y'(t) = k y(t) (b - y(t))

where y'(t) = dy/dt the calculus first derivative of y(t) with respect to t.

A little calculus yields the solution.

     y(t) = y(0) b exp(bkt) /
            ( y(0)( exp(bkt) - 1) + b))

Seeing how the growth goes for several values of k, pick one that seems reasonable. Draw the graph and leave it for the BoD.

That was a Friday, and the BoD meeting started at 8 AM the next day, Saturday.

First thing at the meeting, two crucial BoD members asked how the graph was drawn. For several hours, no one had an answer. The two members gave up on FedEx, got plane tickets back to Texas, returned to their rented rooms, packed, and as a last chance returned to the BoD meeting. FedEx was about to die.

I did all the work for the graph, the idea, calculus, arithmetic (HP calculator), but didn't know about the BoD meeting. Someone guessed that I did know about the graph, and I got a call and came to the meeting. The two crucial BoD members were grim, standing in the hallway with their bags packed, and their airline tickets in their shirt pockets.

I reproduced a few points on the graph, and FedEx was saved.

So, some math saved a business.

Interesting, but I still think most problems like that are solvable via Excel. Put some formulas in some cells, tweak some variables until you find a way to maximize something. Possibly use graphs or pivot tables or other advanced features to help if needed. Once you’ve figured out the solution, then you build a pretty graph for the BoD proving it. Make sure to keep the spreadsheet around as evidence.

Sure, for some applications of calculus can use just discrete steps. That is, instead of the calculus dy/dt just use something like (y)dt.

Then, for the arithmetic, some code can be short and, compared with cells in a spreadsheet, easier and with more control over the time steps, e.g., in Rexx with cf for customer fraction:

     Say '        ==== Growth ===='
     Say ' '
     Say '                Customer'
     Say '     Year       Fraction'

     max_years = 5
     steps_per_year = 10 * 365
     cf = 1 * ( 1 / 100 )
     year = 1
     k = 1 * ( 1 / 2000 )
     Do Forever
       Do i = 1 To steps_per_year
         cf = cf + k * cf * ( 1 - cf )
       End
       Say Format(year,9) Format(100*cf,10,2) || '%'
       If year = max_years Then Leave
       year = year + 1
     End

yielding

        ==== Growth ====

                Customer
     Year       Fraction
        1          5.89%
        2         27.97%
        3         70.66%
        4         93.73%
        5         98.93%

So, get a 'lazy S curve'. I've since learned that the curve has a name, the 'logistic curve'. And, right, can also consider that curve for other cases of growth, e.g., for a first, rough estimate, COVID.

Adjust some of the constants in the program and can get more output, say, for each month, day, etc. The code above uses 10 steps per day.

For more, someone could use the calculus solution and compare.

In a sense, for the FedEx problem and the assumptions about what was driving the growth, the calculus solution is a smooth version of the somewhat more appropriate discrete time version.

But when I did the calculation at FedEx, my best source of arithmetic was an HP calculator in which case the calculus solution was a lot easier.

Of course, this FedEx calculation was just one example and there are many others.

My view from 10,000 feet up is that in business, at times some math can be an advantage if not the work of a steady job.

If some math is an advantage, then that advantage tends to go to the owners of the business. If a mathematician wants to get paid for some math they have in mind, maybe they should start a business and be the owner.

Above gave the calculus solution in algebra and also values from discrete arithmetic with (10)(365) steps per year.

For the arithmetic for the calculus solution, in Rexx,

     y.0 = ( 1 / 100 )
     b = 1
     k = ( 1 / 2000 )

     Do t = 1 To 5
       t1 = t * (10 * 365 )
       e1 = RxCalcExp( b * k * t1, 16 )
       y.t = ( y.0 * e1 ) /  ( y.0 * ( e1 - 1 ) + b )
       Say Format(t,9) Format(100*y.t,6,2) || '%'
     End

Table below has the values from both the calculus and the discrete versions:

         ==== Growth ====

             Customer Fraction
     Year   Calculus   Discrete
        1      5.90%      5.89%
        2     27.99%     27.97%
        3     70.68%     70.66%
        4     93.73%     93.73%
        5     98.93%     98.93%

Lesson: Sometimes in growth problems with a calculus solution, a discrete version can give close results.