Also, JAX-B annotation can serialize and deserialize to JSON given the right provider. That's JSON, XML with POJO with the price of one. Good example of Java ecosystem: build on top of existing one / backward compatible / play nice with others.

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.

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.

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.

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.

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

(sort #(compare %1 %2) coll)

To reverse it

(sort #(compare %2 %1) coll)

Where coll is the collection you want to sort. Same caveat applies with:

(reverse coll)

Try as I might I can't get Clojure to bench slower than its comparative Java. I see no reason to program in Java anymore wherever possible.

coll.sort(comparing(identity(), Integer::compareTo));

Or:

coll.sort(reverseOrder())

Showing what tools and libraries are recommended at the moment and how some of them work together. In Javascript the ecosystem is growing almost exponentially which makes it impossible to keep up with everything. In Java and C# there is many old classes still in the libraries and around that most experienced developers avoid. And some trimmings of the ecosystem would probably be useful every 3-5 years or so.

Here's how I'd write this, lambdas or not:

public static List<Integer> sortDescending(List<Integer> ints) {

      ints.sort(new Comparator<Integer>() {
          @Override
          public int compare(Integer o1, Integer o2) {
              if (o1.equals(o2)) {
                return 0;
              } else if (o1 < o2) {
                return 1; 
              } else { 
                return -1;
              }
          }
      });

      return ints;
  }

      ints.sort((o1, o2) -> {
          if (o1.equals(o2)) {
            return 0;
          } else if (o1 < o2) {
            return 1; 
          } else { 
            return -1;
          }
      });

      ints.sort((o1, o2) -> {
          if (o1.equals(o2)) return 0;
          return (o1 < o2) ? 1 : -1;
      });

   @Override
   public int compareTo(Object arg0) {
       Country country=(Country) arg0;
       return (this.countryId < country.countryId ) ? -1:
              (this.countryId > country.countryId ) ? 1:0 ;

   }

But that's orthogonal to my point, which is that lambdas offer significant improvements to readability because they remove the irrelevant cruft and simplify the code.

it could also be accomplished with

    return -1 * o1.compareTo(o2);

    return o2.compareTo(o1);

( o1, o2) -> o2 - o1

No ternaries or else-ifs required. Swap o1 and o2 if you want ascending.

It will take more than a decade before we see any decent adoption of Java 8 in the industry.

You are still going to see piles and piles of getters/setters, Enums, your design patterns taken to far extreme. Writing such pointless ceremonial code is the bloodline of Java community.

Merely introducing a new version hardly changes anything.

Anecdote: I once saw a Perl shop that could have been the worst of Enterprise Java. They where the same because they where ENTERPRISE, they suffered in Perl in the same way the common office programmer suffers in Java.