5 ms·

ANSI Common Lisp is rather a design-by-committee monstrosity which was forced on the unwilling Lisp vendors by the Defense Department. Most of the feature set

ANSI Common Lisp is rather a design-by-committee monstrosity which was forced on the unwilling Lisp vendors by the Defense Department. Most of the feature set was designed via backroom political horse trading ("We'll let you include pet feature X if you support us for our pet feature Y".) There is no coherent overall plan or design to it at all. (Source: personal communication from a member of the committee that designed it.) It's based on actual use on real computers of the late 1970s and early 1980s -- e.g. the file opening mechanism is a complex abstraction designed to support filesystem paradigms that nobody has used for 30 years, yet there is no standard way to open a TCP socket. I heartily recommend Clojure (clojure.org) as an alternative: a modern, pragmatic Lisp designed for 2016-era software engineering.

cesarbs 10y ago
What about ISLISP? Granted, there are much fewer implementations compared to CL.
bluefox 10y ago
Why do you have to resort to such bullshit in order to promote your favorite language. Please back up your claims.
qwertyuiop924 10y ago
Clojure's an odd, unlispish language, at least for us Lispers and Schemers. CL is still very good at what it does: all current implementations have solved many of the problems you mentioned, and there are a lot of libraries that will run across implementations. CL is a beast, but clojure is a mess. Scheme is elegant, but has a radically different, more ALGOL mentality than CL, at least in some respects. Some of it is good, some is bad. I love it, but there are things that I would rather program in CL any day. IMHO, clojure has neither the practicality of CL nor the elegance of Scheme. It has its advantages, but it's not ideal.
- anoctopus 10y ago
  Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.
  - qwertyuiop924 10y ago
    Well, there's the fact that lists aren't conses, and conses as Lispers would expect them to exist don't. I think conses are pretty useful. But Clojure has the cons operator anyways. This also means that clojure's `read` violates one of read's important guarantees: the structure you read in will be identical to the structure you wrote out. Then there's the macro system. Given, it's better than CL's in some respects (it does what you want by default), but there are problems. Like not being able to use macros inside the packages that they're defined it. It's just generally less clean than Scheme's solution, and less versatile than CL's. And then there's all the things its inherited for Java: and object system that isn't properly OO, a lack of TCO (which would be fine, if it weren't for the fact that the language so very clearly wants to have TCO) At the end of the day, Clojure's fine. It's not terrible or anything. I just disagree with some of its design decisions, just like with Racket. But I do object to it being called The One True Lisp for practical use, because that's nonsense. Scheme and CL are both quite practical, and while most Schemes/CLs don't have the Java interop that makes Clojure so full of nice libraries, most of them do have a C FFI. And the C FFIs they have (at least in the Schemes I've seen) are some of the nicest around.
    - anoctopus 10y ago
      I agree that it isn't the One True Lisp, because there will never be one. Clojure is just a nice, modern lisp with some ideas I really like at the core of it's design. I don't really care about having conses the way CL has them, and seqs feel like a very nice abstraction over the concept, though I also tend to use the idiomatic map-heavy style anyway. Clojurescript has the staged macro issue, but JVM Clojure doesn't. I wouldn't even say that Clojure has an object system, and wouldn't want one. Lacking TCO is a shame.
  - 10y ago
lispm 10y ago
Given that most of the hundreds of Lisp implementations each have their own way to open a TCP connection, Clojure just added another incompatible one. To claim that it is a standard one, is a bit funny. Each of the hundreds other implementations could claim that, too. Clojure generally added incompatibilities, since it is fully incompatible to any other Lisp before in fundamental ways. Clojure was designed with zero backwards compatibility. Lisp concepts were removed, renamed, redesigned. Even identifiers with the same name are doing completely different things. If it did something similar to what Lisp did, Clojure sure has it renamed and redesigned. I doubt that you ever had talked to anyone from the ANSI CL committee. It would also have been easy to find out that Common Lisp was designed by a few core people (the gang of five) with lots of community input from 1980 to 1984. This part is well documented. 1984 the first version of Steele's book Common Lisp the Language was published. The ANSI Common Lisp standardization was started later in 1986, when the core of Common Lisp was already defined. Even there the major extensions were designed by small groups with community input. See for example how CLOS was designed by a few people (Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon.) and by providing a complete reference implementation (PCL).
- pjlegato 10y ago
  You missed the point. Clojure's way of opneing TCP connections is standardized within Clojure -- all Clojure programs use a standard API call to do that. Common Lisp, on the other hand, has no standard way of opening a TCP socket at all, because TCP was uncommon when it was designed. It relies entirely on (poorly documented, often unmaintained) third party libraries to do that. As for your doubts, you can doubt all you like, that changes nothing. I am well aware of the history of ANSI CL, and I'm not sure what point you are trying to make with all the namedropping.
  - lispm 10y ago
    > all Clojure programs use a standard API call to do that. Clojure says nothing about creating TCP sockets, since Clojure implementations (all three) need to call the hosting systems call or emulate it somehow. The JVM Clojure uses a different call than the CLR Clojure. Which makes it worse than Common Lisp, which has widely used socket support with usocket and some others. > Common Lisp, on the other hand Is a real language standard with many different implementations. > It relies entirely on (poorly documented, often unmaintained) third party libraries to do that. Each Common Lisp implementation has a documented and maintained way to open a TCP socket. Additionally there are compatibility layers like usocket https://common-lisp.net/project/usocket/ https://common-lisp.net/project/usocket/ > I am well aware of the history of ANSI CL, Then why are you writing obviously wrong things?
lispm 10y ago
> yet there is no standard way to open a TCP socket. The 'standard way' to create a TCP client socket in Clojure: (java.net.Socket. ^String host (int port)) For the .net version: (System.Net.Sockets.TcpClient. ^String host (int port)) It directly calls the functionality from the platform it is hosted on.
- pjlegato 10y ago
  Yes. That's the point. The one standard way to open a TCP socket is with java.net.Socket. Common Lisp, on the other hand, has no such standard way, as TCP was not common when it was designed. It relies on a hodgepodge of poorly documented third party libraries, or vendor-specific extensions to do this. Clojure is, by definition, a JVM hosted language. The .net version is non-canonical.
  - lispm 10y ago
    ^> The one standard way to open a TCP socket is with java.net.Socket. So Clojure the language has no documented standard way to open a socket. One has to use the host environment (JVM, .net, ...) interface to do so. It means also that Clojure/JVM source code trying to open a socket will not run on Clojure/CLR without changes. That's not a 'standard'. It's the definition of 'implementation specific'. That's different from SBCL, which has a documented and maintained way to create sockets, which works similar over all the platforms it runs on - natively. http://www.sbcl.org/manual/#Networking http://www.sbcl.org/manual/#Networking For a portable way to create sockets over many Common Lisp implementations use usocket: https://common-lisp.net/project/usocket/ https://common-lisp.net/project/usocket/

cesarbs 10y ago

What about ISLISP? Granted, there are much fewer implementations compared to CL.

bluefox 10y ago

Why do you have to resort to such bullshit in order to promote your favorite language. Please back up your claims.

qwertyuiop924 10y ago

Clojure's an odd, unlispish language, at least for us Lispers and Schemers. CL is still very good at what it does: all current implementations have solved many of the problems you mentioned, and there are a lot of libraries that will run across implementations. CL is a beast, but clojure is a mess. Scheme is elegant, but has a radically different, more ALGOL mentality than CL, at least in some respects. Some of it is good, some is bad. I love it, but there are things that I would rather program in CL any day. IMHO, clojure has neither the practicality of CL nor the elegance of Scheme. It has its advantages, but it's not ideal.

anoctopus 10y ago
Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.
- qwertyuiop924 10y ago
  Well, there's the fact that lists aren't conses, and conses as Lispers would expect them to exist don't. I think conses are pretty useful. But Clojure has the cons operator anyways. This also means that clojure's `read` violates one of read's important guarantees: the structure you read in will be identical to the structure you wrote out. Then there's the macro system. Given, it's better than CL's in some respects (it does what you want by default), but there are problems. Like not being able to use macros inside the packages that they're defined it. It's just generally less clean than Scheme's solution, and less versatile than CL's. And then there's all the things its inherited for Java: and object system that isn't properly OO, a lack of TCO (which would be fine, if it weren't for the fact that the language so very clearly wants to have TCO) At the end of the day, Clojure's fine. It's not terrible or anything. I just disagree with some of its design decisions, just like with Racket. But I do object to it being called The One True Lisp for practical use, because that's nonsense. Scheme and CL are both quite practical, and while most Schemes/CLs don't have the Java interop that makes Clojure so full of nice libraries, most of them do have a C FFI. And the C FFIs they have (at least in the Schemes I've seen) are some of the nicest around.
  - anoctopus 10y ago
    I agree that it isn't the One True Lisp, because there will never be one. Clojure is just a nice, modern lisp with some ideas I really like at the core of it's design. I don't really care about having conses the way CL has them, and seqs feel like a very nice abstraction over the concept, though I also tend to use the idiomatic map-heavy style anyway. Clojurescript has the staged macro issue, but JVM Clojure doesn't. I wouldn't even say that Clojure has an object system, and wouldn't want one. Lacking TCO is a shame.
- 10y ago

lispm 10y ago

Given that most of the hundreds of Lisp implementations each have their own way to open a TCP connection, Clojure just added another incompatible one. To claim that it is a standard one, is a bit funny. Each of the hundreds other implementations could claim that, too. Clojure generally added incompatibilities, since it is fully incompatible to any other Lisp before in fundamental ways. Clojure was designed with zero backwards compatibility. Lisp concepts were removed, renamed, redesigned. Even identifiers with the same name are doing completely different things. If it did something similar to what Lisp did, Clojure sure has it renamed and redesigned. I doubt that you ever had talked to anyone from the ANSI CL committee. It would also have been easy to find out that Common Lisp was designed by a few core people (the gang of five) with lots of community input from 1980 to 1984. This part is well documented. 1984 the first version of Steele's book Common Lisp the Language was published. The ANSI Common Lisp standardization was started later in 1986, when the core of Common Lisp was already defined. Even there the major extensions were designed by small groups with community input. See for example how CLOS was designed by a few people (Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon.) and by providing a complete reference implementation (PCL).

pjlegato 10y ago
You missed the point. Clojure's way of opneing TCP connections is standardized within Clojure -- all Clojure programs use a standard API call to do that. Common Lisp, on the other hand, has no standard way of opening a TCP socket at all, because TCP was uncommon when it was designed. It relies entirely on (poorly documented, often unmaintained) third party libraries to do that. As for your doubts, you can doubt all you like, that changes nothing. I am well aware of the history of ANSI CL, and I'm not sure what point you are trying to make with all the namedropping.
- lispm 10y ago
  > all Clojure programs use a standard API call to do that. Clojure says nothing about creating TCP sockets, since Clojure implementations (all three) need to call the hosting systems call or emulate it somehow. The JVM Clojure uses a different call than the CLR Clojure. Which makes it worse than Common Lisp, which has widely used socket support with usocket and some others. > Common Lisp, on the other hand Is a real language standard with many different implementations. > It relies entirely on (poorly documented, often unmaintained) third party libraries to do that. Each Common Lisp implementation has a documented and maintained way to open a TCP socket. Additionally there are compatibility layers like usocket https://common-lisp.net/project/usocket/ https://common-lisp.net/project/usocket/ > I am well aware of the history of ANSI CL, Then why are you writing obviously wrong things?

lispm 10y ago

> yet there is no standard way to open a TCP socket. The 'standard way' to create a TCP client socket in Clojure: (java.net.Socket. ^String host (int port)) For the .net version: (System.Net.Sockets.TcpClient. ^String host (int port)) It directly calls the functionality from the platform it is hosted on.

pjlegato 10y ago
Yes. That's the point. The one standard way to open a TCP socket is with java.net.Socket. Common Lisp, on the other hand, has no such standard way, as TCP was not common when it was designed. It relies on a hodgepodge of poorly documented third party libraries, or vendor-specific extensions to do this. Clojure is, by definition, a JVM hosted language. The .net version is non-canonical.
- lispm 10y ago
  ^> The one standard way to open a TCP socket is with java.net.Socket. So Clojure the language has no documented standard way to open a socket. One has to use the host environment (JVM, .net, ...) interface to do so. It means also that Clojure/JVM source code trying to open a socket will not run on Clojure/CLR without changes. That's not a 'standard'. It's the definition of 'implementation specific'. That's different from SBCL, which has a documented and maintained way to create sockets, which works similar over all the platforms it runs on - natively. http://www.sbcl.org/manual/#Networking http://www.sbcl.org/manual/#Networking For a portable way to create sockets over many Common Lisp implementations use usocket: https://common-lisp.net/project/usocket/ https://common-lisp.net/project/usocket/