Hacker News new | past | comments | ask | show | jobs | submit login
Response to: Problems with Lisp (gnuvince.wordpress.com)
13 points by mqt on Jan 26, 2009 | hide | past | favorite | 7 comments



I lurched to a halt at this:

  # Would you rather type this?
  oldest({"Vincent": 25, "Lincoln": 200})

  # Or this?
  (let ((ages (make-hash-table :test 'equal)))
    (setf (gethash "Vincent" ages) 25)
    (setf (gethash "Lincoln" ages) 200)
    (oldest age))
No one who understood CL would ever write the latter. They would write:

  '((Vincent . 25) (Lincoln . 200))
... which, yes, I would rather type.

It would be surprising if during the 50-year evolution of a language known for code ≈ data, people hadn't thought of a notation for literal key-value pairs.


That's somewhat begging the question, though. Assoc lists aren't hash tables, do not have the performance characters of hash tables, and excepting simple circumstances, cannot be used like hash tables. Now, many Lisps and Schemes have something similar to

    (hash-from-list '((Vincent . 25) (Lincoln . 200)))
but that's still a far cry from having a literal hash table syntax à la Clojure or similar languages.


It's not that tough to make a literal syntax for hash tables with a simple reader macro. This may not be the best way to do it, I'm rather new to lisp, but it only took me about 5 min. (and a peek at "ANSI Common Lisp" 14.3, thanks, PG!):

    (defun ins-hash (h vals)
      (if (oddp (length vals))
          nil
          (if (not (null vals))
              (progn
                (setf (gethash (first vals) h) (second vals))
                (ins-hash h (cddr vals)))
              h)))

    (set-macro-character #\} (get-macro-character #\)))

    (set-dispatch-macro-character #\# #\{
      #'(lambda (stream char1 char2)
          (let ((items (read-delimited-list #\} stream t)))
            (ins-hash (make-hash-table) items))))

    CL-USER> (gethash :b #{:a 1 :b 2 :c 3})
    2
    T


I don't think it's begging the question. People use the term "hashtable" in a general way to subsume all kinds of associative lookup nowadays. A true hashtable is hardly the best way to represent '((Vincent . 25) (Lincoln . 100)). Your "simple circumstances" happen to be the overwhelming majority of cases one is working with this kind of literal data.

I use alists and hashtables all the time in CL. They're not intended for the same things, and I rarely convert between them.

There are two kinds of CL annoyance: the things that people who use the language to do real work are annoyed by, and the things that people who've dabbled with it enough to write ill-informed blog posts about why they don't want to use CL -- a conclusion they almost certainly started with -- are annoyed by. JRockway, incidentally, has been using CL for a while. He made the mistake, I guess, of attempting to explain something substantial about it to critics who haven't.

Edit: let me say something positive to counteract the Naggumification I seem to be undergoing in responding to these posts. If Clojure attracts the masses because it's shiny and not old like stinky CL, and in order for that to happen people need to convince themselves that hashtables which behave like immutable conses are really the killer feature that Lisp has been lacking all these years, and the net result of all this is lots more people using Lisp, I think that's great.


I may be entirely wrong here... but doesn't that create a tree of cons cells (more concretely a list of tuples) instead of a true hash-table?

Would (gethash ...) work on the created structure in constant time?


That's the point, it's not a hash table -- it's an association list. People don't just use them because they're easier to write, they have nice functional characteristics.

(Yes, hash tables are better for many things. I liked the #{} hack, actually.)


The problem with all of the syntax arguments is that they give away something significant to get something almost meaningless.

Accessible syntax is important. However, accessible doesn't mean/imply/require terse or specialized. Moreover, accessibility by programs is also important.

I know some amazing programmers but I've never met one who could write code, let alone good code, faster than a code generator.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: