The more I use Common Lisp, the more disappointed I am that it hasn't become more popular. It really is higher level than Python, Ruby, or Perl but with nearly the performance of C and C++.
It's nice to hear that I'm the only one. I, not too long ago, picked up Common Lisp and after a bit of "getting it", it suddenly became one of my favourite languages. And by "getting it", I'm not talking about the difficulties people normally refer to when talking about learning lisps, it was learning how to develop with it.
There's a huge productivity boost in just the fact that your development process is as follows: boot REPL, run your program and then modify your program (while running). If anything is to break, or hasn't been implemented, the debugger just stops your program, let's you inspect your program state freely and you can update the code that failed and have another go.
I'm normally very much to the strong, static typing side of languages. But to me, the Common Lisp experience is dynamic done right, it gives all the tools to handle the problems that arise from a dynamically typed language (even though Common Lisp is actually partially strongly typed) with is a great boon to productivity.
Those are some examples off the top of my head, but the general point is that unlike mainstream languages, Lisp languages evolved into environment for interactive construction and modification on a continuously running program, which is a bit different way of working than the regular write-compile-run cycle.
I think it's not so much whether the features exist in other languages since we all know they can be added but the whole being more than the sum of its parts.
Python really has a glorified edit-compile-run cycle. The interpreter loop is nice for quick tests or calculations, but isn't too helpful for the incremental development of your program.
This is the crux of the issue. Even in Python 3 the semantics for reloading modules is wrong:
Other references to the old objects (such as names external to the module) are not rebound to refer to the new objects and must be updated in each namespace where they occur if that is desired.
If a module imports objects from another module using from ... import ..., calling reload() for the other module does not redefine the objects imported from it — one way around this is to re-execute the from statement, another is to use import and qualified names (module.name) instead.
If a module instantiates instances of a class, reloading the module that defines the class does not affect the method definitions of the instances — they continue to use the old class definition. The same is true for derived classes.
https://docs.python.org/dev/library/importlib.html#importlib...
In principle Python has a runtime with type-tagged objects that you can inspect and code you can load, so it should be dynamic. Because of the way module and class loading behavior is defined you cannot actually take advantage of this dynamic runtime. Python does not really have a REPL, it has script loading akin to most Unix shells, and a second-class REPL that is useful for some limited debugging. This unnecessary dichotomy imposed on code loading makes it very different from Lisp and Smalltalk.
When clojure came around, I tried lisping again, and for whatever reason i was ready for it, and clojure is my goto language.
That said, I'd never connect to a repl on a server and do any kind of bug fixing unless it was really dire. It's too easy to get the run state out of sync with the text source files, and I don't see why this would be different with common lisp.
I think the repl is great for development and figuring things out, but the whole idea of "program as state" seems antithetical to the ideas of functional programming. With the main issue for me being that I have to somehow keep track of this program state in my head once I start tinkering with it.
For example, say I find a function has a bug and I go into the repl on the server and fix it, in situ. Say I spot some other issues, or had them on my list of things to fix when I had time... I start modifying functions here or there. Now my "program state" no longer matches my source code, and I have to remember to fix it so that it matches. That's error prone. I could enforce my own methodology of fixing the source and copy-paste to the repl or send it in whatever way, still error prone.
I have to remember what changes I made, to what functions, and if I iterated, now I have to remember which iteration was final. Multiply that by any and all functions that are touched. It's a lot to keep track of.
So when you say "inspect the state," I have to think common lisp must have some feature for state inspection that is missing in clojure. I know there are a lot of features of common lisp, especially in stack-tracing, that clojure has no parity to. But I'm curious if common lisp has some way of completing a "round trip edit" such that an edit/correction made on a server process, in situ, are able to be easily propagated back to your master source?
If you read all that, thanks :)
In SLIME you just connect to the Lisp process, open up your versioned-controlled file, edit it, hit C-c C-c for slime-compile-defun or C-c C-k for slime-compile-and-load-file. Isn't that how CIDER works also?
I remember one time, it was actually with Clojure, I had to deal with Paypal. Since paypal only sent results back to the server and not to localhost I couldn't debug the problem locally. So I connected to the server, bunged all the debug information into an atom and made a few requests. Then I could inspect the atom, make some changes and find out what the problem was and fix it right away. It took just a few minutes.
At about the same time I was also working on a C# server. There was a bug there that could only reproduce itself on the server. To fix that bug I had to put a load of logging into the source. Check the file into source control. Wait for the CI system to build and deploy. Then kick off some requests. Inspect the log files. Make some changes. Check in.. wait.. etc.. It took days to fix that bug.
Admittedly the Clojure project was mine on my own server and the C# project was on some corporate enterprise behemoth so there were other factors that hindered that project, but it did highlight to me how much quicker you can get stuff done when you have that instant feedback.
When I say inspect the state, generally I just mean inspecting the values of global variables. In CL it is possible to put breakpoints in the source and inspect all the variables up the stack. Mind you, this can be a bit hairy on the server if there are multiple people connected as there is no guarantee as to whose Slime connection will pick up the breakpoint.
The round trip edit is pretty similar to Clojure. You would generally have your source file open in Emacs, change the source code and press Ctrl+CC with the cursor in your function definition to apply your edits to the server. Then you save the file and check it in to source control. You don't have to type directly into the repl.
You don't have to work like this if you don't want to. Without mentioning any names, it has been known for the server image to be completely out of sync with the state of the source files to the point where there weren't really any source files. The work around was to just treat the server image as the master source of truth. Luckily in CL you can just dump the image to create a new executable with its current state. So for several years this one server existed only as a constantly updated binary image. I wouldn't recommend working like that, but it has been done.
Depending on your implementation - I know Clozure CL at least allows this - you can extract the source code out of the running image. So it is certainly possible to propogate back to master source. It was eventually how this one server was restored to a more orthodox source code tree..
To be fair, though, I run an nREPL TCP listener on my production servers too, so I can do the same thing with Clojure. :)
I think it was in his Beating the Averages essay - the one in which he talks a lot about the advantages Lisp gave them at Viaweb, over the competition.
[1] http://paulgraham.com/avg.html
[2] More Technical Details: http://paulgraham.com/lwba.html (note: redirects twice)
Here's the relevant section:
[ Interactive Toplevel
Lisp's interactive toplevel is a great help in developing software rapidly. But the biggest advantage for us was probably in finding bugs. As I mentioned before, with Web-based applications you have the users' data on your servers and can usually reproduce bugs.
When one of the customer support people came to me with a report of a bug in the editor, I would load the code into the Lisp interpreter and log into the user's account. If I was able to reproduce the bug I'd get an actual break loop, telling me exactly what was going wrong. Often I could fix the code and release a fix right away. And when I say right away, I mean while the user was still on the phone.
Such fast turnaround on bug fixes put us into an impossibly tempting position. If we could catch and fix a bug while the user was still on the phone, it was very tempting for us to give the user the impression that they were imagining it. And so we sometimes (to their delight) had the customer support people tell the user to just try logging in again and see if they still had the problem. And of course when the user logged back in they'd get the newly released version of the software with the bug fixed, and everything would work fine. I realize this was a bit sneaky of us, but it was also a lot of fun. ]
[1] Discussed in this same thread, e.g. this comment by mikelevins:
https://news.ycombinator.com/item?id=14677016
Not sure if PHP has that.
Incidentally, I seem to remember the following: some years ago, after playing around some with Lisp (Allegro CL from Franz, and the Lisp IDE from Lispworks, both of which supported this feature or something like it), I was trying out a then-current version of Visual Studio, and saw that it had a new feature called Edit-and-Continue, which I thought was similar to the Lisp feature.
Or to put it another way, trace is an option that is passed to the Python interpreter. In Common Lisp (trace ...) is a function that can be called in the REPL.
To me the thing that CL has that has yet to be matched by any other languages, REPL-based or not, static or not, is the amazing condition system and dynamic restarts for handling problems. For building and debugging systems this is an utterly amazing thing. It also allows composing exceptional conditions in a reasonable way.
Every other language I use (e.g., Clojure these days a lot) I constantly miss this amazing stack-walking ability and conditional restarts.
Every time I boot my old Symbolics computers and something happens and I get a GUI restart, I'm just amazed at what we have lost through two decades of non-CL living.
Heck, it's easier to handle recovering from an error by just restarting a process and letting it follow the normal unit logic.
Do have any knowledge of how CL and Erlang/Elixir/OTP are similar or vary on error handling?
When an error occurs in a Common Lisp program the runtime signals a __condition__. A condition is an instance of a class that represents unexpected or otherwise exceptional situations that can arise during execution. When a condition is signaled, control searches for a registered handler that matches the type of the signaled condition. If one is found then control passes to the matching handler. If none is found then control passes to the default handler, which by default starts an interactive repl called a breakloop__.
The breakloop has access to the full dynamic state of the suspended computation, including all local and dynamic variables and all pending functions on the stack. From the breakloop a programmer can alter variable values and redefine functions and classes. For example, if you conclude that the error happened because of an incorrect function definition, you can redefine the function and tell the breakloop to resume execution as if the new definition had been called instead of the original one.
A __restart__ in this context is an option for continuing execution. Common Lisp's condition system offers the programmer the ability to choose from among available restarts in a breakloop, or to write a handler that will make the choice automatically when a condition is signaled, and it also offers the ability to define custom restarts.
(defun fn1 ()
(if (yes-or-no-p) (print :yes) (print :no)))
(defun fn2 ()
(fn1))
(defun fn1 ()
(restart-case (error "yes or no?")
(yes () (print :yes))
(no () (print :no))))
(defun fn2-interactive ()
(fn1))
(defun fn2-automated ()
(hander-bind ((error (lambda (c) (invoke-restart 'yes)))) ;; handler
(fn1)))
yes or no?
[Condition of type SIMPLE-ERROR]
Restarts:
0: [YES] YES
1: [NO] NO
2: [RETRY] Retry SLIME REPL evaluation request.
3: [*ABORT] Return to SLIME's top level.
4: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {1003167FA3}>)
Having said that, practically, you wouldn't release a tool which has users interact at the debugger, at least for any level of more serious commercial work no?
As said, you can have a custom "debugger" which does not look like a debugger, but a general purpose user interface in the text terminal. For example, being "custom", it can also hide the restarts which are only meaningful for true debugging (like restart 2,3,4). (see detail [1])
It is possible for a debugger to even invoke a GUI (imagine a debugger hook which pops up a window with an OK button) or a web UI (sends a Websocket message to the client, wait for the user to click something on the browser, receive a reply and invoke the restart). In fact, SLIME is written this way: it overloads the debugger hook, and it sends and receives messages to the Emacs TCP client (thus you can click on the menu on an Emacs buffer to restart -- this action is notified back to the underlying lisp process via TCP, which then calls invoke-restart).
[1] You can obtain the list of restarts with COMPUTE-RESTARTS and filter unassociated restarts (similar to a method dispatch but is temporary / has dynamic extent -- see http://clhs.lisp.se/Body/09_adbd.htm).
It also supports writing condition handlers that can do all of the above under program control, rather than under human control. In other languages you would say "exception handlers", but Common Lisp conditions include representations of situations and responses that exceptions typically don't.
These facilities, along with things like a debugger, a tracer, support for built-in documentation, a compiler, and a disassembler, are part of the language standard, not the development environment.
Common Lisp is a language designed from the ground up for writing programs by interacting with them as they run. There aren't very many other languages like that. Smalltalk is one of them.
* Python REPL does not check and warn the trivial type/arguments errors when a function is defined. It is only after the program reaches that erroneous line that an error is signaled. SBCL always warns about the function signature. Perhaps this may be customized by some global variable or a command line option, but not being warned by default is a huge waste of time, as it takes non-negligible amount of time to reach there (specifically because it is a ML task). (SBCL also warns me about type errors in most of the standard functions as well as ftype'd functions.)
* Python does not have restarts. I mean the condition system in Common Lisp. This again imposes a significant amount of slowdown on the debugging cycle as an error may be signaled only after a multi-hundreds-MB data file is loaded in the beginning of a function and then the erroneous line of code is run. In CL, when an error is signaled, the program enters the debugger and halts there, during which you can correct the program, redefine the function, then resume the code from one or two stacks above the current. In python an error always rewind the stack to the toplevel, so you have to rerun the whole function, loading that huge data file again in the middle of the stack. Don't say you are afraid of some side effects in the code, I follow "Mostly Functional Style" in CL.
* Python debugger shows the stack frame, but does not by default show the values of the arguments in the function call stack when an error is signaled. It forces you to use an ugly printf debugging style. I would like to know if it is possible to alter the way the stack is printed. In CL, a debugger is just a function stored in debugger-hook. I hope you can do something similar.
* Somehow Emacs C-M-f selects the whole line, not an expression.
For those interested buying a copy of Common Lisp Recipes: I think Edi said that for the author it is financially better to go via his page:
But then, supporting a local bookstore might also be an option. Though I have to confess, I got my printed copy from Edi as a gift... :-)
But why can't we have nice things back?
--
[0] - read that in the interviews in "Coders at Work".
Particularly at the beginning, when the web was intended to be nothing but markup and hyperlinks for otherwise plain text documents?
Consider a language like Python. Aggressive duck typing means consistent syntax for different data structures and types. Stuff "just works" without a deep understanding of how it works.
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?
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 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.
Given the amount of video tutorials on YouTube, I would say yes.
(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.)
Do you really think that all the others really read books? :)
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.
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.
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).
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.
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.)
$ 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.
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.
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.
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.
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.
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.
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.
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.
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.
No affiliation -- just checked for myself.