[bsder]

I'm going to go out on a limb and suggest that Lisp is, in fact, an albatross hanging around Emacs neck.

Using Lisp (and especially elisp) is not okay. Lisp has some very sharp corners that simply are not acceptable in modern languages. I use Lisp when I'm very resource constrained but still need an interpreted language--otherwise I use anything else.

Dynamic scoping is just stupid (fault of elisp). Not being to operate on a sequence is stupid. cons pairs to build everything is stupid. nil() terminated to signify lists is stupid. The pervasive necessity of metaprogramming macros is stupid. An inability to type things is stupid.

Lisp/Scheme encased itself in amber in the 1980's and refused to keep up with genuine improvements in programming languages. Sure it meant they missed out on the collective brain damage that was design patterns and object oriented--but it also meant that it missed out on good things, too.

Take a very hard look at Clojure and look at what parts of Lisp/Scheme Rich Hickey put a bullet in and which parts he kept. The Lispers still excoriate Clojure as "not a Lisp" and that perfectly sums up the problems with Lisp nowadays.

[Jtsummers]

> Not being to operate on a sequence is stupid. cons pairs to build everything is stupid.

There are other sequence types than lists in elisp and pretty much every other lisp out there. And what do you mean with "Not being [able?] to operate on a sequence"? [0] contains a bunch of functions for operating on sequences, and it's notable they don't say list but sequence in their signature. They work on multiple types of sequences, not just lists.

I do agree on dynamic scoping by default, that's a major weakness in elisp.

[0] https://www.gnu.org/software/emacs/manual/html_node/elisp/Se...

[bsder]

Lisp "lists" (cons pairs with terminating nil) act kinda sorta like sequences (although the elisp names don't agree with Common Lisp names)--until you need length() and your algorithm blows up to O(n^2) or you replace a value and your list walker blows itself into a mess. This is part of why Clojure shot the idea of building lists up from cons pairs and gave explicit syntax for certain sequence types and made them fundamental.

Which would be fine if all the pedagogy didn't teach stupid cons-pair lists and recursion as THE fundamental pieces of Lisp when they should instead have a gigantic red klaxon saying "Don't use these outside of toy programs as they're a maintenance and abstraction nightmare."

Other grief: #() syntax makes read-only vectors. The syntax for what is basically [] is every other language: (make-array 5 :fill-pointer 0 :adjustable t) I can go on and on and on about the usability disaster that are sequences and collections in Common Lisp. And then let's add the joy of a Lisp-2 on top of everything else.

The problem is that the Real Lisp Programmers know to ditch those and go grab better abstractions when doing Real Programming. However, the extra abstractions are just annoying enough that stuffing things into an unlabeled list is too convenient. So, you see a small number of good abstractions and a bunch of little unlabeled "containers" passing data around with cadr and caddr. There is a reason why a "labeled struct" is a fundamental part of most languages and gets its own syntax.

And even "Practical Common Lisp," which like I like very much, introduces macros before collections. And look at how much time it spends on vectors and hashes (which are FAR more important to building most programs) vs cons-type lists (this ratio holds even as far back as Touretzky in 1986--it's gotten a little better over the years). And then people wonder why nobody uses Lisp for real programming?

So, sure, you can use the Common Lisp standard--and get saddled with a bunch of good design decisions from 40 years ago that now look absurdly stupid.

Or, you can use Scheme which has nothing built in and construct it all yourself. Oh joy.

Alternatively, you can just use a modern language that made design decisions in merely the last decade.

[CRConrad]

> Sure it meant they missed out on the collective brain damage that was design patterns and object oriented--but it also meant that it missed out on good things, too.

The "collective brain damage" and other similarly derogatory epithets that OOP regularly gets slammed with is AIUI actually Java "collective brain damage"; it doesn't necessarily apply to all forms of OOP.

[bsder]

Well, there are two levels to this:

1) It was in fact mostly C++ brain damage. "Design Patterns" predates Java by quite a bit.

2) OOP isn't a unified thing. There was a paper way back that mentioned something like two dozen "characteristics" of "OOP". And then proceeded to point out that "Smalltalk" chooses these, C++ chooses those, Java chooses these, and that there was a lot of disjointed-ness between the definitions.

[CRConrad]

Yup. So the vaunted "brain damage of OOP" is more a matter of the "brain damage" of C++'s / Java's choice of which of these traits to implement and call the result "OOP".

(Personally, I largely agree -- and I say that as a fan of a basically very similar OO language, Object Pascal [as seen in Delphi and Free Pascal / Lazarus], which could also be seen as an imperative language with bolted-on inheritable templates of records with method pointers called classes. It just made a slightly different, and better [IMO], choice of exactly which of these traits to implement, and that makes a all the difference to me.)