Re: Lisp refactoring puzzle
Xah Lee
> On 5 Lip, 20:54, Sean McAfee <eef...@gmail.com> wrote:
> (...)> This is fairly elegant, but I'm disappointed that it doesn't really save
> > me any lines of code over just writing out the mappings by hand.
>
> > Can anyone suggest a more compact/elegant way to establish these
> > mappings?
>
> (...)
>
> Stop and think about what you really want to achieve. How many lines
> of code did you have at the beginning? twelve? And you want to make
> your code a few lines shorter by throwing at it complex cruft? Get a
> life, man! If you had 3000, 30000 lines like that, reducing them to
> 15 would be a real achievement.
>
> The original version is evident, self-documenting, simple, stupid
> even. If you come back to this code in 10 years from now you won't
> have to waste a minute of your time thinking what does it do -- and
> in 10 years, believe me, you will have much more interesting things
> to do with your time.
>
> The original version performs optimally, it's not possible to make it
> run any faster -- the best you can get is a more complex version that
> performs similarly (e.g. a macro that expands at compilation time to
> what you originally had)
I was going to write a rant on this too util i saw Jose A Romero L's
reply above. I agree.
I'm a functional programer since early 1990s. Have always read and
pursued elegance, spent countless hours, years, picking bones on
getting the most elegant, condensed, abstract, code, yet not any bits
of obfuscation (as exhibited by perl idiots).
but what i realized in the past decade is that, it's rather harmful
than helpful. It is fun indeed, but other than that, isn't good.
Concrete, simple, repeating lines are much easier to understand.
Unless you have few hundred of such repeating lines, it's not
worthwhile to abstract it into one line, even if you can.
recently i tried to update one such elegant line i wrote in 1990s.
After 20 minutes, i don't understand it, and had to put it off. lol.
<< DiscreteMath`Combinatorica`
funList = {Sin, Tan, Power[#, -1] &};
Nest[Module[{li = #},
(Union[#, SameTest -> (Module[{arg1 = #1, arg2 = #2},
If[(*both expression contains both x and y*)
And @@ (((((StringMatchQ[#, "*x*"] &&
StringMatchQ[#, "*y*"]) &)@
ToString@#) &) /@ {arg1, arg2})
, SameQ[arg1, arg2 /. {x -> y, y -> x}],
SameQ[arg1, arg2]]
] &)] &)@
Union@Flatten@(Table[(Times @@ # &) /@ KSubsets[#, i], {i, 1,
2}] &)@Flatten@{li, Outer[#1@#2 &, funList, li]}
] &, {x, y}, 1];
Select[%, (StringMatchQ[ToString@#, "*x*"] &&
StringMatchQ[ToString@#, "*y*"]) &]
the above is Mathematica code. For all lisp's macros or whatnot in
functional programer's pockets (e.g. map, lambda, recursion, currying
…), the above code is beyond the regular lambda knights you see
hanging in comp.lang.lisp for example, yet it's the most elegant
functional code possible. (am looking at one Pascal J Bourguignon
common lisp idiot.)
〈Math: Density Plots of Trig Expressions〉
http://xahlee.org/MathGraphicsGallery_dir/dense/dense1.html
Xah
Marco Antoniotti
Looks like Perl to me. Obviously also Mathematica has the improvement of a programmer's self-esteem as a design goal.
--
MA
Xah Lee
Xah wrote:
On Jul 9, 2:14 pm, Marco Antoniotti <marc...@gmail.com> wrote:
> Looks like Perl to me. Obviously also Mathematica has the improvement of a programmer's self-esteem as a design goal.
dear Marco Antoniotti,
have you ever sucked your mom's tits?
you see, that might have contributed to the gap of intellectual
perceptive power between you and me.
Xah
Marco Antoniotti
> > Looks like Perl to me. Obviously also Mathematica has the improvement of a programmer's self-esteem as a design goal.
>
> dear Marco Antoniotti,
>
> have you ever sucked your mom's tits?
Don't remember.
>
> you see, that might have contributed to the gap of intellectual
> perceptive power between you and me.
>
I'd like to think we are equal in that field... Have a look at the Mathematica code and just be a little light hearted about it.
Cheers
--
MA
jvt
highest standards of reason and rhetoric.
jvt
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.
Marco Antoniotti
> I'm glad to see comp.lang.lisp is maintaining its reputation for the
> highest standards of reason and rhetoric.
You ain't seeing nothing yet. :)
Cheers
--
MA
Xah Lee
2011-07-11
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
jvt
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.
WJ
> 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]
fortunatus
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.
Petter Gustad
> 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.
Neil Cerutti
What's the rationale for providing them? Are the definitions
obvious for collections that a not sets?
--
Neil Cerutti
WJ
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]
Marco Antoniotti
> 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]
>
(intersection (list 2 3 5 8) (list 0 2 4 5 6 8))
==> (8 2)
> Union:
>
> [2,3,5,8] | [0,2,4,6,8]
> ==>[2, 3, 5, 8, 0, 4, 6]
(union (list 2 3 5 8) (list 0 2 4 6 8))
==> (5 2 3 8 4 0 6)
Yawn
--
MA
Marco Antoniotti
> Petter Gustad wrote:
>
> > Xah Lee <xah...@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.
As it is well documented in the spec, mon cher. The operations (which, incidentally, suck big time on some, here unnamed, implementation) are on *SETS*. Sets don't have a notion of order, so the results are perfectly fine.
>
>
> * (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]
The right way is the Java way here (or the Fortress way, maybe? :) Surely the SETL way) where you have the appropriate mathematical notion of "set". Ruby instead adds meaning to the set-theoretic operations, which does not sit well with some people (personally, I don't care). Common Lisp, at a minimum, say that you can use "lists" as sets (*) but that by doing so you must accept "set" semantics: no order. So, you may not like it, but COBOL is in this case more honest :)
Yawn
MA
(*) Something usually pretty stupid, given that membership test is linear, as is in your RUby examples.
Pascal J. Bourguignon
> 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 {}.
Marco Antoniotti
> Neil Cerutti <ne...@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.
And that WJ is boring....
Cheers
--
MA
William Clifford
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
Luis Anaya
>
> On Jul 11, 6:51 am, jvt <vincent.to...@gmail.com> wrote:
>> anything. That is much more the province of so-called "function-
>> level" programming languages like APL/J and to a more limited extent
Well, APL/J are meant to be terse languages and to be efficient in
matrix arithmetic, the same way LISP is efficient for list processing
(hence the name). But at the end of the day, all programming
languages are meant to only one thing: to solve a problem.
The difference is how it is solved and how programming best practices
are applied. JVT mentions that functions need to be made in a way that
can be re-used and if for some reason they are not understood is
because the design is not right. That is why one of the reasons, in
OOP, Object design is utmost important.
>
> 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.
>
Well, I tried Objective Camel and... well, it is weird. :). I
sometimes wonder how these languages (Ocaml and Hanskell) which are
considered modern are subject on mangling elegant constructs. That is
where academics and industry programming goes at odds. When the
objective is to deliver software at a given timeframe for time to
market, you do not have the luxury of mangling elegant constructs.
Clever programming leads to having SME's and provides maintenability
issues on the long run when staff turnover is considered. That is why
many of these languages are not used extensively in the industry.
So far, C and C like languages (C++, Objective C, Java, C#) have been
for the most part, successful in penetration because they have a
relative common syntax and it is easier to find expertise to service
them. Before that, COBOL and PL/1 were of choice, because they were
inherently self documenting.
> 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
And what is that used for other than doing those operations? I checked
briefly newlisp's manual and it does have native intersect and unions.
Even though this operations are certainly useful, having or not having those
only imposes rules in the way data structures are built.
> 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
Because it is considered an math specific package. I do not think that
you would see the same for those using Minitab, R or SPSS.
> academic publications on Scheme, Haskell, even Java) I think the
> reason is social, again. Proprietary langs isn't a revue of
>
> Want Mathematica? Pay $2k+.
That is why you see more used on Octave, Maxima or Freemat.
Universities have a fix budget to operate.
> it is the very people in computing community who laughed and stifled
> all the great innovations in computing (e.g. innovations in computer
Can you believe that they put a man on the moon? The same happened
during the Apollo program. It is inherent skepticism of the human race.
I am out of here...
Lou