Comment by mamcx
7 years ago
> you believe SQL is insufficient
I don't believe it, is insufficient, as a fact.
Compare
let city = SELECT name
let filter = WHERE id = @id
to
let city = map name
let filter = filter(id = id)
let query = city |> filter
this is to show that SQL, despite being a programming language, can't compose well.
The syntax is not the point.
You can build full apps in forth or lisp (as examples of even more minimal Langs than SQL) but now consider the idea of build a full app in SQL. Without other language making the rest of their limitations.
You’re asking me to consider the idea of building a full app in SQL. I would ask you - why?
SQL wasn’t designed nor ever meant to be able to write a full app. You’re expecting it to do something it wasn’t designed to do. Because it is a programming language doesn’t necessarily mean it ought to be able to solve any kind of problem.
I personally don’t think SQL is all that great, for various reasons (lack of standardization with various dialects and their own gaps or abilities).
> I would ask you - why?
Optimally, you'll want to build your full app in a single language, frontend, data queries, everything. That eliminates every problematic interface where you have to re-encode values, verify types and other invariants, connect different runtimes, abstract foreign behavior, etc. (Somehow the JS developers talking about isoiconicity only cite code reuse... And the Lisp ones focus on metaprograming.)
We have a variety of good application languages, so it's a safe bet that one can create a not horrible one; we also have a few standards for IPC and some very safe literature on how to integrate them with a language. Foreign interfaces are always iffy, but it's also settle how to create a not horrible one. The most risky part is data querying, so it makes sense to start with a proven implementation here.
> You’re asking me to consider the idea of building a full app in SQL. I would ask you - why?
"We Can Do Better Than SQL"
And the fact that some can't imagine to build a full app in SQL (not as is TODAY but as could BE) is sad.
I live in that world before. With the base/foxpro familia's you can totally build a full app with a database language, in fact, easier than with python.
---
The point here is that obviously, SQL is not mean for programming, but do one-off queries here and there. But it not exist a reason to aim higher.
BTW, part of the laments of the creators of the relational model is that SQL have ruined, like COBOL, the mind of millions of developers.
>”And the fact that some can’t imagine to build a full app in SQL is sad”
You are outlining some general purpose programming language that allows querying, information retrieval, maybe declaratively or functionally or using objects? I don’t know - you provide no other details.
How expressive would this language be? What abstractions would it provide out of the box? How expressive is it? Your examples allow some code reuse via naming/aliasing specific clauses... is that it?
Specifically what apps would it allow someone to build? And what trade offs result from those decisions? Is it better suited for mathematical operations or data science vs building general enterprise applications? There’s a difference. Is it interpreted like SQL? Would it need to be compiled?
You’re doing a lot of handwaving, and when pressed for details, you respond with a thinly veiled insult - the problem is with the reader or me specifically for not being able to read you mind. We should take you at face value without question.
Good luck with that attitude in your career.
1 reply →