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.
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.
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...
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)
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.
> 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.
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.
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.