what's so difficult about namespace?
Xah Lee
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. 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. Elisp doesn't have
name space and it is a well known major issue.
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.
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. I
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?
Could any compiler expert give some explanation?
Thanks.
Xah
∑ http://xahlee.org/
☄
Cor Gest
Nothing at all, my boy , nothing at all.
--
God made man, Colt made some equal, Khalashnikov made the poor equal too
First directive to dissuade criminal intent: Present a Gun
I may be blonde, but I am not stupid
Selfdefense is a basic human right
Gene
> 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.
>
>
> 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. 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. Elisp doesn't have
> name space and it is a well known major issue.
>
> 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.
> 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. I
> 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?
>
> Could any compiler expert give some explanation?
>
> Thanks.
>
> Xah
> ∑http://xahlee.org/
>
> ☄
When multiple existing systems are combined, namespaces provide a
quick way to prevent name clashes.
Lew
>> Of languages that do have namespace that i [sic] have at least working
>> expertise: Mathematica, Perl, Python, Java. Knowing these langs
>> _essence_ of namespace is that a char is choosen as a separator, and
>> the compiler just use this char to split/connect identifiers.
That is hardly the essence of namespaces, just a notational convenience to
help humans relate to namespaces. The essence of namespaces is that they are
distinct.
It's also not an accurate statement. XML namespaces, for example, use many
characters as separators, not just one, but that's not the essence. The
essence is that all the characters matter, not just the putative separators.
>> Although i [sic] 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 [sic] cannot fathom what could possibly be difficult of
>> introducing or implementing a namespace mechanism into a language. I
>> do not understand, why so many languages that lacks so much needed
Point not proven. If they were really needed in every language, every
language would have them.
>> namespace for so long? If it is a social problem, i [sic] don't imagine they
>> would last so long. It must be some technical issue?
Yeah, like technically they aren't needed everywhere.
>> Could any compiler expert give some explanation?
Compilers are not relevant. XML has namespaces, and compilers certainly
aren't the issue there.
--
Lew
Joshua Cranmer
> 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. 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. Elisp doesn't have
> name space and it is a well known major issue.
Namespaces are useful for one reason: they allow you to have conflicts
with names in some cases. In Java, there are two Lists: java.awt.List
and java.util.List. Since a name must only be unique within a namespace,
you can use shorter names without fear of conflict.
In languages without these namespaces, you end up with stuff like
g_type_init, e_data_server_module_init, mysql_connect, etc., where the
prefixes are used to emulate the unique nature of namespaces.
> 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.
Most features aren't sufficiently appreciated until one has to do
without it. The avoidance of collision that comes with namespaces has
shown to be sufficiently useful that I doubt we'll ever see a future
major language that doesn't have some sort of namespace feature.
> The
> _essence_ of namespace is that a char is choosen as a separator, and
> the compiler just use this char to split/connect identifiers.
That's just composition of namespace names. It's not what namespaces is
about.
> i cannot fathom what could possibly be difficult of
> introducing or implementing a namespace mechanism into a language.
Namespaces go to the very core of a language, name resolution.
Retroactively adding such a feature is extremely difficult because there
is a strong chance of accidentally breaking existing code.
> I
> 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?
It's technical: it would be difficult to retroactively implement such a
feature.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Xah Lee
> > i cannot fathom what could possibly be difficult of
> > introducing or implementing a namespace mechanism into a language.
>
> Namespaces go to the very core of a language, name resolution.
> Retroactively adding such a feature is extremely difficult because there
> is a strong chance of accidentally breaking existing code.
could you give some technical detail on this?
i don't know compiler so am probably being foolish here... but i
suppose ultimately name resolution and storage at heart is something
like a hashtable... namely,
put ‹identifier 1› table
put ‹identifier 2› table
and lookup is just
retrieve ‹identifier› table
and now suppose we introduced namespace, so i imagine the compiler
simply just concat namespace component befor put, and split before
retrieve?
Xah
∑ http://xahlee.org/
☄
Wojtek
> i cannot fathom what could possibly be difficult of
> introducing or implementing a namespace mechanism into a language. I
> 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?
Simply put:
- it was not in the original language specification
- some hundreds of millions of distributed browsers interpret
Javascript without namespaces
- to introduce namespaces into the language would require every browser
to be replaced (at least if the user comes across a site which uses it)
The IT community has enough trouble getting a few ISPs to upgrade their
DNS software. How are you going to get millions of general users to
upgrade?
Web stats show that people are still using IE 5...
--
Wojtek :-)
Xah Lee
> > i cannot fathom what could possibly be difficult of
> > introducing or implementing a namespace mechanism into a language. I
> > 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?
On Nov 26, 8:06 am, Wojtek <nowh...@a.com> wrote:
> Simply put:
> - it was not in the original language specification
> - some hundreds of millions of distributed browsers interpret
> Javascript without namespaces
> - to introduce namespaces into the language would require every browser
> to be replaced (at least if the user comes across a site which uses it)
>
> The IT community has enough trouble getting a few ISPs to upgrade their
> DNS software. How are you going to get millions of general users to
> upgrade?
>
> Web stats show that people are still using IE 5...
alright, that's speaks for Javascript.
But how's that apply to, say, Scheme lisp, Emacs lisp, PHP?
In the case of Scheme, i can see that the problem of delay in
introducing namespace is due to the nature of community wanting some
consensus on the most elegant approach.
For emacs lisp, is it prolonged lack of namespace due to lack of
developer resource?
in anycase, the reasons above are social ones. Namely, issues like
backward compatibility, agreement on design, lack of developers. I'd
be very interested if any compiler writer can give technical
perspective on whether introducing namespace to a existing lang is a
problem.
Xah
∑ http://xahlee.org/
☄
Gene
I'm sorry for the earlier post. I read your question too quickly.
I've implemented a few research compilers; none in production. You're
totally right in the case where the language has general nested
lexical scoping. Namespaces just add an "outermost" scope. If you've
done a good engineering job, the compiler change is trivial. In fact I
added namespaces like this to an assembler that had lexical scoping.
It took about an hour including writing a test suite.
If you already have a bunch of compilers for a language like pre-
namespace C or Javascript or Basic that doesn't allow for lexical
scoping, then the addition is likely to be non-trivial because the
implementation compiler language is often C and C programmers will
tend to declare a single, global symbol table. So adding a separate
outer scope involves hunting down all the global references and
replacing them with references to the current namespace table. We can
tut tut about this being bad design, but there you have it...
Kaz Kylheku
> 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.
Tamas K Papp
> 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
Wojtek
> 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 :-)
Xah Lee
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/
☄
> See:http://arcfn.com/2008/07/why-your-favorite-programming-language-is-un...
alex23
> 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.
Kaz Kylheku
> 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.
Dimiter "malkia" Stanev
I myself am proponent of namespace-lessness... That was until I
discovered CLOS and the multi-methods...
For any other language I would pick Apple's approach approach to
Objective C, and the frameworks that they've put (libraries) - e.g. use
couple of letters to prefix your class/functions - like NSObject,
ABAdressBok, UIButton. For these languages, where only single-dispatch
is available, there is no need to prefix their methods, as they are
always send to one object, and this object itself becomes a "package" -
basically it would grok certain "words", "messages", "id-s" whatever you
call them.
But let's go back to CLOS:
Take for example the Lispworks CAPI gui library. To display a component
you normally do:
(display ...)
If you haven't added the CAPI library to the (:use) list then you do:
(capi:display ...)
But let's say you have another library used in your application, that
has the same multi-method "display". For example a PDF library might
have such.
To call it, you would again do:
(display ...)
And if you haven't added the PDF library to the use list:
(pdf:display ...)
In the case where both libraries (:use "CAPI" "PDF") are used, there
would most likely be a problem, but at least you can solve it by
prefixing it with capi: and pdf:, but this would still keep short-naming
in the rest of the modules where that's not needed. The more decoupled
the system, the less you would run into such problems, and most of the
coupling is in the actual application code (not libraries) where you
assemble stuff.
And overall it would be better than naming your methods like this:
(capi-display)
(pdf-display)
Yes this would be safe everywhere, and granted such naming works well
for functions, classes, global variables, etc - but really for METHODS,
being a MESSAGE it makes it unattractive.
Other than that, packages (namespaces) in Common-Lisp are also used for
special cases: The KEYWORD package, The SETF one, and COMMON-LISP would
always be the bible :)
Dimiter "malkia" Stanev.
Xah Lee
On Nov 26, 4:57 pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
> On 2008-11-26, Xah Lee <xah...@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/
☄
jon.harro...@gmail.com
> ...
It's mostly a problem of culture.
If you look, for example, at chinese names, the name space is not that
much important:
"Xee Laa" only takes this space:
" "
^^^^^^^
Instead, if you take a typical english name, say, "Abraham Lincoln",
you instantly recognize the waste of space used by this name:
" "
^^^^^^^^^^^^^^
Concluding: I think that americans are very good at wasting name
spaces, whereas chinese ones seem less name space hungry.
Sure, you could make some other example, proving for the contrary, but
I think the one cited above already suffices.
Peace.
Lew
> 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
Lew
> much important:
> "Xee Laa" only takes this space:
> " "
> ^^^^^^^
Chinese names are presumably not spelled with Roman letters in Chinese, so
this really says nothing about how Chinese "wastes" space.
> Instead, if you take a typical english [sic] name, say, "Abraham Lincoln",
> you instantly recognize the waste of space used by this name:
> " "
> ^^^^^^^^^^^^^^
How is that wasted? "Abraham Lincoln" is a longer name. Only one character
is silent. In the transliteration you show for a Chinese name, two characters
are wasted.
> Concluding: I think that americans [sic] are very good at wasting name
> spaces, whereas chinese [sic] ones seem less name space hungry.
>
> Sure, you could make some other example, proving for the contrary, but
> I think the one cited above already suffices.
Your example shows the opposite of what you claim. By your own example, the
Chinese transliteration "wasted" twice as much space as the American one.
--
Lew
Roedy Green
wrote, quoted or indirectly quoted someone who said :
> If it is a social problem, i don't imagine they
>would last so long. It must be some technical issue?
The problem with namespaces is they resolve the ambiguity for
computers, but not for humans.
Humans are often confused if you mean java.util.List or java.awt.List.
It is best to avoid reusing names because of the way the human brain
works.
Namespaces are a safety feature. You should try to avoid reusing the
same name in different contexts, with a number of exceptions for some
common "local" names.
--
Roedy Green Canadian Mind Products
http://mindprod.com
"Humanity is conducting an unintended, uncontrolled, globally pervasive experiment
whose ultimate consequences could be second only to global nuclear war."
~ Environment Canada (The Canadian equivalent of the EPA on global warming)
Wojtek
> On Tue, 25 Nov 2008 22:29:43 -0800 (PST), Xah Lee <xah...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> If it is a social problem, i don't imagine they
>> would last so long. It must be some technical issue?
>
> The problem with namespaces is they resolve the ambiguity for
> computers, but not for humans.
The good thing abbout namespaces is that they allow for better
organization of application function. And (in Java) they also allow for
information hiding via the default modifier.
> Humans are often confused if you mean java.util.List or java.awt.List.
> It is best to avoid reusing names because of the way the human brain
> works.
Ah but the human does know the context. Am I showing stuff on the
screen, or am I storing information. Different operations.
> Namespaces are a safety feature. You should try to avoid reusing the
> same name in different contexts, with a number of exceptions for some
> common "local" names.
Don't know what you mean by "local". I have many tens of packages (um,
namespaces). Each has a Data class which is passed around by other
classes in the same package (Command, SQL, Validator, the servlet). Is
the Data class "local"? Yet it is marked as public because the JSP
needs to use it.
--
Wojtek :-)
Barry Margolin
wrote:
> Roedy Green wrote :
> > Namespaces are a safety feature. You should try to avoid reusing the
> > same name in different contexts, with a number of exceptions for some
> > common "local" names.
>
> Don't know what you mean by "local". I have many tens of packages (um,
> namespaces). Each has a Data class which is passed around by other
> classes in the same package (Command, SQL, Validator, the servlet). Is
> the Data class "local"? Yet it is marked as public because the JSP
> needs to use it.
I think he means variables that are just used in local contexts, e.g.
(dotimes (i ...) ...)
You shouldn't need to worry about the namespace of I.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Robert Maas, http://tinyurl.com/uh3t
> 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.)