Hacker News new | comments | ask | show | jobs | submit login
Show HN: A notebook-style Common Lisp environment (github.com)
180 points by cddadr on July 8, 2017 | hide | past | web | favorite | 130 comments



This is really cool: now, I'll have a reasonable way to introduce my coworkers to lisp without making them learn emacs at the same time. Anyways, would it be possible to include something like parinfer or paredit here, as well as some reasonable keybindings for them. In vim mode, I find these keybindings extremely ergonomic (loosely based on slimv's settings): https://github.com/fiddlerwoaroof/dotfiles/blob/master/emacs...


Why would you need to introduce your co-workers to Emacs? I have recently got in touch with clojure and developed in atom with parinfer. Was I missing out on something or is the difference between clojure and common lisp decisive?


The main reason is that the emacs mode for common lisp is mature and is what almost all CLers use (unless they use a proprietary environment). So, its CL-specific features are generally more polished than other editing environments (e.g. it has a macro stepper, various cross-reference utilities and other such niceties which are either lacking or buggy in other swank clients).


SLIME is hugely powerful.


There are SLIME plugins for many editors, including Atom.


I haven't used Atom-SLIME much, but the little I've used it makes it seem like it doesn't quite have the range of features the Emacs mode has


Can somebody comment on the status of Lisp in 2017?

If one were to learn a functional language, is Lisp a good choice today? Or is Haskell more appropiate?


Haskell is the pureset functional language. If you want to learn the principles behind the functional programming paradigm learn haskell but its hard. The effort is worth it. But there are situations where the performance is worse compared to other languages but it is the best place to learn FP.

If you are hacking on stuff or doing it as a hobby, learn Scheme. Something like Chicken Scheme is good. Small concise language but a great scarcity of libraries. If you want a pretty ide for scheme or write your own scheme use Racket.

If you want production code in lisp with good library support use Common Lisp. Clojure is better because of better functional programming features than CL but debugging requires knowledge of Java as it runs on a JVM but the plus is you can seamlessly call java libraries which are numerous (more than what is in CL).

OCaml is functional programming with Objects. It it used where there is a need for performance like compilers with the advantage of a functional paradigm. But OCaml is a pain to work with for any Non Unix systems. F# is functional programming for dotNet. Then there is Scala which runs on JVM like Clojure and so has the same pros and cons except Scala is closer to OCaml and Haskell than to Lisp.(ML family)

Depending on your platform make your choice. OCaml is horrible for Windows. Haskell works. Scala and Clojure just need java so platform makes no difference. Schemes mostly have an interpreter for most platforms. Make your choice.


> Clojure is better because of better functional programming features than CL

CL now has [shameless plug] an excellent functional collections library, FSet [0]. Using FSet greatly expands the range of algorithms that can easily be written in a functional style. It's been a while since I looked at Clojure, but my impression is that FSet has a substantially richer API, including a bag (multiset) type and many more operations.

I don't know exactly which Clojure features you have in mind, but I suspect that FSet makes CL at least as good for functional programming as Clojure.

[0] https://github.com/slburson/fset


You seem to be the author (of FSet), is that right?

It's an interesting coincidence - just yesterday I learned about FSet while searching for something else and thought it's interesting. However, after arriving at https://common-lisp.net/project/fset/Site/Project.html and reading through the page I left it without installing.

For the very wrong reason, too: I just couldn't find the source code. Obviously, I didn't try very hard, but on the project page (which looks a bit too minimal, btw, some CSS wouldn't hurt) I didn't find a link to the repo. I think it would be great if you added it on top of the project page.


Okay, thanks for letting me know. I guess I should just move all the text to GitHub at this point.


Oh, I should have mentioned also, it's Quicklisp-loadable. Really, these days, whenever you're looking for the code for some library, Quicklisp is the first thing you should try.


Does Clojure predate FSet? If you hadn't written "now" here, I'd have guessed otherwise.

My only complaint about FSet would be map default values; not necessarily the fact they exist, but (1) when using defaults, that two maps can compare equal even though they have different defaults, and (2) when not using defaults, the way they nevertheless intrude upon the map-union protocol, necessitating handling of otherwise unused default values (usually NIL).

But I love FSet when using CL. Thank you for writing and publishing it!


I don't remember when I first released FSet. I did write it before Clojure showed up (2004-ish). Anyway, by "now" I just meant that FSet was a relatively recent arrival in the history of CL, not that it was necessarily newer than Clojure.

Agreed on both counts about map default values. I've been wanting to change how they work, but the change I have in mind would be incompatible. Here's what I'm thinking. Instead of every map (and seq) having a default, which defaults to NIL, we would distinguish maps with defaults from those without. Doing LOOKUP on a defaultless map at a key it has no mapping for would signal a condition (similarly for an out-of-bounds lookup on a defaultless seq). Then the defaultless versions could be used more conveniently with UNION (and COMPOSE, another place where I've tripped over this problem).

I was thinking that creating a map without supplying a default should give you a defaultless map, and that's how I wish I had done it from the beginning, but making it work that way now would break a lot of code. I could release it as a new major version (and call it "fset-2" in Quicklisp so people don't pull it down accidentally). Or, I could leave the existing constructor behavior unchanged and just add a new defaultless map (and seq) constructor. I think this is considerably less elegant, but it wouldn't break existing code. What do you think?


> What do you think?

I have no way of knowing how such changes would affect the wider installed base of FSet. All I can tell you is what I'd prefer myself.

I wouldn't mind, and actually prefer, if the default SEQ would signal a condition on out-of-bounds access (I'd also suspect that not a lot of existing code would break, but there's no way for me to know that.)

On the other hand, I don't think I'd get much besides having to rewrite code out of map lookups signaling a condition. I glossed over my uses of LOOKUP. For most lookups, the case of some element not being present in the map is normal behavior, expected and handled.

For a minority, an element not being present is an error, but for a majority of those, a specific error message is appropriate, so there'd still be explicit checking and no advantage from signaling within LOOKUP.

The smallest group of LOOKUPS expects the lookup to succeed without checking. In all of these cases, the lookup will succeed unless some code is buggy, and in all cases, a bogus NIL would be consumed immediately by a function that would signal a condition on getting a NIL.

So my personal favorite default kind of map would return (VALUES NIL NIL) for lookup failures but would not have a default for purposes of the MAP-UNION etc protocols.

An alternative (or additional) change that would work for me would be an additional optional function parameter to MAP-UNION and friends which, if present, would handle default values.


Don't forget Racket, it's a beautiful language and IMO pretty practical.


> If you want a pretty ide for scheme or write your own scheme use Racket.


Oops, somehow I overlooked that!


I'd argue that it's anything but practical. Great documentation, but discoverability is severely lacking.


To me, the idea of functional languages seems a bit of the wrong abstraction and functional programming style is a better one. Sure some languages make it easier or harder to program in an imperative or functional (or object oriented) style...I mean it is easier to program in an object oriented programming style using Smalltalk versus Common Lisp (even though CLOS is robust) and much easier to program in an imperative style in C than Haskell due to the way Haskell treats non-idempotentcy.

In 2017 the status of Lisp is about the same as it has always been only more accessible than ever given faster networks over which to download tools and to find documentation...e.g. the Racket ecosystem. And a person who starts exploring one of the Lisps today will learn as much or perhaps more (due to generally better access to diverse information about programming) than at points in the past.

My opinion reflects my bias, but in general I think Lisps are more accessible than Haskell because there has been more time to smooth over the rough edges related to the more significant underlying mathematical/theoretical concepts (lambda calculus versus type theory) and perhaps because lambda calculus is a bit more easily understood than type theory (or perhaps not). There's also a much stronger pedagogical tradition of Lisps as teaching languages (forty years or so) at the undergraduate level than with Haskell.

But in the end, why not both?


Lisp isn't really a functional language, it just pioneered a lot of concepts in functional programming. It has almost no concept of immutability, imperative code is everywhere, and if you try to write in a pure functional style you'll probably find it awkward compared to something like an ML-style language.

Lisp is a multiparadigm language. It has closures and higher order functions and uses them where they make sense; it also has a lot of imperative constructs, and a very sophisticated object system. They all work together and make Lisp a unique, interesting language. If you're only interested in the functional parts, you'd probably be happier with Haskell or Clojure.


Clojure is lisp actually. It is also mutable but it makes mutability as an explicit transaction but the entire thing runs on a JVM so you can use all Java libraries (so no library scarcity for lisps). So if you are doing heavy work it is either this or Common lisp. Clojure is preferable because Java has more momentum than CL.


Yes, Clojure is a Lisp. Lisp is also the shorthand way people refer to Common Lisp. Lisp in the context of OP means Common Lisp.

Common Lisp has an implementation, ABCL, which runs on top of the JVM. Access to the Java ecosystem is a shared trait, not a difference.

Being a multi-paradigm language CL has a wealth of features That Clojure doesn't and they all play well together. Except for the type system and the class system.

For example, it has places and the ability to define your own setf forms.

Common Lisp makes iteration easy with the lisp macro.

Common Lisp has tagbody and gotos so one compile FSMs efficiently

Common Lisp has an object system were the semantics are describe using the same object system. So users can extend the object model according to their needs.

Clojure is designed to support one style of programming envisioned by its hypemaster. Rich Hickey is a brilliant person, and has done an excellent job designing Clojure, but

Clojure approach to 'user erros' is we don't guarantee to signal an error, we may do w/e.

By momentum you mean it is trending. We know mainstream programming is a pop culture, but we shouldn't encourage it by recommending one language over another based a FAD.


> We know mainstream programming is a pop culture, but we shouldn't encourage it by recommending one language over another based a FAD.

To further underscore this point, Common Lisp was created in 1984 incorporating elements of proven late 1970s Lisps like MACLISP; CL has been successfully used on spaceships and important complex systems, and the CL ecosystem continues to evolve and grow till today. The specification has been unchanged since the '80s and probably won't change any sooner, since the language is extensible and thus can evolve as the state of the art evolves.

CL is largely free from any kind of fad; everything that is built into the language is there either because (a) it has been proven to be necessary and proven to work correctly in the best way possible, or (b) was needed for backwards compatibility with earlier lisps.

Clojure is a new language and tries to be nice to newcomers, but it's difficult to compete against technology that has at least 33 years of continuous evolution. Also, if you need to interoperate Java classes with CL, there's ABCL which will do it nicely.

As a lisper said, "those who don't know Common Lisp are doomed to reinvent it."


Armed Bear Common Lisp[0] runs on the JVM.

0: https://common-lisp.net/project/armedbear/


So does Frege [0]. (Your Haskell dialect that runs on JVM) But you know what compared to something like SBCL or Clojure they are just not that popular. They do deserve more attention though.

[0] https://github.com/Frege/frege


The original LISP is pure functional in the sense that you don't change state of an object.


> The original LISP is pure functional in the sense that you don't change state of an object.

Are you sure about that? RPLACA, RPLACD, NCONC, etc are present in the Lisp 1 Programmer's Manual dated March 1st, 1960: http://bitsavers.trailing-edge.com/pdf/mit/rle_lisp/LISP_I_P...


The original paper of LISP by John McCarthy http://www-formal.stanford.edu/jmc/recursive.html

Or the more accessible explanation by Paul Graham http://www.paulgraham.com/rootsoflisp.html

There are only few primitives and no such things as RPLACA, RPLACD, and NCONC.


> The original paper of LISP by John McCarthy http://www-formal.stanford.edu/jmc/recursive.html

> Or the more accessible explanation by Paul Graham http://www.paulgraham.com/rootsoflisp.html

> There are only few primitives and no such things as RPLACA, RPLACD, and NCONC.

That paper is from a month after the manual I posted. It's pretty open about not covering the entirety of Lisp, too, for instance in the section "The LISP Programming System" it says: In addition to the facilities for describing S-functions, there are facilities for using S-functions in programs written as sequences of statements along the lines of FORTRAN (4) or ALGOL (5). These features will not be described in this article.


The implementation by Steve Russell includes those facilities, but the original idea of LISP by John McCarthy don't have to include those facilities and can be implemented as a pure functional language and is shown in the paper.


But can you find anything to point to from that period that talks about an actual programming language called Lisp from that time that was purely functional? McCarthy's 1960 paper isn't about Lisp, it's about recursive functions of symbolic expressions and their computation by machine, using a subset of Lisp as a vehicle for talking about the latter part. The section that is actually about Lisp has an explicit disclaimer that he will only be talking about Lisp as it applies to the broader theory he is discussing. It's about Lisp in the same way that SICP is.

No one's denying that Lisp's early history wasn't wrapped up in early research on functional programming, but I haven't seen any evidence to support the claim that any programming language or anything called Lisp from that time period was purely functional.


So the definition of "LISP" matters. Your definition of LISP seems to be the actual implementation, such as LISP 1. But as many historians say, LISP was invented in 1958, which the implementation did not even exist. From this fact, LISP does not only mean the actual implementation, but also the idea and the idea is written in the 1960 paper, which represents a pure LISP. The idea is the most important thing of LISP and that is why McCarthy is called the Father of LISP and Steve Russell is not. To further say, there may not exist a pure implementation of LISP in 1960, but there exists the idea of pure LISP in those days that is shown in the 1960 paper.


I found an even older reference to impure Lisp; doubt I'm going to do better than this: McCarthy's 1958 paper "An Algebraic Language for the Manipulation of Symbolic Expressions"[0], immediately after introducing our good friend car, says: "For example, statement beginning car (i) = causes a quantity to be computed and stored in the address part of register leaving the rest of the register unchanged."

0: http://www.softwarepreservation.org/projects/LISP/MIT/AIM-00...


My point was that I have never seen any evidence that such an idea was ever called Lisp. Even the 1960 paper differentiates between the functional programming theory and the language Lisp being used to explore that theory. If we're bundling all the theory leading up to Lisp under the "Lisp" name, then why stop at McCarthy? Church's lambda calculus was definitely purely functional.

As for McCarthy's original conception of Lisp, in 1979[1] he wrote: LISP also allows sequential programs written with assignment statements and go tos. Compared to the mathematically elegant recursive function definition features, the ``program feature'' looks like a hasty afterthought. This is not quite correct; the idea of having sequential programs in LISP antedates that of having recursive function definition.

1: http://www-formal.stanford.edu/jmc/history/lisp/node4.html


>My point was that I have never seen any evidence that such an idea was ever called Lisp.

I'm not the only one who has this view.

From Paul Graham, http://www.paulgraham.com/rootsoflisp.html

"There were already models of computation, of course - most notably the Turing Machine. But Turing Machine programs are not very edifying to read. If you want a language for describing algorithms, you might want something more abstract, and that was one of McCarthy's aims in defining Lisp. The language he defined in 1960 was missing a lot. It has no side-effects, no sequential execution (which is useful only with side effects anyway), no practical numbers, and dynamic scope. But these limitations can be remedied with surprisingly little additional code. If you understand McCarthy's eval you understand more than just a stage in the history of languages. These ideas are still the semantic core of Lisp today. So studying McCarthy's original paper shows us, in a sense, what Lisp really is. It' s not something that McCarthy designed so much as something he discovered. It's not intrinsically a language for AI or for rapid prototyping, or any other task at that level. It's what you get (or one thing you get) when you try to axiomatize computation."

Since the word LISP is not mathematically defined and has different meanings in different contexts, there are different views of what LISP is and I understand your confusion.


> The language he defined in 1960 was missing a lot. It has no side-effects, no sequential execution (which is useful only with side effects anyway), no practical numbers, and dynamic scope.

The language LISP I in 1960 had numbers, side-effects and sequential execution.

http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/mit...

Lisp I programmer's manual from 1st March 1960.

It had PROG -> sequential execution. chapter 4.5

It had floating point numbers -> chapter 4.4.

It had side-effects -> SET, SETQ. chapter 4.5


>The language LISP I in 1960 had numbers, side-effects and sequential execution.

Yes, true. But in this context Paul Graham was talking about the language defined in the 1960 paper below and not LISP I.

"Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I"

http://www-formal.stanford.edu/jmc/recursive.html


Really? That has numbers, too. There are several examples with numbers in the paper.

In the paper McCarthy mentions also:

'6. A ``program feature'' allows programs containing assignment and go to statements in the style of ALGOL.'

'7. Computation with floating point numbers is possible in the system'

Basically the paper is more a collections of ideas around various ways to describe parts of LISP. The actual LISP language is described somewhere else. See the LISP I Programmer's manual linked earlier, which gives a complete overview of the state of the LISP language in 1960.


>In the paper McCarthy mentions also: >'6. A ``program feature'' allows programs containing assignment and go to statements in the style of ALGOL.' >'7. Computation with floating point numbers is possible in the system'

This part is about the status of LISP I and not what Graham is referring to. Did you look at the article by Graham?

http://www.paulgraham.com/rootsoflisp.html

He is talking about the core of LISP that he found in the 1960 paper that is pure.

>Basically the paper is more a collections of ideas around various ways to describe parts of LISP

There is clearly a gem in the paper that is viewed as a pure LISP.


Two of Graham's Seven Primitive Operators are car and cdr. These names come from the IBM 704 implementation; they could not have existed in the theory which came before it. Since those names were used, this casts a suspicion that the theory didn't have these functions, and therefore wasn't about Lisp.

What Graham's Paper is describing is a back formation abstracted from what they got running on that IBM 704.

I doubt that the theory had quote, either, which is the gateway to "code is data". Since code-is-data is the core of Lisp, a theory without code-is-data (like the vapid nonsense that is Lambda Calculus) isn't about Lisp.


>Two of Graham's Seven Primitive Operators are car and cdr. These names come from the IBM 704 implementation;

Since the 1960 paper is after the LISP I manual and Graham's article is based on that paper the actual wordings are clearly influenced by LISP1.

>What Graham's Paper is describing is a back formation abstracted from what they got running on that IBM 704.

We viewed it as the core of LISP.

>Since code-is-data is the core of Lisp

Yes an another important part of LISP.


I think the argument comes because your initial statement was "The original LISP is pure functional," which isn't true. McCarthy's original idea of Lisp was not purely functional and the original Lisp implementation was not purely functional. I think that it is true to say that the first real description of a purely functional language came up in the context of work on Lisp, but what you and Paul Graham seem to be doing is saying that that pure Lisp is the real Lisp and what was called Lisp before that (in theory and implementation) was still just a lead-up to his "discovery" of Lisp.


>I think the argument comes because your initial statement was "The original LISP is pure functional," which isn't true.

Since LISP I is the real first implementation, I don't mean the original LISP in the sense of the first LISP, but rather "a core of LISP defined in the original paper". I called that the original LISP. I have explained this view many times so far.

>McCarthy's original idea of Lisp was not purely functional

At least McCarthy had some pureness in his mind for LISP and it is not black or white argument.

>the original Lisp implementation was not purely functional.

True.

> but what you and Paul Graham seem to be doing is saying that that pure Lisp is the real Lisp and what was called Lisp before that (in theory and implementation)

This is not my intention.


> At least McCarthy had some pureness in his mind for LISP and it is not black or white argument.

In his 1958 paper describing what would become Lisp, literally the first example of the use of car he gives is destructively modifying a cons, ie, RPLACA. In his own words, which I quoted earlier and you didn't respond to: "Compared to the mathematically elegant recursive function definition features, the ``program feature'' looks like a hasty afterthought. This is not quite correct; the idea of having sequential programs in LISP antedates that of having recursive function definition."

It seems black and white to me.

> > but what you and Paul Graham seem to be doing is saying that that pure Lisp is the real Lisp and what was called Lisp before that (in theory and implementation)

> This is not my intention.

Could you explain how your intention differs? McCarthy's original conception of Lisp was not purely functional (according to McCarthy himself as well as the historical evidence), and the original implementation was not purely functional, so how would the purely functional subset described in a later paper be "the original LISP" if you aren't denying the earlier work?


http://jmc.stanford.edu/articles/lisp/lisp.pdf

"One mathematical consideration that influenced LISP was to express programs as applicative expressions built up from variables and constants using functions. I considered it important to make these expressions obey the usual mathematical laws allowing replacement of expressions by expressions giving the same value. The motive was to allow proofs of properties of programs using ordinary mathematical methods. This is only possible to the extent that side-effects can be avoided. Unfortunately, side-effects are often a great convenience when computational efficiency is important, and “functions” with side-effects are present in LISP."

Seems not black or white to me. This paper is also written by McCarthy. He had pureness in his mind, but the real implementation had side-effects for practical reasons.

>McCarthy's original conception of Lisp was not purely functional (according to McCarthy himself as well as the historical evidence)

Again not black or white (according to McCarthy himself). The pure language is written in the original LISP paper and Graham and I viewed it as the core and it also showed the pureness of LISP.

>so how would the purely functional subset described in a later paper be "the original LISP" if you aren't denying the earlier work?

Again the definition. I have already explained what I meant with "the original LISP".


> > so how would the purely functional subset described in a later paper be "the original LISP" if you aren't denying the earlier work?

> Again the definition. I have already explained what I meant with "the original LISP".

I didn't ask what you meant by it, I asked how using that definition is different from claiming that McCarthy's earlier work on Lisp wasn't Lisp. In the same paper you just quoted, McCarthy says that Lisp was planned to have sequential programs before it was planned to have recursive functions; the part you quoted does not say that destructive functions were added later or that he ever planned not to have them. In the 1958 paper, he was already describing a language with mutable objects.


>McCarthy's earlier work on Lisp wasn't Lisp.

I didn't say this. I have already explained about the difference between the first LISP implementation and the core language written in the 1960 paper. There is no one true definition of LISP and I have already talked about this. People have different views of what LISP is.

You said black and white and it is not true from the paper I have shown.

>In the 1958 paper, he was already describing a language with mutable objects.

I am not talking about the 1958 paper. I am not also talking about which idea is first or not. Since it is not written clearly in the papers shown so far which idea is first, but I have showed that it is not black or white. Graham and my claim is based on the so called "original LISP paper" in 1960 and the pure version of LISP is written in it.

You and I have different views of LISP and that is OK. But please don't force your view to us, since there is no one true definition or interpretation of LISP.


Herbert Stoyan researched about the early history of Lisp and wrote books about that.

https://github.com/papers-we-love/papers-we-love/blob/master...

He says:

> LISP is understood as the model of a functional programming language today. There are people who believe that there once was a clean "pure" language design in the functional direction which was comprised by AI-programmers in search of efficiency. This view does not take into account, that around the end of the fifties, nobody, including McCarthy himself, seriously based his programming on the concept of mathematical function. It is quite certain that McCarthy for a long time associated programming with the design of stepwise executed "algorithms".

> On the other side, it was McCarthy who, as the first, seemed to have developed the idea of using funtional terms (in the form of "function calls" or "subroutine calls") for every partial step of a program. This idea emerged more as a stylistic decision, proved to be sound and became the basis for a proper way of programming - functional progamming (or, as I prefer to call it, function-oriented programming). We should mention here that McCarthy at the same time conceived the idea of logic-oriented programming, that is, the idea of using logical formulae to express goals that a program should try to establish and of using the prover as programming language interpreter. To come back to functional programming, it is an important fact that McCarthy as mathematician was familiar with some formal mathematical languages but did not have a deep, intimate understanding of all their details. McCarthy himself has stressed this fact (23). His aim was to use the mathematical formalismus as languages and not as calculi. This is the root of the historical fact that he never took the Lambda-Calculus conversion rules as a sound basis for LISP implementation. We have to bear this in mind if we follow now the sequence of events that led to LISP. It is due to McCarthy's work that functional programming is a usable way of programming today. The main practice of this programming style, done with LISP, still shows his personal mark.


> >McCarthy's earlier work on Lisp wasn't Lisp.

> I didn't say this.

Again, I was asking how what you did say was different from it. Your answer seems to just be that your definition of Lisp means the subset described in the 1960 paper, and doesn't include the original implementation or McCarthy's earlier writing on the subject.

> You said black and white and it is not true from the paper I have shown.

The paper you quoted said that Lisp was originally conceived as an impure language (the part I quoted) and that that was unfortunate, but true (the part you quoted).

> I have already explained about the difference between the first LISP implementation and the core language written in the 1960 paper. [...] I am not talking about the 1958 paper.

So you meant to say that the 1960 paper was the first description of a pure language. Calling the 1960 paper's subset of Lisp "the original LISP" and disregarding the already-existing implemented Lisp system which the paper acknowledges, as well as McCarthy's previous writing on the subject, is misleading at best.

> I am not also talking about which idea is first or not.

Then we have different definitions of "original," too.


That's not THE core of Lisp. It's a comstruction of a pure subset variant of Lisp. The actual LISP wasn't pure. Not before this particular paper and not after.


>It's a comstruction of a pure subset variant of Lisp.

We viewed it as the core of LISP and this is just one view of LISP.

>The actual LISP wasn't pure. Not before this particular paper and not after.

LISP I is not pure and I agree.


What are car and cdr called in the pure theory, and why didn't they just stick with those names?


They are in the Lisp 1 Programmer's Manual, also dated 1960.

The white paper doesn't reproduce the entire reference manual; what are the odds?


I'm not talking about the implementation of LISP 1 by Steve Russell, but the original idea of LISP invented by John McCarthy that shows its purity, and that is before the implementation by Russell.


The paper you cited is dated 1960 and bears McCarthy's name.

The Lisp 1 Programmer's Manual is dated 1960 and ... bears McCarthy's name.

The paper you cited has a section titled The LISP Programming System which says:

"The LISP programming system is a system for using the IBM 704 computer to compute with symbolic information in the form of S-expressions."

The Programmer's Manual's Preface begins:

"LISP 1 is a programming system for the IBM 704 for computing with symbolic expressions."

Looks like they are about exactly the same thing to me: an implementation for a specific computer (IBM 704), described in the same year by the same author, with an a nearly identical sentence in the intro.


John McCarthy is not the one who implemented LISP 1 in IBM 704, but it is Steve Russell. McCarthy invented the idea of LISP in 1958 https://www-cs.stanford.edu/memoriam/professor-john-mccarthy that is before the 1960 paper and the LISP 1 manual. In the 1960 paper, he showed that LISP can be implemented in just few primitives that showed its purity of LISP. Of course you can develop a non pure version of LISP which is more practical.


The original idea of McCarthy was to have a list processing language on the IBM 704.

http://jmc.stanford.edu/articles/lisp/lisp.pdf

Lisp was always as much as an idea as a real proramming language and both were developed together. Lisp was developed as a practical tool for AI research, especially for his AI research.


In the paper you shown

"One mathematical consideration that influenced LISP was to express programs as applicative expressions built up from variables and constants using functions. I considered it important to make these expressions obey the usual mathematical laws allowing replacement of expressions by expressions giving the same value. The motive was to allow proofs of properties of programs using ordinary mathematical methods. This is only possible to the extent that side-effects can be avoided. Unfortunately, side-effects are often a great convenience when computational efficiency is important, and “functions” with side-effects are present in LISP."

Reading above, in his original idea, he clearly had the idea of mathematical pureness for LISP, but for practical reasons the real implementation became one with side-effects.


You are right, the 1960 paper describes a language that is a pure functional language. I think it even was the first published pure functional language (pointers to earlier work welcome, of course).


Since you didn't say Common Lisp, i would suggest looking at racket: very powerful macro system with safety, support for static-type checking, contracts. Unlike common-lisp racket is mostly functional and has decent support for object-oriented programming too. Most importantly excellent documentation. Pretty much the best environment, i have seen academic people produce.


Also, DrRacket. While I generally prefer my emacs, "first learn emacs" is a pretty bitter pill to swallow for newcomers. Fortunately DrRacket solves that for both newcomers as well as experienced folk who just don't want to use emacs. Introducing folks to Racket seems to have a lower impedance threshold as a result.

DrRacket looks a little dated in its vanilla configuration, but the layout of the editor / REPL parts can be changed around a bit, the color schemes swapped out. There's even a paredit mode for DrRacket. Overall, if I were somehow coding more exclusively in Racket, I could easily see using and extending DrRacket rather than my current emacs.


Oh, DrRacket also dogfoods its own GUI library. Write high level Racket; get fully native UI on Mac/Windows/Linux(gtk).


The IDE is not very mature. For example if you use the dialog to search through files, the UI locks up while searching. Usability generally is low...


I haven't used it very deeply (again, emacs), but I guess the deficiencies haven't been obvious to me upon casual use.


I agree, it also needs a lot of memory. Unless i use some debugging facility of drracket, i just use emacs with racket-mode.


I am learning Common Lisp after using Clojure exclusively for a year.

Common Lisp may be old, but it is extremely powerful relative to Clojure IMO. Clojure startup times are awful, it takes a very opinionated approach to programming (immutable data), its debugger is buggy, it produces unsightly error messages.

Sure, these problems may be fixed, but for me, I want a powerful tool that I can use now.

I've tried several new hot languages at the time (Rust, Dart, Clojure, Go).

I have come to a point in my career where I want to stick to highly complex, but slightly dusty artifacts defined by a standard( C++ & ANSI Common Lisp).

The SBCL implementation of common lisp does not give me all of the headaches of Clojure. I also don't have to restart the repl to load libs.

On using another dynamic language that isn't a lisp... Forget about it.

...Python maybe for machine learning, but I will probably just wrap cafe in CL or something.

PS. I am 25. Seems relevant to this discussion.


>I have come to a point in my career where I want to stick to highly complex, but slightly dusty artifacts defined by a standard( C++ & ANSI Common Lisp).... . . >PS. I am 25. Seems relevant to this discussion.

This made me LOL. I figured you were 50 or older based on the top of your post. You are wise to pick languages that are proven and "just work " though. I would say Go, while young, is incredibly stable and predictable.


> Can somebody comment on the status of Lisp in 2017?

Sadly the only Lisp environments that resemble in any way the old Lisp Machine or Xerox PARC ones are comercial.

Emacs is kind of ok with SLIME, but it still isn't the same as using Allegro Common Lisp[0] or LispWorks [1].

[0] - https://franz.com/products/allegro-common-lisp/

[1] - http://www.lispworks.com/


vim + slimv is a pretty good combo, if you're used to vim. Also, although it's not widely used, Atom seems to support slime:

Just grab the latest release from https://github.com/slime/slime/releases Install atom-slime and sbcl (something like brew install sbcl on osx) Point atom to the directory you extracted slime to and then hit packages > slime > start


The whole point of my comment was " Lisp environments that resemble in any way the old Lisp Machine or Xerox PARC ones".


These development environments just were IDEs written in Lisp, otherwise they most don't have to do much with those Lisp Machine IDEs.

Most Common Lisp IDEs had a collection of these tools: Editor, Listener, Inspector, Debugger, Stepper, Preferences, ... Additionally there were various browsers, an interface builder, profiler, ...

The Lisp Machine IDEs had most of these tools, too. But they weren't only styled for development, but also for general use. Thus a Lisp Listener was not only a REPL, but also a general command line interface to interact with the machine. They were also more oriented towards group work and had additional features like versioned file systems, software versioning systems, databases, support for multiple programming languages (like C, Pascal, Ada, Fortran, Prolog, ...), source repositories, ...

Over the years (80s onwards) a multitude of these IDEs on Workstations and PCs were developed. CMUCL comes with one for X11 (debugger, editor, ...), Macintosh Common Lisp, ExperLisp, Procyon Common Lisp had one for Macs and Windows, Golden Common Lisp had one for Windows, Corman Lisp for Windows, SPE from SUN, Lucid CL had one (called XLT, their editor was called Helix), Star Sapphire Common LISP had one, Clozure CL has one for macOS (which one can run on a current Mac), ...

Then there were always IDEs based on GNU Emacs or XEmacs. Ilisp was once popular, Allegro CL has ELI, SLIME currently is the most popular with Sly as a fork. This is not so bad, since there are decent versions of GNU Emacs for Windows, Unix/GTk+ and macOS.

Of the commercial ones only Allegro CL (IDE for Windows and Unix/GTk+) and LispWorks (IDE Windows, Unix/Gtk+, deprecated for Unix/Motif, macOS) survived with regular releases.

Of the non-commercial ones SLIME/GNU Emacs is the most popular and it is also used by some users of Allegro CL and LispWorks. McCLIM lingers in the background with a collection of tools which would make an IDE, but it lacks one or more better GUI backends.

There are also a bunch of other ways to use Common Lisp with other editors (vim, atom, ...).

Now 'darkmatter' is another one. Let's see what people think from using it...


Very nice overview, always a pleasure to learn from your real life Lisp experience in the original Lisp environments.

I got mine from endless hours reading the manuals, books and papers from those days, so I sometimes miss a few details.


> McCLIM lingers in the background with a collection of tools which would make an IDE, but it lacks one or more better GUI backends.

Worth noting that McCLIM is again under active open-source development, so there are hopes for a decent GUI backend here.


The Lisp Works page is kind of cute, but in bad way as far as marketing goes, at least in my opinion.

The IDE screenshots for Windows show off Windows XP.


I don't know how the actual UI currently looks like, but even if it still looks like Windows XP, the IDE and Common Lisp compiler are still quite ahead compared with what Emacs + SLIME are capable of, specially in GUI related Lisp development workflows.

Maybe they could improve their marketing message, but I doubt most wannabe Common Lisp developers are willing to pay for comercial tools, with enterprise prices, even if they had the best marketing of all times.


Also, unless you are heavily invested in CL, most people actually can't afford to pay $600 on a compiler license per year.


Lispworks has a free "Personal Edition". It's good enough to get through something like Practical Common Lisp and get a feeling for writing lisp, however since it uses an old version of ASDF, it's a bit difficult to use the "modern" quicklisp ecosystem.


The LispWorks prices are not per year.


Their pricing pages are also a disaster. I had to drill down a few pages deep to find these epic tables: http://www.lispworks.com/buy/prices-1c.html which presumably could be distilled into 32-bit/64-bit categories plus a maintenance add-on.


> The IDE screenshots for Windows show off Windows XP.

The IDE is based on their native GUI backend. Thus it picks up much of the looks of the current OS automatically (windows, buttons, dialogs, ...).


The point being made is that they apparently haven't updated their screenshots in over 10 years, making their product seem dated- a pretty big marketing fail.


LispWorks has been developed from 1987 onwards since 30 years. They can't update their marketing material every year just because someone changed the GUI look. ;-)

Though I'll propose it to them for the next LispWorks release...


A major Windows release is kind of a big thing in the desktop world.

Missing 5 Windows releases is just sloppy: Vista, 7, 8/8.1, 10.

I'm not saying it's a bad product, just that first impressions matter. There's a reason this site is full of discussions about conversions and funnels.

As a side note, Windows is also 30+ years old. Hardly new tech these days ;)


> A major Windows release is kind of a big thing in the desktop world.

I can bet that LispWorks' customers (big companies and experienced lisp users) are largely away from the mainstream desktop world, and wouldn't care too much on how the current Windows UI looks like.


Software age is a non-sequitur- there are plenty of active multi-decade projects that can update their marketing material once in ten years. Nobody suggested they do so every year, even though it takes what like an hour? For a product costing $thousands there is not really an excuse.


I wouldn't recommend Slime to ANYONE because the developers do not care about security. The issue[0] of a gaping security hole has been open for going on two years.


Did you forget the link?


They are talking about this issue

https://github.com/slime/slime/issues/286

If it has being left unaddressed because no one thinks it is enough of a problem. That is how free software works


That actually scares me enough to disable Swank on my laptop. Actually, to disable all localhost services that could by any stretch of the imagination execute code.

Tl;dr: web sites can send requests to localhost TCP sockets despite origin restrictions using a trick called DNS rebinding.


Yes, it certainly a gaping security hope. Yet I cant bring myself to submit a patch


A very tough question. We would need to know more of your background. Haskell is purely functional, with anything impure cast as a monad I think. OCaml is nice and let's you use OO as well. F# is basically OCaml on .NET. Common Lisp is multi-paradigm (imperative, functional, OO, even logic)...there are several others as well. Clojure is a lisp on the JVM that tries to be just functional, but allows you to leverage Java libraries when needed. Clojure has a lot of good things going for it, but I understand that the debugging experience is inferior to Common Lisp as you mainly get Java stack traces. So do you develop on Mac, Linux, or Windows? Do you already know Java? Do you need multicore parallel programming? How much time do you have to invest?


As far as tooling goes, it's also much less of a pain to set up than it used to be. Quicklisp and Roswell[0] make installing and maintaining systems much easier -- together they're kind of like pyenv/pip for Python, or Opam for Ocaml, or what have you.

[0]: https://github.com/roswell/roswell


Professional and open source implementations of Common Lisp are stable but nonetheless under active development.

Many hobbyists and professionals use Lisp to solve their problems and make money.

IDEs are in a sorry state. If you're an Emacs user, you'll be happy. Otherwise, unless you spend hundreds of dollars for a professional IDE, you won't have much. Editing Lisp requires a good IDE.


>Many hobbyists and professionals use Lisp to solve their problems and make money.

Is there anywhere that one can read about such cases? Would be interesting to read about both how well they are doing and what sort of apps they use Lisp for making.


Any recommendations for a Lisp IDE outside of Emacs?

Also, aren't there any other OSS or free Lisp IDEs outside of Emacs? Or are they all crap?


The wiki is a great resource: http://www.cliki.net/Development

Really for a good experience you just need something with Swank support and ability to highlight matching parens. Eclipse would even work, though I haven't tried any of the plugins for it. IDE features like introspecting values, breakpoints, tracing, profiling, stepping, recompiling are all part of the Common Lisp standard so you'll get them for free just by running the Lisp REPL in a terminal. What you use on top of that is really just making it more convenient to interact with the Lisp environment than typing everything in by hand. I like slimv with its auto-paren-infer stuff turned off (matching and rainbow parens are fine for me) but I've also just used a tool that uses two screen sessions to send data back and forth without using Swank (or even Lisp, I use it sometimes for Python but that's trickier because I can't just send a class to (re)define if I have newlines between methods and I can't casually change my namespace).


I wonder why there aren't more good IDEs for Lisp. Is it just because Emacs is already there? It seems like it would actually be easier to create an IDE for Lisp than for other languages. Parenthesis editing should be very simple, as should sending definitions to the running system... Is it more complicated than I think?


Yes, we have Vim and Atom plugins: https://github.com/CodyReichert/awesome-cl#text-editor-resou...

And [Portacle](https://shinmera.github.io/portacle/) is an Emacs shipped with SBCL, Slime and Git in a portable and multiplatform way, so it's straightforward to begin with.


Pretty much everyone I know that does lisp uses Emacs + SLIME.


:(


Also, from a _very_ quick test, it looks like Atom has ok support for SLIME.

Just grab the latest release from https://github.com/slime/slime/releases Install atom-slime and sbcl (something like brew install sbcl on osx) Point atom to the directory you extracted slime to and then hit packages > slime > start


vim + slimv is a pretty good combo, if you're used to vim. Also, although it won't give you the "full lisp experience", using something like parinfer or paredit in Atom will make editing lisp more pleasant.


The stability of something like SBCL feels nice after a year in Clojure.


just look at slimv


There are many Lisps, they are not always like MLy languages like Haskell. Practical Common Lisp -> On Lisp -> Let Over Lambda with Keene and AMOP on the side are good for Common Lisp. Clojure has good resources too, Professional Clojure, Learning ClojureScript. For Haskell, CIS194 online from UPenn is good. I would suggest trying everything out and not being limited by what others think and the limits on what they can communicate to you with language. Where we are going we need your full expression.


Lisp is not used as a purely functional language. It has the tools to write functional programs, but most lisp code is procedural.


There was a good amount of discussion about what Common Lisp has to offer vs. other programming languages in the comments on this:

The Common Lisp Cookbook

https://news.ycombinator.com/item?id=14661239

262 points by macco 9 days ago | 184 comments

Not so much about CL vs. functional languages, but it gives a sense of the current scuttlebutt about CL.


    Is Lisp a good choice (for a functional language)?
If you want to program in stricly functional and only functional style, being totally forbidden of incorporating side effects into your functions (except via Monads), and want to feel a sensation of "types are checked and enforced everywhere, thus I can sleep happy", then go try Haskell.

If you want to be free to do whatever you need to do, to apply the paradigm you need at every moment -- be it procedural, imperative, logic, aspect-oriented, object-oriented, functional... then Common Lisp is for you. If you need the full power because you know what you are doing, then Common Lisp is for you.

    Status of (Common) Lisp in 2017
- You can have a fully configured, ready to use, CL environment in under 5 minutes by downloading and executing Portacle. No configuration needed, it just runs and gives you Emacs, SLIME, Paredit, SBCL, Quicklisp and other nice tools.

- Free books and resources are available, for example "Practical Common Lisp"

- Package ("system") installation is damn easy with Quicklisp. Download package from the web, compile it and load it... with only one command: (quicklisp:quickload <package name>)

- There are libraries out there for anything you need: REST services, web frameworks (many), JSON, machine learning, math, anything really.

- There are many ANSI-compliant CL implementations out there, most of them free: SBCL, CLISP, Clozure CL, SICL, ABCL, LispWorks (commercial), Allegro CL (commercial)

- Interoperability with C is easy with CFFI (there are other ways as well)

etc etc. Lisp in 2017 is better than ever! - Interoperability with Java is easy with the ABCL implementation.


You might be interested in reading this state of the ecosystem for 2015: http://eudoxia.me/article/common-lisp-sotu-2015 I wouldn't expect things to look any worse since then (an interesting characteristic of Lisp is that unlike say JS materials which are a few years old are often obsolete, there are lots of excellent multi-decade-old Lisp references and code you can still use).


FWIW, I reached for CL to do some scripting and found using UIOP for filesystem tasks (as recommended here) intensely painful.


Good to know, I haven't used it. I haven't really done much with scripting in Lisp (I think I'm actually still within the first 10k written lines of it, for whatever that metric is worth) so for filesystem and OS tasks I haven't gone much beyond the standard and some sb-ext functions. I don't really have a need or desire to move from bash or python for scripting; it's the larger programs that make me wish I had Lisp around when I don't.


I've been exploring CL lately.

- IMO the documentation state is not great, but it's being worked on. (it's said to be non-existent for Haskell :p ) CL has many books to learn from (CL recipes of 2015 being the more interesting to me http://weitz.de/cl-recipes/), but the online documentation is not brilliant. Often the web page isn't attractive at all, not every project provides good documentation, the "official" websites are bad (cliki, others). It's being fixed by https://github.com/CodyReichert/awesome-cl, http://lisp-lang.org/, https://lispcookbook.github.io/cl-cookbook/, http://quickdocs.org/ and http://phoe.tymoon.eu/clus/doku.php

- one can feel the language is dating. It has IMO too many weird semantics: no map and filter but map which takes a second argument telling the type of the structure or mapcar and others, remove-if[-not], etc. Creating hash-tables is too verbose and not consistent, et. That all a lot more are fixed in CL21 http://cl21.org/ (its wiki https://github.com/cl21/cl21/wiki). CL21 also offers more functional-oriented stuff like shorter lambdas, lazy sequences, generic functions, or string interpolation, regexp literals, and more. It's a bit under-documented, but its wiki is ok.

- web dev in CL is another topic. I sugest https://stackoverflow.com/a/42838145/1506338 but what's doable now is very elegant.

- CL has a big ecosystem, we can use Emacs/Vim/Atom, Portacle is straightforward is portable and thus straightforward to use (https://shinmera.github.io/portacle/),…


I would definitely recommend looking at Clojure. It's one of the more widely used functional languages in the industry. There are lots of large companies such as Amazon, Walmart, and Boeing using it for mission critical stuff now.

The fact that it runs on the JVM and makes it easy to interop with existing Java code makes it practical to integrate in many organizations already using this stack.


Anyone know of a list or resource that has collected all the of this type of notebook IDE's? I know of a few but I'm sure there are more out there.


Did the author build a whole notebook environment just for lisp?

Can anyone comment on the benefits of this vs integrating a lisp kernel into jupyther notebook?

Personally I've been wanting to do the ProbMod [0] course, which uses a version of lisp called church, but been wishing for a notebook environment to complete the course in, so this looks very interesting!

[0] https://probmods.org/v1/


There are a couple dockerized jupyter and beaker kernels for WebPPL if you want a go at v2, but I had varied success with them.


This was also my question: why not just create a lisp kernel for jupyter?


Is anyone aware of a way to get notebook style Lisp inside Emacs? Along the lines of what EIN does for Python?

I really like the notebook format but I've yet to come across a browser window so good that I'm happy to give up an actual editor program for it.


As the sibling says, org-mode easily delivers here. In ways that makes standard notebook environments somewhat frustrating with their limitations.

Examples:

You can reference data in a table of your page.

You can access the "session" of a code block in a repl. Useful for putting credentials or other sensitive data in.

You can copy from in a result or a code block with the same ease.

Any tags you have setup will jump as expected. Same for completions and documentation.

Arguably, the way images are referenced externally is better for post processing.

Finally, being able to source control the document easily is huge. Json is a terrible format. :(


Thank you all. It took me a while to get back to this thread and see your replies, but I very much appreciate them.

I'm convinced that you just pushed my over the limit to finally start learning org-mode.

And the examples sound lovely.


Org-mode can be pretty good for that kind of thing with many languages.


With many languages per notebook.


Anyone have any idea on how to get this working with debian?


I made it install with the latest version of Roswell, which I installed with linuxbrew (see wiki) (which compiles quite a bit of dependencies). More precisely ros version 0.0.6 didn't install darkmatter.

But I get a stracktrace indeed, missing "libev.so" which we get with libev-dev.


What are you having trouble with?


> by cddadr

My TXR Lisp actually has that function. :)

Oops, I mean accessor.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: