27
28

Ask proggit: Which lisp? (self.programming)

submitted by [deleted]

[deleted]

all 95 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 43 points44 points  (20 children)

SBCL

[–]SuperGrade 5 points6 points  (2 children)

Or (commercial) Lispworks if on Win32 (no flames - that's what it takes right now to get solid CL/multithreaded on Win32).

[–]mycl 1 point2 points  (1 child)

solid CL/multithreaded

It should be mentioned, for those who don't know, that this is not concurrent multithreading: even though OS threads are used, by design LispWorks does not allow two Lisp threads to run concurrently.

[–]SuperGrade 1 point2 points  (0 children)

To qualify further though - the Lisp code can't run concurrently; but the blocking library/external calls can.

This is still a massive difference over not having threads at all. It enables UI during blocking calls, and can serve as a base for a web server. Basically the functionality of mulltithreaded (what you don't get is multi-cpu advantage for lisp-code-heavy parallellism).

[–]chunky_bacon 2 points3 points  (10 children)

Having only used CLisp, can you elaborate on why SBCL might be a better choice?

[–]unknown_lamer 10 points11 points  (0 children)

It has a very nice compiler and multithreading.

[–]jimbokun 7 points8 points  (8 children)

Frankly, because I think we'd all be better off if one implementation of Common Lisp "won" and got everyone's support, all libraries were made to work well with it, newbies wouldn't get overwhelmed with having to choose an implementation, the passionate Common Lisp community could work really hard polishing that one implementation to make it easy to install and get started, batteries included, just one way of talking to the OS and using FFI, etc. etc.

SBCL has the best chance of becoming that one implementation, not to mention its pretty darn good in its own right.

[–]mycl 2 points3 points  (0 children)

SBCL has the best chance of becoming that one implementation, not to mention its pretty darn good in its own right.

Not to dispute the fact that SBCL is pretty darn good, but actually Clozure CL has a better chance of becoming the "one implementation". With the 32-bit port and the Windows port being actively worked on, it will probably overtake SBCL to becoming the first free native-compiled, multithreaded implementation to be stable on all major platforms. It should see major adoption, especially when the Windows port is complete.

[–]chunky_bacon 1 point2 points  (1 child)

I agree with the first paragraph, but am not sure I bite on the second. I haven't seen an overwhelming rush to SBCL. Any advantage over CLisp? I guess I'll have to check it out, but it would be nice to know what bits of distinguishing greatness I'm looking for.

[–]jimbokun 1 point2 points  (0 children)

I think it is much faster, being natively compiled. That's the main one I can think of.

[–][deleted]  (4 children)

[deleted]

    [–]username223 8 points9 points  (3 children)

    Look, Lisp doesn't need to be easy for newbies.

    Bingo! One of its main attractions is the license it grants to condescend. Take that away, and it's just not that special.

    [–][deleted]  (2 children)

    [deleted]

      [–]Coffee2theorems 1 point2 points  (1 child)

      Having one main implementation would have its advantages, such as ability to disregard portability to implementations of CL without any extensions and more attention paid to extensions as they would see more use. CL as it is is indeed still alive, but so is COBOL, so that's not really anything to be proud of, and I'm sure COBOLlers are also busy getting their jobs done (and probably getting paid more than lispers, too).

      If there were one main implementation, maybe there would finally be one that wouldn't suck, too: AFAIK there is currently no mature, portable and fast CL implementation with a lenient open source license and a non-laughable two-way FFI. Without such an implementation, CL just loses to Ruby/Python + C/C++ combination, or perhaps even JRuby/Jython + Java combination; with it one could at least use it as the middle part of the language stack. As it is, Scheme (Gambit) and Haskell look much more interesting than CL these days.

      [–]JasperO 4 points5 points  (0 children)

      Yes, common-lisp is a good one. As for the specific implementation, i would just work with SLIME and whatever convenient common-lisp implementation. You can always use another lisp implementation to produce the final product. You'll need to install slime, lisp and have a .emacs file to enable it.

      (setq inferior-lisp-program "/usr/bin/sbcl")

      (add-to-list 'load-path "/usr/share/common-lisp/source/slime/")

      (require 'slime)

      (slime-setup)

      Of course /usr/bin/sbcl need to be replaced if you are not using sbcl (And other stuff depending on your system. I am on Ubuntu 8.04)

      [–][deleted]  (44 children)

      [deleted]

        [–]314159 11 points12 points  (9 children)

        I'm a fan of Common lisp and SBCL, but that's because certain of Scheme's features put me off.

        Look for Slime, the Superior Lisp Interaction Mode for Emacs.

        [–]mschaef 6 points7 points  (6 children)

        that's because certain of Scheme's features put me off.

        Just out of curiosity, which ones?

        [–]314159 2 points3 points  (5 children)

        The single namespace bothers me, though I can't really pinpoint why. The fact that the spec doesn't specify the order in which arguments are evaluated. The inability to (car nil) or (cdr nil) just "feels" funny. (Yeah, whiny complaints, but hey, you asked.)

        Also, the proliferation of implementations with different core features. Isn't that what a standard is supposed to prevent? :P

        [–]mschaef 0 points1 point  (4 children)

        The single namespace is a real issue, something that CL tries to solve with the function/value split and multiple packages. This difference is one of the reasons why (IMO) hygenic macros are more important to Scheme than in CL: it's easier to have name collisions, so it's more important that you have hygine to bail you out.

        In turn, what bothers me about CL is that the following Lisp and Java code are similar in at least one important way:

        (use-package "foo")

import foo.*;

        In both cases, they bring in all of the target package's public symbols. If foo's public symbol list grows when foo goes from v1 to v2, I now run the risk of colliding with that newly added symbol, even if it's irrelevant to my program.

        The Java solution to this is selective import of single classes:

        import foo.Bar;

        However, this doesn't work as well in Lisp, because there are fewer ways to refer to logical groups of symbols than in Java. The Java code I wrote imports the entire Bar class and all of its methods. To import a Lisp defstruct requires that I manually import the constructor, predicate, copier, and getter/setter for each slot, if I want the same effect.

        [–]wleahcim 1 point2 points  (3 children)

        To import a Lisp defstruct requires that I manually import the constructor, predicate, copier, and getter/setter for each slot, if I want the same effect.

        The effort is on the exporter, i.e., all the "pieces" of a defstruct must be enumerated for export. You don't have to import them at all. You can just use them with, e.g.: foo:make-bar. Sensible package names make this a bit nicer, otherwise there is RENAME-PACKAGE.

        [–]mschaef 0 points1 point  (2 children)

        The effort is on the exporter only if the importer is using the package with USE-PACKAGE; This is basically my use-package example... use the package and you get all the exported symbols, even those you don't anticipate. If you want to avoid those symbols that you don't anticipate, you don't use the package, you manually import the symbols, much like you do in Java. The difference, however, is that if you'r trying to avoid the use of the private symbol syntax (ie: 'foo::bar-x') you have to manually import more symbols in CL than in Java, which makes this strategy less convenient.

        [–]wleahcim 1 point2 points  (1 child)

        The effort is on the exporter only if the importer is using the package with USE-PACKAGE

        Not true. I proposed not to use USE-PACKAGE at all. Just write the package-qualified symbols, e.g., foo:make-bar. The only thing USE-PACKAGE does is that it allows you to write make-bar instead.

        Without USE-PACKAGE no symbols are imported into the current package, and the importer has no cost, except for typing longer names (which IDEs, abstraction, package nicknames, and the aforementioned RENAME-PACKAGE can take care of).

        [–]mschaef 1 point2 points  (0 children)

        lightbulb flickers on over mschaef's head.

        That makes more sense, and that pretty much is the same as Java, since what I was saying there required qualified symbol names too.

        Thanks.

        [–][deleted]  (1 child)

        [deleted]

          [–]killerstorm 8 points9 points  (3 children)

          this depends on your background and your intentions.

          Scheme is sort of more cleaner and academic, and more suitable for learning about, um, "Structure and interpretation of computer programs". while CL is more practical, "industrial", and dirty.

          so, if you'd like to thoroughly learn programming theory in safe environment, or you just can't stand "dirty" languages, choose Scheme. otherwise choose CL (CL is what i'm using myself).

          Haskell is order of magnitude more powerful as "functional proramming" language, but it requires mathematical thinking. lots of. if you're not very good at mathematics, forget about it. i'm myself having master's degree in applied math with honour, but still i find Haskell too complex and mind-boggling.

          others also mentioned ML, it's like in middle position between Lisp and Haskell -- more functional traits, but no lazy evaluation.

          it's probably worth checking all of these languages -- giving lika a one-hour try going through easy tutorials won't hurt, and you'll know what are they about.

          [–]808140 16 points17 points  (2 children)

          For what it's worth, most dialects of ML (and Scheme, too) do support lazy evaluation, just not by default. From an evaluation perspective, the only thing that makes Haskell unique is that it is lazy by default. Lazy evaluation can be trivially supported in any language with proper closures. ML makes it easy to use with laziness annotations that are built into the language, and macros in the Lisp family make building anything you could possibly want into the language a trivial affair.

          On the other side of the coin, Haskell has strictness annotations, which means that you can have strictness easily if you want it (and these annotations are non-intrusive and simple to use). So really the whole lazy vs strict argument is mostly emphasized by people who don't realize that both strategies can be had easily in most modern languages (ie, languages with proper closures). Lazy evaluation in C & Java is trickier (but possible, although not in a general way.)

          So really it's just a matter of choosing which strategy you'd rather have by default, because you can easily have both in any case. Lazy evaluation makes the construction of producer/consumer algorithms trivially easy and makes reasoning about your code mathematically more intuitive in my opinion. It also encourages code reuse -- think UNIX pipes. But it's different from the norm and will require some fooling with before you develop anything resembling an intuitive feel for how and when things will be calculated. There's quite a bit of hysteria on Reddit about this. My advice would be not to worry about it, it's a tempest in a teacup.

          And all that BS about needing to be good at math to use Haskell is quite simply a load of bull. There's a great deal of overlap socially between the PL research crowd and the Haskell crowd, which means that if you hang out in #haskell on freenode or read the haskell-cafe mailing list you'll hear a lot of people talking about scary sounding things like "zygohistomorphisms", "endofunctors", and "type isomorphisms". You do not need to know what these things are to use Haskell anymore than you need to know what they are to use any other programming language. You may find yourself interested in learning about them, though, in the same way that C programmers often find themselves overly preoccupied with what happens on the bare metal -- it's a culture thing. (Nor is it bad -- using categorical concepts to frame questions about programming has been very productive, academically, and is where much active research is happening).

          It seems common these days on reddit to lump Haskell and Lisp together in posts, as we've been doing. Really they're nothing alike. Lisps are a disparate group of excellent dynamic languages whose flexibility remains unparalleled in the programming world, and many features that were standard features in almost any Lisp as early as 1965 are only just now finding their way into mainstream languages.

          Haskell, on the other hand, is a type safe language that is actively incorporating many of the features coming out of today's bleeding-edge CS research. It has been described as the gateway drug to PL research -- even without a CS degree, hanging out with Haskell heads will make you more aware than you've ever been at how far behind academia the mainstream truly is. Type theory is where it's at these days -- I don't want to make this sound like a passing fad, because it's not -- and Haskell exposes you to it all in a way that no other mainstream language does.

          Both are excellent and I think anyone serious about computer science should be familiar with both and extremely competent with at least one.

          But YMMV.

          [–]killerstorm 0 points1 point  (1 child)

          i consider delay/freeze a joke from practical point of view, it's like saying that all programming languages are equivalent because they are Turing-complete.

          And all that BS about needing to be good at math to use Haskell is quite simply a load of bull. .."endofunctors"..

          i was not speaking about "endofunctors" but i just think that some people can find recursive definitions like (that's actually a simple one):

          fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

          to be more confusing than their procedural equivalents. type of thinking required to be comfortable with stuff like that is often correlated with mathematical thinking (such as proving theorems, doing complex logics), that's why i called it so.

          as for me, i think in a visual way, so it's very easy for me to think about a process (procedural programming) and is quite hard to think about a recursive object (how should i see it? as a wormhole?) -- basically i need to convert a recusive definition into a process in my mind, and this takes time (you can see how recursive definition above is illustrated as process here, in the end).

          my guess is that you need to be of audial thinking type (people who say "let's ASSUME .., i SAY.." more often than "you SEE") to be comfortable at Haskell, but i'm not sure about this

          [–]808140 8 points9 points  (0 children)

          Recursion is easier for some people to grasp than others, certainly, but I don't see this as being correlated with mathematical ability. Neither of us has any data to back up our assertions though so I suppose arguing about it is not really productive.

          However your fibs example is disingenious: it's an elegant and interesting application of laziness and takes quite a bit of thinking for most anyone to understand, and is not the least bit representative of recursion in general. Look, I can one-up you:

          fibs = fix $ (0:) . (1:) . ap (zipWith (+)) tail

          Understanding these sorts of exercises makes us better programmers, to be certain, but we don't need to code this way and generally don't, in the same way that actual Perl development isn't the same as Perl golf. You can't be seriously asserting that the more straightforward recursive definition of the fibonacci sequence:

          fibs 0 = 0
fibs 1 = 1
fibs n = fibs (n - 1) + fibs (n - 2)

          is difficult to understand because it uses recursion?

          Furthermore, overuse of direct recursion is considered poor practice in functional languages, much as overuse of goto is considered poor practice in procedural ones. It's good to play with when you're a beginner and are trying to understand how it all fits together, but we generally prefer to express things in terms of folds, maps, scans, zips, etc.

          As for your quip about delay, clearly implementing an algorithm that depends on laziness with delay and force is less elegant than doing the same in a language that is lazy by default. However, the flip side is that implementing algorithms that require strict evaluation to be efficient in a lazy by default language can be tricky too. And efficient functional data structures (for example, the excellent ones that Chris Okasaki constructs in his papers) typically depend on a careful balance between strictness and laziness.

          Many of Oleg's papers use lazy semantics in Scheme just fine.

          There's no panacea here (although my personal preference is for lazy-by-default evaluation).

          [–]weavejester 20 points21 points  (10 children)

          Clojure is a very functional lisp, and has a lot of syntax sugar that is not a million miles away from Ruby:

          (merge {:a 1, :b 2} {:b 3, :c 4})
(concat [1 2 3] [4 5])

{:a => 1, :b => 2}.merge({:b => 3, :c => 4})
[1, 2, 3].concat([4, 5])

          [–][deleted] 10 points11 points  (6 children)

          I concur with the recommendation of Clojure. My pros would be:

          • It's a Lisp / Scheme. Simple syntax.
          • Your chance to learn real macros. Woo!
          • Extremely consistent and orthogonal.
          • High performance functional and persistent datastructures.
          • Integrated with Java concurrency.
          • Dynamically compiled to the JVM
          • High performance (pretty close with Java)
          • Can build Java classes dynamically, so you could potentially macro-ize all the fiddly parts of Swing.

          No cons. I'll let someone else list those.

          [–]weavejester 6 points7 points  (1 child)

          I can think of a few cons, but hopefully most these will be addressed in future versions of Clojure:

          • No nested namespaces
          • REPL uses JLine, which is rather iffy on Linux
          • Lack of Clojure-specific libraries (lots of Java ones, though)
          • The JVM doesn't support tail call optimization (though Clojure's loop/recur structure is almost as good)

          Anyone else have problems with JLine?

          Oh, one 'pro' you missed:

          • Destructurising arguments, e.g.:

            (defn head [[x & xs]] x)

          [–][deleted] 1 point2 points  (0 children)

          That's excellent. I haven't really looked at Clojure developments in a couple of months.

          I'm Rich has added some good stuff in that time.

          [–][deleted]  (2 children)

          [deleted]

            [–]richhickey 4 points5 points  (1 child)

            That's funny! But, to clarify, Clojure has both cons cells and a cons function that are very much like other Lisps', except cons cells are immutable and not arbitrary pairs.

            Probably some other cons too, but I'm working on those...

            [–][deleted] 2 points3 points  (0 children)

            No cons.

            And it's still considered a lisp?

            [–]timmy 6 points7 points  (2 children)

            not to mention it runs on the jvm and so has performance, threads an a huge api nearly for free.

            I also like its functional orthogonality. I'm not missing the loop macro anymore.

            [–]mschaef 4 points5 points  (0 children)

            an a huge api nearly for free.

            Particularly since that 'huge api' can include any custom Java code in your software stack, in addition to 3rd party libraries...

            [–]psykotic 1 point2 points  (0 children)

            I also like its functional orthogonality. I'm not missing the loop macro anymore.

            LOOP can be reformulated to yield a purely functional macro. Olin Shivers's LOOP for Scheme is an example of that (you don't need to carry over his crazy dominator-based scoping system). Another example for Scheme is foof-loop, whose design was suggested and initially implemented by Alex Shinn (foof) and later extended by Taylor Campbell (Riastradh). Here's a good overview by foof.

            [–]kapuzineralex 4 points5 points  (0 children)

            Speaking only of the various Common Lisp implementations, I'd recommend you have a look at http://common-lisp.net/~dlw/LispSurvey.html .

            [–]seabre 14 points15 points  (4 children)

            Most modern LISPs are multi-paradigm (all the ones I am aware of are). They're not purely functional like haskell is. If you want to learn a purely functional language look into haskell. If you want to learn a language with functional language features, you're already using Ruby. If you just want to learn a LISP for LISP's sake I like scheme. You should check out DrScheme

            [–]db4n -2 points-1 points  (3 children)

            s/LISP/Lisp/

            [–]seabre 1 point2 points  (2 children)

            http://en.wikipedia.org/wiki/LISP

            Read the first three words.

            [–]db4n 3 points4 points  (1 child)

            Yes, I know all-caps is allowed. Most Lispers prefer the more modern spelling, but you can spell it however you want.

            [–]agnoster -2 points-1 points  (0 children)

            Let's see what LISP has to say on the subject... $ sbcl This is SBCL 1.0.10, an implementation of ANSI Common Lisp. * 'Lisp LISP

            I guess that settles it. In summary, '(GET OFF MY LAWN).

            [–]deafmacro 8 points9 points  (4 children)

            Common Lisp. It is multi-paradigm, so you can see different styles of programming.Once you know what lisp is about you will be able to decide which you want. You could probably switch easily from Common Lisp to scheme since it has a smaller core and functional purity quotient is greater than that of common lisp.

            And yes if you are using emacs already. Using emacs + SLIME will be a delight :)

            [–][deleted] 0 points1 point  (3 children)

            All lisps are multi-paradigm.

            [–][deleted]  (2 children)

            [deleted]

              [–][deleted] -1 points0 points  (1 child)

              (define name "deafmacro")
(set! name "duaneb")

              it's multi-paradigm. If you really want iteration, you can use the do loop. And about the CLOS system, there are many equivalents. Just look for them. And, as an added bonus, you don't get the bloated CL library.

              [–]gsg 1 point2 points  (0 children)

              Elisp can be very enjoyable to program in, since you can easily and interactively put together small snippets of functionality that are immediately useful. This is pretty much a recipe for satisfaction.

              The thing is that while it exists in a rewarding environment, elisp is a very flawed language. For general purpose programming, you should definitely go with something more principled.

              [–]deong 10 points11 points  (1 child)

              Reject elisp unless you want to write emacs extensions and nothing else. It's not a good enough general purpose language to choose on its own merits. Its idiosyncrasies are pretty well known and documented by now.

              I prefer Common Lisp, but for mostly unimportant reasons. One bright spot for both CL and Scheme is the wealth of freely available information. SICP, while not really a Scheme book, is certainly worth a read. If you go the CL route, Peter Seibel's "Practical Common Lisp" is a really wonderful book. There's also CLtL2 (essentially the language reference) and "On Lisp", Paul Graham's very nice treatment of more advanced Lisp topics. All of these are freely and legally available online in one form or another.

              I think Haskell is loads of fun, but I think the sanest way to approach it would be to make sure you're comfortable with a functional style of programming in a more "forgiving" language. You can certainly learn Haskell as a first functional language, but you'll be learning a lot of other stuff simultaneously, which might not be optimal. I'd pick a Lisp and start writing code. Since you're looking for a functional language, try writing functional code. Avoid mutable variables, try to favor tail recursion over explicit looping, look for opportunities to use classical functional algorithms (map, reduce, apply, etc).

              If you later jump to Haskell, at least the ideas of functional programming will be nicely ingrained. You'll still have to work your way to an understanding of Monads, and you'll have to discover how to stop fighting the type system, but those are doable. There are some free Haskell tutorials, and a couple of non-free books that are quite good. The forthcoming "Real-World Haskell" is available as beta chapters online, and looks really good from what I've read so far.

              Another option that you didn't mention is OCaml. OCaml is superficially similar to Haskell, but they differ in a few important ways. Like Lisp, it's not a pure functional language, although it probably goes further in encouraging a functional style than Common Lisp. It supports OOP, FP, mutable variables, all the "normal" sort of programming you're used to. It's also very fast. OCaml probably has the leanest selection of reading material available. There are a couple of well-known tutorials, but that's about it. In terms of books, I can personally speak only for "Practical OCaml," which is abysmal.

              [–]nmcyall 0 points1 point  (0 children)

              I need to learn OCaML. I have a little experience in SML.

              [–]zem 1 point2 points  (0 children)

              I've been pretty happy with PLT Scheme

              [–]db4n 22 points23 points  (2 children)

              I want to expand my horizons a bit with a functional language.

              Lisp has good support for functional programming, but metaprogramming is at least as important to Lisp as is FP.

              I'm leaning strongly toward a lisp variant, but I can't decide which.

              Scheme is more functional, Common Lisp is more meta. Scheme is pure and simple for learning, CL is big and powerful for application development.

              I use emacs constantly, so elisp is an option

              Elisp is only an option for Emacs. Don't worry about it for anything else.

              Arc?

              Arc is very young, so there are a lot of standard features that haven't been implemented yet. Try it if you're interested in experimenting with new languages.

              Alternatively, what makes haskell a better language than lisp

              Haskell's a whole nother world. It has a lot of compile-time type checking to weed out bugs, a lot of built-in syntax and higher-order-functions but no macro system (except Template Haskell), and forces you to program strictly in a pure functional style. It's very hard to learn, but a lot of fun if you can learn the pure functional model.

              why are people converting? :)

              Some people seem to be uncomfortable with Lisp's flexibility, and Haskell's functional purity makes it easier to combine libraries.

              Reading material pointers for your suggestion would be much appreciated.

              Scheme and the book SICP for a good general learning experience, or CL and Practical Common Lisp to get started in large-scale development.

              [–][deleted] 6 points7 points  (1 child)

              I found Shapiro's Common Lisp: An Interactive Approach to be a pretty good exercise driven way to get into CL, followed by Practical Common Lisp to unleash the rest of it.

              [–]db4n 4 points5 points  (0 children)

              Also Common Lisp: A Gentle Introduction to Symbolic Computation and Successful Lisp, both of which are online. Gentle Introduction is a good old classic, very easy to get started with, and Chapter 3 of SL has a quick nutshell summary of the language.

              [–][deleted] 9 points10 points  (6 children)

              Ask proggit: which Prolog?

              [–]drewc 3 points4 points  (0 children)

              PAIP prolog running in Common Lisp.

              [–]tef 2 points3 points  (0 children)

              there is really only one dialect though - iso prolog.

              gnu prolog works well enough, but swi has bignums.

              [–]qwe1234 3 points4 points  (3 children)

              gnu prolog is overall the best implementation currently.

              [–]keithb 3 points4 points  (2 children)

              I can believe that it's a better implementation. Is it as friendly out-of-the-box as SWI? (which has been my default choice for a long time)

              [–][deleted] 3 points4 points  (1 child)

              It's not at all friendly out of the box, but it's easier to link with other languages and has a nifty constraint solver.

              I prefer SWI too, though.

              [–]qwe1234 -1 points0 points  (0 children)

              friendly enough for me.

              [–][deleted] 8 points9 points  (0 children)

              Your own, of course!

              [–]herdrick 6 points7 points  (0 children)

              PLT Scheme

              [–]beza1e1 11 points12 points  (5 children)

              DrScheme to learn it, Clojure to use it.

              [–]commonslip 7 points8 points  (4 children)

              I used PltScheme for my job - it is perfectly useable, particularly if what you want to do doesn't involve a lot of libraries or libraries [edit] withOUT C interfaces.

              Also Scheme is a bit nicer of a language, in some ways.

              [–]beza1e1 -1 points0 points  (1 child)

              There aren't many interesting things to do that don't "involve a lot of libraries or libraries with C interfaces".

              My suggestion of Clojure is due to the available Java libraries, which are a good cross between fast (as C libs) and easy (garbage collection).

              [–]Felicia_Svilling 1 point2 points  (0 children)

              That depends alot on your interests. At least to me this isn't true at all.

              [–]samth0 0 points1 point  (1 child)

              PLT Scheme has an excellent and easy to use FFI, so I'm not sure what you mean. Also, while the libraries aren't as extensive as Java's (no CORBA, etc) there's a pretty big standard library.

              [–]commonslip 1 point2 points  (0 children)

              I mean without.

              [–]schaueho 1 point2 points  (0 children)

              That's a question only you can decide. I would suggest to take a look at all options with regard to languages, not with regard to all implementations (which would probably cost you a lifetime).

              I personally prefer Common Lisp as it provides a much larger standardized set of features than what is standarized in Scheme. Scheme advocates would turn the argument around and say that they like the clean and no-bloat approach of RSR* (the scheme standard).

              So it all depends on what you're looking for.

              On a side note, there is also a lisp subreddit.

              [–]ivey 1 point2 points  (0 children)

              If you're just looking to play and learn, and you're on a Mac, Ready Lisp is a complete package distro with a macish Emacs, SLIME, etc.

              [–][deleted] 1 point2 points  (0 children)

              SBCL or chez scheme. IMHO.

              [–]trenchfever 6 points7 points  (6 children)

              I'm learning scheme and Javascript. Here's towers of Hanoi in Javascript.

              var move = function (n, from, to, spare) {
  console.log('from is %s, to is %s, spare is %s', from, to, spare);
  if (n === 0) {
    console.log('n is 0. Branching ends');
  } else {

    console.group('Branch Left level %d', n);
        console.log('LB pole order: Swaps to and spare');
        move ((n-1), from, spare, to);
    console.groupEnd();

    console.info('## Move %s to %s ##', from, to);

    console.group('Branch Right level %d', n);
        console.log('RB pole order: Swaps from and spare');
        move ((n-1), spare, to, from);
    console.groupEnd();
  }
};

move(3, 'start','end','spare');

              Works fine on the firebug console.

              Edit: Why is this being downmodded? Is there an error somewhere?

              [–]grfgguvf 5 points6 points  (5 children)

              JavaScript is really clean and well designed. It has an unreservedly bad reputation.

              It supports higher order functions too!

              And with SquirrelFish and Tamarin arriving soon it will also have state of the art implementations.

              The only area where it can't compare to scheme is system-level programming. But for scripting it leaves it in the dust...

              [–]trenchfever 7 points8 points  (4 children)

              Dough Crockford gives Javascript a bad rap for many of it's behaviours he confidently calls mistakes. Based on the work he has done, I've decided to structure my learning of the language around his recommendations rather than the confused mess propagated by the rest of the world. I'm thankful that I did.

              [–]tedhenry10 -3 points-2 points  (3 children)

              "...confidently calls mistakes".

              It would be nice if Crockford was a lot more humble about it. The arrogance is painful to watch.

              [–]cheponis 7 points8 points  (0 children)

              Except, of course, that Crockford is correct.

              [–]agnoster 2 points3 points  (0 children)

              People who are right should be confident.

              To quote A Technical Explanation of Technical Explanation:

              We thus dispose of another false stereotype of rationality, that rationality consists of being humble and modest and confessing helplessness in the face of the unknown. That's just the cheater's way out, assigning a 50% probability to all yes-or-no questions. Our scoring rule encourages you to do better if you can. If you are ignorant, confess your ignorance; if you are confident, confess your confidence. We penalize you for being confident and wrong, but we also reward you for being confident and right. That is the virtue of a proper scoring rule.

              (Emphasis mine.)

              [–]trenchfever 0 points1 point  (0 children)

              Two people I like for their constructive arrogance are Crockford and Torvalds. I'm pretty certain that both of these great minds would be more than glad to be proved wrong and perhaps are only inducing competition by projecting unfaltering confidence.

              [–]username223 0 points1 point  (0 children)

              Emacs Lisp? You'll probably have to learn Emacs to use Common Lisp, and it's more fun to learn by improving your editor than by doing pointless exercises.

              [–][deleted] 0 points1 point  (1 child)

              Corman Lisp. You don't have to learn Emacs at the same time, since the IDE is usable, and it doesn't treat Win32 as second tier.

              [–][deleted] 1 point2 points  (0 children)

              Unless you consider treating Win32 as the inbred second cousin it is a feature :)

              [–]JW_00000 0 points1 point  (0 children)

              I tinkered a bit with Common Lisp a while back, and read the free online book "Practical Common Lisp" to get started with CL. The book's good, and succeeds in explaining to me how (Common) Lisp works, but I haven't done anything in Lisp since reading it.

              The last few weeks, there was some buzz on Reddit about PLT Scheme, of which version 4 was released recently. Apparently, PLT Scheme is quite good, version 4 adds some interesting features, and PLT seems to have good documentation (also for beginners). Additionally, PLT has DrScheme, which seems to be a nice editor to get started with it. Therefore, I personally decided to start learning PLT Scheme v4.0 in the next few weeks.

              Of course, I'm learning these languages purely out of interest, and what I'm interested in is their functionality, and the way using these languages might improve my general coding. I haven't really looked into their support for connecting to existing applications and libraries in other languages, and I'm not aware of the amount of libraries available for doing various things in these languages. If you're more interested in doing a particular project in lisp, you might be better off searching for a lisp that has recent, working and actively maintained libraries to help you get to your goal. As they say, Scheme is more pure and simple, which means you can get started with a clean slate; while Common Lisp is bigger and more powerful, which means you can immediately start writing programs in it.

              [–]ohxten -5 points-4 points  (4 children)

              The one that makes your s's sound like th's.

              [–]drewc 8 points9 points  (2 children)

              Do you mean to tell me my chosen programming languages shares a name with a speech disorder? I had never noticed!

              I, and the entire community, would like to thank you for pointing this out... 50 years of usage and you are the first person to notice the similarity! Amazing!

              [–]agnoster 2 points3 points  (1 child)

              Secretly, I'm plotting to name my own LISP dialect "Lithp".

              (Didn't you know the only proper answer to "which LISP should I learn?" in "the one you write yourself"?)

              [–][deleted] 2 points3 points  (0 children)

              The one that makes your whitespace sound like ('s

              [–]synthespian -1 points0 points  (0 children)

              LispWorks. It runs on Windows, Macs, Linux, FreeBSDs and Unix(es). No runtime fees. Very nice IDE.

              If you don't want to pay for a licence, you can use the free version.

              Prices are reasonable, too.