joel thinks java makes you dumb

[otake-tux]

edit- comment may have offended someone.

in here (http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html) there is an article that deals with the subject of teaching java. Its an interesting read and I'd like to see what the ubuntu comunity thinks about this.

[LordHunter317]

If you like to program and you do not know who joel spolsky is you better read on.If you like to program and you actually listen to what joel says, you should spend yourself bettering your time programming instead of listening to someone who just reguritates pop-thought in poor ways.

It also doesn't help that his article is as wrong as wrong can be. Java has pointers, and Java supports recursion and I've written plenty of recursive code in Java.

His real issues is that schools are no longer teacher the actual topics of CS and software engineering, but rather just turning out waves of programmers. And that's not argued. But his basis for making the argument is well, retarded. Scapegoating something as inanimate as a language indicates to me that you have no argument. There are far eaiser, more passionate, more logical, and stronger arguments to make here.

Java isn't at fault.

Its an interesting read and I'd like to see what the ubuntu comunity thinks about this.I think you should stop reading what Joel says, frankly. The number of obvious logical fallacies he draws is amazing. Virtually every paragraph states a problem, then constructs a strawman to argue against it (he ignores the most important issue or key factor every time).

[Syntax13]

This article is kind of ironic. My friends and I were discussing how the CS degree has become a big joke. I've never seen or used any java, so i can't agree or disagree with him on that. But we were comparing my freshman CS classes with a junior's, and it's basiclly the same thing over and over (actually, the freshman class is ahead...we've passed "the basic structure of a while loop"). The senior and graduate classes seem decent, but overall it's become pretty sad. (i get flashbacks to highschool...same thing every year over and over).

[otake-tux]

I did not say that I agree with him, nor did I say he is always right. Never the less, hi is a proffesional programmer with many years of experience and published works.

[LordHunter317]

Never the less, hi is a proffesional programmer with many years of experience and published works.That doesn't make him qualifed to comment either, per se. His "expertise" is more due to his popularity, not his actually expertise.

Anyway, you asked for commentary, you got it. The article is trash.

[otake-tux]

Anyway, you asked for commentary, you got it. The article is trash.
Why are you being so rude? I happen to agree with you, I just posted this because I thought it be an interesting subject for the programming board. Joel may not be always right, but he does deserve to be heard. Many young college students visit this board and the subject of joels post pertains to them. Joel did justify his views, he does bring an interesting point and its worth discussing in a programming board, there's no need to get all mad about it.

[LordHunter317]

Why are you being so rude? I'm not being rude, I'm being brief. There is a difference.

I happen to agree with you, I just posted this because I thought it be an interesting subject for the programming board.Why? "Joel spouts more drivel" If I want drivel, I'll read /. There's no interesting commentary there. It's not only been done before, it's been done better.

Joel may not be always right, but he does deserve to be heard.Because he has a book published? Because people read his blog? If so, then it's a sad state.

Joel did justify his views,Poorly. A student haven taken 3 days of basic logic or debate could point out the obvious, glaring holes.

he does bring an interesting pointNo, he doesn't. It's a prima facie logical fallacy and is therefore uninteresting.

and its worth discussing in a programming board, there's no need to get all mad about it.I'm not mad. You're the one who's clearly upset about the fact I'm slamming Joel and slamming you slightly for posting it for no other reason then because it was Joel who wrote it, since that's a crap reason.

[nrwilk]

I find this person to be utterly illogical and entirely wrong.

Although I'd rather have the avian flu than write another line of Java, I strongly disagree that this situation is the fault of the language.

[otake-tux]

allright I see what you are saying clearly. I guess we cannot post anything you do not like in this board. I will ask for your permission next time :confused:

see you could have posted you opinion without slamming anybody but joel, you could have just said you didnt agree with him for this and that reason. That was the purpose of this thread. You didnt and now the thread just looks like an ego driven argument between me and you. ok, you win.

[LordHunter317]

I guess we cannot post anything you do not like in this board.No, that's not what I'm saying. What I'm saying is twofold: Trying to defend your posting of Joel's article "because Joel worte is" is illogical, and silly. If it were Strostroup or Dijkstra, maybe then we'd be talking about someone where they're at the level it's sufficent to post their work for the simple sake they wrote it. Joel isn't at that level. Yet, you've done that since the beginning: your whole apparent reason for posting this is "because Joel wrote it," and not because the article actually has any merit or value. Where I come from, the author is cared less about than the merit or value of the work. The merit of this work is zero, and the merit of the author isn't enough to cover for that (it almost never is). Ignoring your reasons for posting it, the article a) says nothing new b) says nothing valid c) other articles say these things better. So if your goal was to start a discussion about the state of higher education and the IT industry, there are far better articles you could have cited. If your goal was to get commentary on Joel's, you got it. The article is bad enough it shouldn't even be read.

If you don't like that view, that's fine. However, I don't think this is the right forum for talking about Joel for the sake of Joel. Which is seemingly what you want.

see you could have posted you opinion without slamming anybody but joel, you could have just said you didnt agree with him for this and that reason.The only thing I ever slammed you for is defended Joel as someone who has an inherent right to be heard or listened to. He doesn't, no more than anyone else. He's not special. He has no excessively special credentials, besides he writes pop-culture IT articles that lots of people seemingly read.

For someone with lots of claimed technical "expertise", he sure makes a lot of technical errors in that article.

[Viro]

I agree with LH that the article is rubbish. Needing a programming language that weeds out poor programmers?!? The problem with many CS courses is that they overemphasize programming, and underemphasize algorithms. So what if you can program in 10 languages but fail to adequately analyze a problem and come up with a solution?

As someone who has tutored undergraduates, it is shocking how so many of them fail at simple problem solving tasks. A move to some difficult programming language with all the gory low level details exposed will not help them. A good course in problem solving will.

In my opinion, Joel is barking up the wrong tree, and while I wouldn't put it across to you the same way that LH has done, in essence I agree with him. Who on earth is Joel, and why should we care about what he thinks? Especially considering that this article has no merit whatsoever. I wouldn't trust anyone who thought that programming in 1s and 0s will make you a better programmer :).

[jerome bettis]

sounds like nothing more than someone who had to bust his balls doing C in college to graduate, while my i just wrote java (great language to type i think) and didn't struggle at all. i.e. i had a social life and he was too busy or too dorky to. jealous maybe?

thankfully i took c++ in 9th & 10th grade so i can use pointers. i can also use recursion, but it's usually not the best way to solve a problem. it is neat though; lisp, prolog etc are very very interesting, but as of now they won't put any cash in my wallet.

if i was teaching programming i'd probably start with pascal for a little bit, then move to java. after a few years of java i'd transition into all the crazy stuff C++ has, i wouldn't even mention C.

[paulr]

I think it's half tongue in cheek. One thing that *is* true is that writing code in a language where you have to do much of the work manually does teach you about the importance of resources ; too many programs these days treat resources like they are infinite (notably Microsoft !). It also helps with algorithm design.

[jerome bettis]

nice first post, that's a good point

when i write i java program i pay 0 attention to ram or any of that crap!! but when i write a c++ program that stuff (resources) is important to keep track of.

but is that really a bad thing? i mean, java is slow but are you really that impatient? if i can turn out working code in 1/2 the time using java, at the cost of your barely noticeable milliseconds, is it really that big of a deal?

[paulr]

It depends what you are coding ! Even in Java you shouldn't throw memory around like it's going out of fashion. It's the old 80/20 rule ; most of the time it doesn't matter.

It's important on some platforms ; some are limited, some (Windows) don't manage resources very well. The point is if you don't understand what's happening inside the JVM, then once in a while you will screw up big time.

[Viro]

I fail to see the point about memory management in GC'd languages like Java or C#. Just because there is a GC, that doesn't automatically make you randomly allocate objects on the heap. It allows you to not have to worry about freeing objects that you have allocated as you don't have to worry about when those objects go out of scope. Nevertheless, it doesn't make you sloppy with memory. You can be sloppy with memory in any language.

[LordHunter317]

when i write i java program i pay 0 attention to ram or any of that crap!!Then you're a horrible java programmer and you need to go back and start over. The only resource you don't have to manage is memory.

It depends what you are coding ! Even in Java you shouldn't throw memory around like it's going out of fashion.I fail to see what you mean here, seeing as you have little choice in the matter about where you do your allocations.

It's important on some platforms ; some are limited, some (Windows) don't manage resources very well.Windows manages what the JVM asks of it perfectly well, unless you're not talking about a Windows NT-based OS (and I don't know why you would).

The point is if you don't understand what's happening inside the JVM, then once in a while you will screw up big time.Rarely do you have to care about how the JVM internals actually operate.

Nevertheless, it doesn't make you sloppy with memory. You can be sloppy with memory in any language.In Java at least, it makes you more disciplined since you have no where else to put things.

[paulr]

Undoubtedly you can be sloppy in any language. I think the line of "oh, it doesn't matter about Memory Management" in Java, or any other language is a programmer problem. Java simply garbage collects up the unused objects. You still may (in some circumstances) have to think about what you are actually creating.

When you are building objects / data structures you still have to think about what you are doing with memory and OS/Hardware resources. Even in Java. All resources are finite, all code takes time to operate. Some coders behave like resources are infinite and processing time are nil.

[LordHunter317]

Undoubtedly you can be sloppy in any language. I think the line of "oh, it doesn't matter about Memory Management" in Java, or any other language is a programmer problem.Not especially. You're taking that line to mean more than it actually does. I don't have to worry about memory deallocation. That's it. I also don't generally have to worry about memory consumption except peak consumption, because the garbarge collector will ensure I stay under whatever my peak is.


When you are building objects / data structures you still have to think about what you are doing with memory and OS/Hardware resources.And the above has never been contradictory with that. I don't know where you got the idea that anyone every suggested it did. Only people who don't understand the language (and thus, should be ignored) believe that.

[jerome bettis]

Then you're a horrible java programmer and you need to go back and start over. The only resource you don't have to manage is memory.

yeah i was exaggerating, i'm always conscious about how much time / space something needs.

[LordHunter317]

I wasn't referring to time/space considerations. I was reffering to unmanged resources, like file descriptions and database handles.

[bavs]

looks like a recruitment website. it seems to say that im a great guru and need people who can program C faster than me but i cant afford to pay you guys more so i dont want people from mit and yale but i need talent. thats what it says to me.

[slavik]

my problems with java ...

1. No operator overloading (int is not Integer and vice versa).
2. Everyone denies that references are hidden pointers. (I like references more than pointers)
3. Exceptions ... sometimes worse than segfaults ...

the good java things ...

1. Built in regex library (standard)
2. Arrays and such are objects with other properties besides data (helps with bounds checking and such)
4. Applets
3. NO SEGFAULTS!!!

As for the way java is being taught ... I don't like that profs yell that memmory is cheap ... even though GC is there, the programmer needs to allocate just enough memmory as he needs and deallocate it when he doesn't (unless he can reuse it somehow).

Did I mention that regex is standard in Java? Before I found that out, I was a Perl person.

Maybe he needs to be reminded of COBOL?

And as far as today's students being dumber, it isn't Java's fault at all ... Java is simply a better language (in some respects) to C++.

[Viro]

1. No operator overloading (int is not Integer and vice versa).

Agreed. This is very annoying and coupled with the lack of a good Math library (the supplied one is extremely precise, but extremely slow) make Java nearly useless for numerical apps. This is a shame, as Java makes it easier to write safe code, i.e. code you know works and doesn't have subtle bugs in it that can affect your results without your knowing it.

2. Everyone denies that references are hidden pointers. (I like references more than pointers)

References are not pointers. You can't do any pointer arithmetic with them, and the annoying thing in Java is the fact that all Objects are references, yet these references are passed to methods by value. To see how stupid this is, try writing a method that takes 2 parameters (say two Strings, a and b) swaps their values. The change will in the method, but will not be reflected outside the method(!!). There is no easy way to do this task in Java and it makes it nearly impossible to return multiple values from a method.

3. Exceptions ... sometimes worse than segfaults ...

In my experience, they are never worse than segfaults. Segfaults do not tell you the line and source file where the error occured, while exceptions do. That has saved me countless hours of hair-pulling ;).

As for the way java is being taught ... I don't like that profs yell that memmory is cheap ... even though GC is there, the programmer needs to allocate just enough memmory as he needs and deallocate it when he doesn't (unless he can reuse it somehow).

If professors are yelling that, they need to get a reality check. Just because the GC is there doesn't mean you liberally sprinkle your code with new statements. The GC is nice as I don't need to worry about memory deallocation (and object lifetimes), something I'm thankful for.

[LordHunter317]

1. No operator overloading (int is not Integer and vice versa).This isn't operator overloading. This is autoboxing, and it's mostly fixed in Java 5.

2. Everyone denies that references are hidden pointers. (I like references more than pointers)They're not hidden pointers, they're just pointers. There's nothing hidden about them.

3. Exceptions ... sometimes worse than segfaults ...No, that means you clearly understand nothing about exceptions. If you had said checked exceptions, I might agree with you.

But exceptions are a totally valid and wonderful tool ,because they provide a mechanism for clean resource disposal in all cases (try/finally). Java programmer would be infinitely more difficult without exceptions and without try/finally.

3. NO SEGFAULTS!!!You haven't written enough Java code then. The JVM is hardly bbug free.

As for the way java is being taught ... I don't like that profs yell that memmory is cheap ...It is cheap. You have 2 GiB of virtual address space, might as well use it.

even though GC is there, the programmer needs to allocate just enough memmory as he needsAnd I don't see many professors encourging anything else.

and deallocate it when he doesn't (unless he can reuse it somehow).He can't deallocate it, so this is a non-sequitur.

References are not pointers.Yes, they are. They point to a variable somewhere else in memory, and they can be reseated (meaning they can be made to point to a different variable). In order to be a reference, they would have to deny reseating (meaning a = c would cause a to copy c, not point to it).

It's trival to write some C++ and Java code to prove that Java "references" have pointer-semantics, not reference-ones.

You can't do any pointer arithmetic with them,So? C and C++ are virtually unique in that regard. Pascal has pointers, arithmetic is denied. So do some dialects of FORTRAN, etc.

and the annoying thing in Java is the fact that all Objects are references, yet these references are passed to methods by value.No, that's a good thing. Passing a pointer by reference doesn't gain you much. In any case, the times I've seen that being useful are few and very far between, and were usually indicitive of an overly complex design.

To see how stupid this is, try writing a method that takes 2 parameters (say two Strings, a and b) swaps their values. The change will in the method, but will not be reflected outside the method(!!). Uhh, yes it will, if you do it correctly. What you're attempting to describe isn't a correct generic swap method in any language. You don't just swap the pointers, you deep copy the the two objects.

Certainly, that's what swap(object* a, object* b) in C++ would do.

Now, you can't do in Java because string are immutable, but that's a different story.

Also, yes you can't write a Java method that swaps the values of two pointers, because there's no way to pass a reference to a pointer or a pointer-to-a-pointer, whereas a generic C++ swap() function could do that.

But that's hardly a large enough limitation to abolish the strict pass-by-value policy, which is one of the few things I love about Java.
If professors are yelling that, they need to get a reality check. Just because the GC is there doesn't mean you liberally sprinkle your code with new statements.Yes, it does, what else am I supposed to do to create objects?

The GC is nice as I don't need to worry about memory deallocation (and object lifetimes),Only if the object consists totally of managed resources. Then you care very dealy about the lifetime.

[alexal]

I dont have read what brainless joel said but because i use java very much i can say that joe is stupid.

if you going to make the same program with java and the same with C java needs less time and because its OOP its easyer and some times more eficient. less time=more programs=more money=....(if you work as a programmer).

So should i open a knew thread:twisted: (refering to his website) with the title
''ALEX SAYS JOEL IS STUPID'' OR ''ALEX SAYS JOEL IS DUMP'' ? :-k

[LordHunter317]

if you going to make the same program with java and the same with C java needs less time No, that's not true at all. Many programs will take equal time, and many will take less time in C (or can't be implemented in Java at all).

and because its OOP its easyer and some times more eficient. less time=more programs=more money=....(if you work as a programmer).I'm generally employed salaried or hourly, so all that matters is I hit my deadlines. I get paid regardless.

[LordHunter317]

I should clarify an eariler statement I made, as it wasn't clear.

As far as segfaults, you can see them for two reasons: JVM bugs (which I have seen before with older Java releases) or broken native code called through JNI, which is more common.

[tbrownaw]

As for the way java is being taught ... I don't like that profs yell that memmory is cheap ...
It is cheap. You have 2 GiB of virtual address space, might as well use it.

But you still only have 1/4 to 1/2 GB of real memory, shared between *everything* that's running at the time.

[LordHunter317]

But you still only have 1/4 to 1/2 GB of real memory, shared between *everything* that's running at the time.No, it's rarely shared between everything, this is why we have a swapfile. My statement was slightly tounge-in-cheek, but the points remains: people fuss over memory when compared to other resources, it's not precious at all.

I may on a server have 2GiB of physical RAM. I may have only 100 database connections. As such, if I'm going to best spending time being frugal with anything, it's the database connections. Spending time on being frugal on RAM (meaning, letting the GC perform optimally in all situations) is silly when I have resource considerations of several orders of magintude more important.

It's the 80/20 rule, but applied to resources. RAM doesn't meet that consideration.

[slavik]

right, so I will write a java program that allocates 1-2GB of space and then we'll see how fun it is for your HDD sub system to constantly have to copy stuff to memmory ...

consider the following piece of code ...


string s="hello world";
for (int i=0;i<100000000;i++) {
s=s+"a";
}


according to C++, the actual string gets changed and since it's dynamic each loop iteration increases the string size by 1 byte. In java a whole new string is created every time ... not to mention that the old string is not deallocated by the programmer, it stays in memmory until the gc kills the old objects ...

memmory is cheap, but it is not infinite ... neither is the hdd space for swap.

another things is that java is interpreted (even if it's compiled for a virtual CPU, the bytecode is still interpreted by the jvm).

create a vector in both languages and then call the sort function on them, C++ will be much faster than java on the same system.

[LordHunter317]

right, so I will write a java program that allocates 1-2GB of space and then we'll see how fun it is for your HDD sub system to constantly have to copy stuff to memmory ...But it won't do that. The pages will be paged out when they're sufficently old enough and there's enough VM pressure, and won't be read in again until garbage collection time.

Pages consisting of an mixture of living and dead objects won't page out, if they're really active.

Which will presumably be when load is low enough the cost of page-in doesn't matter. This isn't always the case (big J2EE servers, desktops in certain situations with other applications) but those cases can be planned and avoided for.

according to C++, the actual string gets changed and since it's dynamic each loop iteration increases the string size by 1 byte.Actually, I'm pretty certain no STL implementation on the planet does this. On a modern OS, even if you did allocate memory on every call via new, you'll only get a new page every 4K bytes or so (x86, anyway), and a syscall even less.

But they don't do that anyway: they allocate a large chunk (usually at least a page) and go from there.

In java a whole new string is created every timeRight, strings are immutable. It doesn't take a genius to realize that such code isn't performance optimal when dealing with an immutable object. Nor did I ever encourage it.

... not to mention that the old string is not deallocatedBecause you cannot.

by the programmer, it stays in memmory until the gc kills the old objects ...Right, and assuming the GC ran instanteously and completely, you could always collect the previously appended string after creating the next one. Best case, you never have more than two strings objects in memory at once. You're certainly not referring to any more.

Even assuming the GC doesn't run instanteously, it could still keep the peak working set of such an operation fairly low and the average acceptable.

another things is that java is interpreted (even if it's compiled for a virtual CPU, the bytecode is still interpreted by the jvm).So?

create a vector in both languages and then call the sort function on them, C++ will be much faster than java on the same system.Yes, but a single sort is meaningless without context.

[slavik]

an interpreted language only has a best case scenario of a language that is natively compiled (yes, java can be compiled to native code, but so can perl, php, many others).

as for not being able to deallocate the old string in java, that is my point ... that you can't and it introduces a memmory leak. that type of code is what the gc is for ...

as for the sort thing ... don't quote me on this, but I read a comparison of 'speed' and it turned out that perl was faster in sorting things than java ...

I'll try to find the time to write up some C++ and Java code to sort integers and time both ...

could you ellaborate more on the paging part?

[Viro]

an interpreted language only has a best case scenario of a language that is natively compiled (yes, java can be compiled to native code, but so can perl, php, many others).


I don't know if you realize that the HotSpot VM compiles Java code 'on-the-fly' to machine instructions, once it has run the code a few times to profile where the 'hot-spots' are. Once the bytecode is compiled to machine code, can it still be considered interpreted? This occurs in .NET and Mono as well.

Java has had a JIT since... v1.1 in '97.


I'll try to find the time to write up some C++ and Java code to sort integers and time both ...

Right.... you're going to pit the STL vector and C++ templates against Java's collection classes and its pseudo generics. I can tell you off hand that C++ will be faster by quite a margin. Any competent Java programmer will know why.

If you're just going to sort arrays, well, that is such a trivial benchmark it doesn't demonstrate anything meaningful.

[LordHunter317]

an interpreted language only has a best case scenario of a language that is natively compiledNo, that's totally wrong.

Consider the simple fact that deallocating memory takes time. In C++, I pay for that deallocation for non-heap objects everytime I go out of scope: this involves a function call for all non primitive objects. For something like std::vector<>, this will involve calls to delete and so forth.

In Java, those calls can be deferred until later, at the cost of memory. But if they can be deferred to a time when I'm not actually doing anything performance sensitive, then the performance sensitive code will be faster, as I'm doing less work.

Proof is in the fact that certain C++ codebases frequently perform an order-of-magnitude faster or more when given a GC. Being able to defer deallocation of memory is occasionally useful, especially if the deallocation is complicated or will cascade to many other objects, like in a std::vector<>.

This is especially true for a lot of the code that Java is used for: web applications that run on threads for short time spans, allocating relatively small objects and not needing them once the thread finishes. Moreover, the GC can run on a seperate thread independent of the web application's task, cleaning up after it whenever it's not/less busy, which means it performs better.

And yes, there's almost always a memory space tradeoff for this and deallocation takes longer when it occurs. But now it's deferred and running in parallel, meaning the task I really care about, pushing webpages, happens faster.

This is also why JDBC drivers and ADO.NET drivers make heavy use of connection pooling: opening a database connection is an extremely expensive operation. So it's better to keep several connections open and ready and simply hand back references to the connections as needed. This also lets us defer the closing (also expensive) and allows us to open new connections independent of need on a seperate thread. So again, we're trading memory and a little time for the ability to defer and for parallelism.

as for not being able to deallocate the old string in java,No, you misunderstand. [b]The programmer can never deallocate memory because that task can only be performed by the GC[/i].

that is my point ... that you can't and it introduces a memmory leak.No, it would only be a memory leak if the GC no longer tracked that object, which would mean the GC is broken.

A memory leak only occurs when you have allocated memory you no longer have a reference to. In a garbage-collected language, the garbage collector effectively has an implict reference to all heap-allocated objects, though it may not be implemented that way.

could you ellaborate more on the paging part?What specifically?

[LordHunter317]

Moreover, w.r.t. to byte-code interpreted vs. native performance, a JIT or AOT interpreter. can do dynamic profiling of the code and hint about what branches will be taken more often on platforms that support such things, like Itanium.

[slavik]

right, the programmer can't deallocate something that he can't "name", no argument there.

what I meant about the memory leak, is that it is still a leak, until gc comes in and sucks up all the spilled memory and returns it to the bucket.

[LordHunter317]

what I meant about the memory leak, is that it is still a leak, until gc comes in and sucks up all the spilled memory and returns it to the bucket.That's not a leak though, by definition. IT would only be aleak if the GC couldn't collect it.

In a garbaged-collected language, merely not having a pointer to a heap-allocated object in your code isn't sufficent for there to be a leak. The GC has to lose track of the item too, or it has to be in a state where the GC can't ever collect it (Python allows this to occur by default).

If this were C or C++, then all you need to do is lose track of it.

[slavik]

oh, I see.

Another thing about Java ... it has a lot of built in things for the standard types.

example: vectors/lists have a "contain" method ... C++ doesn't.

My Java prof made us code a template in C++ and a class in Java to implement a set.

I used vector for both. In the Java version, the only 2 functions that I really had to code (not so trivial) were Intersection and Union. In C++ I had to code that contains method (that tells you if the thing is in your vector).

Another thing I don't like. There is no stdin object (buffered input from stdin) like the is in C++ (cin). I understand that in Java the idea is that you put your own buffered reader together ... but it would be nice if there was something predefined.

It also seems like creating GUI applications (not applets) is simpler in Java (especially with VEP in Eclipse) than in C++. (I like how VB6 does with GUI programs).

[LordHunter317]

example: vectors/lists have a "contain" method ... C++ doesn't.That's because the STL has std::find that works on all containers, not just vectors.

[siman]

end of article says:

"Feh.
I'm going back to ones and zeros.
(You had ones? Lucky bastard! All we got were zeros.)"

obviously joel was not serious about all that "we had it so hard... blabla". I agree that it was stupid to start a language-war to proof his point (or the other way around?).... but maybe there's a joke within i dont get.

where you from? you all seem to have learnt java at univeristy? in europe (austria at least) they started teaching java in most programming classes (not in "functional programming" or "logic oriented programming") in ~2000... during my second year.

i think joels point is, that everything about CS can be learnt when you solve C or assembly problems... maybe that's true to some point.