

Java vs. K: a screencast - henning
http://www.cs.nyu.edu/~michaels/screencasts/Java_vs_K/Java_vs_K.html
K is a proprietary APL-influenced array programming language. A simple 36-line Java program becomes a one-liner in K.
======
3KWA
This is the most obscure piece of Python code I could write to do the same
thing :

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?

~~~
Jd
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))))

(two empty lines, then one space in front of every code line)

~~~
dhouston
def birthday(people=23): from random import randint as rand; return
sum([len(set([rand(1,365) for x in range(people)])) != people for i in
range(1000)])

(constructs fewer inner lists, otherwise changes are completely cosmetic)

~~~
3KWA
ah yes indeed much better! I tried to follow the K structure too much, but
your code is too readable :D

------
rzwitserloot
Unfair comparison.

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);
    	}
     }
    
    

secondly: Regarding the manual import writing and compiling stuff, well, I'll
try and put this nicely: That's masochistic. Download jEdit, Eclipse,
NetBeans, IDEA, or any other java programming environment other than 'notepad'
and 'cmd', and you no longer need to compile anything, just hit F11 or CMD+R
or similar, and you'll see your results right away. Note that in the above
sample, the first 5 and last 2 lines were generated completely automatically
by my IDE (Eclipse), so in practice we're talking about just 5 lines of actual
code. The rest is generated or setup stuff.

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;
    

that's all you need to do. In K, by using the _draw shortcut (A method that
exists in a number of mathemetically oriented add-on libraries, by the way)
you lose that flexibility.

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.

~~~
henning
I like Scala a lot (I spend most of my spare time coding in it), I know he
used bad Java style, and I still think Java got pwned.

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.

~~~
rzwitserloot
??

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.

------
kcl
<http://kx.com/a/k/readme.txt>

