Re: reading file to list

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

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

> On Jan 17, 10:25 am, Tino Wildenhain <t...@wildenhain.de> 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

On Jan 19, 4:49 pm, "Rhodri James" <rho...@wildebst.demon.co.uk>
wrote:
> On Sun, 18 Jan 2009 08:31:15 -0000, Xah Lee <xah...@gmail.com> wrote:
> > On Jan 17, 10:25 am, Tino Wildenhain <t...@wildenhain.de> 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

On Jan 20, 1:39*pm, Xah Lee <xah...@gmail.com> 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

On Jan 19, 11:17 pm, alex23 <wuwe...@gmail.com> wrote:
....

Hi Daniel Weinreb,

Xah wrote:
> • A Ruby Illustration of Lisp Problems
> http://xahlee.org/UnixResource_dir/w...s_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/w..._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

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

> On Jan 19, 4:49 pm, "Rhodri James" <rho...@wildebst.demon.co.uk>
> wrote:
>> On Sun, 18 Jan 2009 08:31:15 -0000, Xah Lee <xah...@gmail.com> wrote:
>> > On Jan 17, 10:25 am, Tino Wildenhain <t...@wildenhain.de> 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

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

On Jan 21, 2:35*pm, Xah Lee <xah...@gmail.com> 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

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

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