4 ms·

JSON is another contestant in the generic data serialization space, which is doing better than sexp - possibly due to the ubiquity of javascript (free-riding th

by 11ren 18y ago

JSON is another contestant in the generic data serialization space, which is doing better than sexp - possibly due to the ubiquity of javascript (free-riding the web). Though, for this technology generation, the fight is over. I think there'll be another chance when SOA/web services are superseded; but there's still huge scope for improvement within their present architecture/ecosystem (e.g. REST vs. SOAP vs. ?). For programming languages, sexps are competing against all the other language syntaxes out there, not just XML. I agree that it seems odd that ant uses XML though... perhaps the extensibility of ant is easier with some kind of generic format (like XML/sexp/JSON)? yet other languages manage to be extensible via functions/classes/modules etc. Thank goodness no one uses JSON to encode a language (in the way that ant uses XML).

michaelneale 18y ago
I am thinking ant did it to get the parser and some kind of tools for free. Certainly no one really likes it as XML.
- mindslight 18y ago
  I don't know the ant specifics, but I'd surmise that one starts off thinking of a simple declarative format (we've got some targets, that depend on other targets, which is just a simple tree, and perhaps we can write various analysis tools later). Then of course as time goes on, it gets more general purpose language features (symbol bindings, conditionals, etc), and adopts an ever more procedural feel (especially in the case of a build system, which essentially all about mutating filesystem state). Since these features weren't designed from the start, you end up with rifts, such as between ant "attributes" and "properties", which don't really tax the ant gurus, just the casual users and newcomers. Seems that it would be easier to write a build system as an embedded DSL in a general purpose language to begin with, and when further analysis tools wanted to be written, make the necessary changes (meanwhile old build scripts run just fine using the old library). But then again, it's much easier to criticize with hindsight than to design a system that becomes popular.
  - michaelneale 18y ago
    >But then again, it's much easier to criticize with hindsight than to design a system that becomes popular. Indeed - ant came about when XML was popular for far more things then it should have been used for, and java wouldn't make a very good declarative build language (which is what ant was targeting).
- gruseom 18y ago
  I really think it's just that ant dates from the time when everyone was walking around with XML stars in their eyes.
  - michaelneale 18y ago
    That's possibly more likely.
gruseom 18y ago
Thank goodness no one uses JSON to encode a language (in the way that ant uses XML). Heh. Of course, they don't need to. As the French guy says in the Holy Grail, "we've already got one, it's very nice!"
- 11ren 18y ago
  If Javascript used JSON in the way I described, it would look something like this (view page source for original): { "function": { "signature": { "name": "byId", "args": ["id"] } "body": { "return": { "call": { "target": "document", "method": "getElementById", "args": ["id"] }}} }}
  - gruseom 18y ago
    Yeah, I know you meant that. The point is people don't do it because they don't have to. In XML, by contrast, your example has been written countless times. For a few years it was almost de rigeur. JS's notation for data and code may not be identical, but they're close enough to get things done (that's JS's Lisp heritage showing). Since XML was explicitly designed to prevent people from doing a bunch of things they needed, it's not surprising that what resulted were montrosities. I suspect that XML is a manifestation of the kind of people who like to lock things down and specify them up front, until they're so tied up in knots of their own making that they form a committee to design the same thing all over again. As you may guess, I'm of the opposite camp. Happily, I can work in my medium and leave them to theirs.
  - ynniv 18y ago
    Lets assume that an identifier array that starts with the word "function" is a function declaration, and has the additional place arguments name, argList, and body. Now we get something like this: [ "function", "byId", ["id"], [ "call", "document", "getElementById", ["id"] ] ]
    - 11ren 18y ago
      Yeah, I was thinking that. You're also omitting an explicit return, I would guess by assuming the value of the last statement (as an expression) is to be returned (this won't work in general, because Javascript allows multiple returns, like C or Java). It's closer to a lisp syntax, by using nested lists instead of structs/maps. I submit that it's against the spirit of JSON to be able to name the values, and then not use that ability. I think you're Greenspunning it ;-). Sure is shorter though. :-)

by 11ren 18y ago

michaelneale 18y ago

I am thinking ant did it to get the parser and some kind of tools for free. Certainly no one really likes it as XML.

mindslight 18y ago
I don't know the ant specifics, but I'd surmise that one starts off thinking of a simple declarative format (we've got some targets, that depend on other targets, which is just a simple tree, and perhaps we can write various analysis tools later). Then of course as time goes on, it gets more general purpose language features (symbol bindings, conditionals, etc), and adopts an ever more procedural feel (especially in the case of a build system, which essentially all about mutating filesystem state). Since these features weren't designed from the start, you end up with rifts, such as between ant "attributes" and "properties", which don't really tax the ant gurus, just the casual users and newcomers. Seems that it would be easier to write a build system as an embedded DSL in a general purpose language to begin with, and when further analysis tools wanted to be written, make the necessary changes (meanwhile old build scripts run just fine using the old library). But then again, it's much easier to criticize with hindsight than to design a system that becomes popular.
- michaelneale 18y ago
  >But then again, it's much easier to criticize with hindsight than to design a system that becomes popular. Indeed - ant came about when XML was popular for far more things then it should have been used for, and java wouldn't make a very good declarative build language (which is what ant was targeting).
gruseom 18y ago
I really think it's just that ant dates from the time when everyone was walking around with XML stars in their eyes.
- michaelneale 18y ago
  That's possibly more likely.

gruseom 18y ago

Thank goodness no one uses JSON to encode a language (in the way that ant uses XML). Heh. Of course, they don't need to. As the French guy says in the Holy Grail, "we've already got one, it's very nice!"

11ren 18y ago
If Javascript used JSON in the way I described, it would look something like this (view page source for original): { "function": { "signature": { "name": "byId", "args": ["id"] } "body": { "return": { "call": { "target": "document", "method": "getElementById", "args": ["id"] }}} }}
- gruseom 18y ago
  Yeah, I know you meant that. The point is people don't do it because they don't have to. In XML, by contrast, your example has been written countless times. For a few years it was almost de rigeur. JS's notation for data and code may not be identical, but they're close enough to get things done (that's JS's Lisp heritage showing). Since XML was explicitly designed to prevent people from doing a bunch of things they needed, it's not surprising that what resulted were montrosities. I suspect that XML is a manifestation of the kind of people who like to lock things down and specify them up front, until they're so tied up in knots of their own making that they form a committee to design the same thing all over again. As you may guess, I'm of the opposite camp. Happily, I can work in my medium and leave them to theirs.
- ynniv 18y ago
  Lets assume that an identifier array that starts with the word "function" is a function declaration, and has the additional place arguments name, argList, and body. Now we get something like this: [ "function", "byId", ["id"], [ "call", "document", "getElementById", ["id"] ] ]
  - 11ren 18y ago
    Yeah, I was thinking that. You're also omitting an explicit return, I would guess by assuming the value of the last statement (as an expression) is to be returned (this won't work in general, because Javascript allows multiple returns, like C or Java). It's closer to a lisp syntax, by using nested lists instead of structs/maps. I submit that it's against the spirit of JSON to be able to name the values, and then not use that ability. I think you're Greenspunning it ;-). Sure is shorter though. :-)