Hacker News Reader

Comment by j_baker | Hacker News Reader

"IMO, Python is farther away from the Lisp genotype than Java. At least Java has post-1980's scoping rules."

1) Why do I need post-1980's scoping rules? I don't seem to recall any huge advances in variable scoping being made since then.

2) Comparing Python and Java's scoping is like comparing apples and oranges. Python is a dynamically typed language where everything is built at run time while Java is a statically typed language where everything is built at compile time.

I can't help but think of these kinds of blog posters of being a kind of anti-Guido van Rossum: smart, knows a lot about their domain (but with functional programming instead of object-oriented programming), but makes absolutely stupid assertions about other schools of thought they know nothing about (but with object-oriented programming instead of functional programming). Do we really need to destroy other peoples' way of doing things to feel good about our way of doing things?

View on HN

Except he doesn't know his FP, e.g. he doesn't know about TCO and how you can use that to avoid having recursion blow the stack.

WRT to 2, your scoping discipline is pretty orthogonal to your typing discipline. E.g. dynamically typed mainline LISP was dynamically scoped before Common Lisp adopted Scheme static scoping. And I'm sure there are dynamically scoped statically typed languages out there (if I ever learned about one, I would have tried to forget it as soon as possible (worst of both worlds)).

Finding a dynamically scoped statically typed language would be quite a trick: dynamic scope doesn't seem to have caught on outside the Lisp community. (I remember reading academic papers (separately for C++ and Haskell) that tried to explain why you would even want dynamic scoping and "look, wow, here's how to implement it.")

It's obviously not statically typed, but Perl has dynamic scoping (and that was the preferred way to have a local variable in perl4, before lexically scoped vars were introduced in perl5).

Whether perl is part of the lisp community is another matter :-)

Exactly - his point is that he doesn't care how map is implemented but really it should be a matter of not caring how recursion/tco is implemented so long as it does not blow the stack.

"Do we really need to destroy other peoples' way of doing things to feel good about our way of doing things?"

No, but it's a valid concern that if you don't, you'll be stuck programming in it when it becomes popular (Java, Python, PHP, ...).

> but makes absolutely stupid assertions about other schools of thought they know nothing about (but with object-oriented programming instead of functional programming)

Tail calls need to be in object-oriented languages too.

Says Guy Steele in "Why Object-Oriented Languages Need Tail Calls" (http://projectfortress.sun.com/Projects/Community/blog/Objec...).

(Just to provide your claim with some supporting arguments.)

Thanks.

I was trying to be funny by making a ridiculous claim without "knowing anything." I guess it didn't come off as funny. :)

The following comment from Matthias Felleisen at the page is especially interesting: (http://projectfortress.sun.com/Projects/Community/blog/Objec...)

>> Thank you, Guy, for emphasizing the importance of proper tail-call implementation (let's call it PITCH here) for software design and refactoring. When I delivered my | ECOOP keynote in 2004, I made the PITCH point slightly differently using the | Design Patterns book. I developed some code using the patterns from the book in Java. I requested and received confirmation that the code was truly OO oriented and truly according to Their Book. Then I tested it and it worked fine. Then I stress-tested it (on a not so large input), and it failed with stack overflow.

>> The next step was to demo the same code in the | PLT Scheme class system, which looked very similar to the Java code. And it ran great on those stress tests and even larger ones. So I asked the 300-400 people in the audience what the problem was and why this slow, interpreted language Scheme did it right and Java, C#, Eiffel, Python, etc got it wrong.

>> Not one person had any insight so after a minute of playing with them, I told them about the story of "Smalltalk to Actors to Scheme and how PITCH had 'come along for the ride'" (you may recall our email exchange in the spring of 2004 to confirm the story of 'apply'). And I did reinforce how much knowledge the OO research community has forgotten over the years.

>> Sadly, the reaction was surprisingly hostile from some corners in the room. One person was especially outspoken in arguing that we all know that we just need three or four special constructs -- and they may have to be map or for-each or such -- and we'd be in business. Given that it was a public exchange, it was difficult to point out to him how messed up his argument was.

>> While I have received many positive emails about the talk (my slides are on-line and people find them time and again), this message about PITCH deserves to be repeated and repeated and repeated for OO audiences. Let's keep going at it.

Reply on news.ycombinator.com