> Emacs Lisp is probably the worst language for "programming in the large". (After Javascript.)
But unlike JavaScript (and Node.js), I don't know of anyone who uses Emacs out of the belief that Emacs Lisp is a language with which they should be building large-scale applications. It is strictly a client-side language and it is used as such.
In fact, Emacs Lisp is actually a pretty good client-side language. Not that it is perfect, but I find it more enjoyable to use than JavaScript.
I strongly disagree, it is just a lisp. It seems very suited for the job, is there any other competitor who has stood the test of time (I dont just mean this years fashion chrome wrapped editor) with as many extensions ?
Strongly disagree. With lexical bindings it's on par with contemporary strongly typed dynamic languages like python. It does even have fancy pattern matching with pcase library built in, plus lots of fancy stuff for editing like thing-at-point.
I assume it's the typical corporate situation: when you have to work together on a codebase that's too big for one person to get a mental overview of. And unlike with a codebase you develop in your free time, you have no real control of who you have to work with.
I'm curious what the criteria for this is? And also happy to note elisp is quite effective at extending emacs. Regardless of what it is lacking at large. :)
But this is odd. When has the lack of namespaces caused a problem to you? When has cl-defstruct or eieio been insufficient to give you what you wanted out of OOP paradigms? I feel like your examples, and multithreading, are just programmers going off surface appearances of modern features and judging before using.
> When has the lack of namespaces caused a problem to you?
I can't imagine the maintenance of a Lisp system where several ten thousand names are flat in one namespace. For example: there is no way to browse those just looking at names with prefix parts. Textual name prefixes are a poor substitute for a proper "first class" namespace system. What parts of the symbol name are actually a prefix?
"CL-CADDAR" -> that means that I can't load any CL source code into Emacs, because every operator has been renamed. What? There is a subset of Common Lisp in GNU Emacs, but with all operators and variables renamed?
40 years ago Zmacs and the surrounding libraries on a Lisp Machine were already better structured.
> cl-defstruct or eieio
It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders.
> It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders.
Not really sure what you mean. These are not "add-ons" any more than standard libraries are add-ons to other languages. They are fully integrated into core of Emacs, and has been that way for decades already. The naming situation might imply otherwise, but "cl-" namespace is by no means a second class citizen and I think there are practical value in keeping that naming scheme. In any case they are pervasively used both internally and in the community.
"Due to restrictions in the Emacs Lisp language, CLOS cannot be completely supported ... EIEO does not support method dispatch for built-in types and multiple arguments types. In other words, method dispatch only looks at the first argument, and this one must be an EIEIO type."
does not look like it is fully integrated into the core.
> I think there are practical value in keeping that naming scheme
To prohibit reuse of existing code? Where is the practical value? If Emacs Lisp had a namespace mechanism, this would be no topic and nobody would argue keeping a strange naming scheme, where operators are named incompatibly to the language where they were coming from.
Let's define most of Scheme features, but rename all the operators. That's really really strange to argue... I makes the reuse of millions of lines of existing code impossible from day zero.
I've never even imagined copy-pasting straight Common Lisp code into an Emacs Lisp file. And I have to say:
1. The implementations of many functions are subtly different anyway, much like you can't expect Ruby's string join to work the same as Python's string join, down to an identical argument order and everything. That would be crazy to expect, right? You also can't do that kind of thing between Scheme and Common Lisp for what that's worth.
2. Even if you wanted to do this, the name of the function would be the easiest part of the migration: it takes one round of search-and-replace. So the namespacing is not the problem, and it's barely a problem at all.
I'm not really understanding you, maybe. Why would you expect Elisp to be able to run CLisp code verbatim? And why would you ding a language for its inability to fulfil such an uncommon use case?
> I've never even imagined copy-pasting straight Common Lisp code into an Emacs Lisp file.
Just go into a different namespace and load the code. The Lisp Machine I use has several different dialects of Lisp in one image. I can tell what dialect to use and it reads and evals code from that dialect. I can have two REPLs for different Lisps running side by side in one Lisp world, where I can call all operators from all other dialects.
That's basically also what was imagined for a GUILE-based GNU Emacs: it would run all of Emacs Lisp, but would also additionally understand Scheme.
> You also can't do that kind of thing between Scheme and Common Lisp for what that's worth.
Sure I can. Here I have loaded SCHEME into Common Lisp. The namespace is called SCHEME.
Now I switch over to the SCHEME namespace, where I can use the SCHEME operators like DEFINE without prefix:
CL-USER 10 > (in-package "SCHEME")
#<The SCHEME package, 774/1024 internal, 0/16 external>
SCHEME 11 > (foo1 20)
42
SCHEME 12 > (define (foo2 a b) (+ a b 22))
foo2 defined.
SCHEME 13 > (foo2 9 11)
42
> the name of the function would be the easiest part of the migration: it takes one round of search-and-replace. So the namespacing is not the problem, and it's barely a problem at all.
I'm not just talking about migrating code by converting it. I'm also talking about using the same code from one file.
> And why would you ding a language for its inability to fulfil such an uncommon use case?
It's only uncommon because you are not used to it. In earlier times even very complex source code was shareable between similar Lisp dialects.
If one adds to a Lisp lots of operators from a slightly different dialect, then it would be useful to do it in such a way that the dialect is integrated in a way that original source code written in that dialect can be shared with only a minimum of work.
Namespaces is an odd one. In general, I've seen more woes from junior programmers over optimizing for "private visibility" than I have noticed the benefits. I can't claim there have been no benefits, so I cede it could be confirmation bias on my part.
Still, I don't want to just turn to nitpicking the examples. I asked, you gave. I'll think on those some.
I stand by my assertion that the abstractions are good for what emacs needs. As evidenced by how well it does keep up, all told. Does it do as well as a staffed resource to build some resources? Probably not. More, it is unlikely to ever be able to make a feature that nothing else can do. By virtue of it being open. If something is amazing from it, others can emulate it.
But, the amount of synergy between modules speaks volumes. Tramp alone is quite amazing at how many modes "just work" with it. With no prior planning on having to expose internals or special methods.
I also confess I expected threading to be mentioned. Another thing which I have seen cause as many errors as it typically helps. Effectively the "goto" of application development. Often best avoided, but also often required.
My impression has been that emacs itself does fine with multiple processes. As seen by the compilation buffer being fine. So, if you setup a sentinel and do the process buffer technique, things can be done. Most people lament the lack of threads, though. More, I think most people do not want to build the necessary stuff for a process buffer to help.
Happy to know where I'm mistaken there. And I've certainly seen places where a blocking call can be annoying. Usually creeps up into a place that was fine at first. Org mode source execution is a good one. For the vast majority of stuff I do in those, I'm fine that it blocks while it gives me the results. Then I'll kick off one block that I should have added the async flag to, but just didn't.
Right. I know if you don't do the process buffer code, you can freeze things. And I can fully cede that doing that for elisp is weird. Same idea in a sly buffer, though, is fine.
Edit: For amusement, I was trying to see how bad it could be, so I made a loop to get the 90000th fib. Which, wasn't enough to see here. Hard to really appreciate how fast computers have become.
sly is easier, there the computation is done by a remote Common Lisp. But the danger may be long running output operations, unless they explicitly give up control for other (possibly green) threads.
But in a Lisp application to not be responsive at all is kind of rare. Most Lisp application runtimes will be able to process interrupts and/or switch "green threads" or "native threads".
Sorry, but it has to be said. Using a more sane language would cut down on the bugs and dependency problems in Emacs in a huge way.
P.S. Been using Emacs for over 25 years.