Why I like Common Lisp
p-cos.blogspot.com
p-cos.blogspot.com
Note that for the above effect, it is irrelevant what Lisp you choose. Yes, it also applies to learning any additional language, but because Lisp is a different breed altogether (as opposed to Fortran-derived languages), more value is to be had from the diversity.
I used to be a huge fan of Common Lisp (even wrote my own series of blogs on why I love it a few years ago) -- still use it in my daily work -- but I came to realize that it's not perfect. There are many things that Clojure has improved upon, e.g. consistent accessor methods, shared immutable data structures vs copying, and probably many more once I dive deeper -- there's a reason why even pg started recommending Clojure over CL or Arc.
I've been coding in Common Lisp for about 3-4 years. Even the algorithm of my startup is written in Common Lisp. There are definitely moments of sheer joy when I switch back and forth between Javascript and Common Lisp. But also moments of annoyance... sometimes certain algorithms are just more naturally imperative, and CL makes it hard not to write recursive.
tl;dr learning a Lisp is highly recommended. It does not matter which flavour. Or just go read SICP.
Say what? Are you sure that you don't mean Scheme? CL has LOOP…
Oh gawd. The biggest wart on the language.
Let's just agree that it's controversial :-)
Still the point is, that Common Lisp prefers iteration by loop-like constructs (or higher-order mapping) to recursion, due to the lack of TCO in the standard: DOLIST, DOTIMES, DO, DO*, LOOP, MAPCAR, MAP, ... Many people prefer the design of the ITERATE macro, but LOOP is already included.
The only people who need to worry about TCO are those writing portable libraries. Everyone else can assume it, at least for local calls, which represent 98% of the times that it matters anyway.
Almost. It's just that that many implementations support it (ABCL not) and that the language does not support it. TCO interacts badly with many Lisp language features: dynamic binding, unwind-protect, ...
> Everyone else can assume it, at least for local calls, which represent 98% of the times that it matters anyway.
If the right optimizations settings are set.
I've never understood this claim. I mean, I understand the technical point: that use of dynamic binding or UNWIND-PROTECT creates a barrier in the stack across which TCO cannot be done. But in practice it seems to me a non-issue. I can't recall ever, in 35 years of Lisp hacking, wanting to write a tail-recursive routine that used one of them on each iteration, in such a way as to cause unbounded stack growth. It just doesn't happen, at least not to me.
Maybe that's partly because I try to keep my usage of dynamic binding to a bare minimum. I think some people overuse it.
http://0branch.com/notes/tco-cl.html
Btw., Symbolics Genera also did not support TCO. ;-)
I'm well aware that the LispMs did not do TCO -- I owned several (starting with a CADR) and still have an XL1200 rusting in my closet :-)
On the other hand, if you want to write more functionally, CL also now has shared immutable data structures. Check out FSet: http://www.ergy.com/FSet.html
I won't say it doesn't have its warts: the namespacing and packaging systems are kludgey, and the extensibility of built-in operators is poor. It's a dynamic language to boot, which implies type derivations are often estimates at best (painful sometimes on a poorly tested codebase).
But, Common Lisp, above all that, is an integrated development system which allows live and fluid development. I can't stress enough that it is a deep and joyful technology which lets me achieve more faster in it.
I only wish there were jobs in it. :-/
Common Lisp has under 10 employers in the US/CA, as far as I can discern: Clozure Associates, Grammarly, 1? 2? defense contractors in the Seattle region, ITA (now owned by Google), a company in Colorado, D-Wave in Vancouver, BC (Canada), and a handful of very small consulting-type shops. Occasionally there are some university jobs that come up, usually in Boston area.
I've been monitoring things for a while, and the prospects are dim. Suppose I'll just have to run my own business, eh? :)
But once you start building APIs or web apps, it falls extremely short for lack of community and open-source libraries/frameworks.
This is one area I'm hoping to improve. I've already built the ORM, auth system and template engine. Now I'm doing the web framework, pretty soon the admin panel, then a couple of pretty project sites and i'll be on Hacker News.
Keep up your stuff. After stumling on your work on that strictly-typed LLVM lisp and your cmacro system, I find your work very inspiring and make me want to focus. You and Fukamachi (did I get his name right? the guy working on cl21 and the Caveman web framework) are doing really cool stuff for the CL FOSS community right now.
[0] http://arclanguage.github.io/ref/evaluation.html
[1] https://github.com/malisper/Clamp/blob/master/experimental/s...
Actually its not very fancy. I basically live in a live CL image, have some emacs key bindings which invoke a simple CL job system (EVAL in a thread). I can shift-right-click things to get a menu of actions for that type of file and plain-right-click to run the VIEW action for that type of file (as a job in CL).
http://i.imgur.com/2b47mII.png
I have a QUERY function which is hooked up to Recoll (full text search). I have the HTML ANSI CL draft under /usr/doc/ansi-common-lisp/ and HTML versions of all manpages under /usr/doc/man so finding documentation is quite nice. E.g. I (query "defun") or (query "gethostname") and get a sane list of results.
I have a markdown like language in which I write all my documentation, its media independent and has backends for plaintext, html and LaTeX output. I want to release it soon but well...
There is the SH DSL for executing UNIX commands, the PIPE macro for doing things like (pipe (sh hostname) (read)) (just a silly example).
My web server is open source (telnet to mr.gy on port 80). Its mostly "cute", not something you'd run on a large site.
My time with UNIX also made me fond of text files so a lot of my "stack" is optimized for plain text interfaces (e.g. the email client started because I didn't like the directory structure of maildir). Also I wanted my mail in a git repository.
> Did you build this all from what you thought you'd rather use
Kind of, its a compromise between what I wanted (a CL OS, optimized for simple text interfaces and CL hacking) and what was in reach. At some point I decided to go the path of least resistance, move my CL stack closer to the UNIX/Slackware stack and reuse and integrate as much open source software as possible.
The result is a very thin layer of CL and Elisp code and some CL apps which combine to a UI I feel comfortable with.
It is very encouraging to see you work and I really need to get up to speed on the Lisp.
Also, I am a Recoll fan too. Great stuff!
Have you considered inferior shell for unix commands?
Does your markdown resemble scribe from racket? I have been considering doing that.
https://www.openhub.net/languages/compare?measure=contributo...
If you mean the overall Lisp family, I think it's more clearly on an upward swing, especially due to Clojure's popularity (and if you're willing to stretch, Julia smuggles a Lisp-like language under cover of Matlab-like syntax).
cll was rabidly against OSS, e.g. Pitman's pure hatred for it was practically Gospel there.
A few years ago some younger Lispers emerged, for who OSS was natural, just like with the short Ada renaissance.
At least the "young Lispers" are still there, unlike their Ada counterparts, even if they haven't taken over the world.
While Clojure is definitely more a in-thing right now, it's nice to see "the originals", where it all came from. There are several things Clojure does really well, at the cost of other aspects. It's a very opinionated language, and for some, it may be too opinionated. I find idiomatic Clojure-code to be a bit on the too terse side, affecting the clarity of the code.
Let's also mention the JVM. While this is often used as argument for Clojure, it can also be an argument against it. Now your application needs a JVM to run. That excludes my Raspberry from ever running it, unless you find 30 seconds+ startup time to be acceptable. I don't.
Looking into Scheme, you will definitely appreciate the simplicity of the language. Unlike Clojure, there's no magic behind the curtains. What you see is what you get, and yet it's still so capable. That's quite eye-opening and magic in its own right.
Scheme however isn't a standardized language, like Common Lisp. In that regard you cannot guarantee that what works in one Scheme-implementation works in another. With Common Lisp you can do that. And from that point of view, it makes sense to have a good story on modules/packages. And Common Lisp has that. In plenty.
In Clojure, with Leiningen, you can easily declare what dependencies you have and have those fetched build-time without any extra work what so ever. Sounds good, eh? In Common Lisp you can do that in ordinary code, runtime, even in the REPL. Your code just declares what it needs, and it's there. Just stop a second and think what that does to extensibility, when software written in CL lets you plug your own code in.
All in all, once you know a LISP looking into others is much less work. And as such, you should definitely check out others. Maybe there are other LISPs which suites your needs even better? Unless you look around, you will never know.
Scheme is a standardized language. The first standards defined a relatively small language, also useful for teaching purposes. Then it was tried to define a more modern Scheme with a core language and a library. The R6RS standard was kind of controversial and now there is work for quite some time on R7RS. Additionally the Scheme community has a process to define extensions. Generally the landscape of Scheme is quite a bit more fragmented than the CL landscape. The implementations can differ widely in their implemented language. But if you look at individual systems, Scheme systems have to offer quite a lot. Also, historically there are a several really excellent Scheme books for learning programming and/or computer science.
This site, news.ycombinator.com , actually is written in a Lisp dialect (Arc) running on top of a 'Scheme'.
Armed Bear Common Lisp http://abcl.org/ is a JVM Common Lisp with this feature.
Am I missing something about Common Lisp?
The sum total is that the complexity of CL vs. Scheme may not in practice be all that different. Take a look at newer Scheme standards, R6RS, R7RS, the SRFI's, and implementations like CHICKEN to see what I'm referring to.
Still CL and Scheme are different languages, each has its fans. It does seem to imply that the stuff it takes to get the job done is more or less independent of language, whether it's included with the base language, or contained in modules or libraries, the features need to be there somewhere in some form.
One thing I still find true: Common Lisp has much more useful functionality in the core. Thus the core and the libraries are often actually using them.
Example: by default Scheme has poor argument lists. Thus a lot of code does not use keyword args and the compiler usually does not know about that.
Another example: Common Lisp has a standard object system. All implementations support it and some use it extensively. In most extended Common Lisp much of the libraries is using CLOS: conditions are CLOS classes, I/O is based on CLOS, etc.
Where it matters is how well the functionality is integrated with the core language. The argument goes that in Scheme it is less regularly the case that libraries are complete and consistent vs. CL.
The effort of the R7RS-large work group to create a "standard" library of extended functionality is ongoing, but in a year or two should produce a language standard that could create consistency across Scheme implementations, effectively similar to CL.
Of course, how well that works out depends on the willingness of implementors of Scheme to make it so. Let's hope that they will do that.
Although Scheme has a handy "do" procedure for iteration (somewhat like "for" in C), it's quite possible it's not used as much as it could be.
Most Schemes also offer "unhygienic" or low-level macros, though there's a learning curve for it.
I agree Scheme IDE support is marginal, but editor support is fine. Haven't really missed SLIME or other IDE. Compiling Scheme to native code is for me a different workflow anyway.
Lisps are also much better at reflection than the MLs. In Common Lisp, you can rebind function symbols from a backtrace, and then carry on as if nothing happened. Changing a class definition updates every instance in the system to conform to that new definition, which makes interactive testing a joy. You can get hold of your namespaces as Lisp objects and interact with them as any other data structure, and see the effects reflected correctly in your runtime. CLOS is the peak of this sort of thing. And most lisps allow you to save a snapshot of the runtime image, which is awesome.
The MLs were originally written in Lisp, and inherit some of these features, but Ocaml, not so much. Still, I love Ocaml.
But one important thing is that Lisp is its own meta language. With OCaml there are changing and competing meta languages as far as I understand (camlp4, MetaOCaml). The simplicity of the language and meta-language being the same leads to a totally different style of programming.
I realize that you can probably optimize your Lisp code a lot more than you can your Clojure code since Clojure is on the JVM, but right out of the box Clojure performs as well as naive Common Lisp, so its probably a more attractive Lisp for most beginners.
The closest thing to that is probably the common-lisp.net website, and that's just an unfinished barebones Bootstrap example.
I've been meaning to design a better one, but that's going to take some time.
I think as a language it deserve the reasonable praise it gets and certainly a beautifully designed language, powerful and yet flexible. I enjoyed very much coding in it and with the help of lispers I was introduced to a language / environment I fallen in love with Smalltalk , Squeak and now Pharo.
Check this out https://github.com/hylang/hy
I remember learning Lisp and all that reverse polish notation was very unorthodox to me.
http://www.gigamonkeys.com/book/
You can start writing simple programs in a weekend. The learning curve is quite gentle.
println("some text")
(println "some text") sum [a,b,c,d,e]
It's just neater, especially when you format as
sum [summand1
,summand2
,summand3]
I really, really want to answer this, but it's worthy of a chapter in a book. May I summarize instead?
1. Lisp syntax is tree syntax.
An expression such as this:
(+3 (* 4 5))
+
3 *
4 5
3. Lisp has little to effectively no syntax. Since all forms (outside of special reader forms) are in simple lists/trees, you effectively know all there is to know about reading Lisp. (Although, you do need to understand the Triforce of Functions, Macros, and Special Forms, but they're worthy of their own chapters to explain. They're still lists, though.)
4. The nodes[1] of a Lisp tree are also their own data structure, known as Cons Cells[CC]. These allow for easy manipulation and construction of trees, as well as easy recursion by poping off the first part of a cons cell, processing/consuming it, then sending the rest of the list back into the function. Essentially stack-like processing of lists. So while recursive functions can be rather ugly in other languages, they're rather elegant in Lisp, and easy to work with.
Jeeze, I can probably keep going, and adding more and more points and elaborating on their purpose, but it'd be better to just study Lisp on your own instead. I only know cursory Common Lisp, so I can't recommend any books or sources, but I can instead recommend learning Clojure. "Programming Clojure" has been stated to be a good starting book, but I've mostly read "Clojure Programming" from O'Reilly and "The Joy of Clojure". These are also good books, but I'm not sure which is best for beginners.
[1]: Okay, to be more pedantically accurate, Lisp 'trees' are just cons cells linking to more cons cells. It's a bit unweildly to think of all Lisp expressions as cons cells rather than nested function calls or trees. [CC]: http://en.wikipedia.org/wiki/Cons
It does take patience to "get used to it". The effort of "getting over the hump" is amply rewarded--one way is the benefit of seeing how marvelously consistent and predictable the notation proves to be. IOW it's a great simplifier, allowing humans to mentally read, parse and understand Lisp code.
To me the great genius of Lisps is shown by the experience of looking at work I'd done months or years ago. Stuff I'd written before in C would often be obscure to me later, especially when I hadn't made enough comments to "explain" what the code was doing.
In contrast, it's much easier to understand my old Scheme programs, often just minutes of review will do it. Sure, I'm talented at making things convoluted, it's just harder for me to do that with Scheme, and no doubt that's true for Lisps in general.
I've looked at Clojure a bit, my impression is it's syntax is more complicated than Scheme. At least there are enough differences that it would take some effortful study to become fluent in Clojure. Not a criticism of the language, but suggests making the transition isn't trivial. Perhaps that applies in both directions.
It's worth adding in the domain of constructing web servers, the list notation of Lisp maps extraordinarily well, and easily, to the hierarchical markup of HTML. It's a feature I've exploited extensively, and I think it could provide better and simpler tools for web programming if employed more widely.
https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/...
What a step back from my Symbolics Lisp Machine, where the infix reader was included...
For example, one of the important capabilities mentioned in the article is getting close to the metal with profilers and hand tuning code and the runtime environment. Yet none of the links discuss this directly or provide tutorials.
The discussion about the wonders of CLOS suggests reading The Art of the Meta-Object Protocol - a $35.00 345 page dead tree tome which Amazon will get to you in about a week if you opt for free shipping. Graham's Ansi Common Lisp is of course even more obscure - it's been out of print for years and from Amazon you're in the realm of individual sellers [my anecdote is that it took about a month to get the copy I ordered - the seller was a nice person but it was a couple of weeks before they read their email from Amazon letting them know someone had purchased their copy].
The author goes on to recommend LispWorks as a platform. It's $1500 for 32 bits in North America and $4500 if you want to use all 64bits that your OS probably runs under. Sure there's a free version, it's 32-bits, not licensed for commercial work, and crippled. Don't get me wrong, the free version is probably fine for playing around with, but this article targets people for whom tuning the heap and GC are appealing, and this tends to be a professional rather than hobbyist market segment.
The "early Web 1.0" vibe is unfortunately common when the Common Lisp community attempts to promote Common Lisp. Let's face it, the linked Lisperati site looks a GeoCities page [a good one]. The LispWorks page requires four clicks to get to the price of non-crippleware. The author's own guide links to academic papers and black and blue on white websites.
The issue is that the Common Lisp Community is not just sending signals that most of the potential market ignores, it's that it is sending signals that turn the potential market off. I will unequivocally say that crippleware is no longer a viable approach to achieving significant developer mindshare. The landscape is open source and $4500 a seat [and calling it Enterprise Edition] is only going to hit some [potentially profitable] edge cases.
Of all the places accessible from the author's post, the only one that looks in touch with the present is the original article on BlogSpot. Everything else screams "This ain't for you" at most people.
It makes Racket look hip. And that's hard to do.
* you don't need to read AMOP to use CLOS. It's there if you want to know 'MORE'. Much more. Much more than you ever wanted to know about reflective OOP. Alan Kay of Smalltalk fame recommended the book as the best book on objected-oriented technology in a decade. ordering it over your book store is easy. But I don't recommend it to anyone wanting to learn Lisp. Read it if you want to know how CLOS is implemented or extended. A bonus point: it shows excellent coding style.
* 'Yet none of the links discuss this directly or provide tutorials.' The LispWorks, SBCL, Clozure CL manuals discuss that. Since there is so much stuff to link to, I recommend to go fully old-school and read the fine manual.
* as the starting book most will point you to Practical Common Lisp by Peter Seibel. Free online and available printed. It even explains a lot of CLOS.
* 'The author goes on to recommend LispWorks as a platform.' I do that too. Not the free version. The full commercial version. I even have the full 64bit 'Enterprise' version of LispWorks on my Mac.
* Web 1.0: Even worse, a comic book about Lisp programming using Common Lisp. http://landoflisp.com
* '$4500 a seat [and calling it Enterprise Edition] is only going to hit some [potentially profitable] edge cases.' - well you may want to compare what a commercial Smalltalk, Ada or Prolog system costs... The market is small and lowering the cost would help letting the company survive. Something must be working for them: LispWorks was first released 25 years ago.
* 'Everything else screams "This ain't for you" at most people.' - well, Common Lisp is not for most people. For most people there are many simpler options. For those wanting to work on fancy Web X.0 stuff in an easy way, there are better options - and that's totally okay.
Common Lisp is not for most people.
For those who want to use Common Lisp as free and no-cost software, the article mentions 'Clozure Common Lisp' and 'SBCL'. I'd say that's excellent choices. I use those, too. Still I prefer the commercial and expensive LispWorks...
Certainly not. The AMOP teaches you CLOS assuming you already know CLOS. In the words of Edmund Blackadder describing Johnson's dictionary, it is the most pointless book since "How to learn French" was translated into Fresh. And therein lies its brilliance.
Don't get me wrong, 4500 bucks is probably a bargin. But again the landscape is dominated by FOSS. More to my point the points of comparison are pre-www. Ada, Smalltalk, and Prolog as alternatives suggest a time before twenty-something developers' parents were in college. Those languages were hot at the same time as Lisp Machines. Was an opportunity missed to mention Modula-2 and rotary dial telephones?
The Common Lisp community doesn't handle onboarding well. Seibel's Practical Common Lisp is ok, but how long has it been since CD's were an important recorded music medium for people spending their time with computers? Well over a decade since the days of Napster. Coming up on a decade of iTunes. CD's are more old-school than landlines.
This is to take nothing away from Common Lisp as a language. It's not a knock on the individuals who make up the Common Lisp community. It's pointing out the Common Lisp community's blind spot. Mcarthy was brilliant. He also could have been Rich Hickey's grandpa. We don't make phonecalls on party lines anymore.
Figuring out how to reach the next generation of programmers doesn't require compromising on principle. It does require recognizing that what didn't really work in the past [that is the past since the days when Prolog and Ada were hot, e.g. since C++] probably won't work today, either.
I mean, what's the case of Common Lisp over Clojure? And by that I mean:
+ point me to a webpage that sells me on the idea
+ has a clear call to action
+ and looks at least as vibrant as Clojure's homepageAs for concerns about the ecosystem, you are going to have to elaborate.
[0] http://t20846.lisp-steel-bank-development.lisptalk.info/1-0-...
As I said, Common Lisp is not for most people.
This Web 1.0 page describes the concept: "Teach Yourself Programming in Ten Years" http://norvig.com/21-days.html
> But again the landscape is dominated by FOSS.
Which landscape? There is not one landscape. Is Apple's XCode FOSS? Windows dev tools? Open Source?
If you believe in FOSS, you can use SBCL, CMUCL, CLISP, ECL, MKCL, Clozure CL and several others. I use SBCL and Clozure CL.
> CD's are more old-school than landlines.
Write games with Land of Lisp then. But sorry, the Common Lisp community is not large enough to rewrite books every so often. In the mean time there are classics like Peter Norvig's PAIP, which are even older and even less exciting. Still it is easily one of the best programming books ever written.
> Ada were hot
Ada was never 'hot'. It is a tool used in a lot of mission critical software.
> I mean, what's the case of Common Lisp over Clojure?
I think you have to find that out yourself. Don't be sad if Common Lisp is not for you. Few people drive a Mercedes Unimog, though Arnold Schwarzenegger had one. http://i.dailymail.co.uk/i/pix/2014/09/04/1409847539952_wps_... You might ask what the Unimog does better than some Toyota, why it costs so much and why so few people have one. If you might spend some time, you might find out what the Unimog is, why it exists and who uses them for what...
This won't really do anything to bring people closer to Common Lisp.
This is a bad thing btw.
Thanks.
Seriously reading this thread makes me so happy that we don't attract these douchebags.
Edit: friendly fire, sorry
Especially since "brudgers" states his case with arguments and politely and has not sweared at anyone.
So yes, I consider it douchey to open a completely pointless debate where there could have been a constructive discussion about the strengths of CL.
That doesn't warrant a "douchebag" stamp.
Plus I don't think the word "douchebag" or "douchey" os appropriate for a discussion among people that are not 17-year olds, 20-yo tops. There are far better adult swear words available if needs be.
> Which landscape? There is not one landscape. Is Apple's XCode FOSS?
Xcode the IDE is not. The Clang/LLVM compiler, LLDB debugger and many of the other tools are open source.
Apple's Cocoa is not FOSS, for example.
For example, it can be like beef liver. It's not that I don't eat it because of a commitment to vegetarianism. I'm not a vegetarian and I'll gladly eat rare cow on a bun. It's not that I don't believe beef liver is nutritious. I just find eating beef liver an inherently unpleasant experience. It's how I feel whenever I try to use Python [even though it is quite likely more popular than beef liver].
There are also languages which aren't right for me because they don't really fit with what I want to do. Swift for example is only available on the OSX platform and I don't own a Mac.
Neither of those apply to Common Lisp. The reason Common Lisp isn't really for me is that there are simply less painful alternatives for the sorts of things I want to do. And one of the ways in which those alternatives are less painful is because of their communities.
It's not that language communities shouldn't be opinionated. I listened to DHH talk about Rails in the early days on an older Hansel Minutes podcast. The object is "person" and the table is "people". If that offends someone, then Rails might not be for that person.
But the Rails community gets to the point quickly. It lays out the facts and moves forward. Within that community it is not considered acceptable to say, "read this book and these five papers and drop a few thousand on commercial software, and then we might consider you worthy."
They tend not to tolerate that. But from the heritage of usenet.comp.lang.lisp that's still considered by some a perfectly entertaining way to treat novice questions in the Common Lisp community. Answering easy questions is dull and being snarky is an outlet for creativity in comparison.
In the end, my hypothesis is that programming languages live and die the same way as natural languages, either the community onboards new speakers and the language lives or it doesn't and the language dies [take this as a Kuhn paradigm if you prefer a reference point in science]. C remains vibrant as the language of Unix and its descendants. JavaScript thrives as the language of the web. Pascal and Algol and Simula are less than vibrant or thriving because few people are learning the language.
By analogy some members of the Common Lisp community often behave as if it's wrong for babies to babble, that toddlers should learn the alphabet by reading Faulkner, and that only then are they qualified as persons.
Norvig's article is about learning programming, not taking ten years to learn a programming language. Contrary to a portion of our dialog, he's a bit language agnostic.
It's a total digression, but if you don't restrict your population under consideration beyond "all humans", I would guess that's not the case.
Quite a few more people eat cow than program, so even if Python is significantly better liked amongst programmers than liver is amongst cow eaters, there's plenty of room for liver to be "more popular".
You totally distort the Common Lisp community and you post FUD. You attack Charlotte's preferences for no reason. She presented HER preferences. Still you attack the Lisp community as if individual opinions are not allowed and as if she speaks for all.
Chearlotte speaks for herself and I think her recommendations are good.
There are a multitude free and open source implementations. Many were developed before stuff like Rails or Java even existed. Free and Open Source software has been written in Common Lisp from day one.
Clozure CL, mentioned by Charlotte. It is published on the LLGPL.
SBCL, mentioned by Charlotte. SBCL's roots go back to the early 80s as Spice Lisp and then CMU Common Lisp. Public Domain since 30+ years.
And many others. Usually people complain the Common Lisp has too many implementations.
Nobody required somebody to invest $4500 into a Lisp system to start.
It's just that some people in the Lisp community use the commercial tools and think they are great. I'm one of those. LispWorks is probably the best implementation of a dynamic language anywhere.
If people have actual problems with coding, they have multiple forums. I have personally answered 1000 Lisp questions on Stackoverflow.
> analogy some members of the Common Lisp community often behave as if it's wrong for babies to babble
Some non-members of the Common Lisp community seem to whine a bit too much for my taste. What the Common Lisp community (if there is one) does not really like is whiners who fail to contribute.
I have nothing against commercial tools. I've spent many thousands of my own dollars on shrinkwrapped bits over the years. That doesn't change the fact that shrinkwrapped bits are continuing to diminish in popularity due to thirty years of Stallmanism running in parallel with nearly thirty years of "greed is good" and even more years of a hacker ethos where spending 80 hours to pirate fifty dollars worth of software is a hobby.
Why care if the Common Lisp community likes me? It don't like most people. It would be foolish to its dislike personally. In fact, why blame them when Hell is other people?
The upshot is that I care enough to say something constructive. I don't wish the Common Lisp community anything but success. I'm not a jaded ex-lover. I hope it meets someone new and that someone turns out to be its soul mate.
[1] Going so far as to coin the term "love song to Lisp": https://hn.algolia.com/?q=love+songs+to+lisp#!/comment/forev...
A lot of it is. XCode's compiler, LLVM is FOSS. Microsoft just open sourced large parts of .NET libs and compiler. And there's also Mono, a FOSS implementation of .NET.
Plus, even the closed parts, like XCode and Visual Studio, are either free, have totally functional "community editions", or at worse are dirt cheap -- not $4500 to get to professional development.
>As I said, Common Lisp is not for most people.
You say that as if it's good.
It might be a fact, but it sure ain't good.
Is there a single good thing that can be argued to come from a language not being popular?
I meanbeside BS like "keeps the amateurs away?", which judging by the abundance of amateur Lisp code one sees, is not an actual advantage of Lisp...
http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
> You say that as if it's good.
> It might be a fact, but it sure ain't good.
Is it bad that not everyone understands Hegel or Heidegger? Does that make their writings less useful?
> Is there a single good thing that can be argued to come from a language not being popular?
It's not a question of good or bad. It's a fact of life that some things are less popular than others, which says nothing about the usefulness of the tool.
> I meanbeside BS like "keeps the amateurs away?", which judging by the abundance of amateur Lisp code one sees, is not an actual advantage of Lisp...
It's just that not every programmer has the intellectual capability to understand, master and use Lisp. That's a fact. I've seen that myself countless times at university in beginner's courses. Also many programmers don't need the features Lisp offers and are happy with other approaches. For them Lisp is too complex, too flexible, etc.
Lots of people can learn some basic Lisp or simple Lisp dialects. But once they use actual features of Lisp, which allows every user to radically change the language, the things get tough... in the industry stuff like that is not liked. They want tools and developers which are more predictable.
I think you should get over this 'popularity' BS.
Yes, actually. If they wrote clearly enough so more people could understand their point, their writings would be more useful. The point of writing something is generally to communicate with others, unless it's a personal journal or diary, meant to be kept private.
"It's just that not every programmer has the intellectual capability to understand, master and use Lisp. That's a fact. I've seen that myself countless times at university in beginner's courses."
Isn't it much more likely that the difficulties are more due to the fact they are beginners, than due to the language used in the course? Did you teach identical material using other languages, and found the students understood the material better? (Honestly curious.)
"But once they use actual features of Lisp, which allows every user to radically change the language, the things get tough... in the industry stuff like that is not liked."
Meta-programming in Ruby has the same challenges, but there is definitely a strong segment of commercial developers who whole-heartedly embrace those techniques. They didn't just give up and say "Oh well, guess we have to give up and go back to using Java", or adopt some complex about their language being too brilliant for other programmers to ever use. Instead, they put effort into persuading others the expressive power of Ruby is worth the tradeoff with predictability. They don't convince everyone, but they certainly managed to get a lot of developers on their side.
I think the Common Lisp community certainly could have accomplished the same thing. There's nothing about the language itself hindering broader adoption, or limiting it's use to academics or elite programmers. It's just the community that seems to want to keep it that way.
To be fair, it's just that no one cares to proselytize.
So, if LISP had them since 60 years and others got it 20+ years later than that, hardly matters by now.
That's what Hegel and Heidegger did. They communicated with others. It's just that their thoughts are more complicated.
> Isn't it much more likely that the difficulties are more due to the fact they are beginners, than due to the language used in the course? Did you teach identical material using other languages, and found the students understood the material better? (Honestly curious.)
The experience is that 10% of a course were able to write some Lisp. 40% struggled with the tasks, but made it somehow. The rest more or less did not get more than the basics and were confused by things like 'code is data', recursion for iteration, ...
> Meta-programming in Ruby has the same challenges
Meta-programming in Ruby is very limited to what Lisp does enable. Matz designed Ruby for 'ordinary programmers' (his words). Ruby lacks the whole Code-is-Data idea and on the OOP side, it lacks many of the features of a MOP, ... But it was designed that way.
http://www.matthewdavidwilliams.com/2008/11/06/rubyconf-2008...
Matz thinks that there is a cliff and Lisp is beyond that cliff for 'ordinary' programmers. 'Smart people just underestimate ordinarily of ordinary people'.
http://rubyconf2008.confreaks.com/matzs-keynote.html
> Instead, they put effort into persuading others the expressive power of Ruby is worth the tradeoff with predictability
What Matz actually did, was scaling down the language to dynamic OOP + some functional elements.
> I think the Common Lisp community certainly could have accomplished the same thing.
The Lisp community could have scaled down the language. People have done it: Standard Lisp, Logo, Dylan, Eulisp, ISLisp, Scheme, Clojure, ... Some were more scaled down that others.
Common Lisp stayed like it ever was: a language with lots of flexibility and extensibility.
> There's nothing about the language itself hindering broader adoption, or limiting it's use to academics or elite programmers
I've seen research programmers struggling debugging macros which were writing macros. There are code bases where I myself struggle debugging stuff... Common Lisp is great, but it offers so many ways to shoot yourself into the foot....
Well, here's a Hegelian thought for you: the demise of Lisp in the AI circles, and then in the industry means that wasn't not "real" enough (in the Hegelian sense), it was just a temporary transition phase till newer languages got GC, reflexion, macros, metaprogramming, etc.
Die Weltgeschichte ist das Weltgericht, as they say...
This is such a silly and elitist argument that I've always wanted to dismiss it outright on those principles, but I think it can finally be dismissed on factual grounds now that Clojure is a thing and is actually popular in the industry. The argument that people just can't get Lisp was always an embarrassing position to stake out, but now it no longer holds any water too.
Everyone has their own opinion as to why Common Lisp is having popularity trouble. Mine is that the spec is twenty years old and has no reasonable process for moving forward. I think a number of people are of the opinion that the spec represents stone tablets handed down by God and is completely perfect, but I on the other hand find a number of useful elements missing that are difficult or impossible to implement universally with macros. IMO, Common Lisp's popularity problem flows from its lack of evolution.
Calling an argument silly and elitist does not help your case much.
> Clojure is a thing and is actually popular in the industry.
The number of Clojure developers and its percentage is tiny. Far from 'popular'. It's also in a different stage of the hype cycle.
> The argument that people just can't get Lisp was always an embarrassing position to stake out, but now it no longer holds any water too.
You need to actually read what I said. Basics of simple Lisps are relatively easy to learn, still many people fail at it. I've seen it in computer science University courses where only like 10% were able to write anything useful in Lisp, struggling with recursion, graphs, dynamic typing, ... Few ever got so far that I would let them program macros.
If you start with the assumption that it's for "few people", and teach it like that, then few of your students will get it.
Yet, people have used Scheme and CL as a first language, and even Haskell, and students were able to pick them just fine.
No, but programming languages are not like Hegel or Heidegger. They have network effects, and they need a good ecosystem.
It's more like a political/state philosopher (like Plato, Marx etc) or a reform theorist. If he could not get people on his platform he wouldn't have the influence he needed to influence policy, which would be bad for him.
Besides elitist (which I wouldn't mind, if it was also true), this is quite false.
In fact I've seen more bragging and preaching than real world output that people care for from most Lisp advocates.
And even most of the things they are so proud of for building (with the exception of Emacs, which is also based on C), people have built in other languages and with more popular and full featured results.
>Lots of people can learn some basic Lisp or simple Lisp dialects. But once they use actual features of Lisp, which allows every user to radically change the language, the things get tough... in the industry stuff like that is not liked. They want tools and developers which are more predictable.
That's cowboy coder mentality stuff.
And in 2014, the ability to "radically change the language" is not that impressive. It merely boils down to: "Hey, my additions have the same syntax as native stuff and I can do meta-programming too". Sure, but first you have constrained yourself to a very specific syntax, so it's all a wash.
Prolog and Coq don't really feel like general purpose languages, they have very specific uses. Haskell and Common Lisp are general purpose languages, they are not meant to be used just for one domain.
What do general purpose languages such as Haskell and Common Lisp gain by remaining niche languages?
I'm genuinely curious. Sure - the community might be a bit more tight knit and the overall signal-to-noise ratio is a bit higher, but the overall output of a community 100x larger will always drown out the smaller one. And among the hundreds of projects out there at least some will certainly outshine the "polished to perfection" projects made by the smaller community. At a certain point the larger community will just have more quality projects than the smaller one.
So what does Common Lisp gain by purposely avoiding contributions? I'm genuinely curious.
Does it do that?
Contributions are welcome. It's just that it is not easy for most people to contribute to something like Haskell or Common Lisp. Many people just don't have the time or capacity to learn in. There are some people who learn Common Lisp because of specialized tasks (like composing music), but they have a motivation to learn a special tool.
There is nothing dismissive about it. It's not that many people need a language, where working on one of several meta-levels is the norm and not the exception.
Or, put more bluntly: stop being an asshole. It demeans you and what you're trying to champion.
It's not. Different people have different intellectual capabilities. Some can read Hegel, most don't. Some understand Monads, most don't. That's how it is. Some can debug compile-time macros, others can't.
> Or, put more bluntly: stop being an asshole. It demeans you and what you're trying to champion
A personal attack. Great style!
Chill.
Get some manners.
See the 2008 Ruby conference keynote from Yukihiro 'Matz' Matsumoto. He explains it in detail. Start at 8:40.
https://www.youtube.com/watch?v=vDnOBXD167k
I have interviewed many Java programmers in the past five years. I never found one who could explain how GC works, what lambda in Java 8 does, etc. There are a lot of ordinary programmers out there, even some of them with ten years work experience were surprisingly bad at actual programming. I hired some good ones, but generally the number of not so good programmers is high. Giving them a language where code is data, is a recipe for failure...
The reason they're "accepted" is that ultimately they make an ecosystem bigger. They want IDEs, linters, debuggers & other tools, books & presentations & trainings, libraries, services, etc - most of which are paid and which allowed better programmers to earn a living. Some of them - a minority - actually move beyond this newbie phase and contribute something useful. They make crappy and less crappy libraries, some of which might be used by "code wizards" when they need to do something (after all, does anyone except for the military, maybe, 100% audit the code dependencies they have?).
Let them come, be nice, and they will filter themselves out.
I have an additional question for this debate: think about a problem you'd like to solve while developing an application as a start up. What's the likelihood that your problem is solved by several robust libraries in Java and in Lisp? I'd bet that Java probably has several, not just one, high quality open source implementations of the thing I'm looking for - despite the crappy programmers you mention. By high quality I mean - at least decent code quality, good documentation, a lot of examples, discussions about it on public forums, maybe even commercial support, etc.
Because unless you are a hobbyist or a devil-may-care like professional, you want a big community, lots of resources, great libraries and tooling.
You might not need "most of the people" (majority or plurality) for that, but you sure need "lots of people".
A big community is an essential for basing whole businesses on a language and having access to everything you need in abundance (instead of several projects in various states of source rot, as happens for most unpopular languages) -- and it also doesn't hurt, infact helps very much, for the language lover that would stick to it even if he was the sole user of the language.
Then use a language which has that. There are a lot of big community languages with great resources. There is nothing bad about using those.
Lisp has several features which makes it slightly unpopular, but at the same time it is different enough, so that it survives and helps some people to express their ideas.
But since Haskell, Prolog, Common Lisp, etc, are designed for people who take their tools seriously and perform serious inquiries, they are generally incapable of casual pickup and use by the novice.
I've spent years in Common Lisp and can't recommend it enough for someone interested in a designed dynamic language (as opposed to Perl or Python). I imagine modern Smalltalk might have the same feel.
However there are books online as well, nowadays, if you really prefer to read on a screen. Seibel's Practical Common Lisp is a good starting point: http://www.gigamonkeys.com/book/
Several books for learning Common Lisp are online or for download:
* Peter Seibel, Practical Common Lisp, http://www.gigamonkeys.com/book/
* Common Lisp: A Gentle Introduction to Symbolic Computation, http://www.cs.cmu.edu/~dst/LispBook/
* On Lisp http://www.paulgraham.com/onlisp.html
It's just that these books are 'old'. Common Lisp is 30 now. But since the core language does not change much, the old books are still fine. They may smell a bit.
What I also take into account is StackOverflow. There are a lot of programmers who don't even read a page of google search results.
I will also say that from my time on HN, the number of people who read dead-tree technical books versus the number who read ebook versions of technical books may be less than dead even. They're cheaper [new] and services like Safari provide entire libraries at reasonable prices. [I've commented elsewhere in this thread on how Seibel's book exemplifies the some of the Common Lisp community's tone deafness].
http://stackoverflow.com/users/69545/rainer-joswig?tab=answe...
What I was getting at is that StackOverflow shows that many programmers in general tend to page fault into learning whatever language they happen to be using. This is a behavior which StackOverflow is explicitly designed to facilitate. It is also designed to facilitate the behavior in ways that are better than traditional Usenet and its web-based descendants in the form of fora.
It is expected that people learn a programming language and when they have actual programming problems, then they come to Stackoverflow.com.
One of the reasons that I listened to all of those podcasts is that I found Spolsky's and Atwood's ideas [1] about online communities insightful and was able to relate them to my experience in other online communities. I recommend them to anyone who shares my interest.
[1] and those of their guests and other team members.
Hey!
In particular, the new default CSS for Scribble is a vast improvement. But racket-lang.org isn't as sexy as clojure.org, and pending an influx of commercial cash probably won't be.
The Racket community tends to row in the same direction and does so by consensus, and that makes it's social structure potentially as hip as any open source project. If there was a Racket on Treads for building CRUD, who knows how much use it would see inside the local Starbucks.
Absolutely agree. The Lisp community could attract hundreds of new people overnight simply by learning a little CSS.
The one thing every other "hip and cool" language community has is that it has learnt that presentation matters. The people who use Python, Ruby and Node have all learnt this, but it seems most Common Lispers are perfectly happy with plain-old HTML pages that look like they were made in 1996.
I think that software deserves very minimal, functional and strict design. Accessibility over everything, uniformity over creativity. I "live" these design decisions for my business website and my products and I have attracted exactly the people I wanted to attract.
So I must assume that my 1996 design was the right choice for my customer segment.
On Lisp is definitely not a good beginners' resource. It's a great book in many ways, but I would never recommend it over PCL.
Lispers in general tend to have a fairly old-fashioned mentality (due, no doubt, to many of us being older) about many things. I think it's fair to say that there's much less of a sharing mindset, and much more of a closed mindset; the other way of wording that is that lispers are getting things done and making money doing them, not spending time updating community sites and sharing code (although there are some excellent open-source packages out there).
I'd really like to figure out how to build more of a Common Lisp community. The more I use it, the more I realise that it's a solid, professional, well-thought-out language for developing solid, flexible, reliable software. It's not perfect, but much of what looks like warts at first are actually features. Using it is the closest thing to expressing my thoughts as code. It really is a joy.
I think the low-hanging fruit is web design. Just touching up the CSS of library documentation would be very useful. Presentation is a lot more important than people think.
For example, compare [0] to [1], or Crane's website[2] with, well, the average Common Lisp library.
[0] http://eudoxia0.github.io/screamer/
The crane website I find utterly horrible. Reminds me of the typical Node.js or Ruby websites and that makes me shiver. A software library is not a consumer product. Design for a lipstick brand can not be used for an airplane company. Software deserves a professional "no-bullshit" design.
All three have a crucial mistake in common: Lines wider than 40em. A line must have between 8-12 words on avarage. And that is a typographic law, don't question it, we have known that since we wrote bibles.
The thing with "modern" web design is: I rather have no CSS then BAD design. And fact is 99% of all web developers are not worth their salt. They completely ignore the lessons of hundreds of years of typography.
My father is a designer and to my luck he taught me about typography. Everyone who touches a website should have read Jan Tschichold. There is no way around it, you will only repeat past mistakes.
(I had a quick look at your site and was vastly disappointed to see that the lines were, indeed, 8-12 words on average, thus precluding my saying "Physician, heal thyself".)
Book design is an amazing field by the way. For latin characters it was pioneered by hand written bibles in the medival ages. I only know a few things about it, barely enough to see that its a dying art. :(
Edit: Oh and you cannot "personaly dislike" a book design work. Its the only art I know which has definitive right or wrongs, black or whites, yes or nos. There is only one correct way to typeset any given text.
In fact, I find the line lengths in many properly typeset works too short for me to read comfortably. For me, longer lines make for easier reading!
Yeah not much of his work was translated, its sad. Maybe you can find similar/related/inspired authors who wrote or write in english. Its important to note that Tschichold made a U-turn at some point, while he was a big proponent of modernism at first, he later dismissed his opinions and became a proponent of classic typography. So I would go for writings from that later era.
And one should note that even old Jan was there way before digital typography on the web, heck, even way before DTP.
Don't get me wrong, I really liked his typography for laymen booklet ("Erfreuliche Drucksachen durch gute Typografie", a title that really can't get both more quaint and Germanic). But he's really supremely conservative in there, warning everybody about the dangers of color, sans-serifs and lauding the beauty and composition of medieval woodblocks. So, yeah, cum grano salis as they say…
It's the best centralized source of CL docs I've seen and the design is fairly modern.
There is no need to market CL. If you are a hardcore programmer then chances are you will love CL.
> Yet none of the links discuss this directly or provide tutorials.
I can recommend "Let Over Lambda" by Doug Hoyte.
> The author goes on to recommend LispWorks as a platform.
We have A LOT of extremely high quality free OSS implementations. Pick any.
> The "early Web 1.0" vibe is unfortunately common when the Common Lisp community attempts to promote Common Lisp.
And I think that this whole Web 2.0 thing is a big pile of bullshit that I never wanted in the first place.
> The issue is that the Common Lisp Community is not just sending signals that most of the potential market ignores, it's that it is sending signals that turn the potential market off.
That paragraph doesn't make any sense at all. No comment.
> Everything else screams "This ain't for you" at most people.
Since when are you the authority on what "most people" feel? Most people don't program the way I do.
> It makes Racket look hip. And that's hard to do.
I knew you were a troll. Your strawmen are just too outrageously bad.
Onlisp is a useful resource: http://www.paulgraham.com/onlisp.html. ANSI CL is nice too. For something simpler checkout David Touretsky's book, or Stuart Shapiro's book. PCL is awesome too. The latter is far more in touch with current CL "style". PAIP is also very cool.
No one is asking you to use Lispworks! If you can't afford to pay for it, use SBCL or CCL with Emacs/SLIME.
$4500 is definitely steep, but I sure hope you're wrong about commercial development tools no longer being viable. Not because I develop such tools myself, but because I want good tools. How will developers be paid to create great development tools, if it doesn't happen to be in the best interest of a company like Google, Apple, Red Hat, or Joyent to fund the work? See also: http://sealedabstract.com/rants/of-wizards-and-magical-machi...
We've become really spoiled. And that applies to me as much as anyone.
It's just that LispWorks comes with batteries included, has a cross-platform GUI toolkit, has a cross-platform GUI-based IDE, has a great runtime, has more delivery options, makes great use of CLOS, has more tools included, ... There is a noticeable step up in features from the typical open source / free software implementations to something like Allegro CL or LispWorks. Since both a proprietary and relatively expensive, often they are not a choice. But the fact remains, that they offer more and better features. SBCL shines with some features of its compiler. The topic is discussed, because for some people it is difficult to understand why one pays thousands of dollars for development and/or runtime (see for example the Azul JVM which starts at $3500 per machine per year).
Maybe it is showing my grey beard age, but I have bought quite a lot of software in my life, books(!) and even pay donations to open source projects.
As someone that lives from software development, I know how much it costs to transform my hours into something I can give in the supermarket and not all types of FOSS can be adapted to consulting.
Every time someone complains to me about software prices, I make them go through how would they manage to get enough money pay their current salaries. Then the prices don't seem that expensive any longer.
If men learn this, it will implant forgetfulness in their souls; they will cease to exercise memory because they rely on that which is written, calling things to remembrance no longer from within themselves, but by means of external marks. What you have discovered is a recipe not for memory, but for reminder. And it is no true wisdom that you offer your disciples, but only its semblance, for by telling them of many things without teaching them you will make them seem to know much, while for the most part they know nothing, and as men filled, not with wisdom, but with the conceit of wisdom, they will be a burden to their fellows.
I am not complaining about software prices. Just acknowledging the zeitgeist. My own grey beard is not so long that it covers my eyes - even when standing on my own bald head.