On 20 October 2012 03:17, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:09:18 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:26, Dale Henrichs <dhenrich@vmware.com> wrote: | > Ah, | > | > So you are asking whether I think this: | > | > {1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}} | > | > is more readable than this: | > | > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 | > #(#Array 1 2 3))) | > | > My answer is that I find the JSON style more readable. | > | > With JSON, I can look a sequence from the middle of the character | > sequence and recognize the syntactic elements: | > | > 'foo': bar', 3 | > | > as a key/value pair (foo/bar) and that 3 is probably a key ... | > while the following sequence is not recognizable as anything: | > | > 'foo' 'bar' 3 | > | > is it 3 elements in an array? is foo, bar or 3 a key? To get it | > right I have to count the key value pairs from the beginning of | > the dictionary, something that only a machine can do or a human | > presented with a small list of elements to look at. | > | > This readability is important when looking at larger structures | > that may span a screen full of items in a text editor. | > | > The {} delimiting a dictionary allows me to recognize the following | > sequence: | > | > 3]} | > | > as the end of an array and a dictionary whereas the following | > sequence could mean anything in the literal Smalltalk array world: | > | > 3)) | > | > I can use a text editor to find the terminator for a dictionary or | > an array. With a smalltalk literal array it isn't possible..again | > the human must resort to careful counting. | > | > I wouldn't think that I would need to point out that the | > #Dictionary and #Array also introduce quite a bit of visual | > noise... and the JSON sequence is about half as long as the | > literal array sequence and still quite readable... | > | > So, yes I find the JSON format more readable than Igor's suggested | > format. | > | Frankly i do not see any difference between those two.
Igor, It depends upon what you are looking for and what is important to you ... I have explained the syntax elements that make JSON more readable for me.
Do you acknowledge that the syntax elements {}, [], :, and ,, provide additional syntactic structure that is lacking in the literal array syntax?
Smalltalk is also famous for lacking curly-brace syntax {} for statement grouping and ';' as statement terminating symbol and of course missing '.' between receiver and 'member method call'. What is your point? :) Why space is worse that comma? If you can provide arguments for using commas, next thing which i will ask from you to apply same argumentation for using 'object.foo' instead of 'object foo' for message sends... and if you can argument that, then i will also ask argument writing 'object.foo()', as well, and then finally 'object.foo();' :) and then we will be very happy (assuming that i will accept your argumentation ;) Btw, one of the reasons why i hate Python is that they using white space for statement grouping. But that is slightly different: treating an arbitrary number of 'white space' characters as single white space is not the same as counting each white-space character to determine statement nesting. That's quite evil , and that's why i live with smalltalk not python.
You may not agree that they are important, but can you at least acknowledge that they might provide useful information that is absent in the pure literal array syntax?
If you cannot acknowledge this little bit, then I'm not sure that it is worth discussing any further...
You right, i cannot. But as i mentioned before , nothing prevents you from using punctuation to separate values (and throw them away after smalltalk parser did its job). And as you said then it is nothing better than STON: if STON syntax can be modified to be parsed using smalltalk parser (no matter what weird literal you will get as result), i think that would be just advantageous.
| I think, if you ask an outsider who don't knows neither JS nor | Smalltalk syntax (to have unbiased opinion), | i bet he will not be able to easily interpret any of them.
Of course .... and my _opinion_ is that the additional syntactic elements in JSON are very useful hints that makes it easier to interpret what you are looking at...when you know what you are looking at.
Hints only for those who know JSON :) But not for those who know smalltalk. Yesterday everyone was using XML, today its JSON.. tomorrow it will be another over-hyped format. Why we can't have own? Ah, yes we have it - STON :)
| | Apart of that , is of course, being able to tell the class of object | literal. | Try to express that with JSON: | | #(IdentityDictionary 1 #(#OrderedCollection 1 2 3) 'foo' 'bar' 3 | #(WeakKeyDictionary 1 2 3 #(#Set 1 2 3)))
Sven implemented STON (which is actually the format that I prefer ... have you looked at STON?) and has inserted the class names into the format ... STON retains the [], : and {} elements to improve readability.
I looked at it briefly.. Sure thing i didn't read details. So, if you say STON can deal with that, then cool :)
| | maybe you don't need that. But i think there's plenty of others who | may find it very useful.
Like I said I prefer STON because it does include class information, you should really take a look:)
Yes. As well as many other interesting stuff which happens around.
| | I didn't wanted to turn this discussion into anti-JSON war. So sorry | for that. | (But you know, sometimes it is hard to stop fighting ;)
I am shocked that a little bit of JSON on disk has created such waves ... If STON had existed at the time I started I would have used that, although I suspect the same animosity would be directed towards STON, because it is a superset of JSON...
If you want to understand why it created such waves, try to do: 'port install cairo' on your mac, which brings half of the unix distribution as dependencies including xml parser, python and god knows what else, just to build this library. While later i discovered that you can build it without having python installed neither xml parser, but just 3 other C libraries which are direct dependencies of it. This is where such way of thinking leads to, when you put extra dependencies without attempting to find a way how to stay minimalist. To me, i find it very compelling to find good arguments, why you needing JSON parser in a project which deals with smalltalk and only smalltalk and nothing else, in same way as why C library needs python in order to be built (while C compiler is sufficient for that).
| | So, as i already demonstrated, this format, while maybe not best for | humans having clear advantages comparing to have NOTHING at all: | | - you can use it for expressing literals in methods (and even easily | extend compiler to pre-evaluate them at compile time)
I don't put STON into literals ... in the smalltalk image, the STON is generated from the objects and written to disk where it may be read/editted by developers using a standard text editor, with emphasis on _may_.
| - you can easily extend it to use for many different classes, | without | breaking anything.
STON shares this feature...
| - and finally, it is fairly small, and simple, because of code reuse | (smalltalk parser)
and we're back to where we started from 9 months ago ... GemStone does not have an accessible Smalltalk parser, and the number one requirement for this format is easy portability between dialects (7 smalltalk dialects are involved here...the JSON parser from Seaside with only 27 methods was easily ported to those dialects lacking their own JSON parser ... STON isn't quite as portable, but because of it's additional features will be worth the effort porting)...
Dale, i know that. Now, don't let me get started to enumerate numerous reasons why it is good to have parser implemented in language side (apart from being used for purposes we currently talking about). In your place, i would see it as a good opportunity for implementing new cross-dialect smalltalk parser, given that the one which we have in Pharo is not that good as we want it to be, and Pharoers (don't know how Squeakers), would be really happy seeing progress in that area, and would only welcome that. Having parser which can work across dialects is very good thing (tm), isn't?
Dale
-- Best regards, Igor Stasenko.