

A namespace implementation for Emacs Lisp - pmoriarty
https://github.com/Bruce-Connor/names

======
skywhopper
Personally, in terms of just convention, I've taken to the style of using
"packagename/" as a function-name prefix in my own Elisp code. Since the
hyphen is the conventional between-word character for function names, it sets
it off much better visually.

But more specificially, I don't really like the idea of adding this "feature".
I don't mind the extra characters in the function names. Verbosity and clarity
are good things. So long as package maintainers follow naming conventions,
that's far preferable to trying to read code that may or may not have apparent
duplicate function names.

------
josteink
I've seen this before and it's definitely a nice stop-gap solution to a well
known and common problem.

However the existence of something like this IMO really shows that a feature
like this should be Emacs (25?) itself, at the core, preferably without
creating indentation issues by leaving your entire module a nesten s-exp.

In an ideal world something like (ns 'my-package) statement at the start of
your module should be enough.

In a less ideal world, that simple solution will cause compatibility problems
when you want packages to work for both Emacs _pre-ns_ and Emacs _post-ns_.

How to get that done properly is a genuinely hard question. Any suggestions?
Any takers?

~~~
rson
For what it's worth, this macro doesn't cause the indentation issue due to how
it's defined[1]. It does, however, leave the extra sexp around your package.

From my experimentation the package worked quite well for the most part but I
ended up not using it in the end.

1: [https://github.com/Bruce-
Connor/names/blob/master/names.el#L...](https://github.com/Bruce-
Connor/names/blob/master/names.el#L373)

------
lukego
Isn't it amazing how well Emacs development scaled without basic features like
namespaces and lexical scope?

These days I find myself more inclined to try and borrow ideas from Emacs Lisp
than to retrofit modern ideas back onto it.

How important can those features really be if their absence has only been a
nuisance during decades of development?

~~~
aardvark179
Dynamic scope (the expectation of it, and the patterns of programming that it
encourages) become more than just a nuisance when you try to separate work
into tasks that can be handled by any form of task pool. In general any form
of concurrency combined with dynamic scoping is at best painful, and at worst
a disaster, and working round those issues introduces considerable runtime
inefficiency.

~~~
hollerith
That is true, but IMHO it is probably irrelevant to Emacs because adding
concurrency to Emacs is probably a bad idea.

Firefox of course has concurrency, and IMHO it makes Firefox a lot "glitchier"
than Emacs is (or Firefox would be if it did not have concurrency). Several
times a day, Firefox goes unresponsive for a few seconds. That does not make
Firefox unusable or unsatisfactory, but not being able to rely on a timely
response from Firefox 100% of the time to a keypress or pointing-device input
really does seem to change the way I use Firefox.

Anyone with experience with math, even with doing multiplications and
divisions in one's head, can see that how much complexity the mind can handle
is dependent on how quickly one can execute sub-tasks. That is an example of
the general principle getting fast -- reliably fast -- at the sub-tasks
increases the complexity of the tasks one can handle (and of course it is the
reliable quickness of small sub-tasks that glitchiness of the user experience
interferes with).

Those without experience with Emacs or Vim (which I am guessing is like Emacs
in being 100% responsive) can get an idea of what I mean by comparing their
experience in using Firefox or Google Chrome with their experience of using a
terminal-emulation app and a Unix shell: although some shell command lines do
take a while to produce a response from the system, most of the time, the user
can predict when a delay will occur (e.g., a `find` over the whole directory
hierarchy) and even when the user is surprised by the presence of a delay, in
retrospect there is always a reasonable explanation for the delay if the user
is willing to think through and learn about enough details about the system.

(Yes, I realize that there are some applications that some people would like
to write in Emacs Lisp that simply cannot be written without concurrency
without blocking Emacs for many many seconds at a time. I am skeptical that
being able to write those application in Emacs Lisp is worth the cost in
complexity and in glitchiness of the user experience.)

The above is a simplification: in reality, glitches do happen in Emacs and in
an interactive Unix shell, _but_ I am almost sure that the cause of those
glitches is in the underlying OS, not in the Emacs or the Unix-shell process.

~~~
lispm
> Several times a day, Firefox goes unresponsive for a few seconds.

This is caused by concurrency?

~~~
hollerith
That is my best guess. I could be wrong. Should people refrain from publishing
their guesses on HN?

None of the programs I have used that lack threads, including lynx, have this
kind of glitchiness. (Also, I think early versions of X lacked threads and at
least when paired with certain video cards, were free of glitchiness -- or
more precisely, a user could learn to operate X in such a way as to avoid
glitchiness.)

In particular, my guess is that although it is theoretically possible to write
huge multi-threaded programs that do not exhibit glitchiness, in reality it is
too hard for even very skilled human programmers to do it, and that is why
Firefox has the glitchiness property.

I am willing to listen to arguments to the contrary.

P.S. I would have supposed that those who disagree with my conclusion would
simply deny that Firefox is glitchier than Emacs or would simply conclude that
the difference in glitchiness is irrelevant. Do you agree with me that it is
glitchier and that the glitchiness matters?

(Again, I realize the glitches are rare -- maybe only a few a day. They do
affect my experience of the app, though.)

