Joel Spolsky and Jeff Atwood have a podcast: Stack Overflow

[Brian]

I like how the Java Posse is more conversational in nature and Joel
Spolsky of (joelonsoftware.com) fame and Jeff Atwood
(www.codinghorror.com) have started a podcast called stack overflow.
The podcast is still working itself out, but the discussion about
learning C is like learning anatomy before going to med school was a
lot of fun. I think Joel on Software (in book or blog form) is
required reading and I love the stuff Jeff does at coding Horror. So
if your looking for more tech on your iPOD I would recommend this one
starting with Episode #3 (perhaps #2 as well).

-Brian

[Casper Bang]

Yeah StackOverflow is entertaining, between the wit of Joel and the
careful candidness of Jeff it has all it takes to become a success. Of
course I believe you should not only spend some time with C, but also
registry or stack based assembly to really get a feeling for what's
going on underneath, although I suspect the general Java crowd
(accustomed to the black magic of the JVM) feel otherwise.

/Casper

[Rick]

@Brian, I agree that Joel's writing is very good. Obviously he's on
"the other side" of the Java vs .Net debate, but apart from that lapse
on his part, he's very interesting. But who is Jeff and why would I
care what he is saying?

As for the usefulness of a deeper knowledge, I think what happens is
that from my exposure to computer science it doesn't necessarily make
me a better person, but it does stop me from doing certain kinds of
things (e.g. I wont write a bubble sort).

But, if I had to repeat certain kinds of things from my undergraduate
days in my day job, I might struggle. The specific example I've
thought of is that several times I've thought "hey, having a balanced
tree here would be cool, maybe I should sit down and write a 2/3-Tree
implementation". And I could probably bang out the inserting and
splitting nodes and pushing nodes up to the root of the tree bit just
from memory, but it would probably take me a day or two to reconstruct
from first principles the removal of items from the tree, and I'd need
lots of examples of removing nodes from different places in the tree,
and whether it was sparse or maximally bushy. And so it doesn't take
me particularly long to go "sod it" and look up TreeSet in the javadoc
and go "red/black... yeah okay that'll do".

But I can't even remember the last time I wanted to manipulate a 'real
pointer' in Java. And as for the example (on the podcast) of
concatenating strings, I had someone complain that I wasn't doing it
properly because I wasn't using a StringBuffer, so I just pulled out a
decompiler, showed them that behind the scenes the decompiler was
taking my readable code and turning it into more efficient code than
their hard to read StringBuffer spaghetti... and they shut up about
that pretty quickly.

So I think the value of Comp Sci is not what we do, but rather the
subconscious things that we steer away from doing without even
consciously realising it. But lessons from one language such as
"memory allocation is slow, string concatenation is bad" don't
necessarily translate to other languages.

[Michael Neale]

Casper - I do agree as well. But for old curmudgeons like us its easy
to say as thats how we learned. I learned Miranda (dick knows this
one !) and C, and motorola ASM all at uni. ASM was very useful later
in life as well, - until I hit x86 ASM and it made me want to break
down and weep in comparison.

C was useful to me as a high level way of doing asm (thats how I
learned it !), with lots of horriffic #asm inline macros etc... (don't
try this at home).

I don't think it would be too much to expect it is still taught, while
C is still so useful and common. Of course I have forgotten it all
now, and would do untold damage should I have to write some C from
scratch now ;)

The whole C++/OO stuff passed me by, until java at least, so I feel a
bit left out when there is discussions on how great/terrible C++ and
its growth was.

On May 2, 1:59 am, Casper Bang <casper.b...@gmail.com> wrote:

[Casper Bang]

On May 1, 10:53 pm, Rick <rickcar...@gmail.com> wrote:
> But who is Jeff and why would I care what he is saying?

You're kidding right? Jeff passed Joel in popularly and quality a long
time ago.

> I had someone complain that I wasn't doing it
> properly because I wasn't using a StringBuffer, so I just pulled out a
> decompiler, showed them that behind the scenes the decompiler was
> taking my readable code and turning it into more efficient code than
> their hard to read StringBuffer spaghetti... and they shut up about
> that pretty quickly.

But not knowing JVM stack assembly, how were they able to assert that?
Didn't you just make the case that it actually pays to know "the lower
level"?

/Casper

[vjosu...@gmail.com]

On May 1, 4:59 pm, Casper Bang <casper.b...@gmail.com> wrote:
> I believe you should not only spend some time with C, but also
> registry or stack based assembly to really get a feeling for what's
> going on underneath, although I suspect the general Java crowd
> (accustomed to the black magic of the JVM) feel otherwise.

It's well known in motor racing circles that racing car mechanics make
poor racing car drivers precisely because they know how the car
works. The result is that they try go to easy on the car to avoid
damaging it or overstressing its weak points. Drivers who have little
knowledge of a cars innards have no such qualms and will drive the car
into the ground in order to win.

[sherod]

I think tom cruise proved this theory in 'Days of Thunder'...

On May 2, 6:25 pm, "vjosulli...@gmail.com" <vjosulli...@gmail.com>
wrote:

[Rick]

The thing is that for a relatively short period of time you could get
fractionally better performance by using StringBuffer instead of
concatenating with the + operator. So some people wrote articles
about this, and it entered the collective folklore.

A similar example is ArrayList. For a relatively short period of time
ArrayList was slightly faster than Vector. Now it isn't
(synchronisation improvements a couple of language versions back). So
we should _almost never_ use ArrayLists, because Vectors are _always_
safer. But, because it entered the collective folklore, most
libraries prefer the wrong one.

Also, Object Creation. Though we did kind of inherit this one, now
that 'new' is much faster (in many cases) than malloc, we should not
be afraid of slapping 'new' liberally throughout our programs. Go
wild, go crazy, do that OO thang. However, because it is in our
collective folklore, you get all these people jumping through some
very strange hoops (e.g. Singletons, Spring and all sorts of weird and
whacky Factory anti-patterns) to avoid using new.

------

My point isn't to be an expert at the byte code level of the JVM.
Quite the opposite. Knuth says it best: "premature optimisation is
the root of all evil".

My point is to challenge the assumptions and folklore. Some of that
is inherited from Computer Science (like the 'new is bad' and 'string
concatenation is bad' examples I have given).

That said, I personally think that learning about the byte code and
learning computer science are worthy (and interesting) goals in and of
themselves. So I did.

------

There has been a lot of discussion about the mythical "average"
programmer. The language change discussion for instance tended to use
this mythical beast as a kind of bogeyman. E.g. "you can't change the
language because average programmers are too stupid to cope with
change". And on the other side of that ideological fence, they also
flog the same bogeyman. E.g. "if you don't like generics it is
because you are too stupid to cope with change".*

*Not something that I've heard recently, but something that the
proponents of generics ended up saying a lot in frustration before and
for some time after generics were thrust upon us.

And what I would say is that the "average" programmer is what he is.
No more, no less. Just because they go home at the end of the day and
watch Big Brother or Neighbours and don't eat breathe and sleep
programming, does not mean that they are bad or stupid. We shouldn't
patronise them, and we shouldn't underestimate them.

At the same time, we shouldn't pretend that "if they only had some
computer science" exposure they would become uber programmers. For
starters, most of the "average" programmers I've worked with had
Computer Science degrees.

And it seemed like on this podcast they were saying (and I know Joel
says it a lot) that the way to fix bad/average programmers is to
educate them in computer science.

------

That said, if someone is already a successful programmer - without
having had any exposure to computer science - then adding a sprinkling
of comp sci is probably going to make them even better. The other
thing that I'd do is try to get them hooked on phonics. Or, well, the
programming equivalent, which is a highly readable coding style. If
they can see the benefit of readability and either develop their own
style or copy someone else's, then that would cover a multitude of
sins.

[Rick]

> You're kidding right? Jeff passed Joel in popularly and quality a long
> time ago.

Nope, perfectly serious. I may know of him from something he's done,
but frankly the name doesn't ring any bells. And I wouldn't bet money
that I've heard of him before this podcast.

Now I know that he is (apparently) popular. Is he like Daring
Fireball's John Gruber? Which is to say, high popularity, but not
much other than that in terms of actual achievements?

[Casper Bang]

Very good posts Rick! I have no idea who Daring Fireball's John Gruber
is but if you took a look at Coding Horror (Jeff's blog) and see the
pragmaticness this true bottom-up-developer brings forth, it doesn't
really matter that he is not the next Dijkstra or Knuth:
http://www.codinghorror.com/blog/archives.html

/Casper

[Reinier Zwitserloot]

Hold. Stop the presses.

Rick: You should NOT USE VECTOR.

Vector is considered deprecated. It doesn't get an actual @deprecated
marker for obscure, swing related issues.

I'll shoot down the "it's safer" argument, as well as the "it's just
as fast" argument, in a little while, but first: Even if we assume
that it is indeed safer and just as fast, then you still shouldn't use
it. Use Collections.synchronizedList(new ArrayList()); if you must.
Vector ships with a big sack of outdated method names which severely
hamper code maintainance. You have get AND elementAt, etcetera. Do not
use Vector. Period.



"It's just as fast":

False. Synchronization on a multi-core CPU still incurs noticable
performance hits. java6 introduced escape detection; a StringBuffer or
Vector that is created inside a method and never leaves that method
couldn't possibly run in another thread and therefore their
synchronization directives are ignored. However, if you have a vector
as an attribute, or post them around, you do incur somewhat of a
logistics hit.

"It's safer":

This is as dumb as the following code:

String x = ""; //safety
x = someMethodCall();

Any halfway seasoned java programmer knows that the = ""; bit is a
complete waste of time. Yes, you can claim (probably correctly) that
javac will just compile that out, but pointless safety code hampers
readability. self-synchronizing lists are almost always insufficient
for ACTUAL thread safety. However, they do in general suggest that
things are thread safe, and thus you're screwing up maintainability/
readability. If you do two dependent operations on the list in a row,
even if that list is synchronized (Collections.synchronizedList /
Vector), you don't get thread safety. For example, moving an item from
one index to another in a thread safe fashion requires synchronized()
blocks, whether or not you use Vector.

If you really really meant to add self-synchronizing behaviour, use
Collections.synchronizedList.

[Rick]

I require proof of your claims.
I've run code to test large numbers* of insertions into ArrayLists and
Vectors, and they come out the same.** Given that, the preferable one
is the thread safe one.

I have not tested a
Collections.synchronizedList(new ArrayList())
vs a standard ArrayList.

I do however, think that is at least as ugly, if not more so, than any
of the 'old school' method names on Vector.

* From memory I think it was a round number, but the VM ran out of
memory, so I chopped the number in half, so whatever it was was a 5
with a bunch of zeroes after it.
**Not sure if this was on multi-core, might have been on a G5.
Convince me.

[Alexey Zinger]

I'm confused about problems with Vector's own method names.  Ever since the collections framework has been out, Vector was patched to implement List and so it doesn't matter if it has elementAt(int) -- just use get(int) and disregard its historic baggage. But I don't know what's wrong with Collections.synchronizedList(List) either.  I think it's a very elegant API that works out of the box with any kind of List implementation you throw at it (duh).  So what's the beef? Alexey 2001 Honda CBR600F4i (CCS) 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net --- On Sun, 5/4/08, Rick <rickc...@gmail.com> wrote:

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

[Jess Holle]

I have to say that most of the time neither seems right as I'm coding.

9 times out of 10 either:

1. The collection is temporary and entirely local to one thread (e.g. used within one method) or
2. The collection is a field in a higher-level class which requires synchronization between these collection and other activities (at least and not limited to iteration through the collection)

In either case Vector and Collections.synchronizedList() are not appropriate.  In case 2, I want to see the synchronization very explicitly in the higher-level classes' code in any/all cases and leave comments regarding the internal locking/synchronization policy of my fields attached to their declarations.

--
Jess Holle

[Reinier Zwitserloot]

Rick: Try again on a multi-core CPU. Engaging locks on a single core
CPU is a lot cheaper. You also didn't adress my main point: Doing
things 'for safety reasons', especially if those safety reasons are
provably useless, is a recipe for unmaintainable code. And, yes, slow
code. A single safety measure won't make much of a difference, but add
every pointless 'safety method' in the book and you've got 20-line
methods, each spinning away doing useless things for 99% of the time
they run.

Alexey: It doesn't matter if you then assign the Vector to a List
instance. It does matter if you write e.g. Vector x = new Vector(),
because auto-complete will suggest far too many methods, and other
coders maintaining your code might go for an old method, which makes
switching list implementations a lot more difficult. But if you're
going to assign it to a List, and thereby remove the 'I'm safe but not
really' context that Rick cares so much about, then why not just go
with ArrayList, or, when you actually carefully analysed the program
and realized that self-synchronizing is exactly what's needed, use
Collections.synchronizedList to convey this notion in your code,
instead of Vector, which parrots any of these ambiguous messages:

- I copied this over from ancient code.
- I learned java at university and my professor still thinks the
latest usable java version is 1.1. There are many professors who work
this way. I know. Hang out in ##java on freenode and you'll know too.
- I have strange and exotic notions of how to write code.
- I actually meant to have a self-synchronized list.

Obviously the ambiguity means that 'Vector' is useless as a hint when
reading the code.

Jess: Indeed, a good point. self-synchronization is almost never
enough if the list is actually used in multiple threads.

[Alexey Zinger]

--- On Sun, 5/4/08, Reinier Zwitserloot <rein...@gmail.com> wrote:

From: Reinier Zwitserloot <rein...@gmail.com> Subject: [The Java Posse] Re: Joel Spolsky and Jeff Atwood have a podcast: Stack Overflow To: "The Java Posse" <java...@googlegroups.com>

Date: Sunday, May 4, 2008, 12:59 PM Alexey: It doesn't matter if you then assign the Vector to a List instance. It does matter if you write e.g. Vector x = new Vector(), because auto-complete will suggest far too many methods, and other coders maintaining your code might go for an old method, which makes switching list implementations a lot more difficult. But if you're going to assign it to a List, and thereby remove the 'I'm safe but not really' context that Rick cares so much about, then why not just go with ArrayList, or, when you actually carefully analysed the program

Hang on a minute.  When you write List l = new Vector() it's still a synchronized implementation of List.  I'd rather go with Collections.synchronizedList(new ...List()), out of the flexibility given to us by synchronizedList(List) method.  There's nothing particularly wrong with Vector itself in the form it is in now and passing it around as a List certainly does not strip it of its synchronous behavior.

and realized that self-synchronizing is exactly what's needed, use Collections.synchronizedList to convey this notion in your code, instead of Vector, which parrots any of these ambiguous messages: - I copied this over from ancient code. - I learned java at university and my professor still thinks the latest usable java version is 1.1. There are many professors who work this way. I know. Hang out in ##java on freenode and you'll know too. - I have strange and exotic notions of how to write code. - I actually meant to have a self-synchronized list. Obviously the ambiguity means that 'Vector' is useless as a hint when reading the code

[Rick]

I refute your argument:

import java.util.*;

public class VectorVsArrayList {

public static void main (String args[]) {
// insert code here...
System.out.println("Hello World!");
Vector v = new Vector();
ArrayList al = new ArrayList();
Test t1 = new Test(v);
Test t2 = new Test(al);
}
}

import java.util.*;
import java.math.*;

public class Test {

public Test(List l) {
long start = System.currentTimeMillis();
addLargeNumberOfItems(l, 500000);
long finish = System.currentTimeMillis();
System.out.println("time taken: " + (finish - start));
}

void addLargeNumberOfItems(List l, int n) {
BigInteger bi = BigInteger.ONE;
BigInteger increment = BigInteger.ONE;

for (int i = 0; i < n; i++) {
l.add(bi);
bi = bi.add(increment);
}
}

}

produces the following output:

[Session started at 2008-05-05 14:08:19 +1000.]
Hello World!
time taken: 470
time taken: 615

The Debugger has exited with status 0.

Thus demonstrating that ArrayList is in fact over 30% slower than
Vector.
Score one for the good guys. :D

NB: as an exercise to the reader, there are _at least_ 3 things wrong
with the above program. As the saying goes, lies, damn lies, and
statistics.

[DJ]

Rick,

That is a faulty benchmark, you have both Vector and ArrayList test in
the same code.
When using your code, yes I get roughly the same result that you got.
BUT, if you switch the line between test1 and test2..then you'll get
ArrayList running almost TWICE faster than Vector.

I didn't bother turn on memory monitoring, but my first guess is that
by that time the heap space getting big and VM spent more time
managing the heap space that cause whichever got called the 2nd time
run slower.

I splitted your code into 2 to call Vector test and ArrayList
individually. Running VectorTest and ArrayList Test 3 times, I got
these number: Vector avg:407ms and ArrayList avg:344ms. Which means
ArrayList is about 20% faster than Vector.

[Reinier Zwitserloot]

Yes, Alexey, in that case Vector is more or less a synonym for
Collections.syncList(ArrayList).

Let's also make duplicate names for InputStream, Long, Math, Random,
Socket, and CharSet.

Why? because it's fun!

That's possibly the most important reason everyone should stop using
Vector. Dupes are dumb, and if one of the two has to go, clearly its
Vector.

On May 5, 12:08 am, Alexey Zinger <inline_f...@yahoo.com> wrote:
> --- OnSun, 5/4/08, Reinier Zwitserloot<rein...@gmail.com>wrote:From: Reinier Zwitserloot <rein...@gmail.com>

> Subject: [The Java Posse] Re: Joel Spolsky and Jeff Atwood have a podcast: Stack Overflow
> To: "The Java Posse" <java...@googlegroups.com>

> Date: Sunday, May 4, 2008, 12:59 PMAlexey: It doesn't matter if you then assign the Vector to a List

> instance. It does matter if you write e.g. Vector x = new Vector(),
> because auto-complete will suggest far too many methods, and other
> coders maintaining your code might go for an old method, which makes
> switching list implementations a lot more difficult. But if you're
> going to assign it to a List, and thereby remove the 'I'm safe but not
> really' context that Rick cares so much about, then why not just go

> with ArrayList, or, when you actually carefully analysed the programHang on a minute.  When you write List l = new Vector() it's still a synchronized implementation of List.  I'd rather go with Collections.synchronizedList(new ...List()), out of the flexibility given to us by synchronizedList(List) method.  There's nothing particularly wrong with Vector itself in the form it is in now and passing it around as a List certainly does not strip it of its synchronous behavior.and realized that self-synchronizing is exactly what's needed, use

> Collections.synchronizedList to convey this notion in your code,
> instead of Vector, which parrots any of these ambiguous messages:
> - I copied this over from ancient code.
> - I learned java at university and my professor still thinks the
> latest usable java version is 1.1. There are many professors who work
> this way. I know. Hang out in ##java on freenode and you'll know too.
> - I have strange and exotic notions of how to write code.
> - I actually meant to have a self-synchronized list.
> Obviously the ambiguity means that 'Vector' is useless as a hint when

> reading the codeBe a better friend, newshound, and know-it-all with Yahoo! Mobile.Try it now.

[Reinier Zwitserloot]

That is not even close to a valid performance test. The fact that
ArrayList is slower than Vector is all by itself proof enough that you
srewed it up.

A few hints:

1. Your code is too simple - do something with v/al in an area that
could theoretically be accessed by another thread. Hotspot will pick
up on this in no time.
2. Are you running this on multiple cores? If not this isn't testing
much - the entire addLargeNumberOfItems method will be hotspotted into
a single large synchronize-free zone.
3. what VM is this on? a single number on the server VM is *ALWAYS*
wrong. You should produce a chart of how long something takes over
time and inspect the chart.
4. Excellent job in taking one of the many arguments and ignoring the
rest of em.
5. As DJ mentioned, ArrayList is really, really, faster than Vector.
Really. And no, it doesn't matter in 99.9% of all cases. It's the
least important argument for why you should stop using Vector.

[zendar]

The results you are getting are among other things also dependant on
the growth policy of the Vector versus the ArrayList.

The Vector's growth policy makes it double its capacity when it
becomes full. From what I remember the ArrayList mulitplies the
current capacity by something around 1.5. This is dependant on the
implementation of the jvm, since Sun hasn't defined a standard growth
policy for ArrayList.

Looking at those numbers and that bad micro benchmark doesnt really
say anything about the speed of Vector versus ArrayList. :)

[Rick]

You get full marks. I'd give you bonus points for extra effort as
well, except that I suspect that your 2x claim indicates that your
benchmark is also suitably flawed. :D

To recap, the three things are:

(1) swapping

Test t1 = new Test(v);
Test t2 = new Test(al);

for

Test t2 = new Test(al);
Test t1 = new Test(v);

also reverses the results. E.g. in this code, whoever goes second is
slower

(2) inserting

Test t1 = new Test(v);

System.gc();

Test t2 = new Test(al);

reverses the result of #1, now the second one is faster, no matter
which is first (Vector or ArrayList)

(3) the sample size is too small to make valid claims about the degree
to which one is better than the other.

You managed to hit all three straight up.

[Rick]

That is a really interesting point.
I suppose by using that to our advantage it would be possible to
further manipulate a simple benchmark one way or the other. E.g.
starting with a Vector of size 1000, we'd end up with one of size
512,000, with 9 doublings, whereas starting with an ArrayList of size
1000 we'd end up with one of size ~656,840 with 16 increases in size.

I disagree with your conclusion though:
"(the test) doesn't really say anything about the speed of Vector
versus ArrayList"

What it does say is:

(1) that even for an excessively large number of insertions, the
performance is close enough for rock and roll.
(2) determining the performance is complicated, often in unexpected
ways (e.g. things being faster after the call to System.gc()).
(3) under some conditions Vector is faster than ArrayList (and vice
versa).

Any one of these points would be a rebuttal to the "ArrayList is
faster" meme, together they are devastating.

In addition, for our particular flavour of that debate I would add the
following:

(4) running on one core or multi-cores didn't change the result.

In order to 'win' ArrayList needed to have a clear result, and it
didn't. In order to 'win' Vector needed to simply keep up with
ArrayList (which it did) and/or show that it is difficult to get a
clear and simple result. Because in the absence of a clear result,
safety trumps performance.

[Reinier Zwitserloot]

"Devastating"? Your crappy microbenchmark doesn't devastate any
claims.

You continue to ignore the fact that 'ArrayList is faster' is the
LEAST important reason why you should stop using Vector. I'll again
summarize the real reason for you: Duplicate classes are stupid. We
must pick between ArrayList and Vector. If we must pick, clearly
ArrayList wins over Vector for obvious reasons. If you have trouble
seeing the obviousness, then read the earlier posts in this thread.

There are also situations where ArrayList can be measurably faster
than Vector. That's simply because there are situations where
synchronized() is measurably slower. These situations are somewhat
rare today, and the intersection of "situations where needless
synchronized() is noticably slower" and "we care at all about the
speed of this particular method" is very small indeed. But it exists.

But, for the sake of this discussion, I'll submit to your efforts:
Let's take 'arraylists are faster' off the table entirely. Let's go
with 'Vector' and 'ArrayList' are equally fast. Now defend Vector
against the real arguments, please:

1) self-synchronizing is almost always insufficient if the list is
actually used in a multi-threaded environment. Writing safety code
because you don't know what you are doing is ALWAYS bad, both for
maintainability, readability, and for producing bug-free code.

2) Vector contains aged cruft. Specifically: It contains old method
names, and its name does not conform to the java.util naming standard
(where implementations of X end in X: TreeMap, HashMap, LinkedHashMap,
are all implementations of Map, LinkedList and ArrayList are
implementations of List, TreeSet and HashSet are implementations of
Set).

3) Combine the above 2 with the fact that we must choose: If every
class in java had a duplicate with virtually equal behaviour, and
everyone just picked a random version to use, code would be utterly
nightmarish to read. You'd need to know twice as many classes. Dupes
are no good. We must pick one.

[kirk]

Reinier Zwitserloot wrote:
> "Devastating"? Your crappy microbenchmark doesn't devastate any
> claims.
>

One needs to be very very careful when benchmarking synchronization. In
fact, I've not found a meaningful way to bench synchronization. The JIT
just does way too many things for one to safely to imply what native
code from Java Code may look like.

Regards,
Kirk Pepperdine

http://www.javaperformancetuning.com

> In