Stupid question, slightly off-topic but why every web app needs to be ready to scale and serve a billion users? I don't mean this in the pessimistic way of "be real you are not next Facebook". My question is what do you think all that money is for, one you are asking for from VCs? Facebook was not ready for a million users in the beginning. You need old stable and safe tech that will not crash your demo or provide horrible user experience to important first-generation users. Every time alpha breaks catastrophically is because somebody ambitiously tried something not well documented or understood. People understand MySQL. why would you add extra time and cost to your original first budget? to prove what? I understand it makes job less "job" and more fun but is it truly worth experimenting while you are fighting for survival? If I put all the dead startups in my cv it would be 50 pages long
We Can Do Better Than SQL
261–270 of 466 posts
Re: We Can Do Better Than SQL
#262Good idea actually! One day one of these efforts will succeed.
As a front-end programmer for 7 years I feel I have a fine understanding about how a relational database and its queries can support my usecase. I understand the basics well enough to advice the backenders. Anyway, SQL or any Object oriented abstraction on top of it gives me migraine.
Let the critics criticize. Most people mistake pragmatism (SQL) for sound solutions anyway. I do feel there is also a need for graphical editors. Yet it is much better to build a graphical editor that compiles to something with comprehensible syntax.
Good luck
Re: We Can Do Better Than SQL
#263Honestly I think SQL is pretty easy. I love it. I can teach the basics to a new person in minutes. You know what we could do better at? Crappy explains from database engines. Crappy rate limiting capabilities. Poor feedback on keep cache pipelines fed during scans. Poor feedback on column size effects on reading stripes from disk and size alignments between the filesystem and database.
Your brain must work different to mine. SQL is by far the hardest tool I use. I’ve used all the main languages from asm up to js for real work and nothing breaks my brain like SQL. I use it daily in a business that is heavy on SPs and while I get by and am improving the jump from inner joins and selects to CTEs and the other wizardry is massive. I want to be better at SQL but so many problems I hit up against and thi…
The problem for SQL is (apart from horrible syntax that makes any query re-factoring tedious) that databases are very strict structures, that through their rigidity make some operations very fast, but some operations impossible (to perform in this fast manner).
When you are crafting good SQL query (crafting is the right word as each non-trivial SQL query is a little puzzle that may take you few days to solve because of the constraints) you need to stay within the bounds of the this fast db world.
Whenever you are forced to open a cursor or use CTE for recursion or even have a full table scan you already left the fast land and landed in the world that all general purpose language inhibit, where you have to iterate and recurse and everything takes ages. And in that land any other language beats SQL because any other language has the syntax designed to make things easier in this world while SQL has the syntax that's just good enough for the fast world where operations are highly restricted and when it ventures into the slow world it's just a horrible mess.
Re: We Can Do Better Than SQL
#264Earlier quoted context omitted.
> So, to summarize: I never actually heard a compelling general theory of good syntax. I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of thi…
The commonality you are referring to sounds like Chomsky's concept of Universal Grammar [1]. The object.method(args) "won" because it is a low barrier to entry from English to Programming indeed, but as you become more and more experienced and you shake off the imperative way of thinking in favour of declarative thinking functional languages becomes more expressive than imperative languages. They become better at man…
I was thinking on a more basic level than UG; just the presence of linguistic universals [1]. I agree that functional languages are in a certain way more expressive than imperative ones, but that seems mostly orthogonal to the syntax of the language.
I’m thinking about basic stuff like improper nouns, denoting a clause’s role by inflection or adposition instead of word order, and having a clearly defined spoken representation- none of this is specific to which abstract structures the language is describing.
Re: We Can Do Better Than SQL
#265I agree with the criticism of SQL here but to make yet another SQL but not SQL is not the way forward imo I hope the writer reads http://www.learndatalogtoday.org/ In Clojure there are multiple databases that you can query by API, SQL and datalog
If by datalog with Clojure, you mean Cognitech's Datomic, yeah it's pretty friggin' cool. Really really liked it (well, the concept)... Until we started working out licensing and realized we were going down a rabbit hole of unclear future costs. They upped the cost on us in the middle of working on a project, their tooling was awful, they deprecated the REST API (which was a selling point for us they pushed) halfway through our efforts. We lost a lot of time, money (we paid for consulting work which was useless), and our product was delayed significantly. I know Stu will probably read this, but it's just the way it is. We also threw away Clojure then and never looked back.
Doh, that's not what this discussion was about. It's an old wound that won't heal. :-)
Re: We Can Do Better Than SQL
#266Earlier quoted context omitted.
I was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TABLE" implementation detail doesn't need to factor into it.
> If SQL is based on tables, what about a QL based on relations only. Try Sparql.
Came looking for the reference, and found it - but there are fewer and fewer mentions of SPARQL with each of these HN discussions. I think people just think "oh some semantic web crap" and move on without realising how powerful RDF etc. really can be when used as simple tools, without the 90s hype of changing the world with linked data.
At least the old ideas are resurging in the form of Neo4j (essentially a triplestore) and Cypher (essentially SPARQL).
Re: We Can Do Better Than SQL
#267Earlier quoted context omitted.
In this case it was a left join sometable on sometable.someuid = isnull(someothertable.someuid, somethirdtable.someuid) I guess that is such an uncommon case that it tripped up the optimizer completely. Also: Thanks for writing "polymorphic associations". Not knowing that probably is why I struggled to find any info on it. Edit: Both tables were actually the same one, just retrieved via different joins, so different…
> Thanks for writing "polymorphic associations". Not knowing that probably is why I struggled to find any info on it. We might have had a similar experience with this. The first time I stumbled across this problem though I was specifically trying to figure out “what is the relational way to implement polymorphism”, so I pretty much lucked into the a rather productive series of google searches.
It wasn't strictly polymorphism, but the term you wrote led me to a article[1] where it mentioned "alternative parent". This alone instantly made the problem more understandable for me.
[1]http://duhallowgreygeek.com/polymorphic-association-bad-sql-...
Re: We Can Do Better Than SQL
#268Earlier quoted context omitted.
That's circular reasoning though. Why do you want your data to be in a relational database? Particularly if you're not actually using its features (I don't think I've ever seen a web application that actually got any value out of database-level transactions, for example). A different kind of datastore could offer you better performance and easier querying.
I love SQL for making it possible to almost trivially enforce most business rules. Such as: You can only use one of the in another table specified values in this field.
It makes some things simple and insanely fast at runtime, at the cost of making other things impossible or if possible horribly awkward and just as slow as in any other programming language.
Re: We Can Do Better Than SQL
#269Earlier quoted context omitted.
You mean like an ORM?
ORMs I've worked with usually expect you to write the complex queries/joins yourself using a series of functions e.g. orm.select(table1).join(table2).on(keys).where(cond).group(by).having(cond).order(by). It's just SQL with extra steps. An ORM that understands db schema, indices, and automatically decides where to use outer join or subqueries based on what would be most efficient given the specific schema would be fa…
At minimum some ORMs let you reorder things which makes SQL 50% better.
Smarter ORMs do what you want. Linq is magical.
Re: We Can Do Better Than SQL
#270Earlier quoted context omitted.
> all the syntax decided on before there was a community that really understood what good syntax is Here you got me thinking: do we even understand that now? There was quite a bit of contemplating about of semantics, data types and different kinds of abstractions in the programming languages for the last couple of generations already, but the general consensus about the syntax is that "nice syntax is nice, but it isn…
> So, to summarize: I never actually heard a compelling general theory of good syntax. I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of thi…
It's not that simple, D has UFCS (Uniform Function Call Syntax), which makes object.method(args) and method(object, args) equivalent calls.
Also there's a non-language related advantage of dot notation. Type the name of the object, press dot and IDE will show you what things you can do with that object. You don't have that with other notations.