gossip, Guy Steel, Lojban, Racket
Xah Lee
some random gossips.
----------
Discovered that Guy Steel, apparantly is a lojban speaker! Yay!
See:
http://www.lojban.org/files/papers/4thtense
Also
Robert J. Chassell, known as the author of
《An Introduction to Programming in Emacs Lisp》
is also a lojban speaker.
amazing. Are they actually have learned much lojban? or just happens
to discuss the issue?
----------
old news: PLT Scheme is now named Racket.
http://racket-lang.org/new-name.html
----------
A classic piece of mockery of Guido by Schemers
• 〈The Fate of Lambda in Python 3000 and Scheme v300〉
http://xahlee.org/comp/the_fate_of_lambda.html
Scott L. Burson
> gossip, Guy Steele, Lojban, Racket
>
> some random gossips.
>
> ----------
> Discovered that Guy Steele, apparantly is a lojban speaker! Yay!
>
> See:
> http://www.lojban.org/files/papers/4thtense
>
> Also
> Robert J. Chassell, known as the author of
> 《An Introduction to Programming in Emacs Lisp》
>
> is also a lojban speaker.
>
> amazing. Are they actually have learned much lojban? or just happens
> to discuss the issue?
As long as we're into random tidbits here, Bob Chassell and I were both
active in the Loglan community, before the schism that led to the
creation of Lojban. I've never learned Lojban, but I do still speak a
little of the 1978 dialect of Loglan.
-- Scott
Tim Bradshaw
> As long as we're into random tidbits here, Bob Chassell and I were both
> active in the Loglan community, before the schism that led to the
> creation of Lojban. I've never learned Lojban, but I do still speak a
> little of the 1978 dialect of Loglan.
Is this a bit like the Wee Frees and the Wee Wee Frees?
Xah Lee
very cool!
i studied lojban leisurely for a couple of year starting in 2003.
wrote some tutorial with voice recordings. Was somewhat popular in mid
2000s.
• 〈Xah's lojban page〉
http://xahlee.org/lojban/lojban.html
but kinda drifted away since about 2006.
Xah
--------------------------------------------------
(a bit personal digression follows)
though, after a couple of years felt disillusioned... not really due
to the lang, but caused by the community. e.g. i was bitching with 4
letter words about the fact that the logo is the worst shit possible,
they (some of them) of course cannot admit it caused by my style. I
kinda just drifted away from lojban.
you can see their logo here:
http://en.wikipedia.org/wiki/Lojban
one of the thread about my complain of the logo is here:
To: lojba...@lojban.org
Subject: Re: [lojban] Re: lojban logo
From: Matt Arnold <mat...@123.net>
Date: Sun, 14 Aug 2005 12:06:33 -0400
http://www.lojban.org/de/lists/lojban-list/msg10298.html
typically, when some truth is so obvious to anyone, the in-group
people don't see it, and will defend/deny it. Same happens with my
what you might call “trolling” experience in emacs, perl, and common
lisp communities.
i eventually did a lot logos and wrote a summary of my experiences
about talking about logos to the geeker communities. Here:
• 〈The Purpose of Logos and Principles of Logo Design〉
http://xahlee.org/UnixResource_dir/logo_design.html
• 〈Logo Design and Software Industry〉
http://xahlee.org/logo_design/index.html
note that several articles came from bitching about lisp logo in
comp.lang.lisp, met with same resistance. Typically, the ignorance
goes: “we don't need stinking logo, cause that's marketing bullshit.”,
and typically a gaggle of tech geekers will follow up and nod their
heads in some whole hearted way.
Xah
Björn Lindberg
> gossip, Guy Steel, Lojban, Racket
>
> some random gossips.
>
> ----------
> Discovered that Guy Steel, apparantly is a lojban speaker! Yay!
>
> See:
> http://www.lojban.org/files/papers/4thtense
What strikes me reading that is that discussing your fancy artificial
language in English is a bit like writing your language X compiler or
interpreter in C.
Björn Lindberg
Isaiah Gilliland
> Subject: Re: [lojban] Re: lojban logo
> Date: Sun, 14 Aug 2005 12:06:33 -0400
>
> http://www.lojban.org/de/lists/lojban-list/msg10298.html
>
> typically, when some truth is so obvious to anyone, the in-group
> people don't see it, and will defend/deny it. Same happens with my
> what you might call “trolling” experience in emacs, perl, and common
> lisp communities.
>
> i eventually did a lot logos and wrote a summary of my experiences
> about talking about logos to the geeker communities. Here:
>
> • 〈The Purpose of Logos and Principles of Logo Design〉http://xahlee.org/UnixResource_dir/logo_design.html
>
> • 〈Logo Design and Software Industry〉http://xahlee.org/logo_design/index.html
>
> note that several articles came from bitching about lisp logo in
> comp.lang.lisp, met with same resistance. Typically, the ignorance
> goes: “we don't need stinking logo, cause that's marketing bullshit.”,
> and typically a gaggle of tech geekers will follow up and nod their
> heads in some whole hearted way.
>
> Xah
Lisp definitely needs a badass logo. It's not really marketing it's
like a flag. Something visual that everybody can bond together over
and paste on forums/get tattooed. A cool logo helps newcomers too,
because seeing the code doesn't lol. I remember first looking at CL
code when I was just interested, got some vertigo and had to stop haha.
Pascal J. Bourguignon
> Lisp definitely needs a badass logo. It's not really marketing it's
> like a flag. Something visual that everybody can bond together over
> and paste on forums/get tattooed. A cool logo helps newcomers too,
> because seeing the code doesn't lol. I remember first looking at CL
> code when I was just interested, got some vertigo and had to stop haha.
It has. http://www.lisperati.com/logo.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
Xah Lee
On Sep 24, 1:18 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Isaiah Gilliland <jonsul...@gmail.com> writes:
> > Lisp definitely needs a badass logo. It's not really marketing it's
> > like a flag. Something visual that everybody can bond together over
> > and paste on forums/get tattooed. A cool logo helps newcomers too,
> > because seeing the code doesn't lol. I remember first looking at CL
> > code when I was just interested, got some vertigo and had to stop haha.
>
> It has. http://www.lisperati.com/logo.html
my fav is this classic
• 〈LISP Logo〉
http://xahlee.org/emacs/lisp_logo.html
another is:
• 〈Qi Language Logo〉
http://xahlee.org/emacs/qi_logo.html
but i think Mark (Tarver) is really a bad marketer. Qi could be great
but it's barely heard.
Mark started to use the logo in their online forum about a couple
years ago:
http://groups.google.com/group/qilang
but it really needs to go onto its home page:
http://www.lambdassociates.org/
(btw, the home page is badly designed. Just compare it to
http://clojure.org/
http://newlisp.org/
)
the few times i chatted to Mark (hi Mark), i recall the impression i
got from him is “i don't know where to use the logo”. About a year
later he used it on the Qi forum and told me about it, which is
fantastic and am very happy. But the most obvious place is the home
page, and any publication associated with the lang. I mean, that's
what logo is for.
i couldn't understand it. At first i thought maybe he doesn't really
want to associate Qi with logo from a “troll”. But apparantly he does
like it and would use it on the forum.
a few times in the past couple years i had the pleasure to browser
some of his essays.
e.g.
http://www.lambdassociates.org/blog/index.htm
look at that war time photo, and a bunch of quite personal essays such
as “why i'm not a professor”, linked directly from the front page.
That really puts a dent on public image.
That needs to go. Perhaps to his personal site with a different
domain. Or, actually, Qi should have its own domain, qilang.org or
qilisp.org.
By the few essays i've read, he designed Qi because he wanted to
revive lisp, and bring it head to head to modern functional langs such
as ML/Haskell, and wish it wide-spread. By his analysis, he thought
the first step in in academia. So, in that respect he is not like some
other lang creators who take the attitude of “i did it purely for
myself and couldn't careless anyone else uses it”.
I think Qi could be a great fix or improvement to Common Lisp. You
know, other new lisps (Clojure, newLISP, Arc, Racket) are all not
Common Lisp, and they are all doing good jobs in bringing wide
awareness of lisp (Clojure being concurrency & JVM, newLISP for good
scripting, Arc by Paul's fame (focusing on web app i think), Racket by
PLT Scheme's established community and now a new name). Only Qi, takes
lisp to a new level in a CL compatible way, only if the marketing
could be improved a bit and if CL people would be more supportive.
Xah ∑ xahlee.org ☄
namekuseijin
> I think Qi could be a great fix or improvement to Common Lisp. You
> know, other new lisps (Clojure, newLISP, Arc, Racket) are all not
> Common Lisp, and they are all doing good jobs in bringing wide
> awareness of lisp (Clojure being concurrency & JVM, newLISP for good
> scripting, Arc by Paul's fame (focusing on web app i think), Racket by
> PLT Scheme's established community and now a new name).
Racket/PLT Scheme also got a damn nice development environment for
lisp-like code -- you may quite as easily write newLisp code in it as
racket code. Plus the stepper and other goodies for racket langs...
namekuseijin
> gossip, Guy Steel, Lojban, Racket
We know the man is made of steel, but it's actually "Steele"... :)
> ----------
> A classic piece of mockery of Guido by Schemers
>
> • 〈The Fate of Lambda in Python 3000 and Scheme v300〉http://xahlee.org/comp/the_fate_of_lambda.html
This is really old news, but in the case of Krishnamurthi's april
fool's reply in the form of mockery of the alleged mockery by Guido:
"We think dropping FILTER and MAP is pretty uncontroversial; (filter P
S) is almost always written clearer as a DO loop (plus the LAMBDA is
slower than the loop). Even more so for (map F S). In all cases,
writing the equivalent imperative program is clearly beneficial."
it just doesn't follow even as mockery, because of 3 things:
1) it assumes list comprehensions in python are imperative programming
2) it assumes do loops in scheme are imperative programming
3) it assumes do in scheme is the equivalent of list comprehensions in
python
Schemers are a pretty desunited group. Many in the Racket group don't
go along with other implementors, like the guy who proposed for a
previous RNRS the DO macro as a shortcut for a named let. DO is no
more of a imperative artifact than a named LET because it is a named
let, which in turn is just a function call with more conveniently
placed bindings. But thanks to lame politics, it's got bad rap.
Plus, Guido wasn't mocking, he was being pragmatic and many of his
points were valid points, like the fact that tail-recursion makes for
lame debugging.
Python did good in replacing convoluted syntax, for clearer and more
direct equivalent, like:
map(lambda x:x+1,[1,2,3,4,5])
[x+1 for x in [1,2,3,4,5]]
==> [2,3,4,5,6]
List comprehensions also have the added benefit of being an all-in-1
replacement for map and filter just nicely:
filter(lambda x:x%2==0,[1,2,3,4,5])
[x for x in [1,2,3,4,5] if x%2==0]
==> [2,4]
Plus, it's *syntax* which combines functionality of above functions:
[x+1 for x in [1,2,3,4,5] if x%2==0]
map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
==> [3,5]
which should be ridiculously lame in Python when a clearer and shorter
alternative is builtin.
Also, just by changing the []'s into ()'s will transform the
comprehension from a list into a generator. That is, no list is built
nor memory grows, it just outputs an iterator function which can be
used to inspect each value from the comprehension. map, filter, fold
and folks are just for lists...
DO is clearly not list comprehension. So, the mockery of the alleged
mockery was not right nor called for.
But fear not, Schemers! Although only in latest R6RS Scheme got such
a widely popular function as fold (fold-left), perhaps in the next few
years it'll come complete with function argument pattern matching
(match-lambda or better just match in a define), function compositing,
automatic currying and list comprehensions (like in
http://srfi.schemers.org/srfi-42/srfi-42.html).
Lisp guys should hear most complaints and fix whatever perceived bad
lisp lisp got. Reducing parenthesis usage and reducing long abstract
names of functions like "call-with-current-continuation" or "sqlite-
query/effect-set" would be a beginning (and renaming such aberrations
in an import was a welcome addition of R6RS), as would be providing
automatic function dispatch on type of arguments so we could get far
shorter function names thanks to function overloading -- make-
datatypefoo, length-datatypefoo, read-datatypefoo is not really
acceptable anymore in this day and age... why not simply (length foo),
(read foo) etc?
Also, something C headers just beats all languages out there:
function prototypes. You read them, you know what types get in and
what types get out. You open a Scheme R6RS lib and you see a name in
the export list, then you need to dig for it in the source to figure
out the parameters and try to guess what it does by peeking at the
code... java is another stinker which decided to get rid of function
prototypes, but at least it provides plenty of automatic IDE tools to
do the digging for you and report the prototypes right in your nose...
Xah Lee
>
> Lisp guys should hear most complaints and fix whatever perceived bad
> lisp lisp got. Reducing parenthesis usage and reducing long abstract
> names of functions like "call-with-current-continuation" or "sqlite-
> query/effect-set" would be a beginning (and renaming such aberrations
> in an import was a welcome addition of R6RS), as would be providing
> automatic function dispatch on type of arguments so we could get far
> shorter function names thanks to function overloading -- make-
> datatypefoo, length-datatypefoo, read-datatypefoo is not really
> acceptable anymore in this day and age... why not simply (length foo),
> (read foo) etc?
>
> Also, something C headers just beats all languages out there:
> function prototypes. You read them, you know what types get in and
> what types get out. You open a Scheme R6RS lib and you see a name in
> the export list, then you need to dig for it in the source to figure
> out the parameters and try to guess what it does by peeking at the
> code... java is another stinker which decided to get rid of function
> prototypes, but at least it provides plenty of automatic IDE tools to
> do the digging for you and report the prototypes right in your nose...
lol. am afraid to say your argument for python is bullshit. Though,
i'll have to look in detail maybe tomorrow, i used up my gossip
reading quota today. I'm sure it contains some interesting
technicalities about scheme or python though.
can you criticize in detail of my rebuttal?
• 〈Lambda in Python 3000〉
http://xahlee.org/perl-python/python_3000.html
if you do, carefully, studying each point i made in a technical way
(and looked up Mathematica's doc i referenced to), then i'll certainly
take your post more seriously.
the basic issue is, most people, including those with 10 or 20 years
experience about programing, or even including many known computer
scientists in academia (e.g. the PLT Scheme camp), don't really know
some of the issues, or never thought about, or their remarks being
taken up without serious understand. (e.g. i recall Shriram
Krishnamurthi in one of his book about “syntax is not important,
semantic is”. Taken at face value, is laughable. Show it to notation
specialists, it'd be the most idiotic concept)
O, btw, “lisp comprehension”, the jargon, AND the concept, is the most
idiotic fuck possible. I repeat, the most idiotic FUCK in computer
science. Any computer scientist please feel free to quote me on that.
(just so people get gets some inkiling of understanding what i just
said: try to think about what Edsger Dijkstra would say about it)
here's the plain text version.
--------------------------------------------------
Lambda in Python 3000
Xah Lee, 2005-09-30
On Guido van Rossum's blog site is a essay “The fate of reduce() in
Python 3000” (2005-03-10) at http://www.artima.com/weblogs/viewpost.jsp?thread=98196,
he muses with the idea that he would like to remove lambda, reduce(),
filter() and map() constructs in a future version Python 3000.
Guido wrote:
filter(P, S) is almost always written clearer as [x for x in S if
P(x)], and this has the huge advantage that the most common usages
involve predicates that are comparisons, e.g. x==42, and defining a
lambda for that just requires much more effort for the reader (plus
the lambda is slower than the list comprehension)
The form “[x for x in S if P(x)]” is certainly not more clear than
“filter(P, S)”. The latter is clearly a function, what is the former?
A function every programer in any language can understand and
appreciate its form and function. Why would anyone to expect everyone
to appreciate a Python syntactical idiosyncrasy “[x for ...]”?
Also, the argument that the form “filter(F,S)” being cumbersome
because the first argument is a function and that mostly likely it
would be a function that returns true/false thus most people will
probably use the inline “lambda” construct and that is quite
cumbersome than if the whole thing is written with the syntactical
idiosyncrasy “[x for ...]”, is rather inane, as you can now see.
The filter(decisionF, list) form is clean, concise, and helps
thinking. Why it helps thinking? Because it condenses the whole
operation into its mathematical essence with the most clarity. That
is, it filters, of a list, and by a yes/no decision function. Nothing
is more, and nothing can be less. It is unfortunate that the decision
function usually goes by the name “Predicate”, and often written in a
syntax construction called “Lambda”. These are un-intuitive jargons
developed by the tech geekers of the functional programing community,
out of historical reasons. (The term “predicate” came from the field
of logic, and the term “lambda” came from branch of logic called
“lambda calculus”). The lambda could be more intuitively renamed as
Pure Function and the Predicate could be called True/False function.
If the predicate P in filter(P,S) is cumbersome, so would exactly the
same thing appear in the syntactical idiosyncrasy: “[x for x in S if
P(x)]”.
Guido added this sting as a afterthought:
(plus the lambda is slower than the list comprehension)
Which is faster is really the whim and capacity of Python compiler
implementators. And, weren't we using clarity as the judgement a
moment ago? The concept of a function every programer understands, but
what the heck is a List Comprehension? Why don't you scrap list
comprehension in Python 3000 and create a table() function that's
simpler in syntax and more powerful in semantics? ( See “List
Comprehension” in Python, and Perl )
Why drop lambda? Most Python users are unfamiliar with Lisp or Scheme,
so the name is confusing; also, there is a widespread misunderstanding
that lambda can do things that a nested function can't -- I still
recall Laura Creighton's Aha!-erlebnis after I showed her there was no
difference! Even with a better name, I think having the two choices
side-by-side just requires programmers to think about making a choice
that's irrelevant for their program; not having the choice streamlines
the thought process. Also, once map(), filter() and reduce() are gone,
there aren't a whole lot of places where you really need to write very
short local functions; Tkinter callbacks come to mind, but I find that
more often than not the callbacks should be methods of some state-
carrying object anyway (the exception being toy programs).
In the outset Guido here assumes a moronitude about the set of Python
users and what they are familiar of. Python users 10 years ago are not
the same Python users today, and will certainly not be the same 10
years later if you chop off lambda. Things change, math literacy
advances, and what users you have changes with what you are. A
function is the gist of a mathematical idea embodied in computer
languages, not something from LISP or Scheme as tech geekers wont to
think.
... there is a widespread misunderstanding that lambda can do things
that a nested function can't...
One is so insulted by a industrial big shot in quoting something so
disparate then shot it down as if showing his perspicacity.
A lambda is a syntax for function or a name for the concept of
function. What does it mean that a lambda isn't as powerful as nested
function??
The lambda in Python is really ill. It is designed with a built-in
limitation in the first place, and regarded as some foreign substance
in the Imperative Crowd such as the Pythoners. If there's any problem
with lambda, it is with lambda in Python and Pythoner's attitude.
Also, once map(), filter() and reduce() are gone, there aren't a whole
lot of places where you really need to write very short local
functions;
Of course, one begins to write things like Java: in three thousand
words just to show you are a moron.
The removing of elements in a language is in general not a good idea.
Removing powerful features so that coding monkeys can use it is
moronic. (e.g. Java) Removing “redundant” constructs is not always
smart (e.g. Scheme), because it pinches on practicality. Removing
existing language features by a visionary upgrade is a waste. It
forces unnecessary shakeup and can cause death.
So now reduce(). This is actually the one I've always hated most,
because, apart from a few examples involving + or *, almost every time
I see a reduce() call with a non-trivial function argument, I need to
grab pen and paper to diagram what's actually being fed into that
function before I understand what the reduce() is supposed to do. So
in my mind, the applicability of reduce() is pretty much limited to
associative operators, and in all other cases it's better to write out
the accumulation loop explicitly.
The existence of reduce() in Python is probably caused by tech geeking
clowns of the computing industry. Basically, nobody really have a
clear understanding of mathematics or computing semantics, but every
elite tech geeker knew one bag of constructs of various languages. So,
you add this, i want that, and the language becomes a incoherent soup
of constructs, with the backlash of wanting to chop off things again,
with that good things.
reduce() in fact embodies a form of iteration/recursion on lists, very
suitable in a functional language environment. If Python's lambda and
other functional facilities are more powerful or complete, reduce()
would be a good addition. For instance, in functional programing, it
is a paradigm to nest or sequence functions. (most readers will be
familiar in the form of unix shell's “pipe”). When you sequence
functions, you can't stop in the middle and do a loop construct. So,
reduce() and other functional forms of iteration are convenient and
necessary.
Suggestions: lambda, reduce(), filter() and map() all should stay. I'm
not sure exactly what's the ins and outs of Python 3000. If one wants
to shake things up based on a vision: don't. There are already
gazillion languages and visions; the world really don't need another
bigshot's say for their personal advancement. As for improvement,
lambda in Python should be expanded to remove its one-argument
limitation (and Imperative Programing Crowd such as Pythoners should
cease and desist with their lambda attitude problem). The function
map() could also be considered for expansion. (see What is
Expressiveness in a Computer Language ) Function reduce() should stay
because it's already there, even if it is not very useful and odd in
Python. filter() should stay as it is as it is superb and proper.
addendum, 2005-10-01
Here i will try to illuminate some miscellaneous things regarding the
lambda in Python issue.
As i have explained in the essay (“List Comprehension” in Python, and
Perl), the so-called List Comprehension is just a irregular syntax to
facilitate generating lists. The name is a terrible jargon, and the
means is also bent. The proper name should be something like List
Generating Form, and the proper means should be the plain function.
For instance, Python's range() is such a list generator, only that it
is limited in scope.
For a example of a powerful list generator, see Mathematica's Table
function. Mathematica: Table
Note Table's power in generating not just flat lists, but trees
(nested lists). And if one really want flat lists, there's the Flatten
function that flats any nested lists. (Python should have this too) It
is far easier to change a tree to a flat list, then partitioning a
flat list into nested list.
Python's reduce() is Mathematica's Fold. Mathematica: Fold
Besides Fold, there's FoldList, FixedPoint, FixedPointList, Nest,
NestList and others. FoldList is like reduce() except it returns a
list of each steps. FixedPoint recursively applies a function to
itself until the result no longer changes (or when a optional function
returns true) Nest is similar, except it does the recursion by a
specified number of times. The NestList and FixedPointList are similar
except that they return a list, containing all the steps.
All these can be written as a For loop, but they make the code
condensed and meaning clear. More so, they are important when
programing in a functional style. In functional programing, you don't
litter lots of variables or temporary functions or intermediate loops
here or there on every other line. The code is usually tight and
inline. When sequencing a series of functions, you can't stop in the
middle and do some loop or auxiliary calculation. All these are made
inline into a function. (that is: constructed as lambda) A block of
code usually corresponds to a unit of the algorithm used, as opposed
to a block of implementation. You don't read the minute details of the
code. You read the algorithmic unit's comments, or just the input and
output of a code block.
Also, these inline loop constructs are not only suitable for computing
numbers as Guido ignorantly thought. They are specialized forms of
generic loop constructs. Their first argument is a function, and
second argument is a list. Their generality lies with the fact that
their first argument is a function. If a language does not provide a
convenient way to represent the concept of a function, then these
functional loop construct's usability will suffer.
The Pythoners, did not provide a convenient way to represent a
function. (they tried, with their limited implementation of lambda and
shun it like a plague)
The way Guido puts it gives us a nice glimpse of their retarded
mentality:
Also, once map(), filter() and reduce() are gone, there aren't a whole
lot of places where you really need to write very short local
functions;
As we can see here, in Pythoner's mind, lambda is for “very short
local functions”.
Python's limited lambda and imperative programer's unfamiliarity of it
made functional programing suffer in Python. Consequently, it is not
surprising for one to feel a need to chop off things unfamiliar.
For Python's map(), look at Mathematica's Map on how it might be
extended. Mathematica: Map
Note the ability to map to not just flat lists but trees (nested
lists). Note the power of expressing the concept of levels of a tree.
For Python's filter(), check out the equivalent in Mathematica's
Select: Mathematica: Select
Note how it provides a third option for picking just the first n
items. Also note, that Select is just a way to pick elements in a
list. Mathematica provides a set to do these: Part, Take, Drop,
Select, Cases, Delete, DeleteCases... All uniformly use the function
syntax and all operate semantically by returning a new list. In Python
and other imperative clown's languages, usually they provide a limited
varieties to do such a task, and also inconsistent as if piled on.
(e.g. In Python we have alist[5:9], filter(f,alist),
alist.remove(...), del alist[...]. Some modify the list in-place, some
returns a new list.)
One is quite sorry to read a big shot contemplating on petty issues
with a ambitious name Python THREE THOUSAND.
For the grand Python THREE THOUSAND, what about supporting non-trivial
things such as exact fractions? What about a built-in worry-free exact-
arithmetics once for all? What about supporting pattern matching for
expression structures? What about supporting unicode in variable and
function names?
The features of Mathematica mentioned above existed over a decade ago.
But today, OpenSourcing bigwigs can contemplate and dither nothing but
which lipstick to use.
A good number of the industrial dignitaries are selfish liers. And
today we have the most human-labor intensive language Java and the
crazily hacked up Perl and their bosses trumpeting them as state-of-
the-art.
Sometimes i get turned off by Stephen Wolfram's megalomaniacal cries,
but in many ways, i think his statements about the moronicities of the
academicians and otherwise dignitaries are justified.
(disclaimer: all mentions of any real person are opinion.)
The required techniques of effective reasoning are pretty formal, but
as long as programming is done by people that don't master them, the
software crisis will remain with us and will be considered an
incurable disease. And you know what incurable diseases do: they
invite the quacks and charlatans in, who in this case take the form of
Software Engineering gurus.
—attributed to Edsger Dijkstra 1930-2002.
Xah ∑ xahlee.org ☄
Xah Lee
On Sep 24, 12:44 pm, namekuseijin <namekusei...@gmail.com> wrote:
> On 22 set, 18:57, Xah Lee <xah...@gmail.com> wrote:
>
> > gossip, Guy Steel, Lojban, Racket
>
> We know the man is made of steel, but it's actually "Steele"... :)
>
> > ----------
> > A classic piece of mockery of Guido by Schemers
>
> > • 〈The Fate of Lambda in Python 3000 and Scheme v300〉http://xahlee.org/comp/the_fate_of_lambda.html
>
> This is really old news, but in the case of Krishnamurthi's april
> fool's reply in the form of mockery of the alleged mockery by Guido:
>
> "We think dropping FILTER and MAP is pretty uncontroversial; (filter P
> S) is almost always written clearer as a DO loop (plus the LAMBDA is
> slower than the loop). Even more so for (map F S). In all cases,
> writing the equivalent imperative program is clearly beneficial."
>
> it just doesn't follow even as mockery, because of 3 things:
> 1) it assumes list comprehensions in python are imperative programming
> 2) it assumes do loops in scheme are imperative programming
> 3) it assumes do in scheme is the equivalent of list comprehensions in
> python
remember, a mockery does not mean it has to mirror every sentence with
some consistent logic.
of course your are trolling, but your list above is questionable to
me.
> 1) it assumes list comprehensions in python are imperative programming
i'd go as far to say that “list comprehension” in every lang is
imperative programing.
for some explanation of “list comprehension” and several examples in
different langs, see:
http://en.wikipedia.org/wiki/List_comprehension
the python example is given as:
S = [2*x for x in range(101) if x**2 > 3]
(see also:
• 〈Perl-Python Tutorial: List Comprehension〉
http://xahlee.org/perl-python/list_comprehension.html
)
you see, one characteristic of functional programing lang is that the
lang has lots of single-purpose functions, and the user is supposed to
sequence or combine them for max power and flexibility.
lisp comprehension is a fucking anomaly in this regards.
i dunno which fucking idiot invented it. (those expert with its
history, please post)
from looking at the Wikipedia examples, you can see that typically it
invents a new syntax. A better way and more in sync with functional
lang spirit, is simply have this instead:
operation(
filterFunction(
listGenFunction(1, 20),
trueFalseDecisionFunction()
)
)
or in Mathematica:
Select[Range@20, # > 3 &]^2
in Mathematica FullForm notation, the above is:
Times[
Select[
Range[20],
Function[
Greater[ Slot[1],3] ]
],
2]
(formatted in a way so lispers can understand)
in my style of coding, the above is typically written like this:
(#*2 &) @ (Select[#,# > 3 &]&) @ Range@20
See also: • 〈A Example of Mathematica Notation and List Processing〉
http://xahlee.org/UnixResource_dir/writ/notations_mma.html
> 2) it assumes do loops in scheme are imperative programming
Of course it is. Look at the big picture. “Do loop” in any lang is
arguably imperative.
> Schemers are a pretty desunited group. Many in the Racket group don't
> go along with other implementors, like the guy who proposed for a
> previous RNRS the DO macro as a shortcut for a named let. DO is no
> more of a imperative artifact than a named LET because it is a named
> let, which in turn is just a function call with more conveniently
> placed bindings. But thanks to lame politics, it's got bad rap.
>
> Plus, Guido wasn't mocking, he was being pragmatic and many of his
> points were valid points, like the fact that tail-recursion makes for
> lame debugging.
From a few articles i read of Guido, it's pretty clear to everyone he
does not have sufficient experience in functional programing to
criticize it.
basically, his article on wanting to chop lambda pretty much just says
“i don't grok functional notations, i prefer syntax that contain hints
telling me what it does”.
> Lisp guys should hear most complaints and fix whatever perceived bad
> lisp lisp got. Reducing parenthesis usage
yes but not by special case syntaxes. Either stick with the existing
99% regular paren syntax, or create a sysematic M-expression
transformation, such as Mathematica.
> and reducing long abstract
> names of functions like "call-with-current-continuation" or "sqlite-
> query/effect-set" would be a beginning (and renaming such aberrations
> in an import was a welcome addition of R6RS), as would be providing
> automatic function dispatch on type of arguments so we could get far
> shorter function names thanks to function overloading -- make-
> datatypefoo, length-datatypefoo, read-datatypefoo is not really
> acceptable anymore in this day and age... why not simply (length foo),
> (read foo) etc?
>
> Also, something C headers just beats all languages out there:
> function prototypes. You read them, you know what types get in and
> what types get out. You open a Scheme R6RS lib and you see a name in
> the export list, then you need to dig for it in the source to figure
> out the parameters and try to guess what it does by peeking at the
> code... java is another stinker which decided to get rid of function
> prototypes, but at least it provides plenty of automatic IDE tools to
> do the digging for you and report the prototypes right in your nose...
Scheme lisp disappointed me very much. I don't think i'll have
anything to do with Scheme again in my life, and i don't think it'll
go anywhere by a iota. Maybe the Racket with the name change will go
somewhere, but i think in a blink of eye i'd hop onto Clojure,
newLISP, OCaml, F#, Ruby, Q/Pure, Erlang, Haskell, then i'd touch
Scheme again. Currently, the ones i really want to have some serious
working knowledge is OCaml/F#, for my math, theorem proving, geometry
visualization, related tasks...
• 〈Language, Purity, Cult, and Deception〉
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
plain text version follows.
--------------------------------------------------
Language, Purity, Cult, and Deception
Xah Lee, 2009-01-24
[this essay is roughly a 10 years personal retrospect of some
languages, in particular Scheme and Haskell.]
I learned far more Ocaml in the past 2 days than the fucking 2 months
i tried to learn Haskell, with 10 years of “I WANT TO BELIEVE” in
haskell.
The Haskell's problem is similar to Scheme lisp, being academic and of
little industrial involvement. About 10 years ago, during the dot com
era around 1999, where scripting war was going on (Perl, tcl,
Applescript, Userland Frontier, with in the corner Python, Ruby, Icon,
Scheme, in the air of Java, HTML 3, CSS, CGI, javascript), i was sold
a lie by Scheme lisp. Scheme, has a aura of elegance and minimalism
that's one hundred miles in radius. I have always been a advocate of
functional programing, with a heart for formal methods. Scheme, being
a academic functional lang, has such a association. At the time, Open
Source and Linux have just arrived on the scene in uproars, along with
Apache & Perl. The Larry Wall scumbag and Eric Raymond fuckface and
Linus T moron and Richard Stallman often appear in interviews in
mainstream media. Richard Stallman's FSF with its GNU, is quick to
make sure he's not forgotten, by a campaign on naming of Linux to GNU/
Linux. FSF announced that Scheme is its chosen scripting lang for GNU
system. Plans and visions of Guile — the new Scheme implementation, is
that due to Scheme Lisp's power will have lang conversion abilities on
the fly so programers can code in any lang anywhere in the GNU OS —
like today's Microsoft “.NET”. Around that time, i also wholeheartedly
subscribed to some A Brave Gnu World bulletin of FSF with high
expectations.
Now, it's 2009. Ten years have passed. Guile disappeared into
oblivion. Scheme is tail recursing in some unknown desert. PHP, one of
the ugly kludge pidgin, practically and quietly surpassed the
huckstered Perl in early 2000s to become the top 5 languages.
(remember? Larry Wall scumbag said P is for “Practical”. PHP's got two
“P”s.) Python has surfaced to became a mainstream. Ruby is the new
hipster on the block. Where is Scheme? O, you can still hear these
idiots continuationing tail recursions among themselves in newsgroups.
Tail recursion! Tail recursion! And their standard the R6RS in 2007,
by their own consensus, is one fucked up shit.
In 2000, i was a fair expert of unix technologies. Sys admin to
several data center's solaris boxes each costing 40 grands. Master of
Mathematica and Perl but don't know much about any other lang or langs
in general. Today, i am a expert of about 5 languages and working
experience with tens or so diverse ones. There is nothing in Scheme
i'd consider elegant, not remotely, even if we only consider R4RS.
Scheme, like other langs with a cult, sold me a lie that lasted 10
years. Similarly, Haskell fucked me with a lure of “no assignment”.
You can try to learn the lang for years and all you'll learn is that
there's something called currying and monad.
In 2005, i spent a year to learn Python. Perl is known for its
intentional egregious lies, lead by the demagogue Larry Wall. It fell
apart unable to sustain its “post-modernistic” sophistry. To me,
Python have always seemed a antidote to Perl, until you walked in. You
learned that the community is also culty, and is into certain grand
visions on beauty & elegance with its increasingly complex syntax soup
with backward incompatible python 3.0. The python fuckheads sport the
air of “computer science R us”, but their intelligence is about the
same level of Perl monger idiots. (Schemers and Haskell book authors
at least know what they are talking about. They are just ignorant
outside of academia.)
I think my story can teach tech geekers something. In my experience,
the langs that are truely a joy to learn and use, are those sans a
cult. Mathematica, javascript, PHP, are all extremely a joy to use.
Anything you want to do or learn how to do, in so far that the lang is
suitable, can be done quickly. Their docs are to the point. And today
i have to include Ocaml. It's not about whether the lang is
functional, or whether the lang is elegant, or what theoretical
advantage it has. Also, lang of strong academic background such as
Scheme and Haskell are likely to stay forever there, regardless what
is the technical nature of the lang. The background of the community,
makes half what the language is.
The above is not a terrible insight, but i suppose it should be useful
for some application. Today, there's huge number of languages, each
screaming ME! To name a few that are bubbled up by tech geekers: Arc,
Clojure, Scalar, F#, Erlang, Ruby, Groovy, Python 3, Perl6. (for a big
list, see: Proliferation of Computing Languages) So, if i want to
learn another lang down the road, and wish it to be a joy to use,
usable docs, large number of usable libraries, well supported, a
community that is not looping eternally around estheticalities, then
which one should i buy? I think Erlang, OCaml/F#, would be safe
choices, while langs like Qi, Oz, Arc, Perl6, would be most
questionable.
Disclaimer: All mentions of real persons are opinion only.Related:
Xah ∑ xahlee.org ☄
Isaiah Gilliland
> know, other new lisps (Clojure, newLISP, Arc, Racket) are all not
> Common Lisp, and they are all doing good jobs in bringing wide
> awareness of lisp (Clojure being concurrency & JVM, newLISP for good
> scripting, Arc by Paul's fame (focusing on web app i think), Racket by
> PLT Scheme's established community and now a new name). Only Qi, takes
> lisp to a new level in a CL compatible way, only if the marketing
> could be improved a bit and if CL people would be more supportive.
>
> Xah ∑ xahlee.org ☄
I actually like that logo a lot, it kinda embodies a lot about lisp.
And though I do like Conrad Barski's approach, it's not really a
professional design and could probably make people not take it
serious. I mean I actually like the mascot thing, I just think the
organization and composition of it needs to be simplified and
streamlined.
I've been going around on just about every CL site and I've never even
heard of Qi. It looks interesting I think, but what's exactly
different about it?
It's nice to see people trying to revitalize CL because, honestly, I
think if scheme ever got its game straight, and came out with the full
commercial version it plans, it would take over the lisp world. Not
saying it's better, but it the better appeal to young people for being
the easier to use side of the lisp world.
Paul Donnelly
>> I think Qi could be a great fix or improvement to Common Lisp. You
>> know, other new lisps (Clojure, newLISP, Arc, Racket) are all not
>> Common Lisp, and they are all doing good jobs in bringing wide
>> awareness of lisp (Clojure being concurrency & JVM, newLISP for good
>> scripting, Arc by Paul's fame (focusing on web app i think), Racket by
>> PLT Scheme's established community and now a new name). Only Qi, takes
>> lisp to a new level in a CL compatible way, only if the marketing
>> could be improved a bit and if CL people would be more supportive.
>>
>> Xah ∑ xahlee.org ☄
>
> I actually like that logo a lot, it kinda embodies a lot about lisp.
> And though I do like Conrad Barski's approach, it's not really a
> professional design and could probably make people not take it
> serious. I mean I actually like the mascot thing, I just think the
> organization and composition of it needs to be simplified and
> streamlined.
>
> I've been going around on just about every CL site and I've never even
> heard of Qi. It looks interesting I think, but what's exactly
> different about it?
Iirc it's got pattern matching built in and partial application, so it
assumes a more functional style of programming than you might use in CL,
but the main thing is its type system which is based on sequent
calculus. I don't understand static typing well enough to comment
intelligently on that, but it's certainly an interesting idea.
Marc Mientki
I think you would get wider reader public when your posts would be not
so long. Sometimes (but only sometimes!) I find your ideas and thought
not bad or at least interesting for reading but your opulent language is
a barier for reader like me with poor english skills. So my appeal to
you - write shorter!
reagrds
Marc
PS. Yes, I know - this is english speaking NG
Pascal J. Bourguignon
Xah Lee
On Sep 26, 6:50 am, Marc Mientki <mien...@nonet.com> wrote:
> Hello Xah Lee,
>
> I think you would get wider reader public when your posts would be not
> so long. Sometimes (but only sometimes!) I find your ideas and thought
> not bad or at least interesting for reading but your opulent language is
> a barier for reader like me with poor english skills. So my appeal to
> you - write shorter!
u rather have feature length films or trailers? :D
u see, these days lots of my writings r short. :D
i used to consider these types of writing drivels, but, as far as
netiquette, popularity, establishing friendship goes, chatty n
actually talking to each person behind a post is better, even if no
content.
nice meeting u & thanks. :D
Xah
Isaiah Gilliland
If it's something I paid to see. A feature length film. If I'm
browsing a mail list and find a post on a topic I'm half interested
but curious in. A trailer :P
namekuseijin
> On Sep 24, 12:44 pm, namekuseijin <namekusei...@gmail.com> wrote:
> > On 22 set, 18:57, Xah Lee <xah...@gmail.com> wrote:
> > 1) it assumes list comprehensions in python are imperative programming
>
> i'd go as far to say that “list comprehension” in every lang is
> imperative programing.
It's mere syntax for a function returning a list. Just because python
happens to use the `for' keyword doesn't make it imperative.
Sometimes it is more convenient, sometime not.
For instance, this is far more convenient:
[x+1 for x in [1,2,3,4,5] if x%2==0]
than this:
map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
but on the other hand, this is more convenient:
map(inc,filter(evenp,[1,2,3,4,5]))
(ignoring the lines of code for inc and evenp, of course. But as long
as they are used in many parts, it *is* more convenient)
In short, list comprehensions are useful syntatic expressions
returning lists as long as you don't care for the short functions used
in them.
> you see, one characteristic of functional programing lang is that the
> lang has lots of single-purpose functions, and the user is supposed to
> sequence or combine them for max power and flexibility.
that's exactly what a list comprehension is: a composition of map and
filter where filter may be (lambda (x) True).
> lisp comprehension is a fucking anomaly in this regards.
> i dunno which fucking idiot invented it. (those expert with its
> history, please post)
>
> from looking at the Wikipedia examples, you can see that typically it
> invents a new syntax. A better way and more in sync with functional
> lang spirit, is simply have this instead:
>
> operation(
> filterFunction(
> listGenFunction(1, 20),
> trueFalseDecisionFunction()
> )
> )
what happened to you, Xah? Weren't you the guy bashing Lisp because
it had "no syntax"? Why are you bashing a useful syntatic
construction to compose map and filter in a single expression without
much fuss?
> or in Mathematica:
>
> Select[Range@20, # > 3 &]^2
>
> in Mathematica FullForm notation, the above is:
>
> Times[
> Select[
> Range[20],
> Function[
> Greater[ Slot[1],3] ]
> ],
> 2]
>
> (formatted in a way so lispers can understand)
>
> in my style of coding, the above is typically written like this:
>
> (#*2 &) @ (Select[#,# > 3 &]&) @ Range@20
>
> See also: • 〈A Example of Mathematica Notation and List Processing〉http://xahlee.org/UnixResource_dir/writ/notations_mma.html
>
> > 2) it assumes do loops in scheme are imperative programming
>
> Of course it is. Look at the big picture. “Do loop” in any lang is
> arguably imperative.
(do ((i 0 (+ 1 i)) ; i initially 1, (+ 1 i) at each "step"
(r 0 (+ i r))) ; r initially 0, (+ i r) at each "step"
((> i 5) r)) ; when i>5, return r
=> 15
it's merely a macro (syntax) that gets transformed into this:
(let loop ((i 0)
(r 0))
(if (> i 5) r
(loop (+ 1 i) (+ i r))))
=> 15
which is merely a macro that essentially gets transformed into this:
((lambda (loop)
(loop loop 0 0))
(lambda (loop i r)
(if (> i 5) r
(loop loop (+ 1 i) (+ i r)))))
=> 15
which, as you can see, is merely function application. There's
nothing there except evaluation of arguments, application of arguments
to function and function return. It's not because they chose `do', or
`for' or `while' for naming such syntax, that it behaves the same as
their imperative homographs.
> Language, Purity, Cult, and Deception
I've read that before. A rouch ride full of "fuckfaces" and much
misunderstanding, but still an amusing read.
Xah Lee
> For instance, this is far more convenient:
> [x+1 for x in [1,2,3,4,5] if x%2==0]
> than this:
> map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
How about this:
LC(func, inputList, P)
compared to
[func for myVar in inputList if P]
the functional form is:
• shorter
• not another idiysyncratic new syntax
--------------------
now, a separate issue. Suppose we want some “list comprehension”
feature in a functional lang.
Normally, by default this can be done by
filter( map(func, inputList), Predicate)
but perhaps this usage is so frequent that we want to create a new
fuction for it, to make it more convenient, and perhaps easier to make
the compiler to optimize more. e.g.
LC(func, inputList, Predicate)
this is about whether a lang should create a new convenient function
that otherwise require 2 function combinations. Common Lisp vs Scheme
Lisp are the typical example of extreme opposites.
note, there's no new syntax involved.
--------------------
Now, let's consider another separated issue related to so-called “list
comprehension”.
Suppose we decided that generating list by a filter is so frequently
used that it worth it to create a new func for it.
LC(func, inputList, Predicate)
Now, in functional langs, in general a design principle is that you
want to reduce the number of function unless you really need. Because,
any combination of list related functions could potentionally be a new
function in your lang. So, if we really think LC is useful, we might
want to generalize it. e.g. in
LC(func, inputList, Predicate)
is it worthwhile say to add a 4th param, that says return just the
first n? (here we presume the lang doesn't support list of infinite
elements) e.g.
LC(func, inputList, Predicate, n)
what about partition the list to m sublists?
LC(func, inputList, Predicate, n, m)
what about actualy more generalized partition, by m sublist then by m1
sublist then by m2 sublist?
LC(func, inputList, Predicate, n, list(m,m1,m2,...))
what about sorting? maybe that's always used together when you need a
list?
LC(func, inputList, Predicate, n, list(m,m1,m2,...), sortPredcate)
what if actually frequently we want LC to map parallel to branches?
e.g.
LC(func, inputList, Predicate, n, list(m,m1,m2,...), sortPredcate,
mapBranch:True)
what if ...
you see, each of these or combination of these can be done by default
in the lang by sequenceing one or more functions (i.e. composition).
But when we create a new function, we really should think a lot about
its justification, because otherwise the lang becomes a bag of
functions that are non-essential, confusing.
In summary:
• “list comprehension” is a bad jargon.
• The concept of “list comprehension” is redundant. There's no
justification for the concept to exist except historical.
• The syntax of “list comprehension” in most lang is ad hoc syntax.
for those who find imperative lang good, then perhaps “list
comprehension” is good, because it adds another idiosyncratic syntax
to the lang, but such is with the tradition of imperative langs. The
ad hoc syntax aids in reading code by various syntactical forms and
hint words such as “[... for ... in ...]”.
Xah ∑ xahlee.org ☄
namekuseijin
> 2010-09-27
>
> > For instance, this is far more convenient:
> > [x+1 for x in [1,2,3,4,5] if x%2==0]
> > than this:
> > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
>
> How about this:
how about this: read before replying.
Xah Lee
hum???
i read your post quite carefully, and rather thought i replied well.
In fact, i really wanted to tell you “read before replying” before but
refrained from making any of that expression.
here's 2 previous posts about list compre.
http://groups.google.com/group/comp.lang.lisp/msg/145f6ecf29ebbdaf
http://groups.google.com/group/comp.lang.lisp/msg/62ca84062c9fcdca
Xah
namekuseijin
> On Sep 27, 12:11 pm, namekuseijin <namekusei...@gmail.com> wrote:
>
> > On 27 set, 16:06, Xah Lee <xah...@gmail.com> wrote:> 2010-09-27
>
> > > > For instance, this is far more convenient:
> > > > [x+1 for x in [1,2,3,4,5] if x%2==0]
> > > > than this:
> > > > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
>
> > > How about this:
>
> > [snip]
>
> > how about this: read before replying.
>
> hum???
>
> i read your post quite carefully, and rather thought i replied well.
I don't think so. You completely missed the point where I agreed
about filter map being more convenient when calling predefined
functions and also the detailed explanation of why do in scheme is not
imperative at all.
toby
> On Sep 26, 2:59 pm, Xah Lee <xah...@gmail.com> wrote:
>
>
>
>
>
> > On Sep 26, 6:50 am, Marc Mientki <mien...@nonet.com> wrote:
>
> > > Hello Xah Lee,
>
> > > a barier for reader like me with poor english skills. So my appeal to
> > > you - write shorter!
>
> > u rather have feature length films or trailers? :D
>
> > u see, these days lots of my writings r short. :D
> > Xah
>
> If it's something I paid to see. A feature length film. If I'm
> browsing a mail list and find a post on a topic I'm half interested
> but curious in. A trailer :P
& a tweet = a headline
Xah Lee
On Sep 27, 4:58 pm, namekuseijin <namekusei...@gmail.com> wrote:
> On 27 set, 18:39, Xah Lee <xah...@gmail.com> wrote:
> > On Sep 27, 12:11 pm, namekuseijin <namekusei...@gmail.com> wrote:
>
> > > On 27 set, 16:06, Xah Lee <xah...@gmail.com> wrote:> 2010-09-27
>
> > > > > For instance, this is far more convenient:
> > > > > [x+1 for x in [1,2,3,4,5] if x%2==0]
> > > > > than this:
> > > > > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
>
> > > > How about this:
>
> > > [snip]
>
> > > how about this: read before replying.
>
> > hum???
>
> > i read your post quite carefully, and rather thought i replied well.
>
> I don't think so. You completely missed the point where I agreed
> about filter map being more convenient when calling predefined
> functions
? are you agreeing on some part or whole? if whole, i don't see the
point of your point, so am annoyed. If agreeing on part, which part?
because the point is about the whole list comprehension being
redundant, in syntax, semantics, concept itself. And i hope my last
post is a more standard-alone exposition of this. I'll edit it and
elaborate it with more examples and detail on my website in a few
days.
> and also the detailed explanation of why do in scheme is not
> imperative at all.
hum?
if i recall correctly, you refer to this:
«Schemers are a pretty desunited group. Many in the Racket group
don't go along with other implementors, like the guy who proposed for
a previous RNRS the DO macro as a shortcut for a named let. DO is no
more of a imperative artifact than a named LET because it is a named
let, which in turn is just a function call with more conveniently
placed bindings. But thanks to lame politics, it's got bad rap.»
from your post at http://groups.google.com/group/comp.lang.lisp/msg/da530a4b112fadfc
i am not in Scheme lisp community, so i don't know what you are
saying. But on the whole, you seems to be making a side-note to
mention how a mockery isn't logically consistent...
in anycase, how's “do” not imperative?
how's “do” a “named let”? can you show example or reference of that
proposal? (is it worthwhile?)
as i said, regarding do: “do” in general in any lang is simply
impreative. We don't even have to know the details. I don't care
whatnot fuck proposal from whatnot lisp of what's actually going on.
If it is named “do”, it is imperative.
though about the PLT/Racket team, i seem to also have perceived that
it's a sub-group from other Scheme groups, even though im not in
Scheme community much.
Xah
namekuseijin
> ? are you agreeing on some part or whole? if whole, i don't see the
> point of your point, so am annoyed. If agreeing on part, which part?
the part you snipped away.
> > and also the detailed explanation of why do in scheme is not
> > imperative at all.
>
> hum?
>
> if i recall correctly, you refer to this:
no, this is the post:
http://groups.google.com.br/group/comp.lang.lisp/msg/3f10f4e4c3c467f0
which you hastily snipped away in order to cram ever more list
comprehension bashing...
> in anycase, how's “do” not imperative?
>
> how's “do” a “named let”? can you show example or reference of that
> proposal? (is it worthwhile?)
I'll post it again in the hope you'll read this time:
"
(do ((i 0 (+ 1 i)) ; i initially 1, (+ 1 i) at each "step"
(r 0 (+ i r))) ; r initially 0, (+ i r) at each "step"
((> i 5) r)) ; when i>5, return r
=> 15
it's merely a macro (syntax) that gets transformed into this:
(let loop ((i 0)
(r 0))
(if (> i 5) r
(loop (+ 1 i) (+ i r))))
=> 15
which is merely a macro that essentially gets transformed into this:
((lambda (loop)
(loop loop 0 0))
(lambda (loop i r)
(if (> i 5) r
(loop loop (+ 1 i) (+ i r)))))
=> 15
which, as you can see, is merely function application. There's
nothing there except evaluation of arguments, application of arguments
to function and function return. It's not because they chose `do', or
`for' or `while' for naming such syntax, that it behaves the same as
their imperative homographs."
> as i said, regarding do: “do” in general in any lang is simply
> impreative. We don't even have to know the details. I don't care
> whatnot fuck proposal from whatnot lisp of what's actually going on.
> If it is named “do”, it is imperative.
It's not: one can name factorial do. It's just a name. Who doesn't
like do? It's short, to the point...
Xah Lee
> in anycase, how's “do” not imperative?
ultimately, all lang gets transformed at the compiler level to become
machine instructions, which is imperative programing in the ultimate
sense.
You say that “do” is merely macro and ultimately function application.
But to what level should we go down this chain on how the language
actually works when evaluating a function in source code?
any functional lang, quickly becomes imperative when compiled to some
intermediate code or interpreted. In a sense, it can't be any other
way. Functions are abstract mathematical ideas, while “do” loop or any
instruction are actual steps of algorithms.
Xah ∑ xahlee.org ☄
namekuseijin
That is true as of Mathematica too. Difference being that do in
scheme is pretty-much user-level syntax. If you look in most (good)
implementations sources, do and let are defined in scheme itself, not
C or lower-level: C code only deals with transforming lambda
application and tail calls into proper gotos.
So, as far as we're talking about scheme, haskell or Mathematica code,
it's all functional in its abstraction context.
do syntax does allow for imperative commands to be issued in scheme,
just like let. It does not mean it was used in said examples nor that
do is automatically inherently imperative just because of choice of
name. imperative do -> (do (steppers ...) (final-condition? result)
malign-imperative-code-here ...)
so, now that we got it clear why do in scheme is not (inherently)
imperative why were you bashing useful (at times) functional syntax in
the form of list comprehensions again?
Pascal J. Bourguignon
> any functional lang, quickly becomes imperative when compiled to some
> intermediate code or interpreted. In a sense, it can't be any other
> way. Functions are abstract mathematical ideas, while “do” loop or any
> instruction are actual steps of algorithms.
This is so only when you compile to a procedural machine. If you
compile to a functional machine, you don't have this problem.
One primitive feature you would need in a functional machine, is an
infinite associative memory. Or a simulation thereof with a garbage
collector hidden in the hardware.
Xah Lee
le's get precise. The argument i want to make, is this:
• “list comprehension” is a very bad jargon; thus harmful to
functional programing or programing in general. Being a bad jargon, it
encourage mis-communication, mis-understanding.
• “list comprehension” is a redundant concept in programing. The
concept is of historical interest. e.g. when people talk about the
history of computer languages. The LC can simply be filter(map(func,
list), predicate).
• The special syntax of “list comprehension” as it exists in many
langs, are not necessary. It can simply be a plain function, e.g
LC(function, list, filter).
I gave a stand-alone explanation of these points at:
http://groups.google.com/group/comp.lang.lisp/msg/329b3b68ff034453
Do you disagree or agree with the above?
This is the point _I_ want to argue about, but you don't seem to admit
any part of it, but you seems to want to discuss about “do” in Scheme
lisp being functional.
So, perhaps we can now focus on this subject:
The “do” in Scheme lisp is not imperative, or, it can be considered as
functional.
Alright. To be honest, i haven't had enough experience to comment on,
but in general, i understand the example you've given, and i disagree.
Full report on your argument on this is given at:
http://groups.google.com/group/comp.lang.lisp/msg/87a987070e80231f
Now, in your message (quoted above), you made further argument on
this. I think the main point is this, quote:
«do syntax does allow for imperative commands to be issued in scheme,
just like let. It does not mean it was used in said examples nor that
do is automatically inherently imperative just because of choice of
name. imperative do -> (do (steppers ...) (final-condition? result)
malign-imperative-code-here ...)»
i don't think your argument is forceful enough.
It appears that by this argument you even say that “let” is not
functional.
Here, the issue verges on what is functional? What is a function? If a
function in lisp is defined as macro, does it ceases to be considered
as a function? Likewise, if a lisp's has “for” loop that is defined as
a macro, is that “for” now considered a function?
this is getting quite iffy. What level or aspect are we considering?
In each lang, usually they define certain terms specifically to the
lang, and to various degree of precision. For eample, the term
“object” means very different things in a technical way in different
langs. Same for the word “function”, “keyword”, “command”, “module”,
“package” ...
So, overall, i consider your argument for “do” in Scheme lisp being
functional is weak, or trivial. It seems to be a pet peeve. You got
annoyed because i seem to have ignored it entirely. But i got annoyed
by you because you don't get the point about what i consider more
significant opinion on “list comprehension”, which you totally ignored
and kept at hacking the “do” in Scheme lisp.
Xah ∑ xahlee.org ☄
Andrew Reilly
I don't know of examples that have extended to main memory systems, but
there have certainly been experimental data-flow processors that
approximated that description, at the instruction set level. And of
course, all modern out-of-order processor cores re-translate the
"imperative" instruction stream into a mostly-functional internal
representation with register names mapped into a larger space, to
accommodate them executing out of order.
Cheers,
--
Andrew
George Neuner
wrote:
And many of the standard transformations done internally by compilers
for imperative languages are meant to "functionalize" the code because
functional programs are easier to analyze and optimize.
George
namekuseijin
> • “list comprehension” is a very bad jargon; thus harmful to
> functional programing or programing in general. Being a bad jargon, it
> encourage mis-communication, mis-understanding.
I disagree: it is a quite intuitive term to describe what the
expression does.
> • “list comprehension” is a redundant concept in programing. The
> concept is of historical interest. e.g. when people talk about the
> history of computer languages. The LC can simply be filter(map(func,
> list), predicate).
I agree it is redundant. Like pretty much all syntax: all one needs
is a way to define functions and to apply function to arguments (or
assignment and pre-defined loops for imperative folks). Syntax may
still be more convenient, though.
Which is strange since you were an ardent syntax lover a few
iterations ago.
> • The special syntax of “list comprehension” as it exists in many
> langs, are not necessary. It can simply be a plain function, e.g
> LC(function, list, filter).
I disagree. Syntax may be redundant, but it is there to be
convenient.
I'll quote it again:
"For instance, this is far more convenient:
[x+1 for x in [1,2,3,4,5] if x%2==0]
than this:
map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
but on the other hand, this is more convenient:
map(inc,filter(evenp,[1,2,3,4,5]))
(ignoring the lines of code for inc and evenp, of course. But as
long
as they are used in many parts, it *is* more convenient)
In short, list comprehensions are useful syntatic expressions
returning lists as long as you don't care for the short functions
used
in them."
> «do syntax does allow for imperative commands to be issued in scheme,
> just like let. It does not mean it was used in said examples nor that
> do is automatically inherently imperative just because of choice of
> name. imperative do -> (do (steppers ...) (final-condition? result)
> malign-imperative-code-here ...)»
>
> i don't think your argument is forceful enough.
>
> It appears that by this argument you even say that “let” is not
> functional.
In the case of Lisps, it depends on context: let is an expression
returning a value, but Lisps are not purely functional languages and
you *may* use imperative statements in the body, resulting in useful
side-effect computations.
That's why I said do is no more imperative than let: 1) because it
*is* let and 2) because Lisps *allow* imperative constructs in the
body of lambdas. do is not inherently imperative in the same sense
Lisp/Scheme is not inherently imperative: they allow you to do purely
functional evaluation of expressions but also to tint the computations
with side-effects... your choice.
> So, overall, i consider your argument for “do” in Scheme lisp being
> functional is weak, or trivial. It seems to be a pet peeve.
It is a pet peeve in that you call `do' imperative without arguments
while a few other Schemers call `do' imperative on the basis of
political bickering. Nobody gives `do' a chance of the base of it
being what it is: a macro transform into let. Any imperative
programming you do with `do' will get the same effect as if you do the
same imperative programming with let. Imperative or functional, it's
up to the user, not inherently from any language construct.
> You got
> annoyed because i seem to have ignored it entirely. But i got annoyed
> by you because you don't get the point about what i consider more
> significant opinion on “list comprehension”, which you totally ignored
> and kept at hacking the “do” in Scheme lisp.
It's because I don't think I have much to comment on list
comprehensions other than being useful syntax at times for an
expression returning a list.
w_a_x_man
> Python did good in replacing convoluted syntax, for clearer and more
> direct equivalent, like:
>
> map(lambda x:x+1,[1,2,3,4,5])
> [x+1 for x in [1,2,3,4,5]]
> ==> [2,3,4,5,6]
>
> List comprehensions also have the added benefit of being an all-in-1
> replacement for map and filter just nicely:
>
> filter(lambda x:x%2==0,[1,2,3,4,5])
> [x for x in [1,2,3,4,5] if x%2==0]
> ==> [2,4]
Ruby:
(1..5).select{|n| 0==n%2}
Xah Lee
> On 28 set, 19:38, Xah Lee <xah...@gmail.com> wrote:
>
> > • “list comprehension” is a very bad jargon; thus harmful to
> > functional programing or programing in general. Being a bad jargon, it
> > encourage mis-communication, mis-understanding.
>
> I disagree: it is a quite intuitive term to describe what the
> expression does.
what's your basis in saying that “list comprehension” is intuitive?
any statics, survery, research, references you have to cite?
to put this in context, are you saying that lambda, is also intuitive?
“let” is intuitive? “for” is intuitive? “when” is intuitive? I mean,
give your evaluation of some common computer language termilogies, and
tell us which you think are good and which are bad, so we have some
context to judge your claim.
For example, let us know, in your view, how good are terms: currying,
lisp1 lisp2, tail recursion, closure, subroutine, command, object. Or,
perhaps expound on the comparative merits and meaning on the terms
module vs package vs add-on vs library. I would like to see your view
on this with at least few paragraphs of analysis on each. If you, say,
write a essay that's at least 1k words on this topic, then we all can
make some judgement of your familiarity and understanding in this
area.
Also, “being intuitive” is not the only aspect to consider whether a
term is good or bad. For example, emacs's uses the term “frame”. It's
quite intuitive, because frame is a common english word, everyone
understands. You know, door frame, window frame, picture frame, are
all analogous to emacs's “frame” on a computer. However, by some turn
of history, in computer software we call such as “window” now, and by
happance the term “window” also has a technical meaning in emacs, what
we call “split window” or “pane” today. So, in emacs, the term “frame”
and “window” is confusing, because emacs's “frame” is what we call
“window”, while emacs's “window” is what me might call a pane of a
split window. So here, is a example, that even when a term is
intuitive, it can still be bad.
as another example, common understanding by the target group the term
is to be used is also a important aspect. For example, the term
“lambda”, which is a name of greek char, does not convey well what we
use it for. The word's meaning by itself has no connection to the
concept of function. The char happens to be used by a logician as a
shorthand notation in his study of what's called “lambda
calculus” (the “calculus” part is basically 1700's terminology for a
systematic science, especially related to mechanical reasoning).
However, the term “lambda” used in this way in computer science and
programing has been long and wide, around 50 years in recent history
(and more back if we trace origins). So, because of established use,
here it may decrease the level of what we might think of it as a bad
jargon, by the fact that it already become a standard usage or
understanding. Even still, note that just because a term has establish
use, if the term itself is very bad in many other aspects, it may
still warrant a need for change. For one example of a reason, the
argon will be a learning curve problem for all new generations.
You see, when you judge a terminology, you have to consider many
aspects. It is quite involved. When judging a jargon, some question
you might ask are:
• does the jargon convey its meaning by the word itself? (i.e. whether
the jargon as a word is effective in communication)
• how long has been the jargon in use?
• do people in the community understand the jargon? (e.g. what
percentage)
each of these sample questions can get quite involved. For example, it
calls for expertise in linguistics (many sub-fields are relevant:
pragmatics, history of language, etymology), practical experience in
the field (programing or computer science), educational expertise
(e.g. educators, professors, programing book authors/teachers),
scientific survey, social science of communication...
also, you may not know, there are bodies of professional scientists
who work on terminologies for publication. It is not something like “O
think it's good, becus it is intuitive to me.”.
I wrote about 14 essays on various jargons in past decade. You can
find them on my site.
i removed your arguments on other parts about “list comprehension”,
because i didn't find them valuable. (barely read them) However, i
appreciate your inputs on the “do” in Scheme lisp has a functional
usage, and some other misc chat info from the beginning of this thread
on comp.lang.lisp.
Xah ∑ xahlee.org ☄
namekuseijin
(define (select f from to)
(do ((i to (- i 1)) ; because recursive consing generates reverse
lists
(r '() (if (f i) (cons i r) r)))
((< i from) r)))
(define (p x) (display x)(newline))
(p (select even? 1 10000))
;p (1..10000).select{|n| 0==n%2}
; not so cool anymore
plus, compiled with chicken or some other native code scheme compiler
chicken silly.ss && gcc -march=x86-64 -O3 silly.c -o silly
namekuseijin@namek:~/dev/scheme$ time ruby -e 'p (1..10000).select{|n|
0==n%2}' > /dev/null
real 0m0.019s
user 0m0.010s
sys 0m0.010s
namekuseijin@namek:~/dev/scheme$ time ./silly > /dev/null
real 0m0.007s
user 0m0.000s
sys 0m0.000s
; silly, huh?
namekuseijin
> On Sep 29, 11:02 am, namekuseijin <namekusei...@gmail.com> wrote:
>
> > On 28 set, 19:38, Xah Lee <xah...@gmail.com> wrote:
>
> > > • “list comprehension” is a very bad jargon; thus harmful to
> > > functional programing or programing in general. Being a bad jargon, it
> > > encourage mis-communication, mis-understanding.
>
> > I disagree: it is a quite intuitive term to describe what the
> > expression does.
>
> what's your basis in saying that “list comprehension” is intuitive?
it generates a list from syntax comprehended in list-like syntax!
> any statics, survery, research, references you have to cite?
how about common sense?
> to put this in context, are you saying that lambda, is also intuitive?
No.
> “let” is intuitive?
yes, it's focking everyday term used in the same way: let this be
this and that be that and thus...
> “for” is intuitive?
yes, it's focking everyday term used in the same way: for this and
this and this do that...
> “when” is intuitive?
when this, then that?
common sense, Xah!
> For example, let us know, in your view, how good are terms: currying,
> lisp1 lisp2, tail recursion, closure, subroutine, command, object.
These terms have a technical meaning coming from historic events in
the areas they are used. It's like that in all areas, you may also
bash medicine jargon if you want.
Though subroutine, command and object are pretty intuitive by common
sense alone.
> perhaps expound on the comparative merits and meaning on the terms
> module vs package vs add-on vs library. I would like to see your view
> on this with at least few paragraphs of analysis on each.
They are all the same shit. These were developed by managers and
buzzwriters... ;)
> Also, “being intuitive” is not the only aspect to consider whether a
> term is good or bad. For example, emacs's uses the term “frame”. It's
> quite intuitive, because frame is a common english word, everyone
> understands. You know, door frame, window frame, picture frame, are
> all analogous to emacs's “frame” on a computer. However, by some turn
> of history, in computer software we call such as “window” now, and by
> happance the term “window” also has a technical meaning in emacs, what
> we call “split window” or “pane” today. So, in emacs, the term “frame”
> and “window” is confusing, because emacs's “frame” is what we call
> “window”, while emacs's “window” is what me might call a pane of a
> split window. So here, is a example, that even when a term is
> intuitive, it can still be bad.
emacs is all FUBAR in more than one way. being intuitive is not
exactly what it is known for... ;)
well, I shouldn't be bashing it, my vim is not that funky among
commoners anymore anyway... :p
> I wrote about 14 essays on various jargons in past decade. You can
> find them on my site.
yeah, I've read them once in a while...
w_a_x_man
Quite ugly.
>
> Ruby:
>
> (1..5).select{|n| 0==n%2}
(1..5).select{|n| n.even?}
==>[2, 4]
(1..5).select( &:even? )
==>[2, 4]
Raffael Cavallaro
>>
>>> filter(lambda x:x%2==0,[1,2,3,4,5])
>>> [x for x in [1,2,3,4,5] if x%2==0]
>>> ==> [2,4]
>
> Quite ugly.
OK, so non-uniform syntax is ugly. Got it.
>
>>
>> Ruby:
>>
>> (1..5).select{|n| 0==n%2}
>
> (1..5).select{|n| n.even?}
> ==>[2, 4]
> (1..5).select( &:even? )
> ==>[2, 4]
But this non-uniform syntax is supposed to be beautiful.
Mr. Pot, allow me to introduce Mr. Kettle.
For the ironically impaired, non-uniform syntax, be it Python, or Ruby,
or what have you, imposes additional cognitive overhead on the
programmer *and* makes it much more difficult to have a full featured
macro system. IOW, non-uniform syntax is lose-lose. Good thing both
scheme and lisp (the two newsgroups this thread is going out to) have
uniform syntax.
warmest regards,
Ralph
--
Raffael Cavallaro
Andrew Reilly
> Good thing both
> scheme and lisp (the two newsgroups this thread is going out to) have
> uniform syntax.
This argument is often made, but I don't see how it is true or useful:
the macro systems of both scheme and lisp operate on the parsed AST, and
one must assume that any amount of grungy and arbitrary syntax must still
wind up as part of the AST at the point of interpretation or compilation,
or macro application. It means that the macro writer has to be aware of
manipulating the AST, rather than the source text, but I doubt that's an
insurmountable issue. (Of course it does complicate the writing of
macros in languages like C, where the macro mechanism is a text-level
preprocessor.)
Cheers,
--
Andrew
namekuseijin
cool, is that a pissing contest? I feel an urge:
(pee 1 5 even?)
; given:
(define (pee from to filter?)
((range to from) '() (filtered filter? cons)))
(define (filtered filter? reducer)
(lambda (i o) (if (filter? i) (reducer i o) o)))
(define (range from to . step)
(let ((> (if (> from to) < >))
(+ (if (> from to) - +))
(step (if (null? step) 1 (car step))))
(lambda (init reducer)
(let go ((from from) (result init))
(if (> from to) result
(go (+ from step) (reducer from result)))))))
plus, by compiling it with, say, chicken, I can get some pretty nice
results for
(p (pee 1 10000 even?))
; given p like ruby's:
(define (p . args) (for-each display args)(newline))
982 9984 9986 9988 9990 9992 9994 9996 9998 10000)
real 0m0.026s
user 0m0.000s
sys 0m0.000s
while with time ruby -e 'p (1..10000).select{|n| n.even? } I get:
972, 9974, 9976, 9978, 9980, 9982, 9984, 9986, 9988, 9990, 9992, 9994,
9996, 9998, 10000]
real 0m0.042s
user 0m0.010s
sys 0m0.000s
namekuseijin
> On Tue, 19 Oct 2010 10:34:05 -0400, Raffael Cavallaro wrote:
> > Good thing both
> > scheme and lisp (the two newsgroups this thread is going out to) have
> > uniform syntax.
>
> This argument is often made, but I don't see how it is true or useful:
> the macro systems of both scheme and lisp operate on the parsed AST, and
> one must assume that any amount of grungy and arbitrary syntax must still
> wind up as part of the AST at the point of interpretation or compilation,
> or macro application. It means that the macro writer has to be aware of
> manipulating the AST, rather than the source text, but I doubt that's an
> insurmountable issue.
the source text of Lisp is pretty much an AST.
Thomas A. Russ
And the functions for manipulating the AST are common, everyday lisp or
scheme functions that all programmers learn in their first few lessons.
There isn't any arcane interface that needs to be learned in order to
manipulate the AST. It all comes "naturally".
--
Thomas A. Russ, USC/Information Sciences Institute
Raffael Cavallaro
> This argument is often made, but I don't see how it is true or useful:
> the macro systems of both scheme and lisp operate on the parsed AST
The parsed AST of lisp is lists (the data structure). The surface
syntax of lisp is lists (the printed representation). Lisp is fairly
adept at manipulating lists (the data structure). Writing macros in
lisp is therefore fairly straightforward. Incremental development is
possible because macroexpansion yields forms (list data structures),
which has the same printed representation - the same surface syntax -
as ordinary code.
When the surface syntax of a language differs significantly from the
AST, writing full featured macros (macros that can do arbitrary
manipulations of the AST) requires that the macro writer deal with two
different syntaxes - the surface syntax, and the AST syntax.
Uniform syntax is a win because:
1. programmers don't need to keep numerous arbitrary syntactic rules
and markers (different kinds of delimiters, various punctuation) in
their head along with the real task at hand - the problem domain and
knowledge of what the code does.
2. programmers don't need to operate in two different syntactic worlds
in order to write full featured macros.
Tim Bradshaw
> This argument is often made, but I don't see how it is true or useful:
> the macro systems of both scheme and lisp operate on the parsed AST, and
> one must assume that any amount of grungy and arbitrary syntax must still
> wind up as part of the AST at the point of interpretation or compilation,
> or macro application.
I think this is right. But languages with a very simple & uniform
surface syntax tend to have very simple and uniform ASTs, because if
they didn't they'd be so hard to read. Languages with complex surface
syntax are typically using that complicated syntax to indicate that
there are lots of complicated & hard-wired things in the language.
Andrew Reilly
Hmm. That's probably true, too.
I was thinking more along the lines of dylan, or perhaps DrScheme (aka
Racket, now) that has a few Algol and Java surface syntax variants
available: I'd be very surprised if the macro systems stopped working
just because the reader had been grunged-up.
Cheers,
--
Andrew
Pascal J. Bourguignon
The point is that the macro will generate a sexp. So why would you want
to write your source otherwise than as sexps?
Andrew Reilly
Who can say why people do the things that they do? Never the less, quite
a few people seem to want to write their source in Java or Python or
whatever. Personally, I prefer sexps. I just wanted to point out that
having a surface syntax that wasn't a direct representation of sexps
wasn't necessarily an argument against a lisp-style macro system that
could manipulate a post-parse AST representation of the program. Not
having a standardised post-parse AST representation in any language
besides the lisps *is* a pretty big practical impedement, though.
Cheers,
--
Andrew