> The base level of knowledge to use the language is so high that you pretty much need a book (...) to be able to get started.

I wonder what that says about developers these days.

Ever since I started 'till this very day, it was obvious for me that if you want to learn something, you go pick a book about it. Books aren't scary. They have one of the highest knowledge-transfer-to-time ratios out of any sources you could find; they easily beat videotutorials and text tutorials. Most programming books I've read are also quite pleasant and easy to follow (better than some novels I've read...).

Are people scared of books these days?

I mean, I accept that the power of a tool can be a limiting factor to adoption, but I'm deeply saddened by it. Learning and understanding things isn't hard.

--

> CL is the opposite. What is the difference between setp, setf, defvar, and defparameter? Why is the documentation so technical and dense? What is a "form"? What are multiple return values and how do I get to them? Should I spend time learning the loop macro DSL?

The answer to that is simple: go and read a book :). Practical Common Lisp is available on-line for free, and it's a current best introductionary book for CL.

http://www.gigamonkeys.com/book/

Given the amount of video tutorials on YouTube, I would say yes.

No, but books are more difficult to access than online tutorials and more expensive.

If I suddenly decide I want to learn Common Lisp one night, I'm going to Google "learn common lisp" and read/watch tutorials before I buy/borrow a book. That's not to say I won't move to a book eventually, but tutorials are infinitely easier to access.

(In fact I'd be worried to work with programmers who didn't back their experience in their primary language(s) with at least one solid book.)

1 - the language was simple enough that there really wasn't that much to learn

2 - that programming language was similar enough to the languages they already knew that there really wasn't all that much to learn

When you're trying to learn something that's radically different from what you already know, and relatively complex, then it's a lot harder to just pick it up by playing with it and using it. That's when you usually need a good book, teacher, and/or course.

I've heard so many programmers brag about how they can learn any language in a weekend, or about how "all languages are the same". Usually they know only one language paradigm: Algol-like imperative languages, and sometimes don't even realize that there are other paradigms out there that are mindbendingly different, and which might actually be challenging to learn if all they've done their life is programmed in languages like C or Java.

Most people I know who learned programming (including with the languages you list) did so by reading books (or the digital analog) and doing things, and the former was essential to the latter. So, no, I don't think those things are examples which your support your “by doing things, not by reading books” position at all.

I think the main trouble is that it's hard to know what the good books are for your particular needs, and most people aren't going to want to try exploring some alternatives to find a good one, or maybe haven't been given a good recommendation yet, so they don't bother reading books at all unless really curious or forced to... When you're just messing around or just need to edit relatively simple business logic in whatever language without making a bunch of new stuff, you can get away without understanding most things in enough detail that a book would cover.

Lots of books exist for different needs (references, subject-focused, beginner focused, general tour of the language...), so again it's hard to pick out in advance the one you need right now. Some of the more generic language level ones targeted at professionals still manage to leave out crucial sections like "How do professionals actually develop in this thing, and what alternatives are there? What's the simplest way? How are things deployed to production?"

For Common Lisp in particular the problem is two-fold. People get recommended SICP all the time, which is a good book, but they read as far into it as they can and then assume they know Lisp and wonder what the big deal is when compared to modern dynamic languages that let them loop without recursion or use infix math. But if they then go on to try and learn about Common Lisp, so many references (including Practical Common Lisp) don't show the good stuff for way too long, if ever, but begin by saying it's basically a waste of time without emacs. Now the reader has to learn emacs and like it. It's not a waste, yet books don't always address that. On the other hand if you're tool-agnostic like some Lisp books you might give a similar impression of SICP and leave out some of the cool bits because they can be hard to convey in text. The Debugging Lisp series at http://malisper.me/debugging-lisp-part-1-recompilation/ is my favorite at the moment to show people what makes Lisp different. It's emacs focused but it shows you why you might want to use emacs, or some other editor that can hook into the same underlying commands like 'COMPILE that aren't emacs-specific. The REPL is like a constantly present gdb (and all that implies like the possibility of better viewers than the text terminal, such as emacs) but way better.

This is a solved problem, too, but not many people seem to understand the solution until told explicitly. I know it took me a while to figure it out, but here it is:

With the Internet (and little English proficiency), you have the access to the very best material human race created on any given subject. In programming, the best books for topic X can be easily identified by searching for "best books on topic X" and browsing the resulting Reddit and Quora threads. It's literally that simple - if you see some books popping up constantly in such topics with high recommendations, it's a safe bet to go and read them.

RE Common Lisp, I don't think it's that bad, as long as people get directed to PCL instead of SICP. I always recommend SICP as a book for blowing your brains out, and learning 80% of concepts used in programming in general - not as a book for learning Lisp, because it's not about that.

The Debugging Lisp series is awesome, thanks for linking that!

This is a common belief I hear from people, but it is deeply, deeply flawed.

The Internet mainly has access to the very best promoted material that the human race has created on any given subject.

> and little English proficiency

Of course, it can't be best if it's not in English.

I disagree, insofar we're not talking about some obscure lone genius work which for some weird reason isn't known to anyone else. I mentioned Reddit and Quora for a reason - communities around specific topics can recommend best sources pretty well, and evaluate them by quality.

> Of course, it can't be best if it's not in English.

Well, for better or worse, English is the dominant language of science and technology today, so it's expected that best resources will be created in, or translated to, this language.

The face value interpretation of your original statement is that not does the Internet accurately recommend the best sources, but it also hosts them too.

"access to the best material" is more than merely "access to reliable recommenders of the best material", right?

Anyways, you are missing the point, that teaching involves conversation and that can't be easily gotten from a book. Sure, a book is a good supplement, some are called companion, even, and with programming the need for good documentation is called out often enough, but still.

Honestly, I'd call it learning experience on using the Internet ;).

> teaching involves conversation and that can't be easily gotten from a book. Sure, a book is a good supplement, some are called companion, even, and with programming the need for good documentation is called out often enough, but still.

Teaching involving conversation with a good tutor can indeed be even more efficient than books. But that's a pretty rare situation (average university classes don't count - too much people, not enough time, too crappy tutors). Books are a good substitute - in fact good books for a given subject exist exactly so that you can learn something without having a specialist explain it to you face to face.

Companion books is something I'd generally avoid, since they exist to support a class, not to give you information.

I guess the point I was trying to make is that patronage at the right time might have a lot more potential to generate motivation, insights, etc. Professors in huge classes are too distant for that, agreed, but one benefit of university is the social experience. Outside of university, stumbling on the right path without guidance would be extremely lucky, while finding a good book on the internet depends on asking the right questions and one single book certainly isn't enough. And most people need guidance on how to work through books, to begin with. Sure, with regards to information technology, the internet hosts the largest community there is to learn from, but arguably it is, again, almost too big for a novice (and might have a lot of negative side effects).

Really? I've never seen such a leaky set of abstractions as Python's collection library. It's ridiculous how very often I find something irritating and the reason behind it is, "This was the first implementation and therefore was crowned 'the simplest.'" That seems to be the pattern in general with Python.

A great example is Python's complex iteration system. You have 2 ways to deal with it; a sophisticated but very limited list comprehension syntax and a absolutely primitive direct object iterator that barely abstracts over a coroutine.

You mention the cognitive cost of deciding what to learn, but this is actually a split responsibility between the language community and you personally. You need to make that call, and it speaks to a broader phenomenon.

> I find it similar to Haskell in this regard. The base level of knowledge to use the language is so high that you pretty much need a book, or a degree, to be able to get started. That's a huge barrier to entry

The thing that's so irritating to me about this argument is that nearly everyone who has learned to program falls into one of two categories:

1. Someone who spent a lot of time self-starting in the core principles of OO and imperative programming.

2. Someone who took a class or read a book to help get those principles down.

Folks offer objections to going back to novice status after they've done it once. But, Haskell and Lisp offer totally alternative programming paradigms, paradigms that mainstream scripting languages have been watering down and implementing in a limited context for years. It's only natural that there is a lot of stuff there. There was a lot of stuff to learn for OO scripting languages like Python!

And yet, the idea of learning these with the same methods new programmers use to learn OO patterns is panned as "unfriendly to beginners." I think in reality it's only unfriendly to intermediates.

A good part of that reluctance is entirely rational.

There are many dozens of programming languages that might be worth learning based on what communities of current users say about them.

But you can't tell if they're really worth investing all over again what you already invested in other languages without, well, investing.

It's a lemon market. Sellers know more than you about the true value of the car, err, language, but they have incentive to tell you it's great. Even worse, with programming languages even the most honest sellers might not know how their language really stacks up to the ones you already know because by symmetry they are underinformed too.

For example, I tried getting into Smalltalk based on the intense hype coming from the community, but I came to suspect it really doesn't offer that much of an advantage over languages I know better and stopped. But maybe it really is better... I'll probably never know.

I ignore smalltalk, ruby, perl, python, all that stuff. I don't want to use them, and somthing like smalltalk probably won't earn me money. Rust and D are similar. I've always thought D was interesting but I can't see it being worth my while to put the effort into it. Rust is just too different to bother with unless it becomes the new C++.

I think swift might be worth a look, as long as Apple doesn't drop it like dylan. It is close enough to what I know that it might not take an age to learn.

CL is good for nerd-cred, and gives a good leg up for Clojure. It probably also has some fundamental lesson to teach different to what I know instinctively. So I keep poking at it hoping it will click one day. Clojure seems like it would be a good thing to be able to claim knowledge of.

For me, I really don't regret learning any of them, and they all had something to teach me that I've carried forward.

For example, learning Common Lisp really let me internalize the concept of programming a meta-language to make my actual job easier (I later went on at that same job to write a very large, sophisticated code generator for a lot of humdrum deserializers). Learning Erlang helped me realize what a distributed system really is. Learning Java helped me understand what good concurrent threaded programs based around semaphores and queues could really god. Learning C# helped me realize there was a whole another level than that. Learning Clojure helped me realize we could use STM in the real world.

I could go on. But all of these things are things I carry with me to this day. I don't do it for "nerd cred." I do it to grow as a software engineer.

That's why I keep poking at CL, and don't bother much with the others. I don't think I'll get much of a paradigm shift from D or python but if I ever grok CL properly I'll feel I've learned something.

1. That there is a high risk here.

2. That the outcome could be bad.

Neither of these seem true. I dislike Python the way I dislike wearing shoes that stealing too small, but I don't regret learning it. I regret working in it more and more over time.

https://en.wikipedia.org/wiki/Opportunity_cost

https://en.wikipedia.org/wiki/The_Market_for_Lemons

How does learning a language as part of a professional skills acquisition represent significant risk when the alternative you're proposing is not learning any new concepts at all?

Your proposed cost model doesn't work when you're not choosing between N options and rather choosing between selection or no selection whatsoever.

You're probably more interested in modeling it as an OSP.

Nope, I don't believe you ever gave me the benefit of the doubt—your undoubted assumption that I was just throwing rocks perfectly explains your arguing style ;)

Very well. You cannot help me, indeed.

Python is definitely a simpler language. At some point it gets more complicated, when you need to move out of the comfort zone. For example last I looked the main Python implementation had a GIL (Global Interpreter Lock) which makes multi-core concurrent execution a problem. Common Lisp has more sophistcated implementations which don't have a GIL and easier use of multi-core threading.

Yes, you need to learn the difference between setting a variable and defining a global variable.

A 'form' is any valid expression in the Lisp programming language:

This is a valid Lisp form: (+ 1 2) It computes to 3.

This is not a valid Lisp form: (1 2 -). Trying to execute it is an error. The list is a valid s-expression, a list with three elements. But it is not a valid Lisp program, because Lisp expects the operator as the first element of a list and 1 is not a valid operator.

This idea of s-expressions and some of them are valid expressions in a programming language is different from Python, which does not have the idea of code-as-data. Thus you have more to learn and it is more complicated. But it makes many forms of computing with code easy.

Yes, you will have to learn about functions being able to return more than one value.

Yes, learning LOOP is useful. It's not the most elegant construct but it is quite powerful. There is a slightly more elegant and even more powerful alternative: Iterate. But it is a library and LOOP is already built-in.

Yes, a book helps. Luckily there are many. See the here mentioned Common Lisp Cookbook.

As introductions see:

Practical Common Lisp from Peter Seibel. http://www.gigamonkeys.com/book/

Common Lisp: A gentle introduction to symbolic computation. https://www.cs.cmu.edu/~dst/LispBook/ You can download the older version for free as a PDF.

Good luck with learning it!

https://www.amazon.com/Land-Lisp-Learn-Program-Game/dp/15932...

That said, it's not as comprehensive as Practical Common Lisp - it covers a bit less of CL, and a bit more of interesting things you can do it.

It is! Very fun in art, style and examples used! Has some funny hacks too, like one-page game written mostly in... format.

(And for learning, a particularly useful thing is a two-page loop DSL reference.)

To me there are different kinds of iterations. Many are naturally written as MAPCAR/REDUCE because the iterations are all independent. Iterations where there's lots of state carried from one iteration to the next are more naturally written with DO or even using tail recursion, if the implementation you're using supports that (most do these days). The theory behind LOOP is that all iterations are fundamentally the same ("one macro to rule them all" I guess). I think this is fundamentally wrong-headed. I want to be able to see at a glance what kind of iteration it is by seeing how it is written.

If later it needs optimization I'll give it a better look. (I've rarely needed to do this.)

I like my iterations to look the same so the source as a whole will be easier to grasp (for me and someone else).

Then again, you're Scott Burson and I'm just an anonymous Lisper so the parent should definitely give your opinion more weight.

[1] And DO has always looked ready unclear to me.

As for giving my opinion weight, it's definitely a minority opinion among CLers, but I think we're a significant minority; I don't think I'm the only one.

DO seems a little complicated at first, it's true, but once you understand it, the parts all fit together neatly. The only thing I wish had been done differently is the sense of the exit test -- currently it acts like "until" (the loop is exited when the test form evaluates to true), but the consensus of modern programming languages is that "while" behavior (exiting when the test is false) is more natural.

  $ txr
  This is the TXR Lisp interactive listener of TXR 180.
  Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet.
  1> [mapcar succ "abc"]
  "bcd"
  2> [mapcar succ #(1 2 3)]
  #(2 3 4)
  3> [mapcar succ '(1 2 3)]
  (2 3 4)
  4> ["abc" 1]
  #\b
  5> ['(0 1 2) 1]
  1
  6> [#H(() (2 two) (1 one)) 1] ;; #H = hash literal
  one
  7> (car "abc")
  #\a
  8> (cdr "abc")
  "bc"
  9> (car "a")
  #\a
  10> (cdr "a")
  nil
  11> (ldiff "abcd" "cd")
  "ab"

Common Lisp does have the the concept of sequences: a collection of generic operations over vectors, strings and lists. It just doesn't "go to town" with it. Common Lisp offers compilation to fast code. Really fast. Python-will-never-get-there fast.

All of those things are there for a reason, and most of them are very well thought out, documented, and are useful. If someone does not like having a lot of tools, they can use a poorer programming language. What kind of contribution do you think that someone with an attitude of "stuff "just works" without a deep understanding of how it works" can make to a community? Popularity and fads only have value to technical book publishers and conference organizers.

From reading about the history of LISP I'm not sure I agree. My take on it is that It was never meant to become a real language as it is now, some guy hacked together an interpreter for the s-expressions because it looked fun and easy, no-one ever bothered to take it further, and here we are.

LISP seems to be the bare mininum required to do whatever McCarthy was starting to explore and these days a lot of LISP nuts seem to think it is the coolest thing ever because of its minimalism without realising it was never meant to be that way.

Yeah, you can express anything in lists. You can also express any program in a turning machine. Doesn't mean you should.

But I don't know LISP well enough to say whether people who are commercially successful with LISP owe it to the language, or they would have been whatever language they use.

McCarthy obv knew what he wanted to be able to express and process, but the LISP he ended up with after the s-expression interpreter was hacked together was like the assembly language he was going to compile m-expressions down to.

At the time his main alternative seemed to be FORTRAN. It would be interesting to see if he came up with the same ideas with today's computing landscape and keyboards that had more characters than a card punch. You could argue that many of today's languages incorporate more and more LISP ideas as they evolve but it still might look and work a bit different.

I'm not convinced it is just 'what is the difference between setp, setf, defvar, and defparameter?' I think it is fundamentally different to how I approach programming.

I learned programming back in the 8-bit era, taught myself assembly, etc. I'm almost a hard-coded imperative programmer. I took to C and Java like a duck to water, and I'm guessing LISP advocates think I'm irreparably broken.

I agree with TeMPOraL that picking up a book to learn things is a good way to go and shouldn't be seen as a black mark against a language. The problem these days is that most books are rubbish. Every Clojure book I've seen is just garbage. I'm guessing CL books are better in regards to technical quality because not every average programmer can vomit one up but everything I've encountered invariably harps on about how much better LISP is than every other idea ever, and how concise and elegant it is, and the general smugness drives me nuts.

Practical Common LISP is better than most in that regard but it still falls into the trap about how expressive and concise and elegant and awesome LISP is right before showing 3 lines of code I have to spend a long time digesting.

I assume I'll get it one day, but it's like turning a container ship going really fast at the moment.

I'm wondering if the best way to understand LISP is to write a CL interpreter.

In very simplified terms:

Use defparameter to define a variable at top level (let's call it "global" for simplification.)

Defvar does the same, but if the variable already had a value, then it won't change that value.

Once you define them you can later change the value using setq or setf.

Setf does everything setq does and more. Setf can change the value of "places". "Places" is a great fundamental concept of CL.

> Why is the documentation so technical and dense?

Because Common Lisp is technical and dense. But it is that way for a reason, and as a reward, it "just works" and allows you to do things impossible or really difficult on other languages. It has no limits. CL is dense in features. It isn't a "watered down" language like python (btw i like python and use it). Python is restrained on features (compared to CL) thus there is less to learn. Thus it is easier to learn.

> What are multiple return values and how do I get to them?

Functions can return more than one value. This is not the same as putting many values on a list and returning said list. CL also allows true multiple return values.

This is explained on the CLHS. Use "multiple-value-bind" to get them.

To answer your specific questions, "form" is just a generic term for any sort of lisp code, whether it's an expression, quoted data, or a special form like defun, if, cond, lambda, etc.

Yes, you should learn the LOOP macro, the simpler iteration macros such as DO-LIST, as well as primitive types of loops (a function that recursively walks down a list, for example). You should learn the primitives because you this is how the nicer macros are implemented. The macros are there to save you time, so you'll end up mostly using them rather than writing everything out long-hand.

There is no setp, but setq is the primitive operation of setting a variable whose name is given by an unquoted symbol: (setq foo 42) sets the variable called foo to the value 42.

setf is magic. It generalizes setq to operate not just on variables but on places. A "place" is any expression that would ordinarily access some value. For example, if I have a list called foo, then the third item in the list is (third foo). I can get the value of that item by calling (third foo), and I can _set_ that value by calling (setf (third foo) 42).

defvar and defparameter are not very different from each other, except that defvar assigns the initial value to the named variable only if the variable isn't yet bound, while defparamter always sets the variable to the inital value you give. This means that if you load a file that has (defvar foo 42) in it, the foo variable will have the value 42. If you then change that value (by running (setf foo 24), for example), and then reload the file, the defvar form in the file won't overwrite the value you've set foo to, while a defparameter would.

For these kinds of questions I recommend the Common Lisp HyperSpec: http://www.lispworks.com/documentation/HyperSpec/Front/index...

The Permuted Symbol Index is usually where I start; it a sorted index of all the symbols, but symbols show up once for each word in their name. For example, if you go to the "I" page of the index (http://www.lispworks.com/documentation/HyperSpec/Front/X_Per...) you'll see that IF is listed, as you would expect, but also FIND-IF and MEMBER-IF. This is super useful, because you might only partially remember the name of what you're looking for, or you might be interested in these other related items that would have been hidden away in a normal index.