Why is HN this interested in Lisp anyway? Not saying it's a good or bad language, just don't quite get why it receives as much attention as it does.
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.
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.
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/
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.
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.
Lisp was already 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.
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
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.
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.
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.
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.
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.
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.
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.
I'm running 1.5.4 on NetBSD/amd64 and can build it on i386, sparc, ppc, arm and arm64.
It cannot be built from source on either of those platforms.
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.
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.