Top products from r/lisp

We found 40 product mentions on r/lisp. We ranked the 44 resulting products by number of redditors who mentioned them. Here are the top 20.

Next page

Top comments that mention products on r/lisp:

u/joinr · 12 pointsr/lisp

Some CL-specific resources:

  • The book Land of Lisp has some sections specifically on functional programming, and answers some of these questions. It goes into more detail on the philosophy and spirit of separating effects and organizing code, albeit for a limited example. Chapter 14 introduces it (in the context of CL), then implements the core of the game Dice of Doom in a functional style in chapter 15.

  • On Lisp discusses programming in the functional style early on in Ch2/3, (with an emphasis on bottom-up programming). I think Graham uses a functional style more-or-less throughout, except for performance optimizations or where the imperative imperative implementation is actually more desirable for clarity.

  • Peter Norvig similarly leverages a bit of a functional style throughout PAIP, and he has several remarks about leveraging higher order functions, recursion, and small, composeable functions throughout the text. FP isn't the focus, but it's discussed and present.

  • Practical Common Lisp has some brief mentions and examples in chapters 5 and 12.

    Non-CL:

  • SICP starts off with functional programming from the start. Although it's scheme, the ideas are similarly portable to CL. It's an excellent resource in general, regardless of language interest IMO.

  • There's a chapter in the free Clojure For the Brave and True that more-or-less covers the bases and builds a small game functionally. Due to its prevalence, you pretty much find articles/blogs/chapters on FP in every clojure resource. I found the ideas generally portable when revisiting CL (absent reliance on persistent structures with better performance profiles than lists and balanced binary trees).

  • Joy of Clojure Ch7 specifically focuses on a FP concepts and applies them to implement a functional version of A* search. They run through simple functions, function composition, partial function application, functions as data, higher order functions, pure functions / referential transparency, closures, recursive thinking, combining recursion with laziness, tail calls, trampolines, and continuation passing style.

    Others:

  • http://learnyouahaskell.com/chapters

    I flip back and forth between Clojure and CL periodically (CL is for hobbies, clojure is for work and hobbies), and have mucked with scheme and racket a bit (as well as decent mileage in F#, Haskell, and a little Ocaml from the static typed family). IME, you can definitely tell the difference between a language with support for FP strapped on after the fact, vs. one with it as a core design (preferably with mutable/imperative escape hatches). CL supports FP (closures/functions are values (e.g. lambda), there's a built-in library of non-destructive pure functions that typically operate on lists - or the non-extensible sequence class, and non-standard but general support for optimizing tail recursive functions into iterative ones enables pervasive use of recursion in lieu of iteration), but I think it's less of a default in the wild (not as unfriendly as Python is to FP though). Consequently, it's one paradigm of many that show up; I think there's likely as much if not more imperative/CLOS OOP stuff out there though. I think the alternate tact in clojure, scheme, and racket is to push FP as the default and optimize the language for that as the base case - with pragmatic alternative paradigm support based on the user's desire. Clojure takes it a step farther by introducing efficient functional data structures (based on HAMTs primarily, with less-used balanced binary trees for sorted maps and sets) so you can push significantly farther without dropping down to mutable/imperative stuff for performance reasons (as opposed to living and dying by the performance profiles of balanced binary trees for everything). You'll still find OOP and imperative support, replete with mutation and effects, but it's something to opt into.

    In the context of other FP langs, F# and Ocaml do this as well - they provide a pretty rigorous locked-down immutable approach with functional purity as the default, but they admit low-hanging means to bypass the purity should the programmer need to. Haskell kinda goes there but it's a bit more involved to tap into the mutable "escape hatches" by design.

    In the end, you can pretty much bring FP concepts into most any languages (e.g. write in a functional style), although it's harder to do so in languages that don't have functions/closures as a first class concept (to include passing them as values). Many functional languages have similar libraries and idioms for messing with persistent lists or lazy sequences as a basic idiom; that's good news since all those ideas and idioms or more or less portable directly to CL (and as mentioned here are likely extant libraries to try to bring these around in addition to the standard map,filter, reduce built-ins). For more focused FP examples and thinking, clojure, racket, and scheme are good bets (absent an unknown resource that exclusively focuses on FP in CL, which would seem ideal for your original query). I think dipping into the statically typed languages would also be edifying, since there are plenty of books and resources in that realm.
u/Xurinos · 2 pointsr/lisp

Ah, I begin to see why they consider you a troll.


> No, six.

Heheh. :) Now I know you are messing around.


> Really? Go on common-lisp.net and try proving your hypothesis.

Go to cliki.net, and try to prove yours first. In my entire experience with Lisp, I never used that older site. Even the ASDF system uses cliki.net. Oh, I knew about it, but I could not understand why anyone would want to use it when the same packages and much more are available at cliki.net.


> Macros are a shitty form of encapsulation.

This statement makes a lot of interesting assumptions. Macros are intended to be a form of encapsulation? Encapsulation is desirable in every language construct? Encapsulation is statistically linked to some form of success?

Tools can be misused in any fool's hand. Macros, when used to abstract (not their only use), can make code much easier to read or much harder to read. We can as easily cry about C pointers and Java's leaky garbage collection.


> I'm aware of that, because I have this:

Knowing names and knowing features/functions = two different things. You would not have made the ignorant statement about Java if you understood MOP. MOP is not only used in Lisp; it would help your knowledge a lot to research it. Do you have this book? -- http://www.amazon.com/The-Metaobject-Protocol-Gregor-Kiczales/dp/0262610744


> What a bloated elegant language.

Show me your objective measures of "bloated" and "elegant". Walk the walk. Measuring number of pages is as useless as measuring lines of code.


Edit: Ah, ninja-editing. I must have struck a chord.

> Great, that's really useful to me.

I could say that about any random library I see anywhere. I tend to start with a problem and then work to solve it, grabbing what libraries are useful for it. I have noticed that rarely does armchair theorizing actually help me (or others) understand anything.

In truth, there are a great many useful packages in the Lisp ecosystem. Here is a nice list of them: http://www.cliki.net/Current%20recommended%20libraries

And better yet, you may want to consider installing QuickLisp and seeing what packages it supports. Inactive and outdated things are actively removed from its list.

u/death · 3 pointsr/lisp

I've not yet read this page carefully, but I would like to say a few words.

I think it is a great example, and I wish there were more pages like this. The program's design and implementation is not perfect, but it's certainly not bad. The author also says that these are "live sources", i.e. it is not fixed code.

With regards to prefixing generic function names with class names: I do not mind it if the name is of a protocol class. In fact, that is my usual convention.

It seems the author did attempt to think about protocols. Certainly, there's room for improvement, but it's not a bad start. In this case, where I have a small program already written, I would try to factor the code a bit before coming up with protocols.

For example, take the function MAKE-EXPLOSION. It may not be terrible, but I think it's too ambitious: it groups several functions into a function. The use of WITH-ACCESSORS is a symptom of such ambitions. Here's a quick attempt at factoring it.

You can see that the functions are very simple. Several of these functions are quite general utility functions. Only EXPLODE is side-effecting (ignoring effecting of random state), the rest can be tested very easily in the REPL without much context. They also make it easy to think up Functional Protocols, a concept described in The Art of the Metaobject Protocol, with some consideration for the parameters and points of extension.

u/Thedabit · 18 pointsr/lisp

Some context, I've been living in this house for about 3 years now, my girlfriend and i moved in to take care of the owner of the house. Turns out that he was a big lisp / scheme hacker back in the 80s-90s and had developed a lot of cutting edge tech in his hay day. Anyway, these books have been hiding in his library downstairs...

It was like finding a bunch of hidden magical scrolls of lost knowledge :)

edit: I will compile a list of the books later. I'm out doing 4th of July things.

update: List of books

  • Lisp: Style and Design by Molly M. Miller and Eric Benson
    ISBN: 1-55558-044-0

  • Common Lisp The Language Second Edition by Guy L. Steele
    ISBN: 1-55558-042-4

  • The Little LISPer Trade Edition by Daniel P. Friedman and Matthias Felleisen
    ISBN: 0-262-56038-0

  • Common LISPcraft by Robert Wilensky
    ISBN: 0-393-95544-3

  • Object-Oriented Programming in Common Lisp by Sonya E. Keene
    ISBN: 0-201-17589-4

  • Structure and Interpretation of Computer Programs by Harold Abelson, Gerald Jay Sussman w/Julie Sussman
    ISBN: 0-07-000-422-6

  • ANSI Common Lisp by Paul Graham
    ISBN: 0-13-370875-6

  • Programming Paradigms in LISP by Rajeev Sangal
    ISBN: 0-07-054666-5

  • The Art of the Metaobject Protocol by Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow
    ISBN: 0-262-11158-6

  • Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp by Peter Norvig
    ISBN: 1-55860-191-0

  • Practical Common Lisp by Peter Seibel
    ISBN: 1-59059-239-5

  • Common Lisp The Language by Guy L. Steele
    ISBN: 0-932376-41-X

  • Anatomy of Lisp by John Allen
    ISBN: 0-07-001115-X

  • Lisp Objects, and Symbolic Programming by Robert R. Kessler
    ISBN: 0-673-39773-4

  • Performance and Evaluation of Lisp Systems by Richard P. Gabriel
    ISBN: 0-262-07093-6

  • A Programmer's Guide to Common Lisp by Deborah G. Tatar
    ISBN: 0-932376-87-8

  • Understanding CLOS The Common Lisp Object System by Jo A. Lawless and Molly M. Miller
    ISBN: 0-13-717232-X

  • The Common Lisp Companion by Tim D. Koschmann
    ISBN: 0-417-50308-8

  • Symbolic Computing with Lisp and Prolog by Robert A. Mueller and Rex L. Page
    ISBN: 0-471-60771-1

  • Scheme and the Art of Programming by George Springer and Daniel P. Friedman
    ISBN: 0-262-19288-8

  • Programming In Scheme by Michael Eisenberg
    ISBN: 0-262-55017-2

  • The Schematics of Computation by Vincent S. Manis and James J. Little
    ISBN: 0-13-834284-9

  • The Joy of Clojure by Michael Fogus and Chris Houser
    ISBN: 1-935182-64-1

  • Clojure For The Brave and True by Daniel Higginbotham
    ISBN: 978-1-59327-591-4



u/unknownmat · 3 pointsr/lisp

That sounds like a reasonable plan. The choice of Lua or Cg depends on the type of programming you plan to do - it sounds like you might be interested in gaming. Personally, I would recommend Haskell ahead of Lisp as a vehicle for learning to be a better programmer. I think Python is close enough to Lisp that learning Lisp-proper won't buy you much.

I actually wrote a huge edit to the above post. Unfortunately, Reddit seems to have hiccuped, and it got lost. Since I took the time to write it, I'll post it below...

-----------------------------

Wow, after reading the responses in this forum, I really worry that you're being lead astray.

Please realize that I like Lisp. It's a wonderfully fun language, and I highly recommend that you learn it eventually. That said, there are several problems with learning it as your first language. In no particular order:

  • Learning "Lisp" really means understanding the concept of Lisp. IMO, this is something that is hard to appreciate until you've got some experience under your belt. I suggest that you pick it up after your compilers class.

  • Supporting the above point - look at the Amazon.com reviews of SICP - probably my favorite programming book of all time. It's highly skewed to 1's and 5's. Typically, beginners who pick it up hate it because it fails to answer the question "How do I use this language to accomplish X" for any real-world value of X.

  • Also note that in this forum alone I see 3 Lisps just casually mentioned - Common Lisp, Scheme, and Clojure - these are all quite different from each other. Just choosing a particular implementation and getting a development environment setup is not trivial.

  • Paul Graham once put Lisp at the top of the "language power" spectrum. However, IMO, Lisp is merely the "logical conclusion" of one particular family of languages (dynamically typed, introspective). There are myriad other paradigms out there - and personally I find Haskell to be more interesting and powerful than Lisp.

  • Also, Python is in the same family of languages as Lisp, is almost as powerful, is much cleaner and more consistent than Common Lisp, and is much easier to accomplish just about any real-world task owing to it's incredibly large set of libraries.

    Anyway, just wanted to give a different perspective. I don't wish to discourage you from learning Lisp, but I really do not think that it is a good first language.
u/charles__l · 11 pointsr/lisp

Lisp is like magic - it's the programmable programming language - if you learn it, everything else kind of pales in comparison :P

One fascinating aspect of lisp is that it's based on lambda calculus, which is basically a cleaner alternative to Turing machines (Turing machines are basically a mathematical way to describe computable problems). After learning about lambda calculus, Turing machines looked like a hack to me. A decent non-mathematical guide I found introducing them was this: http://palmstroem.blogspot.com/2012/05/lambda-calculus-for-absolute-dummies.html

Even though lisp allows for a lot of functional programming, it's not purely functional, and can be used to write object oriented code, or anything else really.

The books I'd recommend to learning it are:

  • The Little Schemer - a lovely, beginner friendly book that introduces Lisp and computation in a rather unique way.
  • Structure and Interpretation of Computer Programs - this is the book that was used to teach a bunch of programming classes at MIT, and is a classic text for computer science. Despite its advanced topics, it's still rather approachable, especially if you have a decent amount of programming background.
u/ddp · 1 pointr/lisp

If you're on OS X, you should also check out Clozure, not that SBCL isn't a fine choice. But Clozure has a functional Objective-C bridge that let's you write native applications on OS X. Both have a vastly superior debugging environment running under SLIME in emacs. Chicken debugging is unfortunately not much fun in comparison. That aside, Chicken's egg repository is a treasure trove and it's trivial to install and use them. The same cannot be said for ASDF[-INSTALL]. Depending on what Lisp libraries you're trying to install, you can easily end up in a mire of abandoned software. And while Cliki makes it appear like there's a lot of choice, I find that choice somewhat misleading: there's often 13 different libraries to wade through but only one or two that are still being maintained, if you're lucky. It takes a lot of time to vet the dependencies. On the other hand, I've found the quality of Chicken eggs to be much higher on average. This is not meant in any way to disparage any of the Lisp libraries, it's just that so many of them are no longer being actively developed and since so much of what we write these days depends on evolving Internet standards, having stale libraries is a real impediment. Chicken is a labor of love and it shows. It's also embeddable in C which is just insanely useful if you ever were to need it.

There are significantly worse things in life than working your way through The Little Schemer or SICP. Stick with Scheme though if you're going to be doing either. While the exercises can be expressed in Lisp, they're no fun to write in Lisp for reasons that are beyond the scope of a reddit comment. Once you know either you can switch back and forth fairly easily, though porting code between them, not so much.

u/smallfishbigpond · 2 pointsr/lisp

On Linux I recommend grabbing the latest SBCL. If you really need to stay on Windows, then CLISP is fine.

You can edit code in any text editor, so simply choose your favorite one on any platform. You will find most of the main CL nerds use emacs and SLIME as their "IDE".

As for books, there are no good books on Lisp. I'm serious, every last one of them sucks ass out loud. But here is a list, taken in order from beginner level (that's you) to CHICK MAGNET (that's me).

u/WarWeasle · 2 pointsr/lisp

After you have read Practical Common Lisp and SICP I suggest The Art of the Metaobject Protocol then Paradigms of Artificial Intelligence Programming.

If you make it through those, you will be very well prepared for solving industrial problems with Lisp.

u/Mark_Tarver · 2 pointsr/lisp

I'm not much interested in perceptions, more in realities. I've never bothered too much about what people think unless there is really something behind it.

http://www.amazon.co.uk/What-Care-Other-People-Think/dp/0141030887

Anyway my post from Y-combinator

"The license was introduced before Shen was issued in September 2011 (the license came out in June) and for a year or so the only specification was Shendoc (now Shendoc 16). The understanding was that Shen was specified in that document and what was not covered by Shendoc was covered by 'Functional Programming in Qi'. Later a hurriedly introduced text 'The Book of Shen (first edition)' (TBoS) was produced to fill a gap (2012) and this year (January 2014) a more thorough 2nd edition of TBoS (> 400 pages) was published which fixes the language standard very thoroughly. This is currently the canonical standard.
You can find a link to that book on the Shen home page.

http://www.fast-print.net/bookshop/1506/the-book-of-shen-sec...

Shen is now very stable and has been for nearly two years. At my suggestion, I posited that it might be better to move the standard to a computable series of tests and this was floated to the 2011 committee that is responsible jointly for all the ports.

http://shenlanguage.org/2011committee.html

Such a change requires the unanimous consent of all the people involved and it seems we have this and a reworded simplified license.

The only obstacle is the work needed to put this test suite together. I've suggested that this suite might be assembled in Github, though for legal reasons the final version must be put in a publicly accessible but tamper-proof place.

Since the type-integrity given out by the system is not better than the strength of the kernel, we take kernel work very seriously. There is already a suite of 126 tests that I run every Shen port through and 2011 members echo these tests. But this informal test suite needs to be amped up to several hundred tests to approach what I consider to be an adequate test suite. It is very boring but important work. So far I have begun assembling all the programs in TBoS into this suite.

These license issues really only affect people who are deeply involved in kernel work and as far as application programmers are concerned, I doubt that it affects them much at all. As far as graphics, concurrency, FFI etc. and add-ons are concerned there are no restrictions. Likewise none on closed source work.

I'll also add that I'll be asking for volunteer contributions on the Shen news group to help assemble this test suite. So people who want to expedite us here can do so."

u/zck · 6 pointsr/lisp

Well, it's still in print. And it's worth getting.

u/DrStrngeluv · 4 pointsr/lisp

I second Practical Common Lisp, and may I recommend ANSI Common Lisp and The Little Schemer (I know its scheme, but when I did the exercises I did them in LISP).

u/suhcoR · 4 pointsr/lisp

Veeery old. In case you need more, see The Art of the Metaobject Protocol. There is even a Wikipedia entry: https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol with download links of parts of the book.

u/learnyouahaskell · 1 pointr/lisp

There is a book called "Looking at Lisp" with a similar idea on the cover:

http://www.amazon.com/gp/product/0201120801/

u/beeff · 2 pointsr/lisp

Check your sources, all of the listed techniques have been around in computer architectures for decades. cfr. Computer Architectures

u/TheSummarizer · 15 pointsr/lisp

My top suggestion: documentation of existing libraries.

I think the #1 biggest problem with the libraries out there is that no one has any earthly idea what the hell they are. Zach on Quicklisp has acknowledged this as a big-time failure.

The same situation existed for LaTeX for a long time: there were oodles of libraries available on CTAN, and no one had any idea what to was available, what to use, how they interacted, what was good, what was old, or even how everything worked together. So these libraries languished in obscurity.

Then The LaTeX Companion came out and revolutionized the LaTeX scene. And all this book was was a compendium description of existing libraries.

Lisp badly, desperately, needs a Lisp Companion.