One Night With Clojure Makes a Scala Guy Humble | Agile Zone

    class Artist:
        def __init__(self, name):
            self.name = name
    
        def __str__(self):
            return self.name

I'm not even arguing that Python's dynamically typed approach is necessarily better overall than Java, but if you're going to evaluate the two in terms of verbosity then you really have to compare idiomatic code in both languages. Whereas if you continue writing Java in Python, of course you'll only see a 2x improvement.

More than a decade ago I worked on a compiler written in C++ and did an exercise to see what the savings would be to implement it in Python. IIRC it was something like 80%. There were huge savings in the size of static data structures. A lot was due to the fact that Python lent itself to being an ad hoc DSL.

Try spending some time on 4Clojure. For a while I was routinely solving problems in half a dozen lines or more, only to find that other people had done them in one line.

Also of course, Paul Graham has said a few things about this, such as: http://www.paulgraham.com/avg.html

Yeah, some of the improvement could be because of better understanding of the problem.

I assume this means you are running the uncompiled version as the script? For Scala at least that is fairly uncommon in situations outside development.

(Note that to do the same in Java is very hard - you'd have to write a custom compile & execute script - and then it would perform similarly to the Scala/Clojure app anyway).

Also, I think it is great to see the startup time for a Java application praised. How things have changed!

Can't find it anymore, sadly, but I remember a guy had done some profiling (on leiningen maybe?) and it turns out more than 90% of the startup time was loading core.clj, not the JVM startup when only took a small fraction of the total.

(now part of clojure.core being so slow goes back to the JVM: a lot of resources are expended JITing stuff which — for leiningen — will just be thrown out. Hence the quite frequent recommendation to run the JVM in -client mode if possible. The -server VM also allocates way more memory on startup)

Java (real code - this is a mild example, imagine this 8 indents deep):

  return users.verifyAccess(userId, oldPassword).flatMap(
    new Callable1<Promise<DataObject>, UserProfile>() {
      @Override
      public Promise<DataObject> call(UserProfile profile) {
        return replyProfile(profile.setPassword(newPassword));
     }
  });

  for {
    profile <- users.verifyAccess(userId, oldPassword)
  } replyProfile(profile.setPassword(newPassword))

Oh man, I wish we started with Scala (or wrote everything sync)... My conclusion from all of this was that Java makes certain abstractions impractical from a readability standpoint.

A great example of imperative vs. less-imperative is looping vs mapping.

Mapping in Python:

    foo = map(function, list)

   for(int i = 0; i < list.size(); i++)
   {
        foo[i] = function(list[i];
   }

However, LoC is a truly bad metric (other measures are, imo, just as bad), and doesn't really capture what I just said at all. What LoC does capture (as I said above) is volume - the extrinsic complexity of the solution. If you can hone your code so that it simply expresses the intrinsic complexity of the solution, your LoC will decrease to that point. And language helps a great deal.

Your point is really well made though: for industrial use you have to have a head to head of expert teams over a reasonable time frame for a reasonably sized system, in reasonably comparable conditions. And yeah, that's the big joke in SW engineering research. It's never really been done and published in any meaningful way. Some companies did do work in that area in the '80s, as I recall - but they didn't publish meaningful datasets as far as my reading shows. Most SW engineering research in this area is very much "small problems" and "students in a class".