Are Lispers Taking Over This Wiki

Are they? "Discussion" of EssExpression as the ultimate mechanism for doing anydamnthing are splattering all over every page that has been touched recently. What is the deal here? Is Wiki full of SmugLispWeenies?

They are fighting with the InvasionOfTheRelationalWeenies for who gets to smoke the ObjectWeenies. But in short, no they aren't.

If you fear lispers, drive them back easily, with this question:

If Lisp is so great, why THERE IS NOT a single WikiEngines made in Common Lisp? Of course, it must run on apache to be a valid answer.

Ahem, CliKi?? (http://www.cliki.net/CLiki) Why must it run under Apache? Many of the other WikiEngines don't.

Because we trust Apache as a robust webserver. We can't start evaluating every custom webserver to run a little piece of software. Yeah, sometimes there may be good reasons to not run apache. A wiki is not one of them.

[On the contrary, although Apache is excellent, it is also vast overkill for many purposes, and a wiki may indeed be one such. In some cases, all that wiki software needs is basically to ride on top of the HTTP protocol, which is trivial to implement in barebones fashion. Granted, one must be careful not to succumb to Greenspunning; if one needs a full-fledged web server, then switching to Apache is the thing to do - but if you don't need such, there's also no need for Apache. It just depends on what you want to do.]

Wrong. If you serve static pages/images/banners, you can skip Apache. If you have dynamic content owned by no one, which lack basic security measures (a wiki, come on), you should at least put it on a secure server. It needs not to be Apache; it can be IIS, if you trust it.

I must note that Apache's default concurrency model (mpm fork) is incredibly inefficient. Each forked process is only capable of processing a single request at a time. It seems to me that all you really need an HTTP server to do is serve static content and proxy everything else to your wiki application server, and most people would be better served by something with a drastically smaller memory footprint.

On the other hand, is a wiki, so security was already throwed over the board. bring your toy server. Still, there is only one wiki engine made in Lisp, and it is not so great.

I don't know about common lisp but a few wiki engines that use apache that are coded in scheme are MoshiMoshi and WiLiKi amd WiLiKi can be run with apache (r2q2)

I don't think Lispers are taking over. I think they've been here all along, and there happens to be a lot of discussion recently about Lisp, dynamic typing, and XML, so they're coming out of the woodwork. Do they bother you somehow? -- RobertChurch

And how is this different from "discussions" of XML as the ultimate mechanism for doing anydamnthing?

Are there proponents of XML on this Wiki who claim XML is the Ultimate Solution? the way the Lispers here claim Lisp is?

Worse, like most of the rehashing of 40+ year old ideas (i.e., much of the programming technology of commercial interest), there are vocal XML'ers who claim all sorts of things about XML without understanding the history of the ideas behind it, what else has been done, or why. People who have watched this go around a few complete cycles get cynical, and annoyed when ignorant proponents of a 'brand new amazing idea' refuse to listen or learn, prefering to rush around like mad repeating decades-old mistakes yet again. In contrast, many lispers have a very good idea of what technologies fit where, and for the most part when they claim that lisp is a superior technology to do something, they are right (there are certainly exceptions, both in individuals and technologies). However, being a superior technology in this game is almost never enough. The same people who are drawn to lisp and similar languages are, I believe, exactly the sort of people who find this very hard to accept. There was a similar flavour to some of the smalltalk discussion here years ago, I believe for much the same reasons.

AhHa. That would make sense. I certainly don't want to argue that Lisp or XML or what-have-you is a superior technology to something else with which I am not familiar. My point originally was that the Lispers seem to be extremely vocal in their put-downs of XML, text processing, and other software languages. The strange thing is that I don't find the language or text processing mechanisms or any other single technical facet of development to be all that important by itself. My interest is in coming up with a solution, and if it means employing this language or that language, this text markup or that string expression processing, this methodology or that methodology, I don't care. My clients certainly don't care. My view of the problem is higher level that that, and I find such bickering over relatively low-level technical minutia to be a waste of valuable time.

On the other hand, it is not necessarily a low-level effect that is driving the discussion. Technologies can be enabling or constraining: perhaps what they are failing to convey is "If you use this approach, you will not be able to solve these types of problems with a resonable amount of work (or perhaps at all)". Some people vocally resist particular technologies because they have seen the widespread effects of poor technological choices on large projects, presumably ones they cared about. If what you really care about it solving problems, sometimes that has to manifest (as you suggest above) in caring about infrastructure, or in effect trying to make it possible to solve the problems.

But to suggest that one language or another is technically limiting to the extent that a technical problem can't be solved in that language is unreasonable. Unless you are stuck with something like GWBasic on a 4.77 MHz 8088 Plain Jane you have options. I get tired of hearing the more vocal Lisp proponents insist that their particular solution is the best solution to every problem they encounter. That simply can't be the case. A Chill Pill is called for, methinks.

--- I would consider it to be the other way around in my case. Before WardsWiki, I had heard of Lisp and even dabbled in EmacsLisp, but I didn't really see the point. Now, I aspire to SmugLispWeenie status.

You can even blame me if you like. I noticed that there seemed to be several knowledgeable LispAholics? here so I've sort of ... tried to encouraged them a little. -- MatthewAstley

I have lightly dabbled in LISP and I find it has intriguing ideas. However, as a language it will probably never earn one a cent, beyond possible "mind expanding" issues. Thus, I have not pursued it very deeply. If you use high-fallutin concepts, other developers will complain that they cannot read your code, and you sound like an over-educated dweeb when trying to explain it. About the only place I see functional or logical programming being semi-mainstream is in the form of relational languages, SQL in particular (which is probably not the best relational language - SqlFlaws).

Thus, LISP is too far from getting mainstream acceptance to consider in a practical setting. If you want to sell people on it, then find some EmpiricalEvidence that it is objectively superior. Without that, it will only turn into a HolyWar.

To return to the question posed on this page, no, I don't think Lispers are taking over this wiki. What may be happening is that Lisp seems to be, for whatever reason, experiencing a small but significant increase in attention recently. I haven't been following the Lisp scene long enough to venture a guess why. But in any case, as people become (re)acquainted with Lisp, there are more questions being asked about it here, since Ward's wiki is a hotbed of discussions on difficult programming topics, techniques, and languages. And the Lisp cognescenti who have always been here are taking the opportunity to answer those questions, and are perhaps also becoming more interested in venturing their Lisp-flavored opinions on programming topics due to the attention. All good stuff, in my opinion - I for one was getting kind of burnt out on exposes of clever C++ programming techniques, and was never terribly interested in Java programming discussions. -- DanMuller

PaulGraham's recent drumbeating for Lisp has gotten it more attention in the last year or so than in the preceding decade. He was even the keynote speaker at the 2003 Python convention (PyCon) - which highlights another related rise: that of dynamically-typed, not-necessarily-compiled languages such as Python and Ruby.

I was under the impression LISP was popular in AI because it's simple syntax made it easier for programs to dynamically write programs.

[Little or nothing in Lisp is unique to it among programming languages. What is unusual is the number of useful tools that come together in this one (family of) language(s). Personally, as I've been relearning Lisp recently, what I have found difficult about it is getting used to the different environment surrounding the actual coding: The replacement of the write-run or write-compile-link-run cycle with the distinct and slightly confusing concepts of loading, compiling, and interactive development. The lack of documented "best practices" for organization of large programs. (Pointers welcome.) The idiosyncratic means of building self-contained executable files. (I haven't had to deal with this directly yet, but it looks to be quite different from one implementation to another, and somewhat complex.)]

"I was under the impression it was popular in AI because it's simple syntax made it easier for programs to dynamically write programs." - [That's true in some cases, but that technique isn't used nearly as often as you might think, except in the form of macros. The availability of symbols as first-class objects (most languages have them only implicitly as an inaccessible compile-time concept) makes things like pattern-matching very easy, and matching patterns occurs frequently in AI. Sophisticated macros make it easy to legibly organize large amounts of data, as is needed for instance in expert systems, and then have that data organized as desired or even have it transformed into code at compile-time, simply by rewriting a macro. As Tayssir pointed out, another appealing feature is the ease with which one can switch between using imperative and functional styles. I try to use a functional style where possible in C++ because it's usually easier to understand and debug, but you sometimes have to jump through hoops to preserve efficiency. In Lisp, it's quite natural to switch between the two. Much of what Lisp's ompiler macros can do can also be emulated in C++ with templates, but with far greater difficulty.]

[It's really about the number of language features that come together in Lisp, and the smoothness with which they're integrated with the language. That's probably why it's hard to articulate the advantages in a brief discourse; it's an accumulation of many small things, which together tend to have the effect of getting the language out of our way when you have an idea that you want to transform into code.]

[The bottom line is that taking the time to learn a new programming language, especially one that includes support for paradigms that you're less familiar with, will enhance your design and programming skills in almost any language. You'll come across concepts and idioms that open your mind to new ways of thinking about problems, and some of those ideas can usually be transported back to the language that you prefer - or are required - to use, although perhaps with greater difficulty. The effort is rarely wasted. Another language that taught me a lot is Oz. It's also a multi-paradigm language, but some of the most basic idioms in that language are completely different from any other language I've worked in. I haven't spent much time with Haskell or ML, but I suspect that the core OzLanguage is conceptually related to them. -- DanMuller]

Favorite quote from this discourse: "it's important to choose wisely which zealots you listen to."

That is something I actually believe too, and I've spent some time through writing, trying to get at the heart of this intuition. While writing, I realized there were different audiences to consider, and I had to write differently for different audiences.

See: WikiWarrior

CategoryRant, CategoryLisp

EditText of this page (last edited July 8, 2013) or FindPage with title or text search