[racket-dev] my '312' this semester, how we compare to others

[ In case you don't know: since the late 90s, I have been teaching a course dubbed software dev every so often. Students choose their favorite language, I choose the project, they program, I program in Racket and in DrRacket (and strictly). Over the semester the students code-walk their projects in class and the 'finals' are two-hour code walks with 'stress tests' of their servers working with my clients and vice versa. This gives me some idea of what languages contribute to the standard of programming and what's out there. ]

***** OBSERVATIONS from this year's '312', starting with some background: 

(1) this is the first year the course was open to MS students and limited enrollment only. So I ended up with 10 MS students and 6 undergraduates. 
(2) I saw much less variety than usual. 
(3) two undergraduates started with Racket but due to team rotations they ended up with Java partners. 
(4) all MS students fell back into their Java/Eclipse monoculture after having seen Racket/DrRacket in the Bootcamp course for MS students. 
(5) one pair chose Python 
(6) one pair chose C++, and lo and behold, this is the first time in 14 years that the C++ pair survived the course. 

On local basis (ten lines here, ten lines there), the C++ and Python code looks as good as Racket code. 

Java looks worst. Period. 

I stuck to Racket's OO world, and I will say that I mostly enjoyed this. 

Racket didn't provide me with much of an advantage anymore. I did benefit from mixins (twice), custodians (once), proper contracts (huge win) and my first large-scale use of rackunit (another large win). If I had remembered logging in Racket, I would have saved myself 40 lines of code and 2 hours of debugging. Higher-order functions and macros played very minor roles. This is possibly due to my choice of project. (Look for Ingenious board game; distributed; variations on the rules) 

Bottom line here: My code implements more features, is easier to read, has many fewer bugs, I am more productive than anybody in there. But it's my personal skill set (with Racket) not the language features that give me most of the advantage. 

;; --- 

Let's get to what I learned about how others live and where we fail: 

***** PROBLEMS WITH DRRACKET: compared to the Eclipse-Java monoculture, DrRacket suffers from three major problems as far as I am concerned as a program designer: 

-1- Eclipse performs 'check syntax' in an on-line fashion. If you are reading a piece of code, and you wish to jump to the definition of some method you're calling, click and you jump. 

-2- Eclipse autocompletes all the time and in a highly convenient manner. 

-3- Eclipse displays tooltips on ids with relevant docs. It makes it trivial to learn the APIs and to recall what your own methods do (assuming your types and your purpose statements contain the proper information). 

DrRacket/Racket is superior to Eclipse in two regards: 

+1+ Contracts are properly integrated into our tool chain. They are comments and or strings in the rest of the world. 

+2+ My discipline of using define/provide-test-suite enabled me to keep interfaces narrow and tests accurate and called properly. 

***** PROBLEMS WITH RACKET: our performance suffers from two problems. 

-A- I demanded that students deliver their functionality via Unix shell scripts, and so I did so too. My tcsh scripts check the argument number and pass the arguments on to Racket. Firing up one of my clients or servers takes several seconds. All other language implementations appear to bring up their servers or clients instantaneously. 

-B- When it comes to raw computational performance (ignore loading Racket, start from REPL and run a single game -- 10 seconds), my implementation is faster than Python (but barely) and one of the Java implementations. But one Java implementation is 10x faster. My hunch is that our OO system is significantly slower than Java's because we lack types to reduce dispatch overhead. Then again I might be wrong. -- Another possibility is that my extremely heavy use of our wonderful (!) contracts may impose a large overhead. I use mostly ->i and ->m. 

;; --- 

So this is the view from the frontline. I am equally delighted and frustrated this year -- Matthias