I am not sure it is true that comp.lang.lisp barely tolerates newbies. I have posted there on several occasions and when I say something wrong, I am politely corrected. I have seen a lot of less experienced programmers come there, ask an obviously beginner question, and get helpful answers. Reading through the past few days of posts, I can see a few beginner questions which all received helpful answers.
The problem in comp.lang.lisp is the number of trolls -- in other words, the universal problem on Usenet. People come in trying to prove that some other language is superior, or asking questions like "If Lisp is so great why is nobody using it?"
homework problems are different than newbie problems..
a homework problem is a problem you're charged with solving so as to reinforce elements and critical thinking from the chapter or segment of teaching that you experienced before the problem. Very few homework problems are given that cannot be solved by the user, if they paid attention to the work. There is a very thin line between someone trying to crowd-source their homework to a programming forum, and actually asking for help. This can usually be determined by how the question is asked.
Example: "How do I write this..?" is not as respectable a question as "I am writing this, i'm this far and I ran into this problem, can anyone help me to understand my problem?"
a newbie problem is a problem generated through normal use of a language to achieve a goal, in which the language user ( the newbie ) lacks the personal experience to conquer some goal post standing between him and his reason for writing what he/she's writing.
Example : "I'm coming from such and such a language where we can do this... ... will this ... work the same in CL?" or "This piece of code behaves in this way ... can anyone help me work through as to why it does this?"
The problem (that people have) with the lisp community is that they tend to be highly sensitive in regards to hand-holding, and can usually sniff out homework problems with relative ease.
Perhaps the author will find the answer to the "why" of how unwelcoming a community can be in his choice of opening paragraphs. A story that calls some number of his audience as stupid[1] or ignorant[2] for holding a belief is probably not the best way to introduce your soul searching on why the community he was a part of is not a welcoming one.
1) the implication if you have read your holy book and still believe then you are a poor thinker.
2) if we were in the Middle Ages, the story might be more relevant. I do believe most believers of any religion in the modern era have probably read their own holy book.
Coming from the Bible Belt, I can assure you that point 2 is absolutely false.
That said, even as a non-Christian I was also uncomfortable with that as an introduction. I'm sure many Lispers are of the opinion that almost 100% of their peers are atheists or other "nones", but that's (I suspect) more a function of geography than language choice.
It's unwise to turn off what could be a significant portion of your readers in the first paragraph!
Indeed, you can catch more flies with honey than vinegar. This author has told us up front attracting people to LISP/Clojure is not his primary goal.
There's also the minor detail that if you're a Christian the really canon stuff is in the New Testament, a lot if not most of the problematic stuff is in the Old Testament and not longer strictly applies (surely most of us remember "Let he who is without sin cast the first stone"???), so I suspect the whole premise is false.
Well, certainly the procedure for going to the bathroom is a bit different in modern times[1], and what parts of the Old Testament is a matter of debate between branches of Christians. Heck, the english translation of "thou shalt not (murder|kill)" is a bit of a thing. By the time you get out of bible school and listen to the sermons, you have gone through the whole bible[2].
I just found it very tone deaf to open with that kind of story when it basically has the same effect as what he is complaining about. Its just odd.
1) Although if you happen to hit a disaster, reviewing a bit of the health guidelines in Leviticus couldn't hurt. It will also probably help if you remember a lot of it is basic how-not-to-die health guidelines.
2) I came from the Catholic and 7th Day Adv family (yeah, not exactly the most agreeable to mix), and both seem to have gone through the whole thing. Plus, they have a bit of disagreement as to what constitutes the whole thing. Luther did a bit of pruning.
The Council of Nicea didn't deal with bible canon - that was made up for "The Da Vinci Code". Various religious sites debunked that one during the books and movie introductions.
Most of the stuff, period, is in the OT. We Jews have boatloads of commentary addressing the problematic stuff though, so if the problem is reading another possible remedy is more reading.
Exactly. If I were a Christian distressed by things in what we call the Old Testament that I didn't find suitably addressed by Christian scholars, I'd certainly review the Jewish commentaries to see how they addressed those things.
A heck of a lot of intellectual firepower, Jewish and Christian, has been focused on all these texts over a couple of thousand years (more by the Jews?), it would be foolish to abandon your religion based simply on reading the Ur-texts with finding out at least some of what the world's best minds have had to say about them and what they might mean.
Heck, merely reading the wonderful prose of the King James Version requires e.g. recognizing that a lot of its prose was somewhat obsolete when William Tyndale's work from 3/4 of a century earlier was used as the basis of all early printed English bibles. So you need to learn archaic English ... and all of that will do you very well in studying subsequent English prose.
As someone who works for a scholarly text analysis company focused on in-depth & intricate understanding of what Judao-Christian authors meant, I concur with this. It is really hard to understate the volume of words and man-millenia spent reading and writing about these books.
So not only is it possible to read your sacred book and still believe it, it's possible to read your sacred book and remaining fragments from other regional books (sacred and otherwise) - all in "close-to-original" language, and a wealth of other secondary material, and then still believe. You'll just slap your forehead than you might have originally bargained for when you started your quest...
Your description of "a scholarly text analysis company focused on in-depth & intricate understanding of what Judao-Christian authors meant" really piques my curiosity---I associate that sort of thing with academia (seminaries and religious studies departments, medieval studies, maybe a few classicists), not a (presumably for-profit) company.
If you don't mind my asking, what company do you work for, and what do they do?
> It is really hard to understate the volume of words and man-millenia spent reading and writing about these books.
So much brain power spent on scriptures which are, in the light of current knowledge… improbable to say the least. Sounds like a huge waste of effort, really.
Take the Genesis, for instance. Currently, only creationist crackpots actually believe it. It's more of a symbol. It seems however that some centuries ago, every Christian, including the most knowledgeable theologians, believed it.
Instead of trying to explain why the text was written for a good reason, wouldn't it be simpler to just recognize, as our knowledge expands, that the Elders were simply mistaken about such and such point, an move on? Just archive the mistakes and strike them from the cannon already, it would be much simpler for everyone.
But I guess a religion that routinely admits its own mistakes wouldn't be very religious, now would it?
Please don't take hardcore fundamentalist strictly-literalist narratives as the accepted "way" of Christianity.
Genesis was regarded as metaphorical around ~400AD, iirc (Augustine). Pretty sure the modern literalist movement is a post-1850 phenomenon. I don't get into the creation story discussions, it is entirely irrelevant in many ways to me. Waste of our time, IMO.
Judaism in particular is aggressive about doubt and questioning. I read in one intro book on it (by a rabbi, I think) that doubt is one of the defining characteristics of Jewish faith.
Anyway, modern scholarship tries in part to disentangle what was meant in the context of that time and place, determining what the precise meaning (or set of meanings) could have meant, then drawing out inferences to be taken from the work. This does involve, from time to time, revising our understanding of what happened when, where, and why. The story of the early reformation is, in one dimension, loosely a story of rereading the texts and throwing out certain interpretations based on closer analysis.
> Please don't take hardcore fundamentalist strictly-literalist narratives as the accepted "way" of Christianity.
I called them "creationist crackpots" for a reason. What I don't get, is why what shouldn't be interpreted literally, isn't simply stricken from the canon. I mean, what is the point of writing about a world created in seven days (oops, six), if we know it wasn't? Sabbath?
> Genesis was regarded as metaphorical around ~400AD, iirc (Augustine).
That's sooner than I expected. Which leaves us around 6 centuries to amend the book.
> Judaism in particular is aggressive about doubt and questioning.
Even if they aggressively show interest in doubt and questioning, I doubt it's for actually doubting an questioning, like, to the point of having some members realizing their religion is probably wrong after all. Here's a related example, from http://lesswrong.com/lw/ib/the_proper_use_of_doubt/
"""
Once, when I was holding forth upon the Way[1], I remarked upon how most organized belief systems exist to flee from doubt. A listener replied to me that the Jesuits must be immune from this criticism, because they practice organized doubt: their novices, he said, are told to doubt Christianity; doubt the existence of God; doubt if their calling is real; doubt that they are suitable for perpetual vows of chastity and poverty. And I said: Ah, but they're supposed to overcome these doubts, right? He said: No, they are to doubt that perhaps their doubts may grow and become stronger.
I think if you saw the actual content of these writings you'd be surprised how very little of it has anything to do with whatever it is you imagine it to. The bulk of the Jewish literature is about ethics. The historicity of a story is irrelevant to the ethical questions it raises, and Jewish analysis regards the Bible as primarily a source of questions.
Judaism is not a religion of creed, so Jews are not required to hold any particular beliefs. I expect you'll be surprised to learn that one can be a religious Jew and an atheist (I know a few, and it's "no other gods before me" not "believe in me" before you ask). Whether you believe in God or treat God as simply some kind of metaphor, the point of Judaism is that you must grapple with it, not blindly accept it.
Your final point is hilariously off-base. The mistakes are not only admitted, they are recorded in the book itself. It's easy to impress oneself by reading Leviticus and getting worked up. Make it through Job and Ecclesiastes, and you'll begin to see that complex ideas about this book are established and much older than people assume.
> Jews are not required to hold any particular beliefs.
I don't believe you. More specifically, I don't believe that the majority of people that regularly visit the synagogue think they don't have to hold any particular belief to stay Jew. I believe even less that the majority of Jews who cease to believe in God continue to call themselves religious.
> The mistakes are not only admitted, they are recorded in the book itself.
Oh. I didn't know the book itself was evidence of the waste of effort I mentioned. Seriously, remove the mistakes already, don't put an erratum 357 pages later.
Your disbelief stems from your fundamental lack of understanding of what you're talking about. You imagine that every religion is basically fundamentalist Protestantism. Your loss, I suppose.
Actually, I was raised in a lukewarm catholic environment, in France. There was no "coming out" as an atheist for me, it was quite… ordinary. My rejection of relativism spurred more heated discussions that my rejection of God, actually.
Anyway, every catholic I met believe in God and in the Immaculate Conception. And I think they also believed it was an important, if not fundamental, part of being catholic. Not to mention all the rituals that mention God and Jesus all over the place.
Which is why I cannot fathom a religion that does not at least strongly encourages its members to believe in something supernatural.
Seriously, you're tempting me to send a e-mail to Robert Aummann¹, and ask him about that. Or read Eliezer Yudkowsky about his childhood. Or just read the wikipedia². Let's see… Oh the chief reason why supernatural belief isn't required is because there's no recognized central authority… I bet however that most Rabbi strongly encourage a belief in something supernatural. If not directly, at least through the rituals they organize.
It matters what you believe in Christianity because it is a religion of faith and belief. If you no longer believe in God, you're not a Christian, you're an impostor. But Jewishness is decided by whether you were born Jewish or converted to Judaism. If either of those is true, you are a Jew, regardless of what you believe. None of the laws are predicated on believing in God (the one I mentioned before from the ten commandments precludes believing in other deities, but apparently permits atheism).
What makes someone a "bad Jew" is failing to practice Judaism. But there's no incentive to conduct a witchhunt over it, so there's no incentive for rhetoric about the importance of belief. I belong to a Conservative synagogue and I have never heard a sermon about the importance of believing in God. It isn't important. Ethical behavior is, and that is the content of our sermons.
It may be difficult to see a point to practicing if you don't believe in God, but, again, I know people who find value in the symbolism and the ritual and the religion's capacity to shape ethical behavior despite not believing in a supernatural being or origin. The entire Reconstructionist movement teaches that Judaism and the Bible were created by mankind. It may be a small movement, but it is real thing, and I know Conservative Jews who are atheists but still get value out of the practice.
I'm sure you will be able to find a marginal rabbi (probably "Orthodox", a self-applied label by a movement younger than the Reform) who will activate your confirmation bias. But I assure you, things are different outside your experience.
> Coming from the Bible Belt, I can assure you that point 2 is absolutely false.
Maybe its a Baptist thing, but Catholics and 7th Day Adv defiantly have gone through the whole thing as part of their studies. Nuns do get a little mad when you giggle about certain sections much like and English teacher with some scenes in Shakespeare.
Depends on how often they go to church. If they attend regularly for a few years, then the preacher will likely have gone over 80% of the Bible in Sunday morning sermons.
And most Baptist churches have some kind of weekly Bible study where you go more in depth.
Plus, most Baptist churches I've been to will start some kind of "read the Bible in a year" thing in January--complete with handouts for how much you need to read each day.
FYI, they are usually arranged fairly cleverly. The ones I remember seeing would run through weekly themes, like "scriptures about love" or "scriptures about finances." They would also often combine relevant Old and New Testament passages together for a day's reading. For example, one day's reading assignment would be one of Jesus' parables that references an Old Testament scripture plus the Old Testament scripture being references. Or, prophetic scriptures would be paired with scriptures detailing the fulfillment of those prophecies.
I also come from the Bible Belt, and point 2 seems reasonable to me, at least if you only consider people of a reasonably modest devotion to their faith (let's say, people with a "home church" where they attend weekly services 30+ weeks a year). Granted, few would have literally read the Bible cover to cover, in order as if it were a large novel.
I love Clojure and I think it's the first Lisp to take the language family out of "cons cell and parenthesis hell". My personal opinion is that Clojure with the following changes would take over much of the Lisp space:
- Rewrite most of Clojure in Clojure (which has been talked about since the beginning, really) to find the "small core". Thankfully ClojureScript has helped hasten the CiC movement.
- Base FFI and code gen on more abstractions so that Clojure living in a .net world or a C/C++ world or a Python world would feel just as cozy as Clojure living on the JVM. Rich Hickey talked about why he abandoned primary CLR support early on. He said he "didn't want to keep writing everything twice". This was probably the best strategy at first, but now one hopes that with ClojureScript + Clojure enough has been learned to discover more ways to factor out the commonalities so that Clojure is more easily retargetable.
- Speaking of targets: there should be a first class, fully supported Clojure frontend to LLVM. There are research projects and personal projects in this area, but that's about it. I'd like to see an official LLVM target.
- Introduce or surface more abstractions and macros such that the immutability and pure functional underpinnings could be extended, removed, or replaced. This is likely to be the most controversial change, but it would be essential to the possibility of Clojure running on small embedded systems and other environments where the choice of underlying data structures and concurrency algorithms can't come baked in. This is mostly done already (as most things in Clojure are built on top of abstractions), but it still needs a deep look.
- Open up the reader. A Lisp without full reader macros is unlikely to win over all potential converts, not because reader macros are this incredibly common thing, but because the personality of most Lisp hackers tends to thinking like "well I don't think I'll need a reader macro, but why would I want a language that won't even give me the option?"
Strong caveat about LLVM: it's not a good target for precise garbage collection, at a certain point the distinction between pointers and integers is lost. Fixing that would require diving into and writing a lot of C++, and I'd rather do that sort of work with a safe pointer language or drop all pretenses for the lowest level stuff.
I think a language like Clojure would have to go the ARC (Automatic Reference Counting, not the language) route.
Whether that's even possible is another matter, but I agree that the LLVM memory management problem is an interesting one.
Another question is whether there should exist a "sys lisp" that can form the lisp core of higher level lisps but that itself is not a garbage collected lisp. I don't immediately see a way forward on that one, but it's an interesting thought.
>> Another question is whether there should exist a "sys lisp" that can form the lisp core of higher level lisps but that itself is not a garbage collected lisp...
> - Open up the reader. A Lisp without full reader macros is unlikely to win over all potential converts, not because reader macros are this incredibly common thing, but because the personality of most Lisp hackers tends to thinking like "well I don't think I'll need a reader macro, but why would I want a language that won't even give me the option?"
While I agree that most of the other points are valid personal opinions, this one could safely be ignored. New Clojure users are largely converted from the enormous Java, Scala, Ruby, ... developer pool, and ignoring the projected wishes of (Common) Lisp programmers is a valid choice.
One interesting thing about having entirely immutable data structures is that you can allocate a temporary heap, and flip the GC around. Copy off just the result and junk the rest without looking at it. All without blocking the main thread.
In certain circumstances - for instance a web framework creating a heap for each request - this will make GC dramatically cheaper. Though of course your cache locality will be poor.
But immutability makes it conceptually a hell of lot cleaner, and feasible to do even if you're investing orders of magnitude less in your GC than went into the JVM.
Which is important if Clojure gets ported to bare metal runtimes, as the parent was suggesting.
That technique (commonly called semispace GC) works for mutable data as well, as long as you have a pointer indirection (so you can move), it's just less efficient than most others. It would be interesting to see whether the balance would shift significantly with immutable objects.
For the native target, LLVM might not necessarily be the best choice. clojure-scheme [1] is an interesting approach, there might be some other suitable target that produces native executables as well.
I doubt Rich Hickey is interested in those few remaining CL stalwarts that won't come over because he doesn't open up the reader. It's just a non issue.
As someone who learned a little Lisp in the last few years, I think there is a good collection of books available for the newbie who wants to learn. For Common Lisp, Land of Lisp, Practical Common Lisp, and Ansi Common Lisp all seem good enough to get hacking quickly.
Thinking about community effects, I'm not as convinced a community represents a gating factor for hackers. I attend the occasional Clojure meetup (and Clojure/Conj for that matter). The meetups in my area are well-attended and run, although they could be improved with a better introduction and ice-breaker for more introverted attendees (yes, I've just outed my personality type).
But from an opportunity mindset, the Clojure community seems to have done an admirable job getting the message out. Multiple good books, the Clojure/conj, and a well-attended meetup in my area all make me feel like I may not only stretch myself and learn new programming techniques, but that I have some hope of advocating for Clojure in my workplace or, good grief, applying for an actual day job where I would use Clojure.
It's unclear to me that Common Lisp can offer that.
Hi tom_b, I'm one of the co-organizers of the NYC Clojure meetup. I don't know if that's the one you attend, but I'm definitely interested in any specific ideas you might have for better introductions and ice breakers.
Thanks for organizing a Clojure meetup, it is much appreciated.
My only recommendations are quite generic - for smaller meetups, make sure a group introduction is on the agenda and actually happens. Might be nice if there were easy ways to become more active in the group, but this is hard for the meetup/talk format.
I'm definitely not being critical though - I feel lucky enough to have a Clojure meetup happen in my general area. Mostly it falls back on me, as an interested-in-the-community hacker to find a way actually be social and integrate myself into that group.
Is this not just another point in a decades long quest to save LISP?
Maybe LISP doesn't need saved? Maybe it's okay that a language isn't popular? Maybe It's okay that a language isn't hip? Maybe it's okay if a language doesn't have the latest gee wiz social status? The fact that people keep trying to save LISP every 4 or 5 years could mean it's perfectly fine how it is. I don't see people trying to save the COBOL, or FORTRAN, or <insert favorite esoteric language here> community.
Maybe ... prior to the R6RS debacle I had my hopes on Scheme, but it's still digging itself out of that mess, plus the long term failure to advance from R5RS that prompted the process change.
Common Lisp has had 3 decades to get its act together and is an abject failure in my view, plus it's got a half century of accumulated backwards compatibility accreted messiness.
Clojure is not a LISP, as in LISt Processing is not its alpha and omega. For now I won't go into details on I think it's being so successful, expect to point out that its architect has exquisite taste and savvy pragmatism, has made some great innovations in e.g. making maps and vectors syntactically first class citizens, and of course if you like serious functional programming and/or multi-core SMP/ccNUMA programming is has a great story. And most of all it's developed an ecosystem that has left Common Lisp and Scheme in the dust.
BTW, I don't think anyone needs to "save" COBOL, it's still used a lot, and as I understand it FORTRAN is still going strong in its niche, with regular new standard. Either are very far from being esoteric languages, although COBOL action is mostly hidden in the IT departments of organizations that write and maintain their custom systems.
I was using COBOL and FORTRAN as languages with a long history and didn't mean to imply they were esoteric. I didn't want to write "<insert old language here>" because I wanted people to think of more than just old.
But you bring up a good point. Those languages are still around because of the niche they fill. It's okay for LISP to be around only because it fills a niche, too.
Am I the only one who thinks Clojure is extremely ugly, especially compared to CL?
I work a lot with clojure, and it reminds me a lot of when I was forced a hack ruby. There is this guy, or even a group of people, who get caught up in the glamourous idea of reinventing programming. They then jerk their favourite features and design artifacts into a language. The main point of the design seems to be being able to express the thing in fancy words.
Some people love that stuff, they think its beauty and good design because it's somewhat consistent (usually not after the second glance).
I think good design is whats works, and what has evolved due to the needs of practicioners. And that is the beauty of CL, it's shaped by evolution and consensus, not by some vison.
Edit: Also, ever taken into account, that CL is maybe simply good enough? Every possble feature can be included by libraries. There is no need for an updated CL, what we need is more standards like bordeaux-threads, usocket, closer-mop...
Sort of. On the surface I find Clojure infinitely more ugly than true LISPs ... but if hairing up the syntax with vectors results in more adaptation its a price I'm willing to pay. On the other hand I'm really pleased at its making vectors, maps and sets first class syntactic citizens, and the other things that have unified them with lists.
Underneath the hood I think there's no comparison, then again it addresses exactly the sort of things I'm interested in. Common Lisp just can't win there due to it being the current version of mainline LISP going back to, well, I supposed the punched card days when it was implemented as FORTRAN subroutines. Yeah, car and cdr are neat, and even useful in combination, but ... well, no where can you assume TCO.
(recur ...) Is an ugly hack. Yes in CL you can assume TCO from good implementations.
You know you can add vector/map whatever syntax to CL in like 50 loc? Are you seriously saying that syntactic sugar is in any way relevant to anything? Let alone an important feature of Clojure? Thats just sad.
> car and cdr are neat, and even useful in combination,
Actually wether you call them car cdr first rest or whatever, it's actually about CONS or call it a pair if you like. A very simple but infinitely powerful datatype. This is the first thing I teach when I teach programming for a very good reason.
Ugly hack ... but maybe a useful one? In that explicitly requesting TCO avoids certain classes of errors? (I don't know on balance, haven't tried TCO in Clojure in anger, and I experience enough value in being in the JVM ecosystem that it's a price I'm in theory willing to pay for now.)
The problem with CL is that you can't assume it in every major implementation. Although I just found this page which paints a fairly good picture: http://0branch.com/notes/tco-cl.html
"The following implementations were found to provide full TCO:
CMUCL
SBCL
CCL
Allegro
LispWorks
…only optimise self-calls in tail position:
CLisp
GCL
ECL (when explicitly compiled)
…neither:
ABCL
Back to me: and CL is so big that "non-major" ports are of much less interest.
As for vector, map and set syntax, that was explicit mentioned as being a surface thing. The real special sauce is in how they've been unified with lists, especially under the hood.
As for your last point, I see great value in all that in the LISPs, although I of course prefer Scheme. But I also see great value in the "Lisp" (LISt Processing no longer the alpha and omega) in what Clojure is doing."
It's spelled Fortran since the 1992 standard, which was a huge improvement, and now since the 2003 and 2008 standards, Fortran is a pretty decent language.
But a funny thought occurred to me: year 1992 is now 21 years ago, but ignorance of the difference between FORTRAN 77 and modern Fortran continues strong. In next 5 year or so we'll start to get Fortran-ignorant comments from people who are younger than the "Fortran 90" standard from 1992.
The language was updated before they were born, but they haven't yet noticed it.
I'm embarrassed to say that I actually know this, but it's so ingrained to type it in caps. I even did it twice in this thread.
It was an interesting exercise in college when I took a class on numerical methods and some programs where in "old" style while other were in "new" style. It made the non-programmers go bonkers.
I came to precisely the same realization about ten years ago, after struggling in vain with the culture and quirks of Common Lisp. There's no question that learning Lisp in some form will make you a better programmer but don't get caught up in the cult that surrounds it. Virtually all of Lisp's innovations now been validated and adopted by more mainstream languages and the fact that nobody has picked up the s-expr syntax is telling.
These days I focus more on writing useful code and making end users happy and I've found that to be much more satisfying than wringing my hands over the inelegance of everyday languages.
Honestly, I don't know that CL was ever exactly beloved among Lispers. (Scheme may fit that description better). CL was a pragmatic construct from the beginning, responding to many conflicting demands.
There isn't, as far as I'm aware, another language with CL's popularity that provides either its condition system or the full power of the CLOS (method combination, for instance). These two major subsystems are still significant improvements over what modern languages have to offer.
Good point about CLOS, but for a lot of us who've gained an allergy to OO over the years, especially in its difficult relation to functional programming, that's of limited appeal unless you're working in one of the areas its fruitfully employed.
Would have to look at it's condition system, it's been way too long.
If you're giving up CL for Ruby, the CLOS is worth discussing. If you're giving up CL for Haskell, well, it's a different story. :)
I never used the condition system extensively (or CL) but my recollection is that when you raise the condition you can also furnish various recovery strategies to be selected by the handler. If the caller doesn't handle, it will travel up the stack to someone who does, but that entity is not limited to innovating its own handling strategy, it can also choose one of the provided ones without breaking the abstraction or involving intermediate callers. The toplevel handler shows the provided restarts, adds the retry/fail options and lets the user interactively select one. It's pretty sophisticated.
Yes, I have, and starting from the Lisp Machine Flavors precursor. While I haven't used it in anger, it's in theory by far my most favorite OO system.
This is in part philosophical, the "prefer 10 data types and 90 functions that operate on them, often all of them" sort of thing, in part my horror at smearing behavior and data all over the place, and pragmatically, how that's much more of an imperative than functional approach. And functional is where its at for what I want to do. And experience in using OOSE to develop a greenfields system. That was utterly cool and amazing, but ... see my last sentence below.
Which is not to say that the next time I do a GUI I'm not going to use OO to model the widgets et. al. on the screen. I believe it has its place, but that it's used much more widely than makes sense.
Props to the author for mentioning Chicken Scheme. The community is very friendly indeed. There are lots of eggs and the easy C integration means that one is not usually left wanting for libraries, assuming a minimal knowledge of C.
Also, it runs basically anywhere. One could embed it inside an iPhone app, for instance.
There are some big things missing still. There is no standard database access library, or an equivalent to Python's WSGI (or Ruby's Rack). Or MongoDB drivers (that's my fault, I promised the community one a couple of months ago).
There's also some missing tooling. Better debugging support, for instance. That's mostly avoided by the use of unit tests and the REPL, but is occasionally required. Or profilers. Or code coverage tools. Due to the fact that everything is compiled to C, there are some tools that may be used, but it is still not ideal.
First there are a lot of programmers who come to CL to debate. They read, they study, and then they complain. I've sat in #lisp since about 2007/8 and there have been numerous nicks that show up just to ask a few rather philosophical questions and debate the merits and technical decisions that went into CL. They usually end up leaving and writing blog posts about how terrible a language CL is and how caustic the community is.
There isn't a problem with the CL community. There's a problem with the culture surrounding CL that seems to attract trolls.
Newbies get answers to genuine questions. I've received a great deal of help over the years from experience CL programmers. Anything from beginner questions to code reviews of various snippets I've been working on. I have received a lot of great advice over the years that has helped me tremendously. And I've seen other newcomers receive the same treatment as well. If you arrive in #lisp of c.l.l and have a genuine question about a problem you are stuck on you will likely attract someone willing to help you. It's a small community but it is friendly.
Second, CL was in the end designed to outlive itself. You get full programmatic access to the compiler and reader. It is trivial to add any feature a modern programmer may require that wasn't accounted for in the original specification. CLUEL could certainly have been useful if the author had finished it and put it out into the wild (maybe waiting until it was finished was the wrong choice).
I think if you are genuinely interested in learning CL you need to check your ego at the door, so to speak, and just start from scratch. Write programs that solve yours or your users' problems and ask questions in #lisp and on c.l.l if you get stuck. There is a wealth of great literature, papers, tools, and a small, friendly community to help you.
Edit: I meant to note that the reason the specification hasn't been updated, afaik, is because it doesn't have to be updated. All the tools you need to add the features you require are there in the spec. You can make it into the language you need.
Completely agree. One thing that I figured out rather quickly is that lispers really want to teach and explain things, but being lazy programmers, they don't bother holding your hand, so if you are willing to do your homework, you'll have an amazing time with lisp.
Lets take a look at a few patterns I've noticed:
* Newbie posts some snippet and asks for review, the snippet is C++ code written in CL, lisper tells him it sucks, newbie explains that he has a lot of C++ experience and this is how his brain works. Lispers(now plural) explain to him that lisp must be learned with a beginners mind and he must forget C++ temporarily in order to learn it properly. Newbie gets insulted for some reason and begins arguing.
* newbie asks question about "generic lisp", lispers explain that the question makes no sense, and give his an answer about common lisp. Newbie asks question again emphasizing that he isn't interested in Common Lisp but in lisp in general, lispers tell him to read the topic, #lisp is about Common Lisp. Newbie argues that #lisp should be about generic lisp, and #commonlisp or whatever should be about CL, argument goes nowhere of course.
* newbie asks question and posts snippet. The code is obviously written by somebody with exactly 1 hour of lisp experience(parens are mismatched and aligned wrong, indentation is horrible, not to mention the obvious hacks). lispers explain that lisp is best learned patiently and not through the "learn x in y minutes" way, and that he should read Practical Common Lisp. Newbie gets insulted he was told to RTFM instead of getting an actual answer to his "wrong" question(at least in the eyes of us lispers).
* newbie asks about scheme/emacs and refuses to accept that #lisp isn't about those languages, see pattern #2.
* newbie asks scheme vs CL vs clojure vs haskell vs python vs ... question. Gets surprised when lispers unapologetically proclaim CL the best language ever and everything else is shit. Lispers do not hide their bias. Newbie then begins to argue about his favorite language and why it is better than lisp. Sometimes it's clojure, sometimes its scheme, or it could be whatever.
* (my favorite, and probably most frequent) Newbie asks what is lisp good for, gets pissed off when we tell him we program computers with it :)
Many other such questions include:
Q: "why isn't lisp popular" A: You haven't converted enough people to it :)
Q: "Why does lisp have so few libraries" A: You haven't written enough libraries yet :)
Q: "Why isn't there a library for X" A: Nobody needed it, if you do, write it and push it to github :)
Q: "Why doesn't library X do Y" A: patches welcome.
Notice a pattern :)
All of these cases or variations of them have happened many times since I started to frequent #lisp, often times the word "fags" or "cunts" get used, and not by lispers.
> Edit: I meant to note that the reason the specification hasn't been updated, afaik, is because it doesn't have to be updated. All the tools you need to add the features you require are there in the spec. You can make it into the language you need.
That's a big part of the reason I haven't used CL for anything bigger than some toy projects.
It's a crusty, old language, and instead of keeping up with the times, everybody has to build the features they need. I can do that, or I can use language that has the features I need and that I don't have to assemble myself.
And to make it worse, it's hard to even use libraries that solve the problem, because nobody in the CL community can agree on anything. There's always a dozen incompatible solutions, and it's never clear which one should be used.
" There's always a dozen incompatible solutions, and it's never clear which one should be used."
Welcome to software.
While your other sentiment seems logical, if you actually look at it as a lisp practitioner, you'll find the answers to the questions you have relatively easy. You don't have to "update" the language, for many things you can just use it like any other.
The problem isn't that lisp isn't updated, but that there aren't enough of us to build the lisp django, or at least there aren't enough of us who want the lisp django for it to happen, so thats why web development in lisp is limited to using raw hunchentoot or microframeworks like Restas and Caveman/Clack(which are both pretty awesome btw). Other than a few minor tweaks, lisp really doesn't need updating. More/better libraries would be sufficient!
Can you give a couple of specific examples where you think lisp is behind the times and you are "forced" to implement whatever. I can think of maybe a handful of such instances(there isn't a really great STM, but we do have other awesome concurrency options as just one example), but the list of lisp features I miss in python(my day job) is 1-2 dozens at least(and If I had macros and CLOS I could probably half that list in a week or two :)
In other words if you are crazy enough to use lisp for useful projects, the language will help you, maybe you haven't tried? Maybe you have and just had bad luck. Some domains(GUI programming for example) aren't as well supported for example. Others are pretty ok.
I don't really understand the, "crusty, old language," argument either. C++ became an ISO-certified specification in 1998 which is roughly around the same time that CL became an ANSI standardized language. We still use C in many systems for very valid reasons.
However unlike the C++ and ANSI C standards, the CL specification left room for programmers to extend the language as they need it. Instead of waiting for decades of expensive committee debates and meetings as you do with C/C++/ECMAScript/etc the programmers using the language in the field can go ahead and add the features they need and implementors can fill the gaps between new OSs and hardware. How is that bad?
It's bad because every implementation fills the gaps in their own incompatible way. And then instead of converging on the "best" solution, the community argues endlessly about each unique solution is the best.
And it's also bad because CL is ancient and it's filled with things that simply don't make sense any more, or have been replaced by "better" solutions in every other language. Look at filename and filepath handling to see what I mean. 2 or 3 of the fields haven't been used in real systems in 20 or 30 years, yet they're kept around because they're in the unchanging CL standard.
The Lisp community as typified by #lisp and comp.lang.lisp can be remarkably acerbic to the point of toxic, depending on who feels like contributing at the time. Part of this are the annoying trolls that show up; one's patience wears thin. A FAQ document might go a ways. However, there are a large number of people who don't ream newbies out and really are helpful. lispm here on HN is one of the friendliest Lispers out there and actually has helped me out tons.
Addendum: r/lisp on Reddit is good for generalish Lisp questions. StackOverflow's common lisp tag almost always gets an answer to most any reasonable question. sbcl-devel mailing list is useful if you want to take the time to posit in-depth technical questions to the SBCL developers. Lispforum, oddly enough, I haven't used much. I simply don't go there much. I should, I suppose. :)
2. Technical. I can do no better than quote my /r/lisp post on this (r/lisp is really good for lisp help).
---
First of all, consistency. A variety of things are peculiar in how they are named. TERPRI? Really?
Second, Common Lisp is a (the?) programmable programming language. CLUEL-esque platforms could be used to drive CDR adoption and cleanups of the original language.
My primary gripes with CL are the lack of CDR-2, lack of CDR-8, the lack of hierarchical namespaces, the funky naming conventions & expectations[1], and the lack of deeper CLOS integration[2].
[1] ELT vs AREF vs NTH, for instance. Or, LOOP for lists vs arrays vs (your data structure here).
This reminds me of my experiences with Plan 9. A very cool system, but it's managed to attract some of the absolute worst people in computing. Dare to criticize something and they'll leap down your throat. In the end, I just gave up. We tried to drag things kicking and screaming into the 21st century with source control, 64 bit kernel, automated builds and testing, etc. but nobody wanted it.
On the other hand, the mailing list did get a lot of posts that kind of remind me of this: "Hi, I just started using Plan 9, where's emacs? Anyway I have a lot of great ideas on how to fix this OS so you should all start doing these things... I'll set up the wiki and write the newbie guide"
On the other hand, the mailing list did get a lot of posts that kind of remind me of this: "Hi, I just started using Plan 9, where's emacs? Anyway I have a lot of great ideas on how to fix this OS so you should all start doing these things... I'll set up the wiki and write the newbie guide"
and this:
Dare to criticize something and they'll leap down your throat.
81 comments
[ 3.4 ms ] story [ 147 ms ] threadThe problem in comp.lang.lisp is the number of trolls -- in other words, the universal problem on Usenet. People come in trying to prove that some other language is superior, or asking questions like "If Lisp is so great why is nobody using it?"
a homework problem is a problem you're charged with solving so as to reinforce elements and critical thinking from the chapter or segment of teaching that you experienced before the problem. Very few homework problems are given that cannot be solved by the user, if they paid attention to the work. There is a very thin line between someone trying to crowd-source their homework to a programming forum, and actually asking for help. This can usually be determined by how the question is asked.
Example: "How do I write this..?" is not as respectable a question as "I am writing this, i'm this far and I ran into this problem, can anyone help me to understand my problem?"
a newbie problem is a problem generated through normal use of a language to achieve a goal, in which the language user ( the newbie ) lacks the personal experience to conquer some goal post standing between him and his reason for writing what he/she's writing.
Example : "I'm coming from such and such a language where we can do this... ... will this ... work the same in CL?" or "This piece of code behaves in this way ... can anyone help me work through as to why it does this?"
The problem (that people have) with the lisp community is that they tend to be highly sensitive in regards to hand-holding, and can usually sniff out homework problems with relative ease.
1) the implication if you have read your holy book and still believe then you are a poor thinker.
2) if we were in the Middle Ages, the story might be more relevant. I do believe most believers of any religion in the modern era have probably read their own holy book.
That said, even as a non-Christian I was also uncomfortable with that as an introduction. I'm sure many Lispers are of the opinion that almost 100% of their peers are atheists or other "nones", but that's (I suspect) more a function of geography than language choice.
It's unwise to turn off what could be a significant portion of your readers in the first paragraph!
There's also the minor detail that if you're a Christian the really canon stuff is in the New Testament, a lot if not most of the problematic stuff is in the Old Testament and not longer strictly applies (surely most of us remember "Let he who is without sin cast the first stone"???), so I suspect the whole premise is false.
I just found it very tone deaf to open with that kind of story when it basically has the same effect as what he is complaining about. Its just odd.
1) Although if you happen to hit a disaster, reviewing a bit of the health guidelines in Leviticus couldn't hurt. It will also probably help if you remember a lot of it is basic how-not-to-die health guidelines.
2) I came from the Catholic and 7th Day Adv family (yeah, not exactly the most agreeable to mix), and both seem to have gone through the whole thing. Plus, they have a bit of disagreement as to what constitutes the whole thing. Luther did a bit of pruning.
A heck of a lot of intellectual firepower, Jewish and Christian, has been focused on all these texts over a couple of thousand years (more by the Jews?), it would be foolish to abandon your religion based simply on reading the Ur-texts with finding out at least some of what the world's best minds have had to say about them and what they might mean.
Heck, merely reading the wonderful prose of the King James Version requires e.g. recognizing that a lot of its prose was somewhat obsolete when William Tyndale's work from 3/4 of a century earlier was used as the basis of all early printed English bibles. So you need to learn archaic English ... and all of that will do you very well in studying subsequent English prose.
So not only is it possible to read your sacred book and still believe it, it's possible to read your sacred book and remaining fragments from other regional books (sacred and otherwise) - all in "close-to-original" language, and a wealth of other secondary material, and then still believe. You'll just slap your forehead than you might have originally bargained for when you started your quest...
If you don't mind my asking, what company do you work for, and what do they do?
So much brain power spent on scriptures which are, in the light of current knowledge… improbable to say the least. Sounds like a huge waste of effort, really.
Take the Genesis, for instance. Currently, only creationist crackpots actually believe it. It's more of a symbol. It seems however that some centuries ago, every Christian, including the most knowledgeable theologians, believed it.
Instead of trying to explain why the text was written for a good reason, wouldn't it be simpler to just recognize, as our knowledge expands, that the Elders were simply mistaken about such and such point, an move on? Just archive the mistakes and strike them from the cannon already, it would be much simpler for everyone.
But I guess a religion that routinely admits its own mistakes wouldn't be very religious, now would it?
Please don't take hardcore fundamentalist strictly-literalist narratives as the accepted "way" of Christianity.
Genesis was regarded as metaphorical around ~400AD, iirc (Augustine). Pretty sure the modern literalist movement is a post-1850 phenomenon. I don't get into the creation story discussions, it is entirely irrelevant in many ways to me. Waste of our time, IMO.
Judaism in particular is aggressive about doubt and questioning. I read in one intro book on it (by a rabbi, I think) that doubt is one of the defining characteristics of Jewish faith.
Anyway, modern scholarship tries in part to disentangle what was meant in the context of that time and place, determining what the precise meaning (or set of meanings) could have meant, then drawing out inferences to be taken from the work. This does involve, from time to time, revising our understanding of what happened when, where, and why. The story of the early reformation is, in one dimension, loosely a story of rereading the texts and throwing out certain interpretations based on closer analysis.
I called them "creationist crackpots" for a reason. What I don't get, is why what shouldn't be interpreted literally, isn't simply stricken from the canon. I mean, what is the point of writing about a world created in seven days (oops, six), if we know it wasn't? Sabbath?
> Genesis was regarded as metaphorical around ~400AD, iirc (Augustine).
That's sooner than I expected. Which leaves us around 6 centuries to amend the book.
> Judaism in particular is aggressive about doubt and questioning.
Even if they aggressively show interest in doubt and questioning, I doubt it's for actually doubting an questioning, like, to the point of having some members realizing their religion is probably wrong after all. Here's a related example, from http://lesswrong.com/lw/ib/the_proper_use_of_doubt/
"""
Once, when I was holding forth upon the Way[1], I remarked upon how most organized belief systems exist to flee from doubt. A listener replied to me that the Jesuits must be immune from this criticism, because they practice organized doubt: their novices, he said, are told to doubt Christianity; doubt the existence of God; doubt if their calling is real; doubt that they are suitable for perpetual vows of chastity and poverty. And I said: Ah, but they're supposed to overcome these doubts, right? He said: No, they are to doubt that perhaps their doubts may grow and become stronger.
[1]: http://yudkowsky.net/virtues/
"""
If not, feedback about I did wrong would be most welcome.
Judaism is not a religion of creed, so Jews are not required to hold any particular beliefs. I expect you'll be surprised to learn that one can be a religious Jew and an atheist (I know a few, and it's "no other gods before me" not "believe in me" before you ask). Whether you believe in God or treat God as simply some kind of metaphor, the point of Judaism is that you must grapple with it, not blindly accept it.
Your final point is hilariously off-base. The mistakes are not only admitted, they are recorded in the book itself. It's easy to impress oneself by reading Leviticus and getting worked up. Make it through Job and Ecclesiastes, and you'll begin to see that complex ideas about this book are established and much older than people assume.
I don't believe you. More specifically, I don't believe that the majority of people that regularly visit the synagogue think they don't have to hold any particular belief to stay Jew. I believe even less that the majority of Jews who cease to believe in God continue to call themselves religious.
> The mistakes are not only admitted, they are recorded in the book itself.
Oh. I didn't know the book itself was evidence of the waste of effort I mentioned. Seriously, remove the mistakes already, don't put an erratum 357 pages later.
Anyway, every catholic I met believe in God and in the Immaculate Conception. And I think they also believed it was an important, if not fundamental, part of being catholic. Not to mention all the rituals that mention God and Jesus all over the place.
Which is why I cannot fathom a religion that does not at least strongly encourages its members to believe in something supernatural.
Seriously, you're tempting me to send a e-mail to Robert Aummann¹, and ask him about that. Or read Eliezer Yudkowsky about his childhood. Or just read the wikipedia². Let's see… Oh the chief reason why supernatural belief isn't required is because there's no recognized central authority… I bet however that most Rabbi strongly encourage a belief in something supernatural. If not directly, at least through the rituals they organize.
[1]: https://en.wikipedia.org/wiki/Robert_Aumann
[2]: https://en.wikipedia.org/wiki/Jewish_principles_of_faith
What makes someone a "bad Jew" is failing to practice Judaism. But there's no incentive to conduct a witchhunt over it, so there's no incentive for rhetoric about the importance of belief. I belong to a Conservative synagogue and I have never heard a sermon about the importance of believing in God. It isn't important. Ethical behavior is, and that is the content of our sermons.
It may be difficult to see a point to practicing if you don't believe in God, but, again, I know people who find value in the symbolism and the ritual and the religion's capacity to shape ethical behavior despite not believing in a supernatural being or origin. The entire Reconstructionist movement teaches that Judaism and the Bible were created by mankind. It may be a small movement, but it is real thing, and I know Conservative Jews who are atheists but still get value out of the practice.
I'm sure you will be able to find a marginal rabbi (probably "Orthodox", a self-applied label by a movement younger than the Reform) who will activate your confirmation bias. But I assure you, things are different outside your experience.
Maybe its a Baptist thing, but Catholics and 7th Day Adv defiantly have gone through the whole thing as part of their studies. Nuns do get a little mad when you giggle about certain sections much like and English teacher with some scenes in Shakespeare.
Depends on how often they go to church. If they attend regularly for a few years, then the preacher will likely have gone over 80% of the Bible in Sunday morning sermons.
And most Baptist churches have some kind of weekly Bible study where you go more in depth.
Plus, most Baptist churches I've been to will start some kind of "read the Bible in a year" thing in January--complete with handouts for how much you need to read each day.
- Rewrite most of Clojure in Clojure (which has been talked about since the beginning, really) to find the "small core". Thankfully ClojureScript has helped hasten the CiC movement.
- Base FFI and code gen on more abstractions so that Clojure living in a .net world or a C/C++ world or a Python world would feel just as cozy as Clojure living on the JVM. Rich Hickey talked about why he abandoned primary CLR support early on. He said he "didn't want to keep writing everything twice". This was probably the best strategy at first, but now one hopes that with ClojureScript + Clojure enough has been learned to discover more ways to factor out the commonalities so that Clojure is more easily retargetable.
- Speaking of targets: there should be a first class, fully supported Clojure frontend to LLVM. There are research projects and personal projects in this area, but that's about it. I'd like to see an official LLVM target.
- Introduce or surface more abstractions and macros such that the immutability and pure functional underpinnings could be extended, removed, or replaced. This is likely to be the most controversial change, but it would be essential to the possibility of Clojure running on small embedded systems and other environments where the choice of underlying data structures and concurrency algorithms can't come baked in. This is mostly done already (as most things in Clojure are built on top of abstractions), but it still needs a deep look.
- Open up the reader. A Lisp without full reader macros is unlikely to win over all potential converts, not because reader macros are this incredibly common thing, but because the personality of most Lisp hackers tends to thinking like "well I don't think I'll need a reader macro, but why would I want a language that won't even give me the option?"
Whether that's even possible is another matter, but I agree that the LLVM memory management problem is an interesting one.
Another question is whether there should exist a "sys lisp" that can form the lisp core of higher level lisps but that itself is not a garbage collected lisp. I don't immediately see a way forward on that one, but it's an interesting thought.
You may be interested in Henry Baker has a paper where he shows a VM where the semantics prevent garbage from being created http://home.pipeline.com/~hbaker1/LinearLisp.html
While I agree that most of the other points are valid personal opinions, this one could safely be ignored. New Clojure users are largely converted from the enormous Java, Scala, Ruby, ... developer pool, and ignoring the projected wishes of (Common) Lisp programmers is a valid choice.
In certain circumstances - for instance a web framework creating a heap for each request - this will make GC dramatically cheaper. Though of course your cache locality will be poor.
Which is important if Clojure gets ported to bare metal runtimes, as the parent was suggesting.
1. https://github.com/takeoutweight/clojure-scheme
Thinking about community effects, I'm not as convinced a community represents a gating factor for hackers. I attend the occasional Clojure meetup (and Clojure/Conj for that matter). The meetups in my area are well-attended and run, although they could be improved with a better introduction and ice-breaker for more introverted attendees (yes, I've just outed my personality type).
But from an opportunity mindset, the Clojure community seems to have done an admirable job getting the message out. Multiple good books, the Clojure/conj, and a well-attended meetup in my area all make me feel like I may not only stretch myself and learn new programming techniques, but that I have some hope of advocating for Clojure in my workplace or, good grief, applying for an actual day job where I would use Clojure.
It's unclear to me that Common Lisp can offer that.
though "tell us your name, where you're from and one nice thing that happened to you this week" is a non-demanding one
My only recommendations are quite generic - for smaller meetups, make sure a group introduction is on the agenda and actually happens. Might be nice if there were easy ways to become more active in the group, but this is hard for the meetup/talk format.
I'm definitely not being critical though - I feel lucky enough to have a Clojure meetup happen in my general area. Mostly it falls back on me, as an interested-in-the-community hacker to find a way actually be social and integrate myself into that group.
Maybe LISP doesn't need saved? Maybe it's okay that a language isn't popular? Maybe It's okay that a language isn't hip? Maybe it's okay if a language doesn't have the latest gee wiz social status? The fact that people keep trying to save LISP every 4 or 5 years could mean it's perfectly fine how it is. I don't see people trying to save the COBOL, or FORTRAN, or <insert favorite esoteric language here> community.
Common Lisp has had 3 decades to get its act together and is an abject failure in my view, plus it's got a half century of accumulated backwards compatibility accreted messiness.
Clojure is not a LISP, as in LISt Processing is not its alpha and omega. For now I won't go into details on I think it's being so successful, expect to point out that its architect has exquisite taste and savvy pragmatism, has made some great innovations in e.g. making maps and vectors syntactically first class citizens, and of course if you like serious functional programming and/or multi-core SMP/ccNUMA programming is has a great story. And most of all it's developed an ecosystem that has left Common Lisp and Scheme in the dust.
BTW, I don't think anyone needs to "save" COBOL, it's still used a lot, and as I understand it FORTRAN is still going strong in its niche, with regular new standard. Either are very far from being esoteric languages, although COBOL action is mostly hidden in the IT departments of organizations that write and maintain their custom systems.
But you bring up a good point. Those languages are still around because of the niche they fill. It's okay for LISP to be around only because it fills a niche, too.
I work a lot with clojure, and it reminds me a lot of when I was forced a hack ruby. There is this guy, or even a group of people, who get caught up in the glamourous idea of reinventing programming. They then jerk their favourite features and design artifacts into a language. The main point of the design seems to be being able to express the thing in fancy words.
Some people love that stuff, they think its beauty and good design because it's somewhat consistent (usually not after the second glance).
I think good design is whats works, and what has evolved due to the needs of practicioners. And that is the beauty of CL, it's shaped by evolution and consensus, not by some vison.
Edit: Also, ever taken into account, that CL is maybe simply good enough? Every possble feature can be included by libraries. There is no need for an updated CL, what we need is more standards like bordeaux-threads, usocket, closer-mop...
Underneath the hood I think there's no comparison, then again it addresses exactly the sort of things I'm interested in. Common Lisp just can't win there due to it being the current version of mainline LISP going back to, well, I supposed the punched card days when it was implemented as FORTRAN subroutines. Yeah, car and cdr are neat, and even useful in combination, but ... well, no where can you assume TCO.
(Have to run, more later.)
(recur ...) Is an ugly hack. Yes in CL you can assume TCO from good implementations.
You know you can add vector/map whatever syntax to CL in like 50 loc? Are you seriously saying that syntactic sugar is in any way relevant to anything? Let alone an important feature of Clojure? Thats just sad.
> car and cdr are neat, and even useful in combination,
Actually wether you call them car cdr first rest or whatever, it's actually about CONS or call it a pair if you like. A very simple but infinitely powerful datatype. This is the first thing I teach when I teach programming for a very good reason.
The problem with CL is that you can't assume it in every major implementation. Although I just found this page which paints a fairly good picture: http://0branch.com/notes/tco-cl.html
"The following implementations were found to provide full TCO:
…only optimise self-calls in tail position: …neither: Back to me: and CL is so big that "non-major" ports are of much less interest.As for vector, map and set syntax, that was explicit mentioned as being a surface thing. The real special sauce is in how they've been unified with lists, especially under the hood.
As for your last point, I see great value in all that in the LISPs, although I of course prefer Scheme. But I also see great value in the "Lisp" (LISt Processing no longer the alpha and omega) in what Clojure is doing."
Still trying to find a copy of his MIT IAP Lisp course notes (haven't tried very hard yet); they and his delivery of them were very very good.
At the same time Jeff Schiller (JIS) would give a short neat talk on how macros worked and why they were neat.
It's spelled Fortran since the 1992 standard, which was a huge improvement, and now since the 2003 and 2008 standards, Fortran is a pretty decent language.
But a funny thought occurred to me: year 1992 is now 21 years ago, but ignorance of the difference between FORTRAN 77 and modern Fortran continues strong. In next 5 year or so we'll start to get Fortran-ignorant comments from people who are younger than the "Fortran 90" standard from 1992.
The language was updated before they were born, but they haven't yet noticed it.
It was an interesting exercise in college when I took a class on numerical methods and some programs where in "old" style while other were in "new" style. It made the non-programmers go bonkers.
These days I focus more on writing useful code and making end users happy and I've found that to be much more satisfying than wringing my hands over the inelegance of everyday languages.
Would have to look at it's condition system, it's been way too long.
I never used the condition system extensively (or CL) but my recollection is that when you raise the condition you can also furnish various recovery strategies to be selected by the handler. If the caller doesn't handle, it will travel up the stack to someone who does, but that entity is not limited to innovating its own handling strategy, it can also choose one of the provided ones without breaking the abstraction or involving intermediate callers. The toplevel handler shows the provided restarts, adds the retry/fail options and lets the user interactively select one. It's pretty sophisticated.
This is in part philosophical, the "prefer 10 data types and 90 functions that operate on them, often all of them" sort of thing, in part my horror at smearing behavior and data all over the place, and pragmatically, how that's much more of an imperative than functional approach. And functional is where its at for what I want to do. And experience in using OOSE to develop a greenfields system. That was utterly cool and amazing, but ... see my last sentence below.
Which is not to say that the next time I do a GUI I'm not going to use OO to model the widgets et. al. on the screen. I believe it has its place, but that it's used much more widely than makes sense.
Also, it runs basically anywhere. One could embed it inside an iPhone app, for instance.
There are some big things missing still. There is no standard database access library, or an equivalent to Python's WSGI (or Ruby's Rack). Or MongoDB drivers (that's my fault, I promised the community one a couple of months ago).
There's also some missing tooling. Better debugging support, for instance. That's mostly avoided by the use of unit tests and the REPL, but is occasionally required. Or profilers. Or code coverage tools. Due to the fact that everything is compiled to C, there are some tools that may be used, but it is still not ideal.
There isn't a problem with the CL community. There's a problem with the culture surrounding CL that seems to attract trolls.
Newbies get answers to genuine questions. I've received a great deal of help over the years from experience CL programmers. Anything from beginner questions to code reviews of various snippets I've been working on. I have received a lot of great advice over the years that has helped me tremendously. And I've seen other newcomers receive the same treatment as well. If you arrive in #lisp of c.l.l and have a genuine question about a problem you are stuck on you will likely attract someone willing to help you. It's a small community but it is friendly.
Second, CL was in the end designed to outlive itself. You get full programmatic access to the compiler and reader. It is trivial to add any feature a modern programmer may require that wasn't accounted for in the original specification. CLUEL could certainly have been useful if the author had finished it and put it out into the wild (maybe waiting until it was finished was the wrong choice).
I think if you are genuinely interested in learning CL you need to check your ego at the door, so to speak, and just start from scratch. Write programs that solve yours or your users' problems and ask questions in #lisp and on c.l.l if you get stuck. There is a wealth of great literature, papers, tools, and a small, friendly community to help you.
Edit: I meant to note that the reason the specification hasn't been updated, afaik, is because it doesn't have to be updated. All the tools you need to add the features you require are there in the spec. You can make it into the language you need.
Lets take a look at a few patterns I've noticed:
* Newbie posts some snippet and asks for review, the snippet is C++ code written in CL, lisper tells him it sucks, newbie explains that he has a lot of C++ experience and this is how his brain works. Lispers(now plural) explain to him that lisp must be learned with a beginners mind and he must forget C++ temporarily in order to learn it properly. Newbie gets insulted for some reason and begins arguing.
* newbie asks question about "generic lisp", lispers explain that the question makes no sense, and give his an answer about common lisp. Newbie asks question again emphasizing that he isn't interested in Common Lisp but in lisp in general, lispers tell him to read the topic, #lisp is about Common Lisp. Newbie argues that #lisp should be about generic lisp, and #commonlisp or whatever should be about CL, argument goes nowhere of course.
* newbie asks question and posts snippet. The code is obviously written by somebody with exactly 1 hour of lisp experience(parens are mismatched and aligned wrong, indentation is horrible, not to mention the obvious hacks). lispers explain that lisp is best learned patiently and not through the "learn x in y minutes" way, and that he should read Practical Common Lisp. Newbie gets insulted he was told to RTFM instead of getting an actual answer to his "wrong" question(at least in the eyes of us lispers).
* newbie asks about scheme/emacs and refuses to accept that #lisp isn't about those languages, see pattern #2.
* newbie asks scheme vs CL vs clojure vs haskell vs python vs ... question. Gets surprised when lispers unapologetically proclaim CL the best language ever and everything else is shit. Lispers do not hide their bias. Newbie then begins to argue about his favorite language and why it is better than lisp. Sometimes it's clojure, sometimes its scheme, or it could be whatever.
* (my favorite, and probably most frequent) Newbie asks what is lisp good for, gets pissed off when we tell him we program computers with it :)
Many other such questions include:
Q: "why isn't lisp popular" A: You haven't converted enough people to it :) Q: "Why does lisp have so few libraries" A: You haven't written enough libraries yet :) Q: "Why isn't there a library for X" A: Nobody needed it, if you do, write it and push it to github :) Q: "Why doesn't library X do Y" A: patches welcome.
Notice a pattern :)
All of these cases or variations of them have happened many times since I started to frequent #lisp, often times the word "fags" or "cunts" get used, and not by lispers.
That's a big part of the reason I haven't used CL for anything bigger than some toy projects.
It's a crusty, old language, and instead of keeping up with the times, everybody has to build the features they need. I can do that, or I can use language that has the features I need and that I don't have to assemble myself.
And to make it worse, it's hard to even use libraries that solve the problem, because nobody in the CL community can agree on anything. There's always a dozen incompatible solutions, and it's never clear which one should be used.
Welcome to software.
While your other sentiment seems logical, if you actually look at it as a lisp practitioner, you'll find the answers to the questions you have relatively easy. You don't have to "update" the language, for many things you can just use it like any other.
The problem isn't that lisp isn't updated, but that there aren't enough of us to build the lisp django, or at least there aren't enough of us who want the lisp django for it to happen, so thats why web development in lisp is limited to using raw hunchentoot or microframeworks like Restas and Caveman/Clack(which are both pretty awesome btw). Other than a few minor tweaks, lisp really doesn't need updating. More/better libraries would be sufficient!
Can you give a couple of specific examples where you think lisp is behind the times and you are "forced" to implement whatever. I can think of maybe a handful of such instances(there isn't a really great STM, but we do have other awesome concurrency options as just one example), but the list of lisp features I miss in python(my day job) is 1-2 dozens at least(and If I had macros and CLOS I could probably half that list in a week or two :)
In other words if you are crazy enough to use lisp for useful projects, the language will help you, maybe you haven't tried? Maybe you have and just had bad luck. Some domains(GUI programming for example) aren't as well supported for example. Others are pretty ok.
However unlike the C++ and ANSI C standards, the CL specification left room for programmers to extend the language as they need it. Instead of waiting for decades of expensive committee debates and meetings as you do with C/C++/ECMAScript/etc the programmers using the language in the field can go ahead and add the features they need and implementors can fill the gaps between new OSs and hardware. How is that bad?
And it's also bad because CL is ancient and it's filled with things that simply don't make sense any more, or have been replaced by "better" solutions in every other language. Look at filename and filepath handling to see what I mean. 2 or 3 of the fields haven't been used in real systems in 20 or 30 years, yet they're kept around because they're in the unchanging CL standard.
Let's address his complaints in two basic areas:
1. Community.
The Lisp community as typified by #lisp and comp.lang.lisp can be remarkably acerbic to the point of toxic, depending on who feels like contributing at the time. Part of this are the annoying trolls that show up; one's patience wears thin. A FAQ document might go a ways. However, there are a large number of people who don't ream newbies out and really are helpful. lispm here on HN is one of the friendliest Lispers out there and actually has helped me out tons.
Addendum: r/lisp on Reddit is good for generalish Lisp questions. StackOverflow's common lisp tag almost always gets an answer to most any reasonable question. sbcl-devel mailing list is useful if you want to take the time to posit in-depth technical questions to the SBCL developers. Lispforum, oddly enough, I haven't used much. I simply don't go there much. I should, I suppose. :)
2. Technical. I can do no better than quote my /r/lisp post on this (r/lisp is really good for lisp help).
---
First of all, consistency. A variety of things are peculiar in how they are named. TERPRI? Really?
Second, Common Lisp is a (the?) programmable programming language. CLUEL-esque platforms could be used to drive CDR adoption and cleanups of the original language.
My primary gripes with CL are the lack of CDR-2, lack of CDR-8, the lack of hierarchical namespaces, the funky naming conventions & expectations[1], and the lack of deeper CLOS integration[2].
[1] ELT vs AREF vs NTH, for instance. Or, LOOP for lists vs arrays vs (your data structure here).
[2] See CDR-8.
On the other hand, the mailing list did get a lot of posts that kind of remind me of this: "Hi, I just started using Plan 9, where's emacs? Anyway I have a lot of great ideas on how to fix this OS so you should all start doing these things... I'll set up the wiki and write the newbie guide"
On the other hand, the mailing list did get a lot of posts that kind of remind me of this: "Hi, I just started using Plan 9, where's emacs? Anyway I have a lot of great ideas on how to fix this OS so you should all start doing these things... I'll set up the wiki and write the newbie guide"
and this:
Dare to criticize something and they'll leap down your throat.
are related?
I doubt that, based on my observation of a strong correlation between intense academic study of the Bible and fortitude of Christian faith.