Earlier quoted context omitted.
> John McCarthy didn't implement Lisp in machine code. McCarthy also didn't expect S-expressions to be a concrete form. He expected everybody would write in M-expressions. The fact that S-expressions worked as the language itself is again due to Steve Russell's insight.
The problem was that M-expressions are just really silly way of spelling S-expressions, almost node for node, atom for atom. Whatever disadvantages we agree S-expressions have, M-expressions have all of them, and then some: like extra noise due to punctuation. What are M-expressions? Basically this: (a b c) (quote (a b c)) car[x] (car x) car[append[(a b c); (d e f)]] (car (append (quote (a b c)) (quote (d e f)))) Par…
The Idea of Lisp
301–310 of 348 posts
Re: The Idea of Lisp
#302Earlier quoted context omitted.
This is the challenge I have as well. I want to use Lisp for a lot of things but the reality is that parsing PDFs, tagging parts of speech, and then throwing it all into Postgres/Elasticsearch is a lot easier with a bunch of "gem install" commands than anything I've seen for Common Lisp.
(ql:quickload "packagename") works great in Common Lisp. The QuickLisp package manager has been around for a few years now.
Re: The Idea of Lisp
#303Earlier quoted context omitted.
I don't think actual Lisp programmers share this obsession with purity and ideal forms. It's more something that shows up in blog posts about Lisp by people who probably don't actually use it. The title of this one is telling: it's about "the idea of Lisp." On the other hand, if you look at, say, ANSI Common Lisp, it's not at all some kind of perfectionistic attempt at divine elegance. It's a pragmatic compromise res…
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…
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.Re: The Idea of Lisp
#304Nice article. Check out Paul graham's The Roots of Lisp for a similar exploration in which he shows how to build the metacircular interpreter. > John McCarthy wrote 6 easy things in machine code It was actually Steve Russel, McCarthy's grad student, who had the idea of writing McCarthy's eval function in machine code.
> It was actually Steve Russel I seem to recall reading that McCarthy was actually surprised to discover that Lisp _could_ be run by a real computer; he intended it to be a completely theoretical tool.
Re: The Idea of Lisp
#305Earlier quoted context omitted.
PS seems like a nice language. Such a shame it's stuck on the printer: it seems like it would be a good alternative to FORTH in less memory-constrained environments.
NeWS is a Network extensible Window System developed by James Gosling at Sun in the 80's, which used PostScript not just to draw on the screen (like NeXT), but also (unlike NeXT but like AJAX) to implement entire window managers, user interface toolkits, applications, and intelligent responsive front-ends to networked applications, all in the NeWS window server (like a web browser). NeWS was architecturally similar t…
Re: The Idea of Lisp
#306Earlier quoted context omitted.
The "base rate" popularity of Python is much higher than all those others. This leads (via many mechanisms) to Python being more popular than these others. (The reason it's Python and not another popular language is another matter - I think for various reasons Python was a more popular language for scientific computing).
Could you explain what you mean by the "base rate" popularity?
Python is much more popular in general, which makes it more likely to be popular in any specific subfield, for various reasons:
1. More chance that people who decide to do anything in ML already use Python.
2. There's better existing support for various ML-related tasks in Python.
3. There's a larger audience available for ML-related things in Python, therefore people think it's more worthwhile to code things in it.
etc.
Re: The Idea of Lisp
#307Earlier quoted context omitted.
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…
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.
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.
Re: The Idea of Lisp
#308It's interesting, I'm reading Black Swan at the moment by Nassim Taleb, and one of his big rants is about how we get blinded by idealized, platonic forms and ideas when the real world is messy and inherently unpredictable. E.g. trying to explain the forms of nature with platonic archetypal shapes like circles, rectangles and triangles. Lisp and the community around it kinda has that flavor - getting lost in a world o…
And if that's not practical, I don't know what is.
Re: The Idea of Lisp
#309Earlier quoted context omitted.
There's already a language called Max: https://cycling74.com/products/max/#.WFRNp-wWVpg Your SLIST sounds similar to data structures which go by various names in different languages, e.g. list in Python or ArrayList in Java. Common Lisp vectors support that functionality too. Your VCHAR presumably works in a similar way? I agree ASCIZ is a very inefficient way of representing strings, unless they're guaranteed to be…
Max is the internal name I use for my system. The actual name will be decided when I publish the program. At the top of my description of SLIST, I acknowledge that I may not be the first to define a simple structure like that but I can say that I never got the idea from somewhere else. These lists can be used as an autobalanced binary tree for small lookups? Are these other structures pointer free with next to no ove…
Re: The Idea of Lisp
#310Earlier quoted context omitted.
And how is that implemented under the hood?
Same as in a higher-level statically typed imperative language: mutable arrays contained within larger dynamic buffers for amoritized constant-time append and prepend.