On 4/24/12, Igor Stasenko <[email protected]> wrote:
> On 24 April 2012 12:50, H. Hirzel <[email protected]> wrote:
>> On 4/24/12, Sven Van Caekenberghe <[email protected]> wrote:
>>>
>>> On 24 Apr 2012, at 11:10, Stéphane Ducasse wrote:
>>>
>>>>>> And yet again I point to Tirade :)
>>>>>>
>>>>>> http://goran.krampe.se/blog/Squeak/Tirade.rdoc
>>>>>> http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
>>>>>> http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
>>>>>>
>>>>>> Especially Tirade2 above shows a bit about size (4 classes, 500 loc)
>>>>>> speed and portability. Tirade is basically a parser for Smalltalk
>>>>>> messages that only are allowed to use literals as arguments (although
>>>>>> arbitrarily nested literals).
>>>>>>
>>>>>> Which is exactly what Stef describes + a bit more. :)
>>>>>
>>>>> Yeah, I remember reading that a long time ago. It is indeed a cool
>>>>> idea,
>>>>> Göran. Reminds me of the Erlang related UBF
>>>>> (http://www.sics.se/~joe/ubf/site/home.html).
>>>>>
>>>>> I think the JSON choise is not bad: it is simple and universally
>>>>> accepted.
>>>>
>>>> But you can express **EXACTLY** the same with
>>>>      #(
>>>>
>>>>
>>>>              )
>>>>
>>>> So what is the point?
>>>>
>>>> Stef
>>>
>>> Yes, you are right, they are technically mostly equivalent. (JSON has
>>> simpler primitive types, clear escapes, lists/arrays and
>>> maps/dictionaries).
>>>
>>> But the point is, there are so many formats out there, and everybody
>>> likes
>>> to make there own.
>>>
>>> If you pick JSON, the discussion ends. It is an RFC standard.
>>
>
> If you pick smalltalk , it is ansi standard.. so.. what the point?
>
>> +1

There is already a documentation of the format. No additional work needed.

>>
>>> If you pick something that looks suspiciously like some (for most people)
>>> weird programming language you will get discussions, always.
>>>
>>> Dale said so: it is a pragmatic choice.
>>
>> +1
>>
>>> Now, given the fact that the domain here is Smalltalk anyway, there is
>>> something to say for using a Smalltalk based representation.
>>>
>>> But then you need to write a clear spec and a non-compiler based parser.
>>>
>>> With the JSON meta data, you could envision other non-Smalltalk tools
>>> using
>>> it more easily.
>>
>> +1
>
> this is killer argument ;)
>
> can you name just one which can be useful in this context???
> what tools, except written in smalltalk and used by smalltalkers you
> are expecting to use
> with smalltalk source code stored in source code repositories?

JavaScript  :-)  in connection with Amber. And couchDB.


>
> Sorry, the only valid and understandable argument here to me, is that
> it is purely pragmatic choice :)

And as Dale writes. It is already implemented in different dialects of
Smalltalk.

Thank you for asking

Hannes

> --
> Best regards,
> Igor Stasenko.
>
>

Reply via email to