This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-15
Channels
- # babashka (41)
- # beginners (47)
- # calva (7)
- # cider (5)
- # cljsrn (2)
- # clojure (38)
- # clojure-europe (74)
- # clojure-nl (2)
- # clojure-spec (1)
- # clojure-uk (38)
- # clojurescript (42)
- # component (30)
- # core-async (2)
- # cryogen (6)
- # cursive (47)
- # datahike (7)
- # datomic (18)
- # defnpodcast (1)
- # fulcro (17)
- # graalvm (8)
- # graphql (4)
- # helix (5)
- # honeysql (5)
- # introduce-yourself (1)
- # jobs (5)
- # jobs-discuss (4)
- # malli (20)
- # meander (4)
- # mental-health (1)
- # off-topic (41)
- # pathom (18)
- # podcasts-discuss (2)
- # re-frame (20)
- # react (1)
- # reagent (22)
- # reitit (2)
- # releases (2)
- # remote-jobs (1)
- # reveal (2)
- # sci (10)
- # shadow-cljs (42)
- # sql (20)
- # tools-deps (7)
- # vim (2)
- # xtdb (51)
Hi, folks, there’s a comment that Rich Hickey makes in his talk https://youtu.be/MCZ3YgeEUPg?t=2550 which I don’t understand. He’s using the metaphor of musical instrument design for language design. At 43:40 he calls our attention to the fact that “these things (i.e. old synthesizers) had a machine interface first…and then they put a human interface (i.e. knobs) on it…Imagine if someone had built something without any machine interfaces, but primarily with human interfaces…” and he gives SQL and Unix as examples. What does he mean by this? How do SQL and Unix have “human interfaces” but no “machine interfaces”?
The way I take that is SQL is essentially a string you send over the wire, and this has a number of implications.
SQL was meant to be written directly by an human; but if you want to programmatically construct a SQL statement from something else, you will realize that is not exactly that easy.
You will inevitably end up with some terrible string concatenations, making sure you put a comma in the right place, or make sure the HAVING
clause comes after the WHERE
. And that’s one of the reasons ORMs were born.
Imagine instead a “sql” that would not be a gigantic string, but instead a series of data structures; a new where clause would not be some weird string concatenation, but just a new element pushed into a vector or something like that (Datalog? ). When you have that as a base (instead of strings) then constructing a human interface (the SQL we have now or any other DSL that pleases you) is way way easier.
In UNIX you have the shell which was invented with human interaction, but ended used as a scripting language. SQL afaik was also intended to be used for ad-hoc queries, hence the natural language-like syntax (select something from database where …)
since the design focused on the UI first it ended up being inferior (proof being the tons of different shells, management tools, configuration management and interpreted languages for UNIX) and ORMs for SQL
In principle, what could a “machine interface” for Unix look like, generally? Having a hard time imagining it.
I would imagine something like Ansible, K8s or Nix
@eric.auld Think about all the commands you have in Unix, such as cat, tail
; can you programmatically use them, or are you forced to throw sh commands from your software (which is just wrong?)
Wouldn’t it be great if all the commands you have on unix would also be available as standard unix api?
The Human Interface would be a byproduct of the good underlying API, and not the only way to use the unix command itself. Am I making sense?
I’m still learning programming, but I think I understand what you mean. There don’t exist the analog of “system calls” you can make from, say, Python into the *nix OS to do things like cat
. Instead you have to instruct the system to run a shell script to do those things, which is a wasted layer. Is that right?
Not only is a wasted layer, but it’s brittle. Managing error is hard and most of the time unsuccessful
The only reliable information you can get is the return code (0, -1). Any other detail is left at the mercy of the standard output string that you need to read, parse, hope that it does not change and break everything.
The way I take that is SQL is essentially a string you send over the wire, and this has a number of implications.
SQL was meant to be written directly by an human; but if you want to programmatically construct a SQL statement from something else, you will realize that is not exactly that easy.
You will inevitably end up with some terrible string concatenations, making sure you put a comma in the right place, or make sure the HAVING
clause comes after the WHERE
. And that’s one of the reasons ORMs were born.
Imagine instead a “sql” that would not be a gigantic string, but instead a series of data structures; a new where clause would not be some weird string concatenation, but just a new element pushed into a vector or something like that (Datalog? ). When you have that as a base (instead of strings) then constructing a human interface (the SQL we have now or any other DSL that pleases you) is way way easier.
Or also, think about the fact that SQL Statements would be data structures, a software could easily analyze them be like “I think I’m gonna send this modified query to the database server, and I’ll do this additional filter here on the application server directly because I know better how to do that”
By “data” you mean something more like a vector and less like a raw, bloated string?
I think in the Clojure community we often say “data” (since that is what Rich Hickey says), but what we really mean is structured data.
And in Clojure terms that structured data is a composition of the built-in data literals rather than some DSL contained in a string of bytes.
@eric.auld Think about all the commands you have in Unix, such as cat, tail
; can you programmatically use them, or are you forced to throw sh commands from your software (which is just wrong?)
Wouldn’t it be great if all the commands you have on unix would also be available as standard unix api?
The Human Interface would be a byproduct of the good underlying API, and not the only way to use the unix command itself. Am I making sense?
> Imagine instead a “sql” that would not be a gigantic string, but instead a series of data structures; a new where clause would not be some weird string concatenation, but just a new element pushed into a vector or something like that (Datalog? ). -- @vincenz.chianese I haven't worked with Datalog before, but this description is exactly why I've come to love HoneySQL's approach: it retains the expressiveness of vanilla SQL (mostly), while actually applying the structure from Structured Query Language. That last part is why we generally use ORMs over SQL: so we know the SQL is correct. HoneySQL might not guarantee correct SQL (especially when mixing in raw SQL bits), but for 95+% of your queries, it will. On top of that it's easier to manipulate the structure of the SQL by using normal, built-in data structure operations. TL;DR: I ❤️ HoneySQL for the reason you described above 😝
The two examples you gave ("comma in the right place", and "`HAVING` clause comes after the WHERE
") are, for example, completely solved by HoneySQL
I am not familiar with the specific library you’re mentioned but I took a quick look and that gets the point, yes 🙂
We love the composability of HoneySQL at work: we can pass a “query” (data structure) into a function and it can easily add new columns to be selected and a new join clause and additional where clauses and pass back that updated “query” (data structure).
i recently had to make a 5 table union all query, and being able to introspect the individual queries, gather all the columns, and backfill the missing columns (selecting null) into the other queries greatly simplified the whole thing
One more satisfied user of HoneySQL here too 🙂. I even hacked some "ad-hoc queries" over a chatbot for people to make queries, and because it's all data structures, I was also able to make joins automatically!
The only reliable information you can get is the return code (0, -1). Any other detail is left at the mercy of the standard output string that you need to read, parse, hope that it does not change and break everything.
I have seen many workspaces slow down... very little traffic... It could be the problem for many. The app is not working.
Run it in a web browser?
thanks @seancorfield I found the link hidden behind the popup... to open the browser... I miss this way of using the app
today I learned there is a language called Tabloid, and it is hilarious:
DISCOVER HOW TO fibonacci WITH a, b, n
RUMOR HAS IT
WHAT IF n SMALLER THAN 1
SHOCKING DEVELOPMENT b
LIES! RUMOR HAS IT
YOU WON'T WANT TO MISS b
SHOCKING DEVELOPMENT
fibonacci OF b, a PLUS b, n MINUS 1
END OF STORY
END OF STORY
EXPERTS CLAIM limit TO BE 10
YOU WON'T WANT TO MISS 'First 10 Fibonacci numbers'
EXPERTS CLAIM nothing TO BE fibonacci OF 0, 1, limit
PLEASE LIKE AND SUBSCRIBE
Looks very similar to Arnold C https://github.com/lhartikk/ArnoldC
Reminds me of https://codewithrockstar.com/