In a recent post in the thread “Announcing a new release of Lisp1”,
Blake McBride wrote some reasons he doesn't like Scheme lisp. Among
which, he explained how Scheme's inconsistency in treating the NIL and
#f. Namely, that it separates nil from its boolean #f, breaking what's
typical in lisp of considering just nil as false and everything else
as true, but Scheme does not make this separation consistently, in the
sense that a if a boolean is expected (such as in “if” construct) but
boolean is not given, it however treats it as valid boolean.
The post in question is this:
Newsgroups: comp.lang.lisp, comp.lang.scheme
From: Blake McBride <·····@mcbride.name>
Date: Mon, 28 Jan 2008 19:48:30 -0600
Subject: Re: Announcing a new release of Lisp1
Message-ID: <···············@news.supernews.com>
http://groups.google.com/group/comp.lang.lisp/msg/6d2eeffd40b5a4a5?dmode=source
--------------------
I replied to that post, indicating Mathematica's behavior, which, has
symbols Tru and False, and when a construct expect a boolean, it must
be a boolean. So, in this respect, the lang does not suffer Scheme
Lisp's inconsistency.
Recently, while reading Paul Graham's new lang “arc”, i noticed that
the lang does not have a dedicated boolean entity, but treat it like
traditional lisp, of nil or empty list as false and everything else a
strue.
See: arc tutorial:
http://ycombinator.com/arc/tut.txt
Quote:
«It sometimes causes confusion to use the same thing for falsity and
the empty list, but many years of Lisp programming have convinced me
it's a net win, because the empty list is set-theoretic false, and
many Lisp programs think in sets.»
Of the past i've skim'd his essays about arc, i think arc in my
opinion will be one of the most stupid language, and i bet it will not
be popular. (it may be, in the sense that Python or Perl is/was/will-
be popular, due to a charismatic leader going great lengths to peddle
it)
In particular, i think arc is based on a utter stupid premise, namely,
some conception about “hackers” (which we take it to mean elite
programers). It seems to me that Paul Graham has a infatuation with
the word hacker. This is most illustrated in this quote:
«I think the answers to these questions can be found by looking at
hackers, and learning what they want. Programming languages are for
hackers, and a programming language is good as a programming language
(rather than, say, an exercise in denotational semantics or compiler
design) if and only if hackers like it.»
quoted from http://www.paulgraham.com/popular.html
--------------------------
First of all, i hate the word “hacker”. I'd prefer the word great
programer, knowledgeable programer, experienced programer,
accomplished programer. What the motherfuck is with the fashions and
trendy word “hacker”?
Now, if we take the word “hacker”, to mean educated, knowledgeable,
experienced, accomplished programer, which is reasonably what Paul
Graham meant. Then, i think his infatuation with such programers as a
basis for his lang design, really puts a death knell to his lang.
My concept, of a popular language, becoming popular by its good design
and quality, is actually the opposite of being a “hacker's lang”.
Namely, the language must be most easy to use, that the most people
understand it without requiring some tortuitous concepts invented by
computer “scientist” morons. The lang should have thousands or all
possible functions simply as built-in. Works out of the box.
In a sense, this is already confirmed by reality, of langs that's born
in the past 2 decades. Namely, Python, PHP, Javascript. PHP is already
one of the top 5 most deployed language, and Javascript is a immediate
a follower.
They are easy to use, has wide number of things built-in, does not
require tortuitous computer “scientist-morons”'s fucked up behind-the-
scenes concepts.
--------------------------
In this post, i like to address how not having a dedicate boolean is a
hack, which in general results confusion and confoundness to the users
of the language.
This is a essay i've written previously. The perm url is here:
The Hack of bitmask used as Boolean Parameters
http://xahlee.org/UnixResource_dir/writ/bitmask.html
The following is a plain text version.
-----------------------------
The Hack of bitmask used as Boolean Parameters
Xah Lee, 2007-04-23
In this article, i explain how the use of bit masks is a hack in many
imperative languages.
Often, a function will need to take many True/False parameters. For
example, suppose i have a function that can draw a rainbow, and each
color of the rainbow can be turned on or off individually. My function
specification can be of this form: “rainbow(red, orange, yellow,
green, blue, violet, purple)”. Each parameter is a true or false
value. So, to draw a rainbow with only red and yellow stripes on, one
would code, for example “rainbow(t,f,t,f,f,f,f)”, where “t” stands for
true and “f” stands for false. (or, similar values for the true/false
of the language's boolean system)
The problem with this simple approach is that when a function has too
many parameters, “which position means what” becomes difficult to
remember and manage. Imagine:
“MissleControl(t,f,t,t,f,f,f,t,f,t,t,t,t,f,f,f,f,t,f,f)”.
Alternatively, a high-level language may provide a system for named
parameters. So, for example, the function may be called like this with
2 arguments “rainbow(red:t, yellow:t)”, meaning, supply true values to
the parameters named “red” and “yellow”. Parameters not given may
automatically assumed to have false values by default. Similarly, the
language can simply have the function call look like this:
“rainbow(red, yellow)”, where omitted parameter names simply means
false.
In many low-level languages, the need for the situation where a
function has many true/false parameters, is dealt with by using a
concept of bit-mask that came from low-level languages. The way to
call this rainbow function would now look like this: “rainbow(red |
yellow)”. On the surface, it seems just a syntax variation. But
actually, the “red” and “yellow” here are global constants of type
integer, defined by the language, and the “|” is actually a bit-wise
binary operator. To explain this to a educated person (e.g. a
mathematician) but who are not a professional programer, it gets a bit
complex as one has to drag in binary notation, boolean operation on
binary notation realized as a sequence of slots, and the the language
designer's laziness in resorting to these instead of a high-level
interface of named parameters.
The hack of using the so-called bit-mask as a interface for functions
that need named parameters, is similar to languages using “1” and “0”
as the true/false symbols in its boolean system, and languages using
the “or” operator “||” as a method of nested “if else” program flow
constructs. The problem with these hacks, is that they jam logically
disparate semantics into the same construct. Their effects is making
the source code more difficult to read, and thus increased programer
error.
It may seem like nickpicking to say that it is a hack. However, when
many such seemingly trivially improper designs appear in a language,
adds up to the language's illness, and overall making the language
difficult to learn, difficult to read, difficult to extend, increase
programing errors, and most importantly, reduce a clear understanding
of key concepts.
Unix and C, are the primary perpetrator of this sin. Due to their
“$free$” and “speedy” and “simplistic” nature as cigarettes given to
children, have passed these designs to many imperative languages and
left programers not understanding the basic issues of a function's
parameters and named parameters.
Examples of using bitmask as a hack:
• Many functions in C. (e.g. fcntl)
• Unix's function/“command line tool”'s error values. (as bits)
• Perl's “sysopen”, “select”, and others.
• Second Life's Linden Scripting Language. (see Linden Scripting
Language Problems )
A example of confusion about function's parameters is exhibited in
unix's bewildering, inconsist syntaxes in its command line tools's
ways of taking arguments. (some parameter influence other parameters.
Argument order sometimes matter, sometimes doesn't, sometimes causing
unintented output and sometimes causing syntax error. Named parameters
sometimes have the names optional(!). Named parameters that are
predicates sometimes act by their presence along, sometimes by their
value, sometimes accept both, sometimes causes syntax error. Some
defaults are supplied to unnamed parameters, and some are to named
parameters. Some parameters has synonyms. ...)
For another example in a more modern language, is Python's
“re.search()” function for text pattern matching. Its optional third
parameter is a bitmask. (See Regular Expressions in Python )
As a example of not clearly understanding a function's parameters and
the need and role of named parameters in computing languages, Python's
“sorted” function as well as its “lambda” construct are both victims.
Further readings:
* Sorting in Python and Perl
* Python Doc Problem Example: sort()
* Lambda in Python 3000
If a bit-field appears as a function's parameter, it is not
necessarily a hack. For example, functions dealing wiht IP addresses
or otherwise TCP/IP protocols, where the networking protocol primarily
deals with bits, bytes, and bitmasks. Other examples would be
functions in a byte processing package, or binary logic
algorithm, ...etc.
-----------------------------
Xah
···@xahlee.org
∑ http://xahlee.org/
☄