Java vs. K: a screencast
cs.nyu.edu
K is a proprietary APL-influenced array programming language. A simple 36-line Java program becomes a one-liner in K.
cs.nyu.edu
def birthday(people=23): import random days = 365 sample_size = 1000 return reduce(lambda x, y : x + y, (len(s) != len(set(s)) for s in (map(lambda x: random.choice(range(x)), (days, )*people) for i in range(sample_size))))
I am sure someone can beat it ;) let me know http://www.3kwa.com/Logbook/20070708
How do I get the code to indent properly?
(two empty lines, then one space in front of every code line)
(constructs fewer inner lists, otherwise changes are completely cosmetic)
First things first, his java skills are rusty. Here's how a real java programmer would write this. Does the exact same thing as his final java sample; it's just less than half the size:
import java.util.HashSet;
import java.util.Random;
import java.util.Set;
public class BDays {
public static void main(String[] args) {
int people = Integer.parseInt(args[0]);
int days = 365;
int sampleSize = 1000;
int total = 0;
Random random = new Random();
for ( int k = 0 ; k < sampleSize ; k++ ) {
Set<Integer> s = new HashSet<Integer>();
for ( int i = 0 ; i < people ; i++ ) s.add(random.nextInt(days));
if ( s.size() < people ) total++;
}
System.out.println(total);
}
}
thirdly: To optimize this code, you could stop generating birthdays the moment there's an overlap. Doing this in the K example is more complicated than the java example, in java you'd change the line 's.add(Random.nextInt(days))' to:
if ( !s.add(Random.nextInt(days)) ) break;
Between the cartoon swearing I actually like the java code better.
Java could certainly use more functional stuff and there are legitimate arguments to be made for adding something to your toolbox (I suggest Scala; compiles to JVM so you can mix and match java and scala at will). However, these trivial examples invariably have archaic java compared to state of the art $OTHER_LANGUAGE. These straw man comparisons are thus pointless exercises as no actual java programmer would ever be convinced by this kind of thing. They'd just blame to horrible quality of the java example.
(def bdays (people)
(count [no (iso _ (dedup _))] (n-of 1000 (n-of people (rand 365)))))
Complaining about the code appearance is like Java/C++ people who complain about the parentheses in Lisp.
Trivial examples are all you can fit in a screencast. You have to be respectful of people's time. If, e.g., you show Java people the code for the Scala compiler, when it was being bootstrapped in Java, and the > 2x LOC reduction when they were able to rewrite it in Scala to make the language self-hosting, Java programmers still wouldn't care, even though that's an example where the code bases are > 10K LOC.
I'm not complaining about code appearance. My code is completely different from his code; I use the same principles as the stuff he uses in K - create a UNIQUE set and check if the size of the unique set is smaller.
Trivial examples have a fundamental failure in that programming in general doesn't scale up without side effects. It's like special effects: If you try to run a scene by creating miniatures, certain effects, such as wind blowing across water, and speed, do not remain the same. You need to tweak stuff endlessly to make it 'look right' and even then there are practical issues.
I get that screencasts can't very well delve into a 3-man-year project. This does not mean that because the issue cannot be represented in a screencast, that it doesn't exist.
Take static typing for example. For trivial-to-small code samples, static typing is completely useless cruft. In LARGE (man-month or 3 with multiple developers), it's definitely useful. This is somewhat hard to explain in a screencast.
I've gone toe to toe with Slava Pestov of Factor recently regarding a JSON parser and a basic non-blocking I/O webserver, both from scratch, and factor code was smaller than java code by a factor of 90%. In other words, where I had 10k LOC, he had 9k LOC. That's a virtual wash in my book, and nothing like the usual numbers claimed.
It also depends on programming style. I find this perfectly acceptable java:
someContainer.add(title = new Label("Title Goes Here"));
whereas most java programmers would rip this up into two lines. This goes into the meaning of a 'line of code'. A massive perl one-liner clearly is much more heavy than something like "a = 5". Almost all java vs. other code contests I've seen, the relative weight of each java line is on average way less. Just because a language likes to use a lot of punctuation doesn't mean it's inferior.
I'm not apologizing for java - in fact there are tons of changes I'd like to see. I'm just saying that trivial examples and pointless comparisons (LOC comparisons without any form of context or attempt to normalize vs. statement complexity) aren't convincing.