the collapse of /prog/

With the heresy of Abelson, a plague of threads and individual posts have come out attacking the cornerstone of /prog/, the Structure and Interpretation of Computer Programs.  While I do not go so far as to condemn our lost brothers, now walking the road of enterprise programming, I fear for the future of this board.  While there are and always will be others, here is one of the keenest sites of public discussion on computer science.  The work our collective spent on BBCode has greatly expanded the understanding of programming paradigms; the groundbreaking discovery that Python contains, in one word, the forced indentation of code headed off what's now recognized as a potential disaster for the entire field; and perhaps most importantly, we've nurtured a new generation of programmers, analytic minded, creative, striving for satori. 

I don't know about you guys, but Sussman damn it I don't want to see this thing go.  So what can we do?

>>1
Lol
But Python is not enterprise programming. In fact, they had to create Zope to make Python half-enterprise. I'm confident Abelson will still teach proper programming, and remember Python's treatment of functions, even if it has its limitations(*), is as powerful as Scheme, and certainly better than that of Common Lisp and Ruby, in that it's like a Lisp1 and you can do f()()() all you want.

(*): And its limitations aren't severe. Mainly two: lambda cannot contain statements, so you have to use def (which cannot be used in an expression, and is not anonymous, but you can always use _ as a temporary name), and the lexical scoping problem that allows you to access and modify outer variables, but not rebind them with =, which is getting fixed in Python 3000.

Admittedly, these are pretty equivalent:

Scheme/BBCode:
(define (foldl f acc l)
    (if (null? l)
        acc
        (foldl f (f acc (car l)) (cdr l)))))

Python:
@tailcall
def foldl(f, acc, l):
    if l: return foldl(f, f(acc, l[0]), l[1:])
    else: return acc

Oh, and I'm working on a new, safe, efficient tail call optimizing decorator for Python using trampolines and no stack inspection or exceptions. It can be safely used on all existing code provided that it's tail-recursive (tail-call to different functions is supported too, and optimized even if not all of them are @tailcall). It could even help students by making them think on whether the function they're writing is tail-recursive or not.