2 ms·
I really like the idea of developing a modern Access alternative, but why are you trying to create a new language? Aren't QBE and SQL sufficient? Why not somet
by taffer 7y ago
I really like the idea of developing a modern Access alternative, but why are you trying to create a new language? Aren't QBE and SQL sufficient?
Why not something that is like a cloud SaaS version of Access, but can be extended with some procedures and later used as a GraphQL backend like Hasura?
- codeulike 7y agoSalesforce is (among other things) basically a cloud SaaS version of Access. And people pay a lot of money for it. See my other comment https://news.ycombinator.com/item?id=21403393 https://news.ycombinator.com/item?id=21403393
- taffer 7y agoTrue, when I think about what I've seen, what people are building with Access and what people are building with Salesforce, there's a lot of overlap.
- mamcx 7y agoSQL/GraphQL are query languages. Good for that, but not for fully develop an app. FoxPro have his own language that allow mix SQL and imperative constructs: https://en.wikipedia.org/wiki/Visual_FoxPro https://en.wikipedia.org/wiki/Visual_FoxPro This mean: * You code login in foxpro * And the stored procedures * And the forms * And the reports * And the script glues * .... "Just" adding SQL/GraphQL to a RDBMS is absolutely not enough. Both are too limited. For example: - Can you build a btree with SQL? No - Work with the terminal? No - Make a visual grid? No - etc Only query and maybe crud.