4 ms·
SQL is complete but ugly: everything is expressible, but nothing is reusable; simple ideas are complex to express; the language is verbose and lacks smart defau
by aivarsk 5y ago
SQL is complete but ugly: everything is expressible, but nothing is reusable; simple ideas are complex to express; the language is verbose and lacks smart defaults.
It begs for examples of the ugly/verbose/complex SQL and the beautiful/succinct/simple Malloy. Looking at the samples folder did no work for me.
- jakey_bakey 5y agoAgreed. I'm not a big fan but the Coffescript docs do this beautifully. https://coffeescript.org/#overview https://coffeescript.org/#overview
- shepardrtc 5y agoHaving worked in a Coffeescript codebase for the past couple of years, its horrible to read. It just turns into a giant mess with multiple layers of nesting and everything just kind of mushed together. Coffeescript looks fun to play with, but having it in a large production codebase is an exercise in confusion and frustration. It lets people be clever with their code. Don't be clever.
- Oddskar 5y agoI think they were talking about the comparison, not Coffeescript itself.
- ako 5y agoIndeed, and i'm not buying the "nothing is reusable". Sql views are in my opinion the opposite, as they make every query reusable.
- cerved 5y agothe downside with views it's that they are persistent so you can't reuse it only in the context of one connection you can use CTEs but only with one query
- zimpenfish 5y ago> persistent so you can't reuse it only in the context of one connection Don't e.g. Postgres temporary views cover this case? "Temporary views are automatically dropped at the end of the current session."
- cerved 5y ago¯\_(ツ)_/¯ I expect vendor specific stuff called something along the lines of temporary view would do this, yes
- gwd 5y agoUnlike functions, views don't have arguments you can use to change the output. (Edited for clarity.)
- ako 5y agoYes they do, you can use them as the source for any sql query, so they have the exact same argument options as tables.
- kthejoker2 5y agoWithout speaking to the merits of Malloy Think of a sales orders table. Think of all the orders in there that should be considered "invalid" for some reason or another. It would be awesome to define some logic, one time, in one place, for "invalid orders" and then have end users be able to say "from invalid orders", "stores having no invalid orders", "customers with multiple invalid orders", "top 3 reasons orders are invalid" ... And of course "valid orders" might just be defined as "not invalid orders" Instead this is probably multiple views, CTEs, UDFs, and still some logic in the main query to handle NULLs or joins or whatnot. Even little things like hierarchies - I don't want to have separate sprocs for salesByCountry, salesByRegion. salesByState,and then an umbrella dynamic sproc to figure out which one to call. It's ironic because SQL is such a human friendly declarative language that it has such poor ability to create meaningful shorthand expressions. I've written SQL for nearly 30 years, I love it, but natural language transpilers have shown me some of its limits as an expressive tool.
- edmundsauto 5y agoThis is the use case for a metric store. https://blog.transform.co/history-of-the-metrics-store/ https://blog.transform.co/history-of-the-metrics-store/ It's a separate system, which has downsides. As an upside, by being a component of your system, the integrations with monitoring, alerting, quality checks, and dashboards is usually pretty easy.
- kthejoker2 5y agoYeah I don't believe in a separate metrics store (or feature store - and I sell one!) It should all be in one SQL-like DSL with a natural language transpiler on top.
- edmundsauto 5y agoCan you recommend any good implementations of the ideal state? I worry that SQL is too much to learn, but natural language is way too ambiguous to map to anything resembling logic. (The best we can do, for natural logic -> executable logic is legislative code... And the ambiguity there is famous.)