[ 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


_________________________________________________
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Reply via email to