How Other Query Languages Address Sql Flaws Discussion
Continued discussion about HowOtherQueryLanguagesAddressSqlFlaws.
Moved due to size and threadiness:
Availability of Implementation
...
-
SmeQl: Imaginary. Is nowt but a gleam in Top's eye.
- Pro: Gives us time to fix any major flaws or shortcomings.
-
Con: Said time may be infinite.
- Like your nagging
- You love it. That's why you keep coming back for more.
- I'd like to point out that TutorialDee existed as an "imaginary" language for quite a time, yet served a purpose. -- top
- I don't claim SmeQl is without purpose. I claimed it is imaginary. There's a difference.
- It runs on biological CPU's, just not artificial ones yet :-) Why does one make it "imaginary" but not the other?
- An imaginary language is one without an implementation. It requires imagination to "run" the code because it won't run any other way.
- Brains ARE computers, not just very accurate/consistent ones.
- So? You appear to suggest SmeQl has validity as a language despite not existing. That is reasonable if SmeQl exists to illustrate significant concepts. TutorialDee, for example, pre-dated implementations in order to illustrate the RelationalModel and show what DateAndDarwen's abstract D specification could look like if implemented. What significant concept(s) does SmeQl illustrate?
-
See TqlDesignGoals. I'm sure you will disagree with the priorities it optimizes for, but I expected that.
- Further, Tutorial D served as a 'training language' for some time before it was implemented. Are you dismissing this period of time?
- Absolutely. Similarly, I will dismiss SmeQl as mere fantasy until it's executable.
- Let me get this clear. You are saying it was a bad idea for C. J. Date to use Tutorial D as a training language or syntax until it was machine executable? If so, is algebra also useless until students can actually "execute" it on an artifical machine? -t
- Are you claiming SmeQl is a teaching language, despite putting it here on a page of comparisons to other usable, executable languages? Are you claiming it represents a theoretical foundation so significant that it's on equal footing with algebra?
- Yes, in the sense it "illustrates concepts". Further, being a teaching tool does not preclude it from being a potential production notation either. It can be both. Pascal started out as a "teaching language", I would note.
- What concepts does it illustrate?
- See TqlDesignGoals.
- Those are language design goals, the things that presumably make it of value once implemented; they are not a description of the concepts that an unimplemented SmeQl illustrates.
- I disagree: they illustrate at least one approach to achieving them.
- You mean SmeQl syntax illustrates at least one approach for achieving SmeQl syntax? That's hardly a conceptual illustration.
- No. You misread something.
- What I mean is that your goals are primarily syntactic. Essentially, they are tweaks to what SQL already does rather than being conceptually distinct. A language that is strictly adherent to the RelationalModel is conceptually distinct from SQL. A language that allows column selections to be specified via a table is not.
- My main goal is indeed to improve "expressiveness" and less about achieving "purity", which I see best treated as an option, not dictated, in order to better fit the messy real world and existing databases. We keep coming back to this same disagreement and are not likely to settle it. You seem to downplay the importance of expressiveness. Few would want to use a "pure" relational assembler language (at least outside of SystemProgramming). - t
- If your goal is to improve "expressiveness", then I take back my point above that "I don't claim SmeQl is without purpose." I now claim it is mainly without purpose until it is implemented, because merely demonstrating improved expressiveness is meaningless without an implementation. This has nothing to do with "purity" or lack thereof, and everything to do with whether or not your imaginary language serves any purpose.
- Please elaborate on "demonstrating improved expressiveness is meaningless without an implementation". I'm sure most language designers drafted their language on paper and mentally executed examples and scenarios before hitting the keyboard. In fact, 'mathematical algorithms' existed only on paper and were quite useful WITHOUT the computer being invented yet. Most creators and users of math notation didn't even conceive of the existence of computers yet. Sure, it's nice to have a computer implementation, but lack of does not make a notation "useless". You protest too much. - t
- Mathematical algorithms and novel language designs are of value on paper because they illustrate something new. What is new in SmeQl?
- Hogwash. 100% novelty is not necessary to study a notation for usability/grokkability. In fact, it was foolish to start to implement Rel and related languages without first bouncing around the paper notation to wider parties. I've gotten very useful comments from others looking at the draft of SmeQl.
- Of course, 100% novelty is not necessary. What I'm asking about is any novelty. As for Rel and related languages, these have been bounced around to various parties in three editions of TheThirdManifesto, an article also entitled TheThirdManifesto dating back to 1995, Date's An Introduction to Database Systems text, and Date, Darwen, and Lorentzos's Temporal Data and the Relational Model book. At least. There are also various articles, dissertations, etc., based on this work. I'm sure you have received useful comments -- on SmeQl syntax itself. SmeQl, however, does not illustrate any new concepts or approaches. It merely demonstrates the concepts of SQL in a slightly different syntax from SQL. In terms of conceptual illustration, SQL will do.
- Sorry, I disagree. It appears you are more interested in purity than expressiveness and thus weigh such issues much heavier than expressiveness. That's fine, but your priorities are not the center of the universe. You've yet to prove that purity will save the world from asteroids, cure cancer, and rescue kittens from trees without any downsides. I haven't either, but at least I don't claim my personal priorities magically trump yours.
- And I disagree with "slightly different". It has standard and re-compos-able atoms where SQL doesn't (other than a mishmash of keywords). It's almost like 'Lisp versus COBOL'.
-
{It does? Where is this standard? And quit griping about people being "more interested in purity than expressiveness" when it isn't especially relevant. One can be pure AND expressive. Perhaps SmeQl is more expressive than SQL, but I'm not convinced that SmeQl is more expressive than RelProject's dialect of TutorialDee. (Appealing to priorities does not convince. It isn't as though the primary developer of SmeQl is a skilled LanguageDesigner, and real expressivity is a tricky snipe to catch even if one is trying.)}
- "Consistent" is perhaps a better word than "standard" in this context.
- Until we have an objective way to measure "expressiveness", I will present my approach and you yours, and we'll LetTheReaderDecide. I would like to point out PageAnchor prefix_vs_infix under TutorialDee as food for thought.
- {You're going after 'expressiveness' and you don't even know what it is? I'll let that stand for itself.}
- I didn't say I didn't know what is, only that I cannot quantify it thus far. And, if you do, then document it, quantify it, apply it, measure it, and then score it. Science, my friend, science. Otherwise, there's no objective way to say that approach X is more expressive than approach Y, despite bragging and personal attacks. Note that expressiveness often involves simplicity in building blocks, power (ability to do work), brevity (less code to do X), and intuitiveness. - t
- {I have no responsibility to document anything on your behalf, but I will posit that your understanding of 'expressivity' is fundamentally incorrect if you think it is a one-place word (see http://lesswrong.com/lw/ro/2place_and_1place_words/). Anyhow, it seems you are suggesting you do know what expressiveness is, albeit only in the same sense as 'pornography' or 'home' - you know it when you see it. That makes designing to achieve it quite difficult. And what the frell is 'intuitiveness'?}
- Again, I believe PsychologyMatters. Maybe expressiveness to your mind is not expressive to another. I have no problem with that being the case. I never claimed any universal truth. The purpose of this topic is to present and explore the many alternatives. In many cases there will be no magic formula to narrow down the "right" choice. YOU are the one implying a master truth, not me.
-
{Ah, the hand-wavy appeal to 'psychology', followed by a baseless accusation that your opposition is depending upon a 'universal' or 'master' truth. I applaud your skill with bullshit. Anyhow, is the purpose of this topic really to explore imaginary alternatives? Like SmeQl? If so, then why aren't there more imaginary alternatives listed? Or maybe this whole page is really a thin excuse to put TopMind's imaginary pet as the first of four alternatives?}
- I've put the list in alphabetical order.
- Again again, it's not any more imaginary than math notation before computers.
- {Oh? Math notation before computers was published in books, well formalized, well defined. Are you claiming your SmeQl notation is at a similar status, such that all that is left to do is implement it within computers? If so, point me. If not, then SmeQl is much more imaginary than mathematical notation.}
-
You are just biased against anything I touch. If other people want to create a candidate relational language to explore, I for one 'am all for it' because the community should bounce around ideas before wasting time implementing something before sufficient scrutiny has been applied to it. If that's not rational, then beat me with a sigma symbol. Below are typical steps to engineering something with lasting impact. You did step 5 first.
- 1. Brainstorm among stakeholders
- 2. Categorize and group options/choices
- 3. Discuss and evaluate the options/choices among the stakeholders
- 4. Vote (if applicable)
- 5. Implement
-
{That looks an awfully lot like a formula for DesignByCommittee. (And what a committee! of stakeholders rather than experts.)}
-
Not necessarily. There may be a final "decider", perhaps the implementer. But I think it is rational and reasonable to let multiple minds review the possibilities and selection reasoning before hitting the keyboard. If we are going to suggest SQL be replaced by something better, let's make sure we 'covered all the bases. For example, HughDarwen, an influencer of TutorialDee, has suggested that settling on infix notation was perhaps a mistake (or at least better for teaching than for production). It's a lot harder to fix it now. - t
- Infix vs prefix has been discussed on TheThirdManifesto forum; HughDarwen is an active participant. I don't recall him reiterating any regrets about infix, and there's been ample opportunity for redesign and no reluctance to doing so. Some portions of TutorialDee have changed dramatically over the three editions of TheThirdManifesto, and a forthcoming publication will make further changes. If anything, the consensus appears to be that infix vs prefix is essentially insignificant -- at best deserving consideration on an operator-by-operator basis and not much consideration at that.
- BTW, if we're "going to suggest SQL be replaced", the "suggestion" is going to be afforded all the attention it deserves, i.e., none, because we're nowt but a gaggle of WikiZens idly babbling around the virtual water cooler. If SQL is going to be replaced, it will be replaced by an implementation, not a discussion.
- Sometimes great things come from water-cooler talk. It's not like there's a single formula for progress. In my opinion it's good to bounce an idea around among many people before actually coding, if possible (even if you reject their suggestions). If you disagree with such, so be it. That's life.
-
Not necessarily. There may be a final "decider", perhaps the implementer. But I think it is rational and reasonable to let multiple minds review the possibilities and selection reasoning before hitting the keyboard. If we are going to suggest SQL be replaced by something better, let's make sure we 'covered all the bases. For example, HughDarwen, an influencer of TutorialDee, has suggested that settling on infix notation was perhaps a mistake (or at least better for teaching than for production). It's a lot harder to fix it now. - t
-
Indeed. Top, I think you've confused "design by committee" with "engineering something with lasting impact", neither of which have anything to do with actually creating something with lasting impact, which usually goes something like this:
- 1. Vision!
- 2. Implement vision.
- 3. Hard slogging, good promotion, and luck.
- 4. Profit! :) Or fail. :( No telling which 'til you get here...
- But I'm suggesting a decent compromise between CowboyDesign and DesignByCommittee. - t
- Why?
- They both suck in different ways. If you wish to continue this discussion, I'd suggest splitting this section off and putting it in something like DesignApproachDiscussion.
- Related: LearningWithoutImplementation