Live data from Hacker News

The Idea of Lisp

dev.to

231–240 of 348 posts

Re: The Idea of Lisp

#231
post #92

Earlier quoted context omitted.

They have gradual typing but I believe they're still enforced as runtime contracts, making them not static types.

In a Typed Racket program that does not import any untyped racket code, there is no runtime enforcement. Runtime contracts are only introduced at the boundary between typed and untyped code. This allows programs to be soundly transitioned from untyped to partially typed to fully typed.

That sounds pretty rad. Do you know what the status is of dependent types in Racket? I have always been interested in that.

Re: The Idea of Lisp

#232
post #70

This article has many misstatements in its first half. > John McCarthy wrote 6 easy things in machine code, then combined them to make a programming language. John McCarthy didn't implement Lisp in machine code. Steve Russell did. Implementing Lisp properly in machine code is not easy; you have to write a garbage collector. To do that in the early 60s, you had to first invent garbage collection . Lisp was and is bril…

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

Re: The Idea of Lisp

#233

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…

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.

Re: The Idea of Lisp

#234
post #56
post #6

Does anybody have a few examples of DSLs people make in a lisp (ideally clojure because I have worked with it a tad)? I've seen plenty of cases where people make a pseudo-dsl via optional arguments, but not seen this so-oft mentioned "yeah we just wrote a dsl for it because lisp" sort of deal.

Matthew Butterick (the author of Beautiful Racket linked in another reply) is solving this year's Advent of Code, all as DSLs: https://github.com/mbutterick/aoc-racket

That repository has last year's challenge and the six days I checked did not involve writing a DSL.

Re: The Idea of Lisp

#235

This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's. The only major difference was that more than 1 function could be defined in 1 source code line. (I think that machine code is nothing but a sequence of function calls where the function is the logic encoded in the CPU itself for each opcode.) Is it fair to compare t…

> This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's.

Far from it. Recursive functions and symbolic expressions were nothing like assembler back then.

> You can indent a Lisp program in any way but the language doesn't require any at all.

One can indent it in any way, but practically people use common indentation styles. Lisp also provides formatting&indentation via the pretty printer.

    CL-USER 48 > '(DEFUN COLLAPSE (L)  (COND 
    ((ATOM L) (CONS L NIL))
    ((NULL (CDR L))
    (COND ((ATOM (CAR L)) L)
    (T (COLLAPSE (CAR L))))) (T
    (APPEND (COLLAPSE (CAR L))
    (COLLAPSE (CDR L))))))


    (DEFUN COLLAPSE (L)
      (COND ((ATOM L) (CONS L NIL))
            ((NULL (CDR L))
             (COND ((ATOM (CAR L)) L) (T (COLLAPSE (CAR L)))))
            (T (APPEND (COLLAPSE (CAR L)) (COLLAPSE (CDR L))))))
> I think with practice, some programmers developed an eye for the lack of structural clues

Lisp has a lot of syntax and structural clues, but you just don't know them. You have to learn them, since much of, say, C syntax knowledge does not carry over to Lisp.

>and made some reasonable size code.

Like the 1 million lines of Lisp code of the Lisp Machine OS? Or the several hundred thousand lines of an editor largely written in Lisp (GNU Emacs)?

> Linked lists are poorly executed in modern computers that rely heavily on locality of data

Lisp nowadays usually does not execute linked lists, but runs compiled Lisp. Some data is in linked lists, but there are many other data structures not made of linked lists. Still the language runtime is often pointer heavy.

Re: The Idea of Lisp

#236

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…

Quite right. That's why Clojure was invented.

Clojure is a modern Lisp with the explicit goal of being a practical and pragmatic Lisp intended for getting real-world software engineering tasks done, not just a grand walled garden with beautiful and pure ideas but without standard libraries for stuff like, say, "opening a TCP socket".

Re: The Idea of Lisp

#237

Earlier quoted context omitted.

You may be interested in checking this out for inspiration: http://www.ccs.neu.edu/home/matthias/HtDP2e/ (It's the Intro to CS book used at my alma mater, teaching programming in Racket)

Tried doing some of that with High School kids -- I have to admit, at the beginning it was very difficult for them to wrap their head around the basic concepts in functional programming. The other issue was that the few syntactical rules and prefix notation, while great in the long term, required the kids to do a bit more of mental gymnastics for even basic things at the beginning, so that didn't help either. But man…

That's why I'm using a library (https://github.com/rongarret/ergolib) to smooth over some of Common Lisp's rough edges. The goal of the book, what I hope will make it unique, is to teach all of the basics without having to get too hung up on the details of CL.

The reason chapter 3 is taking so long is that I can't figure out a good way to get around one of those details. I want chapter 3 to be about parsing i.e. I want the reader to build READ before they build EVAL. So I want to introduce READ-FROM-STRING, and one of the things I want to be able to read from strings is characters. Unfortunately, CL uses the same character (backslash) as the reader dispatch macro character for characters (e.g. #\x) as it does for the escape character in strings. So if you type #\x you get the character x, but if you type "#\x" you get a reader error because the backslash is consumed as an escape character inside the string. I have yet to find a satisfactory solution.

Re: The Idea of Lisp

#238
post #128

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…

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

Re: The Idea of Lisp

#239
post #140
post #106

Earlier quoted context omitted.

The story as I have heard it before is that John McCarthy wrote a Lisp interpreter in Lisp and Steve Russell translated it directly into machine code to get a working interpreter. Wikipedia indicates that Steve Russell implemented Lisp in machine code twice but gives no details. Do you have a source giving additional details of what happened?

Here's an account by McCarthy of the early history: http://www-formal.stanford.edu/jmc/history/lisp/lisp.html

That is the account that I had read before. It only talks about Steve Russell's first implementation and makes it sound like a mechanical transform into reality of a theoretical implementation.

However Wikipedia says that there is a second, and the person that I was responding to indicated that Steve Russell had to create a garbage collector to make it work. Those are things that I had not previously heard, and I'm curious about.

Re: The Idea of Lisp

#240

Earlier quoted context omitted.

Isn't that a tuple containing a unit, and therefore not empty?

It's the closest you can get in Scala to represent an empty value whose type is `Tuple`.

Type names are irrelevant here. Unit could be called "Tuple0", or be defined as a synonym of a type named such. The semantics are identical.
Post reply on HN