Skip to content

Comment on Translating mathematics into code

Comments

Nice to see this.

I'm convinced, from long experience, from long experience, that functional collections are stylistically superior to imperative collections, even in otherwise imperative code.

In fact I'd go so far as to say that the worst mistake van Rossum made in designing Python was not to use functional collections. Then we wouldn't need to discuss how to copy them: http://news.ycombinator.com/item?id=3201033 There also wouldn't be this bug where using an empty list as the default value of an optional parameter would do the wrong thing (the same list object is reused on subsequent calls, when it is no longer empty).

(Yes, I understand, Python does have functional sets, but not AFAICT functional sequences or maps.)

It's great to see that Rich Hickey has designed Clojure around functional collections. I'm sure he'll do more for the cause than my own FSet library for Common Lisp, but I'll plug the latter anyway: http://common-lisp.net/project/fset/

> There also wouldn't be this bug where using an empty list as the default value of an optional parameter would do the wrong thing (the same list object is reused on subsequent calls, when it is no longer empty).

That's not a consequences of not using "functional collections" - lisp has non-functional collections, yet the empty list doesn't have that behavior.

Note the difference between "an empty list" (correct for python) and "the empty list" (correct for lisp). That reflects a design decision that has consequences. Neither is superior in all circumstances.

In some sense, this is an instance of an overloading error. Python's lists aren't lisp's lists and there are many other definitions.

I have found it handy to make a 'frozendict' type in Python, though my implementation scales horribly -- I'm not usually worrying about efficiency. I wish a good one were built in, too.

Re functional sequences, there's tuples.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.