[PRL] The latest from Joel

[Matthias Felleisen]

On Jan 2, 2006, at 2:58 PM, Felix S Klock II wrote:

> Matthias-
>
> On Dec 30, 2005, at 3:22 PM, Matthias Felleisen wrote:
>
>> Felix, Joel is right for the wrong reasons. You're wrong in some  
>> details, too:
>
> This post by Bill de hÓra says some things that I wish I had thought  
> of (and some other things that are more questionable, with respect to  
> the usefulness of OOP):
>
> http://www.dehora.net/journal/2005/12/ 
> difficult_v_hard_as_opposed_to_java_v_c.html

0. He agrees with Joel on recommending The Little Schemer.

> In particular, it points out that Java opens up new teaching avenues,  
> such as multithreading or distributed programming.  You can do those  
> things in C as well, but not without pulling in a lot of target system  
> dependencies.

1. My "312" (transl. 670) introduces distributed programming and I wish  
I could do more. It's difficult and hasn't gotten easier with the new  
languages over the past 30 years. I proposed adding more to the  
curriculum (specifically one course) because I find it critical. But  
Will appears to think we can do enough within the existing framework of  
courses (370 followed by 670).

2. Ditto and harder for concurrent programming.

3. It's clearly a great research topic for language people who want to  
make it big. Starting reading an enormous list of papers and books. Go  
back to Dan's Coordinated Computing and further.

4. Is it a good measure for distinguishing good from bad programmers?  
No, because it is so difficult that only people with tremendous  
training can do it well. When you pose extraordinarily difficult  
questions, you will fail everyone. Given the state of affairs, most  
students from most places won't have enough background here to do well.

5. Having said that I still think that Joel should ask about recursion  
in Java. Most kids don't understand that Pure OOP forces recursion on  
you.

> I'm not saying that we should be putting those topics into the 1st  
> year curriculum.  But I think this supports my thesis: if you want to  
> test the Java programmers, you should shift your interviewee testing  
> strategy, rather than adopting the cop-out of "Java's too easy."

As 5 suggests, I agree with you to some extent. But I also disagree  
especially with respect to pointers and unsafe software. If you don't  
teach what's going on there, you can't even ask the question.

All said and done: I think I am closer to Bill's position than you.

-- Matthias

P.S. I sent email to Joel and he implied that he wants to provide cover  
for teaching C and FP/Scheme. Strange combination but hey it serves me  
well :-)