Re: reading file to list

Discussion in 'Python' started by Xah Lee, Jan 17, 2009.

  1. Xah Lee

    Xah Lee Guest

    comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.python,comp.lang.ruby

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

    ------------------------
    On Jan 16, 2:29 pm, Drew Krause wrote [paraphrased a bit]:

    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 a file's content

    3 10 2
    4 1
    11 18

    example of programing behavior
    (make-list-from-text "blob.txt") => ((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)
    )
    )

    (defvar mylist '() "result list" )
    (setq mylist '()) ; init in case eval'd again

    (mapc
    (lambda (x) (setq mylist
    (cons (split-string x " ") mylist )) )
    (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)).

    Note that the result element is string, not numbers. There's no easy
    way to convert them on the fly. 3 or so more lines will be needed to
    do that.

    The “read-lines†function really should be a built-in part of elisp.
    It is not so mostly because emacs people have drawn themselves into a
    elitist corner, closing off to the outside world. (i am sending a
    suggestion to the official emacs dev list on adding read-line now.)

    -----------------

    gave a ruby solution:

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

    augumented by Jilliam James for result to be numbers:

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

    Very beautiful.

    -------------------

    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
    http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

    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
    http://xahlee.org/UnixResource_dir/writ/notations.html

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 17, 2009
    #1
    1. Advertising

  2. Xah Lee

    Xah Lee Guest

    On Jan 17, 9:16 am, Xah Lee <> wrote:
    > Here's a interesting toy problem posted by Drew Krause to
    > comp.lang.lisp:
    > ...


    The code in my previous elisp code got a bump. It should be:

    (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) (split-string x " ") )
    (read-lines "xxblob.txt")
    )

    The article is now archived at:

    • A Ruby Illustration of Lisp Problems
    http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 17, 2009
    #2
    1. Advertising

  3. Xah Lee

    MRAB Guest

    Tino Wildenhain wrote:
    > Xah Lee wrote:
    >> comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.python,comp.lang.ruby
    >>
    >>

    > ...
    >> 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 a file's content
    >>
    >> 3 10 2
    >> 4 1
    >> 11 18
    >>
    >> example of programing behavior
    >> (make-list-from-text "blob.txt") => ((3 10 2) (4 1) (11 18))

    >
    >>
    >> 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)).

    >
    > So? Please count the lines:
    >
    > [line.strip().split() for line in file("blob.txt")]
    >

    The original requirement was for a list of lists of integers:

    [[int(x) for x in line.split()] for line in open("blob.txt")]

    Still only 1 line, though.
    MRAB, Jan 17, 2009
    #3
  4. Xah Lee

    Xah Lee Guest

    On Jan 17, 9:34 am, Xah Lee <> wrote:
    > The code in my previous elisp code got a bump. It should be:
    > ...
    > • A Ruby Illustration of Lisp Problems
    > http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html


    Sorry again. More correction:

    (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")
    )

    this is last post of correction.

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 17, 2009
    #4
  5. Xah Lee schrieb:
    > comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.python,comp.lang.ruby
    >
    > Here's a interesting toy problem posted by Drew Krause to
    > comp.lang.lisp:
    >
    > ------------------------
    > On Jan 16, 2:29 pm, Drew Krause wrote [paraphrased a bit]:
    >
    > 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 a file's content
    >
    > 3 10 2
    > 4 1
    > 11 18
    >
    > example of programing behavior
    > (make-list-from-text "blob.txt") => ((3 10 2) (4 1) (11 18))
    >
    > gave a ruby solution:
    >
    > IO.readlines("blob.txt").map{|line| line.split }
    >
    > augumented by Jilliam James for result to be numbers:
    >
    > IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}
    >
    > Very beautiful.
    >
    > -------------------
    >
    > 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.


    *Of course* Xah is wrong, as always.
    Who would expect anything else?
    In the Lisp style Clojure for example one does exactly the same as
    Jillian James (JJ) did in Ruby:
    (map #(map (fn (Integer/parseInt s)) (.split % "\\s")) (line-seq
    (reader "blob.txt")))

    This is slightly longer, simply because the functions have longer names.
    Integer/parseInt vs to_i

    Also the function split takes a regexp, so I have to add the "\\s" here.
    I don’t know though if Jillians version also handles any kind of
    whitespac per line.
    And the last thing is, that the function reader returns a BufferedReader.
    So in general this is more valuable in real programs as opposed to one-
    line scripts. If we combine line-seq and reader into readline and apply
    the two other changes we would say:
    (map #(map (fn (to_i s)) (.split %)) (readlines "blob.txt"))
    vs
    IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}

    So, obviously Xah is far away from any reality.
    It took him hours of his life to write up all his ideas about Lisp.
    Sad to see that all that time was wasted. All of it was wrong.
    Poor Xah :(


    And btw, Drew Krause is just a Lisp newbie. No Lisper would ever store
    data for his programs in the format
    3 10 2
    4 1
    11 18

    but instead as
    (3 10 2)
    (4 1)
    (11 18)

    And then read it back into the program with:
    (map read-string (line-seq (reader "blob.txt")))


    André
    --
    André Thieme, Jan 17, 2009
    #5
  6. Xah Lee

    Xah Lee Guest

    Xah Lee wrote:
    > • A Ruby Illustration of Lisp Problems
    > http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html



    On Jan 17, 12:30 pm, André Thieme <address.good.until.
    > wrote:


    > In the Lisp style Clojure for example one does exactly the same as
    > Jillian James (JJ) did in Ruby:


    > (map #(map (fn (Integer/parseInt s)) (.split % "\\s")) (line-seq
    > (reader "blob.txt")))


    Note that you have nested map. This is a problem of function chaning
    as i detailed.

    The other problem of cons, is commonly seen. Just about every week, we
    see some perhaps beginning lisper asking how to do various trivial
    list
    manipulation problem, which you don't see such question or frequency
    in any of modern high level lang forms.

    The frequently asked list manipulation question we see include how to
    append, prepend, or anything involving nested list such as
    partitioning, reordering sublists, getting leaves, interpretation of
    leaves, etc. This is caused by the cons.

    associated lisp problem compound the issue. Namely, the not exactly
    regular syntax, and the eval model of sometimes symbol sometimes
    uneval'd symbol, e.g. “'(...)â€, “`(...,@ ...)†things.

    The clojure example you gave above, apparently inherited the irregular
    syntax problem. (you see the #, [], % things, which is breaks the
    lisp's sexp idea) Also, all modern lisp basically all get fucked up by
    inheriting the cons (e.g. clojure, NewLisp, Arc lisp, Liskell). Often,
    they change the semantic a bit apparently as a mesaure towards solving
    the cons problem. (and Qi Lisp creates a huge bag of ad hoc, extremely
    ugly, syntax soup)

    Advice: if you are creating a lispy lang, two things:

    • stick to a _pure_ nested syntax, no exception whatsoever. (e.g. no
    more ` ' # % shits) If you want, add a transparent layer on top to
    support arbitrary algeraic notation. (e.g. look at Mathematica, CGOL)

    • get rid of the cons. (you can still implement the so-called linked
    list, but no where it should be shown to the programer)

    Further readings:

    • Fundamental Problems of Lisp
    http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 18, 2009
    #6
  7. Xah Lee schrieb:
    > Xah Lee wrote:
    >> • A Ruby Illustration of Lisp Problems
    >> http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html

    >
    >
    > On Jan 17, 12:30 pm, André Thieme <address.good.until.
    > > wrote:
    >
    >
    >> In the Lisp style Clojure for example one does exactly the same as
    >> Jillian James (JJ) did in Ruby:

    >
    >> (map #(map (fn (Integer/parseInt s)) (.split % "\\s")) (line-seq
    >> (reader "blob.txt")))

    >
    > Note that you have nested map. This is a problem of function chaning
    > as i detailed.


    Yes, Jillian also has nested maps:
    IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}


    > The other problem of cons, is commonly seen. Just about every week, we
    > see some perhaps beginning lisper asking how to do various trivial
    > list
    > manipulation problem, which you don't see such question or frequency
    > in any of modern high level lang forms.


    You see questions about trivial problems every week in all forums about
    programming languages.
    It has nothing to do with conses. Wrong road.


    > The frequently asked list manipulation question we see include how to
    > append, prepend, or anything involving nested list such as
    > partitioning, reordering sublists, getting leaves, interpretation of
    > leaves, etc. This is caused by the cons.


    Yes, same with all containers in all programming languages.


    > The clojure example you gave above, apparently inherited the irregular
    > syntax problem. (you see the #, [], % things, which is breaks the
    > lisp's sexp idea)


    My code used 8 “mysterious symbolsâ€:
    ( ) # [ ] . " %

    The Ruby version had these 7:
    ( ) | { } . "

    And of course, neither in Ruby nor Clojure they break any idea.



    > Also, all modern lisp basically all get fucked up by
    > inheriting the cons (e.g. clojure, NewLisp, Arc lisp, Liskell). Often,
    > they change the semantic a bit apparently as a mesaure towards solving
    > the cons problem. (and Qi Lisp creates a huge bag of ad hoc, extremely
    > ugly, syntax soup)


    Funny.
    What you write is an english text with words that most people can
    understand.
    You trick them into thinking that it actually makes sense what you say.
    It is so technical, that a random would believe it.
    But what you really say is about as meaningful as saying that it is
    impossible to write good programs in Python, because it adds whitespace
    to its syntax.


    > • Fundamental Problems of Lisp
    > http://xahlee.org/UnixResource_dir/writ/lisp_problems.html


    You wasted lots of your time. Or was this maybe generated by a bot?
    Maybe http://pdos.csail.mit.edu/scigen/ or something like that?
    I also found this paper that you wrote:
    http://apps.pdos.lcs.mit.edu/scicache/184/scimakelatex.7076.Xah Lee.html
    Another crap posting of you. But a random person might be impressed.


    André
    --
    André Thieme, Jan 18, 2009
    #7
  8. Xah Lee

    Xah Lee Guest

    a idiot wrote:
    > Yes, Jillian also has nested maps:


    the issue here, is not about whether Ruby has nested map or not. It is
    about illustrating a lisp problem. In particular, nested syntax
    impedes the functional programing paradigm of function chaining.

    • A Ruby Illustration of Lisp Problems
    http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html

    a idiot wrote:
    > My code used 8 “mysterious symbolsâ€:
    > ( ) # [ ] . " %
    >
    > The Ruby version had these 7:
    > ( ) | { } . "


    The issue here is not about which lang employs more special chars. The
    issue is about the irregularities in lisp's syntax damaged its power
    of its otherwise believed superior regular syntax.

    • Fundamental Problems of Lisp
    http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 18, 2009
    #8
  9. Xah Lee

    Xah Lee Guest

    On Jan 17, 10:25 am, Tino Wildenhain <> wrote:
    > > [[int(x) for x in line.split()] for line in open("blob.txt")]


    Nice (python code).

    Few comments:

    • the above code is borderline of atypical. e.g. it is not a average
    python code would produce or one'd seen in corporate python code.

    • voodoo like the above makes me dislike python. To me, the one
    advantage of python is its clarity enforced by its syntax.
    Specifically, the forced indendation and quite simple semantics.
    However, the way i've seen Guido's propensities and how python 3 is
    moving to, it is becoming more mumbo jumbo of computer sciency OOP
    jargons with syntax soup. (with iterators, enumerators, list
    comprehension... shits forced upon the users)

    The above line illustrate well the ad hoc syntax soup nature python is
    moving into.

    Further readings:

    • Perl-Python Tutorial: List Comprehension
    http://xahlee.org/perl-python/list_comprehension.html

    • Lambda in Python 3000
    http://xahlee.org/perl-python/python_3000.html

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 18, 2009
    #9
  10. André Thieme wrote:

    > Xah Lee schrieb:
    > > comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.pytho
    > > n,comp.lang.ruby
    > >
    > > Here's a interesting toy problem posted by Drew Krause to
    > > comp.lang.lisp:
    > >
    > > ------------------------
    > > On Jan 16, 2:29 pm, Drew Krause wrote [paraphrased a bit]:
    > >
    > > 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 a file's content
    > >
    > > 3 10 2
    > > 4 1
    > > 11 18
    > >
    > > example of programing behavior
    > >(make-list-from-text "blob.txt") => ((3 10 2) (4 1) (11 18))
    > >
    > > gave a ruby solution:
    > >
    > > IO.readlines("blob.txt").map{|line| line.split }
    > >
    > > augumented by Jilliam James for result to be numbers:
    > >
    > > IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}
    > >
    > > Very beautiful.
    > >
    > > -------------------
    > >
    > > 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.

    >
    > *Of course* Xah is wrong, as always.
    > Who would expect anything else?
    > In the Lisp style Clojure for example one does exactly the same as
    > Jillian James (JJ) did in Ruby:
    > (map #(map (fn (Integer/parseInt s)) (.split % "\\s")) (line-seq
    > (reader "blob.txt")))


    That fails when numbers are separated by more than one space.
    And what about leading or trailing space?

    >
    > This is slightly longer, simply because the functions have longer
    > names. Integer/parseInt vs to_i
    >
    > Also the function split takes a regexp, so I have to add the "\\s"
    > here. I don’t know though if Jillians version also handles any
    > kind of whitespac per line.



    irb(main):003:0> puts " foo \t bar "
    foo bar
    => nil
    irb(main):004:0> " foo \t bar ".split
    => ["foo", "bar"]
    irb(main):005:0> "foo...bar?-!hoo".split /\W+/
    => ["foo", "bar", "hoo"]


    > And the last thing is, that the function reader returns a
    > BufferedReader. So in general this is more valuable in real programs
    > as opposed to one- line scripts. If we combine line-seq and reader
    > into readline and apply the two other changes we would say:
    > (map #(map (fn (to_i s)) (.split %)) (readlines "blob.txt"))


    That is not a complete program.

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


    That is the complete program.

    >
    > So, obviously Xah is far away from any reality.
    > It took him hours of his life to write up all his ideas about Lisp.
    > Sad to see that all that time was wasted. All of it was wrong.
    > Poor Xah :(
    >
    >
    > And btw, Drew Krause is just a Lisp newbie. No Lisper would ever store
    > data for his programs in the format
    > 3 10 2
    > 4 1
    > 11 18
    >
    > but instead as
    > (3 10 2)
    > (4 1)
    > (11 18)


    Perhaps the data was stored by someone else. Understand?

    >
    > And then read it back into the program with:
    > (map read-string (line-seq (reader "blob.txt")))
    >


    You make a very strong case that Lisp is very feeble at
    processing data. I'm almost convinced.

    Ruby isn't feeble, so data like this is fine:


    shall we begin?
    or lotus135? 1984 times!
    The 3 stooges: COBOL,LISP,FORTRAN.
    3.14, si11y L00KING


    Extracting the unsigned integers:

    IO.readlines('data').map{|s| s.scan(/\d+/).map{|s| s.to_i}}
    ==>[[], [135, 1984], [3], [3, 14, 11, 0]]
    William James, Jan 18, 2009
    #10
  11. William James schrieb:
    > André Thieme wrote:
    >
    > You make a very strong case that Lisp is very feeble at
    > processing data. I'm almost convinced.


    I somehow don’t believe you :)


    > Ruby isn't feeble, so data like this is fine:
    >
    >
    > shall we begin?
    > or lotus135? 1984 times!
    > The 3 stooges: COBOL,LISP,FORTRAN.
    > 3.14, si11y L00KING
    >
    >
    > Extracting the unsigned integers:
    >
    > IO.readlines('data').map{|s| s.scan(/\d+/).map{|s| s.to_i}}
    > ==>[[], [135, 1984], [3], [3, 14, 11, 0]]


    Just take the program I posted before and replace
    (.split % "\\s")
    with
    (re-seq #"\d+" %)


    Now that I was so kind to give you what you asked for, you will
    probably do the same for me and show me your Ruby code, in which you
    define a variable that contains the Fibonacci sequence.

    (def fibs (lazy-cat [0 1] (map + fibs (drop 1 fibs))))


    (nth fibs 70) ==> 190392490709135

    One requirement is that when you look at the n'th fib the results up
    to n must be memoized, so that nothing needs to be calculated again
    when you ask for a fib between 0 and n. And when you ask for the n+1'th
    it will start the calculation right from point n.

    Example:
    user> (time (nth fibs 900))
    "Elapsed time: 16.898726 msecs"

    user> (time (nth fibs 901))
    "Elapsed time: 0.268603 msecs"


    André
    --
    André Thieme, Jan 19, 2009
    #11
  12. Xah Lee

    Rhodri James Guest

    On Sun, 18 Jan 2009 08:31:15 -0000, Xah Lee <> wrote:

    > On Jan 17, 10:25 am, Tino Wildenhain <> wrote:
    >> > [[int(x) for x in line.split()] for line in open("blob.txt")]

    >
    > Nice (python code).
    >
    > Few comments:
    >
    > • the above code is borderline of atypical. e.g. it is not a average
    > python code would produce or one'd seen in corporate python code.


    I can't imagine why not. It's clean and clear, after all. If I
    needed to do the slightly odd processing that it's written to do,
    the only change I'd make for production code is to wrap the file
    object in a 'with' statement.

    > • voodoo like the above makes me dislike python. To me, the one
    > advantage of python is its clarity enforced by its syntax.
    > Specifically, the forced indendation and quite simple semantics.
    > However, the way i've seen Guido's propensities and how python 3 is
    > moving to, it is becoming more mumbo jumbo of computer sciency OOP
    > jargons with syntax soup. (with iterators, enumerators, list
    > comprehension... shits forced upon the users)
    >
    > The above line illustrate well the ad hoc syntax soup nature python is
    > moving into.


    To a native English speaker, it illustrates entirely the reverse.
    List comprehension is actually quite a linguistically natural way
    to express the iterative construction of a list.

    --
    Rhodri James *-* Wildebeeste Herder to the Masses
    Rhodri James, Jan 20, 2009
    #12
  13. Xah Lee

    Xah Lee Guest

    On Jan 19, 4:49 pm, "Rhodri James" <>
    wrote:
    > On Sun, 18 Jan 2009 08:31:15 -0000, Xah Lee <> wrote:
    > > On Jan 17, 10:25 am, Tino Wildenhain <> wrote:
    > >> > [[int(x) for x in line.split()] for line in open("blob.txt")]

    >
    > > Nice (python code).

    >
    > > Few comments:

    >
    > > • the above code is borderline of atypical. e.g. it is not a average
    > > python code would produce or one'd seen in corporate python code.

    >
    > I can't imagine why not.


    consider code produced by corporations, as opposed to with respect to
    some academic or philsophical logical analysis. Looked in another way,
    consider if we can compile stat of all existing pyhton code used in
    real world, you'll find the above style is rarely used.

    in a logical analysis, each lang fanatics will actively sell certain
    style of construction, but that's just not the way code in the real
    world are. Ample examples can be found especially in other cultish
    lang groups such as lisp, perl, etc. (less of this phenomenon is found
    in lang like php, javascript, java, C, where the lang simple don't
    create fancy constructions in the name of improvement or esthetics or
    weird philosophy in the first place.)

    > > • voodoo like the above makes me dislike python. To me, the one
    > > advantage of python is its clarity enforced by its syntax.
    > > Specifically, the forced indendation and quite simple semantics.
    > > However, the way i've seen Guido's propensities and how python 3 is
    > > moving to, it is becoming more mumbo jumbo of computer sciency OOP
    > > jargons with syntax soup. (with iterators, enumerators, list
    > > comprehension... shits forced upon the users)

    >
    > > The above line illustrate well the ad hoc syntax soup nature python is
    > > moving into.

    >
    > To a native English speaker, it illustrates entirely the reverse.
    > List comprehension is actually quite a linguistically natural way
    > to express the iterative construction of a list.


    computer lang is not human lang. In argument based on human lang, you
    have AppleScript, Perl, which are un-readable or cumbersome to most
    programers. Even with human lang, if you know linguistics to some
    extend, you know that natural lang is a complete wortheless mess in
    every aspect with respect to “design†qualities.

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 20, 2009
    #13
  14. Xah Lee

    alex23 Guest

    On Jan 20, 1:39 pm, Xah Lee <> wrote:
    > consider code produced by corporations, as opposed to with respect to
    > some academic or philsophical logical analysis. Looked in another way,
    > consider if we can compile stat of all existing pyhton code used in
    > real world, you'll find the above style is rarely used.


    I've worked for several corporations that used Python and at -all- of
    them the developers were not only aware of list comprehensions, they
    used them regularly. Same with iterators. Not -one- of them found them
    to be "computer sciency OOP jargons" but useful metaphors that made
    their code more concise without sacrificing readability.

    Not everything new is crap, y'know. Neither is everything that you
    fail to understand the first time you're exposed to it.

    I find it kinda funny that you constantly criticise "academic"
    language development when it seems pretty clear from your posts that
    you've never actually engaged in any practical application-focused
    development in your life. But as they say: those that can do, those
    that can't post godawful screeds to their much-hyped-on-usenet vanity
    blogs...
    alex23, Jan 20, 2009
    #14
  15. Xah Lee

    Xah Lee Guest

    On Jan 19, 11:17 pm, alex23 <> wrote:
    ....

    Hi Daniel Weinreb,

    Xah wrote:
    > • A Ruby Illustration of Lisp Problems
    > http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html

    Daniel Weinreb wrote:
    > Xah Lee: Elisp is an interesting choice. But without converting the
    > strings to integers, it's not really right.


    i did post a correction quickly that includes the conversion to
    string/
    num. Here's the full code:

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

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

    > It's interesting that Elisp already has a style of reading in the
    > whole file, but no built-in to convert strings to integers, whereas
    > Common Lisp is the other way around.


    > The statement "It is not so mostly because emacs people have drawn
    > themselves into a elitist corner, closing off to the outside world" is
    > just a rude ad hominem attack.


    sure. In a political context, many criticism or description of the
    situation from one party can be seen as ad hominem attack. I feel that
    that many old emacs users, which includes significant portion of emacs
    developers (if not majority), are so exteremly bottled up and turn
    down any possibility of advancing. They are killing emacs. (similar
    feelings for most regular posters here in comp.lang.lisp )

    Now, that statement is imprecise, is attacking, needs a lot
    qualifications. I have literally written about 20 articles each a
    thousand words or more over the past 3 years that explains many
    specific cases in painful detail. (e.g. seehttp://xahlee.org/emacs/emacs_essays_index.html
    ) However, in a one sentence description in this thread's context,
    calling them “elitist†and “closing off to the outside worldâ€, is to
    the point.

    > Your claim that this shows something wrong with lists is completely
    > unclear, although if I read your paper (I'll try) I might have some
    > idea what you're getting at


    More specifically, 2 fundamental problems of lisp i feel this ruby
    example illustrates well:

    • the cons impedes many aspects of lists. e.g. difficult to learn,
    confusing, hard to use, prevent development of coherent list
    manipulation functions.

    • nested syntax impedes the functional programing paradigm of function
    chaining, esp when each function has 2 or more arguments (e.g. map).

    here's a short summary of the nesting problem:

    (map f x) ; 1 level of chaining
    (map g (map f x)) ; 2 levels
    (map h (map g (map f x))) ; 3 levels

    compare:

    x | f | g | h ----> unix pipe
    x // f // g // h ----> Mathematica
    h @ g @ f @ x ----> Mathematica
    x.f.g.h -------> various OOP langs, esp Ruby, javascript
    h g f x -------> some functional langs, Haskell, Ocaml

    The way the above works is that each of f, g, h is a lambda themselves
    that maps. (that is, something like “(lambda (y) (map f y))â€)

    Note, that any of the f, g, h may be complex pure functions (aka
    lambda). Because in lisp, each lambda itself will in general have
    quite a lot nested parens (which cannot be avoided), so this makes any
    chaining of functions of 2 args, for more than 2 or 3 levels of
    nesting, unusable for practical coding. One must define the functions
    separately and just call their names, or use function composition with
    lambda (which gets complex quickly). One major aspect of this problem
    is that the scope of vars becomes hard to understand in the deep
    nested source code. This is worse in elisp, because emacs is
    dynamically scoped, so you have to avoid using var of same name.

    More detail here:

    the section “The Cons Business†at
    • Fundamental Problems of Lisp
    http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

    • The Concepts and Confusions of Prefix, Infix, Postfix and Fully
    Nested Notations
    http://xahlee.org/UnixResource_dir/writ/notations.html

    Your input will be highly valued. Though, forgive me to say, that i
    think my opinion on this is beyond any computer scientist of any
    standing can try to tell me otherwise. If they disagree (which i think
    most of them won't), i think their knowledge and experience in the
    area of computer languages and syntax and notations, IQ, are inferior
    to me.

    Xah
    ∑http://xahlee.org/

    ☄
    Xah Lee, Jan 20, 2009
    #15
  16. Xah Lee

    Rhodri James Guest

    On Tue, 20 Jan 2009 03:39:45 -0000, Xah Lee <> wrote:

    > On Jan 19, 4:49 pm, "Rhodri James" <>
    > wrote:
    >> On Sun, 18 Jan 2009 08:31:15 -0000, Xah Lee <> wrote:
    >> > On Jan 17, 10:25 am, Tino Wildenhain <> wrote:
    >> >> > [[int(x) for x in line.split()] for line in open("blob.txt")]

    >>
    >> > Nice (python code).

    >>
    >> > Few comments:

    >>
    >> > • the above code is borderline of atypical. e.g. it is not a average
    >> > python code would produce or one'd seen in corporate python code.

    >>
    >> I can't imagine why not.

    >
    > consider code produced by corporations, as opposed to with respect to
    > some academic or philsophical logical analysis. Looked in another way,
    > consider if we can compile stat of all existing pyhton code used in
    > real world, you'll find the above style is rarely used.


    I *was* thinking of code produced in the real world, and I don't buy
    your assertion. I'm not an academic, and I wouldn't hesitate to lay
    down a line of code like that. As I said before, it fits into English
    language idioms naturally, and as a result is pretty self-descriptive.

    > in a logical analysis, each lang fanatics will actively sell certain
    > style of construction, but that's just not the way code in the real
    > world are. Ample examples can be found especially in other cultish
    > lang groups such as lisp, perl, etc. (less of this phenomenon is found
    > in lang like php, javascript, java, C, where the lang simple don't
    > create fancy constructions in the name of improvement or esthetics or
    > weird philosophy in the first place.)


    Long experience particularly in C suggests that you are entirely wrong.
    You are conflating simplicity with flexibility; C is a simple language,
    but it is very syntactically flexible, and programmers not only can but
    do regularly and with malice aforethought write horribly convoluted
    code. Sometimes this is out of cunning (dropping through cases in a
    switch statement, for instance), sometimes because the language is too
    simple (function dispatch tables can look gruesome if you aren't
    careful), and sometimes it's because you need a particular sequence of
    instructions to get the optimiser to Do The Right Thing; regardless,
    it happens in a large fraction of non-trivial C programs.

    >> > The above line illustrate well the ad hoc syntax soup nature python is
    >> > moving into.

    >>
    >> To a native English speaker, it illustrates entirely the reverse.
    >> List comprehension is actually quite a linguistically natural way
    >> to express the iterative construction of a list.

    >
    > computer lang is not human lang. In argument based on human lang, you
    > have AppleScript, Perl, which are un-readable or cumbersome to most
    > programers. Even with human lang, if you know linguistics to some
    > extend, you know that natural lang is a complete wortheless mess in
    > every aspect with respect to “design†qualities.


    Having studied natural languages, I am well aware that the designers
    of AppleScript didn't study natural languages. If they had, they'd
    have been a lot more careful in their choice of constructs to map
    AppleScript onto English less ambiguously.

    I can't think of a language less like AppleScript than Perl, which
    is incomprehesible for entirely different reasons. Grouping them
    together as if they had anything else in common is... eccentric.

    Computer languages are not human languages, but computer language
    constructs do attempt to map onto human language constructs to
    provide some measure of comprehensibility. Where a construct like
    list comprehension maps very well onto idiomatic English, dismissing
    it as "ad hoc syntax soup" is just plain wrong.

    --
    Rhodri James *-* Wildebeeste Herder to the Masses
    Rhodri James, Jan 21, 2009
    #16
  17. Xah Lee

    Xah Lee Guest

    Xah Lee wrote:
    > > consider code produced by corporations, as opposed to with respect to
    > > some academic or philsophical logical analysis. Looked in another way,
    > > consider if we can compile stat of all existing pyhton code used in
    > > real world, you'll find the above style is rarely used.


    Rhodri James wrote:
    > I *was* thinking of code produced in the real world, and I don't buy
    > your assertion. I'm not an academic, and I wouldn't hesitate to lay
    > down a line of code like that. As I said before, it fits into English
    > language idioms naturally, and as a result is pretty self-descriptive.


    The issue is whether the python code in the real world, by statistics,
    uses a style such as list comprehension as discussed in this thread.
    (to simplify the matter: whether code out there uses list
    comprehension in situations when it can, by what percentage. I claimed
    it is rare, being borderline esoteric. This can be interpreted as less
    that 10%)

    In partcular, the issue, is not about your opinion or joe tech
    geeker's personal experiences of what they have seen. In newsgroups,
    every joe geeker makes claims using personal experiences as if that
    apply for the world. I, of course also based on my claims on personal
    experience, however, the difference is that my claim is explicitly
    made in the context of applying to the world. For example, my claim is
    not about my experiences being such and such. My claim is about such
    and such is so in the real world.

    If, now, you claim that it is not so, then perhaps we might have
    something to argue about.

    If you can, say, as a example, have a code that crawl the web of all
    google's own python code at google code for example, and do some
    simple analysis and report what is the percentage, and if that
    percentage is more than what i claim, i'll find it very interesting.
    But if you simply have such code to do such scale of analysis, that's
    far more interesting by itself than our debate.

    Similarly, if you can find any evidence, say by some code researcher's
    reports, that'd be great. At this point, i recall that i have read
    books on such report. You might try to do research on such books and
    read up.

    > Long experience particularly in C suggests that you are entirely wrong...


    Try to study more. I recommend spend less time coding or tech geeking
    (such as reading blogs, studying languages, or studying computer
    science ). I recommend taking a course in community college on
    philosophy, logic, literature, economics. After that, your thinking in
    coding and all the social issues related to coding, and computing
    industry, will sharpen by far.

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 21, 2009
    #17
  18. Xah Lee

    alex23 Guest

    On Jan 21, 2:35 pm, Xah Lee <> wrote:
    > I, of course also based on my claims on personal
    > experience, however, the difference is that my claim is explicitly
    > made in the context of applying to the world. For example, my claim is
    > not about my experiences being such and such. My claim is about such
    > and such is so in the real world.


    So the claims of people who have personally worked on "real world"
    code that contains list comprehensions isn't valid, whereas you who
    have _no_ such experience have a more genuine understanding of the
    world? Which is somehow totally unbiased and yet somehow always agrees
    with your preconceived notions?

    Talk about Aristotle and his wife's teeth...

    > I recommend taking a course in community college on
    > philosophy, logic, literature, economics. After that, your thinking in
    > coding and all the social issues related to coding, and computing
    > industry, will sharpen by far.


    Because clearly what the world needs is more of your style of academic
    understanding over practical, pragmatic knowledge. And arrogant
    condescension...we sure can't get enough of that.
    alex23, Jan 21, 2009
    #18
  19. Xah Lee

    Rhodri James Guest

    On Wed, 21 Jan 2009 04:35:22 -0000, Xah Lee <> wrote:

    > Xah Lee wrote:
    > Similarly, if you can find any evidence, say by some code researcher's
    > reports, that'd be great. At this point, i recall that i have read
    > books on such report. You might try to do research on such books and
    > read up.


    Given that you are the one who is attempting proof by repeated
    assertion, I'd suggest that it is your job to find the evidence to
    support your claim. I am merely observing that I find your claim
    highly unlikely.

    >> Long experience particularly in C suggests that you are entirely
    >> wrong...

    >
    > Try to study more. I recommend spend less time coding or tech geeking
    > (such as reading blogs, studying languages, or studying computer
    > science ). I recommend taking a course in community college on
    > philosophy, logic, literature, economics. After that, your thinking in
    > coding and all the social issues related to coding, and computing
    > industry, will sharpen by far.


    I recommend spending less time being certain that you are correct
    without seeking evidence (something the later philosophers seem
    dreadfully bad at) and more in the application of logical thought.
    While expanding one's horizons is a good thing (my personal list
    places more emphasis on the theory and practice of music, theology,
    literature and democracy, but anything is fair game), expanding
    one's ego is not.

    --
    Rhodri James *-* Wildebeeste Herder to the Masses
    Rhodri James, Jan 21, 2009
    #19
  20. Xah Lee

    Xah Lee Guest

    Rhodri James wrote:
    > I recommend spending less time being certain that you are correct
    > without seeking evidence


    I don't concur.

    For instance, when you are talking to a bunch of kids, you have to be
    sure of yourself, else they run all over you, even if they didn't mean
    to be rude.

    Also, one's demeanor must commensurate one's knowledge. If i pamper
    you, you might think i'm a whimp, and run on with your opinions and
    thoughts unbridled, which, can be considered as a miscommunication on
    my part.

    Xah
    ∑ http://xahlee.org/

    ☄
    Xah Lee, Jan 21, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Darrel
    Replies:
    3
    Views:
    650
    Kevin Spencer
    Nov 11, 2004
  2. Luis Esteban Valencia Muñoz
    Replies:
    3
    Views:
    1,386
    Scott Allen
    Jun 4, 2005
  3. Replies:
    0
    Views:
    764
  4. Karim Ali

    Reading a file and resuming reading.

    Karim Ali, May 25, 2007, in forum: Python
    Replies:
    2
    Views:
    352
    Hrvoje Niksic
    May 25, 2007
  5. caroliina

    reading list of list to a file

    caroliina, Dec 9, 2007, in forum: Python
    Replies:
    0
    Views:
    253
    caroliina
    Dec 9, 2007
Loading...

Share This Page