Next Lisps | Hacker News Reader

Next Lisps

axisofeval.blogspot.com

29 pointsfogus20 comments

"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?

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.

> 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.

"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, ...).

I don't find Clojure all that ugly. I think it's tiny bit of extra "syntax" help make it much more readable. When I see [] I know I'm in a vector and when I see {} I know I'm in a map.

That's the main cultural difference between clojure and CL. Clojure wants to be a broad language with concrete syntatic support for many data structures. CL is a tall language with fewer syntax than data structures; you can have vectors in literal sytnax, #(1 2 3), but you can also create them explicitly:

   (vector 1 2 3).

Hashtables can only be created explicitly:

  (make-hash-table) then 
  (setf (gethash "one" *) 1)

but you're free to create your own syntax or shortcuts, which is what Alexandria provides:

  (hash-table-alist '(("one" 1) ("two" 2) ("three" 3)))

Also, except for popularity, Python didn't go anywhere as a language.

What sort of strange definition of progress is the author using for languages?

If, quoting him quoting Mark Tarver, Python is indeed "not new; its just a sugaring on the Lisp genotype in favour of a syntax that people feel comfortable with.", who then follows with a note on how far that got, it still "went somewhere", both in the adoption by so many of its interesting syntax and dragging people even closer to Lisp than the half-way that Steele said Java accomplished.

Where are languages supposed to go, anyway?

Didn't you know? To be a truly great language, you have to toil in obscurity like a tortured artist.

This guy sounds like the LoperOS fellow talking about Clojure, but after a margarita. http://www.loper-os.org/?p=42

Yeah, but the LoperOS guy has a serious point, one that will in fact be addressed after most of the Clojure that is written in Java is reimplemented in Clojure ("Clojure in Clojure"). From there one or more people with implement "Turtle Clojure" as I like to call it, turtles all the way down to the bare metal or OS or whatever.

It's the reason one of those "match a language to a picture" items had Clojure represented by Locutus of Borg, or as Reddit commentator pillsy put it, "Clojure is a terrifying meld of a beloved character and an unreasoning alien onslaught."

Whereas I didn't see much merit to this guy's Clojure comments. E.g. yep, Clojure is uglified by the syntax for maps and vectors, but the generalization this allows, by making them first class homoiconic data structures, is potentially worth it.

It is difficult for me to tell whether the author is joking at times or being serious; his arguments are lacking substance and the statements about Python are just silly.

I read the title and I thought of Perl 6.

Apart from that, the article is lacking substance.

Reply on news.ycombinator.com