Show HN: A notebook-style Common Lisp environment(github.com)
github.com
Show HN: A notebook-style Common Lisp environment
https://github.com/tamamu/darkmatter
114 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?
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.
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
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.
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!
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?
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.
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.
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.
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.
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."
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/
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
[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...
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.
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.
> 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.
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...
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
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.
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.
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
[deleted]
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?
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.
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.
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.
"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).
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?
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?
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.
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 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.
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.
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/
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
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...
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.
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.
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.
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.
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 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...
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 ;)
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.
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
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.
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
[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.
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.
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?
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).
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.
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.
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
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.
[deleted]
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.
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 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
- 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/),…
- 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.
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/
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.
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. :(
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.
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.
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.
My TXR Lisp actually has that function. :)
Oops, I mean accessor.