A Ruby Illustration of Lisp Problems

perm url: http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html

A Ruby Illustration of Lisp Problems

Xah Lee, 2009-01-17

Here's a interesting toy problem posted by Drew Krause to comp.lang.lisp:

OK, I want to create a nested list in Lisp (always of only integers) from a text file, such that each line in the text file would be represented as a sublist in the 'imported' list.

Example of input

3 10 2
4 1
11 18

example of output:

((3 10 2) (4 1) (11 18))

Here's a emacs lisp version:

(defun read-lines (file)
  "Return a list of lines in FILE."
  (with-temp-buffer
    (insert-file-contents file)
    (split-string
     (buffer-substring-no-properties 1 (point-max)) "\n" t)
    )
  )

(mapcar
 (lambda (x)
   (mapcar
    (lambda (y) (string-to-number y) )
    (split-string x " ")
    )
   )
 (read-lines "xxblob.txt")
 )

The above coding style is a typical maintainable elisp.

In a show-off context, it can be reduced to by about 50%, but still far verbose than ruby or say perl (which is 1 or 2 lines. (python would be 3 or 5)).


w_a_x_...@yahoo.com and William James gave a ruby solution:

IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}

That's really the beauty of Ruby.

This problem and ruby code illustrates 2 fundamental problems of lisp, namely, the cons problem, and the nested syntax pain. Both of which are practically unfixable.

The lisp's cons fundamentally makes nested list a pain to work with. Lisp's nested syntax makes functional sequencing cumbersome.

In the ruby code, its post-fix sequential notation (as a side effect of its OOP notation) brings out the beauty of functional sequencing paradigm (sometimes known as functional chain, sequencing, filtering, unix piping).

its list, like all modern high level langs such as perl, php, python, javascript, don't have the lisp's cons problem. The cons destroys the usability of lists up-front, untill you have some at least 2 full-time years of coding lisp to utilize cons properly. (and even after that, it is still a pain to work with, and all you gain is a bit of speed optimization in rare cases that requires largish data, most of which has better solutions such as a database.)

Both of these problems i've published articles on. For more detail on the cons problem, see the section “The Cons Business” at Fundamental Problems of Lisp.

For more detail on the nested syntax problem for function chaining, see the section “How Purely Nested Notation Limits The Language's Utility” at The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations.


Related essays:

Popular posts from this blog

11 Years of Writing About Emacs

does md5 creates more randomness?

Google Code shutting down, future of ErgoEmacs