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