3 ms·

So you thought the version written in a language you're familiar with was more readable than the version written in a language you're not familiar with? But se

So you thought the version written in a language you're familiar with was more readable than the version written in a language you're not familiar with? But seriously, take a look at the two examples again. Are you really suggesting that the Lisp version is easier? All you have to understand for the Awk example how field variables work, then you can read the whole thing at a glance. The Lisp version contains custom macros and is four lines long!

rayiner 15y ago
For someone who doesn't know either, but is familiar with programming generally, which is more readable? I can guess what 'with-lines-from-file' does, I can guess what 'string-split' does, i can guess what 'string=' does, etc. The only thing I might not understand is 'aref'. With the AWK example, I have no place to start. Symbol-oriented languages, rather than word-oriented languages, are like that. They tend to be more concise for things very specialized tasks, like this, but that limits their generality. Show me a matrix multiplication routine in AWK versus Common Lisp.
- KaeseEs 15y ago
  I think you're agonizingly close to the point the author is quoting Peter da Silva as trying to make in your last paragraph here. Roughly sketched - 1) text and file processing are very common tasks 2) Lisp is not especially suited at these tasks, though it is very well suited for some other tasks. 3) If a dialect of lisp more suited to these very common tasks were made, it would increase the popularity of Common Lisp for the tasks that it works well for by familiarizing people with it.
- wanorris 15y ago
  It is both strictly correct and irrelevant to the topic at hand that the Lisp is easier to read. Because that's like saying "Lisp sucks because WTF does 'cddadr' mean anyway?" AWK is a purpose-built language for splitting lines into fields and doing stuff with the result, so of course there's not a lot of boilerplate for splitting lines into fields and doing stuff with the results. Lisp for doing a lot of fancy work with s-expressions is going to be high density code that's a lot harder for newcomers to read than verbose, plodding Java code that is working with a simple LinkedList class or something. Readability (Edit: to newcomers) just isn't the relevant benchmark here.
  - tikhonj 15y ago
    I don't think a linked list in Java is a good example. I took two CS intro courses in a row last year; the first one used Scheme and the second one concentrated on data structures and used Java. There were some completely inexperienced people taking the two courses along with me. As far as I could tell they had much more difficulty with linked lists and trees in Java, which made them needlessly complex, than they did in Scheme. And this is with people who had actually learned about both concepts first in Scheme, so they had more experience when they came to Java.
    - wanorris 15y ago
      Fair point. Perhaps I picked a bad example. At the same time, if you were writing a bunch of random awk-like one-offs as part of your normal lisp workflow, you wouldn't write 4 lines of code every time, right? You sit down and write some functions or macros that condensed it into something simple that allowed you to easily specify things like a split token, one or more filter-on fields and values (or better, a filter lambda), and one or more output fields, I bet. Because it's silly to write several lines for something you do a lot. And while you might call it process-file-and-return-matching-results or something, the interface to the result might not be so different from the line of awk in the original post.
sixbrx 15y ago
Never said I was familiar with Lisp, I've written more things in AWK (years ago)though not much and I don't use either at all anymore. Like another poster mentioned, the lisp at least has recognizable functions, and an easy syntax structure which is easy to remember across infrequent visits to the language. AWK is so specialized and irregular, I'd have to consult a reference to do simple things even (and not just to lookup function names which is quick), which is why I eventually stopped using it. Another reason to not use it is that it doesn't adapt readily to a problem that ends up being more difficult than first thought, or one that has additional requirements added. I've often regretted doing programming in specialized mini-languages (and I'd include bash in that category too), when requirements were added that made me wish I'd used a full power language from the start, like Python, so I wouldn't have to rewrite. I've used awk here and there, and like programming in bash, I find it so irregular that I have to consult the manpage for simple things.

rayiner 15y ago

For someone who doesn't know either, but is familiar with programming generally, which is more readable? I can guess what 'with-lines-from-file' does, I can guess what 'string-split' does, i can guess what 'string=' does, etc. The only thing I might not understand is 'aref'. With the AWK example, I have no place to start. Symbol-oriented languages, rather than word-oriented languages, are like that. They tend to be more concise for things very specialized tasks, like this, but that limits their generality. Show me a matrix multiplication routine in AWK versus Common Lisp.

KaeseEs 15y ago
I think you're agonizingly close to the point the author is quoting Peter da Silva as trying to make in your last paragraph here. Roughly sketched - 1) text and file processing are very common tasks 2) Lisp is not especially suited at these tasks, though it is very well suited for some other tasks. 3) If a dialect of lisp more suited to these very common tasks were made, it would increase the popularity of Common Lisp for the tasks that it works well for by familiarizing people with it.
wanorris 15y ago
It is both strictly correct and irrelevant to the topic at hand that the Lisp is easier to read. Because that's like saying "Lisp sucks because WTF does 'cddadr' mean anyway?" AWK is a purpose-built language for splitting lines into fields and doing stuff with the result, so of course there's not a lot of boilerplate for splitting lines into fields and doing stuff with the results. Lisp for doing a lot of fancy work with s-expressions is going to be high density code that's a lot harder for newcomers to read than verbose, plodding Java code that is working with a simple LinkedList class or something. Readability (Edit: to newcomers) just isn't the relevant benchmark here.
- tikhonj 15y ago
  I don't think a linked list in Java is a good example. I took two CS intro courses in a row last year; the first one used Scheme and the second one concentrated on data structures and used Java. There were some completely inexperienced people taking the two courses along with me. As far as I could tell they had much more difficulty with linked lists and trees in Java, which made them needlessly complex, than they did in Scheme. And this is with people who had actually learned about both concepts first in Scheme, so they had more experience when they came to Java.
  - wanorris 15y ago
    Fair point. Perhaps I picked a bad example. At the same time, if you were writing a bunch of random awk-like one-offs as part of your normal lisp workflow, you wouldn't write 4 lines of code every time, right? You sit down and write some functions or macros that condensed it into something simple that allowed you to easily specify things like a split token, one or more filter-on fields and values (or better, a filter lambda), and one or more output fields, I bet. Because it's silly to write several lines for something you do a lot. And while you might call it process-file-and-return-matching-results or something, the interface to the result might not be so different from the line of awk in the original post.

sixbrx 15y ago

Never said I was familiar with Lisp, I've written more things in AWK (years ago)though not much and I don't use either at all anymore. Like another poster mentioned, the lisp at least has recognizable functions, and an easy syntax structure which is easy to remember across infrequent visits to the language. AWK is so specialized and irregular, I'd have to consult a reference to do simple things even (and not just to lookup function names which is quick), which is why I eventually stopped using it. Another reason to not use it is that it doesn't adapt readily to a problem that ends up being more difficult than first thought, or one that has additional requirements added. I've often regretted doing programming in specialized mini-languages (and I'd include bash in that category too), when requirements were added that made me wish I'd used a full power language from the start, like Python, so I wouldn't have to rewrite. I've used awk here and there, and like programming in bash, I find it so irregular that I have to consult the manpage for simple things.