Live data from Hacker News

The Idea of Lisp

dev.to

301–310 of 348 posts

Re: The Idea of Lisp

#301
post #232

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…

IIRC in M-expressions, uppercase meant an atom. You'd write X instead of quote[x]. QUOTE was introduced only for the eval function working on the S-expression form.

Re: The Idea of Lisp

#302

Earlier 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.

QL is a package manager. I'm talking ecosystem/libraries. Use QL to install postmodern and tell me how you feel about its time zone support.

Re: The Idea of Lisp

#303
post #128

Earlier 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…

> 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.

Re: The Idea of Lisp

#304
post #13

Nice 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.

No, that's definitely wrong. Initially they compiled LISP code into assembly by hand (when LISP still looked a lot like fortran) and the plan was to write a compiler in assembly to automate that. Instead, McCarthy came up with a way to express LISP code (aka M-expressions) as data (aka S-expressions) to give a definition the LISP semantics in LISP itself. Steve Russell then hand compiled this definition, and lo, they had a working interpreter of S-expressions. M-expressions were never implemented and the compiler was written in LISP instead of assembly.

Re: The Idea of Lisp

#305

Earlier 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…

Yes, NeWS was cool. But NeWS no longer exists, sadly.

Re: The Idea of Lisp

#306
post #20

Earlier 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?

Pretty much what czinck said.

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

#307

Earlier 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.

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.

Re: The Idea of Lisp

#308

It'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…

If you want to see a Lisp desiged for practicality (other than CL, which definitely was, make no mistake), Kaz Kylheku (who goes by kazinator around here)'s TXR is a neat thing. It's a combination of Lisp and a pattern matching language, desiged for data-munging tasks similar to those done by AWK and Perl. But it's actually better than AWK (I won't go so far as to say it's better than Perl: it is, however, more regular than Perl, which is a nice thing), because the pattern matching language was designed with multiline records in mind, and is a lot more readable than a long regex, IMHO. And the built-in lisp was deliberately optimized for succinctness, something many lisps don't do well. You can find some examples at http://www.nongnu.org/txr/.

And if that's not practical, I don't know what is.

Re: The Idea of Lisp

#309

Earlier 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…

ASCIZ = https://en.wikipedia.org/wiki/Null-terminated_string

Re: The Idea of Lisp

#310

Earlier 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.

So it isn't really functional at all. It just hides the side effects behind a lot of complexity.
Post reply on HN