Guido on Functional | Hacker News Reader

Guido on Functional

fold.sigusr2.net

34 pointsapgwoz34 comments

As much as I like Python, Guido has repeatedly demonstrated a pretty fundamental lack of understanding when it comes to functional programming concepts (I'm thinking in particular of past HN discussions regarding his confusion about the difference between tail calls and tail recursion). While it's entirely appropriate to take the stance that Python should not become "more functional" (whatever that means), it's not appropriate to do so without a clear understanding of what you're talking about.

For the record, here's a link to the Haskell Prelude version of reduce, aka, foldr. Looks like "a few lines" to me...

http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0...

In looking at that, I was surprised to see that the foldr/build deforestation technique is still in use. That was part of my advisor's PhD work from the mid 90s.

If I had to guess, he thinks this way because he isn't yet used to thinking about space-free tail calls. In that sense, he's correct -- you really couldn't create a usable reduce if the function grew linearly in the size of the list. However, this is not a restriction that we actually face.

It amazes me how some programming language authors seem to be clueless about really major areas of our field.

If I ever were to design a language, it would only be after studying all of the various interesting programming languages. How else can you be certain that you aren't doing something that hasn't been done before?

Just be glad Guido knows how to write a parser.

Be glad the author of a major programming language has the decency to read Levine and the first 3 chapters of the dragon book?

O industrial PL designers, how easily we let you off the hook.

I think the guy who had the misfortune to create newLisp caught more flack than Guido, Matz and Larry combined.

If you want a lot of people to hate your language, name it "somethingLisp". The CL people will hate you because it's not CL, the Scheme people will hate you because it's not Scheme, and everyone else will hate you because it has parentheses.

ISLisp.

Find anyone who hates it :-)

This is another standardized Lisp that even Common Lispers and Schemers respect. The ISLispers were the Trotskyists persecuted by the DoD backed CL Stalinist politburo. They had a beautiful Lisp that reconciled all the Lisp differences without sacrificing good taste. However, it was a high-level design that left too many details to the whims of implementers, and would have been impossible to stay compatible to without active and deliberate cooperation.

There you have it. And I must go now to board a chopper to to an Alaskan rehab/work program for my reactionary accusations against the U.S. Department of Defense, and the venerable X3J13 ;-)

EuLisp may have a similar story?

Yes; ISLisp was an international effort (EU + JP + some U.S. delegates) while EuLisp was purely European (France and UK.)

Also, EuLisp is a more divergent dialect, and even more ambitious than common lisp; it had ML style modules, continuations via let/cc, generic LAMBDA (yes, first class anonymous methods!) full support for TCO and other goodies. EuLisp was an ideological successor to LeLisp (which was ancient and fugly) and I consider both the academic dabblings of one Christian Quinnec, Lisp designer extraordinaire.

If that always happened, there would be almost no new langs ever.

Again: definition of a gentleman computer scientist: Some one who knows enough to write a new programming language, but doesn't.

It amazes me how some programming language authors seem to be clueless about really major areas of our field.

Guido isn't the only one. Andrew (the submitter/author of this post) once told me a story of how Brian Kernighan told him Scheme had too many parentheses and is too strange and functional to be useful (take that with a grain of salt - it's a paraphrase of a paraphrase). I've also yet to see any non-Smalltalker/Erlanger language author understand the importance of OOP in the sense of creating encapsulated objects which can be hot-swapped at will. As far as I can tell, this was the point of OOP as Alan Kay saw it. Java-style "reload the VM to reload objects" being called OOP is just painful.

"It amazes me how some programming language authors seem to be clueless about really major areas of our field."

I saw Larry Wall speak within the last year or so about Perl 6. His presentation on the stuff inherited from Perl 5 was solid, but when he started talking about the other things that were more functional and/or "like Haskell", there was a marked change in his confidence and depth of description. I saw him go to dinner with some people organizing the talk and when asked about what other languages he had studied besides Perl, I recall his answer was something along the lines of "well, lots of Perl is written in C." I came away with the impression that he didn't study other languages in order to improve Perl, and the more functional stuff in Perl 6 was coming from somewhere else.

I've talked with Larry about Pugs. He knows Haskell.

I came away with the impression that he didn't study other languages in order to improve Perl....

That's an unfortunate impression. I've worked with Larry for several years, and he's most assuredly a polyglot, as are many of the other Perl 6 developers.

Guido is exactly right. reduce is one line of code, not "a few" lines of code.

SICP defines fold-right in 5 lines, so I'd rather say he's just wrong.

The Haskell 98 Report takes two lines:

    foldr f z []     =  z
    foldr f z (x:xs) =  f x (foldr f z xs)

Clojure does it like this (note the overloading - this is both "foldl" and "foldl1" in Haskell terms): http://github.com/richhickey/clojure/blob/49a7d6b8e14050a45d...

To be true, it's customary that you also add a line for the types in Haskell. Though not necessary.

Couldn't we do this?

r' f (x:xs) | xs == [] = (f x):[] | otherwise = (f x):(r' f xs)

or:

[(f a) | a <- myList]

- another edit -

r' f (x:xs) | xs == [] = x | otherwise = f x (r' f xs)

That's map, not reduce.

Well, to be really fair, most of the people I've seen trying to prove him wrong ended up implementing it as, basically, "let my_reduce = reduce", or something similar but obfuscated enough to make it not look completely tautologous. Which is really the point: a lot of the modern FP languages make folds and other similar constructs so fundamental to the language ("primitives" in terms of the quote) that it can be difficult -- either due to mindset or due to the language itself getting in the way -- to drop down a level or two on the abstraction ladder and try different approaches.

(and the fact that everybody who hasn't implemented a tautologous reduce has basically used the same tail-recursive algorithm lends a bit more support to this theory)

The more I think about it, it's just another expression of the old "when all you have is a hammer" aphorism. Guido's being yelled at and called names not because he's wrong or because he's stupid or doesn't understand what he's talking about, he's being yelled at and called names because the "hammer" in this case -- functional programming -- is a bit of a sacred cow, and a lot of people get really defensive about it.

Fold/reduce is not a primitive in Clojure, Erlang, Haskell, SML, Mercury, or any other functional language I know (though it is a standard library function in all of them). Do you have any counter-examples?

Of course all functional programmers write the same tail-recursive implementation of "reduce." That's like observing that everyone uses a loop to implement "reduce" in an imperative language. It's the simple, straightforward way to do it. (And since folds are trivially implemented in any functional language with tail recursion, why would the language designer include them as a primitive?)

I took "primitive" to mean not only language syntax, but built-in functions which are so fundamental to programming in a given language that it's difficult to escape them. For, say, Haskell, that's quite true of folds.

I don't think it's true in Haskell at all. A fold is just walking a list with an accumulator. That's not weird or low-level; it's as common for Haskell programmers as loops and variables for C programmers. It actually took me a while (when first learning SML and Scheme) to realize I could use the built-in reduce functions more, instead of writing loops "by hand" all the time.

It's also very common in Haskell to implement your own fold for various reasons. For example, in a simple 50-line text processing script[1], I defined a fold for a list-of-trees data structure without calling any builtin fold function[2].

[1]: http://github.com/mbrubeck/outline-grep

[2]: http://github.com/mbrubeck/outline-grep/blob/master/OutlineG...

P.S. I like your blog, and huge thanks for Django!

Actually, a fold is walking a Foldable with an accumulator :)

Guido works at Google. I wonder if Google is looking at functional languages like Clojure.

Google is large enough that I assume they keep an eye on every language of note. As I understand it, they use a number of different languages for their various needs.

Google is not the homogeneous or coherent; IMO, they've transcended languages by standardizing on communication protocols, which are far more important.

A bit like Facebook does with Thrift?

Hah! Thrift is a knockoff of an older Google technology called Protocol Buffers, which is also open source.

Take a look for yourself.

Odd, I'm fairly sure everything facing customers had to be Python, Java or C.

Reply on news.ycombinator.com