I think it's more a concern that the hardware isn't useful in the real world, rather than that the hardware doesn't meet the description they provide of it.
Lisp is a family of languages. They share a common ancestry. That family is larger than Common Lisp, although Common Lisp is might be the last living descendant. While there are common traits among members of the family (parenthesized notation, certain special forms, symbol names), the presence of these traits does not itself define the family any more than having fins implies that an animal must be a member of the fish family.
A language is not only its syntax, but also it's semantics. Lisp is not just parentheses or even 'homoiconicity.' In addition to the surface syntax, there is a shared cultural understanding of what certain symbols mean, how they fit together into a system, what a symbol even is, and so on.
Given that, while there is some surface resemblance to lisp, it's plainly obvious to me that Clojure does not belong in that family. This is not a dig at Clojure! Clojure makes a lot of people happy and productive, and that's great. It's my third favorite language on the JVM. But when you take a closer look at some very core design decisions made in Clojure you'll find that they depart strongly enough from all the other languages in the Lisp family that it belongs to a distinct language family. A few of them:
- Reader doesn't intern symbols
- EQUAL symbols aren't EQ
- Introduction of vars
- Cons doesn't cons
- No numeric tower
- Backquote behavior
These things don't necessarily come up in day-to-day programming, so it might seem like quibbling, but these are fairly central differences in meaning.
I think it's sensible to consider "Clojures" as a distinct language family. Rhere are languages like Fennel and Hy that are clearly Clojures, and I'm sure there will be more.
What would be the point of equal symbols being EQ in a functional language? They are effectively EQ because it can compare by value quickly.
Also, is there anything good about cons? It seems like the most obtuse way to do a sequence unless you need something funky that you could implement yourself.
Yeah, "consing" isn't such a big deal in Clojure because its philosophy revolves around "sequence abstraction," which is a significant improvement over the traditional approach. Lispers with a limited understanding of Clojure often criticize its departures from Common Lisp, such as using square brackets for function arguments, without grasping the reasons behind these choices. Once you understand Clojure's destructuring, you'll immediately appreciate the utility. Yet some people resist even hearing about contemporary techniques like modern irrigation methods and cloud seeding, and they'd rather stick with ancestral rain dance rituals simply because that worked for thousands of years.
I'm not here to debate taxonomy. Rich Hickey says: "Clojure is a dialect of Lisp and shares with Lisp the code-as-data philosophy and a powerful macro system." No disrespect, but unless Alan Kay or Guy Steele come to your side and convince Rich to stop calling Clojure a Lisp, I'll be calling it that. Sorry, maybe Mr. Hickey knows better than I do about the language he created?
"Being a Lisp" or "being a dialect of Lisp", these are two different things for me.
But even the "dialect of Lisp" actually is more like "spiritual dialect of Lisp".
Clojure was from the beginning designed with exactly ZERO backwards compatibility to Lisp. Exactly ZERO of the existing Lisp programs/libraries could work. It was even difficult to port them. It's basically a kind of "dialect" with new operators and data structures, which interprets prior concepts in new ways and mixes in new stuff.
But it was designed with compatibility to Java and the JVM -> one could not reuse existing Lisp code, but one could reuse existing Java code -> since Clojure was hosted on the Java and had integrated calling Java code. Reusing Java was more important, because the goal was to work in a Java industry. Thus there wasn't a version of Clojure on top of Lisp, only versions on top of languages/infrastructures like JavaScript or .net, because there was another source of reuse.
If we look at the above linked paper "The Evolution of Lisp", then "Evolution" actually meant "Evolution", not "Restart" -> the language evolved by improving, adding, extending, removing, ... around a core design.
Clojure was designed as a new dialect, free of the baggage from the past, with a completely fresh start. Reusing existing code or evolving an existing language was a non-goal. It was newly designed as a hosted implementation (-> the Lisp runtime was gone), it was designed with lazy data structures at its core (-> the Lisp linked lists were gone), it was an opinioned new design, based upon of what Rich Hickey liked about Lisp and what would help him to be employed as a consultant in a Java world -> by developing upon and within the Java stack of standards, tools and libraries.
And that's fine for him. Rich Hickey had his goals and succeeded with them. Other people found it useful, too.
Okay, look. My native tongue is Russian. In Russian, "being a Russian" has two forms: "Русский" and "Российский." "Ethnic Russian" and "a Resident of Russia." When translated to English, the difference gets blended, but in Russian, it still exists. We can imagine some completely imaginary English dialects in which "Lisp" would have a different meaning, can't we? We can even add some weird rules similar to "Российский Флаг" and "Русский Флаг," which would be translated depending on the context and time differently. We would have to find ways to describe "the subtle differences of 'Lisp' in different contexts." We can pretend we're talking in different dialects where "Lisp" means different things. We can create all sorts of rules and standards. But at the end of the day, for most people, Lisp is like "porn" in the sense that "if it is, you know it." I'm in that school. Clojure is a Lisp to me. Call me a religious idiot. If people can't tell the difference between Common Lisp, Lisp, and Clojure, call them idiots. I don't know, usually when I mean to say "Common Lisp" I'd say it, or I would use "CL" and people usually know what I meant. Then I don't know what we're arguing about.
I usually don't want to call people "idiots", but I would want to prevent confusion. Even though English is a Germanic language, it's not German. It's a matter of expectation. If a book title says "Lerne Deutsch" it's not meant to mean "Learn English". Same for "Learn Lisp" and "Learn Clojure". Both books usually will be about different languages. For example there was a book "The Little Lisper", for Scheme it was renamed the "The Little Schemer". People then knew that the book is using the Scheme dialect of Lisp and not Lisp itself.
Btw., even though "lernen" and "learn" are coming from a common language background (Proto German, also called Common Germanic, no joke -> https://en.wikipedia.org/wiki/Proto-Germanic_language) and here mean the same.
There's no confusion. Anyone who wants to learn Lisp can start with Emacs Lisp, Racket, Guile, Janet, Fennel, Clojure, or Common Lisp, and soon they'd know how they differ. Telling people "Oh no, Clojure is not an actual Lisp" is disingenuous. Yes, there are certain differences, but the main ingredients are there - homoiconicity, macros, REPL-driven. Sure, in some contexts, clarification is required, and usually, it is present. I have never heard anyone say something like "I actually wanted to learn Lisp, but I ended up using Clojure and never found out what 'the real Lisp' is like." When people want to specifically talk about Common Lisp, they say that. Again, I have no idea what the fuzz is about, Clojure is a Lisp. Yes, it's not Common Lisp, it's not Emacs Lisp, we know that. Most people who know just a bit about Lisps, do know that. And yet we're arguing like someone accidentally may end up using wrong Lisp and kill thousands of polar bears or something.
That's "strange", isn't it? It prints as (1 2 3), but it is not a list? So there are things which print as lists, but aren't lists? What? Which also means that when we print it and read it back, it will be of a different type and list? will be true?!
It's not "inconsistent" between the variants. Clojure is a hosted language, it depends on the underlying platform.
In Clojurescript, the implementation details and type checks differ slightly from Clojure due to the different runtime environments (Javascript vs. JVM). As a result, certain predicates like `list?` might behave differently.
In Clojure, it's generally better to use (seq?) instead of (list?) when you need to check if a value is a sequence, as (seq?) is more encompassing and works for all sequence types, not just lists.
You almost never use (list?) in Clojure unless you explicitly need to check for a list created via (list ...), and most of the time we use (seq?) instead.
Maybe Clojure doesn't work for you because you haven't even bothered checking the documentation? At least you could've asked Google or ChatGPT, before crying how "broken it is". The language after all wasn't created last weekend, it's been around for 17 years
You can probably make many like minded friends in r/haskell. Just post something about Clojure and pedants most likely crawl out, saying how it is not an FP-language. :)
It's not "failing" on the simplest basic list cons'ing, it did what's expected, it consed the list. You're trying language features without even bothering to ask if the function you're using does what you think it does.
Have you read the docstring for (list?)? It says "Returns true if x implements IPersistentList". (cons 1 '(2 3)) results in a clojure.lang.Cons not the instance of clojure.lang.PersistentList. A clojure dev would be using (seq? (cons 1 '(2 3))) instead of what you tried.
Maybe before hating something so fervently try to learn it a bit more first?
Clojure is a hosted language. It embraces the idioms, strengths, and ecosystems of the platforms it runs on (JVM, Javascript, .NET, Dart, etc.) without trying to "change the platform" or impose an absolute uniform behavior across different environments.
Clojure encourages using idiomatic patterns that align with the host platform’s best practices. For instance, when running on the JVM, it leverages JVM's threading model and garbage collection; in Clojurescript, it adopts patterns suitable for JS's event-driven model.
Clojure does not try to provide a uniform abstraction layer that masks platform differences. Instead, it exposes platform-specific capabilities, making developers aware of and able to exploit the unique features and strengths of each platform.
Clojure compiles down to the native code of the host platform. For the JVM, it compiles to JVM bytecode; for JS, it compiles to JS code. This means the compiled code runs as if it were natively written in the host language.
Clojure operates within the host runtime, using the host platform’s execution model, memory management, and runtime services.
Being a hosted language means that Clojure does not attempt to hide or abstract away the platform it runs on. Instead, it integrates deeply with the host platform, leveraging its native capabilities and interoperation features. This allows Clojure code to be idiomatic to the host environment and benefit fully from its strengths.
I can only add to that - the hosted nature of Clojure is one of the most underrated awesome features of it. You can write for example a macro that's defined in Clojure code, but to be used in Clojurescript, and changes the behavior of a browser app based on a condition detected in JVM - for example, you can parse some .js library and based on that (clojurescript compiler would) emit modified compiled Javascript code. That stuff is useful for dynamic polyfilling, i18n, css-in-js, feature-flagging, using shims to ensure compatibility, and more.
Moreover, you can have namespaces where Clojure and Clojurescript code is intertwined. I have never seen so much code reusability, even when I was heavily writing for Node. Check this out: you can write specs that would represent your data, alright? Then, you can generate some random collections of data based on those specs. The data that you can use both - on front-end (e.g., for end-to-end testing) and back-end (e.g., for testing the domain logic). You can also use the same specs for validation in UI controls - 'not a valid email', etc. Neat, right?
But why is a list not a list across all platforms?
Other Lisp dialects run on top of the JVM, .net, JavaScript, LLVM, UNIX, iOS, Android, Linux, ... and there is no such problem.
Try ABCL on the JVM. (listp (cons 1 '(2 3))) is T.
I would think that consistency and correctness of basic Lisp operations (-> LISP stands for "List Processor") would be a high priority of any self-respecting Lisp dialect?
Alright, your concern about consistency in basic operations is valid. Yet, it's important to consider the different design philosophies and practical constraints of Clojure and Clojurescript - platform-specific optimizations, type systems, practical trade-offs, etc.
To be honest, I never knew about this (list?) thing behaving differently with (cons) because I personally have never stumbled upon that. Most likely, people raised this question because, like I said, the language has been around for decades. I don't know the proper and accurate answer for you here, that's probably some intentional design choice rather than a bug, driven by the need to balance consistency with platform-specific optimizations and constraints; if that was important, I would've found it and known how to explain it. It is not important (think of it as an easter egg), because...
Like I said before, Clojure emphasizes using seq abstraction instead of lists. It is a core part of Clojure's design and works uniformly across Clojure, Clojurescript, Clojure-Dart and other variants. It abstracts over different collection types, allowing you to work with sequences without worrying about the underlying concrete types. Functions that return `seq` often produce lazy sequences, which can be more memory-efficient and allow for incremental processing. This is particularly useful for handling large datasets or infinite sequences. `seq` functions, such as `first`, `rest`, `next`, and higher-order functions like `map`, `filter`, and `reduce`, provide a consistent API and behavior across different implementations of Clojure. This minimizes the impact of platform-specific differences. In addition, it can often lead to performance optimizations tailored to the specific platform, as it allows the runtime to use the most efficient way to traverse collections.
Yes, Lisp traditionally stands for "LISt Processing," and lists are indeed central to Lisp's heritage. However, modern Lisp dialects have evolved to handle a broader range of data structures efficiently while maintaining the core principles of Lisp. Common Lisp, while having first-class support for lists, also has a broader set of data structures including vectors, strings, and bytevectors. Racket enhances the language with a diverse range of data structures—vectors, hash maps, sets, and streams. Elisp, too, has hash tables and strings. Clojure adds vectors, maps, and sets as first-class citizens. I guess that's why we no longer use "Lisp" as an acronym - we no longer capitalize each letter. I guess one could say "it is still 'LISt Processing' because every expression written in it is a list..." ¯\_(ツ)_/¯
LISP does not stand for "List processing", it stands for "List Processor". To quote John McCarthy: "A programming system called LISP (for LISt Processor) has been developed for the IBM 704...".
This is a programming system, which is a list processor. Not a vector processor, not a graphics processor, not a number cruncher -> it's a list processor.
Now McCarthy defines three basic LISP features:
* Data has the form of S-expressions, for which a definition is given, which is linked lists of atoms&lists. -> a very low level definition.
* There is a LISP language which processes these s-expressions. Simple operators are being defined.
* LISP can interpret and execute LISP programs in the form of s-Expressions.
To sum up: there are linked lists, a programming language for processing them AND the programs themselves can be interpreted by LISP.
He then defines an "universal LISP function", an interpreter for LISP in LISP.
That's the actual core essence of LISP. Think about it!
That's the big thing which was defined in the very first pages of the first LISP papers: a very simple foundation, which describes how to do computation by a List Processor, applied to itself.
This is the core language: a data structure, a few operations and an interpreter written in itself.
Fire up your Emacs Lisp (start GNU Emacs and do m-x ielm). It's all there: the data structure (-> linked lists of symbols), the operations (car, cdr, cons, read, print, cond, lambda, eq, assoc, append, ...) and the interpreter (-> eval).
It's not one of many data structures, it is the central thing: s-expressions, programs as s-expressions, a list processor (-> EVAL) defined in the language it is executing, executing programs which are given as s-expressions, able to execute itself.
All the other stuff you've mentioned is secondary: Homoiconicity, First-class Functions, Macro System, automated memory management, REPL-driven, interactive development.
McCarthy described a specific way to do computation. That's the core of LISP. One which can be taught in a day, which fits on a few pages and which allows us to develop a simple mental model of it.
Clojure does not have the same axiomatic definition of a List Processor, it is not interpreting lists, ... It has a complex data structure at its core: lazy persistent sequences, it compiles code (the compiler is written in Java and compiles to the Java Virtual Machine), it has the JVM underneath, ...
If I break the execution of a list processor, I see the programs as lists being executed by a lisp processor. Write a program in Emacs Lisp, execute it by the interpreted EVAL, run it, interrupt it and you'll see a backtrace where the interpreter runs the Lisp expressions.
If I want to teach people Lisp, I explain this simple LISP PROCESSOR. That's the mental model they need to have: the form of Lisp programs and its execution. Once they have this mental model of LISP, it is valid for all core LISP dialects.
This is also explained in the LISP literature: "LISP 1.5 manual", "Anatomy of LISP" (John Allen -> the book is available here for download: https://dl.acm.org/doi/10.5555/542865 ), "Structure and Interpretation of Computer Programs" (Abelson/Sussman), "Paradigms of AI Programming" (Norvig), "Lisp In Small Pieces" (Queinnec), "The roots of LISP" (Graham) and others. All these explain this foundation (and expand on it).
Clojure is slightly different. It's a modern&pragmatic&opinionated dialect of Lisp for the JVM, which does not have this simple LIST PROCESSOR. That's why it is an dialect of LISP, but not one which shares the axiomatic core of LISP.
While Clojure emphasizes lazy persistent sequences, it still uses lists as a primary data structure and supports list processing. The new data structures are extensions, not replacements, designed to address specific application needs more effectively.
Many classical Lisp implementations also compile code. Compilation does not preclude a language from being a Lisp. Clojure continues the use of s-expressions for code and data representation. Clojure provides a REPL, a staple of Lisp environments.
Clojure retains the homoiconic nature of Lisp. Macros in Clojure very much akin to those in traditional Lisps.
Clojure’s design choices are about extending Lisp principles to solve modern software engineering challenges. Rich Hickey wasn't like: "Lispers were all wrong..." He chose to build the language on top of Lisp principles, and these principles are evident, unmistakably clear and can be seen with a naked eye.
I'm honestly getting worn out by this debate. You're delving into the minutiae of taxonomy, like whether early hominids can be classified as humans, and it's just exhausting. I've told you before, and I'll tell you again — unless someone truly eminent persuades Rich and he eventually concedes, saying: "Yes, Clojure in reality ain't no Lisp..." only then will I alter my position. Until that time, I will continue to call it a Lisp, regard it as a Lisp, and talk about it as a Lisp. The only thing you can do to change my opinion - is to persuade Rich to change his.
You are on the surface. I'm talking about a computing paradigm defined by LISP. A foundational model at the core of the language, enabling us to understand how the List Processor actually works.
LISP has dialects which are not homoiconic, where programs are not written as s-expressions, ... But the core is the same: a specific List Processor. McCarthy himself did not want to write programs as s-expressions. He defined M-Expressions, where S-Expressions were only used for the data.
Check the book "Anatomy of LISP", which is a classic. All the code in the book is written in M-Expressions. Now, Racket gets a new syntax (-> Rhombus). But the language core mechanisms are still there. I'm a fan of the s-expression syntax, but I've also heard&read from many people (incl. McCarthy), that THEY preferred a different syntax. I've seen Apple defining Dylan (Dynamic Language) with an s-expression syntax and then changing the language to a different syntax for broader adoption. You (and me) think it is essential. McCarthy and others thought that it was the wrong syntax for getting wider adoption.
Btw., personally, I don't care that much what Rich Hickey says. I can think for myself.
It is fallacious to suggest that in order to have generic iteration that supports non-list objects, we must abandon the classic list processing functions and give them alternative names and behaviors.
In the TXR Lisp dialect, classic functions like mapcar iterate over nonlists, without losing a shred of backward compatibility over lists.
For instance, we can iterate starting from an integer, in parallel with iterating over a list:
1> (mapcar 'cons '(a b c) 0)
((a . 0) (b . 1) (c . 2))
What we do is pattern the iteration abstraction after the car/cdr model, so that car/cdr iteration falls out as a straightforward special case.
To do this we define an iteration API with four operations:
iter-begin: construct the iterator from the sequence object
iter-more: test the iterator whether it has more elements
iter-item: if iter-more tested true, get the first item
iter-step: calculate iterator of rest of sequence
iter-step may be functional or destructive, so the caller must capture the new iterator returned as a value and must stop using the old one.
Integer:
1> (iter-begin 0) ;; identity
0
2> (iter-more 0) ;; true function: ignores argument, returns t.
t
3> (iter-item 0) ;; identity
0
4> (iter-step 0) ;; successor function
1
Since there are other decent dynlangs out there, the benefits are less about the surface language aspect, and more about the process of getting to a solution. These are the system aspects of lisp that enable an incremental development workflow with a lightning-fast feedback loop. While there are important language features that support this, it's ultimately a "whole is more than the sum of its parts" effect.
I'd recommend checking out videos of people developing systems in lisp. Off the top of my head:
If you are interested in machine learning, check out Gabor Melis's library: https://github.com/melisgl/mgl. It's not an area I'm super familiar with, so I can't speak to it's feature set, but I believe he used it to win a machine learning competition some years ago.
I don't think anyone's written a transformer or diffusion model with it, could be a fun challenge.
lmao, brilliant scientist Elon Musk is NOT. A closer comparison would be general Groves, someone who can get the team and resources in place so the work can get done.
He's actually the complete opposite based on reports of what it is like to work with him at SpaceX and Tesla in recent years. Employees describe having to avoid him so he doesn't meddle in the projects and screw them up.
Maybe he was like you describe long ago but something...happened.
I don't think that's at question in this case. It was decided in Massachusetts v. EPA that EPA is required to make that determination itself. Three years after that decision, EPA basically answered "we think it is."
The court isn't bringing any of that up in this opinion. They are looking only at whether Congress specifically delegated EPA the power to regulate emissions by means of "generation shifting". The majority opinion was "no, they didn't."
Right, right. Guns are absolutely about power. What is interesting to me about this difference between us is that I really, really want people to have that power: I think it is very important that regular people have this "violent potential" as you put it. Having the potential is obviously not the same as deploying it, but having it still matters very much.
Most people are good, trustworthy, and deserving of this power. A few people are not, but taking power away from regular people really won't do so much to help them. In fact, at the end of the day, all it does is force them to become like children, dependent on someone else -- or really, a special class of person, since people absolutely should work together -- for their own security.
"Society" is really nothing more than these people: those that choose "cooperate". It's not the same thing as the "political system" or even the "rule or law". Some people choose "defect", and view the cooperators as prey. Correct me if I misunderstand, but it seems to me, that out of fear of defectors, you want to take power from cooperators and give it to a sanctioned, "regulated" class of people. Presumably because you think you would be safer.
I think you can imagine why this would be ill-considered. If you are concerned about "equality", it's hard for me to imagine a more unequal state. We've basically arrived again at a medieval distinction between peasants, warriors, and priests. Who keeps your warriors in check? The unarmed peasants? The priests with their "regulations"? I'm guessing you are more of a priestly type. I would caution you, your magic is not as strong as you think it is, and it doesn't seem to work at all on the bandits.
It's a bad idea to dox gun owners, but I personally would be very pleased to learn that my neighbors are well armed. I already know a lot of them are. Perhaps you would not be. But if not, consider that you might need better neighbors or maybe a better relationship with them.
I couldn't disagree more. With respect, all of these arguments are specious and exist in the world of fantasy, not reality.
The "dependent on someone else" business is in fact the way the world works, with billions of people, trillions of capital, millions of businesses, deeply interconnected trade, etc etc.
In this reality, everyone has a few jobs that they perform, and many, many jobs they don't. Doing your job, and leaving other jobs to others, is what adults do.
Children are people who don't understand reality and live in their fantasies, dreaming about days that never come, inventing stories about the creatures in their minds, not living in the world.
The question of "who keeps the warriors in check" in fact empirically answers itself, every single day.
Similarly, every single act of civilian gun violence- so unique to the United States- is the evidence against any argument that there is a legitimate role for gun possession.
Finally, with respect to well armed neighbors- the data and logic and every ounce of decency know that a world where everyone has a gun is a world where everyone dies prematurely, violently, needlessly.
The magical thinking is yours. I hope that you come out of it some time. Cheers.
Writing an insult and punctuating it with “cheers” is so insincere and sanctimonious that your argument is it’s own counter-argument.
If you think civilian gun violence is unique to the US, you should really r check in on any country south of our border. All of which have much more restricted gun ownership.
>We've basically arrived again at a medieval distinction between peasants, warriors, and priests. Who keeps your warriors in check? The unarmed peasants? The priests with their "regulations"? I'm guessing you are more of a priestly type. I would caution you, your magic is not as strong as you think it is.
Except, in reality, the peasants are armed to the teeth and not keeping the warriors in check at all, rather they and the warriors tend to pay fealty to the same lords. Although the armed peasantry does like to boast that if they weren't as armed to the teeth as they are, things would be much much worse, that claim seems as dubious to many as the priests' magic.
Isn't it a good thing that armed citizens and the professional warrior caste like police and military -- who are also really just other citizens -- work together?
If you are asking why the glorious revolution hasn't happened despite having an armed to the teeth peasantry, then the answer is simple: the peasants are still getting their bread and circuses.
>then the answer is simple: the peasants are still getting their bread and circuses.
I think you're half right. The answer is the armed peasants like the feeling of power and "violent potential" of their guns, and claiming to be champions of the people keeping the warriors in check, but really couldn't give less than half a rat's ass what the warriors do as long as they get to keep their toys.
