341–348 of 348 posts
Earlier quoted context omitted.
`void` in C does not have a value. You can't make a variable and put a void in it because there is no such object as "void".
That is an artificial restriction if C. Also see how ! In Rust is also loosing it's artificial restrictions.
Earlier quoted context omitted.
Immutability was what I had in mind calling it opinionated, and it's an opinion I agree with. After learning Clojure, I now hate working in languages with mutability. It obviously isn't necessary to make working applications, but I like not having to think about where else I'm passing this particular data structure, and the language has enough escape hatches for places when it really would get in the way.
This is merely a psychological issue, because when you're programming in an "everything-mutable" Lisp dialect, you also don't worry about this. If you don't know where else you're passing that data structure and don't care to find out, then ... you don't mutate it. Libraries and API's simply don't mutate the inputs that you pass to them, unless loudly documented otherwise. Thus, mutation is applied in controlled ways…
Earlier quoted context omitted.
Often reference counting is considered distinct from GC; sometimes the term "tracing GC" is used to disambiguate. Refcounting & tracing GC have the same purpose, but different implementation techniques and performance implications; and perhaps more importantly, reference counting can't collect objects which cyclically reference one another.
That makes sense. I guess this is also why CPython uses reference counting as well as mark and sweep?
Earlier quoted context omitted.
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 desi…
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…
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.
Earlier quoted context omitted.
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.
I use Common Lisp, and now sometimes Clojure. I don't get why folks call Clojure a modern-Lisp. I miss the cons cell abstraction, the multiple values support, condition system, the fast start-up times, the native compilation, and executables. Stacktrace in Clojure with no possibility to restart also make me sad.
Earlier quoted context omitted.
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 desi…
> 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.
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.
Earlier quoted context omitted.
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…
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 y…
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/
> I am well aware of the history of ANSI CL,
Then why are you writing obviously wrong things?
Earlier quoted context omitted.
> 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.
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.
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
For a portable way to create sockets over many Common Lisp implementations use usocket: