As one of the few programmers who has worked in CL commercially in this century, my general analysis is that the language has way too much rope. The code base I worked on wasn’t too clever by half, it was too clever by leaps and bounds. I’d genuinely never start a multi engineer project in Lisp ever.
The way I see it, all the power and flexibility of CL is what keeps it alive; any other language would have died off with so little people working on the libraries. I used to not mind this that much, but recently I also started working on Clojure code, and the difference is like night and day.
Any language that has to compete and be acceptable to the larger programming community today needs libraries. So it kind of becomes a Chicken/Egg problem.
I don't think anything today will ever reach the levels of Java usage. Partly because no company is likely to spend on a new language as much as Sun spent on Java.
So you are pretty much well off building on their ecosystem than fight it.
Having said that, TCO is the only thing I missed in Clojure compared to CL.
To take an example: in a project I'm working on, we're using Ring[0] at the backend + bunch of middleware, including Liberator[1]. Take a look at e.g. Liberator docs[2] and tell me, where's a CL library for just that, with so much thought that went into it? Or, in a CL project we had to implement CORS handling ourselves, whereas in Clojure we get it for free. Etc. This kind of story seems to repeat every time I need a library. In Common Lisp, you have to hope that Edi Weitz, Shinmera or Fukamachi wrote something, and that you won't have to patch much to make it work for you. In Clojure, everything I've seen so far[3] makes me expect to find solid and feature-complete libraries whenever I need something.
Now to be clear, I still love working in Common Lisp. It's just that my experience with Clojure made me jealous.
--
[0] - https://github.com/ring-clojure/ring
[1] - https://github.com/clojure-liberator/liberator
[2] - http://clojure-liberator.github.io/liberator/
[3] - I've been writing Clojure for only couple of months, so this may be colored by first impressions.
>Ring is a Clojure web applications library inspired by Python's WSGI and Ruby's Rack.
We have had this on the Common Lisp world for years, see "Clack" and "Lack" -- two libs that work together and do exactly this.
> Take a look at e.g. Liberator docs[2] and tell me, where's a CL library for just that
If you want exactly a "Liberator" in Common Lisp, there has been a good one for 3 years on:
https://github.com/joaotavora/snooze
Note how Snooze uses Clack. Clack is almost a de-facto standard now.
To be honest, REST services can be done with a regular web development routing lib.
>Or, in a CL project we had to implement CORS handling ourselves, whereas in Clojure we get it for free
But it's only adding a few headers to your HTTP headers... Patching the response handler to add those is an easy task in CL (Clack already has the facilities to let you add middlewares into the response handler), does one really need a library for that?
I don't want to sound arrogant, but the complains seem a bit exaggerated.
You can do exactly the same in Common Lisp, by using ABCL.
I am a happy "customer". (ABCL is free)
Clojure for certain feels much more modern. They actually have modern build tools, logging systems, and testing frameworks, which is nice. The emphasis on more data types than just linked lists was amazing, sometimes you just need a hashmap, and Clojure's worked great. The rate of progress on the build tools was frankly spectacular, and some of my favorite libraries in the world are available in Clojure (core.logic anyone?)
The Clojure community has an approach to libraries that is utterly unique in my experience, and I miss it in other languages. Clojure libraries are the most lightly coupled libraries I've ever seen, as they use data as the API (a very Clojure and very Rich Hickey thing to do), which makes tying libraries together a trivial and reliable thing to do. They also have a habit of finishing libraries and not arbitrarily creating competitors for whatever reason. The result is that there are a lot of Clojure libraries that are narrowly scoped, feature complete, and trivial to upgrade if necessary. I really miss that.
Clojure also had some downsides however, both for how we used it and in general. The team that I worked on with it is now mostly Java these days.
Domain specific issues. If you have a bunch of objects that are similar syntactically, but vary semantically, you do not want to use Clojure. Clojure has very poor structures for handling this kind of stuff, and it's very very easy to accidentally go from your pretty record type back to a regular persistent hashmap on accident. Basically Clojure encourages (although does not strictly enforce) hashmap oriented programming. There are some domains where this is fine, but ours was decidedly not one of them.
Guidance wise, interacting with Clojure maintainers was rough. It's their project and they can guide it how they want, and we just got the feeling that they couldn't give a rip about what anyone else wanted. That's their right, but it was super annoying as an end user of the products that they were pushing so hard. We never really had any luck getting any of the bugs or issues that we found dealt with by the core team. We got the distinct impression that they were running the code we submitted and then deciding post-facto that what the code did was exactly what they'd wanted in the first place, but proving that is of course impossible. It's been a few years since I last tried to talk to them, so it's entirely possible that this has turned around since then.
I quit that job before Spec was released, so I cannot really comment on how effective that is in bullet-proofing a Clojure code base. What I can say is that the core Clojure libraries are wildly type unsafe, to a degree that's really only beaten by PHP. There are a ton of core functions that'll change output types without warning, sometimes in several different ways. Nominally this is fine because all the collections are built on top of the seq abstraction, but in reality that abstraction is as leaky as they get. The result is that our code base was littered with "(map identity x)" and "(vec y)" and "(into {} z)" to handle all these little weird edge cases. My suspicion is that Spec is a tacit admission that these little type errors really get out of control in a larger Clojure code base, and they're trying to fix it without having to revamp the entire core library.
That being said, between the two I would start any modern project in Clojure rather than CL. Access to Java, modern libraries for web development, and a much much larger pool of developer talent to access are absolutely killer features for that language over CL.
>That being said, between the two I would start any modern project in Clojure rather than CL. Access to Java, modern libraries for web development, and a much much larger pool of developer talent to access are absolutely killer features for that language over CL.
While I agree with the "larger pool of developer talent", I am already working with ABCL which has pretty easy Java interop.
As for developer talent, What's difficult to find, is to find developers who really grok macros and the "code is data" feature.
When you find one, he/she will have it very easy to jump from CL <--> Scheme <--> Clojure, so i'm not too worried about that.
I'm sad to see this is still the case. When I got into Lisp (Common Lisp) ten years ago, one of the first thing I did was ask what logging library I should use by default. Almost all the answers I got were variations of, "In Lisp, it's so easy to write your own, you shouldn't bother looking for one by someone else." One kind person gave me an FTP url to a tar file on a server at MIT and warned me that it might not work because he thought the person it belonged to might be retired or dead. And then he told me, "You'll see when you look at the code, it's so easy, you might as well write your own." Very frustrating. Every time I see an article like this, I hope things have changed, but at this point I wonder if Lisp is in a sense too good to ever be done right, like the kid who is so bright in school that he never learns how to do anything difficult. But now I'm getting flashbacks to all the speculation and armchair psychoanalysis we used to do about why the Common Lisp community was the way it, and that never did any good.
Right now, you have a pretty solid logging library in CL that is pretty much the go-to for anything but simplest of needs: log4cl[0]. It's feature-rich, performant, and even integrates with Emacs/SLIME. The README covers a lot of those things... briefly. Good luck figuring out how to e.g. use the (log:config) facility for anything more complicated than changing log levels. As you can see[1], it has a huge docstring describing a lot of things, but the description is shallow. It's like 20% of what is needed to figure out common things like just saving output to a fresh file (without automatic log rotation).
This is IMO a good example of the problem I see in those libraries that are actually solid and done. They miss detailed user-oriented documentation, forcing you to wade through code, which can get pretty complex[2].
--
[0] - https://github.com/sharplispers/log4cl
[1] - https://github.com/sharplispers/log4cl/blob/8c42ca6bd07726fc...
[2] - Try to macroexpand a simple call to logger, like (log:warn "Foo" some-object). Performance and power can be nicely wrapped under a clean set of macros, but if you deviate from the intended use case, you'd better have a spare couple of hours for figuring out how things work.
> You can find a library for anything these days
https://www.quicklisp.org/beta/
Kudos to the new Common-Lisp.net!
I would like to recommend to add links to websites like planet.lisp.org to make common-lisp.net look active on a regular basis. Another interesting style is used by haskellnews.org/grouped.
As some one new, but with active interest in Lisp, I'm genuinely curious to know the projects you've worked on.
Unless some one describes it to us, we wouldn't even know what that experience even felt like.
"Graphical Programming with Xerox Lisp"
https://www.youtube.com/watch?v=J4F6ioMKiqw&list=PL80581C8F8...
"Symbolics Lisp Machine"
https://www.youtube.com/watch?v=o4-YnLpLgtk&t=28s
"The Interlisp Programming Environment (1981)"
https://news.ycombinator.com/item?id=5966328
"Interlisp-D Reference Manual Volume II: Environment"
http://www.bitsavers.org/pdf/xerox/interlisp-d/198510_Koto/3...
Pharo just to occasionally check how much it has changed since those days.
Yes, Smalltalk does provide a similar experience to Lisp Machines.
Also if you read Xerox papers about Mesa XDE and Mesa/Cedar, one the goals was to provide a developer experience similar to the Lisp and Smalltalk workstations in the context of a strong typed systems programming language.
I mean not exactly, but mostly like that?
Lisp Machines allowed for multiple applications, the Emacs was only related to the REPL and text editing, aka Zmacs.
https://en.wikipedia.org/wiki/Zmacs
I don't use Emacs regularly any longer, but it used to lack the ability to embedded widgets or graphics on its REPL, one of the reasons why I used to be a XEmacs user instead.
Back to Lisp Machine, you have to imagine that the whole OS is written in a mix of Assembly and Lisp, nothing else.
Then the whole OS was exposed to the developer, as they were single user workstations.
Imagine the ability to access any running application from the REPL and interact with it in some way, for example, reformat the selected image in the word processing application. As very basic example.
Something that on modern systems is only kind of replicated with COM/.NET alongside PowerShell, and it fails short of what was possible.
When an application would trap at any level, the debugger pane gets invoked and you are able to fix the error, followed by redoing the action that triggered the error.
Also the OO system was much more powerful than what most OO programming languages are capable of. You had multiple inheritance, traits (aka protocols), aspects, contracts, multiple dispatch available.
Something I have always felt was a killer-feature of the Windows and Office platforms, and something the industry is moving away from. I never saw what you describe, but I'm sad to increasingly lose what interop we've had since the 1990s and 2000s in exchange for cross platform support, security of one kind or another, and silo'd cloud services.
But then again, what you describe sounds worse not better. Like half "wow, malware playground", and half "I just wanted a nutcracker but all I have available is this hammer factory and the machine shop which built it". Would I see the past differently if I started there, then moved to this present? Would I see COM interop differently if I had started in a world of Apps with constrained interop based on a "share this content with a link" popups?
Along with "if everything's top priority, nothing is", and "one size fits nobody very well", if a system is configurable for any task, does that mean it fits no task very well? A set of magnetic letters on a fridge door lets you rearrange the words to say whatever you want, but that doesn't make it "better than all novels".
But I'd expect a lot of needs for security and encryption since those times had almost no troubles regarding this.
As a fan of lisp and smalltalk myself, and as "one of the few programmers who has worked in CL commercially in this century", I take my emacs hacking sessions as the most similar experience to it I can have in a daily basis, but in the link I posted, Kent Pitman says:
"I don't even find Emacs itself to be equivalently self-documenting and easy to get around in, much less the many systems that Emacs touches."
I did the first version of that, it was easy to get pharo image and program to try it. I highly suggest playing with it.
- feeling of a single language and semantics at all layers - very different OO feel than java/cpp, much more human, much more thoughtful
'Boolean>>ifTrue:' is just the gateway drug.
Not hanging yourself is a convention and most languages that are more mainstream have bigger communities and more conventions (and frankly, more adults encouraging them).
I have a hard time blaming the language for what are essentially organizational problems.
Too many lisp people start projects doing everything with a single implementor.
Therefore the convention starts out as “whatever this guy wants to do that works.” Anyone working in a bubble like that is bound to eventually create something that makes sense to the implementor, but not necessarily outside people.
Which is why you need peer review when you’re writing your code. If you don’t get it, you’re gonna have problems. Maybe there is something about lisp that makes it difficult to review, but I think more likely there is something about lispers that makes them unwilling to do that particular set of work.
> Now make this thought experiment interesting: Imagine adding object orientation to the C and Scheme programming languages.
How was it done in Lisp?
1) various experiments and getting real work experience with 1st and 2nd generation OOP in Lisp (Flavors, Loops, CommonObjects, Object Lisp, ...)
2) various proposals for a standard OO system
3) a small group (with people from Xerox PARC, Symbolics and Lucid) working on an OO system with large amounts of user feedback -> developing a full-blown portable public domain CLOS implementation and using public mailing lists for feedback. The resulting implementation PCL (Portable Common LOOPS) was ported to more than a dozen Lisp implementations. A SPEC was written. Books were written.
The result was CLOS. THE object system for Lisp. Built with the input of hundreds of developers/users.
It worked great. The fear of group work in and for Lisp is massively overblown.
> Why don't they make a free development system that calls to mind some of the lost glories of the LispM, even if they can't reproduce another LispM? The reason why this doesn't happen is because of the Lisp Curse.
The reason is that the first systems were developed in a totally different environment: large research organizations like PARC and MIT AI Lab swimming in DARPA money employing the brightest minds of their generation. A genius like Richard Feynberg wanted to work there: '...many a visitor at Thinking Machines was shocked to see that we had a Nobel Laureate soldering circuit boards or painting walls...' http://longnow.org/essays/richard-feynman-connection-machine...
The hacker community can't replicate that in their spare time.
This is really like some one describing Ice Cream to a person who never tasted it ever.
The solution is to be sad, in the same way we can be sad about the loss of the library of Alexandria, and move on, creating new works of beauty. As brought up above though, it's very hard to do this in your spare time... Few are lucky enough to hack with CL professionally, and I would wager even fewer still of those are any less free than other companies' employees of business needs coming first and forcing some terrible choices in the development cycle. Still, there can be beauty in the system, and CL is very much a systems-oriented language... (https://www.dreamsongs.com/Files/Incommensurability.pdf describes it as more of a programming system than a programming language, even.)
I mean I understand licensing and all that, but much of that code is past its commercial use.
Merely reading OnLisp and Let Over Lambda felt like some one opened up a new portal to a world most of the world's programmers don't even know exists.
I would die to read and learn from code written in the past.
Which, IMO, is mostly bollocks. See: CLOS, Quicklisp, Clack/Lack, ASDF, etc.
Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming.
My personal favorite WTF from CL was the :around methods from CLOS. These allowed you to wrap a function with other functions, possibly from a completely different place in your code base, and handle any setup/teardown as needed. We typically used them for database transactions, along with the ability to catch exceptions and trigger a DB rollback. The catch was that every single around method had to call the magic (call-next-function) function, otherwise the main function would not be called. Wondering why in the hell the function you just called isn't actually executing is quite a brainfuck, especially when it was caused by a bug in a completely different package.
CL + Emacs was truly great though, best editor to language integration I've ever seen, period.
Java has public/private/protected/package-scope, but you can get around it trivially with reflection. (Java 9 I think "fixed" this, but you can override it at startup time.) Personally I'm in favor of Python's "we're all adults here" philosophy.
Proxy patterns are common in large Java code bases, and various other things inspired by aspect-oriented programming. I've never thought to blame the language though because someone forgot to call (or decided not to call, e.g. because it got too smart with a cache) child.method() on the real object it is wrapping.
Its a big like what Larry Wall talks about code complexity(https://en.wikipedia.org/wiki/Waterbed_theory). Basically if say a language X provides in built feature to do complex task Y, and it a little hard to understand. In another language Z which lacks the feature, the code that one has to write to achieve Y will be equally complicated and hard if not more.
Sounds like a not-so-appropriate way of doing it.
I do this by wrapping my transactions... on a (with-transaction ) expression! Which is easily done using CLSQL (common lisp lib). This would do exactly what you want: exec the rollback, etc. Note that I speak from personal experience: this has worked perfectly on a commercial project.
>Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming.
CL is, mostly, for ideally experienced engineers. And i'm not being smug or elitist here. Ideally experienced engineers are able to leverage the full power of CL.
>when deadlines are looming.
And the reason to use CL is precisely to enable greater speed of development for complex stuff, so deadlines don't scare you so much (compared to using a lesser-featured language like Java for example)
for me the "rope" was the ridiculous complexity of things like the "loop" macro. Coming from a newb (to CL) perspective and wondering "how do i use this thing" ... ugh you could probably write a small book on all the different ways to use that thing. This type of stuff was littered through the language. Instead of small focused functions that were really self explanatory, but limited in capability, you have things that are way too ... i dunno "configurable"? "modifiable"? There were also thinks akin to "method overloading" but done by a drunk person seeing how many "useful" ways they could call this one function.
The core language documentation is extraordinary. Probably better than any language out there.... but I moved on to Chicken Scheme for my personal work. Life was much better afterwards.
You are not forced to use it. I like the LOOP macro, but there are many alternatives, which you can easily load and use.
>Instead of small focused functions that were really self explanatory, but limited in capability, you have things that are way too ... i dunno "configurable"?
So, for example, it looks like you would have liked to use the ITERATE lib instead of the LOOP macro.
The worst bit of rope I ever personally saw was reader macros. These allowed you to essentially modify the grammar of the language on the fly, inserting functions into the lexer to handle unknown symbols at read time. This is exactly how the quote operator, which allows you to insert literal code without running it, works. Since this happened at run time, any reader macro you registered affected all files that were read later, and thus was build order dependent. If you wanted to use your reader macro in every file, you better load it first and hope it doesn't break any of your libraries.
CLOS, the standard OOP structure of CL was also full of foot guns. It's super impressive that they managed to add an OOP system to an existing language without breaking everything, but the design was .... dangerous. CLOS has some pretty weird rules around method routing, with the methods existing outside Objects and routing be handled by argument specificity. The moment you find yourself extending classes just to win the specificity race with another method you have gone too far and it's time to turn around and go back down whatever road you came up.
For the most part CLOS was fine, but you could design yourself into some really weird corners. The worst part about CLOS was the before, after, and around functions. These allowed you to add functions that wrapped your regular functions, possibly multiple times with order of execution being handled by similar specificity rules. The kicker was that every of these methods was responsible to call the magic "call-next-method" function, which continued the call chain down the stack. If an around method did not do this, the main method would never execute. It is super confusing to manually call a method, only for it to not execute or trigger your debugger, especially since you can register around methods on any method from any package.
Also, CL has a very weak definition of package privacy. Any public symbol, function or otherwise, is accessed externally with the form "package:symbol". But private symbols, those not explicitly exported, can be accessed with "package::symbol". Much like ruby's much maligned "send" method, there's nothing preventing sane programmers from staying way the hell away from private methods. But just like ruby's send method, that is a mighty tempting tool to leave laying around when deadlines loom and pressure is mounting.
Before I finish, a sibling comment mentioned the loop macro. This thing is absolutely insane, I personally stayed way away from it because I never really mastered it, and syntactically is didn't match anything else from CL. Here's a valid example from the "LOOP for Black Belts"[0] page.
(loop for i in *random*
counting (evenp i) into evens
counting (oddp i) into odds
summing i into total
maximizing i into max
minimizing i into min
finally (return (list min max total evens odds)))
And before you ask, no symbols like "counting" are not already functions in the lisp standard. That would be far too easy. God help you if you have a loop call that needs to be modified just enough to make using loop unfeasible.
[0] http://www.gigamonkeys.com/book/loop-for-black-belts.html
Common Lisp has readtables, which you can create and change. So you can read certain files with a different readtable, leaving the default intact.
> It is super confusing to manually call a method
This is just the usual super method call in most object-oriented programming languages. If you have method and you want to call the method from the superclass, you have to explicitly call it.
> loop macro
The LOOP macro is not CL specific. CL has inherited it from Lisp Machine Lisp, which got it from Maclisp. At MIT it was even a single source file for several different Lisp dialects. The origin of this macro is actually Xerox' Interlisp - where it was called FOR.
It's not that bad once one masters the basics and the documentation is in the ANSI CL standard.
The upgrade from LOOP is the ITERATE macro, which even more powerful, but with more parentheses:
That a footgun can be occasionally be handled carefully does not erase the fact that it's a footgun. The ability to modify the read table on the fly is for certain super interesting, but IMHO very dangerous. I am glad that the languages I use on a daily basis do not have this capability, for certain.
> This is just the usual super method call in most object-oriented programming languages. If you have method and you want to call the method from the superclass, you have to explicitly call it.
Not a good comparison. While there is some similarity to super in languages like Java, the :around and call-next-method in CLOS is far more dangerous. In Java, super calls are inside the method in question, any stupid decisions around super are right in front of you. In CLOS, it can be in any file in your code base. This makes the source of the problem far less clear, and expands the possible scope of WTFs by a lot.
> The LOOP macro is not CL specific. CL has inherited it from Lisp Machine Lisp, which got it from Maclisp. At MIT it was even a single source file for several different Lisp dialects. The origin of this macro is actually Xerox' Interlisp - where it was called FOR.
An interesting history, for certain, but still jarring as hell, in my opinion. Macros like these are un-lispy, and really never should have been included. I always avoided them for the more primitive looping constructs, but which ones exactly now slip my mind.
Haven't seen much danger with it in practice.
> In Java, super calls are inside the method in question, any stupid decisions around super are right in front of you
The problem you mentioned was when the super call was missing. You have to find out which method gets called for the runtime object and then see that the super call is missing.
In CLOS I'd list the applicable methods and edit the first :around method.
True, CLOS is the much more complex system, with a meta-object protocol, generic functions, multi-methods, multiple-inheritance, meta-classes, method combinations, ...
Java was designed for the simple case and then promoted for the 'industrial programmer' - which explains part of its success - but it got complicated soon and people added for example Aspect Oriented Programming to it - which has similar features like CLOS :around methods.
> Macros like these are un-lispy
Not really. What you think as un-lispy is perfectly fine for many. There is a tendency to narrow down the language to simplify it, like Dylan or many others. Lisp is always more about freedom of design, experimentation, flexibility. Otherwise we wouldn't have widely different extension approaches in one language: format strings with loops, a whole complex language for printing code, macro like LOOP, ...
Sure you can just use macros to reorder arguments and make code more convenient, but at the same time you can use macros to add radical different sublanguages - that's one of the reasons I use Lisp - it allows me to do that and many have implemented very interesting language extensions on top of Lisp. Personally I think with some practice LOOP macros are relatively easy to write and I even prefer them over tail-recursive loops in Scheme - which are IMHO much harder to follow.
You know, there are languages that don't allow you to shoot yourself in the foot, because they don't allow any guns.
I prefer languages with power.
>The ability to modify the read table on the fly is for certain super interesting, but IMHO very dangerous.
> I am glad that the languages I use on a daily basis do not have this capability, for certain.
Reader macros are there to be used when they are necessary. And in those cases, they make ALL the difference in the world. In such cases, the "languages that do not have this capability" will require a lot of code, often hard to maintain, to achieve the same result.
So, i prefer languages with guns.
>Macros like these are un-lispy, and really never should have been included.
LOOP wasn't included on a whim. Read about the Common Lisp standard creation, it was based on at least a decade of experience writing Lisp for "serious" stuff.
Note that the compiler will often tell you if the LOOP is wrongly written, at compile-time.
It is ugly to some. I love it. On imperative programming, a big part of programming is doing iteration. LOOP makes iterative code read easier, natural, as you sample code snippet proves. LOOP looks like that because it's a DSL; it is a DSL tailored for doing iteration.
>How do I figure out what magic keywords are available within this loop macro? It's maddening!
Yeah, but then it comes on second nature.
Again, you're not forced to use LOOP, there are alternatives like ITERATE.
If you just want option types that you can use with lists, the most direct way to do that is by encoding None as NIL and Some x as (list x), which still lets "no value" be false, makes "some value" true even for the empty list, and pairs nicely with pattern matching libraries like Optima (which people yearning for option types might also be interested in):
(match maybe-value
((list value) value)
(nil 'not-found))
It might also make sense to represent the absence of a value by just not assigning a value. For example, CLOS instances won't bind their slots to anything by default, so trying to read them will signal UNBOUND-SLOT. You can check if it's bound beforehand with SLOT-BOUNDP, and CLOS does differentiate between a slot not being bound and a slot not existing at all. If you're working on something interactively and UNBOUND-SLOT gets signalled, by default execution will pause, and Lisp will offer strategies for resolving the issue, like entering in a value to use instead for just this call, entering in a value to store in the slot for later use, just aborting the computation, etc. That's a pretty nice experience (and just the tip of the iceberg) that people coming from more static languages might not even think about.
If you're returning a value to someone, maybe it would be best to work like GETHASH does and return two return values, the first either a value pulled from the table or a default, and the second a boolean indicating whether the key was present or whether you got the default. Because Lisp has multiple return values (not like Python or Ruby where you're really just returning a sequence and then destructuring it), callers that are fine with the default and don't care if it was actually present can just use the primary return value, and since the default is provided when you call GETHASH, you can also do nice things like (incf (gethash key hash 0)).
There's other ways too, of course, but it's impossible to say what would be the most appropriate solution without knowing more about the problem. (eq nil '()) returning T is not a bug, so the issue must be higher up the call stack. If that seems like a dealbreaker to someone, they're probably just looking at it in isolation and not thinking in terms of Lisp as a whole.
There is a boolean type in CL. You can declare variables as boolean and they will be enforced to hold the T and NIL boolean values.
>Maybe I'm nuts, but that really isn't acceptable in this century.
Perhaps you haven't realized this: Booleans are all over the place in CL, they are first class: Any value is true in CL, except the NIL value, which is synonym with the empty list (). This sounds strange, but makes perfect sense in practice and makes writing code really easy.