From: Kaz Kylheku
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <20081211231321.223@gmail.com>
On 2008-11-26, Xah Lee <······@gmail.com> wrote:
> comp.lang.lisp,comp.lang.functional,comp.lang.perl.misc,comp.lang.python,comp.lang.java.programmer
>
> 2008-11-25
>
> Recently, Steve Yegge implemented Javascript in Emacs lisp, and
> compared the 2 languages.
>
> http://steve-yegge.blogspot.com/
> http://code.google.com/p/ejacs/
>
> One of his point is about emacs lisp's lack of namespace.
>
> Btw, there's a question i have about namespace that always puzzled me.
>
> In many languages, they don't have namespace and is often a well known
> sour point for the lang. For example, Scheme has this problem up till
> R6RS last year.

Scheme hasn't officially supported breaking a program into multiple files until
R6RS. If the language is defined in terms of one translation unit, it doesn't
make sense to have a namespace feature.

> PHP didn't have namespace for the past decade till
> about this year. Javascript, which i only have working expertise,
> didn't have namespace as he mentioned in his blog.

Javascript programs are scanned at the character level by the browser as part
of loading a page.  So there are severe practical limitations on how large
Javascript programs can be.

Namespaces are useful only in very large programs.

> Elisp doesn't have
> name space and it is a well known major issue.

C doesn't have namespaces, and yet you have projects like the Linux kernel
which get by without this.

Given that the Linux kernel can do without namespaces, it's easy to see how
Javascript and Elisp can survive without it.

> Of languages that do have namespace that i have at least working
> expertise: Mathematica, Perl, Python, Java. Knowing these langs
> sufficiently well, i do not see anything special about namespace. The
> _essence_ of namespace is that a char is choosen as a separator, and
> the compiler just use this char to split/connect identifiers.

The essence of a true namespace or package system or whatever is that you can
establish situations in which you use the unqualified names.

You can emulate namespaces by adding prefixes to identifiers, which is
how people get by in C.

In C, you can even get the functionality of short names using the preprocessor.

I have done this before (but only once). In a widely-used public header file, I
prefixed all of the names of struct members (because struct members are not
immune to clashes: they clash with preprocessor symbols!)

  struct foo {
    int foo_category;
    time_t foo_timestamp;
    /* ... */
  }

Inside the implementation module, I made macros for myself:

  #define category foo_category
  #define timestamp foo_timestamp

In this way, I didn't have to edit any of the code in order to move the struct
members into the namespace. Expressions like ``pf->category'' continued to work
as before.

> Although i have close to zero knowledge about compiler or parser, but
> from a math point of view and my own 18 years of programing
> experience, i cannot fathom what could possibly be difficult of
> introducing or implementing a namespace mechanism into a language.

The same things that make it difficult to add anything to a language, namely
the stupid way in which languages are designed to get in the way of extension.

What would it take to add namespaces to C, for instance?

If you have any proposal for a new C feature, the ISO C people encourage you to
develop a proof-of-concept, which means: hack it into an existing
implementation to demonstrate that it's feasible.

If you need new syntax, hacking it into an implementation means hacking it into
the parser. Everyone who wants to experiment with your feature needs to get
your compiler patches (for GCC for instance) and rebuild the compiler.

The process is painful enough that it's only worth doing if it solves something
that is perceived as being a critical issue.

> do not understand, why so many languages that lacks so much needed
> namespace for so long? If it is a social problem, i don't imagine they
> would last so long. It must be some technical issue?

I recently read about a very useful theory which explains why technologies
succeed or fail. 

See: http://arcfn.com/2008/07/why-your-favorite-programming-language-is-unpopular.html

The perceived crisis which namespaces solve is not sigificant enough relative
to the pain of adoption.  No, wrong, let's restate that. Programmers do use
namespaces even when there is no language feature. It's not about adoption of
namespaces, but adoption of proper support for namespaces.  Not using
namespaces is a crisis in a software project, but (at least in the perception
held by many programmers) that crisis is adequately mitigated by using a naming
convention.  Proper namespaces only address the small remaining vestiges
of the original crisis.

Thus: the perceived crisis which is solved by properly incorporating namespaces
into a programming language (rather than living with a prefix-based emulation)
is not significant enough relative to the perceived pain of adopting proper
namespaces into the programming language. 

However, proper namespaces, if available, are easier to use than prefixed
identifiers, and not diffcult to adopt. So if someone has gone to the trouble
of making them available in the programming language, then they do get used.

From: Xah Lee
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <fb3c950e-2861-4b65-8cd6-3f076faef48f@e1g2000pra.googlegroups.com>
Dear Kaz Kylheku,

your post is too much verbiage and enthusiasm.

Why? because you went into the la la land of philosophy.

Although, i do think you did give some good exposition on your views.

Now, let me detail some analysis of your post.

In summary, you are saying a few things about namespaces, for example,
you gave some reasons javascript doesn't really need namespaces that
much, and in general, your thesis is that although lack of namespace
is bad, but overall it's ok, and the pain of adding namespaces is more
than the problem it solves. You cite C and linux, and some joe blog's
philosophy on the multi-core crisis as support.

On the whole, given your post as is, i don't disagree with your
general point of view. However, you seem to went onto your own gripe
about alarmists, by the magic of vodoo speak and future-predicting
formula, wantonly applied it to the namespace “crisis”. And in the
process, you seems to brush it off, almost sounding like lacking
namespace is a none-problem.

Nobody is saying that lacking namespace is a CRISIS. But it is a
problem, a problem that is rather seriously, practically, hampering
software development, in PHP, in Scheme Lisp, in Emacs Lisp, a widely
acknowledged problem by programers in these communities, counting
myself. Nobody is saying that linux development is crumbling just
because C lacks namespace. Nobody is saying that human animal couldn't
land on the moon when people are still using slide rules and punch
cards. (note that the issue proper of this thread is about technical
issues of introducing namespace into a existing lang. Am not accusing
you of derailing, but just pointing out a background fact.)

Can you see, how you latched your personal beef about anti software
crisis philosophy into this no namespace thread?

In your fervor to dispel the software crisis beliefs, you painted a
picture that lacking namespace in C, Javascript, Emacs Lisp, Scheme
Lisp, PHP, as trivial, unimportant, none problems.

Do you actually, seriously, believe, that lacking namespaces in these
languages is not a problem? Sure, if a programer got a accident and
fell into a manhole and broke his legs, i bet he can still live long
and program well. But that doesn't mean being a cricrublempple is
cool, right?

In your hot haste, you got a few things factually wrong too.

• Javascript, although used in browser mainly, but that is not its
only use. It has huge potential as a general purpose lang. It is
adopted here and there as the scripting lang. Check out Wikipedia on
it. It lists about 20 such adoptions by various tech or software app
as scripting lang.

• You mentioned that adding prefix is a workable solution. Yes, but
only to some extent. For example, in elisp, it lacks lexical scoping,
lacks closure, and its manual suggest that names shouldn't be more
than 32 chars. These, seriously put a dent on the workaroundibilities
of the no namespace problem. I do a lot emacs lisp scripting, i
already felt the pain. Steve Yegge in his blog, for his work of
implementing javascript interpreter in elisp gave detail. Similarly,
lacking namespace in PHP is also a major, practical, problem to web
app developers. Scheme lisp's lack of namespace is also a major sore
point, being one of its major problems that in their view prevented
them from going outside of academia. These are not just made-up
scenarios. These are widely acknowledged, practicality oriented,
problems. Yeah sure, you can always find some workaround, and the
world won't crumble by it, just like cripples and dumb and blind can
all still lead a happy and fruitful life.

There is no crisis!

  Xah
∑ http://xahlee.org/

☄

On Nov 26, 1:32 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-11-26, Xah Lee <······@gmail.com> wrote:
>
>
>
> > comp.lang.lisp,comp.lang.functional,comp.lang.perl.misc,comp.lang.python,co mp.lang.java.programmer
>
> > 2008-11-25
>
> > Recently, Steve Yegge implemented Javascript in Emacs lisp, and
> > compared the 2 languages.
>
> >http://steve-yegge.blogspot.com/
> >http://code.google.com/p/ejacs/
>
> > One of his point is about emacs lisp's lack of namespace.
>
> > Btw, there's a question i have about namespace that always puzzled me.
>
> > In many languages, they don't have namespace and is often a well known
> > sour point for the lang. For example, Scheme has this problem up till
> > R6RS last year.
>
> Scheme hasn't officially supported breaking a program into multiple files until
> R6RS. If the language is defined in terms of one translation unit, it doesn't
> make sense to have a namespace feature.
>
> > PHP didn't have namespace for the past decade till
> > about this year. Javascript, which i only have working expertise,
> > didn't have namespace as he mentioned in his blog.
>
> Javascript programs are scanned at the character level by the browser as part
> of loading a page.  So there are severe practical limitations on how large
> Javascript programs can be.
>
> Namespaces are useful only in very large programs.
>
> > Elisp doesn't have
> > name space and it is a well known major issue.
>
> C doesn't have namespaces, and yet you have projects like the Linux kernel
> which get by without this.
>
> Given that the Linux kernel can do without namespaces, it's easy to see how
> Javascript and Elisp can survive without it.
>
> > Of languages that do have namespace that i have at least working
> > expertise: Mathematica, Perl, Python, Java. Knowing these langs
> > sufficiently well, i do not see anything special about namespace. The
> > _essence_ of namespace is that a char is choosen as a separator, and
> > the compiler just use this char to split/connect identifiers.
>
> The essence of a true namespace or package system or whatever is that you can
> establish situations in which you use the unqualified names.
>
> You can emulate namespaces by adding prefixes to identifiers, which is
> how people get by in C.
>
> In C, you can even get the functionality of short names using the preprocessor.
>
> I have done this before (but only once). In a widely-used public header file, I
> prefixed all of the names of struct members (because struct members are not
> immune to clashes: they clash with preprocessor symbols!)
>
>   struct foo {
>     int foo_category;
>     time_t foo_timestamp;
>     /* ... */
>   }
>
> Inside the implementation module, I made macros for myself:
>
>   #define category foo_category
>   #define timestamp foo_timestamp
>
> In this way, I didn't have to edit any of the code in order to move the struct
> members into the namespace. Expressions like ``pf->category'' continued to work
> as before.
>
> > Although i have close to zero knowledge about compiler or parser, but
> > from a math point of view and my own 18 years of programing
> > experience, i cannot fathom what could possibly be difficult of
> > introducing or implementing a namespace mechanism into a language.
>
> The same things that make it difficult to add anything to a language, namely
> the stupid way in which languages are designed to get in the way of extension.
>
> What would it take to add namespaces to C, for instance?
>
> If you have any proposal for a new C feature, the ISO C people encourage you to
> develop a proof-of-concept, which means: hack it into an existing
> implementation to demonstrate that it's feasible.
>
> If you need new syntax, hacking it into an implementation means hacking it into
> the parser. Everyone who wants to experiment with your feature needs to get
> your compiler patches (for GCC for instance) and rebuild the compiler.
>
> The process is painful enough that it's only worth doing if it solves something
> that is perceived as being a critical issue.
>
> > do not understand, why so many languages that lacks so much needed
> > namespace for so long? If it is a social problem, i don't imagine they
> > would last so long. It must be some technical issue?
>
> I recently read about a very useful theory which explains why technologies
> succeed or fail.
>
> See:http://arcfn.com/2008/07/why-your-favorite-programming-language-is-un...
>
> The perceived crisis which namespaces solve is not sigificant enough relative
> to the pain of adoption.  No, wrong, let's restate that. Programmers do use
> namespaces even when there is no language feature. It's not about adoption of
> namespaces, but adoption of proper support for namespaces.  Not using
> namespaces is a crisis in a software project, but (at least in the perception
> held by many programmers) that crisis is adequately mitigated by using a naming
> convention.  Proper namespaces only address the small remaining vestiges
> of the original crisis.
>
> Thus: the perceived crisis which is solved by properly incorporating namespaces
> into a programming language (rather than living with a prefix-based emulation)
> is not significant enough relative to the perceived pain of adopting proper
> namespaces into the programming language.
>
> However, proper namespaces, if available, are easier to use than prefixed
> identifiers, and not diffcult to adopt. So if someone has gone to the trouble
> of making them available in the programming language, then they do get used.
From: alex23
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <d8f2f662-446c-4a1d-8a99-faa7ea6e35cd@q26g2000prq.googlegroups.com>
On Nov 27, 9:28 am, Xah Lee <······@gmail.com> wrote:
> Hi Stefan, try not to be a moron.

Hi Xah, try not to be an asshole.

[and in a separate post]
> your post is too much verbiage and enthusiasm.

The hypocrisy here would be funny if I didn't think you were serious.
From: Kaz Kylheku
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <20081212022944.59@gmail.com>
On 2008-11-26, Xah Lee <······@gmail.com> wrote:
> Can you see, how you latched your personal beef about anti software
> crisis philosophy into this no namespace thread?

I did no such thing. My post was about explaining the decision process
that causes humans to either adopt some technical solution or not.

In doing so, I put on the ``hat'' of an Emacs Lisp, Javascript or C programmer.

If enough programmers share this type of perception (be it right or wrong),
that explains why there is no rush to add namespace support to these languages.

The theory is that the adoption of some technology is driven by
a function of the ratio:

   perceived crisis
   ----------------
   perceived pain of adoption

These perceptions may not be accurate. The crisis may be larger than perceived,
or the pain of adoption may be smaller than perceived.

But, you missed the point that I don't necessarily agree or disagree with the
perceptions. They are what they are.

> Nobody is saying that lacking namespace is a CRISIS.

I.e. you agree that it's not widely perceived as a crisis. Hence, small
numerator in the above ratio.
From: Xah Lee
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <faac2632-34a5-4406-86ea-417cb33675c5@z6g2000pre.googlegroups.com>
On Nov 26, 4:57 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-11-26, Xah Lee <······@gmail.com> wrote:
>
> > Can you see, how you latched your personal beef about anti software
> > crisis philosophy into this no namespace thread?
>
> I did no such thing. My post was about explaining the decision process
> that causes humans to either adopt some technical solution or not.

Yes, you did that by following a moronic pop theory. The purpose of
this message is to tell you, that you should have decades of study of
multiple deciplines in history, economics, psychology, sociology, to
be immune to the lots of pop theories that float about especially
today with the internet.

let me explain why the pop theory you fell for breaks apart with
respect to the namespace issue here in this thread.

lacking namespace is not due to some ratio of perceived benefit
divided by perceived pain.

The benefit is huge, practical, and undeniable, the pain to adopt the
namespace fix is almost non-existant, because any such solution will
obvious be done in a backward compatible way. If the solution is
provided, the pain at max is just like a version upgrade. Java, Perl,
and all langs goes thru major upgrade every few years.

there are social reasions and technical reasons why langs lacking much
needed namespace took so long to fix. Social reason being, as others
has said in this thread, for examples: compatibilities issues in the
case of javascript's browser/server situation. In the case of Scheme
lisp, there's the issue of committee consensus and the RnRS standard.
You can't just have someone created a namespace implementation and
have every other Scheme lisp adopt it. As far as i know, namespace has
been in lots of Scheme implementations for long. The problem is
getting it into RnRs. The situation in Emacs lisp, at least partly
have to do with lack of developers, and partly have to do with Richard
Stallman. First, you need someone capable enough to actually implement
it as some sort of proof of concept, then you have to pass thru
Stallman himself, else you get XEmacs fork situation, which
significantly hurled GNU Emacs forward for the past about 15 years. In
the case of PHP, i suppose the primary reason is that it works without
namespace so far. PHP lang is mostly hack. The lang is so messy that
namespace is not just one thing that needs to be fixed. All the above
reasons, are of social one. There are undoubtly some technical reasons
too. I don't have compiler knowledge so i can't say what, but to say
the least, that creating a namespace in a existing lang that is widely
used in the industry is not something a average computer science
graduate can do.

The above are ugly, perhaps complex, real world facts. It's not some
pop fucking book about some pop pereciveness of some ratios.

one can go on analyze the perceived benefit and pain about the
namespace issue on each language specifically. You can see how it
doesn't apply. But going in detail on this'd be waste of time. If you
spend your time to debunk pop theories, play their game, the
scientific establishment would go no where.

There are quite a lot pop books on the market, they usually sells.
Their audience is the mass market. They have little scientific value.
They are not valued by any expert in any field. Most of them cannot be
invalidated in any way. This does not mean pop theory, pop psychology,
wisdoms, or anything not dry science, are all bullshit. Ultimately,
there's no magic rule that can tell you which is which. The degree and
quality of you or the masses's judgement, ultimately depends on your
education level. That is why, general education is so important, in
every nation and culture, while it's little talked about only because
its so obvious, so plain.

here's another pop book you might like:

• Book Review: Patterns of Software
  http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html

this one is published a decade ago by a lisp dignitary.
Its theory of programing and software engineering is poetry and
taoism.
It suggests that C will be the last lang.

  Xah
∑ http://xahlee.org/

☄
From: Lew
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <ggmdss$rg6$2@aioe.org>
Xah Lee wrote:
> this one is published a decade ago by a lisp [sic] dignitary.
> Its theory of programing [sic] and software engineering is poetry and
> taoism [sic].
> It suggests that C will be the last lang.

In a paroxysm of precognitive genius, seemingly.

-- 
Lew
From: Tamas K Papp
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <6p5v4pF6d3rrU2@mid.individual.net>
On Wed, 26 Nov 2008 21:32:24 +0000, Kaz Kylheku wrote:

> See:
> http://arcfn.com/2008/07/why-your-favorite-programming-language-is-
unpopular.html

That was 404 for me, but

http://arcfn.com/2008/07/why-your-favorite-language-is-unpopular.html

works.  Interesting, thanks for mentioning it.

Tamas
From: Wojtek
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <mn.d3567d8be60e6a58.70216@a.com>
Kaz Kylheku wrote :
> Javascript programs are scanned at the character level by the browser as part
> of loading a page.  So there are severe practical limitations on how large
> Javascript programs can be.

> Namespaces are useful only in very large programs.

But even more useful where you are getting libraries from several 
sources.

Without a generally acknowledged name space scheme different developers 
will tend to walk all over each others variable/function names. 
Especially as Javascript has global variables.

-- 
Wojtek :-)
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: what's so difficult about namespace?
Date: 
Message-ID: <REM-2008nov28-001@Yahoo.Com>
> From: Kaz Kylheku <········@gmail.com>
> Scheme hasn't officially supported breaking a program into
> multiple files until R6RS. If the language is defined in terms of
> one translation unit, it doesn't make sense to have a namespace
> feature.

Good point. Note that any language that uses optionally-loadable
"libraries" automatically has more than one translation unit,
namely the application itself and at least one loaded library. More
on this later.

> Javascript programs are scanned at the character level by the
> browser as part of loading a page.  So there are severe practical
> limitations on how large Javascript programs can be.

That's only half the reason. The other half is that JavaScript
doesn't support requiring additional libraries to be downloaded
from another site to be added to the main JavaScript application,
right?

> Namespaces are useful only in very large programs.

Or in medium sized programs that require loading libraries written
by other people, of the total set of all such libraries is too
large to globally manage well enough to avoid name clashes. The
main program might not use namespaces internally, but the various
libraries *must* use namespaces internally, and then the main
program must arrange for external functions to be propertly called
with namespace+localname.

> The essence of a true namespace or package system or whatever is
> that you can establish situations in which you use the unqualified
> names.

Correct.

> You can emulate namespaces by adding prefixes to identifiers,
> which is how people get by in C.

With the pain that you must always use the fully-qualified name, right?

> In C, you can even get the functionality of short names using the
> preprocessor.

I hear Greenspun there! :-)

> I have done this before (but only once). ...

(Story of a Greenspun task. Yes, I agree what you did, after the
 fact, to avoid needing to manually edit all the files in your
 source to have fully-qualified names when porting for others to
 use, was a reasonable hack.)

> I recently read about a very useful theory which explains why
> technologies succeed or fail.
> See: http://arcfn.com/2008/07/why-your-favorite-programming-language-is-unpopular.html
404 not found.

Otherwise this thread, and your article in it, are interesting and
enlightening. BTW comp.lang.lisp is my favorite newsgroup for
articles that give new insight I overlooked before. KentP and
PascalB have the largest amount of good insight, but other posters
contribute too. Thanks for posting Kaz et al. (I hope once in a
while something I post provides enlightening insight to somebody.)