4 ms·

I wrote a SOAP webservice -- not because I'm insane, but because our business relies on data sent to us. We could certainly tell everyone that they'll need to

by jtheory 12y ago

I wrote a SOAP webservice -- not because I'm insane, but because our business relies on data sent to us. We could certainly tell everyone that they'll need to write code to send us the data we need to be of use to them. Or we could look at the installed systems that hold their data, and see what built-in support those systems have for external integrations. And so: we quickly added a simple SOAP endpoint. About serializing -- I'm potentially missing your point, but "The source code of the language is already in its serialzed form" doesn't seem to make sense. Who serializes source code? Values in data structures need to be transmitted, normally (sometimes in the form of source code -- e.g., JSON) -- homoiconic languages are interesting for other reasons, but not serialization.

nickbauman 12y ago
So you're consuming data of an existing (legacy) SOAP service? Or complying with exisiting clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service. If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that before down-voting what I have to say about it.
- coldtea 12y ago
  >If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. Yeah. If only that language and "not needing serialization" code format didn't have 200 other problems, like NONE of the major services accepting it, lack of tooling, a sorry state of an ecosystem, difficulty of finding programmers and/or jobs, etc...
  - jerven 12y ago
    And the simple fact that taking code provided by a remote service and just using it as is just handing the keys of your server over. LISP homoicity is nice but its a bad, bad idea to accept LISP code over the network from any client. Documented dataformats that are not executable are enough of a security risk that sending an executable around is not a great idea. (Should have been attached to grandparent, as I agree with parent)
    - nickbauman 12y ago
      You really don't get it do you. An s-expression doesn't have to be evaled to be read. I just keep getting downvoted here. It's like offering a machine gun to a caveman and getting clubbed to death with it.
      - coldtea 12y ago
        >An s-expression doesn't have to be evaled to be read. Yeah, so you get a serialization format that's the same as your code. Big deal. And you have to live with your code having the same look as a serialization format. Even McCarthy wanted to give Lisp a proper syntax. >It's like offering a machine gun to a caveman and getting clubbed to death with it. More like it's coming to Paul Graham's house to tell him all about this new wonderful Lisp thing thing you've discovered. I mean, this is HN, what makes you think those that answered you don't already know and/or use Lisp and its homoiconicity properties? Being used as a serialization format is perhaps the least interesting and useful property of Lisp code.
        jtheory 12y ago
        Okay, this suggests I'm not confused; there's just no argument given. > Yeah, so you get a serialization format that's the same as your code. Big deal. There's no reason this would be automatically a "good thing" -- a serialization format that is also valid source code -- it's just a thing. It's good to have a clean path from data structure to serialized data and back again; but if the obvious way to re-create the data structure (exec the code) has a huge security flaw built into it, that's no longer a clean path. Human-readable serialized formats are nice; but guidelines on "readable" for a data structure vs. "readable" for full-power source code are not the same -- and "compact" is also strongly good for serialization formats, but not nearly so important for source code.
        nickbauman 12y ago
        > Yeah, so you get a serialization format that's the same as your code. Big deal. Oh, but it is! Making a massive compute grid can be done with just a few lines of code if your language is homoiconic. If you have to come up with a protocol and a data transfer format, well you have some work to do then.
- jtheory 12y ago
  > So you're consuming data of an existing (legacy) SOAP service? Or complying with existing clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service. Neither; we're accommodating large, complex systems that only have a few options for "send selected data elsewhere". "Web services" (meaning SOAP) tends to be on that list, plus often other options that are completely unacceptable like "FTP". > If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that before down-voting what I have to say about it. I'm someone who responded to you; I didn't downvote anything. I can try again: I use serialization all the time, to convert in-memory data structures into something I can send over a connection (or to disk, etc.), then to reconstitute them back into in-memory data structures on the other end. So I don't yet see how homoiconic languages play into serialization.

by jtheory 12y ago

nickbauman 12y ago

So you're consuming data of an existing (legacy) SOAP service? Or complying with exisiting clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service. If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that before down-voting what I have to say about it.

coldtea 12y ago
>If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. Yeah. If only that language and "not needing serialization" code format didn't have 200 other problems, like NONE of the major services accepting it, lack of tooling, a sorry state of an ecosystem, difficulty of finding programmers and/or jobs, etc...
- jerven 12y ago
  And the simple fact that taking code provided by a remote service and just using it as is just handing the keys of your server over. LISP homoicity is nice but its a bad, bad idea to accept LISP code over the network from any client. Documented dataformats that are not executable are enough of a security risk that sending an executable around is not a great idea. (Should have been attached to grandparent, as I agree with parent)
  - nickbauman 12y ago
    You really don't get it do you. An s-expression doesn't have to be evaled to be read. I just keep getting downvoted here. It's like offering a machine gun to a caveman and getting clubbed to death with it.
    - coldtea 12y ago
      >An s-expression doesn't have to be evaled to be read. Yeah, so you get a serialization format that's the same as your code. Big deal. And you have to live with your code having the same look as a serialization format. Even McCarthy wanted to give Lisp a proper syntax. >It's like offering a machine gun to a caveman and getting clubbed to death with it. More like it's coming to Paul Graham's house to tell him all about this new wonderful Lisp thing thing you've discovered. I mean, this is HN, what makes you think those that answered you don't already know and/or use Lisp and its homoiconicity properties? Being used as a serialization format is perhaps the least interesting and useful property of Lisp code.
      - jtheory 12y ago
        Okay, this suggests I'm not confused; there's just no argument given. > Yeah, so you get a serialization format that's the same as your code. Big deal. There's no reason this would be automatically a "good thing" -- a serialization format that is also valid source code -- it's just a thing. It's good to have a clean path from data structure to serialized data and back again; but if the obvious way to re-create the data structure (exec the code) has a huge security flaw built into it, that's no longer a clean path. Human-readable serialized formats are nice; but guidelines on "readable" for a data structure vs. "readable" for full-power source code are not the same -- and "compact" is also strongly good for serialization formats, but not nearly so important for source code.
      - nickbauman 12y ago
        > Yeah, so you get a serialization format that's the same as your code. Big deal. Oh, but it is! Making a massive compute grid can be done with just a few lines of code if your language is homoiconic. If you have to come up with a protocol and a data transfer format, well you have some work to do then.
jtheory 12y ago
> So you're consuming data of an existing (legacy) SOAP service? Or complying with existing clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service. Neither; we're accommodating large, complex systems that only have a few options for "send selected data elsewhere". "Web services" (meaning SOAP) tends to be on that list, plus often other options that are completely unacceptable like "FTP". > If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that before down-voting what I have to say about it. I'm someone who responded to you; I didn't downvote anything. I can try again: I use serialization all the time, to convert in-memory data structures into something I can send over a connection (or to disk, etc.), then to reconstitute them back into in-memory data structures on the other end. So I don't yet see how homoiconic languages play into serialization.