Problems with Lisp

http://blog.jrock.us/articles/Problems%20with%20Lisp.pod

by jawngee • 17 years ago

23 37 17 years ago

blog.jrock.us

burke• 17 years ago

It's worth noting that Clojure has native support for hashes via the {} syntax. (http://clojure.org)

pmjordan5• 17 years ago

And hashtable lookups are possible by just function-calling the table itself with the key:

  => ({ :foo 1  :bar 2 } :foo)
  1

the common pattern of defaulting to a value if the key isn't found is easy too:

  => ({ :foo 1  :bar 2 } :baz 4)
  4

The above is a hash map, #{ ... } creates a hash set which otherwise has similar semantics. Sets, being function-callable, can be used directly for checking if something is one of a bunch of values:

  (if (#{301 302 303 307} response-code)
    ; we've been redirected

Maps and sets (you also have sorted maps and sets and a compact struct-map, all of which have identical semantics as the hash variants where appropriate) can additionally be used with most functions accepting a seq (list) or can be converted to a list explicitly using the seq function.

Basically, maps and sets really are first-class citizens in clojure. Some of the flexibility is down to the fact that Clojure is a Lisp-1: these features are therefore hard to replicate in CL. (and yes, hash tables also bothered me somewhat in CL, altough other things probably bothered me more)

whacked_new• 17 years ago

Something I find strange about hashes in Clojure, is that you can access them using the key as a function. So instead of

    ({ :foo 1  :bar 2 } :foo) ;; => 1

You get the equivalent by doing

    (:foo { :foo 1  :bar 2 }) ;; => 1

For default values:

    (:baz { :foo 1  :bar 2 } 3) ;; => 3

I vaguely remember this is because keys act as functions, and hashes act as functions as well. Out of habit and similarity to other languages, I never use the key-first notation, nor can I see where it is better to use it.

jrockway4• 17 years ago

Clojure definitely has nice data structures.

Does anyone do this sort of hash-table-as-function thing in Scheme?

jrockway4• 17 years ago

My article was actually a response to all of the "CL sucks, I'm switching to Clojure" articles I've read this week.

While Clojure is certainly a good language, I think people are "switching" to it from CL due to hype, rather than their deep understanding of the problems with CL. Clojure gives you a few nice features, like immutable data structures, "nicer" reader syntax, and JVM compatibility. In exchange, you give up CLOS in favor of Java's broken object model.

All I'm saying is that I don't think the popular community is really considering CL's advantages before switching, they are only considering the disadvantages. If you are going to consider disadvantages, it's important to keep in mind that Clojure has them too.

(Another often-cited reason for switching to Clojure is Java's libraries. In my experience working with Java, its libraries are pretty bad. Read the URLConnection class that comes with Java 6. It is clear that the API designer has no idea what OOP is, and it's clear that those implementing the library had no idea how to program. CL libraries, I've found, are usually better-done.)

But with that in mind, I really like Clojure. I have the occasional client that insists on JVM applications, and Clojure is significantly less painful than pure Java (or JRuby, or Scala). But it is not my first choice when the JVM is not a requirement.

weavejester• 17 years ago

Clojure provides several ways of interfacing with Java's object model, but generally this is just for compatibility purposes. The equivalent to CLOS in Clojure would be multimethods and hierarchies.

newt03113• 17 years ago

The problem is not the complexity of the api but how verbose it is. Having to type

    (setf (gethash "foo" *hash*) "OH HAI")

just for something as trivial as "hash['foo'] = "OH HAI"" is really too much work and a significant disincentive to using hash tables.

KirinDave3• 17 years ago

Setf is the generic form (and it's pretty cool how setf works). There are more succinct ways of putting it.

But you need to remember that functional languages discourage that kind of mutable state. It should be no surprise that some things (like assignment) are more awkward in that environment. It's a tradeoff.

newt03113• 17 years ago

Yes but lisp is not a functional language and (to my incomplete knowledge of CL) setf is the only way to modify the hash table. Thus, people have to use that form if they want to use hash tables.

jimbokun2• 17 years ago

In Arc that's

    (= (*hash* "foo") "OH HAI")

KirinDave3• 17 years ago

And in PLT Scheme it's

  (hash-set! *hash* "foo" "OH HAI")

jrockway4• 17 years ago

Seriously? This is a price I'm willing to pay for the symmetry setf buys me. In languges with = for assignment, you are stuck with what the language gives you. In Lisp, you are one "defsetf" away from perfect symmetry between reads and writes.

In addition, usually you are going to hide the hash-table. Instead of accessing it directly, you will probably have an interface like:

    (defvar *customer-cache* (make-hash-table :test equal))

    (defmethod add-customer ((customer customer))
        (cache-customer customer)
        (write-customer-to-database customer))

    (defmethod cache-customer ((customer customer))
        (setf (gethash (name customer) *customer-cache*) customer))

    (defmethod get-customer-by-name ((name string))
        (let ((maybe-customer (gethash name *customer-cache*)))
            (if maybe-customer maybe-customer
                (let ((c (get-customer-from-database-by-name name)))
                    (cache-customer c)
                     c))))

By the time you have more than a one-line example, the length of gethash is irrelevant. You are using your own "API" now:

    (add-customer (make-customer :name "jrockway" :email "jon@jrock.us"))
    (get-customer-by-name "jrockway")
    #<CUSTOMER JROCKWAY {10027D1401}>

Hexstream2• 17 years ago

Title should be "Perceived problems with hash-tables in Common Lisp"...

It's true that it would be interesting to have native syntax for hash-tables so you could read and dump them like you can lists and arrays and other stuff. Surprisingly the article doesn't even mention that which is the only real problem with CL's hashtables, aside from the inability to define arbitrary lookup mechanisms beyond eq, eql, equal and equalp...

silentbicycle2• 17 years ago

Having such a cumbersome syntax for hash tables is just as real a problem as the verbosity some Lisp programmers hold against e.g. Java.

One solution could be a read macro that translates into the (setf (gethash ...)) form. Lisp read macros are usually prefix, though, and [key]hash is awkward. OTOH, adding suffix read macros (maybe only of the form symbol[... values], e.g. hash[# key] or hash[: key], with brackets and char(s) at the beginning to represent which suffix read macro.

Or, making the hash a function: (hashname key) to get, (hashname key newval) to set.

jrockway4• 17 years ago

> Title should be "Perceived problems with hash-tables in Common Lisp"...

Good idea. Title changed :)

I decided not to bring up the printed representation, since other languages don't do much better. Perl will print either the keys and values with no spaces between them (by default), or something like "5/8" in scalar context, or "HASH(0x123456)" if it's a reference. No better than CL, and nobody complains about this :)

lgriffith2• 17 years ago

The issue is that there is no one solution for all problems and all contexts. ANY given language was written in response to a given set of problems in a given set of contexts. Change one thing to be outside that domain and the fit is less good. Change almost everything and the fit is a misfit.

For example: a 5 lb slege hammer is a very good tool for breaking rocks. Now fix a Rolex Watch with it. Its not so good of a tool, is it?

The answer is understand the problem and its context. Then select the tool that fits good enough (YMMV). Otherwise you will soon find yourself in a world of hurt and still not have a good solution to your problem.

I am sure Lisp has a problem set and a context set for which its a good match. Though I haven't found it yet but then I really haven't looked. The tools I use are good enough for the problems and contexts I have encountered in over 40 years of software development. Thus I have no reason to hammer my head against the rubber wall of Lisp as well as approximately 900 other languages.

Retric2• 17 years ago

Lisp is the best language for generating HTML, XML, writing compilers, or parsers.

PS: Lisp is more a family of languages that share features than it is a specific language.

chollida1• 17 years ago

> , writing compilers, or parsers.

I think the OCaml guys and the Haskell guys(Parsec) might take exception to this.

See: http://flint.cs.yale.edu/cs421/case-for-ml.html http://www.ffconsultancy.com/ocaml/benefits/parsing.html

It's not that CL is bad for writing compilers or parsers (I've written a few parsers using it), its just that blanket statements like "Lisp is the best language for ..." isn't always going to be true.

lgriffith2• 17 years ago

Hince my reference to good enough and rubber wall of Lisp. Lisp is not one thing. Its a collection of collections of things capable of being indefinitely morphed by itself. ANSI C is bad enough without those kinds of problems.

Incidentally I have written several efficient and effective parsers and compilers in both Pascal and ANSI C. I found them quite good enough. I have a hard time seeing Lisp as little more than a big brother to Forth. I see both of them as wonderful solutions to the wrong problems. At least to probelms I don't have nor want to solve.

Hexstream2• 17 years ago

40 years of software development? I can't help but laugh at your mentioning it as if it really means anything and makes your "arguments" carry more weight.

vikram3• 17 years ago

Lisp has support for {} syntax for hashes. It's just not built in. Use a reader macro.

gruseom2• 17 years ago

nickb posted this article a couple of hours earlier:

http://news.ycombinator.com/item?id=449240

The duplicate wasn't detected even though the urls, after submission, are identical. It turns out there's a bug (a corner case, really) in how duplicates are detected. Probably nickb put this in the Submit field:

  http://blog.jrock.us/articles/Problems with Lisp.pod

while jawngee used this:

  http://blog.jrock.us/articles/Problems%20with%20Lisp.pod

If you resubmit with the first string you get taken to nickb's submission, while the second takes you to jawngee's.

On another note, how many μStallmans of insensitivity would it take to notify pg of this triviality the day after the birth of his first child?

scott_s• 17 years ago

μStallmans? I love it. Your concept, or did you steal it?

gruseom2• 17 years ago

Alan Kay famously said "Arrogance in computer science is measured in nanodijkstras." (http://www.youtube.com/watch?v=s7ROTJKkhuI). To which someone wittily answered, "And microkays".

Problems with Lisp

Related Stories