In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)
nicklevine.org
nicklevine.org
Disclaimer: 4x O’Reilly author and contributor to their blog. Don’t think there’s a financial incentive, I make less than minimum wage on books.
EDIT: above post originally said "This doesn't belong on Hacker News", but is has been edited out.
I don't think this two word explanation is going to help people understand your opinion.
First, there must be a huge market for technical books that don't appeal to Lisp fanatics. There are people coming from nontraditional backgrounds into technical roles, and they, I assert, probably want a different book than the types of books O'Reilly generally publishes, which are very technical, like those dealing with Lisp.
Two, and this is what is controversial: O'Reilly as a publisher is unable to offer those types of books and misses out on those types of customers.
I don't know how they marketed my book, honestly. I intended that it would speak to the beginner programmer by offering up chapters that introduced a new programming language in each chapter. I hoped people who weren't technology experts would find a gentle path into technology with my book. But I don't think it resonated, maybe that speaks to the quality of the book, but maybe not.
Less than 1% of the people in the world are software developers. Are the people fascinated by Lisp less than 1% of that? But, excluding say the Luddite population, let's say 90% of the rest of the people in the modern world do want to learn about technology and how to play with it, and I'm not sure O'Reilly knows how to reach them. O'Reilly is full of some of the smartest people in the tech community, but I'm not sure the empathy for beginners is there and that's hindering them as a publisher.
... and "the for Dummies" does not cater to them ? Or are you saying that O'Reilly should become somewhat more like the "Dummies" Series. Regardless of the name some of those books dont speak to the reader as if the reader is a dummy. Then there are those "21 days", "Unleashed".
I like it that O'Reilly speaks to me more than the "21 days" variety. Each to his own. I have been happy with Apress (other than Practical Ocaml) and Manning too. Packt is mostly an abomination.
O'Reilly speaks to me too, but I think there is entire population of people that aren't familiar with Tim O'Reilly and buy books from his publisher to join that community of thinkers. And that's a shame.
I always put masking tape over the “dummies” part and write “geniuses” on it before I display it on my desk so nobody will know.
From what computer science construct does that organization's name come from?
Who founded that organization?
How did that person get wealthy enough to start seed funding other companies?
Did that person write not one, but two books on Common Lisp?
Just some points to ponder.
Also if one knows a bit about Lisp history, the headline "O'Reilly agreed to publish a book about Common Lisp" triggers some memories, since for a long time O'Reilly actively discouraged people from trying to contact them about publishing Lisp books. ;-)
I once got chewed out for not knowing who Paul Graham is.
Relevant XKCD: https://www.xkcd.com/1053/
Paul Graham's essays are widely known among the HN user base, especially the "Beating the Averages" [1] one. Some of those who've read it know a bit more about the deeper history. And others obsessed with the "10x programmer" myth and they randomly stumble upon Lisp as one of the many "magic oils" that are rumored to make one into such a mythical creature.
It's a big circle jerk imho, but there's a lot to be learned for any programmer from modern Lisp-family languages like Clojure or Scheme/Racket. CL is also worth playing with if you want to know how a truly-hyper-flexible language feels like, but it's probably not a good tool to use unless your problem requires you to invent a new programming language but at the same time you have no time/budget/people to actually do it "the academic way" so you need a weird ducktaped-nuclear-power-tool to hack your way at the problem. Guess that's why some folk in quantum computing and computational chemistry and other on-the-edge-fields tend to pick it from time to time, but it gets replaced with other tech after the really hard research problem gets solved and the software gets rewritten to something else for v2.0. I alway re-try playing with it but it never sticks in my head, the [Python + (C++ or Rust or Go)] combo always wins over it.
I'm not sure that's true anymore. I think there's a much wider variety of people here now than 10 years ago.
Any programmer benefits from exposure to language families other than the one that is their daily driver. Even within familiers there can be nuances and differences that are worth at least a passing thought. Probably applies to life in general too.
I'm curious why you say this.
More precisely PG attributed success of Viaweb to LISP (speed of iteration etc)
http://www.paulgraham.com/lisp.html
http://www.paulgraham.com/avg.html
I am pretty sure the key factor was having a small and talented team. It didn't have to be LISP. They could have used another language they were familiar with.
Lisp was already Lisp.
I agree with you, the web apps in CL story is much better now. I am biased, now that I am mostly retired most of my fun side projects are in CL (with Haskell being a close second).
I really don’t care what languages other people choose to use but using CL makes me happy and I enjoy reading about other people doing good things in CL.
I hope such an editing system could offset the power of AST macros due to the possible ease of discovery.
Macros unfortunately require a very skilled developer team to not cause mayhem, taken to the extreme in Go not offering any fancy typing or macros.
It was all about logistics. YC had two competing companies. They pushed them together. The lisp team could get up to speed on python faster than the python team could on common lisp.
Viaweb also used GNU's compiler, ran on FreeBSD, and stored all data in flat files -- but those other choices aren't nearly as popular here (or in general practice) today.
Over time I noticed that posts about Lisp were quite common and decided to read up on it thinking there must be something to it if people bring it up again and again. Has been a gratifying journey so far.
Alas one of the problems Lisp does quite acutely suffer from is that SBCL has become a defacto standard and its support for anything that isn't GNU/Linux (like Solaris / illumos) is dismal.
By the way expecting that something be fixed by a non-specialist just because something is open source and expecting someone to sink their extremely valuable free time so someone could break and destroy that work again, well, that's not only despicable, it's extremely infuriating.
All the more infuriating as SBCL wouldn't exist without Solaris, which means someone already broke it at least once and here you come expecting me to not only know what to fix, but invest my life into something where my effort would likely be broken upstream again.
This needs to be taken up by the core SBCL team. Meanwhile, pity the time I used to report bugs which just sit there unhandled.
I'm sure that people will suggest things to try if you post details of what you have done to get it to build. Leave out words like "despicable" though.
Your account info states that you want to work with the Solaris successor projects, debugging a complex application is a good way to learn more about an OS.
Working on debugging C code and assembler is one thing, working on debugging Lisp another: I have to master Lisp first, but without working SBCL that's not possible and I'm not switching to an inferior OS just to master something I can't later on deploy on illumos / Solaris. I'd spend an inordinate amount of my free time for dubious gain, something I can no longer afford, so much so that I've stopped sinking my precious free time into computers. Why does software often fail to gain acceptance, respectively why does it become successful? Availability.
The only Lisp which works is CCL but when I tried to build SBCL with it, the build failed spectacularly.
I then went to use CCL but all the getopts examples are for SBCL and since I'm still learning Lisp I couldn't figure out how to make them work on CCL. So I'm busted.
Post scriptum: it's been around six months since I've opened those bug reports for i86pc and sparc and there are still no new releases:
http://www.sbcl.org/platform-table.html
I wouldn't have written what I have about SBCL and dismal support for Solaris if I hadn't tried to build, debug, package and research it and research throughly I did. As a professional engineer, the first thing I did was read all the documentation and all the INSTALL instructions I could find as well as any other documentation and bug reports I could locate using multiple search engines; the official documentation is very poor for such a big and serious project and in my opinion as an engineer, not very professional at all, especially when compared to corporate documentation efforts. This creates an additional hurdle for someone looking to master Lisp and do so using SBCL. Pity the two intense weeks of my spare time; what a waste of my life since I'm none the smarter or more knowledgeable for it.
I'm running 1.5.4 on NetBSD/amd64 and can build it on i386, sparc, ppc, arm and arm64.
How about ABCL?
> I wouldn't have written what I have about SBCL and dismal support for Solaris
Unfortunately, a niche language implementation & OS combination.
Never tried ABCL but will look into it when I get a chance.
That depends entirely on the Lisp implementation. Some implementations can do this easily.
SBCL supports using another CL implementation. One compiles SBCL with that other compiler and then in a next step this then can compile SBCL.
SBCL supports building with a few selected other implementations. For example I used recently a version of CLISP in the SBCL compilation process. That's described in the INSTALL documentation. CLISP is usually a bit more portable, since it is written in C and does not use a native code compiler.
I couldn't find a working version of CLISP for Solaris 10 for sparc and i86pc.
Guys, I've built hundreds of packages for Solaris 10 on both sparc and i86pc the number of which can easily compete with the number of packages on "OpenCSW" and I'm telling you that SBCL is so broken on the operating system from which it came that it can no longer be built or run on it without the involvement of the core SBCL team. It needs serious attention.
The usual reason that SBCL stops building is that something has changed in the OS.
[1] http://us-east.manta.joyent.com/pkgsrc/public/reports/upstre...
I actually patched that and got past it, half a year ago. The build broke somewhere else after that and it was in Lisp so I had no idea how to fix it. This breakage is just a simple endianess "pre-flight check". SBCL's problems are much more serious then this: they broke it but good.
It cannot be built from source on either of those platforms.
My TXR runs on Solaris (Intel x86, note). I roll a build for Solaris 10 for every release.
TXR Lisp isn't an implementation of Common Lisp, however.
I build on Solaris because by doing so, I can tick off a little mental checkbox: "[ ] Runs on at least one OS that has Bell Labs Unix DNA".
It's only x86 because I don't have a port of jmp.S for SPARC. A quick an dirty port could be done using setjmp/lonjmp, without delimited continuations. (Or maybe even with?)
I've had to debug a few things in the past that showed up only on Solaris. For that it was worth it to have that Solaris port; but the debugging was difficult without GDB. For instance, most recently, a GC-related bug (potentially affecting all platforms) only reproduced, by chance, on Solaris.
By doing builds on Solaris, you are ensuring your code remains clean and honest because Solaris and illumos are reference implementations of just about any open standard imaginable. If it works there, it's highly probable that the code is standards compliant.
For debugging, you can use dbx, which comes included with Sun Studio, which is a gratis download. If you compile with GCC, you'll have to use gdb. At least I couldn't figure out what Sun engineers did to their version of GCC to make it emit DWARF 2 debugging format.
Originally, I used setjmp and longjmp. The motivating reason jmp.S exists at all is that at one point I added delimited continuation support to the language. Delimited continuations are captured by copying segments of the stack into heap objects. Continuations are revived by copying back to the stack; but at a different location: the current stack top. Here is where setjmp/longmp became inadequate on Glibc/Linux systems. Glibc's setjmp applies an XOR mask to the pointers stored in jmp_buf, using a secret word (that is different with each process invocation). This is to make certain exploits difficult or impossible. But when we revive a continuation, we need to find inner pointers (from the stack back to itself) and fix them up, including the pointers in a jmp_buf. If these are masked by an XOR, that's a problem.
For any unsupported platform, the thing to do would be to try to just target the C library setjmp and longjmp instead of adding code to jmp.S.
The following applies to Common Lisp at least, if not others.
It is homoiconic and most implementations are written in Lisp.
It is very open, in that you can inspect existing structures from the REPL.
It has a long history and was the language where many common software paradigms were developed.
It comes with powerful builtin tools like a debugger with restarts where you can make changes to the system live.
The core language is very small but doesn't constrain what can be done with it.
I bet circa 1940's you would say the same thing about binary, and your question might be "why is X this interested in binary?"
Just as binary notation is a very simple notation that underlies all of computing, and has completely changed the world once an enthusiastic group of early adopters figured out how to leverage it, so goes Lisp. The details people haven't gotten quite right yet with Lisp, but once those are straightened out, imo, it will finally go mainstream like binary has.
Paul’s blog posts on the subject are useful background: http://paulgraham.com/lisp.html
You should probably start with this one: http://paulgraham.com/avg.html
It is a functional language, and functional programming is making a comeback as well.
There's a lot to it.
I work at a company that used common lisp all the way down.
In general though, lisp is a functional language.
ii. It's properly a family of languages, and they usually have "Lisp" in the name (plus Scheme, and now Clojure -- still a small enough set you can remember them all). The Algol family of languages don't all have "Algol" in the name, and the Simula-style object systems don't all have "Simula" in the name, even though both of those are extremely popular today.
Update: Thanks for all the replies, makes sense. Why downvote an honest question?
> In May 2009 O'Reilly agreed to publish a book about Common Lisp, and I agreed to write it.
It isn't less worthy if you're looking for an article about the book, but 2009 or 2019 is definitely relevant to whether I'm interested in reading it.
I'd say typically in software, once something is beyond about 5 years old - a library, a resource, a language version - it's very important to be aware of that as your decision to use that thing as-is needs to take that into consideration.
Maybe you decide to use it, maybe not, but you're always better off knowing when it was produced going in than not paying attention to that.
Title was: "O'Reilly agreed to publish a book about Common Lisp, and I agreed to write it"
> I feel like hackers cling to the “if it’s not new, it’s not worthy” paradigm.
is incorrect and reeks of an accusation of elitism which is not fair in this case.
Hardly a trait exclusive to hackers.