Learning Without Implementation
Learning Without ImplementationI've tossed around a few draft languages of sorts on this wiki, and sometimes get criticized for not having or making an implementation to test in order to comment and evaluate. While I agree that an implementation is certainly a nice thing to have, saying it's a requirement before general critiques are made is off-base in my opinion. One can learn and comment on a language without an implementation. Mathematicians have been doing it for centuries even because (practical) computers didn't exist. I learned dBASE almost entirely from a book (Microsoft Press) before I ever touched it on a computer, sat down and was able to almost instantly produce useful code when the computer came. (This was back in the days where desktop computers were not so readily available and software was relatively more expensive.) Thus, requiring an implementation is balderdash. --top
Eh? How do you reconcile this with your own RaceTheDamnedCar?
You can still race a virtual car. It's not as good as the real thing, and probably not useful for "proving a point" in an open-and-shut way, but can still provide experience and lessons.
How do you distinguish racing a virtual car from HandWaving? Sounds to me like you're back-pedalling as fast as you can go.
And if it's not clear, ask questions.
That is reasonable with novel languages. It's not reasonable with conventional ones that offer nothing new. In that case, use an existing implemented language.
It's your opinion that it "offers nothing new". It does things Rel cannot do, your grand pet language, such as dynamic column selection. You are focusing on superficial syntax issues.
It might well do things Rel cannot do. So can LISP, Haskell, Pascal, and almost any assembly language. That is irrelevant. What does it do that ExBase -- which it semantically resembles so closely as to differ only (insignificantly) in syntax -- doesn't do? Fundamentally and crucially, what about those things helps clarify human thinking to such a degree that it's worth being a tool for reasoning without being implemented?
StrawMan. Assembler can also do anything Rel can. And it's not like ExBase. It's more limited than ExBase (because it's a query language, not an app language) and (currently) lacks cursor-centric operations. It's also not imperative (although can be emulated as imperative). It's closer to SQL than ExBase.
So... Even less capable than ExBase and equivalent to SQL sans cursors? Fine. Fundamentally and crucially, what about it helps clarify human thinking to such a degree that it's worth being a tool for reasoning without being implemented?
It better fits my WetWare than SQL, and may also fit others'. I would find such a language easier to read and manage than SQL. And it off-loads many "operations" to table processing rather than dedicated syntax, which keeps it simpler instead of key-word and API proliferation found in SQL and Rel, and more "meta" because table operations can optionally generate the "parameters" of processing, such as column lists and criteria. It practices EatYourOwnDogFood. -t
These are all excellent reasons to implement it, but none of your justifications have anything to do with using it as a tool for reasoning; they're all pragmatic programming (and primarily syntax) issues.
The primary purpose of software is to document and present ideas in a precise-as-possible way to other humans. Thus, "reasoning". It shares a lot in common with legal documents.
Be careful how you use the term "reason". I use it in a very particular fashion related to consideration of theory. Mathematical notations make it easier for us to reason about mathematical theories or abstractions. What theories or abstractions do SmeQl give us the ability to reason about? What, for example, can we understand more deeply about the RelationalModel by writing and considering SmeQl code that we can't by writing, say, SQL?
An example of how it might help analysis: SmeQl doesn't need to explicitly state a column list if using a subset of columns. Thus, it can be more compact than other query languages, with the actual columns being an abstract idea, if that info is not necessary to convey an idea. Abstraction: eliminating/hiding the non-essential.
This is again a reason to implement it, not a reason to not implement it.
What? They are not mutually exclusive.
Again, reasoning is about abstractions, not mere programming. What theories or abstractions do SmeQl give us the ability to reason about? What, for example, can we understand more deeply about the RelationalModel by writing and considering SmeQl code that we can't by writing, say, SQL?
Reasoning about the relational model itself is not the intent. Reasoning about domain-specific solutions are more along the lines of what I had in mind.
But didn't you write in ExperimentalQueryLanguageDiscussion that SmeQl is "closer to RelationalAlgebra, but pre-fix instead of in-fix. 'Prefix RelationalAlgebra' is a far more accurate description [...]"?
Another example, in cases where SQL doesn't readily offer duplication factoring, one can first draft up a solution in SmeQl to study the more ideal factored form, and then de-factor it into production SQL. If you rid duplication, you can sometimes spot things that the duplication obscures or spreads apart (ThickBreadSmell).
Why use SmeQl for this instead of SQL's WITH clause?
It's more compact for such, and the x = y(...) style syntax makes it easier to follow all the virtual table references, at least to my WetWare. There's a reason standard math notation doesn't use key-word syntax. (I have suggested a kind of key-word syntax for sample languages that integrate better with SQL, but that's mostly to gel with SQL itself because it's the de-facto query standard. Given a choice, I'd make SmeQl the standard. But, that's probably not realistic, so it may be a smaller hurdle to EmbraceSql.) Related: WorkBackwardFromPseudoCode.
This made me think of a young boy who took lessons to play a piano and had to do his at home practice on a cardboard keyboard which made no sound. When he returned the next week to his instructional class, he was able to play the exercises which had been practiced only via the soundless cardboard piano. This illustrates that sometimes a scheme or process can be carried out without the implementing devices. WardCunningham and others with ExtremeProgramming utilize Patterns, Stories and CrcCards to layout designs and assign responsibilities for coding which does not exist. One might also mention such devices as Flowcharts and Pseudocode. -- DonaldNoyes.20111026
Still, I bet he took quicker to the real piano than he would have without such practice. Thus, it wasn't necessarily a useless technique, just sub-optimal. Further, programming is not about motor skills, and thus is a weak analogy. -t
So if he took quicker to the real piano this means someone would take quicker to the real SmeQl too. Personally I prefer learning from model/paper languages because they are far more interesting than boring existing implementations with no new novelties or innovations. For example if I was going to add Tables to Cee instead of just the dumb structs it has now, I would much prefer learning/creating a table Cee language on paper first, to prove whether it was worthwhile, and to have fun enjoying the language before implementing. Since it's a novelty not implemented by any implementation, that novelty is much quicker to get using on paper first than to implement it physically. If structs are just "DumbTables" or "DumbRows?" in Cee, then it should be fairly easy to add tables to a prototype cee language (RelationalCee). After creating this language on paper one might realize that although cee with tables is better than regular Cee, it would be better to ditch Cee as a language, since it doesn't have strings - it only has pointers to chars. On the other hand you might find the opposite: it isn't worth ditching Cee and it is worth implementing "RelationalCee" with Strings added too. A lot can be found out on paper before implementing.
Exactly: different notations often help one look at a problem from different perspectives. Sure, sometimes it's MentalMasturbation, but sometimes you need some MentalMasturbation to stretch your mind a bit during the early planning stages. Similarly, Lisp is a great teaching and experimenting tool even if it's not very practical on most actual shop floors because it can help you examine or find higher abstractions for consideration. If you then have to dumb down (de-abstract) the design too much for your target language/tool-stack, then that's a yellow flag to consider other tools or angles for the project. Sometimes you have to walk around in Ideal-Land for a while to know when, where, why, and how much reality is falling short in order to shore it up a bit. -t
CategoryLearning? [EditHint: category suggestions welcome] how about CategoryEducation
EditText of this page
(last edited August 8, 2013)
or FindPage with title or text search