Re: [Pharo-project] Yet another Notation format: Object literals

Oct. 20, 2012

      ----- Original Message -----
| From: "Igor Stasenko" <siguctua@gmail.com>
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 4:46:47 PM
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
| 
| On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> wrote:
| > Igor,
| >
| > It's not clear that I need to be part of this discussion.
| >
| > If you want to invent a new serialization format, then go for it.
| >
| > I did chime in with my opinion that your suggested format was not
| > very readable. You happen to disagree with me.
| >
| 
| Yes, i disagree. Tell me what is not readable in this:
| 
|  #( Dictionary
| 
|    yellow  (Color 1 1 0)
|    blue  (Color 0 0 1)
|    red (Color 1 0 0)
| 
| ) fromObjectLiteral.

Please read my earlier description of why I think JSON is more readable as you haven't addressed the main points with this format...
| 
| this is human-written object literal. It took me very little effort
| to
| express correctly the data structure i need to get out of it, with
| little chance of doing some syntax mistake.
| For smalltalker, like me, i find this expression is natural and
| straightforward to read.

I understand that you can read this format, but I still maintain that in the end the lack of a few syntactic elements make this format ambiguous to read/write for the human...You need to full expression to make sense of it though.

It is not the fact that the expression works evaluates correctly but the fact that the interpretation of all of the elements relies upon knowledge of the underlying implementation ... for example, I am not familiar with the Color class so:

  (Color 1 1 0)

tells me nothing when I read it ... are those rgb values cyn or some other encoding the lack of the names causes me problems .... if the shape of the Color class changes, then this particular expression will be useless ... in the wild classes tend to change shape over time ...

| 
| And do not discount the environment where people working in: it is
| smalltalk.
| So, even if i not understand what is inside, i can always select that
| piece of code and press Cmd-I
| to inspect it (or explore it) and then i will see everything very
| clear :)

except when you sitting in a text editor or when you are in a Smalltalk dialect that doesn't have the class you are looking at or the shape of the class in that dialect is different ...

| 
| As well, as you can do reverse: you can craft a complex thingy, and
| then send #asObjectLiteral
| and after some prettyfying, you can make it clearly readable. (not
| mentioning that you can of course
| pretty-print it automatically).
| 
| While with JSON, if you evaluate json code in JS, you will get same
| JSON as response..
| which is cool, because of invariant, but won't make it easier to
| understand by any bit.
| 
| > That's fine.
| >
| > I also mentioned that YAML is a standard format that is designed to
| > be very readable by humans while still being parsable by a
| > machine. You told me that I was missing the point.
| >
| yes, because my intent was to use smalltalk syntax (so that we
| reusing
| existing codebase, and keep uniformity, which is also important).
| 
| > That's fine.
| >
| > You told me that the point is that you can encode arbitrary objects
| > in literal arrays and that this representation is optimizable by
| > the compiler.
| >
| 
| right, but that's a side effect (which i discovered discussing here
| btw). I didn't had that in mind nor putting that as a requirement of
| design. Still, admit, that this side effect is quite nice :)
| 
| > That's nice, but it is still not readable by humans (in my opinion)
| > and I don't want to involve the compiler ... I don't want to
| > execute code directly from the repository - I want to insert a
| > parser, so that we have control over the code that gets executed.
| 
| i know. But my implementation does not evaluating any new code: it
| just parses the input and transforms it into objects. It doesn't
| installs new behavior to system. If you don't trust me, you're free
| to
| debug the code to see what it does.
| 
| 
| >
| > Obviously the goals that you have for this notation do not match up
| > with the requirements that I have.
| >
| 
| my goal is just one: use smalltalk syntax to express data.
| If you take smalltalker who knows smalltalk and nothing else, i think
| he will learn to read that notation much faster comparing to learning
| JSON/STON/YAML first.
| Because it is already smalltalk and needs just a slight shift in POV
| to see through braces.
| That's the main point.

Regarding this goal...you realize that you are entering the territory where you have a solution (using smalltalk syntax to express data) and are looking for a problem to solve.

The problem I had (9 months ago, which was solved by using JSON/STON) is still not solved by your solution... you don't fail in terms of functionality, but in the simple fact that I value the extra syntax that STON/JSON provides that differentiates between arrays and dictionaries ...

You create a literal dictionary/object syntax for Smalltalk and you might have a convert. 

Igor, you are asking form my _opinion_ and I' giving you my _opinion_, and I will repeat it again, I think there needs to be a syntactic difference between dictionary and array ... only to make it possible for the poor human to make sense of things.... the lack of the syntactic demarcation is the weakness here.

I really think that your current variant is way to dependent upon magical ordering...multiple platforms do not represent common classes the same way and positional parameters don't allow for shape changes over time ... way to rigid and structured...

Dale