Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #9301 > unrolled thread

Re: Lisp refactoring puzzle

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Lisp refactoring puzzle Xah Lee <xahlee@gmail.com> - 2011-07-11 20:37 -0700
    Re: Lisp refactoring puzzle jvt <vincent.toups@gmail.com> - 2011-07-12 07:30 -0700
    Re: Lisp refactoring puzzle "WJ" <w_a_x_man@yahoo.com> - 2011-07-12 15:27 +0000
    Re: Lisp refactoring puzzle fortunatus <daniel.eliason@excite.com> - 2011-07-12 09:16 -0700
    Re: Lisp refactoring puzzle gene heskett <gheskett@wdtv.com> - 2011-07-12 14:23 -0400
    Re: Lisp refactoring puzzle Petter Gustad <newsmailcomp6@gustad.com> - 2011-07-12 21:02 +0200
      Re: Lisp refactoring puzzle Neil Cerutti <neilc@norwich.edu> - 2011-07-12 19:44 +0000
        Re: Lisp refactoring puzzle "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-07-13 00:51 +0200
        Re: Lisp refactoring puzzle William Clifford <wobh@yahoo.com> - 2011-07-13 17:53 -0700
      Re: Lisp refactoring puzzle "WJ" <w_a_x_man@yahoo.com> - 2011-07-12 19:52 +0000
    Re: Lisp refactoring puzzle Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-13 13:47 +1200
      Re: Lisp refactoring puzzle Roy Smith <roy@panix.com> - 2011-07-12 21:58 -0400
    Re: Lisp refactoring puzzle Terry Reedy <tjreedy@udel.edu> - 2011-07-13 00:39 -0400
      Re: Lisp refactoring puzzle rusi <rustompmody@gmail.com> - 2011-07-12 22:10 -0700
    Re: Lisp refactoring puzzle Teemu Likonen <tlikonen@iki.fi> - 2011-07-13 11:29 +0300
      Re: Lisp refactoring puzzle Terry Reedy <tjreedy@udel.edu> - 2011-07-13 10:34 -0400
        Re: Lisp refactoring puzzle Teemu Likonen <tlikonen@iki.fi> - 2011-07-13 18:25 +0300
      Re: Lisp refactoring puzzle Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-14 15:12 +1200

#9301 — Re: Lisp refactoring puzzle

2011-07-11

On Jul 11, 6:51 am, jvt <vincent.to...@gmail.com> wrote:
> I might as well toss my two cents in here.  Xah, I don't believe that
> the functional programming idiom demands that we construct our entire
> program out of compositions and other combinators without ever naming
> anything.  That is much more the province of so-called "function-
> level" programming languages like APL/J and to a more limited extent
> concatenative languages where data (but not code) is mostly left
> without names.
>
> Functional programming, in my mind, is about identifying reproducibly
> useful abstractions, _naming them_, and constructing other
> abstractions from them.  Your piece of code above probably needs to be
> factored out into named pieces so that the composition is more
> sensible.  If a piece of code isn't comprehensible, it might be
> because it isn't using the right abstractions in the right way, not
> because the notion of functional programming is itself problematic.
>
> One might instead provide a nightmare nest of procedural code and
> claim that procedural programming has problems. Of course, this
> particular kind of problem might be less common in procedural code,
> since it depends heavily on naming and side effecting values, but it
> isn't hard to find procedural code with a long list of operations and
> namings wherein the chose names are random or otherwise unrelated to
> the problem domain.  My adviser in grad school used to name variables
> after pieces of furniture in dutch, but that didn't cause me to
> impeach the _notion_ of procedural code.

hi jvt,

of course, you are right. But i wasn't criticising functional
programing in anyway.

was just putting out my tale as a caution, to those of us — e.g.
academic scheme lispers and haskell types — who are perpetually
mangling their code for the ultimate elegant constructs.

but speaking on this now... as you guys may know, i was a naive master
of Mathematica while being absolute illiterate in computer science or
any other lang. (see 〈Xah Lee's Computing Experience (Impression Of
Lisp from Mathematica)〉 @ http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html
) When i didn't know anything about lisp, i thought lisp would be
similar, or even better, as a highlevel lang in comparison to
Mathematica. In retrospect now, i was totally wrong.

lisp, or scheme lisp, is a magnitude more highlevel in comparison to C
or C derivatives such as C++, Java. However, in comparison to
Mathematica, it's one magnitude low level. (it pains me to see lisp
experts here talking about cons and macros all day, even bigshot names
such as one Paul Graham and in lisp books praising lisp macros. Quite
ridiculous.)

over the years, i had curiosity whether perhaps ML/OCaml, Haskell,
would be equivalent high-level as Mathematica as i thought.
Unfortunately, my study of them didn't went far. (best result is my
incomplete 〈OCaml Tutorial〉 @ http://xahlee.org/ocaml/ocaml.html ) Am
not qualified to comment on this, but i think that even Haskell,
OCaml, are still quite low in comparison to Mathematica.

it's funny, in all these supposedly modern high-level langs, they
don't provide even simple list manipulation functions such as union,
intersection, and the like. Not in perl, not in python, not in lisps.
(sure, lib exists, but it's a ride in the wild) It's really
exceedingly curious to me. And it seems that lang authors or its
users, have all sorts of execuse or debate about whether those should
be builtin if you force them to answer. (i.e. they don't get it)
While, we see here regularly questions about implementing union etc
with follow up of wild answers and re-invention the thousandth time.
Of course, Mathematica has Union, Intersection, and a host of others
some 20 years ago, and today it has a complete set of combinatorics
functions as *builtin* functions (as opposed to add-on libs of second-
rate quality). (this is not a question. No need to suggest some
possible reasons why lang might not want to have a whole set of list
manipulation builtin. You (the lisper/python/perl regulars and other
lang fans) are a complete idiot, that's what i'm saying. COMPLETE
IDIOT. (actually, this is not surprising, since genius and true
thinkers are rare and few. (such as myself. As they say, beyond the
times)))

i also wondered, if Mathematica is truely a magnitude higher level
than lisp, why we don't see any computer scientists talk about it? (of
course there are, but almost non-existant in comparison to, say,
academic publications on Scheme, Haskell, even Java) I think the
reason is social, again. Proprietary langs isn't a revue of
academicians, together with the fact that Stephen Wolfram goes about
as if the entire science of computer science comprises of himself.

Want Mathematica? Pay $2k+.

recently i spent several days studying and watching a talk by Douglas
Crockford.  it is incredible. He went thru history, and explained, how
it is the very people in computing community who laughed and stifled
all the great innovations in computing (e.g. innovations in computer
languages). Many of these innovations we enjoy today (e.g web) took
few decades to finally be accepted (usually in a inferior form (and he
showed, how the web came to be thru Tim, and Mosaic etc folks, and
cookies and javascript of Netscape by utterly ignoring the tech
geeker's loud cries of pain about how things “should” be. e.g. Tim
ignored SGML folk's cries. Mosaic added the image tag, ignoring Tim's
cries. …)). These people, i call tech geekers. (e.g. as we witness
here recently, where lisper idiots siging the tunes of cons — a
concept based on hardware that's obsolete for like 30 years.) Douglas
Crockford gave many examples thru-out his lectures.

i had similar impressions about how new tech is always sneered upon
first by the very people of that field (e.g. cookies, js, web email,
blogs, instant messaging, and in recent years youtube, twitter,
facebook), and old habit really are impossible to die. Progress on
comp lang is exceedingly slow, usually in the form of tiny
improvements (think of the C C++ Java C# C-go spanning 40 years of
minor tweaks, or think of acceptance of functional programing langs).
(Douglas says it take a generation to swap people out) For example,
lisp cons business, computer language formatting, 80 char line
truncation business, unix line truncation business, netquette issues,
RFC idiocies and RFC idolization, unix philosphy shit, emacs meta key
and UI gospels …. (you can read bout my take here: 〈Computing ＆ its
People〉 http://xahlee.org/Periodic_dosage_dir/skami_prosa.html )

watch the first episode of Douglas Crockford's talk here:
 http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-1
it's a hour and 42 minutes, worth every minute. There are 5 more.

 Xah

[toc] | [next] | [standalone]

#9319

I might argue that it isn't quite right (or politic) to call those who
resist technological changes "idiots" so much as to observe they often
have goals which cannot wait for the ideal expressive system.  People
love python not because Python is the platonic programming language,
but because it does what they need it to do right now.  Ditto (often)
for Lisp.

It is easy to point out an example of forward thinking languages like
Mathematica, and who knows, perhaps it will be the template upon which
languages are built in the next 100 years.  But if it is, there will
be tons of other technologies which _didn't_ make it but which might
have seemed equally advanced.  Early adoption is always a risk, and
few people want to deal with it when technology exists now that solves
their problem now, however sub-optimally. That is hardly idiotic, Xah.

[toc] | [prev] | [next] | [standalone]

#9320

Xah Lee wrote:

> it's funny, in all these supposedly modern high-level langs, they
> don't provide even simple list manipulation functions such as union,
> intersection, and the like. Not in perl, not in python, not in lisps.

Ruby has them.

Intersection:

[2,3,5,8] & [0,2,4,6,8]
    ==>[2, 8]

Union:

[2,3,5,8] | [0,2,4,6,8]
    ==>[2, 3, 5, 8, 0, 4, 6]

[toc] | [prev] | [next] | [standalone]

#9323

I think the problem with so-called "forward looking" or "highest
level" languages is that they tend to become domain specific.  What
Lispers are always saying is construct your own high level language
out of your favorite Lisp.  Of course no one else will use it then, or
even discuss it, unless you have some good buddies.

What happens is that high level languages don't end up addressing
needs across a large community.  The lower down languages can be
common denominators across wide swaths of programmers.  So we live in
this world of roll-your-own on top of the common denominator language.

One exception to this is in data base development, where there were
some "4th generation" languages that had some success, where the needs
of mapping business data models onto data base oriented implementation
has had a large community.

I guess Mathematica, or MatLab in my environment, also address a
community of needs for modelling mathematical algorithms, or for doing
analysis of data sets.

However both the data base field and the math/arithmetic tool field
are examples of domains that are narrower than programming in
general.  Hence those higher level languages could be seen as domain
specific, but for domains with lots of users.

[toc] | [prev] | [next] | [standalone]

#9335

On Tuesday, July 12, 2011 02:08:02 PM Terry Reedy did opine:

> On 7/11/2011 11:37 PM, Xah Lee wrote:
> > watch the first episode of Douglas Crockford's talk here:
> >   http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-1
> 
> The link includes a transcript of the talk, which I read
> 
> I suspect Lee likes Crockford because they both think they are smarter
> than everyone else. Writing about Smalltalk, for instance, Crockford
> says:
> 
> "I don't know why it is, but a lot of programmers just couldn't get used
> to this syntax. [everything is done by sending a message with arguments
> to some object] ...So this may be a superior notation, but it was
> profoundly rejected. By who? By us, by the programmers, because we
> couldn't understand it."
> 
> Actually, I and others see Smalltalk as deeply flawed because its
> message passing syntax arbitrarily breaks symmetries in operations. For
> instance, in the expression 'a+b', both operands have equivalent roles
> in the operation for all normal interpretations of '+'.# On the other
> hand, in the expression 'a.extend(b)', where a is a list and b any
> iterable and the result is to mutate a but not b, a and b have very
> different roles in both the operation and the expression that invokes
> it.
> 
> # Under the covers, Python implements 'a+b' as first 'a.__add__(b)', but
> it also tries 'b.__radd__(a)' if the first does not work. This
> introduces a slight asymmetry in that a gets first say at defining the
> meaning of 'a+b', but it does not get the only say. And, as far as I can
> presently remember, this asymmetry is never visible with builtins. In
> fact, this implementation makes it possible for 'a+b' and 'b+a' to both
> give the same answer when a is a builtin and b is a user-class instance.
> 
> Crockford is right that he does not 'know why it is' that not everyone
> loves Smalltalk. He should have stopped there instead of projecting his
> ignorance on everyone else.
> 
I have my own reasons to hate smalltalk but won't elaborate.

> As a side note, the same principle of expressions matching operations in
> symmetry suggest that majority of up are quite sensible and not dumb
> idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a function call,
> the function has a different role than the arguments, so it is
> appropriate that it have a different role in the expression.

Which should be well documented if one expects the programmers to use it 
properly.  So far, I have only found two languages that are adequately 
defined and implemented.  K&R C, and the now essentially defunct Amiga 
ARexx.  But I should preface that by saying that I have not yet adequately 
studied python, one of the reasons I joined this list.

Specifically, I am trying to install the altera quartus software so I can 
program one of their DE1 boards, but because the majority of the linux 
distro's have not kept their repo's zlib packages up to date, one of the 
quartus imports, gzdirect is on the missing list and I am dead in the water 
until I install zlib version 1.2.5.

I hope this list serves me as a tutorial to fill in the gaps of my python 
knowledge which at the moment seem too wide to jump over.  I hope I can ask 
intelligent, if newbie, questions occasionally.

Now, I hate to mention it Terry, but your clock seems to be about 126 
months behind the rest of the world.  Does your system not run ntpd by 
default?  The date in the header from your machine is 
"Mon Jan 1 14:11:11 2001".

Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
What makes us so bitter against people who outwit us is that they think
themselves cleverer than we are.

[toc] | [prev] | [next] | [standalone]

#9340

Xah Lee <xahlee@gmail.com> writes:

> it's funny, in all these supposedly modern high-level langs, they
> don't provide even simple list manipulation functions such as union,
> intersection, and the like. Not in perl, not in python, not in lisps.

In Common Lisp you have:

CL-USER> (union '(a b c) '(b c d))
(A B C D)
CL-USER> (intersection '(a b c) '(b c d))
(C B)

//Petter
-- 
.sig removed by request. 

[toc] | [prev] | [next] | [standalone]

#9344

On 2011-07-12, Petter Gustad <newsmailcomp6@gustad.com> wrote:
> Xah Lee <xahlee@gmail.com> writes:
>
>> it's funny, in all these supposedly modern high-level langs, they
>> don't provide even simple list manipulation functions such as union,
>> intersection, and the like. Not in perl, not in python, not in lisps.
>
> In Common Lisp you have:
>
> CL-USER> (union '(a b c) '(b c d))
> (A B C D)
> CL-USER> (intersection '(a b c) '(b c d))
> (C B)

What's the rationale for providing them? Are the definitions
obvious for collections that a not sets?

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#9354

Neil Cerutti <neilc@norwich.edu> writes:

> What's the rationale for providing them? Are the definitions
> obvious for collections that a not sets?

The rational is to prove that Xah is dumb.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[toc] | [prev] | [next] | [standalone]

#9452

Neil Cerutti <neilc@norwich.edu> writes:

> On 2011-07-12, Petter Gustad <newsmailcomp6@gustad.com> wrote:
>> Xah Lee <xahlee@gmail.com> writes:
>>
>>> it's funny, in all these supposedly modern high-level langs, they
>>> don't provide even simple list manipulation functions such as union,
>>> intersection, and the like. Not in perl, not in python, not in lisps.
>>
>> In Common Lisp you have:
>>
>> CL-USER> (union '(a b c) '(b c d))
>> (A B C D)
>> CL-USER> (intersection '(a b c) '(b c d))
>> (C B)
>
> What's the rationale for providing them? Are the definitions
> obvious for collections that a not sets?

This seems like a good general question to me, although, I feel like the
answer to this question specifically is "yes, obvious enough." A general
purpose programming language ought to be general enough to allow
expansion, but have enough "obvious" features, that one doesn't have to
reinvent the wheel.

I recently read somewhere that human languages "differ less in what they
allow, and more in what they require" (paraphrase). I have little-to-no
computer science expertise, but I sense that in computer languages with
Turing equivalency this is exactly true.

-- 
William Clifford

[toc] | [prev] | [next] | [standalone]

#9345

Petter Gustad wrote:

> Xah Lee <xahlee@gmail.com> writes:
> 
> > it's funny, in all these supposedly modern high-level langs, they
> > don't provide even simple list manipulation functions such as union,
> > intersection, and the like. Not in perl, not in python, not in lisps.
> 
> In Common Lisp you have:
> 
> CL-USER> (union '(a b c) '(b c d))
> (A B C D)
> CL-USER> (intersection '(a b c) '(b c d))
> (C B)

The order was changed.

COBOL Lisp is always mindless.


* (union '(2 2 3 4) '(7 7 8 9))

(4 3 2 2 7 7 8 9)


The right way (MatzLisp):

[2,2,3,4] | [7,7,8,9]
    ==>[2, 3, 4, 7, 8, 9]

[toc] | [prev] | [next] | [standalone]

#9359

Xah Lee wrote:
> they
> don't provide even simple list manipulation functions such as union,
> intersection, and the like. Not in perl, not in python, not in lisps.

Since 2.5 or so, Python has a built-in set type that
provides these (which is arguably a better place for them
than lists).

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#9360

In article <4E1CF936.4050902@canterbury.ac.nz>,
 Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:

> Xah Lee wrote:
> > they
> > don't provide even simple list manipulation functions such as union,
> > intersection, and the like. Not in perl, not in python, not in lisps.
> 
> Since 2.5 or so, Python has a built-in set type that
> provides these (which is arguably a better place for them
> than lists).

Set is the best addition to Python since string methods.

[toc] | [prev] | [next] | [standalone]

#9364

On 7/12/2011 2:23 PM, gene heskett wrote:

> Now, I hate to mention it Terry, but your clock seems to be about 126
> months behind the rest of the world.

Please do not hate to be helpful. It was a bad malfunction perhaps due 
to a run-down battery on a machine turned off for two weeks. I will keep 
watch to see if it happens again overnight.


> Does your system not run ntpd by default?

Is that *nix or Windows? My XP system only checks the net time 
automatically once a week and refused to update at first on request 
because the dates did not match. Typically windows stupidity. If I click 
'Update from internet', it should believe that I really mean it.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#9365

On Jul 13, 9:39 am, Terry Reedy <tjre...@udel.edu> wrote:
> On 7/12/2011 2:23 PM, gene heskett wrote:
>
> > Now, I hate to mention it Terry, but your clock seems to be about 126
> > months behind the rest of the world.
>
> Please do not hate to be helpful.

Ha Ha. Cute one. Thanks

[toc] | [prev] | [next] | [standalone]

#9374

* 2001-01-01T14:11:11-05:00 * Terry Reedy wrote:

> As a side note, the same principle of expressions matching operations
> in symmetry suggest that majority of up are quite sensible and not
> dumb idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a
> function call, the function has a different role than the arguments,
> so it is appropriate that it have a different role in the expression.

Please don't forget that the whole point of Lisps' (f x) syntax is that
code is also Lisp data. It's not just a function call with arguments.
First, it's literal data (two linked cons cells and symbols) and then
the Lisp evaluating model makes it a function call in certain
situations.

Lisp is

    CL-USER> (let ((lisp (cons 'programmable nil)))
               (setf (rest lisp) lisp))
    #1=(PROGRAMMABLE . #1#)

programming language and it's totally irrelevant and pointless to say
"which syntax someone prefers" because this feature (code being data) is
very fundamental principle of the language. You know, it's easy to write
programs that write programs. If we remove this feature (i.e., don't
talk about Lisp at all) then it's perhaps relevant to discuss about such
choices in syntax.

You wouldn't want Python arrays have a read and print format "a[b, c]",
that is, the first item of the array printed outside []'s. It would be
silly.

[toc] | [prev] | [next] | [standalone]

#9398

On 7/13/2011 4:29 AM, Teemu Likonen wrote:
> * 2001-01-01T14:11:11-05:00 * Terry Reedy wrote:
>
>> As a side note, the same principle of expressions matching operations
>> in symmetry suggest that majority of up are quite sensible and not
>> dumb idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a
>> function call, the function has a different role than the arguments,
>> so it is appropriate that it have a different role in the expression.
>
> Please don't forget that the whole point of Lisps' (f x) syntax is that
> code is also Lisp data.

Thank you for clarifying that. Some Lispers appear to promote the 
'simple, uniform syntax' as a end in itself (making code=data a side 
effect) rather than as a means to accomplish a deeper end.

> It's not just a function call with arguments.
> First, it's literal data (two linked cons cells and symbols) and then
> the Lisp evaluating model makes it a function call in certain
> situations.
>
> Lisp is
>
>      CL-USER>  (let ((lisp (cons 'programmable nil)))
>                 (setf (rest lisp) lisp))

This much looks like Lisp

>      #1=(PROGRAMMABLE . #1#)

This must be some of the new-fangled Common LIsp stuff I never learned ;=).

> programming language and it's totally irrelevant and pointless to say
> "which syntax someone prefers" because this feature (code being data) is
> very fundamental principle of the language. You know, it's easy to write
> programs that write programs. If we remove this feature (i.e., don't
> talk about Lisp at all) then it's perhaps relevant to discuss about such
> choices in syntax.
>
> You wouldn't want Python arrays have a read and print format "a[b, c]",
> that is, the first item of the array printed outside []'s. It would be
> silly.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#9406

* 2011-07-13T10:34:41-04:00 * Terry Reedy wrote:

> On 7/13/2011 4:29 AM, Teemu Likonen wrote:
>> Please don't forget that the whole point of Lisps' (f x) syntax is
>> that code is also Lisp data.
>
> Thank you for clarifying that. Some Lispers appear to promote the
> simple, uniform syntax' as a end in itself (making code=data a side
> effect) rather than as a means to accomplish a deeper end.

Perhaps, yes. We can't really speak of Lisp's syntax in the same sense
as syntax in other languages.

>>      CL-USER>  (let ((lisp (cons 'programmable nil)))
>>                  (setf (rest lisp) lisp))
>
> This much looks like Lisp
>
>>      #1=(PROGRAMMABLE . #1#)
>
> This must be some of the new-fangled Common LIsp stuff I never learned
> ;=).

It's a way for the Lisp printer to show circular structures. In this
case it shows a cons cell. Its first part is the symbol PROGRAMMABLE and
the second part is a pointer back to the cons cell itself. So, it's a
kind of infinite linked list with the same item PROGRAMMABLE all the
time. With Lisp printer settings

    (setf *print-circle* nil
          *print-length* 5)

the same thing would be printed this way:

    (PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE ...)

[toc] | [prev] | [next] | [standalone]

#9457

Teemu Likonen wrote:

> Please don't forget that the whole point of Lisps' (f x) syntax is that
> code is also Lisp data.

It's possible to design other syntaxes that have a similar
property. Prolog, for example -- a Prolog program is expressed
in terms of Prolog data structures, yet it manages to have
things that look like fairly normal function calls and infix
expressions.

-- 
Greg

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web