There's plenty that's worthy and new-to-me even if it's years or decades old. We're sophisticated enough to recognize that but still find the context valuable.
Some people cling to it more than others. The date is usually added for context around articles where context in terms of time matters (such as this one)
I wouldn't say it's about not being worthy, it's just very valuable context.
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.
In addition to context, quite a few things end up getting reposted to HN after having already topped the list years earlier when they were new. That's fine, but you can get confused if the headline makes you think something happened twice.
There's a difference between an honest question and the "I feel like hackers cling to the..." bit, which is an entirely unfair accusation. Not once have I seen a post negatively commented on just because of its age. Old posts are far more positively received here than elsewhere, and you'll often see a comment linking all previous posts because each time it's posted interesting discussion has come up which shouldn't be ignored.
I can see how it may have come off that way. It was my first thought as I’ve seen people get pretty exited about the new—rather than the old. Some thoughts are better kept to the self.
To your question re: why the downvotes (I wasn't one of them): it was an honest, but not very good, question. You essentially misunderstood the main focus of this site (Hacker News[1]) and asked, in a way that likely came across as pejorative (i.e. 'cling'), 'why are people so interested in the news at this news discussion site?'
Oh really, that's interesting. Is that sort of info widely known among the HN user base and I'm an ignoramus or is it a case of some of the users of longer standing being vocal about Lisp?
I would guess that the majority of HN users never even think about the fact that the site is affiliated with Y Combinator and its associated personalities.
I'm well aware of the start up incubator link, but you're definitely right otherwise in my case. When you get here it just looks like a nice lil' news site!
Quite likely, but also something users that have been around a long time might not think about. From my understanding, in the early days of HN the link was a lot closer (content-wise, pg participating on the site, ...)
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. ;-)
They didn’t sell well. It doesn’t matter how interesting or important a topic is. Eventually a publishing business has to decide on what their limits are for risk/reward. O’Reilly had decided that Lisp books cost too much and brought in too little for them.
> Is that sort of info widely known among the HN user base
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.
Before today I did not know who Paul Graham was, what he had done or the lispy association to HN. Then again, I'm a few thousand miles from the Bay area and not much of one for keeping track of personalities in any field. Though I am of course interested in things 'tech' related for both work and personal reasons. Am I really in the minority of HN?
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 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.
Even if you give LISP a role, one also has to consider that it was a time when the most popular languages (C++, early Java, Perl) were pretty low-level and not at all web-friendly or async-friendly. LISP could bridge that gap because it makes it very easy to build DSLs and "go up" in abstraction with minimal fuss. If you start with Python or Ruby and their popular frameworks, these days, most of that work is already done for you.
New languages are coming out all the time. For every one like Python that proves to have serious staying power, there are dozens of others that slowly stagnate. It doesn't typically make sense to bet your business on a new unproven language; you want to use something that's already been around for awhile, clearly has staying power, and has a decent community built up around it. Lisp has fit that bill for decades now. At the time of Viaweb's founding, Python was not there yet. The closest thing that was would've been Perl.
When Alexis Ohanian gave a talk at Google in 2013 I asked him afterwards about converting Reddit from Common Lisp to Python. He said the Common Lisp version crashed too often. He even made a funny comment about this when he autographed Without Their Permission for me.
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.
Do you know of any good setup for type-aware autocompletion of Haskell? There are some language servers for it, but it's difficult to get them to play nicely in the face of updates and such.
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.
I doubt crashing had anything to do with lisp -- the site crashes hard at least once every week.
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.
I don't think "HN exists because of LISP" is the reason that Lisp posts are popular on HN today.
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.
That's not what pg has said. He said lexical closures were critical to Viaweb's success, and no popular language offered them except Javascript, which was decidedly not a server language in those days.
I was wondering the same thing. IIRC I found hn without having a clue about either Lisp nor about Startups or YCombinator.
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.
Because it can easily solve or altogether eschew a lot of the issues that object-oriented JavaScript developers are struggling with and that's barely scraping the tip of the iceberg of problems which Lisp doesn't suffer from.
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.
I'm a private person in this capacity, so paying someone to reverse the breakage is out of the question. It's an outrage that something like that was allowed to happen in the first place. If this were my software, not only would I fix it immediately, but I would be deeply ashamed of myself for allowing it to happen. We as programmers should start taking responsibility for our actions.
I would if I knew how; it sure wasn't for lack of my trying to do so, but I don't know enough to pull it off.
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.
If none of the core SBCL team use Solaris then they won't know that SBCL doesn't work on it.
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.
I've left as much information as I could, but nobody even bothered taking on the bug. The other bug was "fixed" but no information was provided on when it will be rolled into the next release, so that's not useful either, especially since Lisp cannot be built without a working Lisp first, which doesn't work now, so I've no way to test the fix.
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.
There are regular SBCL releases, something that is fixed will appear in a month or less. If you don't have a working SBCL you can bootstrap it using CLISP or cross-compile from a different OS such as FreeBSD.
CLISP doesn't work on Solaris either and I've no FreeBSD nor the spare time to figure out how to get it to work.
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:
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 get an existential crisis when I read "niche implementation" in the context of one of the most important operating systems which changed computing forever and which is a reference implementation for just about any open standard imaginable and that on an IT site full of IT professionals.
Never tried ABCL but will look into it when I get a chance.
> since Lisp cannot be built without a working Lisp first
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.
SBCL documentation states that it can be built with another Lisp, but that is not true: I've tried with CCL and it failed spectacularly.
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.
CLISP should build from source, it seems to be getting built fine by Joyent pkgsrc bulk builds. Their build of SBCL is failing in C code [1], maybe a Solaris expert could fix this.
The usual reason that SBCL stops building is that something has changed in the OS.
But nothing has changed on my build servers which are running Solaris 10, so OS change cannot be the cause; without additional information, that leaves us with one or more breakage(s) caused by someone in the core SBCL team.
I sure did: it's due to changing the code but not using the correct macro definitions and compiler options from what I could see (I'm on a mobile telephone, on vacation, so lots of the log is cut off). But you also have to realize that Solaris 10 is much older than illumos and I'm telling you that the build breaks on both.
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.
SBCL is not alone in neglecting Solaris. For instance, the GNU Debugger is not usable on Solaris any more. And it won't even read core files post-mortem. There is an open bug for this, unsolved.
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.
I might be able to help you with jmp.S since I know SPARC assembler.
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.
Knowing assembler isn't so much a problem; I wrote the PPC and ARM variants in there without being versed in ARM or PPC assembler. I just don't understand the SPARC register windows well enough to be confident it would work.
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.
A lot of people (notably the creator of YCombinator and HackerNews) are arguably "in love with" Lisp.
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.
Because Paul Graham, who founded Y Combinator and by extension Hacker News, loves Lisp. He used it as the primary language at Viaweb (basically late 90s Shopify) and viewed the language as a key enabled of their success.
Lisp the language has "code as data" which other languages are just catching up on. Basically, you can generate code using formal code, not a pre-processor
Independently of the connection between PG and Lisp, many engineers are interested in Lisp because it's one of the simplest programming languages that is closely connected to the Lambda calculus.
Is the second programming language to have existed, and it is still used for some applications. It has some unique properties, including _code is data_.
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.
i. From the Jargon File: "The dominant HLL among hackers until the early 1980s, LISP has since shared the throne with C." Even though it's not the dominant HLL today, it's been around for 50 years. There's a lot of area under that curve.
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.
Lisp is an interesting programming language. Some have strong opinions that it's a good one as well. I personally think it deserves more attention than it gets and the more mainstream languages usually get more attention than they deserve (like Go for example).
I know Mike. He was editor of my first book and I still deal with him. He’s about the most standup guy I’ve ever worked with. If you’re thinking about writing a book, pitch Mike. I can’t recommend him more. I needed help with having the confidence to get my thoughts down on the first book and he coached me through it.
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.
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.
> 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.
... 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.
I hate the dummies books too. People that consider themselves intelligent don't want to buy a book that forces you to call yourself a dummy. I'm saying there is another space for people that feel they are intelligent and don't yet have the knowledge about programming and could do it given the right introductions.
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 think you're right about this. I'd much rather read LISP for Poets or LISP for Future Presidents than something with a title that is insulting or degrading. There's probably a considerable market for books that educate and respect the reader.
That's a great theme. Programmers have a different set of aspirations than most people, so making books that speak to both a different aspiration and teach tech seems like a winner of an idea for the rest of the people out there who don't identify as a nerd.
The old "For Dummies" books were very respectful if used self-deprecating humour on authors side often. The polish term used to translate "For Dummies" was a bit better IMO, though not exactly translateable.
Oh I did not mean to say I hate the Dummies series. I had picked one up, something on personal finance if I remember correctly. I was quite pleasantly surprised that the author did not speak to me as if I am a dummy.
That's my experience with them as well. But, I've resisted looking at them even knowing that because I resisted calling myself a dummy. They are huge sellers, so I'm in the no minority with that opinion obviously.
To second rjurney’s comment, I’ve also recently had the pleasure of working with Mike Loukides, and his feedback has always been hugely insightful and valuable.
129 comments
[ 0.16 ms ] story [ 306 ms ] threadUpdate: 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.
[1]https://www.merriam-webster.com/dictionary/news
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.
[1] http://www.paulgraham.com/avg.html
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
E.g. https://crypto.stanford.edu/~blynn/lambda/lisp.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.
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.