beauty contest
If you had to pick between red, green or blue below, which would you? No matter if you actually get these snippets, just pick The One. Because, for the love of God, I can’t…
- Comment
- Reblog
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Absynth Mind 
My order, from best to badst would be: green red blue.
PS I would insert ‘;’ after every declaration… but that is probably besides the point.
And that indeed, would be the choice of a programmer 🙂
In the Green example certainly, a
;would not go amiss. Red tries to move away from looking like a programming language and in this case getting rid of a typical programming construct and relying on just an EOL instead makes (somewhat) sense, I guess. Of course, I’m still using curly braces… 🙂How about this notation?
An Author has a name and email. It owns many Posts.
A Post has a title (text) and text. It owns many Comments.
A Comment has an author (text) and text.
It would build on a few conventions, but I think it could work? 🙂
Of the three, I like to type Red best in a text editor, but otherwise I like Blue best.
Oh boy, do I like this notation! And I think I could get this to work even with the relatively straightforward tooling I’m using right now.
I love the use of ‘it’ to continue the scope so I can get rid of those pesky curly braces. And of course,
ownsis so much better thanembeds(really should have caught that one myself :oops:). Certainly will experiment with this notation!I do intent to back up these notations with full-on code completion BTW. So when confined to their respective environments, there should not be any difference in typing comfort between Red, Green, or Blue.
It is tempting to make a programming/specification language close to our natural language. But in my opinion it has serious disadvantages. The first (small) examples look neat but when examples become real life extensive specifications the neatness evaporates quickly. The result is not easily readable as natural language anymore, at the same time the meaning of all the words is not easily deduced anymore because a natural language brings a lot of fuzz with it.
I had my first encounter in this area with AppleScript years ago (http://en.wikipedia.org/wiki/AppleScript). My first reaction was “Oh boy, this is nice”. But when I started using it, I typed in lots of sentences that looked very sensible to me but were erroneous or interpreted completely (or worse, a subtle) different by the engine.
Natural languages have the property of being ambiguous, human listeners can deal with this ambiguity easily. Sometimes they even correct erroneous expressions on the fly because the context indicates an interpretation. Furthermore natural languages mostly allow to express one thing in many ways, again humans can easily figure out the meaning that is most logical and filter out what parts are redundant. When you give a user a language that looks like a natural language they will be surprised that they are not understood when they say what they mean the way they usually say things. But the engine you build will not always be prepared to understand each and every way a certain statement can be made. The result is that the user will have to find out what way he should specify what he means in a natural language that lacks the power that his own natural language has.
The user will end up with an extra step in his head: first he has to turn a vague idea into an exact specification, then he has to express this in a natural-like language with its own quirks. It is much easier to have a language that is as close as possible to the exact specification that he derived in the first step.
In my opinion this is the green or red example above or equivalent, not the one from Mats above.
and do i love beauty contests…. but this is an easy one….
green -> Tawny Roberts
red ->Gina Lynn
blue->ugly crack whore, uuhhh I mean Divine Brown
Gina Lynn is adorable but Tawny Roberts is the bomb…. anyone caught interfering with Divine Brown must be shot
Well, how can I argue with this? I thought I disliked Green for being a geeky aberration, but with the Tawny Roberts connection… I dunno, it doesn’t look that bad then I guess 🙂
If I’m informed well, she has a crush on geeks 😉
Hard to say which I like best. I like Mats’ suggestion. I Smalltalk it would probably look something like (it has been nearly 20 years since I did Smalltalk so it will not be correct syntax):
Author has: name and: email owns: (many Posts)
Post has: title and: text owns: (Comments many)
The things I don’t like are the difference between primitive types and types (string and Text), the “as” construct as it smells like type casting (and looks like VB), the curly brackets since you’re probably not aiming to woo the mass of the java/c++ community based on syntactic similarities. Most importantly are the phrases one uses to indicate the type of dependencies. From your examples I got the impression the relationship between Author and Posts is a different one than between Posts and Comments. Mats interpreted them as the same (maybe for the sake of simplicity of his suggested syntax). Finding the few options you want to support and then the terms to go with them (very hard probably) seems like more important than exactly which format the layout takes. Maybe a powerpoint like syntax
an Author consists of
* a Name
* an optional Email
and is related to
* Posts [here the plural should make “many” or something similar redundant]
A Post consist of
* a Text named Title [maybe “known as”]
* a Text
* optional Comments
and is related to
* an Author
A Comment consists of
* a String named author
* a Text
and is related to
* a Post
The related to needs maybe one or more cousins depending on how much you need to read into them. The back reference is not specified in place but can be inferred.
sorry for the late response, hope it helps and is not too late.