Ask HN: If you could only code with one language which would it be?

Here [0] is a list of the various SRFIs. To answer your first question, I'm going to first digress.

The history of Lisp began in McCarthy's lab with him and his students. As the language grew in adoption many variants developed, there was no real standard (as opposed to Ada, Fortran, Algol, and others that developed around standards groups). Scheme was an attempt at something like a minimal, lambda calculus-based, lisp. There's more to its history than that, but that sense of minimalism is crucial to the Scheme approach. Common Lisp was developed in the 80s as a way to develop a common lisp that brought together many of the academic and commercial variants in use at the time.

Why is that important? Commercial and academic lisps and a standard merging them was necessarily large. There were a lot of decisions made that look like over engineering, until you think about the multitude of systems that it had to run on. Common Lisp's file path handling can understand how any operating system might present file paths. The DOS/Windows formatted string, a Unix/Posix path, whatever VAXes do, IBM mainframes, etc. Very very useful. But not everything made it into the standard, and it hasn't been updated. As a community Common Lisp implementations do stay near each others' approach when extending their implementations to account for things like Unicode or multithreading, but it won't be the same. Some libraries work by creating an interface and wrapping the implementation specific code behind it, giving you a more portable way to accomplish your tasks. CFFI [1] is one such interface, as an example. Common Lisp had to include some functionality so that people who'd written Maclisp or Starlisp or whatever could port their code with minimal alterations,

Scheme never aspired to that. And that's where the SRFIs come in. SRFIs aim to take common behaviors that may have various conflicting implementations by people over time and provide a consistent interface. Every SRFI is not available in every Scheme implementation, and some may have portable implementations written in mostly pure Scheme, while others need to be tailored to a specific Scheme implementation. This also means, though, that unless a library is written in pure Scheme (and many are), they are less portable in the Scheme world than libraries written in Common Lisp.

Chicken Scheme is the one I used the most besides PLT Scheme which developed into Racket. It has a pretty comprehensive coverage of the SRFIs (or did at the time, should still) and a good sized set of available libraries (called eggs [2]).

When it comes to being able to get things done and write a program, both Scheme and Common Lisp are equally effective in my view. But they do have differing philosophies in how they grew to be where they are today.

You may have to write more code yourself in Scheme. But that's not always a bad thing. In Common Lisp I often found a function already existed to do exactly what I had in mind. I mean, yes-or-no-p [3] already exists in Common Lisp. It was considered sufficiently common and useful to make it into their standard. Scheme doesn't have that and wouldn't have that. So it goes to philosophical differences and differences in the goals of the two communities.

==============

Regarding tooling, I've not spent too much time trying to do performance profiling. But CL has a lot of that baked in. This is part of its kitchen sink appeal. It has a really good debugging system built in. You can change the value that caused an error and resume from that same point. Scheme debugging is more implementation specific, I generally did it by way of the REPL adding a line or function call at a time until I found the error.

CL has baked in trace and time functions which can be used for performance profiling (how often does a function get called, how long does it take to execute an operation, etc.). For Scheme implementations this will largely be implementation specific (NB: Can't comment more on this because I didn't try to use these when I programmed in Scheme).

==============

The FFI story on both is pretty good these days, though in my experience the FFI side in Scheme was often really good and a central feature in a number of implementations (both Guile and Chicken Scheme which I used a decent amount). Calling into C was almost trivial, having C call into Scheme was less trivial but not hard.

==============

If you'd like a recommendation on where to start: The Little Schemer. Nearly everything in it is portable across Scheme and Common Lisp (with minor changes due to some differences in syntax). It's an entertaining book and ought to get you comfortable with the lisp approach to things. From there you'll be able to start with either Scheme or Common Lisp. IME, it's easy to switch between them and I don't get tripped up when I do. It's harder to switch between Scheme implementations for me than between Scheme or Common Lisp due to their often slightly different handling of certain behaviors (how they handle modules, or FFI, or something). This won't teach you how to write large programs in a lisp, but you'll be very comfortable understanding the structure of lisp functions and source files and be on your way to coding in the large in lisp.

If you have a math/science/engineering/CS background, check out Structure and Interpretation of Computer Programs and the associated lecture videos. Free, Scheme specific though you could technically follow along in Common Lisp if you take the time to understand the differences between the two languages for some tasks.

Norvig's Paradigms of AI Programming is a great, but non-free, resource if you want to understand Common Lisp. It is an AI programming text book, but it's more like 90% AI and 90% Common Lisp (yes, those don't add up).

And I can't believe I forgot about these: Practical Common Lisp [4]. It is free, and a very good intro to Common Lisp. On Lisp [5], Paul Graham's text on the subject. Also free and a great introduction to the language. It's very heavy on using macros which is one of the defining features of lisps in general, the ability to write code that writes code (metaprogramming, if you're familiar with Ruby you've likely done some of this before).

==============

[0] https://srfi.schemers.org

[1] https://common-lisp.net/project/cffi/

[2] http://wiki.call-cc.org/chicken-projects/egg-index-4.html

[3] http://www.lispworks.com/documentation/HyperSpec/Body/f_y_or...

[4] http://www.gigamonkeys.com/book/

[5] http://www.paulgraham.com/onlisp.html

==============

I've reread this a couple times now. I hope it's clear and that I got the details right. Lisp is a great language to learn. Like learning statically typed functional languages in the ML and Haskell camp, or learning Erlang, learning Lisp will open your mind to ideas in how to construct programs that you probably had never thought of or seen before. The lisp community is pretty good and responsive, you can check out the IRC channels for them, mailing lists, and comp.lang.lisp is (or was) a pretty good resource (seeing a decent amount of spam on the front page, but I don't know if that's common or just me catching it at a bad time).

I can't promise a lot of help, but if you have some more questions you can contact me (HN name at gmail). I generally answer my email within a day, and I'll either give you the answer if I have it or point you to resources that may help. I will admit my non-work programming has been 90% Erlang the past several years so I'm a bit rusty (and work is 90% C# and 10# C++ so not much help here either).